/prd-to-goal

name: prd-to-goal
description: "Decomposes a PRD, issue, or spec into a copy-pasteable single `/goal until ..., or stop after N turns` line. Use when running /goal against a spec, to reduce acceptance criteria to AND-joined boolean assertions."
argument-hint: "[prd-text | issue#N | path/to/spec.md]"
tags: [/goal, planning, prd, automation, cc-2.1.139]
version: 0.1.0
author: OrchestKit
license: MIT
compatibility: "Claude Code 2.1.251+ (uses GA `/goal` loop)."
user-invocable: true
complexity: low
context: inherit
persuasion-type: guidance
allowed-tools: [Read, Write, Bash, Grep, Agent]
metadata:
  category: planning
  milestone: M140
triggers:
  keywords: ["prd to goal", "goal from prd", "convert prd to goal", "/goal from issue", "decompose acceptance criteria"]
  examples:
    - "turn this PRD into a /goal line"
    - "what should my /goal until clause be for issue #1792"
    - "decompose this spec into observable assertions"
  anti-triggers: [implement, fix, commit, refactor, push]

prd-to-goal — PRD → /goal Decomposition

Converts a PRD / issue / spec into a single copy-pasteable `/goal` line. The hard part of `/goal` is not running it — it is writing an `until` clause that is *convergent* (terminates), *falsifiable* (testable boolean), and *observable* (the agent can actually check it without subjective judgement). This skill makes that decomposition reproducible.

1. When to use

**Use it when:**

• You have a written PRD, GitHub issue, or spec and want to run `/goal` against it.
• Past `/goal` runs drifted, looped, or burned tokens because the `until` clause was vague (`until tests pass`, `until done`, `until design is good`).
• You need to justify the abort budget — turns, tokens, no-progress threshold.

**Skip it when:**

• One-shot bug fix where the failing test *is* the acceptance criterion. Just run `/goal until pnpm test -- auth.spec.ts passes`.
• No written PRD exists. Run `write-prd` first — vibes do not decompose.
• The work is destructive or irreversible (DB migrations, mass file deletes). `/goal` retries; you do not want retries on `DROP TABLE`.

2. Inputs the skill accepts

| Input | How | |---|---| | Pasted PRD text | Provide as the argument, or paste into the chat after invoking. | | GitHub issue | `gh issue view <N> --json title,body,labels` — the skill reads `body`. | | Spec file | Path to a Markdown / text file; the skill `Read`s it. | | ADR / design doc | Same as spec file. |

3. The decomposition algorithm

1. **Extract acceptance criteria.** Pull every `MUST`, `SHOULD`, `Definition of Done`, `Acceptance Criteria`, and checkbox-style line. If the doc has none, stop and tell the user to run `write-prd` first — there is nothing to converge on. 2. **Map each criterion to an observable boolean.** Each criterion must reduce to a single shell-checkable assertion. Examples of observable state:

• `test -f path/to/file` (file exists)
• `pnpm test -- pattern passes` (test command exits 0)
• `gh pr view <N> --json state | jq -r .state == "MERGED"`
• `wc -l < src/auth.ts` returns a number within bound
• `pnpm lint` exits 0
• `curl -sf $URL` returns 2xx

3. **Reject non-observable criteria.** Drop or rewrite criteria that depend on subjective judgement (`code is clean`, `design feels right`, `users are happy`). Either find a proxy (`lint exits 0`, `Lighthouse score > 90`, `NPS survey ID exists`) or surface the criterion back to the user as out of scope for `/goal`. 4. **Compose the `until` clause.** AND-join the observable assertions in priority order — the cheapest, most likely-to-fail check first so the loop short-circuits early. Three to five assertions is the sweet spot; more than seven usually means the PRD is two PRDs. 5. **Fold the budget INTO the same condition.** Claude Code accepts one goal per session, replace-on-set, and the bound is written inside that single condition (`…, or stop after 15 turns`). It is not a second command. Sensible turn caps:

• `15` for a single feature, `30` for a refactor, `5` for a bug fix.

> **Never emit a second `/goal` line.** A second line does not add a rail — it > parses as a fresh condition, REPLACES the first, and leaves the session > goaled on the budget alone with every acceptance assertion discarded. The > `abort-if` form this skill used to emit was never Claude Code syntax at all: > `grep -c -a -F 'abort-if'` against the 2.1.226 binary returns `0`, and it > appears in none of the 357 archived changelogs. Verified 2026-08-08 (#3312).

4. Output template

The skill emits exactly ONE line, ready to paste:

/goal until <assertion_1> AND <assertion_2> AND <assertion_3>, or stop after <N> turns

Emit the line first, on its own. A fenced code block around it is fine, since the user copies it out. Any notes (assertion ordering, what a grep cannot prove) go after the line and stay short. Never emit a second `/goal` line, and never emit a goal line at all when the input has no observable acceptance criteria (step 1 of the algorithm): say so and point at `write-prd` instead.

Optional: rubric emission (`.claude/rubric.json`)

When the user wants graded feedback beyond pass/fail booleans, the skill MAY also emit `.claude/rubric.json` conforming to `ork-rubric/1.0` (schema: `${CLAUDE_PLUGIN_ROOT}/shared/rubric.schema.json`), mapping each acceptance criterion to one dimension:

{
  "rubric": "ork-rubric/1.0",
  "skill": "prd-to-goal",
  "dimensions": [
    { "name": "regression_test_added", "weight": 0.4, "min_pass": 8, "min_blocker": 3 },
    { "name": "auth_suite_green",      "weight": 0.4, "min_pass": 10, "min_blocker": 5 },
    { "name": "lint_clean",            "weight": 0.2, "min_pass": 10, "min_blocker": 0 }
  ]
}

Scores are 0–10 (`min_pass` = soft floor, `min_blocker` = hard blocker regardless of composite); dimension weights MUST sum to 1.0 — see the schema for the full contract.

The file is deliberately **user-editable before the `/goal` run**