agentleFS
anyoneandersonanyoneanderson/agent-skills/skills/spec-workflow-init/SKILL.md

spec-workflow-init

Skill3 starsChanged 8 days agoMITView on GitHub

Development workflow generator — Generate issue-to-pr-workflow.md for your project.

The file

Show its rules and text

We split this skill into the rules it gives an agent

22 rules. About 0 are common, 12 are distinctive, and 10 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈12

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 10

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    If not a Git repo, warn and skip branch detection.

    line 38
  2. Very specific:

    If found and --force is not set, show the existing file path and proceed to Step 7 (idempotency handling).

    line 50
  3. Distinctive:

    Run the following checks to auto-detect the project environment:

    line 54
  4. Distinctive:

    Ask the user to confirm or correct the detection results before proceeding.

    line 126
  5. Very specific:

    If cmux detected (CMUX_SOCKET_PATH is set):

    line 199
  6. Distinctive:

    If cmux NOT detected:

    line 209
  7. Very specific:

    Ask which agent definitions to generate.

    line 220
  8. Very specific:

    Use the selection to fill {implementer_ai}, {tester_ai}, {reviewer_ai} in the role table.

    line 243
  9. Very specific:

    If agent targets include Claude → keep {if_claude_agents}...{end_claude_agents}, otherwise remove

    line 282
  10. Very specific:

    If agent targets include Codex → keep {if_codex_agents}...{end_codex_agents}, otherwise remove

    line 283
  11. Very specific:

    If agent generation is skipped → keep {if_no_agent_files}...{end_no_agent_files}, otherwise remove

    line 284
  12. Very specific:

    No typecheck command → remove {if_typecheck}...{end_typecheck}

    line 285
  13. Very specific:

    No build command → remove {if_build}...{end_build}

    line 286
  14. Very specific:

    If AI column not applicable (no cmux dispatch), remove AI column from role table

    line 293
  15. Distinctive:

    Create output directory: if needed:

    line 297
  16. Distinctive:

    If an existing workflow file is detected (from Step 1 or during generation):

    line 306
  17. Distinctive:

    Check for convention files:

    line 329
  18. Distinctive:

    If CLAUDE.md is a symlink to AGENTS.md, update only AGENTS.md:

    line 334
  19. Distinctive:

    If at least one file exists, ask for confirmation:

    line 339
  20. Distinctive:

    If approved, append the following section (adapt language to match output):

    line 348
  21. Distinctive:

    If neither file exists, output a warning:

    line 366
  22. Distinctive:

    After generating the workflow:

    line 406

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

spec-workflow-init — Development Workflow Generator

Generate a project-specific issue-to-pr-workflow.md through interactive dialogue. The workflow serves as a playbook for spec-implement and development agents.

Language Rules

  1. Auto-detect input language → output in the same language
  2. Japanese input → Japanese output, use references/workflow-template.ja.md
  3. English input → English output, use references/workflow-template.md
  4. Explicit override takes priority (e.g., "in English", "日本語で")

Sub-agent template selection (when generating agent definitions):

  • English → references/agents/claude/workflow-*.md
  • Japanese → references/agents/claude/workflow-*.ja.md
  • Codex templates: English → references/agents/codex/workflow-*.toml, Japanese → references/agents/codex/workflow-*.ja.toml

Execution Flow

Step 1: Initial Checks

  1. Verify Git repository:
    git rev-parse --is-inside-work-tree 2>/dev/null
    If not a Git repo, warn and skip branch detection. Continue with other checks.
  2. Check current directory:
    pwd
    ls -la
  3. Detect existing workflow file:
    find . -name "issue-to-pr-workflow.md" -maxdepth 3 2>/dev/null
    If found and --force is not set, show the existing file path and proceed to Step 7 (idempotency handling).

Step 2: Environment Detection

Run the following checks to auto-detect the project environment:

Package manager:

ls pnpm-lock.yaml yarn.lock package-lock.json bun.lockb 2>/dev/null

Container usage:

ls docker-compose.yml docker-compose.yaml Dockerfile 2>/dev/null

CI/CD service:

ls -d .github/workflows .gitlab-ci.yml .circleci 2>/dev/null

