feat(instructions): backlog skill — story readiness validation + human work breakdown (#307)

[isolomatov-gd]

Closes #307.

What

New skill instructions/r3/core/skills/backlog/ — the human/BSA-facing backlog skill, two modes behind one router.

story-validator (the issue's ask): decide whether an existing story is honestly ready for the next sprint, grounded in the actual code, and make an unready story partially actionable rather than blocked.

intake (read-only via data-collection)
  → business analysis (engineer subagent)
  → user Q&A gate
  → technical analysis (engineer subagent, reasoning from the implementer's seat)
  → focused concerns
  → user Q&A gate
  → persist report to FEATURE PLAN folder
  → gated backlog write-back (engineer subagent)

Two verdicts, decided independently from the enough-information test — can this be built with no assumption and no hallucination? — applied as tracker labels and restated in the report:

Axis	Ready	Not ready
Business	ready-for-development	not-ready-for-development
Technical	tech-ready	not-tech-ready

work-breakdown: human WBS with EARS FRs. This method previously lived as a secondary branch inside planning, whose own SKILL.md targets AI session graphs. It now belongs to the skill whose subject it actually is.

Files

Path	Role
backlog/SKILL.md	router: dispatch branch, mode table, orchestration, cross-mode grounding + audience rules
assets/story-validator.md	mode-1 method: 7 steps, verdict rules, toolbox, report contract
assets/story-validator-business-analysis.md	dispatch prompt
assets/story-validator-technical-analysis.md	dispatch prompt
assets/story-validator-backlog-writeback.md	dispatch prompt + tracker write binding
assets/work-breakdown.md	merged pl-human + pl-wbs
assets/work-breakdown-templates.md	LARGE-only: EARS FR + risk register
backlog/README.md	maintainer doc

planning keeps AI-session planning only and carries one compatibility redirect so existing callers asking it for a human WBS still reach the owner. Its four pl-* assets are removed; nothing outside skills/planning/ referenced them.

Design notes for review

• Tasks carry context, never decisions. Verbatim contracts, affected paths, links to existing specs and patterns, unchosen options. No schema, no interface, no pseudocode — the implementer decides how; the task guarantees they never have to ask what.
• Grounding is enforced, not encouraged. No citation means it is not a finding; it becomes a recorded unknown. Contracts are copied, never paraphrased — a paraphrased field list is the exact defect that stalls a sprint.
• Concerns fail independently. The technical pass splits concerns and validates each alone, so one unreachable external API cannot drag every other concern to not-ready.
• Structured returns. Both analysis dispatches return XML, so findings carry stable BA-nn / TA-nn ids. The write-back and the report reference findings by id rather than re-deriving them, which is what keeps the write-back from quietly reinterpreting the analysis.
• Write binding has no delete operation. Removing a tracker item is irreversible and destroys other people's history, so it is proposed for a human, never performed. Writes are preview-then-approve, with separate confirmation for overwrites and closes, and degrade to ready-to-paste text when credentials lack write access.
• One story, one context. The mode does not mandate subagents. Both analysis prompts apply sequentially in the same context, so the two lenses stay separate without a process boundary and the codebase orientation happens once rather than twice. The exception names its subagent: story too big for one context -> INVOKE SUBAGENT engineer per pass. A focused concern that must be delegated reuses technical-analysis scoped to that concern, so it still inherits the grounding rules. Batching across many stories is the caller's decision, not this skill's.
• Write-back is never dispatched. It holds the preview approval and the per-operation confirmations, which a subagent cannot obtain. The actor that made the promises to the user makes the irreversible calls.
• Dispatch mechanism (for the too-big case). APPLY SKILL FILE resolves against the current skill and a fresh subagent has none, so dispatch lines cannot name assets/... directly — pa-rosetta.md alias rule 8 requires expressing intent and letting the skill route. The <dispatch> branch sits ahead of <core_concepts> on purpose: a spawned subagent never runs the Rosetta prep steps, so it must reach the branch before that gate.
• Report persists before write-back, so a lost session resumes from evidence instead of re-running both analysis passes.
• Workspace locations are TERM references (FEATURE PLAN folder), never literal paths — load-project-context owns the paths.
• No model recommendations. The skill names subagents, never models.
• Routing to backlog from planning is a concept reference, which the authoring rules permit — only naming another skill's files is forbidden. It is how existing planning callers reach this method.

Validation

• venv/bin/python scripts/pre_commit.py passes; all plugin variants regenerated with the shipped --deterministic-hooks false posture
• backlog present in all seven targets plus light profiles; no pl-* remnants anywhere in plugins/
• No dangling references repo-wide (hitl/README.md repointed at the moved template); instructions/r2 untouched by design
• Authoring flow followed end to end: brief → draft → hardening against pa-hardening.md + pa-rosetta.md → edit → dispatch-path simulation → review round applied

🤖 Generated with Claude Code

[github-actions]

Rosetta Triage Review

Summary: Adds a new backlog skill (router + story-validator and work-breakdown modes) for human/BSA-facing sprint-readiness validation and work breakdown, moves the human-WBS method out of planning, and regenerates all 14 plugin variants accordingly.

Findings:

• All plugin variants (core-{claude,codex,cursor,copilot,antigravity} × standard/light, plus standalones) mirror instructions/r3/core/skills/backlog consistently; no stale pl-* remnants anywhere under plugins/ or instructions/r3 (r2 correctly untouched).
• Repo-wide grep confirms zero dangling references to the deleted pl-human, pl-wbs, pl-functional-requirements, pl-risk-and-unknowns assets — the PR body's claim holds.
• subagent_required_model normalizes correctly per IDE in the generated plugins (verified directly: claude-opus-5 in core-claude, gpt-5.6-sol-high in core-codex, inherit in core-antigravity, short IDs in core-cursor, display names in core-copilot).
• The <dispatch> mechanism is sound and matches the subagent-directives EXECUTION_CONTROLLER pattern: a fresh subagent loading USE SKILL backlog still has its own dispatch-naming prompt in context, APPLY SKILL FILE resolves against the now-current skill, and an unknown dispatch name is explicitly guarded ("STOP, report to the orchestrator").
• work-breakdown.md + work-breakdown-templates.md preserve the deleted pl-wbs.md template and pl-functional-requirements.md's EARS structure verbatim, and the risk register is structurally unchanged (renamed only) — no substantive content loss from the merge.

Caveats:

• SKILL.md's <templates> contract states work-breakdown -> plans/<FEATURE>/ artifacts, wbs.md on LARGE, but work-breakdown.md's own size-scaling table only writes to plans/ for MEDIUM (>5 tasks) and LARGE — SMALL stays in todo tasks only. The router's stated output contract overstates what two of three size tiers actually produce.
• In story-validator.md's ad-hoc "focused concerns" fan-out, those subagents are explicitly not given a fixed dispatch name and so never load backlog's own <grounding> section (citation/verbatim-quote requirement) — the only carried-over instruction is an unenforced "evidence bar" phrase. Citation discipline is solid in the three named dispatch assets but has this one gap in the ad-hoc path.
• subagent_required_model is carried as a prose sentence inside <orchestration> in this SKILL.md; every other occurrence in the repo is an XML attribute on a workflow <phase> tag. Values are correct, but the carrier is a new, schema-undefined pattern for skills.

Clarifications:

• The self-declared "known deviation" (planning/SKILL.md naming backlog directly) may not actually be a deviation — pa-hardening.md's reword-to-intent guidance (USE SKILL <name> to do X, no file names) is arguably satisfied by the existing line, and the repo already has a same-shape precedent (data-collection referenced by role from other skills). Worth confirming with the author whether this is genuinely non-compliant or mislabeled.

Suggestions:

• Consider tightening the ad-hoc concern-dispatch prompt in story-validator.md to explicitly restate the citation-or-unknown rule, since it is the one dispatch path that doesn't inherit <grounding> via a named dispatch.
• Align the <templates> output line with the actual size-scaling behavior (or note the SMALL exception explicitly) so the contract doesn't overstate persistence.

Automated triage by Rosetta agent

[isolomatov-gd]

Thanks for the careful read — six comments, six landed.

Applied as suggested

• USE SKILL hitl now opens both Q&A gates, and what it duplicated is deleted: TLDR-first and batching belong to hitl, "ask only what code cannot answer" belongs to questioning. Only the story-specific part remains. This was the most useful comment of the set.
• Both planning/README.md wordings tightened, the second using your phrasing verbatim.
• The description is compressed to triggers only; the BSA/architect tail was explanation that would never make anything fire.

Answered by design, with a clarity fix

• backlog-writeback is deliberately not dispatchable: it holds the preview approval and the per-operation confirmations, which a subagent cannot obtain. Two of the comments landed in that area, which told me <dispatch> read as incomplete — it now says so explicitly.
• Business analysis is no longer dispatched at all. The mode runs one story in one context, so the two lenses stay separate as sequential prompts and the codebase orientation happens once. The exception names its subagent in SKILL.md.
• The invocability fields stay unspecified on purpose: the skill should be reachable by both a user and the model, which is exactly what the defaults give, and the schema says emit these only when non-default.

Also from the automated triage: the <templates> output line now matches the size table, model recommendations are out of the skill entirely, and the planning → backlog route is documented as a route rather than a deviation — referencing a skill by concept is permitted; only referencing another skill's files is not.

Resolving these. Reopen any where the reasoning does not hold.