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`

安全

• 保留来源措辞，并区分证据与推断。
• 不要将问题界定转化为已承诺的范围或首选解决方案。
• 未经明确批准，不要写入外部记录。