docs(skill): 覆盖率阶段 1 样板 —— req / ai-proj 的 evals 与四段式文档
- skills-req/req-plugin/skills/evals/evals.json(3 条:正常/边界/失败恢复) - docs/skills/req.md(What/When/Common questions/It's working if) - skills-core/ai-proj-plugin/skills/evals/evals.json - docs/skills/ai-proj.md - coverage: 40 -> 38
This commit is contained in:
@@ -0,0 +1,24 @@
|
||||
# ai-proj — 任务与需求管理
|
||||
|
||||
## What it does
|
||||
|
||||
通过 ai-proj(`https://ai.pipexerp.com`)的 MCP / CLI 管理需求、任务、文档与进度:查询、创建、更新状态、关联需求与任务、挂证据文档。是所有项目状态数据的唯一权威来源。
|
||||
|
||||
## When to reach for it
|
||||
|
||||
- 要查「某个 REQ / 任务的真实状态、优先级、截止、关联任务」
|
||||
- 要更新任务状态、挂文档、改优先级、改派
|
||||
- 汇报进度或做对齐检查前,需要拉真实数据
|
||||
|
||||
## Common questions
|
||||
|
||||
- **数据以哪为准?** ai-proj,不靠聊天记录或记忆。主机必须是 `https://ai.pipexerp.com`(写成 `api.pipexerp.com` 会失败)。
|
||||
- **可以自己改需求优先级吗?** 不行,需求优先级是业务决策;任务优先级可以对齐需求。
|
||||
- **任务 completed 就是完成了吗?** 不是,REQ 未 `released` 只能算步骤完成。
|
||||
- **接口报错怎么排查?** 先 GET 查证实体是否存在、凭证主机是否正确,不要猜 ID。
|
||||
|
||||
## It's working if
|
||||
|
||||
- 问「REQ-XXXX 现在什么状态」时,它给出带字段名与时间戳的真实数据,而不是复述对话
|
||||
- 更新任务状态前先查一次实体,写入后回读确认
|
||||
- 遇到 404/401 时给的是排查步骤与真实查询结果,不是编造的 ID
|
||||
@@ -0,0 +1,23 @@
|
||||
# req — 需求全生命周期
|
||||
|
||||
## What it does
|
||||
|
||||
把一条需求从创建推进到归档:创建 → 讨论确认 → PRD → 评审 → 开发 → 测试 → 部署 staging/prod → PDV 验收 → released → 归档。同时约束评审、门禁与交付口径,防止跳步和自审批。
|
||||
|
||||
## When to reach for it
|
||||
|
||||
- 用户说「/req」「新建需求」「需求走到哪了」「提交评审」「部署上线」时
|
||||
- 任何需求类工作开始时的第一步(先确定当前阶段,再决定下一个命令)
|
||||
|
||||
## Common questions
|
||||
|
||||
- **能不能跳过评审直接开发?** 不能。PRD 是评审前置,评审通过才能进 dev。
|
||||
- **提交人能不能自己批?** 不能;`allow_self_approve` 只作临时手段且要收回。
|
||||
- **任务都 completed 了算交付吗?** 不算,需求要走到 `released` + PDV 验收通过。
|
||||
- **部署是每个需求单独做吗?** 各需求独立到 testing 后进待部署池,由 `/req deploy` 批量推进。
|
||||
|
||||
## It's working if
|
||||
|
||||
- 问「这个需求现在到哪一步、下一步做什么」时,它先给出 `delivery_stage` 与下一个命令,而不是直接开始写代码
|
||||
- 出现「直接改 approved」「跳过 PRD」这类请求时,它会阻断并给出正确路径
|
||||
- 汇报完成时用的是「REQ 阶段 + 下一节点」,不是「某个开发步骤完成」
|
||||
Reference in New Issue
Block a user