Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add commands/gpolanco/dev-workflows/specgit clone --depth 1 https://github.com/gpolanco/dev-workflowsWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00009 | $0.00279 |
| Opus 5 | $0.00005 | $0.00139 |
| Sonnet 5 | $0.00002 | $0.00056 |
| Haiku 4.5 | $0.00001 | $0.00028 |
Grade A, and why
spec scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured yesterday.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
What it actually says
You are a senior software architect. Your job is to create a clear, complete specification for a new feature.
Follow this process:
-
Ask 3-5 clarifying questions about the feature. Focus on:
- What problem does this solve?
- Who is the target user?
- What are the key constraints (performance, compatibility, etc.)?
- What does success look like?
-
Research the codebase before writing. Look at:
- Existing patterns and conventions
- Related features that already exist
- Technology stack and dependencies
-
Generate the spec in
docs/specs/<feature-name>.mdusing this structure:
# Feature: <name>
## Summary
One paragraph describing the feature and its purpose.
## Requirements
- [ ] Requirement 1
- [ ] Requirement 2
## Technical Constraints
- Constraint 1
- Constraint 2
## Edge Cases
- Edge case 1
- Edge case 2
## Acceptance Criteria
- [ ] Criterion 1
- [ ] Criterion 2
Wait for the user to answer your questions before generating the spec. Do not make assumptions.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- yesterday First seen · 48 lines · 9 tokens per session scan A 7edf31aaf270
spec is a command published in the GitHub repository gpolanco/dev-workflows (1 stars, last pushed 2mo ago), licensed MIT. It adds 9 tokens to every session and 279 once invoked, about $0.0000 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other commands, from other repositories
icpg-bootstrap
Infer ReasonNodes from existing git commit history. One-time setup for existing codebases.
version
Display current guide and Claude Code versions.
go-review
Go code review for idiomatic patterns.
review-branch
Review the current branch's diff against base by dispatching atomic-reviewer. No orchestration loop, no spec required — pre-flight before /commit pr or /commit merge.
session-report
Capture what changed this session and why, scoped to the current branch. Read by ship verbs when synthesizing the commit message; deleted after a successful commit.
execute
Executa o plano aprovado em .first-plan/07-state/plans/. Segue o plano à risca, para se algo invalidar premissa, gera relatório ao final.