jpskill.com
📦 その他 コミュニティ

contracts

契約書の作成から利用、修正、そして問題解決といった、契約ライフサイクル全体を効率的に管理し、ビジネスにおける契約業務をスムーズに進めるSkill。

📜 元の英語説明(参考)

Contract lifecycle management - creation, consumption, modification, and resolution.

🇯🇵 日本人クリエイター向け解説

一言でいうと

契約書の作成から利用、修正、そして問題解決といった、契約ライフサイクル全体を効率的に管理し、ビジネスにおける契約業務をスムーズに進めるSkill。

※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。

⚡ おすすめ: コマンド1行でインストール(60秒)

下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。

🍎 Mac / 🐧 Linux
mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o contracts.zip https://jpskill.com/download/17952.zip && unzip -o contracts.zip && rm contracts.zip
🪟 Windows (PowerShell)
$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/17952.zip -OutFile "$d\contracts.zip"; Expand-Archive "$d\contracts.zip" -DestinationPath $d -Force; ri "$d\contracts.zip"

完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。

💾 手動でダウンロードしたい(コマンドが難しい人向け)
  1. 1. 下の青いボタンを押して contracts.zip をダウンロード
  2. 2. ZIPファイルをダブルクリックで解凍 → contracts フォルダができる
  3. 3. そのフォルダを C:\Users\あなたの名前\.claude\skills\(Win)または ~/.claude/skills/(Mac)へ移動
  4. 4. Claude Code を再起動

⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。

🎯 このSkillでできること

下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。

📦 インストール方法 (3ステップ)

  1. 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
  2. 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
  3. 3. 展開してできたフォルダを、ホームフォルダの .claude/skills/ に置く
    • · macOS / Linux: ~/.claude/skills/
    • · Windows: %USERPROFILE%\.claude\skills\

Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。

詳しい使い方ガイドを見る →
最終更新
2026-05-18
取得日時
2026-05-18
同梱ファイル
1

📖 Skill本文(日本語訳)

※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。

Contracts Skill

Contracts は、並行タスク間のインターフェースを定義します。依存関係を明示的にすることで、安全な並行実装を可能にします。

この Skill をロードするタイミング

  • Architect: 設計で contracts を定義するとき
  • Executor: 実装前に contracts を具体化するとき
  • Implementer: contracts を実装または利用するとき
  • Contract-Resolver: contracts を修正するとき

Contract のライフサイクル

DESIGN → MATERIALIZE → IMPLEMENT → VERIFY → (ブロックされた場合は RESOLVE)
   ↓          ↓            ↓          ↓            ↓
Architect  Executor   Implementer  Verifier  Contract-Resolver

Phase 1: Design (Architect)

Architect は、設計アウトプットで contracts を定義します (コンパクトな JSON):

{"contracts":[{"name":"user-repository","description":"Interface for user data access","definition":"interface UserRepository { getById(id: string): Promise<User | null>; save(user: User): Promise<void>; }","used_by":["task-001","task-002","task-003"]}]}

Architect 向けのルール:

  • タスク間の依存関係には必ず contracts を定義する
  • contracts を最小限かつ完全にする
  • 誰が提供し、誰が消費するかを明記する
  • execution_plan.contracts_first に含める

Phase 2: Materialize (Executor)

Executor は、implementer を生成する前に、contracts をファイルに書き込みます。

final_design.contracts の各 contract について:
  memory/contracts/{name}.json に書き込む (コンパクトな JSON)

場所: memory/contracts/{contract-name}.json

Contract ファイルの構造:

{"name":"user-repository","version":1,"status":"active","created_at":"ISO-8601","source_design":"memory/reports/final_design.json","definition":{"type":"interface","language":"typescript","spec":"interface UserRepository { ... }"},"description":"Interface for user data access","consumers":[{"task_id":"task-001","role":"provider"},{"task_id":"task-002","role":"consumer"}],"history":[{"version":1,"date":"ISO-8601","change":"Initial contract from design"}]}

Phase 3: Implement (Implementer)

Implementer は contract のパスを受け取り、以下を行う必要があります。

  1. コーディング前に contracts を読み込む
  2. contract で指定された内容を 正確に実装する
  3. 実装をアウトプットで 報告する:
{"contracts_implemented":[{"name":"user-repository","location":"src/repositories/user.ts","role":"provider"}]}

contract が不十分な場合:

  • Status: blocked
  • Reason: contract_change
  • 提案された contract の修正を含める

Phase 4: Verify (Verifier)

Verifier は以下をチェックします。

  • Provider がすべての contract メソッドを実装しているか
  • Consumer が contract で定義されたインターフェースのみを使用しているか
  • 型が contract の仕様と一致しているか

Phase 5: Resolve (Contract-Resolver)

Implementer が contract でブロックされている場合:

  1. ブロックを読み込む - どのような変更が必要か?

  2. 影響を評価する - 他に誰がこの contract を使用しているか?

  3. アクションを決定する:

    • modify: contract を更新する。必要に応じて breaking とマークする
    • extend: breaking なしに contract に追加する
    • reject: 代替アプローチを提案する
  4. contract ファイルを更新する - バージョンをインクリメントし、履歴に追加する

  5. 影響を受けるタスクについて executor に指示する

Contract の種類

Interface Contract

{"definition":{"type":"interface","language":"typescript","spec":"interface PaymentGateway { charge(amount: number, token: string): Promise<ChargeResult>; refund(chargeId: string): Promise<RefundResult>; }"}}

Data Structure Contract

{"definition":{"type":"data_structure","language":"typescript","spec":"type User = { id: string; email: string; createdAt: Date; }"}}

