← 返回 Skills 市场
smokealot420

Piv

作者 SmokeAlot420 · GitHub ↗ · v1.0.3
darwinlinux ⚠ suspicious
1553
总下载
0
收藏
2
当前安装
4
版本数
在 OpenClaw 中安装
/install ftw
功能描述
PIV workflow orchestrator - Plan, Implement, Validate loop for systematic multi-phase software development. Use when building features phase-by-phase with PRPs, automated validation loops, or multi-agent orchestration. Supports PRD creation, PRP generation, codebase analysis, and iterative execution with validation.
使用说明 (SKILL.md)

PIV Ralph Orchestrator

Arguments: $ARGUMENTS

Parse arguments using this logic:

PRD Path Mode (first argument ends with .md)

If the first argument ends with .md, it's a direct path to a PRD file:

  • PRD_PATH - Direct path to the PRD file
  • PROJECT_PATH - Derived by going up from PRDs/ folder
  • START_PHASE - Second argument (default: 1)
  • END_PHASE - Third argument (default: auto-detect from PRD)

Project Path Mode

If the first argument does NOT end with .md:

  • PROJECT_PATH - Absolute path to project (default: current working directory)
  • START_PHASE - Second argument (default: 1)
  • END_PHASE - Third argument (default: 4)
  • PRD_PATH - Auto-discover from PROJECT_PATH/PRDs/ folder

Detection Logic

If $ARGUMENTS[0] ends with ".md":
  PRD_PATH = $ARGUMENTS[0]
  PROJECT_PATH = dirname(dirname(PRD_PATH))
  START_PHASE = $ARGUMENTS[1] or 1
  END_PHASE = $ARGUMENTS[2] or auto-detect from PRD
  PRD_NAME = basename without extension
Else:
  PROJECT_PATH = $ARGUMENTS[0] or current working directory
  START_PHASE = $ARGUMENTS[1] or 1
  END_PHASE = $ARGUMENTS[2] or 4
  PRD_PATH = auto-discover from PROJECT_PATH/PRDs/
  PRD_NAME = discovered PRD basename

Mode Detection

After parsing arguments:

  • If PRD_PATH was provided or auto-discovered → MODE = "execute" (normal flow)
  • If no PRD found and no PRD_PATH provided → MODE = "discovery"

Required Reading by Role

CRITICAL: Each role MUST read their instruction files before acting.

Role Instructions
Discovery (no PRD) Read {baseDir}/references/piv-discovery.md
PRD Creation Read {baseDir}/references/create-prd.md
PRP Generation Read {baseDir}/references/generate-prp.md
Codebase Analysis Read {baseDir}/references/codebase-analysis.md
Executor Read {baseDir}/references/piv-executor.md + {baseDir}/references/execute-prp.md
Validator Read {baseDir}/references/piv-validator.md
Debugger Read {baseDir}/references/piv-debugger.md

Prerequisite: A PRD must exist before entering the Phase Workflow. If no PRD exists, the orchestrator enters Discovery Mode (see below).


Discovery Mode (No PRD Found)

When MODE = "discovery":

  1. Read {baseDir}/references/piv-discovery.md for the discovery process
  2. Present discovery questions to the user in a friendly, conversational tone (single message)
    • Target audience is vibe coders, not senior engineers — keep it approachable
    • Skip questions the user already answered in their initial message
  3. Wait for user answers
  4. Fill gaps with your own expertise:
    • If user doesn't know tech stack → research (web search, codebase scan) and PROPOSE one
    • If user can't define phases → propose 3-4 phases based on scope
    • Always propose-and-confirm: "Here's what I'd suggest — does this sound right?"
  5. Run project setup (create PRDs/, PRPs/templates/, PRPs/planning/)
  6. Generate PRD: Read {baseDir}/references/create-prd.md, use discovery answers + your proposals to write PRD to PROJECT_PATH/PRDs/PRD-{project-name}.md
  7. Set PRD_PATH to the generated PRD, auto-detect phases → continue to Phase Workflow

