mcpField
E
escribir-contrato

escribir-contrato

github.com/adminoryslabs開発011 回インストール1 週間前に更新
リポジトリ

escribir-contrato について

ユーザーストーリーとプロジェクト上の決定事項から、テスターと開発者向けに観測可能な振る舞いを定める契約を作成するスペイン語のスキルです。未解決の要件は質問し、契約と質問を提示した時点で停止します。

主な機能

  1. 01範囲を絞ったコンテキストの整理
  2. 02観測可能なインターフェース動作の定義
  3. 03ケースと受け入れ基準の対応付け
  4. 04提案する決定事項の明示
  5. 05変更履歴付きのバージョン管理
  6. 06実装や公開を行わず停止

活用シーン

  1. 01HTTP、画面、コマンド、イベントの動作仕様化
  2. 02テスターと開発者の共通契約の作成
  3. 03開発前の要件不足の解消

インストール

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

$npx skills add https://github.com/adminoryslabs/armory --skill escribir-contrato

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

同梱ファイルassets/contrato-template.md

詳細

契約書の作成

目標

TESTER と DEV が読む唯一のドキュメントを作成します。つまり、HU が外部から見てどのように動作する必要があるかを、互いに連携しない 2 つのエージェントが同じ結果にたどり着けるだけの精度で記述します。契約書で定めるのは外部から観測できる内容であり、内部の実装は DEV に委ねます。

このスキルでは何も構築しません。 記述し、質問し、そこで停止します。

入力

  • HU — MCP が接続されている場合は Jira から取得し、そうでない場合は指定されたファイルまたはリンクから取得します。未解決の論点がある場合は、停止します。契約書を作成する前にエスカレーションが必要です。
  • TECH-DESIGN.md — この HU に該当するセクションと受け入れ条件。
  • adrs/ — この HU に関連するストーリーの ADR のみ(API スタイルなど、インターフェースに影響する横断的な ADR を含む)。
  • AGENTS.md — プロジェクトの規約。
  • contratos/ 内の過去の契約書 — すでに確定した名称との矛盾を避けるために参照します。

ワークフロー

  1. コンテキストパッケージを作成します。 HU、該当する ADR、TDD のセクションのみを含めます。パッケージに含めたものと、その理由を列挙します。

  2. 機能を利用するための外部から観測可能なインターフェース(HTTP ルート、画面、コマンド、イベントなど)を特定します。契約書はそのインターフェースについて記述します。

  3. **各 Gherkin シナリオと TDD の各受け入れ条件について、**次のケースを導き出します。

    • 正確な入力(ルート、パラメーター、形式)。
    • 各ケースの正確な出力(ステータス、データ、画面に表示されるテキスト、永続化される効果)。
    • エラー(無効な入力がどの応答を返すか)。
  4. 変更を認めない名称を確定します。 ルート、フィールド、画面に表示されるメッセージ、形式などです。TESTER はこれらをテキストで検証します。

  5. 各行の出典を記録します(Gherkin シナリオ、TDD の基準、ADR)。出典のない行は新しい決定です。DECISIÓN PROPUESTA と記し、人間への質問リストに追加します。HU に由来するかのように提示してはいけません。

  6. 契約書の対象外となるもの(構造、関数名、クエリーなど、すべての内部要素)を明記します。これらは DEV に委ねます。

  7. assets/contrato-template.md を使い、バージョン v1 の contratos/CONTRATO-<HU>.md を保存します。

  8. 停止します。 契約書と質問を人間に提示します。誰にも呼びかけません。

バージョン管理

サイクル中に未確定事項が見つかった場合(TESTER、DEV、または判定結果からの報告):

  1. 人間への質問を作成します。
  2. 回答を受けて契約書を編集し、バージョンを上げ(v2、v3…)、変更内容、理由、承認者を記載した行を変更履歴に追加します。
  3. LEAD が TESTER と DEV に新しいバージョンを通知します。

制約

  • HU に記載されていないことを推測で補いません。質問します。
  • 契約書に内部実装を記述しません。
  • 以前の契約書で確定した名称と矛盾させる場合は、その旨を明示します。
  • 何も公開しません。

コメント