spec-impl

Core Philosophy

• Implementation is pure mechanical execution—all decisions were made in Plan phase.
• External model outputs are prototypes only; must be rewritten to production-grade code.
• Keep changes tightly scoped; enforce side-effect review before any modification.
• Minimize documentation—prefer self-explanatory code over comments.

Guardrails

• NEVER apply 后端/前端模型 prototypes directly—all outputs are reference only.
• MANDATORY: Request unified diff patch format from external models; they have zero write permission.
• Keep implementation strictly within tasks.md scope—no scope creep.
• Refer to openspec/config.yaml for 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.

Steps

1. Select Change

   • Run openspec list --json to inspect Active Changes.
   • Confirm with user which change ID to implement.
   • Run openspec status --change "<change_id>" --json to review tasks.

2. Apply OPSX Change (Pre-flight Check)

   • Call /opsx:apply internally to enter implementation mode:

     /opsx:apply
     

   • This will load the change context and guide you through the tasks defined in tasks.md.
   • Note: This is an internal call. If this step fails, guide the user to re-run /ccg:spec-impl.
   • HARD GATE: Check the returned state field:
     • If state: "blocked" → STOP immediately. Inform the user which artifacts are missing and suggest: "Run /ccg:spec-plan to generate missing artifacts first."
     • If progress.total === 0 → STOP immediately. Inform: "tasks.md has no parseable tasks. Run /ccg:spec-plan to regenerate."
     • Only proceed to Step 3 when state: "ready" and progress.total > 0.

3. Identify Minimal Verifiable Phase

   • Review tasks.md and identify the smallest verifiable phase.
   • Do NOT complete all tasks at once—control context window.
   • Announce: "Implementing Phase X: [task group name]"

4. Route Tasks to Appropriate Model

   • Route A: {{FRONTEND_PRIMARY}} — Frontend/UI/styling (CSS, React, Vue, HTML, components)
   • Route B: {{BACKEND_PRIMARY}} — Backend/logic/algorithm (API, data processing, business logic)

   工作目录：{{WORKDIR}} 必须通过 Bash 执行 pwd（Unix）或 cd（Windows CMD）获取当前工作目录的绝对路径，禁止从 $HOME 或环境变量推断。如果用户通过 /add-dir 添加了多个工作区，先确定任务相关的工作区。

   For each task:

   codeagent-wrapper --progress --backend <{{BACKEND_PRIMARY}}|{{FRONTEND_PRIMARY}}> {{GEMINI_MODEL_FLAG}}{{GROK_MODEL_FLAG}}- "{{WORKDIR}}" <<'EOF'
   TASK: <task description from tasks.md>
   CONTEXT: <relevant code context>
   CONSTRAINTS: <constraints from spec>
   OUTPUT: Unified Diff Patch format ONLY
   EOF
   

   会话复用：保存返回的 SESSION_ID:（{{BACKEND_PRIMARY}} → CODEX_PROTO_SESSION，{{FRONTEND_PRIMARY}} → GEMINI_PROTO_SESSION），Step 7 审查时复用。

5. Rewrite Prototype to Production Code Upon receiving diff patch, NEVER apply directly. Rewrite by:

   • Removing redundancy
   • Ensuring clear naming and simple structure
   • Aligning with project style
   • Eliminating unnecessary comments
   • Verifying no new dependencies introduced

6. Side-Effect Review (Mandatory before apply) Verify the change:

   • Does not exceed tasks.md scope
   • Does not affect unrelated modules
   • Does not introduce new dependencies
   • Does not break existing interfaces

   If issues found, make targeted corrections.

7. Multi-Model Review (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.