The orchestrator handles discovery and PRD generation directly (no sub-agent needed — interactive Q&A requires staying in the same session, and answers are already in context for PRD generation).


Orchestrator Philosophy

"Context budget: ~15% orchestrator, 100% fresh per subagent"

You are the orchestrator. You stay lean and manage workflow. You DO NOT execute PRPs yourself - you spawn specialized sub-agents with fresh context for each task.

Sub-agent spawning: Use the sessions_spawn tool to create fresh sub-agent sessions. Each spawn is non-blocking — you'll receive results via an announce step. Wait for each agent's results before proceeding to the next step.


Project Setup (piv-init)

If the project doesn't have PIV directories, create them:

mkdir -p PROJECT_PATH/PRDs PROJECT_PATH/PRPs/templates PROJECT_PATH/PRPs/planning

Copy {baseDir}/assets/prp_base.md to PROJECT_PATH/PRPs/templates/prp_base.md if it doesn't exist. Create PROJECT_PATH/WORKFLOW.md from {baseDir}/assets/workflow-template.md if it doesn't exist.


Phase Workflow

For each phase from START_PHASE to END_PHASE:

Step 1: Check/Generate PRP

Check for existing PRP:

ls -la PROJECT_PATH/PRPs/ 2>/dev/null | grep -i "phase.*N\|pN\|p-N"

If no PRP exists, spawn a fresh sub-agent using sessions_spawn to do both codebase analysis and PRP generation in sequence:

RESEARCH & PRP GENERATION MISSION - Phase {N}
==============================================

Project root: {PROJECT_PATH}
PRD Path: {PRD_PATH}

## Phase {N} Scope (from PRD)
{paste phase scope}

## Step 1: Codebase Analysis
Read {baseDir}/references/codebase-analysis.md for the process.
Save to: {PROJECT_PATH}/PRPs/planning/{PRD_NAME}-phase-{N}-analysis.md

## Step 2: Generate PRP (analysis context still loaded)
Read {baseDir}/references/generate-prp.md for the process.
Use template: PRPs/templates/prp_base.md
Output to: {PROJECT_PATH}/PRPs/PRP-{PRD_NAME}-phase-{N}.md

Do BOTH steps yourself. DO NOT spawn sub-agents.

Step 2: Spawn EXECUTOR

Spawn a fresh sub-agent using sessions_spawn:

EXECUTOR MISSION - Phase {N}
============================

Read {baseDir}/references/piv-executor.md for your role definition.
Read {baseDir}/references/execute-prp.md for the execution process.

PRP Path: {PRP_PATH}
Project: {PROJECT_PATH}

Follow: Load PRP → Plan Thoroughly → Execute → Validate → Verify
Output EXECUTION SUMMARY with Status, Files, Tests, Issues.

Step 3: Spawn VALIDATOR

Spawn a fresh sub-agent using sessions_spawn:

VALIDATOR MISSION - Phase {N}
=============================

Read {baseDir}/references/piv-validator.md for your validation process.

PRP Path: {PRP_PATH}
Project: {PROJECT_PATH}
Executor Summary: {SUMMARY}

Verify ALL requirements independently.
Output VERIFICATION REPORT with Grade, Checks, Gaps.

Process result: PASS → commit | GAPS_FOUND → debugger | HUMAN_NEEDED → ask user

Step 4: Debug Loop (Max 3 iterations)

Spawn a fresh sub-agent using sessions_spawn:

DEBUGGER MISSION - Phase {N} - Iteration {I}
============================================

Read {baseDir}/references/piv-debugger.md for your debugging methodology.

Project: {PROJECT_PATH}
PRP Path: {PRP_PATH}
Gaps: {GAPS}
Errors: {ERRORS}

Fix root causes, not symptoms. Run tests after each fix.
Output FIX REPORT with Status, Fixes Applied, Test Results.

After debugger: re-validate → PASS (commit) or loop (max 3) or escalate.

Step 5: Smart Commit

cd PROJECT_PATH && git status && git diff --stat