Branch information:

git branch -r 2>/dev/null | head -10

Language, framework, and scripts:

cat package.json 2>/dev/null | grep -A 50 '"scripts"'
cat package.json 2>/dev/null | grep -A 30 '"dependencies"'
ls go.mod requirements.txt pyproject.toml 2>/dev/null

Database:

ls prisma/schema.prisma 2>/dev/null
grep -l "postgres\|mysql\|mongo" docker-compose.yml 2>/dev/null

Lint tools:

ls .eslintrc* biome.json 2>/dev/null

Coding rules file:

find . -name "coding-rules.md" -maxdepth 3 2>/dev/null

Review rules file:

find . -name "review_rules.md" -maxdepth 3 2>/dev/null

cmux environment:

echo $CMUX_SOCKET_PATH

Present the detection results to the user in a summary table:

Detected project environment:
  Language/FW:       {detected}
  Package Manager:   {detected}
  Container:         {detected}
  Test:              {detected}
  CI/CD:             {detected}
  Branch:            {detected}
  Database:          {detected}
  Lint:              {detected}
  Coding Rules:      {detected or "Not found"}
  Review Rules:      {detected or "Not found"}
  cmux:              {detected or "Not available"}

Ask the user to confirm or correct the detection results before proceeding.

Step 3: Interactive Dialogue

Gather workflow configuration through AskUserQuestion rounds.

Round 1: Output Path

question: "Where to save issue-to-pr-workflow.md?" / "issue-to-pr-workflow.md の出力先は?"
header: "Output"
options:
  - "docs/issue-to-pr-workflow.md (Recommended)" / "docs ディレクトリ直下(推奨)"
  - "docs/development/issue-to-pr-workflow.md" / "docs/development 配下"

Round 2: Branch Strategy

Q1:
question: "Base branch (PR target)?" / "ベースブランチ(PRターゲット)は?"
header: "Branch"
options:
  - "develop (Recommended)" / "feature → develop → main(Git Flow)"
  - "main" / "feature → main(GitHub Flow)"
  - "trunk" / "Short-lived branches → main(Trunk-based)"

Q2:
question: "Feature branch naming convention?" / "featureブランチの命名規則は?"
header: "Naming"
options:
  - "feature/{issue}-{slug} (Recommended)" / "e.g. feature/42-add-auth"
  - "{issue}-{slug}" / "e.g. 42-add-auth"
  - "{type}/{issue}-{slug}" / "e.g. fix/42-login-bug, feat/43-dashboard"

Round 3: Quality Gates

question: "Quality gates before PR creation?" / "PR作成前の品質ゲートは?"
header: "Gates"
multiSelect: true
options:
  - "All tests must pass (Recommended)" / "テスト全パス(推奨)"
  - "Lint and type check must pass" / "Lint / Typecheckパス"
  - "Coverage threshold" / "カバレッジ基準"

Round 4: Development Style

question: "Select your development style" / "開発スタイルを選択してください"
header: "Style"
options:
  - "Implementation First (Recommended)" / "実装 → レビュー → テスト → テストレビュー → 品質ゲート → PR"
  - "TDD" / "テスト(RED) → 実装(GREEN) → リファクタ → レビュー → 品質ゲート → PR"
  - "BDD" / "E2Eシナリオ → テスト(RED) → 実装(GREEN) → レビュー → 品質ゲート → PR"

Round 5: E2E Test Level

question: "E2E test scope?" / "E2Eテストの範囲は?"
header: "E2E"
options:
  - "API level only (Recommended)" / "supertest等でリクエスト→レスポンスを検証"
  - "API + Browser E2E" / "上記 + Playwrightでクリティカルパスを検証"

Round 6: Execution Strategy

Show options based on cmux detection from Step 2.

If cmux detected (CMUX_SOCKET_PATH is set):

question: "Select your execution strategy" / "実行戦略を選択してください"
header: "Strategy"
options:
  - "Single agent" / "単独実行 — メインエージェントが全工程を順番に実行(シンプル・安全)"
  - "Multi-agent (Recommended)" / "マルチエージェント(推奨) — Codex custom agents または Claude Code agent team で役割分担"
  - "Multi-agent (cmux)" / "マルチエージェント(cmux) — cmux で別ペインに各ロールを起動(進捗がリアルタイムで見える)"

