1. Auto-detect input language → output in the same language
2. Japanese input → Japanese output, use

   references/implement-guide.ja.md

3. English input → English output, use

   references/implement-guide.md

4. Explicit override takes priority (e.g., "in English", "日本語で")

1. Verify environment:
   • Run

     pwd

     to confirm working directory
   • Run

     git status

     to confirm inside a git repository
   • Run

     gh auth status

     to confirm GitHub CLI access
2. Parse user input for options:

   • --resume

     → resume from last uncompleted task

   • --issue {N}

     → specify GitHub Issue number

   • --spec {path}

     → specify

     .specs/

     directory path

   • --dry-run

     → show execution plan without making changes

   • --parallel

     → force parallel execution if environment is ready

   • --no-parallel

     → force sequential execution
3. Locate spec directory:
   • If

     --spec

     provided → use that path
   • If issue body contains

     .specs/

     path → use that
   • Otherwise → scan

     .specs/

     and ask user to select:

     AskUserQuestion:
       question: "Which spec to implement?" / "どの仕様書を実装しますか？"
       options: [list discovered .specs/ directories]

4. Locate and read project files (in this order):
   Workflow playbook — search in order, use first found:

   1. docs/development/issue-to-pr-workflow.md

   2. docs/issue-to-pr-workflow.md

   3. Fallback:

      find . -name "issue-to-pr-workflow.md" -not -path "*/node_modules/*" -not -path "*/.git/*" -not -path "*/vendor/*" -not -path "*/dist/*" -not -path "*/build/*" | head -1

   4. If not found → trigger fallback (see Phase 1)
   Coding rules — search in order, use first found:

   1. docs/development/coding-rules.md

   2. docs/coding-rules.md

   3. Fallback:

      find . -name "coding-rules.md" -not -path "*/node_modules/*" -not -path "*/.git/*" -not -path "*/vendor/*" -not -path "*/dist/*" -not -path "*/build/*" | head -1

   4. If not found → trigger fallback (see Phase 2)
   Project instruction files — read all that exist:

   • CLAUDE.md

     (project root)

   • src/CLAUDE.md

     (source-level rules)

   • test/CLAUDE.md

     (test-level rules)

   • AGENTS.md

     (agent definitions)
   Spec files:

   • .specs/{feature}/requirement.md

     → what to build

   • .specs/{feature}/design.md

     → how to build it

   • .specs/{feature}/tasks.md

     → task breakdown with checkboxes
5. Detect parallel-capable agent environment (runtime-aware):
   • Determine active runtime from the current execution environment (do NOT infer runtime solely from repository directories)
   • Use repository files only for runtime setup validation:
     • Codex validation:

       .codex/config.toml

     • Claude Code validation:

       .claude/agents/workflow-*.md

   • If runtime cannot be determined, ask user to choose runtime
   • Check whether workflow contains a parallel section (

     Parallel Execution Strategy

     /

     Agent Roles

     )
   • Parse optional workflow section for explicit agent file paths:

     • Agent definition files:

       /

       エージェント定義ファイル:

     • Extract paths for implementer / reviewer / tester from list items
     • Use extracted paths as first priority for validation and dispatch context
     • If section is absent, fallback to runtime defaults
   • Validate runtime-specific sub-agent setup:
     • Codex:

       .codex/config.toml

       has

       [features] multi_agent = true

       and

       agents.workflow-*

     • Claude Code: agent files from workflow section exist; if absent, use defaults (

       .claude/agents/workflow-implementer.md

       ,

       .claude/agents/workflow-reviewer.md

       ,

       .claude/agents/workflow-tester.md

       )
   • If any required condition is missing, continue in sequential mode

develop

main

{variable}

{base_branch}

1. Look for "branch strategy", "base branch", "PR target", "develop", "main" in the workflow
2. If the workflow specifies a branch (e.g.,

   develop

   ), use it as

   {base_branch}

3. Default fallback:

   main

AskUserQuestion:
  question: "Workflow file not found. Generate it?" / "ワークフローファイルが見つかりません。生成しますか？"
  options:
    - "Run spec-workflow-init" / "spec-workflow-initを実行"
    - "Continue without workflow" / "ワークフローなしで続行"

main

{base_branch}

1. Workflow includes a parallel section with role assignment
2. Runtime-specific sub-agent configuration is valid
3. User did not pass

   --no-parallel

   (or explicitly passed

   --parallel

   )

AskUserQuestion:
  question: "Which runtime should execute sub-agents?" / "どのランタイムでサブエージェント実行しますか？"
  options:
    - "Codex runtime" / "Codexで実行"
    - "Claude Code runtime" / "Claude Codeで実行"

• Run implementer and tester in parallel, then run reviewer after both complete.
• Use explicit runtime-specific dispatch instructions, not narrative role assignment only.

• Required config:

  .codex/config.toml

  with

  multi_agent = true

  and

  agents.workflow-*

• Agent definition file paths:
  • First priority: paths declared in workflow

    Agent definition files

    section
  • Fallback: runtime defaults (from

    .codex/agents/

    conventions)
• Dispatch format (example):

Task:
  subagent_type: workflow-implementer
  prompt: "Implement task T001 using design section 2.3. Edit implementation files only."

Task:
  subagent_type: workflow-tester
  prompt: "Create tests for task T001. Edit test files only."

• Required files:
  • First priority: paths declared in workflow

    Agent definition files

    section
  • Fallback defaults:

    .claude/agents/workflow-implementer.md

    ,

    .claude/agents/workflow-reviewer.md

    ,

    .claude/agents/workflow-tester.md

• Dispatch format: use Claude Code sub-agent call format with

  subagent_type

  set to workflow agent names (

  workflow-implementer

  ,

  workflow-tester

  ,

  workflow-reviewer

  ).
