名称： mini-piv
描述： "轻量级 PIV 工作流 - 以探索驱动的功能构建器。无需 PRD。通过快速提问、生成 PRP，并执行带验证循环的流程。适用于希望跳过 PRD 形式化流程的中小型功能。"
user-invocable: true
disable-model-invocation: true
元数据： {"openclaw":{"emoji":"zap","homepage":"https://github.com/SmokeAlot420/ftw","requires":{"bins":["git"]},"os":["darwin","linux"]}}

Mini PIV Ralph - 轻量级功能构建器

参数: $ARGUMENTS

解析参数：

FEATURE_NAME = $ARGUMENTS[0] 或 null (将在探索阶段询问用户)
PROJECT_PATH = $ARGUMENTS[1] 或当前工作目录

核心理念：快速与质量并重

“当您想跳过 PRD 直接构建功能时使用。”

采用相同的质量管道（执行 → 验证 → 调试），但起点是一次快速对话，而非一份 PRD。

您是协调者 - 保持精简，为繁重任务创建新的子代理。

子代理创建： 使用 sessions_spawn 工具创建新的子代理会话。每次创建都是非阻塞的——您将通过公告步骤接收结果。在进入下一步之前，请等待每个代理返回结果。

各角色必读文档

可视化工作流

┌──────────────────────────────────────────────────────────┐
│ 1. 探索 → 提出 3-5 个问题                                 │
│ 2. 研究与 PRP → 代码库分析 + PRP 生成                     │
│ 3. 执行 → 实现 PRP                                       │
│ 4. 验证 → 通过 / 发现缺陷 / 需要人工介入                  │
│ 5. 调试循环 → 修复缺陷 (最多 3 次)                        │
│ 6. 提交 → feat(mini): {描述}                             │
└──────────────────────────────────────────────────────────┘

步骤 1：探索阶段

1a. 确定功能名称

如果未提供：询问用户或根据上下文推断。将其规范化为 kebab-case 格式。

1b. 检查现有 PRP

ls -la PROJECT_PATH/PRPs/ 2>/dev/null | grep -i "mini-{FEATURE_NAME}"

如果存在，询问：“覆盖、重命名，还是跳过直接执行？”

1c. 提出探索性问题

在一个对话式消息中呈现：

我有几个快速问题，以便正确构建此功能：

1.  **此功能是做什么的？** 简要说明。
2.  **它在代码库中的哪个位置？** 文件、文件夹、组件？
3.  **需要遵循哪些特定的库、模式或现有代码？**
4.  **“完成”的标准是什么？** 1-3 个具体的成功标准。
5.  **哪些内容明确不在范围内？**

根据功能类型（UI、API、合约、集成）进行调整。

1d. 结构化探索答案

feature:
  name: {FEATURE_NAME}
  scope: {Q1}
  touchpoints: {Q2}
  dependencies: {Q3}
  success_criteria: {Q4}
  out_of_scope: {Q5}

步骤 2：研究与 PRP 生成

使用 sessions_spawn 创建一个新的子代理：

MINI PIV：研究与 PRP 生成
====================================

项目根目录：{PROJECT_PATH}
功能名称：{FEATURE_NAME}

## 探索输入
{粘贴结构化的 YAML}

## 步骤 1：代码库分析
阅读 {baseDir}/references/codebase-analysis.md 了解流程。
保存至：{PROJECT_PATH}/PRPs/planning/mini-{FEATURE_NAME}-analysis.md

## 步骤 2：生成 PRP（分析上下文仍保留）
阅读 {baseDir}/references/generate-prp.md 了解流程。

### 探索 → PRP 转换
| 探索项 | PRP 章节 |
|-----------|-------------|
| 范围 (Q1) | 目标 + 内容 |
| 接触点 (Q2) | 实现任务位置 |
| 依赖项 (Q3) | 上下文 YAML，已知问题 |
| 成功标准 (Q4) | 成功标准 + 验证 |
| 范围外 (Q5) | 内容章节中的排除项 |

使用模板：PRPs/templates/prp_base.md
输出至：{PROJECT_PATH}/PRPs/mini-{FEATURE_NAME}.md

**请自行完成这两个步骤。不要创建子代理。**

等待完成。

步骤 3：创建执行代理

使用 sessions_spawn 创建一个新的子代理：

执行代理任务 - Mini PIV
============================

阅读 {baseDir}/references/piv-executor.md 了解您的角色。
阅读 {baseDir}/references/execute-prp.md 了解执行流程。

PRP：{PROJECT_PATH}/PRPs/mini-{FEATURE_NAME}.md
项目：{PROJECT_PATH}

遵循：加载 PRP → 详细规划 → 执行 → 验证 → 确认
输出执行摘要。

验证规模决策

在创建完整验证代理之前，评估：
- 更改文件数 < 5，更改行数 < 100，无外部 API 调用 → 快速验证（由协调者自行审查更改）
- 其他情况 → 创建完整的验证子代理（步骤 4）

步骤 4：创建验证代理

使用 sessions_spawn 创建一个新的子代理：

验证代理任务 - Mini PIV
=============================

阅读 {baseDir}/references/piv-validator.md 了解您的流程。

PRP：{PROJECT_PATH}/PRPs/mini-{FEATURE_NAME}.md
项目：{PROJECT_PATH}
执行摘要：{SUMMARY}

独立验证所有要求。
输出包含等级、检查项、缺陷的验证报告。

处理结果： 通过 → 提交 | 发现缺陷 → 调试代理 | 需要人工介入 → 询问用户

步骤 5：调试循环（最多 3 次迭代）

使用 sessions_spawn 创建一个新的子代理：

调试代理任务 - Mini PIV - 第 {I} 次迭代
============================================

阅读 {baseDir}/references/piv-debugger.md 了解您的方法论。

项目：{PROJECT_PATH}
PRP：{PROJECT_PATH}/PRPs/mini-{FEATURE_NAME}.md
缺陷：{GAPS}
错误：{ERRORS}

修复根本原因。每次修复后运行测试。
输出修复报告。

调试代理完成后：重新验证 → 通过（提交）或循环（最多 3 次）或上报。

步骤 6：智能提交

cd PROJECT_PATH && git status && git diff --stat
git add -A
git commit -m "feat(mini): 实现 {FEATURE_NAME}

- {要点 1}
- {要点 2}

通过 Mini PIV Ralph 构建

使用 FTW (First Try Works) 构建 - https://github.com/SmokeAlot420/ftw"

完成

## MINI PIV RALPH 完成

功能：{FEATURE_NAME}
项目：{PROJECT_PATH}

### 产出物
- PRP：PRPs/mini-{FEATURE_NAME}.md
- 分析：PRPs/planning/mini-{FEATURE_NAME}-analysis.md

### 实施情况
- 验证轮次：{N}
- 调试迭代次数：{M}

### 更改的文件
{列表}

所有要求均已验证并通过。

错误处理

• 执行代理受阻：向用户寻求指导
• 验证代理需要人工介入：向用户寻求指导
• 3 次调试循环已用尽：上报并附上持续存在的问题列表

子代理超时/失败

当子代理超时或失败时：
1. 检查部分完成的工作（创建的文件、编写的测试）
2. 使用简化、更短的提示重试一次
3. 如果重试失败，向用户上报已完成的工作

快速参考

文件命名

PRPs/mini-{feature-name}.md                  # PRP
PRPs/planning/mini-{feature-name}-analysis.md # 分析