v0.9.0

Changed

• pm specs-from-prd, business PRDs: the skill no longer assumes the PRD knows the systems. In Phase 1 it reads the repositories' own onboarding, architecture and README documents and agent instruction files, notes every other system they or the code name (including services that appear only in code comments), and asks for each repository's path and for the branch or ref that counts as the current code, recorded in a new Baseline header line. It also looks for specs, planning documents and tickets that already cover the PRD outside the specs folder. Phase 2 reads the documents the PRD relies on and settles, in one question, which are in scope, which version of each counts and which areas the run covers.
• pm specs-from-prd, analysis: Phase 3 starts with a systems map and translates every requirement into the systems that would deliver it. Requirements get MET, PARTIAL or ABSENT; an ABSENT status needs a search record and survives a second pass that tries to find the capability under another name. Decisions already recorded in tickets, existing specs and design rules are collected and not asked again. A new Defect category covers code that is meant to work and does not: reported, not asked about. Subagent ABSENT results are re-read like FALSE and PARTIAL ones.
• pm specs-from-prd, interview: opens with the systems map in plain words, then the audience question. Every question names the system it concerns and has background, an example, the question, options with what each means for the product's users, and evidence after them, written for a tech lead or solution architect who knows the systems in general but not every detail this PRD touches. The opening shows only the part of the systems map this PRD touches, for the user to correct, and quotes the audience and success measure when the PRD already states them. More than about ten findings: grouping by system or area is recommended. A finding that rested on a wrong fact is corrected and the decisions built on it are re-asked.
• pm specs-from-prd, template and checker: the template gains a Baseline header line, a Systems involved table and a system column in the findings table. The checker accepts citations into other repositories as repo:path:line and takes --root NAME=PATH once per repository; an unprefixed citation in a spec resolves under that spec's Repo.
• pm specs-from-prd, checker call: the draft reaches the checker as a file, specs-from-prd-draft-<slug>.md in the scratchpad or system temporary directory, instead of an inline heredoc that failed on Windows and led the agent to improvise a temporary file. Content rule 8 now allows that one draft copy. When python3 is missing or is the Windows Store stub, the skill tries python, py -3 and uv run --no-project python.
• pm specs-from-prd, frontmatter and permissions: model: sonnet is removed, because a skill's model override lasts only until the user's next message, so it covered the analysis and nothing after it. The Permissions section now says accurately what is pre-approved and that the checker may ask for permission after the user's first reply.
• pm specs-from-prd, when the user is asked: a new section lists the five points where the skill asks the user something, one step per message, so a repository found during the analysis is not folded into the opening question. The pacing offer is now a statement, not a second question.
• pm specs-from-prd, decisions: a D-nn needs the user's answer or a source document that states it. When the user declines the interview, every choice they did not make is a gap, even when their success signal seems to settle it. A PRD claim the code shows to be FALSE is not reported as a defect.
• pm specs-from-prd, Atlassian: a Confluence PRD can be read through an Atlassian server registered under another name or with other tool names, such as getConfluenceContent. The Atlassian steps moved to references/confluence.md, read only for a Confluence PRD, and the pm README now states this exception to the atlassian server-name requirement.
• pm specs-from-prd, rules that survive a summary: a short Rules for the whole run block at the top of SKILL.md (no write before the confirmed review gate, the Source check: line, a gap instead of a choice nobody made, re-read the phase's reference after a summary) and an eight-step progress list replace the closing completion checklist. SKILL.md is shorter, so the part kept after a conversation summary holds the review gate.
• pm specs-from-prd, scope and contradictions: what is in or out of scope must come from the PRD, the user or the code, and how to resolve a contradiction between the PRD and the code is a choice: without an answer it is a gap. The INVEST check asks before it splits, merges or reframes a locked spec or one a recorded decision settled, instead of "before drafting", which came after the draft.
• pm specs-from-prd, asking for other repositories: the Phase 1 question says in one plain line what each system found does in this feature, with the evidence in brackets after it.

Added

• pm evals: specs-from-prd/no-interview-records-gaps-not-decisions, and a dry-run-writes-nothing grader that checks the user is told whether the checker passed or did not run. Each writes-no-file grader, the edits-no-file grader and writes-nothing-outside-docs-specs now allow the checker's draft copy, and every ran-the-checker grader accepts python, py -3 and uv run python as well as python3. The plain-language grader of maps-a-business-prd-onto-the-systems is written for a tech lead or solution architect and judges only how the systems are described.
• pm configuration: specs_dir in .claude/pm.json sets the folder specs-from-prd writes to (default docs/specs; absolute paths and .. refused).
• pm evals: specs-from-prd/maps-a-business-prd-onto-the-systems, a PRD that names no system where the repository's docs and a code comment place invoices in an external billing service.