contracts
契約書の作成から利用、修正、そして問題解決といった、契約ライフサイクル全体を効率的に管理し、ビジネスにおける契約業務をスムーズに進めるSkill。
📜 元の英語説明(参考)
Contract lifecycle management - creation, consumption, modification, and resolution.
🇯🇵 日本人クリエイター向け解説
契約書の作成から利用、修正、そして問題解決といった、契約ライフサイクル全体を効率的に管理し、ビジネスにおける契約業務をスムーズに進めるSkill。
※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。
下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。
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
$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. 下の青いボタンを押して
contracts.zipをダウンロード - 2. ZIPファイルをダブルクリックで解凍 →
contractsフォルダができる - 3. そのフォルダを
C:\Users\あなたの名前\.claude\skills\(Win)または~/.claude/skills/(Mac)へ移動 - 4. Claude Code を再起動
⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。
🎯 このSkillでできること
下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。
📦 インストール方法 (3ステップ)
- 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
- 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
- 3. 展開してできたフォルダを、ホームフォルダの
.claude/skills/に置く- · macOS / Linux:
~/.claude/skills/ - · Windows:
%USERPROFILE%\.claude\skills\
- · macOS / Linux:
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 のパスを受け取り、以下を行う必要があります。
- コーディング前に contracts を読み込む
- contract で指定された内容を 正確に実装する
- 実装をアウトプットで 報告する:
{"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 でブロックされている場合:
-
ブロックを読み込む - どのような変更が必要か?
-
影響を評価する - 他に誰がこの contract を使用しているか?
-
アクションを決定する:
modify: contract を更新する。必要に応じて breaking とマークするextend: breaking なしに contract に追加するreject: 代替アプローチを提案する
-
contract ファイルを更新する - バージョンをインクリメントし、履歴に追加する
-
影響を受けるタスクについて 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 の再検証
- 場合によっては再実装
原則
- コードより先に Contracts - implementer を生成する前に、すべての contracts を具体化する
- Single provider - 各 contract には、正確に 1 つの provider タスクがある
- Explicit consumers - すべての consumer をリストする必要がある
- Version everything - バージョンをインクリメントせずに変更しない
- 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:
- Read contracts before coding
- Implement exactly what contract specifies
- 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:
-
Read the block - What change is needed?
-
Assess impact - Who else uses this contract?
-
Decide action:
modify: Update contract, mark breaking if neededextend: Add to contract without breakingreject: Suggest alternative approach
-
Update contract file - Increment version, add to history
-
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
- Contracts before code - Materialize all contracts before spawning implementers
- Single provider - Each contract has exactly one provider task
- Explicit consumers - All consumers must be listed
- Version everything - Never modify without incrementing version
- History is immutable - Never edit past history entries