paperclip-plan-work

Paperclip の作業計画

一度に計画するのは、子課題の1階層だけにしてください。複数階層にわたる課題ツリー全体を展開して作成しないでください。

計画と実行は別です。このスキルでは、提案する子課題が後のトリアージに向けて準備できているように見えるかを分類できますが、着手可能な状態にしてはいけません。オペレーターが明示的に paperclip-triage または委任ワークフローに切り替えない限り、計画中の課題は backlog とし、担当者を割り当てないでください。

参照資料

まず、次の資料を読んでください。

• references/CONTEXT.md
• references/docs/paperclip-operator/control-plane.md
• references/docs/paperclip-operator/workflow.md
• references/docs/paperclip-operator/afk-readiness.md
• references/docs/paperclip-operator/cli-contract.md
• references/docs/paperclip-operator/integration-matrix.md

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

手順

1. 親となる戦略課題または親課題を特定します。

2. 課題、親課題の階層、プロジェクト、計画ドキュメント、ブロッカー、コメントを読みます。

3. Paperclip のサーフェスの事前確認を実行します。

4. 子課題を1階層分だけ提案します。

5. 提案する各子課題を、次のいずれか1つだけに分類します。

   • 準備できているように見える
   • 計画用の親課題
   • 人間による対応が必要
   • ブロック中
   • 情報が必要

   すべての提案課題に、1つだけ分類が付いていれば完了です。

6. 「人間による対応が必要」「ブロック中」「情報が必要」に分類された課題、または広範な計画用親課題が3件以上ある場合は、課題を作成する前に、的を絞った質疑・精査を行うために一時停止します。

7. 各課題について、書き込む正確なタイトル、本文、ステータス、親課題、プロジェクト、目標、ブロッカーリンク、担当者を提示します。

8. 提案する内訳を示し、承認を求めます。

9. 承認後、依存関係の順に課題を作成します。

10. 計画用の親課題については、それぞれに対してもう一度計画を行うかどうかを尋ねます。

Wiki の参照資料

親課題、計画ドキュメント、コメント、またはオペレーターのプロンプトで Paperclip wiki の URL、wiki ページのパス、または取得済みの wiki ソースが参照されている場合は、子課題を提案する前に paperclip-wiki-fetch を使用してください。取得したソースのタイトル、パス、更新時刻、ハッシュ、根拠となる抜粋のうち、作業に関係するものを提案する課題の本文または受け入れ条件に含めてください。

認証情報、会社のスコープ、wiki ID、スペースのスラッグ、またはページのパスが不足していて wiki を取得できない場合は、計画を一時停止し、不足している情報を尋ねてください。アクセスできない wiki 資料に依存する子課題は作成しないでください。

オペレーターから計画結果を wiki に公開、同期、または更新するよう明示的に依頼された場合は、提案する内訳を完成させてから、承認後に paperclip-wiki-manage を使用して wiki を変更してください。

サーフェスの事前確認

変更を提案する前に、次の項目について書き込み可能なサーフェスを確認します。

• アクティブな会社と会社 ID
• 課題の作成・更新
• 子課題の親課題へのリンク付け
• 計画中の作業を backlog に維持する場合に限った、課題ステータスの更新
• blockedByIssueIds
• 計画ドキュメントが関係する場合の、計画ドキュメントの読み取り・書き込み
• CLI と専用 MCP ツールで必要なネイティブフィールドに書き込めない場合の、MCP API リクエストまたは直接 REST を利用できるかどうか

API 接続情報の導出には、paperclipai context show --json、paperclipai auth whoami --json、~/.paperclip/auth.json だけを使用してください。ベアラートークンを表示してはいけません。必須のネイティブフィールドに書き込めない場合は、停止して不足している機能を報告してください。オペレーターがその機能低下を明示的に承認しない限り、第一級のブロッカー、親課題リンク、計画ドキュメントをコメントで代用してはいけません。

提案する内訳の形式

## Proposed Child Issues

### 1. <title>

- Type: ready-looking | planning parent | needs-human | blocked | needs-info
- Priority:
- Status to write: backlog
- Parent:
- Project:
- Goal:
- Blocked by:
- Assignee: null
- Body:
- Acceptance criteria:
- Validation:
- Stop conditions:

作成ルール

• 計画では backlog の課題と、担当者が割り当てられていない課題のみを作成します。
• このスキルから todo を作成または更新したり、エージェントを割り当てたり、作業をチェックアウトしたり、ハートビートを手動で実行したりしないでください。
• todo は運用上アクティブな状態として扱ってください。課題が引き受けられる可能性があります。計画済みの作業を todo に移せるのは、paperclip-triage または明示的な委任ワークフローのみです。
• オペレーターの意図を尊重してください。「計画する」「細分化する」「構造を作る」は、実行ではなくバックログ構造の作成を意味します。
• 計画の親課題は backlog として作成してください。
• parentId または現在の操作画面で使われるネイティブの親フィールドを使用して、子課題を親課題にリンクしてください。MCP を使用する場合は、公開されているツールのスキーマを確認し、作成されたレコードに親とのリンクが保持されていることを検証してください。
• 利用可能な場合は、親がコマンド内で明示される paperclipai issue child:create <parentIssueId> --payload-json <json> --json を優先してください。続行する前に、返された子課題と親課題とのリンクを検証してください。
• CLI または専用の MCP 課題ツールでこのフィールドが公開され、検証される場合を除き、blockedByIssueIds には MCP の paperclipApiRequest を使用してください。
• 計画で作成した課題を実行エージェントに割り当てないでください。
• 必要に応じて、計画上の判断を説明するコメントを追加してください。

変更トランザクションの規律

Paperclip は、現在のオペレーター向け操作画面では、複数の課題にまたがる明確なトランザクションを提供していません。複数の課題を作成する場合：

1. 課題を1つ作成します。
2. 直ちに次の項目を検証します。
   • parentId が想定した親と一致している
   • projectId が対象のプロジェクトと一致している
   • goalId が正しく引き継がれているか、リンクされている
   • status が backlog である
   • 担当者が null である
   • 該当する場合、blockedByIssueIds のリンクが存在する
3. CLI、MCP、paperclipApiRequest、または直接 REST を通じて可能な場合は、構造上の不一致を修正します。
4. 計画済みの課題を todo に変更しないでください。準備が整っているように見える課題は、トリアージ候補として報告してください。
5. 検証に成功した後でのみ、次の課題に進みます。

親とのリンク、ブロッカーとのリンク、プロジェクトとのリンク、ゴールとのリンク、バックログの状態、または担当者が null であることを正しく設定できない場合は、残りの課題を作成する前に停止し、部分的な状態を報告してください。

変更ルール

オペレーターが提案された細分化を承認するまで、子課題を作成しないでください。