If cmux NOT detected:

question: "Select your execution strategy" / "実行戦略を選択してください"
header: "Strategy"
options:
  - "Single agent" / "単独実行 — メインエージェントが全工程を順番に実行(シンプル・安全)"
  - "Multi-agent (Recommended)" / "マルチエージェント(推奨) — Codex custom agents または Claude Code agent team で役割分担"

Round 7: Agent Targets (only if Multi-agent or Multi-agent (cmux) selected)

Ask which agent definitions to generate. Do NOT decide targets based on .claude/ / .codex/ directory detection.

question: "Which agent definitions should be generated?" / "どのエージェント定義を生成しますか?"
header: "Agents"
options:
  - "Both Claude + Codex (Recommended)" / "Claude と Codex の両方を生成"
  - "Claude only" / "Claude のみ生成"
  - "Codex only" / "Codex のみ生成"
  - "Skip generation" / "生成しない"

Round 8: Agent AI Assignment (only if Multi-agent (cmux) selected in Round 6)

question: "Which AI to assign to each role?" / "各ロールにどのAIを割り当てますか?"
header: "AI Assignment"
options:
  - "Implement=Codex, Test=Codex, Review=Claude (Recommended)"
  - "All Claude Code" / "全て Claude Code"
  - "All Codex" / "全て Codex"

Use the selection to fill {implementer_ai}, {tester_ai}, {reviewer_ai} in the role table.

Round 8.5: Second Opinion (only if Multi-agent (cmux) selected in Round 6)

question: "Run second opinion at review gates?" / "レビューゲートでセカンドオピニオンを実施しますか?"
header: "Opinion"
options:
  - "Always (Recommended)" / "毎回実施(推奨)"
  - "On user request only" / "ユーザーが要求した場合のみ"
  - "Never" / "実施しない"

Additional Questions (project-type specific):

  • Docker project: "Run all commands inside Docker?" / "Docker内で全コマンドを実行しますか?"
  • Next.js project: "Include build check in workflow?" / "ビルド確認をワークフローに含めますか?"

Step 4: Workflow Generation

  1. Select template based on Language Rules:
    • English → references/workflow-template.md
    • Japanese → references/workflow-template.ja.md
  2. Read the template and replace placeholders with collected values:
    • {package_manager}, {container_tool}, {database}, {test_framework}, etc.
    • {pr_target}, {branch_naming}, {dev_style}
    • {test_command}, {lint_command}, {typecheck_command}, {build_command}
    • {e2e_test_command}, {browser_e2e_command}, {coverage_command}
    • {timestamp} → current date/time
  3. Select development style sections:
    • Implementation First → keep {if_implementation_first}...{end_implementation_first}, remove TDD/BDD blocks
    • TDD → keep {if_tdd}...{end_tdd}, remove others
    • BDD → keep {if_bdd}...{end_bdd}, remove others
  4. Handle conditional sections:
    • Browser E2E not selected → remove {if_browser_e2e}...{end_browser_e2e} blocks
    • Multi-agent not selected (Single agent chosen) → remove {if_multi_agent}...{end_multi_agent} blocks
    • If agent targets include Claude → keep {if_claude_agents}...{end_claude_agents}, otherwise remove
    • If agent targets include Codex → keep {if_codex_agents}...{end_codex_agents}, otherwise remove
    • If agent generation is skipped → keep {if_no_agent_files}...{end_no_agent_files}, otherwise remove
    • No typecheck command → remove {if_typecheck}...{end_typecheck}
    • No build command → remove {if_build}...{end_build}
    • review_rules.md detected → keep {if_review_rules}...{end_review_rules}, remove {if_no_review_rules}...{end_no_review_rules}
    • review_rules.md not detected → keep {if_no_review_rules}...{end_no_review_rules}, remove {if_review_rules}...{end_review_rules}
    • Multi-agent (cmux) selected → keep {if_cmux_dispatch}...{end_cmux_dispatch} and {if_second_opinion}...{end_second_opinion}
    • Multi-agent (cmux) not selected → remove both cmux/second-opinion blocks
    • Replace {review_rules_path} with detected path (or placeholder)
    • Replace {implementer_ai}, {tester_ai}, {reviewer_ai} with selected AI values (from Round 8). Default: claude
    • If AI column not applicable (no cmux dispatch), remove AI column from role table
  5. Clean up remaining placeholders and conditional markers
  6. Create output directory if needed:
    mkdir -p {output_directory}
  7. Write the file to the specified output path

