agentleFS
morodomimorodomi/dev-crew/skills/orchestrate/SKILL.md

orchestrate

Skill1 starsChanged 26 days agoMITView on GitHub

TDDサイクル全体をPdM(Product Manager)として自律管理。plan mode起点でワークフロー制御。sync-plan→RED→GREEN→REFACTOR→REVIEW→COMMITを専門エージェントに委譲・判断する。Manual trigger: 「orchestrate」「全体管理」「PdMモード」。Do NOT use for 個別フェーズのみの実行(→ 各フェーズスキル)。

161 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use define-requirements, orchestrate-plan and 9 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • sson0-erSkill

    define-requirements

    Work with the user, one question at a time, to complete the requirements document (docs/claudex/<slug>/01-requirements.md). Run by the orchestrator (parent). Stays out of design and implementation.

    Also in 3 projects that use this

  • EternallLightSkill

    orchestrate-plan

    Use when executing a locked, reviewed PLAN.md by delegating the implementation to visible worker agents in Orca, herdr, or cmux ONE PHASE at a time — splitting the plan into context-window-sized phases, giving every phase a pristine worker context, and (when the plan touches INDEPENDENT repos) running one worker per repo IN PARALLEL. Triggers on "run the plan with a worker", "execute the plan in the other pane", "split the plan into phases and build it with workers", "build the backend and frontend in parallel panes". Not for edits you can finish inline; outside Orca, herdr, or cmux use tgc-skills:orchestrate.

    Also in 3 projects that use this

  • sson0-erSkill

    record-evidence

    How to record external facts (docs, command output, codebase findings) as evidence and design choices as decisions. Used by the researcher, designer and reviewer agents.

    Also in 3 projects that use this

  • PinkneyJiangSkill

    improve-architecture

    扫描代码库中的架构摩擦点,识别浅模块并挖掘深模块演进机会。生成可视化交互式 HTML 诊断报告,并在用户确认后闭环实施深度重构。

    Also in 4 projects that use this

  • kjnezSkill

    ticket

    Work on a JIRA/Linear ticket end-to-end: read ticket details, explore codebase, create a branch, implement with TDD, run quality checks, update ticket status, and create a PR. Use when the user provides a ticket ID to implement. Triggers on requests like "/ticket PROJ-123", "work on this ticket", "implement PROJ-123".

    Also in 4 projects that use this

  • xfstudioSkill

    reverse-engineer

    Expert reverse engineer specializing in binary analysis,

    Also in 3 projects that use this

The file

Files
SKILL.md

Current State

