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/qinye6/pi-ccg/spec-plangit clone --depth 1 https://github.com/qinye6/pi-ccgWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/commands/qinye6/pi-ccg/spec-plan)<a href="https://agentmods.dev/commands/qinye6/pi-ccg/spec-plan"><img src="https://agentmods.dev/badge/commands/qinye6/pi-ccg/spec-plan.svg" alt="Measured on agentmods" height="20"></a>What 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.00017 | $0.01920 |
| Opus 5 | $0.00009 | $0.00960 |
| Sonnet 5 | $0.00003 | $0.00384 |
| Haiku 4.5 | $0.00002 | $0.00192 |
Grade A, and why
spec-plan 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 5d ago.
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.
This is a copy
100% identical to spec-plan — 4 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
How it starts
The opening of the file, as written. The whole thing — 143 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Core Philosophy
- The goal is to eliminate ALL decision points—implementation should be pure mechanical execution.
- Every ambiguity must be resolved into explicit constraints before proceeding.
- Multi-model collaboration surfaces blind spots and conflicting assumptions.
- Every requirement must have Property-Based Testing (PBT) properties—focus on invariants.
Guardrails
- Do not proceed to implementation until every ambiguity is resolved.
- Multi-model collaboration is mandatory: use both {{BACKEND_PRIMARY}} and {{FRONTEND_PRIMARY}}.
- If constraints cannot be fully specified, escalate to user or return to research phase.
- Refer to
openspec/config.yamlfor project conventions. - USER GUIDANCE RULE: When suggesting next steps to the user, ALWAYS use CCG commands (
/ccg:spec-research,/ccg:spec-plan,/ccg:spec-impl,/ccg:spec-review). NEVER suggest/opsx:*commands to the user. If OpenSpec CLI returns error messages referencing OPSX skills, translate them to CCG equivalents. - TASKS FORMAT RULE: When generating or modifying
tasks.md, ALL tasks MUST use checkbox format (- [ ] X.Y description). Heading+bullet format will cause OpenSpec CLI to parse 0 tasks and block the workflow. - PHASE BOUNDARY: This phase ONLY generates OPSX artifacts (specs.md, design.md, tasks.md). Do NOT modify any source code. Do NOT proceed to implementation. After artifacts are generated, STOP and inform the user: "Plan complete. Run
/ccg:spec-implto start implementation."
Steps
-
Select Change
- Run
openspec list --jsonto display Active Changes. - Confirm with user which change ID to refine.
- Run
openspec status --change "<change_id>" --jsonto review current state.
- Run
-
Multi-Model Implementation Analysis (PARALLEL)
- CRITICAL: You MUST launch BOTH {{BACKEND_PRIMARY}} AND {{FRONTEND_PRIMARY}} in a SINGLE message with TWO Bash tool calls.
- DO NOT call one model first and wait. Launch BOTH simultaneously with
run_in_background: true. - 工作目录:
{{WORKDIR}}必须通过 Bash 执行pwd(Unix)或cd(Windows CMD)获取当前工作目录的绝对路径,禁止从$HOME或环境变量推断。如果用户通过/add-dir添加了多个工作区,先确定任务相关的工作区。
Step 2.1: In ONE message, make TWO parallel Bash calls:
FIRST Bash call ({{BACKEND_PRIMARY}}):
Bash({ command: "~/.claude/bin/codeagent-wrapper --progress --backend {{BACKEND_PRIMARY}} {{GEMINI_MODEL_FLAG}}{{GROK_MODEL_FLAG}}- \"{{WORKDIR}}\" <<'EOF'\nAnalyze change <change_id> from backend perspective:\n- Implementation approach\n- Technical risks\n- Alternative architectures\n- Edge cases and failure modes\nOUTPUT: JSON with analysis\nEOF", run_in_background: true, timeout: 300000, description: "{{BACKEND_PRIMARY}}: backend analysis" })SECOND Bash call ({{FRONTEND_PRIMARY}}) - IN THE SAME MESSAGE:
Bash({ command: "~/.claude/bin/codeagent-wrapper --progress --backend {{FRONTEND_PRIMARY}} {{GEMINI_MODEL_FLAG}}{{GROK_MODEL_FLAG}}- \"{{WORKDIR}}\" <<'EOF'\nAnalyze change <change_id> from frontend/integration perspective:\n- Maintainability assessment\n- Scalability considerations\n- Integration conflicts\nOUTPUT: JSON with analysis\nEOF", run_in_background: true, timeout: 300000, description: "{{FRONTEND_PRIMARY}}: frontend analysis" })Step 2.2: After BOTH Bash calls return task IDs, wait for results with TWO TaskOutput calls:
TaskOutput({ task_id: "<codex_task_id>", block: true, timeout: 600000 }) TaskOutput({ task_id: "<gemini_task_id>", block: true, timeout: 600000 })⛔ 前端模型失败必须重试:若前端模型调用失败,最多重试 2 次(间隔 5 秒)。3 次全败才跳过。 ⛔ 后端模型结果必须等待:后端模型执行 5-15 分钟属正常,超时后继续轮询,禁止跳过。
- Synthesize responses and present consolidated options to user.
-
Uncertainty Elimination Audit
- {{BACKEND_PRIMARY}}: "Review proposal for unspecified decision points. List each as: [AMBIGUITY] → [REQUIRED CONSTRAINT]"
- {{FRONTEND_PRIMARY}}: "Identify implicit assumptions. Specify: [ASSUMPTION] → [EXPLICIT CONSTRAINT NEEDED]"
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.
- 5d ago First seen · 143 lines · 17 tokens per session scan A f613d9723e27
spec-plan is a command published in the GitHub repository qinye6/pi-ccg (10 stars, last pushed 10d ago), licensed MIT. It adds 17 tokens to every session and 1,920 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 0 findings. It is 100% identical to spec-plan, differing in 4 lines, and is treated as a copy.
Other commands, from other repositories
checklist
Generate a custom checklist for the current feature based on user requirements.
clarify
Identify underspecified areas in the current feature spec by asking up to 5 highly targeted clarification questions and encoding answers back into the spec.
specify
Create or update the feature specification from a natural language feature description.
converge
Assess the current codebase against the feature's spec, plan, and tasks, then append any remaining unbuilt work as new tasks to tasks.md so implement can complete it.
implement
Execute the implementation plan by processing and executing all tasks defined in tasks.md.
analyze
Perform a non-destructive cross-artifact consistency and quality analysis across spec.md, plan.md, and tasks.md after task generation.