Better Specs with Adversarial AI and Glossary Skills

Multi-Model Spec Review and Glossary Skills using OpenSpec and OpenCode

This post extends the OpenSpec + OpenCode walkthrough with two new skills added to the [intent-driven-template](https://github.com/intent-driven-dev/intent-driven-template): adversarial authoring and glossary. Both are aimed at getting your specifications into good shape before they reach human review.

The Problem These Solve

Specs written by a single model carry that model’s blind spots, and we often have to intervene by handing these specifications to another model to avoid bias. A second issue with specifications authored by agents is the inconsistency in terminology across sessions. Each model may have its own way of expressing the spec. And also, each human reviewing it may also have their own inputs. We need a way to both reduce model bias and remain consistent by building domain-specific terminology to achieve better specifications. These two skills address that directly.

1. Adversarial Authoring — Cross-Model Review Inside the Workflow

The [adversarial-authoring skill](https://github.com/intent-driven-dev/intent-driven-template/tree/main/.agents/skills) wires two sub-agents into the proposal phase: one author, one reviewer. A common setup is having one model write the proposal and another model review it - Claude writing and GPT reviewing, or vice versa.

For example, if we use this skill to author proposal.md, this also produces council notes: what the author subagent wrote, what the reviewer subagent challenged, and how each challenge was resolved - accepted, rejected, and why.

This matters because:

• Different models surface different assumptions and biases
• Over-specification gets caught before it reaches you
• The decision trail is visible, not buried in a chat session

Keep it to two or three sub-agents. More than that and the output becomes noise.

The [glossary skill](https://github.com/intent-driven-dev/intent-driven-template/tree/main/.agents/skills) runs during the design phase and maintains a file of domain and technical terms with precise definitions scoped to your application.

Consider a common scenario: an agent designing an import layer for inconsistent legacy CSV data might coin a term like translation boundary service — verbose, invented, and unfamiliar to your team. The right term is anti-corruption layer (ACL), a Domain-Driven Design context mapping pattern introduced by Eric Evans: “an isolating layer to provide your system with functionality of the upstream system in terms of your own domain model” — a concept your engineers already know. This way we can reduce inconsistency where one person calls ACL a translation boundary and others may use some other term. And each of these may be slightly different. When we agree on the concept we are using that leads to clear specifications.

Why this helps over time:

• Terms defined once are reused by the agent in every subsequent spec
• Engineers at different experience levels converge on the same language
• Agents are part of your team — shared terminology applies to them too

A single precise term like idempotent or anti-corruption layer carries more information than a paragraph of approximation.

The same applies to terminology specific to your organization or industry. In a run club, a sweeper (or tail runner) is the volunteer who runs at the back of the pack — matching the pace of the slowest participant, ensuring no one is left behind or lost, and relaying updates to the lead group or organizers. An agent designing a run club management feature might describe this role as a “designated rear-of-pack participant welfare coordinator” — verbose and imprecise. Your team calls it a sweeper. Define it once in the glossary — with its responsibilities scoped to your club’s rules — and the agent will use that term in every spec it writes after that.

Putting It Together

These skills complement the ones we discussed in our previous post. Adversarial authoring reduces model bias. Glossary enforces terminological consistency. Combined with grill-me for interrogating the plan upfront - covered in the previous post - the spec that arrives at your desk should require our review, and much less cleanup.

The [intent-driven schema](https://github.com/intent-driven-dev/openspec-schemas/tree/main/openspec/schemas/intent-driven) automatically sequences all of this. You don't have to remember to run the review; it's built into the workflow.

Video Walkthrough

[embed]

References

• Intent-Driven Template — intent-driven-dev/intent-driven-template
• Adversarial Authoring skill — [.agents/skills/adversarial-authoring](https://github.com/intent-driven-dev/intent-driven-template/tree/main/.agents/skills)
• Glossary skill — [.agents/skills/glossary](https://github.com/intent-driven-dev/intent-driven-template/tree/main/.agents/skills)
• OpenSpec — Fission-AI/OpenSpec
• Anti-Corruption Layer — Wikipedia; Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software (2003), Chapter 14: Maintaining Model Integrity
• Previous post — Spec-Driven Development with OpenSpec and OpenCode

Originally published at https://intent-driven.dev on June 27, 2026.