!ls -t docs/cycles/*.md 2>/dev/null | head -5 || echo "(none)" !git log --oneline -5 2>/dev/null || echo "(no commits)"

TDD Orchestrate (PdM Mode)

TDDサイクル全体をPdM (Product Manager) として管理。plan mode起点でワークフロー制御。

Progress Checklist

orchestrate Progress:
- [ ] Block 0: planファイル / Cycle doc 確認 → 開始地点決定
- [ ] Block 1: sync-plan (with Design Review) → 自律判断
- [ ] Block 2a: RED — Task(red-worker) でテスト作成、失敗確認
- [ ] Block 2b: GREEN — Task(green-worker) で実装、全テストPASS確認
- [ ] Block 2c: REFACTOR — Skill(refactor) で品質改善
- [ ] Block 2c.5: VERIFY — Product Verification (advisory, skip if absent)
- [ ] Block 2d: REVIEW — 敵対的レビュー 1 回 + 指摘の振り分け(review skill は起動しない)
- [ ] Block 2e: DISCOVERED — スコープ外項目をissue起票
- [ ] Block 2f: RETROSPECTIVE — Skill(dev-crew:cycle-retrospective) で失敗-成功 insight 抽出
- [ ] Block 3: COMMIT → 完了

PdM の原則

  • 自分で実装・テスト・レビューしない → 専門 Teammate/Subagent に委譲
  • PASS/WARN → 自動進行、BLOCK → 再試行 → ユーザーに報告
  • 曖昧なまま進まない → AskUserQuestion で確認

Workflow

Block 0: Prerequisite Check

0. Codify notice — frontmatter-only scan(件数を出すだけ。codify-insight は起動しない):

n=0; for f in docs/cycles/*.md; do awk '/^---$/{c++;next} c==1{print}' "$f" 2>/dev/null | grep -E '^retro_status:[[:space:]]*captured[[:space:]]*$' >/dev/null && n=$((n+1)); done; echo "$n"

N が 1 以上なら「未処理の振り返りを持つ Cycle doc が N 件あります(retro_status: captured)。処理するときは /dev-crew:codify-insight を別に実行し、タスクとは別の commit にしてください。」と 1 行通知する。0 なら通知しない。件数にかかわらず次へ進む。

最初に実行: TaskCreate でタスクを登録。詳細: reference.md

planファイルを起点に開始地点を決定する:

  1. planファイルあり? → YES: 未完了 cycle doc あり? plan-review 記録+architect Post-Transfer Verification 記録あり → Block 2a / sync-plan 済みだが architect 未実施 → Block 1(architect のみ再開、resume gap 対策)/ いずれも未実施 → Progress Log 再開 / cycle doc なし → Block 1 → NO: 新規開始 (plan mode): Skill(dev-crew:spec) → 設計・Test List → Skill(dev-crew:review, args: "--plan") → Step 8(承認前 Codex plan review、plan mode 内で完了済み) → approve → Block 1

Block 1: Sync-Plan (with Design Review)

Codex plan review は承認前(spec Step 8)に完了済みの前提で進行する。順序: sync-plan(転記)→ architect(転記後検証)。

  1. sync-plan: plan の Plan Review Record を Cycle doc へ転記し、Cycle doc を生成
  2. architect: 転記後検証(Post-Transfer Verification)を実施。転記欠落=BLOCK / scope 実質変更=AskUserQuestion で再承認 / 観察のみ=DISCOVERED
  3. Codex不在時: Socrates adversarial review — which codex 失敗時、Socrates を計画への adversarial reviewer として起動。詳細: reference.md
  4. codex_mode / 委譲モード: RED/GREEN の委譲先はユーザー選択を優先。詳細: reference.md
  5. 自律判断: PASS/WARN → Block 2a へ、BLOCK → sync-plan再実行

Block 2: Implementation

MUST: 次のフェーズに進む前に、現フェーズの完了条件を確認せよ。詳細手順はモードに応じて参照: steps-subagent.md / steps-teams.md / steps-codex.md

Block 2a: RED

Task(red-worker, sonnet): Cycle doc + TC → テスト作成・失敗確認

Block 2b: GREEN

Task(green-worker, sonnet): Cycle doc → テストを通す最小実装・全PASS確認

Block 2c: REFACTOR

Skill(dev-crew:refactor): Verification Gate通過(テスト全PASS + 静的解析0件 + フォーマット)

Block 2c.5: VERIFY (Product Verification)

## Verification セクションのコマンドを実行。advisory evidence(非ブロッキング)。real-path invocation なしの場合 WARN ログ (rules/integration-verification.md)。セクション不在 → WARN スキップ。詳細: reference.md

Block 2d: REVIEW

敵対的レビューを 1 回(Codex は新しいセッション、無い・失敗時は dev-crew:adversarial-reviewer)→ 修正役が「直す / 人間に戻す / 記録のみ」に振り分けて直す → 件数を Cycle doc に記録。再レビューしない。 判定: 完了 → Block 2e へ。取得失敗・作業ツリーの変化・代行の失敗・修正の未達 → BLOCK。詳細: adversarial-review.md / steps-*.md の REVIEW 節

Block 2e: DISCOVERED

スコープ外項目をCycle docに記録し、GitHub issueに起票(起票→ issue #N 参照、reject→ 理由記載)。

Block 2f: RETROSPECTIVE

Skill(dev-crew:cycle-retrospective): 失敗-成功 insight 抽出、retro_status: captured/resolved 遷移。abort (exit 1) → COMMIT 停止「/orchestrate を再起動してください」。詳細: reference.md

Block 3: Finalization

  1. COMMIT: pre-commit-gate(cycle doc 明示指定)PASS → Skill(dev-crew:commit) へ委譲(commit skill Step 3 が Cycle doc を phase: DONE へ遷移させてから git add & commit)
  2. 完了報告: サイクル完了をユーザーに報告

Mode Selection

codex_mode は RED/GREEN の委譲先のみ制御 する。Plan Review は Codex 利用可能なら常時 competitive 実行、REVIEW は Codex 利用可能なら新しいセッションで敵対的レビューを実行 (いずれも codex_mode 値に依存しない)。

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.