Source Command Ccg Spec Impl

source-command-ccg-spec-impl

Use this skill when the user asks to run the migrated source command ccg-spec-impl.

Command Template

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 Codex/Gemini 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.

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

   • Use /ccg:spec-impl (which uses OpenSpec skills internally) to enter implementation mode.
   • This skill will guide you through the tasks defined in tasks.md.

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: Gemini — Frontend/UI/styling (CSS, React, Vue, HTML, components)
   • Route B: Codex — Backend/logic/algorithm (API, data processing, business logic)

   For each task:

   codeagent-wrapper --backend <codex|gemini> --gemini-model gemini-3-pro-preview - "$PWD" <<'EOF'
   TASK: <task description from tasks.md>
   CONTEXT: <relevant code context>
   CONSTRAINTS: <constraints from spec>
   OUTPUT: Unified Diff Patch format ONLY
   EOF
   

   Note: --gemini-model parameter is only used when --backend gemini is specified.

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 Codex AND Gemini 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.

   Step 7.1: In ONE message, make TWO parallel Bash calls:

   FIRST Bash call (Codex):

   Bash({
     command: "/Users/tangchunwu/.Codex/bin/codeagent-wrapper --backend codex - \"$PWD\" <<'EOF'\nReview the implementation changes:\n- Correctness: logic errors, edge cases\n- Security: injection, auth issues\n- Spec compliance: constraints satisfied\nOUTPUT: JSON with findings\nEOF",
     run_in_background: true,
     timeout: 300000,
     description: "Codex: correctness/security review"
   })
   

   SECOND Bash call (Gemini) - IN THE SAME MESSAGE:

   Bash({
     command: "/Users/tangchunwu/.Codex/bin/codeagent-wrapper --backend gemini --gemini-model gemini-3-pro-preview - \"$PWD\" <<'EOF'\nReview the implementation changes:\n- Maintainability: readability, complexity\n- Patterns: consistency with project style\n- Integration: cross-module impacts\nOUTPUT: JSON with findings\nEOF",
     run_in_background: true,
     timeout: 300000,
     description: "Gemini: maintainability/patterns review"
   })
   

   Step 7.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 })
   

   Address any critical findings before proceeding.

8. Update Task Status

   • Mark completed task in tasks.md: - [x] Task description
   • Commit changes if appropriate.

9. Context Checkpoint

   • After completing a phase, report context usage.
   • If below 80K: Ask user "Continue to next phase?"
   • If approaching 80K: Suggest "Run /clear and resume with /ccg:spec:impl"

10. Archive on Completion

    • When ALL tasks in tasks.md are marked [x]:
    • The agent will use OpenSpec skills to archive the change.
    • This merges spec deltas to openspec/specs/ and moves change to archive.

Reference

• Check task status: openspec status --change "<id>" --json
• View active changes: openspec list --json
• Search existing patterns: rg -n "function|class" <file>

Exit Criteria Implementation is complete when:

• All tasks in tasks.md marked [x]
• All multi-model reviews passed
• Side-effect review confirmed no regressions
• Change archived successfully