chore: snapshot main sync

data/skills/booskills/boo-validating-changes/SKILL.md

@@ -0,0 +1,109 @@
+---
+name: boo-validating-changes
+description: >
+  Independently validates an OpenSpec change folder in a fresh context, in one
+  of two modes: adversarial plan validation before implementation (is this
+  plan buildable and honest), or post-implementation validation that the diff
+  satisfies specs/ and that every checked task's claim is true. Use for
+  "validate this plan," "is this change folder ready to build," "verify the
+  implementation matches the spec," "check it was built right." Do NOT use for
+  general code-quality review of a diff; use boo-reviewing-code. Do NOT use to
+  produce or fix a plan; use boo-planning-changes. Do NOT use to implement;
+  use boo-implementing-changes.
+metadata:
+  version: "1.0"
+---
+
+# Validating Changes
+
+Fresh-context validation of OpenSpec change folders. The planner validating its own plan and the implementer checking its own boxes are claims; this skill treats both as wrong until proven.
+
+## Size
+
+Classify small/medium/large from requirement count and task count in the change folder. Default: small (single capability, under ~10 tasks). Announce with one-line justification. Accept `$size` override.
+
+## Mode selection
+
+Read `openspec/changes/<id>/tasks.md` first:
+- Any task unchecked: **plan mode**.
+- All tasks checked: **implementation mode**.
+- Operator may force a mode; a mixed state with no operator instruction means ask once.
+
+## Process
+
+1. Resolve the change-id and read proposal.md, design.md, specs/, tasks.md in full. Run `openspec validate <id>` (probe the CLI surface with `openspec --help` first); record the result.
+2. Select mode per the rule above and announce it.
+
+Plan mode (adversarial, before any code exists):
+
+3. Verify every file path design.md cites actually exists and behaves as described; a cited file that does not exist is a Blocking finding.
+4. Check internal consistency: proposal scope, specs/ requirements, and tasks.md must describe the same change. Anything in one and missing from the others is a finding.
+5. Check task quality: each task sized 5-20 minutes, independently verifiable, with a named verification command. Vague tasks are findings.
+6. Dispatch `adversarial-validator` (assume the plan fails; find how) and `junior-developer` (artifact review: hidden assumptions, unanswered questions) against the full folder.
+7. Verdict: Ready to implement, or Revise with findings. Stop; never fix the plan.
+
+Implementation mode (after tasks are checked):
+
+3. Treat every checked box as a claim. Re-run each task's named verification command; a verification that cannot run or fails flips that task to unproven.
+4. Trace each requirement and scenario in specs/ to implementing code at file:line. Requirements with no implementing code are findings; scenarios with no covering test are findings.
+5. Diff audit: `git diff --stat` against the pre-change baseline. Edits outside tasks.md scope are findings; tasks claiming edits the diff does not show are Blocking.
+6. Check design.md `## Implementation notes`: divergences recorded there are legitimate; divergence discovered in code but absent from the notes is a Blocking finding (silent redesign).
+7. Dispatch `adversarial-validator` against the conformance summary; add `test-engineer` when scenario coverage is the weak point.
+8. Verdict: Implemented as specified, Divergent (enumerated), or Incomplete. Stop; never fix the code and never archive.
+
+## What NOT to do
+
+- Do not fix, re-plan, or re-implement anything. Findings only.
+- Do not archive the change; the operator archives after a passing verdict.
+- Do not accept a checked box, a passing CI badge, or the implementer's report as evidence; re-derive from commands and code.
+- Do not grade general code quality; that is boo-reviewing-code's job and the two verdicts are independent.
+
+## Gotchas
+
+- **A checked box is a claim, not evidence**: the entire skill exists because self-reported completion drifts from reality.
+- **OpenSpec profile**: the installed CLI version may differ from assumed commands. Run `openspec --help` to verify.
+- **Baseline matters in implementation mode**: diff against the ref where implementation started, not HEAD~1; ask the operator if the baseline is ambiguous.
+- **Evidence rule**: every finding cites file:line or a command output captured this run. No finding from memory.
+<!-- standing-rules:pi:start -->
+- **Subagent visibility**: when the Paseo MCP tools (`mcp__paseo__*`) are available, spawn each agent persona as an attached Paseo subagent with `create_agent` (`detached: false`, `notifyOnFinish: true`; for an opencode provider also pass `settings.modeId: "build"` and `settings.features.auto_accept: true`) so every persona appears in the operator's Paseo agent track. Resolve each persona's provider/model from the active preset's `agents` map in `~/.paseo/orchestration-preferences.json`; supervise on the finish notification (never poll) and read each result with `get_agent_activity`.
+- **Subagent fallback**: when the Paseo MCP tools are not available, use the platform's native subagent dispatch. On a platform with no subagent dispatch at all (for example Pi), read each `agents/<name>.md` persona and apply its lens in sequential passes.
+- **Subagent concurrency**: honor the active preset's `concurrency` value in `~/.paseo/orchestration-preferences.json`. When it is `1` (local heavy-weight presets, around 27b/35b or larger on a single llama-swap server), dispatch subagents STRICTLY ONE AT A TIME: launch one, wait for its finish notification and read its result, then launch the next. This overrides any parallel fan-out. Absent or higher `concurrency` means parallel fan-out is fine.
+<!-- standing-rules:pi:end -->
+<!-- standing-rules:core:start -->
+- **No commit**: never commit, push, or stage changes; never `git add -A`. Prove any edits with `git diff --stat`.
+- **No em dashes**: never use em dashes (U+2014) in output or files you write.
+<!-- standing-rules:core:end -->
+
+## Output format
+
+```
+# Validation: <change-id> (<plan | implementation> mode)
+
+## Verdict
+<Ready to implement | Revise> or <Implemented as specified | Divergent | Incomplete>
+
+## openspec validate
+<command output summary>
+
+## Traceability
+
+| Requirement / Task | Evidence (file:line or command) | Status |
+|--------------------|--------------------------------|--------|
+
+## Findings
+
+**V1: <title>** (Blocking | Advisory)
+- **Location:** <file:line or artifact>
+- **Evidence:** <what was observed>
+- **Impact:** <why it blocks or matters>
+
+## Claims I did not verify
+- <verifications that could not run, with reason>
+```
+
+## Failure modes
+
+- **Change folder missing**: the id does not exist under openspec/changes/. Report and stop.
+- **Mixed task state, no operator mode**: ask once which mode; do not guess.
+- **Verification command cannot run**: mark that task unproven, name the blocker, and cap the verdict at Divergent.
+- **Empty specs/**: nothing to validate conformance against. Report; plan mode can still check tasks and design, implementation mode stops.