mcpField
C
coding-agent-pm

coding-agent-pm

github.com/davepoonエージェントワークフロー3.7k37 回インストール今日更新
リポジトリ

coding-agent-pm について

Claude Code、Codex、OpenClaw などのコーディングエージェントに実装を委任する人向けのスキルです。依頼を範囲の明確なタスクにし、検証、差分レビュー、問題からの復旧を体系化します。

主な機能

  1. 01依頼を範囲限定タスクに整理
  2. 02担当ファイルと除外範囲の指定
  3. 03確認可能な受け入れ基準の作成
  4. 04納品前検証の必須化
  5. 05範囲逸脱やリスクの差分確認

活用シーン

  1. 01コーディングエージェントへの依頼準備
  2. 02実装差分のレビュー
  3. 03停滞や過剰編集からの立て直し

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/davepoon/buildwithclaude --skill coding-agent-pm

インストール後、Claude Code で/coding-agent-pmを入力して読み込まれたか確認します。

詳細

コーディングエージェント PM

Claude Code、Codex、OpenClaw、またはその他のコーディングエージェントが行う実装作業を、人間が準備、委任、レビュー、または立て直す際にこのスキルを使用します。

このスキルを使う場面

  • 曖昧な実装依頼を、範囲の明確なエージェントタスクに落とし込む必要がある場合。
  • 1つ以上のコーディングエージェントに作業を割り当て、ファイルの担当範囲を明確にする必要がある場合。
  • エージェントの差分をレビューし、スコープの逸脱、リグレッション、検証漏れを確認する場合。
  • コーディングエージェントが停止した、編集しすぎた、または信頼しにくい結果を返した場合。

このスキルでできること

  1. 提供する成果を1文で定義します。
  2. 範囲を明確にします。担当するファイルやモジュール、対象外のファイルやモジュール、および禁止される破壊的な操作を指定します。
  3. 実装開始前に、関連するプロジェクトのコンテキストを把握します。
  4. 直接確認できる受け入れ基準を作成します。
  5. 最終納品前に、検証コマンドまたは手動確認を必須にします。
  6. 作業を受け入れる前に差分をレビューします。

割り当てルール

  • タスクは具体的で範囲を限定し、簡潔にします。
  • エージェントがファイルを編集してよいのか、調査と計画のみを行うのかを明記します。
  • コード変更の担当範囲を指定します。
  • 無関係なユーザーの作業を元に戻さないようエージェントに伝えます。
  • 新しい抽象化を導入するより、既存のプロジェクトのパターンを優先します。
  • 最終回答に、変更したファイル、実施したチェック、その結果、残るリスクを含めるよう求めます。

エージェント向けブリーフのテンプレート

# Agent Brief

## Outcome
Ship:

## Scope
Owned files/modules:

Do not edit:

Forbidden actions:
- Do not run destructive git commands.
- Do not revert unrelated user changes.

## Context
Relevant files:

Existing patterns to follow:

## Acceptance Criteria
- [ ] 
- [ ] 
- [ ] 

## Validation
Run:

Manual checks:

## Final Response Must Include
- Files changed
- Validation run and result
- Remaining risks or follow-ups

レビューチェックリスト

次の順にレビューします。

  1. 動作上のバグまたはリグレッション。
  2. 受け入れ基準の不足。
  3. テスト不足または弱い検証。
  4. スコープの逸脱や無関係なリファクタリング。
  5. セキュリティ、プライバシー、または破壊的なコマンドのリスク。

エージェントがスコープから逸脱した場合は、新たな編集を止め、各変更が元の受け入れ基準のどれに対応するのか説明するよう求めます。

立て直し用プロンプト

コーディングエージェントの作業が信頼しにくい場合に使用します。

Pause implementation. Map every changed file and every material change back to the original acceptance criteria. For each change, mark it as required, optional, or unrelated. Do not edit files until this map is complete.

例

ユーザー:「コーディングエージェントに OAuth ログインを追加させてください。」

より良い割り当て:

Outcome: Add GitHub OAuth login to the existing auth flow.

Scope:
- Own: src/auth/*, src/routes/login.tsx, tests/auth/*
- Do not edit: billing, onboarding, database migrations unless a failing test proves it is required

Acceptance criteria:
- [ ] Existing email login still works.
- [ ] GitHub login creates or links a user through the existing auth service.
- [ ] Auth errors render through the existing form error pattern.
- [ ] Tests cover success, denied OAuth, and existing linked account.

Validation:
- npm test -- auth
- npm run lint

ヒント

  • 担当するファイルが少ないほど、エージェントの成果は良くなります。
  • 共有モジュールやリスクの高いモジュールについては、「編集禁止」の一覧を明示します。
  • 長い実装手順より、受け入れ基準を優先します。
  • 検証は後続作業ではなく、タスクの一部として扱います。

コメント