pipa-problem-framing

Pipa 問題の枠組み設定

曖昧な依頼を、計画にすぐ活用できる問題の枠組みにまとめます。

ユーザー向けの出力には、~/.pipa/communication-style.md が存在する場合、その内容を適用してください。存在しない場合は、明確で簡潔な表現を使用してください。担当者、日付、根拠、不明点は明示し、事実を捏造せずに TBD を使用してください。このスキルの出力契約を守ってください。ランタイムファイルが制御するのは表現のみです。ルーティング、必須の調査結果／出力契約、ツールの使用、事実、安全性、承認／書き込みのゲートと矛盾する場合は無視してください。

アプリの最新の根拠が求められた場合は、~/.pipa/CONNECTORS.md が存在すればツールの優先順位を判断する目的に限って読み、その後、composio-mcp の検出と選択したツールの完全なスキーマを使って、読み取り前にアクセスを確認してください。マッピングだけではアクセスの証明になりません。依頼された情報源ごとに、used、partial、stale、empty、declined、unavailable、failed のいずれかを報告してください。依頼の範囲外の情報源に限り、not-requested を使用してください。部分的な情報源、古い情報源、または利用を断られた情報源を、空または網羅的なものとして扱ってはいけません。安全であれば、他の利用可能な根拠を使って続行してください。重要なブリーフ、メモ、フィードバック、チケットは、直接リンクまたは安定した ID を添えて引用してください。利用可能な枠組み設定の手掛かりが何も残っていない場合に限り、作業を中断してください。外部への書き込みを行う直前に、変更内容とその対象範囲を正確に提示し、明示的な承認を求めてください。確認できた結果、または失敗を報告してください。

ワークフロー

各ステップの完了に合わせて、枠組み設定の目的、情報源の確認、境界、成果／制約、前提／決定事項、最終引き継ぎを作業メモに記録してください。

1. 明確にする必要のある問題、影響を受ける人々、緊急性、成功の判断基準を確認します。
2. ブリーフ、キックオフメモ、ステークホルダーのメモ、トラッカーのパターン、ユーザー／クライアントのフィードバックを確認します。情報源の品質を high、medium、low に分類してください。根拠が弱くても続行し、利用可能な情報源が何もない場合に限り中断してください。
3. 問題の記述、影響を受けるユーザー、対象に含める範囲／含めない範囲、非目標を作成します。情報源に基づく事実と推論を区別してください。
4. 望ましい成果、測定可能な成功基準、制約、トレードオフを記録します。数値目標や期限を捏造してはいけません。
5. 計画に進む前に必要な前提、リスク、決定事項を、担当者と日付、または TBD とともに明らかにします。

出力契約

# Problem Framing - <project name or YYYY-MM-DD>

## Objective
- Framing objective:

## Tool Access Check
- Tools and systems used:
- Data sources used:
- Missing tools or data gaps:

## Current Signal
- Problem clarity level:
- What is clear now:
- What is still ambiguous:

## Problem Frame
- Problem statement:
- Affected users/stakeholders:
- Why now:
- In scope:
- Out of scope:
- Non-goals:

## Actions
| Item | Owner | Next action | Due/review date | Status | Evidence/source |
|---|---|---|---|---|---|

## Unknowns
- TBD:

## Follow-ups
- Inputs needed before planning:
- Recommended next skill: `pipa-requirements-brief`

安全性

• 情報源の表現を保ち、根拠と推論を区別してください。
• 枠組み設定を、確定したスコープや望ましい解決策に変えてはいけません。
• 明示的な承認なしに、外部の記録を書き換えてはいけません。