mcpField
P
paperclip-clarify

paperclip-clarify

github.com/bbengaminエージェントワークフロー356 回インストール11 週間前に更新
リポジトリ

paperclip-clarify について

Paperclip の運用者向けスキルで、曖昧な意図を構造化された確認サマリーにまとめます。依存関係に沿って一問ずつ質問し、確認中に Paperclip を変更しません。

主な機能

  1. 01一度に一問ずつ確認
  2. 02依存関係に沿った意思決定
  3. 03未解決事項の判断記録
  4. 04Paperclip wiki の参照
  5. 05変更を行わない確認フロー

活用シーン

  1. 01曖昧な Paperclip の目標を明確化
  2. 02範囲と成功基準の決定
  3. 03承認要件と停止条件の特定

インストール

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

$npx skills add https://github.com/bbengamin/skills --skill paperclip-clarify

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

同梱ファイル

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

references/
CONTEXT.md
references/docs/paperclip-operator/
control-plane.md
workflow.md

詳細

Paperclip Clarify

曖昧なオペレーターの意図を、構造化された確認サマリーに変換します。Paperclip は変更しません。

参照資料

まず、以下をお読みください。

  • references/CONTEXT.md
  • references/docs/paperclip-operator/workflow.md
  • references/docs/paperclip-operator/control-plane.md

これらのプロジェクトドキュメントがない場合は、まず paperclip-setup を実行して、同梱のテンプレートから作成してください。

プロセス

Paperclip 専用の掘り下げセッションとして進めます。

意思決定ツリーを一度に1つの分岐ずつ進め、依存する判断の前に、その前提となる判断を解決します。たとえば、成果が安定する前に課題の範囲を明確にしたり、影響範囲が分かる前に自律性を明確にしたり、成功基準が具体的になる前に検証方法を明確にしたりしないでください。

質問は常に1つだけ提示し、担当者の回答を待ってから、次に最も重要な分岐を選びます。各質問には推奨する回答を添え、担当者がすぐに承認、編集、または却下できるようにします。複数の質問を1回のやり取りにまとめてはいけません。

コードベースまたは Paperclip の状態から答えを確認できる場合は、質問するのではなく、そちらを調べてください。

担当者が Paperclip wiki の URL、wiki ページのパス、または取得した wiki ソースをコンテキストとして提示した場合は、wiki の内容で答えられる質問をする前に、paperclip-wiki-fetch を使って内容を読み取ってください。wiki にアクセスするための情報が不足している場合は、不足している最小限の情報を尋ね、変更を伴わない確認にとどめてください。

表面的な確認だけで終わらせないでください。入力が例外的に明確な場合を除き、良いセッションでは通常、複数回のやり取りが必要です。意図が曖昧なままなら、「質問が5つ未満」であることを疑い、作業の実態を理解せず、単にラベルを受け入れているだけではないか、結論を出す前に確認してください。

進行中は、簡潔な意思決定記録を維持してください。

  • 確定事項:計画の前提として扱える程度に解決済みの事実や判断。
  • 仮定:推奨しているものの、担当者が明示的に確認していない回答。
  • 未解決の分岐:重要な判断のうち、まだ解決していないもの。
  • 矛盾:範囲、オーナーシップ、検証、自律性、または停止条件に関して、互いに両立しないことを示す回答。

記録を使って次の質問を選んでください。回答によって1つの分岐が解決しても、依存関係が明らかになった場合は、別の分岐に移る前にその依存関係を確認してください。

コンテキストとトピックの実用的なモデルができるまでは、確認モードを続けてください。担当者が最初の数問に答えたからといって、計画、分解、実装、または Paperclip の変更に移行してはいけません。

要約を提示する前に満たすべき最低条件:

  • 以下の必須領域それぞれについて、すでに明確な回答が得られている場合を除き、少なくとも1つ質問してください。
  • 回答に「安全」「完了」「セットアップ」「E2E」「エージェント」「レビュー」「バックエンド」「フロントエンド」「データベース」「自律的」「自己完結型」などの曖昧な表現が含まれる場合は、追加の質問をしてください。
  • 最初の AFK ループを成功させるために何が実現していなければならないかを尋ね、広すぎる目標の範囲を絞ってください。
  • 具体的なシナリオで計画を検証してください:クリーンなチェックアウト、シークレットの不足、E2E の失敗、スキーマ変更、不安定な依存関係、ブロックされたエージェント、実装の一部完了、レビュアーによる却下。
  • 矛盾やコンテキストの欠落を厳しく確認してください。2つの回答が異なる範囲、オーナーシップ、検証基準、または停止条件を示唆する場合は、すり合わせて済ませるのではなく、追加で質問してください。
  • 要約する前に、最初の具体的な AFK ループ、それを紐づけるべきコントロールプレーンのオブジェクト、明示的に対象外とするもの、成功を証明する証拠、エージェントを停止させる条件を言い直せる状態にしてください。
  • 要約する前に、意思決定記録を見直してください。重要な分岐はすべて、確定済み、意図的に未解決の質問として記載済み、または支障のない仮定として扱われている必要があります。
  • 成果、範囲、検証、自律性、または停止条件に重要な曖昧さが残っている場合、最終要約を提示してはいけません。

以下を明確にしてください。

  • 望ましい成果
  • それが重要な理由
  • 範囲
  • 対象外とするもの
  • 成功基準
  • 対象ユーザーまたはオペレーター
  • 制約
  • リスク
  • 自律性のレベル
  • 必要な承認
  • 検証に関する期待
  • 停止条件
  • 未解決の質問

質問集

これらは台本ではなく、質問のきっかけとして使ってください。次に尋ねるのは、最も効果の高い質問だけにしてください。

  • この作業は、具体的にどの Paperclip の会社、目標、プロジェクト、または既存の Issue に関連付けますか?
  • オペレーターが最初の AFK ループの成功を実感するには、どのような結果が必要ですか?
  • 最初の段階で明確に対象外とするものは何ですか?
  • どの既存 Issue を正として扱い、どれを過去の参考情報としてのみ扱いますか?
  • エージェントは確認なしに何を変更できますか?フロントエンド、バックエンド、データベース、インフラ、ドキュメント、テスト、シークレット、外部サービスのうち、どれですか?
  • どのような場合に作業を停止して、ボードに質問する必要がありますか?
  • Issue を完了としてマークする前に、どの検証が必須ですか?
  • クリーンなチェックアウトから利用できる必要があるローカルセットアップは何ですか?
  • 必要なシークレット、サービス、マイグレーション、シードデータ、ブラウザー、テストコマンドは何ですか?
  • これまでに発生した、または発生する可能性の高い失敗パターンは何ですか?
  • エージェントは、コメントや成果物にどのようなレビュー用の証跡を残す必要がありますか?
  • エージェントがローカルで完全な検証を実行できない場合、どうすべきですか?
  • どの判断は後から変更可能で、どの判断は実装前に承認が必要ですか?
  • どのような場合、計画された Issue は AFK 実行には範囲が広すぎますか?

出力

最後に、確認事項のまとめを記載してください。

## Clarification Summary

### Outcome

### Why This Matters

### Scope

### Non-Goals

### Success Criteria

### Constraints

### Risks

### Autonomy Level

### Required Approvals

### Validation

### Stop Conditions

### Open Questions

その後、paperclip-record-strategy に進むかどうかを尋ねてください。

変更に関するルール

このスキルから Paperclip の目標、プロジェクト、Issue、承認、スキル、コメントを作成または更新してはいけません。

コメント