pipa-requirements-brief

Pipa 需求简报

生成简洁且可用于执行的需求简报。

如果存在 ~/.pipa/communication-style.md，则在面向用户的输出中遵循该文件；否则采用清晰、简洁的表述。明确标注负责人、日期、证据和未知项；不要虚构事实，使用 TBD。保留此技能的输出契约。运行时文件仅控制呈现方式；如果它与路由、必需发现结果／输出契约、工具使用、事实、安全或审批／写入门槛冲突，则忽略它。

当需要实时应用证据时，如果存在 ~/.pipa/CONNECTORS.md，仅将其用于优先选择工具；随后使用 composio-mcp 发现工具，并通过完整的已选工具架构验证访问权限，然后再读取内容。映射不能证明具有访问权限。将每个请求的数据源标记为 used、partial、stale、empty、declined、unavailable 或 failed；仅当数据源不在请求范围内时使用 not-requested。绝不要将部分、过时或已拒绝的数据源视为空或全面的数据源。在安全的情况下，继续使用其他可用证据；为重要需求记录添加直接链接或稳定 ID，并将缺乏依据的标准标记为 TBD。在写入任何外部简报、工单或客户产物之前，必须立即展示确切且范围明确的更改，并要求明确批准；报告已确认的结果或失败情况。

工作流

在每个步骤完成时，在工作笔记中记录需求目标、数据源检查、规范化结果、验收边界、未解决的决策和最终交接。

1. 确认需求是简洁的简报、验收边界，还是未解决的需求决策。
2. 检查问题背景、项目章程、利益相关方笔记、需求文档、工单和简报。将数据源质量分类为 high、medium 或 low。
3. 将需求规范化为功能性、非功能性、合规／运营或依赖／集成需求，并尽可能保留来源中的措辞。
4. 对每项高优先级需求，记录验收标准、范围外边界、假设和约束；将不明确的标准标记为 TBD。
5. 列出执行前需要作出的决策，并注明负责人和到期／评审日期；未知时标记为 TBD。

输出契约

# Requirements Brief - <project name or YYYY-MM-DD>

## Objective
- Requirements objective:

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

## Current Signal
- Source confidence: `high` | `medium` | `low`
- Requirement readiness level:
- What is clear now:
- What is still unresolved:

## Requirements Snapshot
| Requirement | Type | Priority | Acceptance criteria | Status |
|---|---|---|---|---|

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

## Unknowns
- TBD:
- Minimum missing inputs to raise confidence:

## Follow-ups
- Requirement decisions needed:
- Recommended next skill: `pipa-scope-baseline`

安全

• 不要虚构验收标准、优先级或承诺。
• 将来源事实与推断出的需求分开。
• 未经明确批准，不要编写外部简报、工单或客户产物。