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.

Security Scan

The skill's instructions broadly match a PIV orchestrator, but there are several internal inconsistencies and underspecified tool/credential expectations you should understand before installing.

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).

What to consider before installing

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.

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.