This post extends the OpenSpec + OpenCode walkthrough with two new skills added to the 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 to hand these specifications to another model so that we 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 the model bias as well as be consistent by building domain terminology to achieve better specifications.

These two skills address that directly.

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

The adversarial-authoring skill wires two sub-agents into the proposal phase: one authors, one reviews. 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.

2. Glossary — Shared Language as a First-Class Artifact

The glossary skill 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 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. Similarly, you can also use the glossary for domain-specific language — if your team works in a specialised domain, define the terms once rather than relying on each agent session to approximate them fresh.

Putting It Together

These skills are complementary to the skills we had 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 sequences all of this automatically. You don’t have to remember to run the review; it’s built into the workflow.

Video Walkthrough

References