ReddRadar
Agent skill
writing-commands
Use when creating new commands, editing existing commands, or reviewing command quality. Triggers: 'write command', 'new command', 'create a command', 'review command', 'fix command', 'command doesn't work', 'add a slash command'. NOT for: skill creation (use writing-skills).
Install this agent skill to your Project
npx add-skill https://github.com/axiomantic/spellbook/tree/main/skills/writing-commands
SKILL.md
Writing Commands
Announce: "Using writing-commands skill for command creation, editing, or review."
Invariant Principles
- Commands are direct prompts: A command loads entirely into context. No phases, no subagents, no orchestration. The agent reads it and does the work.
- Structure enables scanning: Agents under pressure skim. Sections, tables, and code blocks catch the eye. Prose paragraphs get skipped.
- FORBIDDEN closes loopholes: Every command needs explicit negative constraints. Agents rationalize under pressure. Each excuse needs a counter.
- Reasoning tags force deliberation:
<analysis>before action,<reflection>after. Without these, agents skip straight to output. - Paired commands share a contract: If command A creates artifacts, command B must know exactly how to find and remove them. The manifest format is the interface.
Inputs
| Input | Required | Description |
|---|---|---|
| Command purpose | Yes | What the command should accomplish when invoked |
| Trigger phrase | Yes | The /command-name that invokes it |
| Existing command | No | Path to command being reviewed or edited |
Outputs
| Output | Type | Description |
|---|---|---|
| Command file | commands/<name>.md |
Complete command following schema |
| Review report | Inline | Quality assessment against checklist (review mode) |
Phase Overview
| Phase | Name | Purpose | Command |
|---|---|---|---|
| 1 | Create | Schema, naming, required/optional sections, example, token efficiency | /writing-commands-create |
| 2 | Review | Quality checklist, anti-patterns, review protocol, testing protocol | /writing-commands-review |
| 3 | Paired | Paired command protocol, assessment framework integration | /writing-commands-paired |
Phase 1: Create Command
Define command structure using the schema: file naming, frontmatter, required sections, optional sections, and token efficiency targets.
Execute: /writing-commands-create
Outputs: Command file at commands/<name>.md
Self-Check: Frontmatter present, all required sections included, imperative language used, token targets met.
Phase 2: Review Command
Run the quality checklist against the command. Score structure, content quality, behavioral correctness, and anti-pattern avoidance. Follow the review and testing protocols.
Execute: /writing-commands-review
Outputs: Review report with score, passing/failing checks, critical issues.
Self-Check: All checklist items evaluated, score calculated, critical issues flagged.
Phase 3: Paired Commands
When a command creates artifacts, ensure a paired removal command exists with proper manifest, discovery, safety, and verification contracts.
Execute: /writing-commands-paired
Outputs: Paired command file, cross-references in both commands.
Self-Check: Manifest format defined, both commands cross-reference each other, removal is safe.
Self-Check
Before completing command creation or review:
- Frontmatter has
descriptionfield with triggers, not workflow - MISSION section is one clear paragraph
- ROLE tag has domain expert + stakes
- 3-5 Invariant Principles, each testable
- Execution steps are numbered and imperative
- Every step that can fail has a failure path
- Output section has concrete format
- FORBIDDEN section has 5+ specific prohibitions
- Analysis tag prompts pre-action reasoning
- Reflection tag asks specific verification questions
- If paired: partner command referenced, manifest format defined
If ANY unchecked: STOP and fix before declaring complete.
<FINAL_EMPHASIS> Commands are the atomic unit of agent behavior. A well-written command is a contract between the author and every future agent that loads it. Ambiguity in that contract means agents will do the wrong thing under pressure. Precision in that contract means agents do the right thing even when rushed. Write for the agent under pressure, not the calm reviewer reading at leisure. </FINAL_EMPHASIS>
Recommended Agent Skills
Expand your agent's capabilities with these related and highly-rated skills.
axiomantic/spellbook
spellbook-auditing
Meta-audit skill for spellbook development. Spawns parallel subagents to factcheck docs, optimize instructions, find token savings, and identify MCP candidates. Produces actionable report.
axiomantic/spellbook
documentation-updates
Use after modifying library skills, library commands, or agents to ensure CHANGELOG, README, and docs are updated
axiomantic/spellbook
project-encyclopedia
[DEPRECATED] Use project-level AGENTS.md files instead. Previously used for first-session codebase onboarding and persistent glossary creation.
axiomantic/spellbook
reviewing-impl-plans
Use when reviewing implementation plans before execution. Triggers: 'is this plan solid', 'review the plan', 'check before I start building', 'anything missing from this plan', 'will this plan work', 'audit the implementation plan'. NOT for: reviewing design documents (use reviewing-design-docs) or creating plans (use writing-plans).
axiomantic/spellbook
session-resume
Session resume protocol and session repairs handling. Loaded when spellbook_session_init returns resume_available: true, or when session_init returns a repairs array. Triggers: 'resume', 'continue', 'where were we', session resume, session repairs.
axiomantic/spellbook
brainstorming
Use when exploring design approaches, generating ideas, or making architectural decisions. Triggers: 'explore options', 'what are the tradeoffs', 'how should I approach', 'let's think through', 'sketch out an approach', 'I need ideas for', 'how would you structure', 'what are my options'. Also invoked by develop when design decisions are needed.
Didn't find tool you were looking for?