mcpField
D
design-to-issues

design-to-issues

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

design-to-issues について

設計ドキュメントのユーザーストーリーを GitHub Issues と同期するスキルです。ストーリー契約を検証し、管理対象の Issue を作成・更新して、内容と状態を設計に照合します。

主な機能

  1. 01設計とストーリー契約の検証
  2. 02ストーリーと正規 Issue の対応付け
  3. 03GitHub Issues の作成と更新
  4. 04契約変更時の Issue 再オープン
  5. 05Issue の内容と状態の確認

活用シーン

  1. 01改訂済み設計のストーリーを Issue 化
  2. 02要件変更後の Issue 更新
  3. 03Issue の依存関係とマイルストーンの確認
  4. 04削除されたストーリーの判断対象を特定

インストール

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

$npx skills add https://github.com/eho/agent-skills --skill design-to-issues

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

同梱ファイル

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

scripts/
create_issue.sh
create_milestone.sh
render_issue_body.py
story_contract.py
tests/
create_milestone_test.sh
render_issue_body_test.py
story_contract_test.py

詳細

デザインを Issue に同期

現在のユーザーストーリーを GitHub に同期します。デザイン文書では目指すスコープを定義し、GitHub Issues では進捗を追跡します。

前提条件

  • リポジトリの指示とデザイン文書全体を読みます。
  • 正確なデザインパスを必須とします。
  • 通常の同期には Status: Revised が必要です。これは、直近の独立レビューでブロッカーがなく、機械的な検証に合格していることを意味します。ユーザーは意味上のレビューリスクについて明示的に例外を認めることができますが、デリバリーモードの機械的な検証には引き続き合格する必要があります。
  • 認証済みの GitHub CLI とリポジトリのポリシーを使用します。

正規の識別情報

リポジトリ相対のデザインパスとストーリー ID の組み合わせで、管理対象の Issue を識別します。

scripts/story_contract.py を解決し、デリバリーモードで実行して、ステータス、ストーリー構造、安定 ID、依存関係を検証します。正規化されたストーリーソースを、管理対象 Issue の契約として使用します。スクリプトのハッシュはコンテンツの比較に役立つ場合がありますが、GitHub の進捗管理に別の追跡システムは必要ありません。

各ストーリーは正規のものであり、その実装に影響するアーキテクチャ、データ、セキュリティ、移行、互換性、ロールアウトに関する共有要件をすべて含める必要があります。そのような要件が変更された場合は、影響を受けるすべてのストーリーを更新してください。変更されたストーリー本文によって、完了済みの作業が再開されます。

正確なマーカーペアを使って、オープンとクローズの両方の Issue を検索します。完全一致するストーリー ID のタイトルは、レガシー候補の発見にのみ使用し、デザインパス、コンテンツ、履歴から一致が明確な場合にのみ採用します。候補が重複している場合は中止します。

同期

  1. 次を実行します。

    python3 /absolute/path/to/scripts/story_contract.py \
  <design-doc> --repo-root <repository-root> --mode delivery \
  --include-source \
  > <temporary-manifest.json>

  2. リポジトリ、デフォルトブランチ、マイルストーン、ラベル、安定したデザイン URL を特定します。

  3. 変更を加える前に、現在の Issue マップをすべて作成します。

  4. マイルストーンを作成するか、既存のものを再利用します。ユーザーまたはリポジトリのポリシーによる権限がない限り、クローズ済みのマイルストーンを再オープンしないでください。

  5. 不足しているストーリー Issue をすべて作成します。付属のレンダラーを使用し、Issue の本文に正確な正規化済みストーリーソースと正規の依存関係リンクを含めます。

  6. 管理対象のストーリー本文、タイトル、依存関係、ラベル、マイルストーンが異なる場合は、既存の Issue をその場で更新します。

  7. ストーリーの契約が変更された場合は、完了済みの Issue を再オープンします。変更されていない完了済みの Issue はクローズしたままにします。

  8. すべての正規 Issue を再読み込みし、マーカー、管理対象の本文、依存関係、ラベル、マイルストーン、状態を検証します。

デザインから削除されたストーリーを、何も伝えずにクローズしないでください。該当する既存の Issue を報告し、削除、延期、復元のいずれにするかを尋ねます。以降の実行で再び尋ねなくて済むよう、ユーザーの決定を Issue に記録します。

管理対象 Issue の本文




## Managed Story Contract
<exact normalized story source>

## Canonical Dependencies
<canonical numbered issue references or None>

## Design Doc
[View in Design Doc](<repository blob URL>)

マニフェストのハッシュは同期時のコンテンツ比較に役立つ場合がありますが、利用側はハッシュ遷移のルールを再現するのではなく、正規 Issue 本文と現在の GitHub の状態を参照してください。

結果

- Design:
- Milestone:
- Issues created:
- Issues updated:
- Changed completed issues reopened:
- Unchanged completed issues:
- Removed-story issues requiring a decision:
- Blocker:

スクリプト

  • scripts/create_issue.sh
  • scripts/create_milestone.sh
  • scripts/story_contract.py
  • scripts/render_issue_body.py

スキルを基準にスクリプトの場所を解決します。複数行の本文には一時ファイルを使用し、無関係なリポジトリの変更は保持してください。

コメント

Markdown 対応