Agent Orchestration
Skill
/writing-specs
Use when agent_specs is on (or the user asks for a spec) to write what done looks like and why before a plan or implementation.
Claude Code
$ npx -y skills add iha2/superlite --skill writing-specs --agent claude-code
Codex
$ npx skills add iha2/superlite --skill writing-specs -a codex -y
Cursor
$ npx skills add iha2/superlite --skill writing-specs -a cursor -y
Gemini CLI
$ npx skills add iha2/superlite --skill writing-specs -a gemini-cli -y
GitHub Copilot
$ npx skills add iha2/superlite --skill writing-specs -a github-copilot -y
OpenCode
$ npx skills add iha2/superlite --skill writing-specs -a opencode -y
Windsurf
$ npx skills add iha2/superlite --skill writing-specs -a windsurf -y
SKILL.md
writing-specs.SKILL.mdname: writing-specs
description: Use when agent_specs is on (or the user asks for a spec) to write what done looks like and why before a plan or implementation.
Writing specs
A **spec** defines what “done” looks like and **why**. A **plan** chooses **how** to get there. One spec can outlive many plans: rewrite or replace the plan without rewriting success criteria. The spec is durable authority; if a plan drifts, fix the plan or report `DONE_WITH_CONCERNS`—never silently override the spec.
When
- Check `bash "$CLI" agent_specs status`. If **off**, skip unless the user asked for a spec.
- **Feature flow (default):** write one **feature-sized** spec before implementers code (and before or beside the `.feature.md` / machine plan as the success criteria). Optional task-local notes under `.superlite/specs/<plan-topic>/` refine *how* for a long-running task; they must stay consistent with the feature spec.
- No human gate on task-local notes. Feature-level specs and plans may be opened for the user when `open_in_harness` is on.
Paths
- Feature (or sub-feature) spec: `docs/plans/YYYY-MM-DD-<topic>.spec.md` (or the path the user names).
- Task-local note (optional): `.superlite/specs/<plan-topic>/T<N>-<slug>.md`.
Shape
Use `templates/feature-spec.md`. Prefer diagrams and tables; keep prose outside fences and tables ≤ 150 words for task-local notes. Feature specs may be longer but stay dense: intent/why, goals and non-goals, constraints, what “done” looks like (acceptance), decided vs left to the builder. Mermaid first for structure, flow, or state.
Open in harness
When status shows `open_in_harness: on`, after writing the file, open it for the user (`superlite:drafting`, After writing; the harness's open row is in `using-superlite/references/<harness>-tools.md`). The flag now covers plans and specs. `superlite-cli agent_specs open off` turns it off without disabling specs.
Style (flows §9)
| Rule | Instead of | |---|---| | Diagram first for structure, flow, or state | Paragraphs of boxes and arrows | | Tables for contracts, options, edge cases | Long bullet prose | | Precise technical register | Vague paraphrase | | Every sentence a fact, constraint, or decision | Filler and restatement |
Read more
name: writing-specs description: Use when agent_specs is on (or the user asks for a spec) to write what done looks like and why before a plan or implementation.
Writing specs
A **spec** defines what “done” looks like and **why**. A **plan** chooses **how** to get there. One spec can outlive many plans: rewrite or replace the plan without rewriting success criteria. The spec is durable authority; if a plan drifts, fix the plan or report `DONE_WITH_CONCERNS`—never silently override the spec.
When
- Check `bash "$CLI" agent_specs status`. If **off**, skip unless the user asked for a spec.
- **Feature flow (default):** write one **feature-sized** spec before implementers code (and before or beside the `.feature.md` / machine plan as the success criteria). Optional task-local notes under `.superlite/specs/<plan-topic>/` refine *how* for a long-running task; they must stay consistent with the feature spec.
- No human gate on task-local notes. Feature-level specs and plans may be opened for the user when `open_in_harness` is on.
Paths
- Feature (or sub-feature) spec: `docs/plans/YYYY-MM-DD-<topic>.spec.md` (or the path the user names).
- Task-local note (optional): `.superlite/specs/<plan-topic>/T<N>-<slug>.md`.
Shape
Use `templates/feature-spec.md`. Prefer diagrams and tables; keep prose outside fences and tables ≤ 150 words for task-local notes. Feature specs may be longer but stay dense: intent/why, goals and non-goals, constraints, what “done” looks like (acceptance), decided vs left to the builder. Mermaid first for structure, flow, or state.
Open in harness
When status shows `open_in_harness: on`, after writing the file, open it for the user (`superlite:drafting`, After writing; the harness's open row is in `using-superlite/references/<harness>-tools.md`). The flag now covers plans and specs. `superlite-cli agent_specs open off` turns it off without disabling specs.
Style (flows §9)
| Rule | Instead of | |---|---| | Diagram first for structure, flow, or state | Paragraphs of boxes and arrows | | Tables for contracts, options, edge cases | Long bullet prose | | Precise technical register | Vague paraphrase | | Every sentence a fact, constraint, or decision | Filler and restatement |
Ships withsuperlite
A fast software factory workflow for Claude Code: one approval gate, parallel waves, routed models
24912 skills8 agents
Stars on GitHub
Momentum
- stars in total
- 249
Other skills on superlite.
More skills from other plugins.
agentmail
Use your assigned AgentMail inbox to read email tasks, explicitly send or reply, and check delivery. Provided automatically by…
@paperclipaiInstall Skilladr-create
Create a new Architecture Decision Record with sequential numbering and AgentDB registration
@ruvnetInstall SkillQuestions about writing-specs.
- Which coding agents can use writing-specs?
- writing-specs installs in Claude Code, Codex, Cursor, Gemini CLI, GitHub Copilot, OpenCode and Windsurf with the skills CLI, using each agent's flag shown on this page. Flowy's auto-invocation, which fires a skill when your prompt matches, runs in Claude Code only.