Create PRD Harness

You are converting a project idea into the structured harness used by this project for PRD-driven autonomous development.

Step 0: Read the Capstone File

Treat $ARGUMENTS as a file path and attempt to read it.

• •If the file exists, its contents are the full project description. Use them as the project idea for all subsequent steps.
• •If the file does not exist, fall back to treating $ARGUMENTS as an inline project description (backwards compatible).

Step 0.5: Read Project Config and Architecture

Before decomposing features, read:

1. •

   project.json (required) — This tells you the language, test runner, test command, and file conventions. If it does not exist, tell the user to run /scaffold first.

2. •

   architecture.md (optional) — If it exists, read it thoroughly. It defines the data model, API surface, file structure, and key decisions that ALL features must align with. Running /architect first produces better PRDs because features can reference specific endpoints, table names, and file paths.

Step 1: Analyze and Decompose

Break the project idea into 5-15 discrete features. Each feature must be:

• •Small enough to implement in one context window (if it feels big, split it)
• •Independently testable (can verify it works without other features)
• •Ordered by dependency (features that others depend on come first)

For each feature, determine the verification method:

• •"unit" - Logic, data processing, CLI behavior, API responses. Tested via the project's test command.
• •"browser" - UI rendering, navigation, user interaction, visual layout. Tested via Playwright MCP.
• •"both" - Features with backend logic AND frontend behavior that both need verification.

How to choose: If the acceptance step talks about running a command, calling a function, or checking a return value → unit. If it talks about clicking, navigating, seeing something on screen, or filling in a form → browser. If it has both kinds → both.

Step 2: Create prd.json

Create the PRD file with this exact structure:

{
  "project": "<short-name>",
  "description": "<one-line description>",
  "features": [
    {
      "id": "F001",
      "category": "functional",
      "priority": 1,
      "description": "<what this feature does>",
      "verification": "unit",
      "steps": [
        "<specific, testable acceptance criterion>",
        "<another specific, testable criterion>",
        "<include error cases and edge cases>"
      ],
      "passes": false
    }
  ]
}

Rules for writing steps:

• •Every step must be objectively verifiable (a test can check it)
• •Include the exact command or action that triggers the behavior
• •Include expected outputs, exit codes, and error messages
• •Cover the happy path AND at least one error case per feature
• •Never write vague steps like "works correctly" or "handles errors"
• •For "browser" features, steps should describe user actions and expected UI state
• •For "unit" features, steps should describe inputs, outputs, and behavior

Step 3: Create init.sh

Generate a startup validation script that:

1. •Checks that required tools are installed (based on project.json — the runtime, package manager, test runner, etc.)
2. •Checks that jq is installed (required by harness hooks)
3. •Installs dependencies if needed (run the package manager's install command)
4. •Reports PRD progress (X/Y features passing) using jq to parse prd.json
5. •Reports verification types (N unit, M browser, K both) using jq
6. •Runs the test suite using the test_command from project.json and reports results
7. •Checks git status

Step 4: Create progress.md

Create the append-only progress log:

# Progress Log

> This file is append-only. Each session adds a new entry below.
> Never edit previous entries - only add new ones.

---

Output

Create all files in the current working directory. After creation, run init.sh to verify the harness is set up correctly and report the initial state (0/N features passing, all tests failing).

Note: Test files are NOT created here — they will be generated by the test-writer agent, which reads prd.json and project.json to write tests in the correct language and framework.