API Contract

{"definition":{"type":"api","spec":"POST /api/users | Request: { email: string, password: string } | Response: { id: string, token: string } | Errors: 400 (validation), 409 (exists)"}}

Event Contract

{"definition":{"type":"event","spec":"Event: user.created | Payload: { userId: string, email: string, timestamp: ISO8601 } | Emitted by: UserService | Consumed by: EmailService, AnalyticsService"}}

Contract の発見

タスクの contracts を見つけるには:

1. タスクの説明を読み込む
2. Glob("memory/contracts/*.json")
3. consumers に task_id が含まれるものをフィルタリングする
4. role (provider vs consumer) で分離する

Breaking Changes

変更が breaking であるのは、以下の場合です。

  • メソッドのシグネチャが変更された
  • 必須フィールドが入力に追加された
  • フィールドが出力から削除された
  • 型が互換性のないように変更された

Breaking changes には以下が必要です。

  • すべての consumer の再検証
  • 場合によっては再実装

原則

  1. コードより先に Contracts - implementer を生成する前に、すべての contracts を具体化する
  2. Single provider - 各 contract には、正確に 1 つの provider タスクがある
  3. Explicit consumers - すべての consumer をリストする必要がある
  4. Version everything - バージョンをインクリメントせずに変更しない
  5. History is immutable - 過去の履歴エントリを編集しない
📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開

Contracts Skill

Contracts define interfaces between parallel tasks. They enable safe concurrent implementation by making dependencies explicit.

When to Load This Skill

  • Architect: When defining contracts in design
  • Executor: When materializing contracts before implementation
  • Implementer: When implementing or consuming contracts
  • Contract-Resolver: When modifying contracts

Contract Lifecycle

DESIGN → MATERIALIZE → IMPLEMENT → VERIFY → (RESOLVE if blocked)
   ↓          ↓            ↓          ↓            ↓
Architect  Executor   Implementer  Verifier  Contract-Resolver

Phase 1: Design (Architect)

Architect defines contracts in design output (compact JSON):

{"contracts":[{"name":"user-repository","description":"Interface for user data access","definition":"interface UserRepository { getById(id: string): Promise<User | null>; save(user: User): Promise<void>; }","used_by":["task-001","task-002","task-003"]}]}

Rules for Architects:

  • Define contracts for ANY cross-task dependency
  • Make contracts minimal but complete
  • Specify who provides vs consumes
  • Include in execution_plan.contracts_first

Phase 2: Materialize (Executor)

Before spawning implementers, executor writes contracts to files:

FOR each contract in final_design.contracts:
  Write to memory/contracts/{name}.json (compact JSON)

Location: memory/contracts/{contract-name}.json

Contract file structure:

{"name":"user-repository","version":1,"status":"active","created_at":"ISO-8601","source_design":"memory/reports/final_design.json","definition":{"type":"interface","language":"typescript","spec":"interface UserRepository { ... }"},"description":"Interface for user data access","consumers":[{"task_id":"task-001","role":"provider"},{"task_id":"task-002","role":"consumer"}],"history":[{"version":1,"date":"ISO-8601","change":"Initial contract from design"}]}

Phase 3: Implement (Implementer)

Implementer receives contract paths and must:

  1. Read contracts before coding
  2. Implement exactly what contract specifies
  3. Report implementation in output:
{"contracts_implemented":[{"name":"user-repository","location":"src/repositories/user.ts","role":"provider"}]}

If contract is insufficient:

  • Status: blocked
  • Reason: contract_change
  • Include suggested contract modification

Phase 4: Verify (Verifier)

Verifier checks:

  • Provider implements all contract methods
  • Consumer only uses contract-defined interfaces
  • Types match contract specification

Phase 5: Resolve (Contract-Resolver)

When implementer is blocked on contract:

  1. Read the block - What change is needed?

  2. Assess impact - Who else uses this contract?

  3. Decide action:

    • modify: Update contract, mark breaking if needed
    • extend: Add to contract without breaking
    • reject: Suggest alternative approach
  4. Update contract file - Increment version, add to history

  5. Instruct executor on affected tasks

Contract Types

Interface Contract

{"definition":{"type":"interface","language":"typescript","spec":"interface PaymentGateway { charge(amount: number, token: string): Promise<ChargeResult>; refund(chargeId: string): Promise<RefundResult>; }"}}

Data Structure Contract

{"definition":{"type":"data_structure","language":"typescript","spec":"type User = { id: string; email: string; createdAt: Date; }"}}

API Contract

{"definition":{"type":"api","spec":"POST /api/users | Request: { email: string, password: string } | Response: { id: string, token: string } | Errors: 400 (validation), 409 (exists)"}}

Event Contract

{"definition":{"type":"event","spec":"Event: user.created | Payload: { userId: string, email: string, timestamp: ISO8601 } | Emitted by: UserService | Consumed by: EmailService, AnalyticsService"}}

Contract Discovery

To find contracts for a task:

1. Read task description
2. Glob("memory/contracts/*.json")
3. Filter where task_id in consumers
4. Separate by role (provider vs consumer)

Breaking Changes

A change is breaking if:

  • Method signature changed
  • Required field added to input
  • Field removed from output
  • Type changed incompatibly

Breaking changes require:

  • Re-verification of all consumers
  • Potentially re-implementation

Principles

  1. Contracts before code - Materialize all contracts before spawning implementers
  2. Single provider - Each contract has exactly one provider task
  3. Explicit consumers - All consumers must be listed
  4. Version everything - Never modify without incrementing version
  5. History is immutable - Never edit past history entries