mcpField
U
user-story-implementer

user-story-implementer

github.com/eho開発170 回インストール10 週間前に更新
リポジトリ

user-story-implementer について

user-story-implementerは、1件のGitHub Issueを実装するコーディングエージェント向けスキルです。担当範囲の確認から実装、検証、引き継ぎまでを扱い、各受け入れ条件の具体的な証拠を求め、重複作業や権限のないレビュー・マージを防ぎます。

主な機能

  1. 01Issue、依存関係、既存作業の確認
  2. 02受け入れ条件を満たす変更の実装
  3. 03条件ごとの証拠の記録
  4. 04検証の実行と差分の自己レビュー
  5. 05所定の形式でのPR準備と引き継ぎ

活用シーン

  1. 01単一のGitHub Issueの実装
  2. 02既存ブランチやPRでの作業再開
  3. 03実装を検証してレビュー用に準備

インストール

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

$npx skills add https://github.com/eho/agent-skills --skill user-story-implementer

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

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

scripts/
create_pr.sh
prepare_story_branch.sh
tests/
create_pr_test.sh
prepare_story_branch_test.sh

詳細

ユーザーストーリー実装者

1 件の GitHub Issue の実装を担当します。別のリポジトリポリシーとユーザー指示で明示的に許可されている場合を除き、独立したレビュアーとして振る舞ったり、自分の変更をマージしたりしないでください。

作業内容を確認する

  1. リポジトリの指示、Issue 全文、受け入れ条件、依存関係、コメント、リンクされた設計コンテキストを確認します。
  2. 依存関係が単にクローズされているだけでなく、提供済みであることを確認します。
  3. 担当者、ブロック状態、進行中のリンクされた作業を確認します。明示的な権限がない限り、他の担当者の Issue を引き継がないでください。
  4. リンクされた PR、ローカルとリモートのブランチ、ワークツリーの所有状況を調べ、この Issue に関する既存の作業を探します。既存のブランチまたは PR が明確な場合はそれを再開し、重複を作成しないでください。
  5. ワークツリーを調べ、無関係な変更を保持します。ブランチの切り替えによって進行中の作業に影響が及ぶ場合は、分離されたワークツリーを使用します。
  6. 複数の Issue、ブランチ、または PR が同じ成果物を指している可能性がある場合は、作業を止めて曖昧さを報告します。

実装する

  1. 関連するコード、テスト、契約、ドキュメントを調べます。
  2. Issue のすべての要件を満たす、まとまりのある最小限の変更を実装します。
  3. 受け入れ条件ごとに、コードパス、重点的なテスト、手動での確認、ドキュメントの変更など、直接的な根拠を記録します。
  4. 有効な正常系と、関連する失敗ケースまたは境界ケースを網羅するテストを追加します。
  5. 変更によるリスクに絞った検証と、リポジトリポリシーで要求されるより広範な検証を実行します。
  6. ツールを利用できる場合は、適切なランタイムでユーザーに見える動作を確認します。自動テストだけでは、視覚的または対話的な受け入れ条件を満たした証明にはなりません。
  7. 回帰、セキュリティ、権限、データの安全性、マイグレーション、互換性、並行処理、診断、ドキュメントについて、差分を自己レビューします。

プロダクト上の判断、認証情報、外部サービス、または未完了の依存関係によって正しい実装が妨げられる場合は、その具体的なブロッカーを Issue に記録して停止します。

受け入れゲート

新しい PR を作成する前、または PR をレビューに回す前に、Issue を再確認し、すべての受け入れ条件を簡潔な表で説明します。

条件実装の根拠検証

根拠には、具体的なコード、テスト、確認内容、またはドキュメントの変更を記載します。必須の行が不足している、差分と矛盾している、または未検証の場合は、実装を続けるかブロッカーを報告してください。レビュー可能な PR として提示してはいけません。完成した表は ### Acceptance Criteria Evidence に記載します。 修正作業では、レビュー指摘の全項目に対応し、新たなレビューを依頼する前にこのゲートを再実行します。

ブランチとプルリクエスト

新規作業では、story/<story-id-lowercase> や issue/<issue-number> のような、目的を絞ったブランチを選びます。scripts/prepare_story_branch.sh を確認して実行し、デフォルトブランチの取得、依存関係のマージ確認、ブランチまたは分離されたワークツリーの安全な準備を行います。既存のブランチを使う場合は --resume を使用します。

  • 意図したファイルのみをステージします。

  • リポジトリのコミット規約に従います。

  • PR を作成する前にブランチをプッシュします。

  • PR の本文には ### Summary、### Acceptance Criteria Evidence、### Verification、### Not Verified を記載します。

  • scripts/create_pr.sh を確認して実行します。

    bash /absolute/path/to/scripts/create_pr.sh \
  "<issue-number>" "<pr-title>" "<body-file>" \
  "<story-id-or-none>" "<design-path-or-none>"

修正作業では、同じオープン中の PR にプッシュします。以前の成果物がすでにマージされ、Issue が正当に再オープンされた場合は、同じ正規の Issue にリンクしてクローズする、新しい目的を絞った PR を作成します。マージ済みの履歴を書き換えてはいけません。

引き継ぎ

- Issue:
- PR:
- Head SHA:
- Result: Created | Resumed | Revised | Blocked
- Acceptance-criteria evidence:
- Verification:
- Blocking findings addressed:
- Blocker:

独立した承認、マージ、Issue のクローズ、または機能の準備完了を主張しないでください。

コメント

Markdown 対応