Create semantic commit with Built with FTW (First Try Works) - https://github.com/SmokeAlot420/ftw.

Step 6: Update WORKFLOW.md

Mark phase complete, note validation results.

Step 7: Next Phase

Loop back to Step 1 for next phase.


Error Handling

  • No PRD: Enter Discovery Mode (see Discovery Mode section above)
  • Executor BLOCKED: Ask user for guidance
  • Validator HUMAN_NEEDED: Ask user for guidance
  • 3 debug cycles exhausted: Escalate to user

Sub-Agent Timeout/Failure

When a sub-agent times out or fails:

  1. Check for partial work (files created, tests written)
  2. Retry once with a simplified, shorter prompt
  3. If retry fails, escalate to user with what was accomplished

Completion

## PIV RALPH COMPLETE

Phases Completed: START to END
Total Commits: N
Validation Cycles: M

### Phase Summary:
- Phase 1: [feature] - validated in N cycles
...

All phases successfully implemented and validated.
安全使用建议
This skill is largely coherent with its stated purpose (orchestrating PIV workflows) but there are a few things to verify before installing or using it: 1) Tooling & credentials: The manifest only lists git as required, but the instructions reference tools like tree, gh (GitHub CLI), and a sessions_spawn tool. If you expect the skill to search GitHub or private repos, confirm what credentials (GH_TOKEN, etc.) the platform will need and whether the skill will request them explicitly. Do not provide secrets unless you understand where they are used and stored. 2) External research and data exposure: The skill instructs agents to perform web searches and use external CLIs. If your project contains sensitive code or PII, understand where those searches will be run and whether the platform or sub-agents will send project content to external services. Ask the platform how sessions_spawn handles privacy and outbound network access. 3) Model-invocation mismatch: The skill declares disable-model-invocation=true but its workflow depends on spawning sub-agents. Confirm with the platform whether sessions_spawn will be allowed or whether the skill will be functional in this configuration. 4) Metadata discrepancy: The SKILL.md includes a GitHub URL while the registry listing said 'Homepage: none'. If provenance matters to you, check that repo (https://github.com/SmokeAlot420/ftw) and verify the author and code there before trusting the orchestrator. 5) Least privilege and testing: Because the skill writes files and can run tests and shell commands in your project, try it first on a disposable/example project or in a contained environment. Review generated PRDs/PRPs before allowing any automated executor to run write/exec steps. If these gaps are clarified (where sessions_spawn runs, how external queries are handled, whether GH or other tokens are needed and how they are protected), the skill would be substantially more trustworthy. Without that information, treat it cautiously.
功能分析
Type: OpenClaw Skill Name: ftw Version: 1.0.3 This skill bundle is classified as suspicious due to the broad and powerful capabilities granted to the AI agent, particularly explicit shell command execution (`exec`) and access to a 'Shell/command runner' for research, as detailed in `references/execute-prp.md`, `references/generate-prp.md`, and `references/piv-executor.md`. While these capabilities are plausibly needed for a comprehensive software development workflow (e.g., running `git`, `ls`, `tree`, and project-specific build/test/lint commands), they represent a significant attack surface. There is no clear evidence of intentional malicious behavior like data exfiltration or persistence, but the extensive permissions without strict sandboxing or explicit guardrails against misuse elevate the risk beyond benign.
能力评估
Purpose & Capability
Name and description match the provided instructions: the skill orchestrates Plan→Implement→Validate workflows, creates PRDs/PRPs, analyzes codebases, spawns sub-agents, and writes files under a project path. Requested resources are minimal (git only), which is plausible. However, the SKILL.md metadata references a GitHub homepage (https://github.com/SmokeAlot420/ftw) while the registry summary stated 'Source: unknown / Homepage: none' — a minor metadata inconsistency. The instructions also reference tools like `tree` and `gh` and expect a sessions_spawn tool; those tools are not declared as required binaries, which is an under-specification (not necessarily malicious, but surprising).
Instruction Scope
The SKILL.md instructs the agent to read and write files under PROJECT_PATH (create PRDs/PRPs/templates, write PRD and PRP files), run local shell commands (ls, mkdir, grep, tree if available), spawn sub-agents via sessions_spawn, run test/lint commands, and optionally perform web searches or use the GitHub CLI. Those actions are coherent with a project orchestration tool. Caveats: 'Use whatever research tools your platform provides' and explicit web-search/gh usage are broad and could cause external queries that include project or conversation content — the skill does not declare or limit what external endpoints are used. The instructions do not request unrelated secrets, nor do they instruct reading system config outside the project path, so there is no explicit file-exfiltration step, but the web-research and sub-agent flow could leak project/user content to external services depending on how the platform implements those tools.
Install Mechanism
This is instruction-only (no install spec, no code files executed). That is the lowest-risk install pattern — nothing is downloaded or written by an installer. Runtime behavior will depend on the platform's session tooling rather than any bundle-installed binaries.
Credentials
The skill declares no required environment variables or credentials, which is consistent with an instruction-only orchestrator. However, the instructions optionally recommend using the GitHub CLI (`gh`) and conducting web searches; those tools often rely on credentials (e.g., GH_TOKEN) to access private repos. The skill does not declare those env vars or request them as required, so if you expect it to search private repos or use authenticated APIs, you should not assume it will prompt for or protect credentials. In short: environment requests are minimal, but there are implicit credential needs that are not documented.
Persistence & Privilege
The skill is not always-included (always:false) and is user-invocable. Notably, disable-model-invocation is true in the SKILL.md metadata — this reduces autonomous model invocations for the skill itself. However, the instructions repeatedly instruct spawning fresh sub-agents via a sessions_spawn tool (non-blocking spawns and receiving results). There is a potential mismatch: the manifest forbids model invocation for the skill, yet the orchestrator is designed to create and rely on sub-agent model sessions. Depending on platform semantics, this could either mean the skill will be non-functional or rely on platform tools that do model invocation on its behalf. Clarify with the platform: will sessions_spawn be allowed when disable-model-invocation is true? If sessions_spawn causes the platform to spawn agents that run models, that increases blast radius (the orchestrator may cause many sub-agents to run and access project data).
如何使用
  1. 确保已安装 OpenClaw(本地或 Docker 部署)
  2. 在对话框中输入安装命令:/install ftw
  3. 安装完成后,直接呼叫该 Skill 的名称或使用 /ftw 触发
  4. 根据 Skill 的参数说明提供必要输入,即可获得结构化输出
版本历史
v1.0.3
Discovery-first flow: no-PRD users get guided discovery questions and automatic PRD generation
v1.0.2
Fix unsafe git add -A: now stages specific files only, never secrets or unrelated changes
v1.0.1
Improved SKILL.md: added workflow step overviews to mode sections for better AI comprehension
v1.0.0
Initial release: unified PIV skill with full, mini, and init modes
元数据
Slug ftw
版本 1.0.3
许可证
累计安装 2
当前安装数 2
历史版本数 4
常见问题

Piv 是什么?

PIV workflow orchestrator - Plan, Implement, Validate loop for systematic multi-phase software development. Use when building features phase-by-phase with PRPs, automated validation loops, or multi-agent orchestration. Supports PRD creation, PRP generation, codebase analysis, and iterative execution with validation. 它是一个面向 Claude Code / OpenClaw 的 AI Agent Skill 插件,目前累计下载 1553 次。

如何安装 Piv?

在 OpenClaw 或 Claude Code 对话框中运行命令「/install ftw」即可一键安装,无需额外配置。

Piv 是免费的吗?

是的,Piv 完全免费(开源免费),可自由下载、安装和使用。

Piv 支持哪些平台?

Piv 跨平台运行,可在任意部署了 OpenClaw / Claude Code 的环境中使用(darwin, linux)。

谁开发了 Piv?

由 SmokeAlot420(@smokealot420)开发并维护,当前版本 v1.0.3。

💬 留言讨论