Step 5: Idempotency Handling

If an existing workflow file is detected (from Step 1 or during generation):

  1. Without --force: Show a warning with the existing file path
    question: "Existing workflow found at {path}. Overwrite?" / "既存のワークフローが {path} に見つかりました。上書きしますか?"
    header: "Overwrite"
    options:
      - "Yes, overwrite" / "はい、上書きする"
      - "No, cancel" / "いいえ、キャンセル"
  2. With --force: Overwrite without confirmation

Step 6: Sub-Agent Generation

Read references/agent-and-pipeline-setup.md completely (.ja.md for Japanese), then execute its Steps 6a through 6d in order. Skip agent generation only when Round 6 selected Single agent or Round 7 selected Skip generation; pipeline config and watchdog handling still follow the reference's independent conditions.

Step 7: AGENTS.md / CLAUDE.md Reference Update

  1. Check for convention files:
    ls AGENTS.md CLAUDE.md 2>/dev/null
  2. If CLAUDE.md is a symlink to AGENTS.md, update only AGENTS.md:
    readlink CLAUDE.md 2>/dev/null
  3. If at least one file exists, ask for confirmation:
    question: "Add workflow reference to AGENTS.md / CLAUDE.md?" / "AGENTS.md / CLAUDE.md にワークフローの参照を追記しますか?"
    header: "Update"
    options:
      - "Yes, add reference (Recommended)" / "はい、参照を追記する(推奨)"
      - "No, skip" / "いいえ、スキップ"
  4. If approved, append the following section (adapt language to match output):

    English:

    ## Development Workflow
    
    Follow the development workflow for Issue → Implementation → PR:
    - [{workflow_path}]({workflow_path}) — Development workflow generated by spec-workflow-init

    Japanese:

    ## Development Workflow
    
    開発フロー(Issue → 実装 → PR)は以下のファイルに従ってください:
    - [{workflow_path}]({workflow_path}) — spec-workflow-init で生成された開発ワークフロー
  5. If neither file exists, output a warning:
    "Warning: Neither AGENTS.md nor CLAUDE.md found. Skipping reference update."
    / "警告: AGENTS.md も CLAUDE.md も見つかりません。参照追記をスキップします。"

Options

OptionDescription
--forceOverwrite existing files without confirmation

Error Handling

ErrorDetectionResponse
Not a Git repositorygit rev-parse failsWarn and skip branch detection. Continue with other checks
No package.jsonls package.json failsSkip package manager / test / lint detection. Gather via dialogue
Write permission errormkdir -p or file write failsShow error and re-ask output path via AskUserQuestion
Network error (git branch -r)Command timeout or non-zero exitSkip remote branches. Use local branches only. Gather via dialogue
Existing file conflictFile found at output pathWithout --force: show warning and ask to overwrite. With --force: overwrite

Usage Examples

# Generate workflow with dialogue
"Generate development workflow"
「開発ワークフローを生成」

# Generate with force overwrite
"Create workflow --force"
「ワークフロー生成 --force」

# After spec-rules-init
"Now create the development workflow"
「次に開発フローを作って」

Post-Completion Actions

After generating the workflow:

question: "Workflow generated. What's next?" / "ワークフローを生成しました。次のアクションは?"
options:
  - "Run spec-implement" / "spec-implement を実行する"
    description: "Start implementing with the generated workflow" / "生成したワークフローで実装を開始"
  - "Review and customize" / "レビューしてカスタマイズ"
    description: "Open the generated file and make adjustments" / "生成されたファイルを開いて調整"
  - "Done for now" / "完了"
    description: "Finish without further action" / "追加アクションなしで完了"

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.