• Example (pseudocode):

SubAgent:
  subagent_type: workflow-implementer
  prompt: "Implement task T001 using design section 2.3. Edit implementation files only."

• Continue with the existing single-agent sequential loop.

• {Rule detail}

Apply rules by severity:

| Severity | On Violation | Action |
|----------|-------------|--------|
| `[MUST]` | Error | Stop → fix → recheck before continuing |
| `[SHOULD]` | Warning | Log warning → continue |
| `[MAY]` | Info | Log info only |

**Check timing:**
- **Before task**: Review rules relevant to the task's category
- **During code generation**: Self-check against `[MUST]` rules
- **After task**: Verify completion criteria + rule compliance
- **Final gate**: Check all `[MUST]` rules across all changes

**Fallback (no rules file):**
If no coding rules file is found:

If continuing without rules, use CLAUDE.md or AGENTS.md as fallback reference if available.

CLAUDE.md

src/CLAUDE.md

test/CLAUDE.md

AGENTS.md

[MUST]

• Extract conditional rules: IF-THEN patterns, conditional instructions, and environment-specific constraints (e.g., "when using Docker...", "if the project has...") are mandatory action triggers
• Extract environment constraints: Docker requirements, package manager restrictions, etc.
• Extract commit conventions: Commit message language, format, co-author requirements
• Extract test patterns: Required test helpers, test structure conventions
• Merge with coding-rules.md: These rules supplement (not replace) coding-rules.md

--issue {N}

gh issue view {N} --json title,body,labels,assignees

• Feature overview and requirements
• Spec directory path (if referenced)
• Phase/task checklists
• Assignees and labels

🚨 BLOCKING GATE — Feature branch is MANDATORY

Implementation MUST NOT proceed on

main

,

master

, or

develop

branches. This gate cannot be skipped. Violation = immediate stop.

git checkout {base_branch} && git pull origin {base_branch}
git checkout -b feature/issue-{N}-{brief-description}

{base_branch}

main

main

master

develop

--resume

current_branch=$(git branch --show-current)
if [ "$current_branch" = "main" ] || [ "$current_branch" = "master" ] || [ "$current_branch" = "develop" ]; then
  echo "🚨 ERROR: Cannot implement on protected branch: $current_branch"
  echo "Create a feature branch first."
  exit 1
fi

1. Parse explicit agent file paths (if present):
   • Read workflow section

     Agent definition files:

     /

     エージェント定義ファイル:

   • Build a map of role → definition file path (implementer/reviewer/tester)
   • If no section exists, use runtime defaults
2. Parse the Role Assignment Table — find the Markdown table with columns like

   Role | Agent | Responsibility

   :
   • Extract each row's

     Agent

     column value → use as runtime sub-agent identifier (

     subagent_type

     )
   • Extract each row's

     Responsibility

     column value → use as context in the task prompt
3. Parse the Parallel Execution Strategy Table (if present) — find the table with phase rows and role columns:
   • Each row = a phase (execute sequentially, top to bottom)
   • Cells with

     -

     = role is idle in that phase
   • Non-

     -

     cells = role's action (roles active in the same row run in parallel)
4. Present options to the user:

   AskUserQuestion:
     question: "Workflow defines agent roles. Use sub-agents for parallel execution?" /
               "ワークフローにエージェントロールが定義されています。サブエージェントで並列実行しますか？"
     options:
       - "Use sub-agents (parallel)" / "サブエージェント使用（並列）"
       - "Single agent (sequential)" / "シングルエージェント（順次）"

5. If sub-agents selected, branch by runtime:
   • Codex runtime: spawn agents via Codex Task dispatch using parsed

     Agent

     names as

     subagent_type

   • Claude Code runtime: spawn agents via Claude Code sub-agent dispatch using parsed

     Agent

     names as

     subagent_type

   • Execute phases per strategy table (same-row roles run in parallel)
6. If single agent selected: proceed with sequential execution below

requirement.md

design.md

tasks.md

tasks.md

1. Read task details (requirements ID, design reference, target files, completion criteria)
2. Reference the corresponding design.md section
3. Implement: create or modify target files
4. 🔍 Implementation Review:
   a. Self-review generated code against design.md specifications
   b. Verify coding-rules.md [MUST] rules for generated code
   c. Verify CLAUDE.md conditional rules for generated code
   d. If review finds issues → fix before proceeding
5. If task includes test implementation:
   a. Write tests following project test patterns (from CLAUDE.md / coding-rules.md)
   b. Run tests to verify they pass
   c. 🔍 Test Review:
      - Verify test coverage matches completion criteria
      - Verify test patterns match project conventions
      - If review finds issues → fix before proceeding
6. Update tasks.md: mark completion criteria (- [ ] → - [x])
7. When all criteria pass: mark top-level task checkbox (- [x])
8. Commit progress:
   git add .specs/{feature}/tasks.md [+ implementation files]
   git commit -m "{commit message following project conventions}"

feat: {task-id} complete — {brief description}

.specs/

1. Run test commands from the workflow (or language-appropriate default)
2. Run lint/typecheck commands from the workflow (if specified)
3. Verify all

   [MUST]

   rules from coding-rules.md pass
4. Verify all CLAUDE.md conditional rules pass
5. If any check fails → fix → recheck
6. All checks pass → proceed to PR creation

{base_branch}

gh pr create \
  --title "{type}: {description} (closes #{N})" \
  --body "{PR body following workflow template}" \
  --base {base_branch}

{base_branch}

main

--base {base_branch}

• Do NOT create PR if tests are failing
• Do NOT force push
• Do NOT push directly to main/master
• Do NOT target wrong base branch (verify against workflow)
• Ask for user confirmation before large-scale code deletions