mcpField
A
align

align

github.com/canhassancode開発141 回インストール3 日前に更新
リポジトリ

align について

alignは、実装前に依頼を合意済みの仕様、インターフェース、失敗状態で固定したテストにまとめるワークフロー用スキルです。エージェントとユーザーによる段階判定、レビュー、ドメイン決定、チケットの完了を導きます。

主な機能

  1. 01依頼の段階判定と振り分け
  2. 02レッドチームレビューとユーザー判断
  3. 03仕様作成と決定事項の記録
  4. 04インターフェースのスタブと固定テスト
  5. 05チケットとセッションの完了処理

活用シーン

  1. 01実装前のスコープ明確化
  2. 02コーディング用子タスクの準備
  3. 03決定事項と未解決点の記録

インストール

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

$npx skills add https://github.com/canhassancode/skills --skill align

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

同梱ファイル

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

EXAMPLES.md
references/
red-team.md
spec.md
tiers.md

詳細

Align

依頼を仕様、承認済みのインターフェース、ロックされた失敗テストへと変換し、ビルド時に判断すべきことが残らないようにします。

由来：Shape Up のシェイピング（アペタイト、対象外、深追いすべき論点を賭ける前に決めること）と Liu et al. 2026（レビュー済みの計画は役立つが、質の低い計画は計画がない場合よりも悪い）。

すべての質問はgrillingに従います。すべての用語と ADR はdomain-modelingに従います。事実はサブエージェントから得て、ユーザーからは得ません。すべての数値はreferences/spec.mdの Numbers ルールに従います。接続先を探すためであっても、.env、.mcp.jsonなどの認証情報を含む設定ファイルは決して開きません。すべての返信はEXAMPLES.mdに従います。

手順

  1. Tier. references/tiers.mdに基づいて依頼を分類し、確認します。
    • 1文の差分：そう伝え、差分とリスクをそれぞれ1行で示して終了します。提案はしません。エイリアス、シム、フォローアップも提案しません。
    • 不明瞭：不明点ごとに1つずつ、/spike、/research、または/prototypeに送ります。それぞれの回答を Decisions に記録し、再分類します。
    • 親が打ち切られたタスクの子タスク：親の仕様を読み、手順3に進みます。
  2. Red team. references/red-team.mdに従って、新しいサブエージェントに概要を伝えます。その判定（go、shrink、または no-go）を示し、判断はユーザーに委ねます。
  3. Spec. references/spec.mdのテンプレートが埋まるまで質問します。1セッションで収まる場合は子仕様、それ以外は親仕様にします。決着した質問はそれぞれ、日付付きのQ → Aとして Decisions に記録します。
  4. Domain. 新しい用語と ADR はそれぞれ個別に承認を得ます。
  5. Interface（子タスクのみ）。codebase-designを使ってシグネチャを提案します。コード、呼び出し元1つ、エラーの種類を、一度に1つのインターフェースについて提示します。承認されたら、コンパイルできて例外をスローするスタブとしてコミットします：feat: stub <capability> interface。
  6. Tests（子タスクのみ）。/testerを実行し、そのレポートとTypecheck:およびGaps:の行を一字一句そのまま示します。各ギャップは、1つずつ質問する場合でも、同じメッセージで必ずユーザーに伝えます。ギャップがある間はロックできません。インターフェースのギャップは手順5へ、仕様のギャップは手順3へ進みます。テストがすべて成功する場合、ロックが古い場合、または型チェックに関するギャップがある場合は、ユーザーに確認します。テストがすべて成功する場合は、その行を残すかどうかと、残す場合の文面を確認します。ロックが古い場合は、行を再度ロックする前に、ユーザー自身で削除してもらいます（! git rm <file>）。型チェックを実行できなかった場合は、通常、依存関係をインストールして/testerを再実行します。ギャップがなく承認されたら、test: lock <capability> testsをコミットします。
  7. Close. references/spec.mdの Numbers ルールに基づいてすべての数値を確認し、仕様をチケット本文に記入し、ブランチがあればプッシュして、セッションコメントを投稿し、ラベルを設定します。
終了時の状態ラベル次の手順
テストをロックした子タスクready-to-build/build <ref>
親仕様ready-to-cut/cut <ref>
ルーム外での承認が必要ready-to-propose/propose <ref>
未解決の質問があるneeds-alignment（質問を明記）対応するルート、その後/align <ref>
no-gowontfix理由を記録して終了

保存場所

  • Spec：親仕様の場合は親チケットの本文、子仕様の場合はそのチケットの本文に記載します。本文に記載されていた内容はすべて置き換えます。ステータスは本文に記載せず、ラベルで示します。
  • Code（子タスクのみ）：スタブとロック済みテストはfeat/<capability>に置き、チケットへのリンクを含むドラフトのプルリクエストとして開きます。複数のリポジトリにまたがる子タスクでは、references/spec.mdに従い、ヘッダー行に各リポジトリのブランチとマージ順を記載します。親タスクにはブランチがありません。
  • Session comment：セッションごとに1つ投稿し、進展した内容だけを記載します。

1セッションにつき子タスクは1つです。次のタスクは新しいセッションで開始します。ロック済みテストで停止したビルドはここに戻します。まず仕様を変更し、ユーザーが古いテストを削除した後、変更された行のみを対象に手順6を実行します。

コメント

Markdown 対応