Refine staged workflow context and evidence handling; preserve validation rigor while reducing repeated work

plugins/staged-implementation/skills/implementer/SKILL.md

@@ -27,7 +27,7 @@ The prompt should define scope, non-goals, requirements, invariants, validation,
 1. Read context.
    - Read project instructions first.
    - Read the supplied implementer prompt.
-   - Read only the plan, checklist, docs, source files, and tests needed for the declared chunk.
+   - Read the plan, checklist, docs, source and tests needed for the chunk using targeted searches/relevant sections; expand to full files when dependencies or findings require it. Avoid repeated unchanged dumps. Parse large logs/JSON programmatically where useful without hiding relevant evidence.
 
 2. Make a plan before implementation.
    - Use `update_plan` for non-trivial work.
@@ -37,8 +37,8 @@ The prompt should define scope, non-goals, requirements, invariants, validation,
    - Record exact temporary paths as created, purpose/owner and remaining consumers in the existing handoff. Check target-filesystem headroom before large builds/installations/copies; hold unsafe allocations and report insufficient space. Reuse compatible environments only when isolation and candidate identity remain intact.
    - Coordinate large allocation starts with the parent and report completion/retained bytes; recheck after substantial allocations. Defaults unless explicitly overridden: below 5 GiB free report/serialize large allocations; 2 GiB or less pause write-heavy work and report a blocker. Admission must leave more than the critical reserve after combined remaining peak usage, not merely pass an independent free-space check. Outside orchestration, apply the same checks to known competing allocations and serialize when uncertain.
 
-3. Extract contracts before coding.
+3. Verify contracts before coding.
-   - For contract-heavy chunks, write down the required MUSTs, invariants, exact fields, response shapes, event semantics, error mappings, persistence formats, and non-goals before editing.
+   - For contract-heavy chunks, verify an existing applicable checklist against authoritative MUSTs, invariants, exact fields, response shapes, event semantics, error mappings, persistence formats and non-goals. Reuse it when complete; add missing requirements or create one if none is suitable. An omitted invariant still applies. Share requirement IDs but keep this pass's findings/evidence separate from independent validation.
    - Treat those requirements as the acceptance checklist for the diff.
    - Do not use placeholders such as "same as today" for contract behavior in code or tests.
 
@@ -55,6 +55,7 @@ The prompt should define scope, non-goals, requirements, invariants, validation,
 
 5. Validate.
    - Before expensive checks, preflight working directory/paths, tool versions, generated-input prerequisites and relevant file-type/symlink handling; reuse verified setup and recheck changed or uncertain assumptions. Derive intended assertions from frozen contracts and use source for implementation facts; investigate disagreement rather than making tests mirror a defect. Reuse applicable harness/verification helpers and candidate input records; create only the smallest missing helper when needed. Preflight does not replace behavioral tests.
+   - Batch compatible independent checks, preserving each underlying operation's exit status and success/failure/timeout/cancellation/unexecuted result. Shared fixtures, ports, generated files or build destinations require sequencing unless isolation is established; respect candidate and allocation boundaries. Keep required full logs durable, return concise results and inspect failures. Filtering/parsing success or no matching error text does not establish a pass; surface incomplete output/parser failures and inspect raw evidence as needed.
    - Run the validation commands requested in the prompt when feasible.
    - Run targeted additional checks only when they directly reduce risk for the edited surface.
    - For corrections, identify affected behavior/consumers and rerun affected checks. Reuse evidence only when the assignment permits it and relevant inputs still match; retain original limits. Rerun if applicability is uncertain. Never skip a required fresh check or broaden into unrelated matrices/harnesses.
@@ -74,11 +75,13 @@ The prompt should define scope, non-goals, requirements, invariants, validation,
    - Distinguish fresh validation from verified reused evidence; give concise differences, counts, failures, skipped cases/limits and artifact paths instead of repeating unchanged inventories or full logs. Retain raw evidence and prior candidate provenance; inspect failures/unexpected output. Briefly explain recurring setup failures or repeated checks in this report. Apply process improvements prospectively without repackaging historical evidence.
    - Hand off owned temporary paths, active processes, retained evidence/recovery needs and disposable candidates to the parent. Do not remove a build/check-out needed by validation or a later gate merely because implementation ended.
    - List blockers, ambiguities, or residual risk.
-   - Include the requested contract verification matrix for contract-heavy chunks.
+   - Link the durable contract verification matrix for contract-heavy chunks unless explicitly required in the response; keep blocking findings and missing evidence visible and verify artifact accessibility.
    - Always propose a one-line commit message unless the user explicitly asks not to. If the prompt defines a chunk ID, start the message with that exact prefix.
 
 ## Implementation Rules
 
+Complete routine steps within the assignment without repeated parent acknowledgements. Promptly report blockers, material findings and ownership conflicts; candidate release, shared-resource acquisition, scope changes and required approvals remain coordination points. Completion does not release resources. For a bounded correction, verify the original assignment/current candidate and apply the delta with required revalidation instead of recreating still-valid artifacts. Preserve required user updates. Correctness obligations take priority over token savings.
+
 An authorized orchestration run includes routine cleanup of its tracked, disposable temporary resources; the parent passes that bounded scope and any restrictions into the assignment. Clean only exact assigned run-owned resources after parent/consumer release, without a separate user approval within that scope. Verify ownership and path boundaries, preserve required evidence in a verified durable location with updated references, and release owned processes first. Never sweep `/tmp`, follow links into unrelated locations, prune shared caches, remove files predating the run or force-remove uncommitted work. Standalone implementation permission does not grant this orchestration scope. Without applicable authority or with uncertain retention, leave paths recorded and request clarification; retention/no-deletion instructions and pauses remain binding.
 
 - Treat questions, observations, and suggestions as analysis-only unless the user explicitly asks for code or patches.
@@ -105,10 +108,13 @@ Do not silently broaden the test strategy in a way that changes project structur
 
 Keep the final response concise and factual:
 
+- ready for review | blocked | incomplete; candidate baseline plus scoped changes/build identity as applicable, not self-acceptance
 - changed files and behavior
-- validation results
+- fresh/reused validation, failures and missing evidence
 - blockers, ambiguities, or residual risk
-- contract verification matrix when requested
+- owned-resource retention/release needs and accessible evidence links, including a required matrix unless explicitly requested in full
 - proposed commit message
 
+Omit empty optional sections. A compact return is a navigation aid, not a substitute for the parent's actual-diff review or acceptance checks.
+
 When asked for a commit message, provide a one-line message. If multiple sentence-like clauses are needed, separate them with semicolons. Do not invent a chunk ID; use one only when the prompt or task packet defines it.

plugins/staged-implementation/skills/orchestrator/SKILL.md

@@ -166,9 +166,9 @@ Every implementer prompt must require:
 For contract-heavy chunks, require:
 
 ```text
-Before coding, extract the explicit MUST / invariant / field / response-shape / event / error-mapping requirements into a concrete checklist.
+Before coding, verify an existing applicable checklist against authoritative MUST / invariant / field / response-shape / event / error-mapping requirements. Reuse it when complete; add missing requirements or create a checklist if none is suitable.
-After coding, audit the actual diff against that checklist before finishing.
+After coding, audit the actual diff against those requirements. Shared requirement IDs do not merge implementer and independent-validator findings/evidence; keep each pass attributable and investigate obligations outside the checklist.
-In the final summary, include a contract verification matrix and explicitly confirm no out-of-scope work was included.
+Keep the contract verification matrix in durable evidence and link it in the final summary, with blocking findings, missing evidence and scope deviations visible. Include the full matrix in the response if explicitly requested; verify linked artifacts exist and are accessible.
 ```
 
 Keep the implementer `Read these first:` list focused:
@@ -177,12 +177,17 @@ Keep the implementer `Read these first:` list focused:
 - include relevant feature-plan sections, not unrelated phases/history
 - include the implementation checklist only when it adds chunk-relevant boundaries or state not restated in the prompt
 - include chunk-specific docs/artifacts the implementer actually needs
+- identify the current authoritative reading path, including any still-binding amendments; keep historical evidence accessible without routinely loading superseded narratives. Expand inspection when dependencies or findings require it.
 - do not include the prompt map by default
 - do not include planner/reviewer/orchestrator process docs
 - do not list the prompt file itself in its own `Read these first:` block
 
 ## Delegation Rules
 
+For new implementer and independent-validator assignments, default to fresh scoped context without full parent-history inheritance when supported; explicitly select the supported no-history setting rather than relying on tool defaults. Carry the task, applicable instructions/contracts, candidate identity, source locations, known findings, dependencies, validation obligations and authority. Context selection is separate from model selection: explicitly preserve authorized model/effort through supported controls if changing context mode changes defaults; never silently substitute a configuration for smaller context. If scoped context is unavailable, use supported controls while preserving required independence and obligations. Reuse an appropriate worker for bounded same-assignment corrections; use a fresh worker when independence, persistent misunderstanding or stale context warrants it, not because a fixed context threshold was crossed.
+
+Dispatch complete bounded assignments so workers can finish already-authorized routine steps without acknowledgement chatter. Coordinate candidate release, shared-resource acquisition, scope changes and required approvals explicitly; a completion notification does not release a workspace. Prefer completion notifications or interruptible waits, with proportionate polling when necessary. Preserve required user updates and immediate blocker/material-finding reports; do not add a permanent monitoring loop or wait so long that intervention is prevented.
+
 When spawning an implementer sub-agent:
 
 - start with a fresh sub-agent for each new chunk by default
@@ -191,7 +196,6 @@ When spawning an implementer sub-agent:
 - instruct it to edit files directly if the runtime supports sub-agent code edits
 - instruct it not to commit
 - keep the task narrow and self-contained
-- where supported, use scoped context instead of a full-history fork, carrying all applicable instructions, authority and contract references; preserve model/effort choices
 - assign the verified persistent source workspace and evidence destinations; workers must not relocate implementation into disposable storage
 - pass cleanup scope, retention requirements and disk/allocation restrictions; require workers to report exact owned resource paths and outstanding consumers on handoff
 - avoid delegating planner/reviewer decisions
@@ -216,13 +220,17 @@ Use lightweight provenance sufficient to identify what was tested, such as a sco
 
 ## Review and Validation Effort
 
+Efficiency changes organization and communication, not what must be understood, implemented or proven. Required correctness and acceptance obligations take priority over token savings; do not impose token/turn caps that force incomplete work.
+
 Keep roles distinct: implementer self-audit; parent actual-diff/integration/contract review; validator independent checks of assigned behavior/risks. Do not automatically add a general reviewer for each correction. Reuse a validator for bounded corrections while context remains valid; a changed mechanism, disputed finding, new risk or explicit gate may require a fresh challenge. All mandated independent reviews remain required.
 
 Reuse reliable verification helpers and a canonical candidate-scoped input record where useful; verify their coverage/applicability rather than rebuilding them per worker. Keep prior candidate provenance intact when inputs change, and keep concurrent candidates separate. Create only the smallest missing helper when justified, not a mandatory evidence framework. Before expensive checks, preflight relevant paths, tool versions, generated prerequisites and file-type/symlink handling. Recheck changed or uncertain setup; preflight does not replace behavioral assertions. Validators independently verify inputs and expected outcomes against the frozen contract, not an unexamined helper or previous verdict.
 
-For corrections, put a short impact note in the existing prompt/review: changed behavior/files, affected consumers, reruns and proposed evidence reuse. Reuse only after verifying relevant source, harness, dependencies, build configuration and environment match, preserving original limits. A commit ID alone is insufficient. Rerun if applicability is uncertain; shared owners/styles may affect many consumers. Required fresh checks cannot be skipped.
+For same-contract corrections, reference the original assignment and current candidate, then send the concrete finding, affected scope, required revalidation and proposed evidence reuse. Do not regenerate valid assignments, matrices, environment audits or evidence packages. A replacement worker needs enough baseline context to interpret the delta. Group coherent findings from the current review when practical, but report urgent safety/contract blockers immediately. Reuse only after verifying relevant source, harness, dependencies, build configuration and environment match, preserving original limits. A commit ID alone is insufficient. Rerun if applicability is uncertain; shared owners/styles may affect many consumers. Required fresh checks cannot be skipped.
 
-Use automation for repeatable regression/mechanical checks and browser inspection for relevant visual/focus behavior and discrepancies. Do not automatically repeat the full matrix with every tool. Retain each required case at its assigned evidence layer/gate. Matching builds/evidence satisfy a requirement only when it permits reuse; later platform/device checks remain pending until observed. Never silently rewrite acceptance to avoid a blocker.
+Use targeted searches/relevant sections and programmatic extraction from large logs/JSON; expand to full files or raw evidence when needed. Avoid repeatedly dumping unchanged documents, inventories or successful logs into model context. Store required full logs durably and return concise results with failures, limitations and paths. Capture the underlying operation's exit status, not only a filter/parser's success; distinguish success, failure, timeout, cancellation and unexecuted work. Incomplete output or parser failure must be surfaced and investigated, never treated as a clean pass.
+
+Batch compatible independent reads/mechanical checks and inspect every result together. Preserve individual statuses; tests sharing ports, fixtures, generated files or build destinations remain sequential unless isolation is established. Keep dependent edits, mutations, approvals and decisions sequential. Apply existing candidate-freeze and disk-allocation rules; do not hide failures inside a large command batch. Use browser inspection for relevant visual/focus behavior and discrepancies rather than automatically repeating the full matrix with every tool. Retain every required case at its assigned gate and all mandated fresh checks; local/reused evidence cannot silently pass a later platform gate.
 
 Report concise differences, counts, failures, skipped/not-tested obligations, evidence limits and artifact paths; retain raw logs/artifacts and inspect unexpected output. Link any existing canonical input record and detailed results instead of regenerating/reproducing unchanged inventories, hashes or packages. Apply process improvements prospectively; do not reorganize historical evidence merely to match a new convention. Briefly record causes of recurring setup failures or reasons for repeated checks in the existing report, not a new tracking system. Efficiency does not authorize model changes, missed cases, weaker contracts or unsafe rollback.
 

plugins/staged-implementation/skills/planner/SKILL.md

@@ -120,6 +120,8 @@ Do not create separate prompts just because a second file is touched, a helper i
 
 Give each artifact one job: plan = architecture/rationale; checklist = work/dependencies/acceptance; prompt map = assignment routing/inputs; prompt = bounded execution pass. Link authoritative contracts or restate the exact applicable subset instead of copying whole contracts into every artifact. Preserve all applicable obligations and make them accessible to a fresh worker.
 
+Efficiency changes organization and communication, not what must be understood, implemented or proven. Required correctness and acceptance obligations take priority over token savings; do not impose token/turn caps that force incomplete work.
+
 Design validation alongside chunk boundaries. Assign each obligation to the first gate that needs it: local implementation, integrated behavior, or actual platform/device/release. Record its target and prerequisites. Do not require later release evidence before a local chunk unless correctness or safe activation depends on it. An unavailable mandatory check remains pending at its assigned gate; emulation/local success cannot pass that gate.
 
 Prefer existing tests/harnesses and the smallest validation surface that credibly proves the contract. Plan a cheap setup preflight before expensive validation: working directory/paths, tool versions, generated-input prerequisites and relevant file-type/symlink handling; subsequently recheck changed or uncertain assumptions. Intended test outcomes come from frozen contracts; source establishes implementation facts, not permission to copy a defect into the expected result. Investigate disagreement. Expand for shared-owner impact or newly found risk. Do not prescribe every appearance × viewport × state combination, another harness or another general review without a coverage need. Retain required integration/independent review and any explicitly mandated matrix or fresh run unless expressly amended.
@@ -215,6 +217,7 @@ Keep the implementer `Read these first:` list focused:
 - include relevant feature-plan sections, not unrelated phases/history
 - include the implementation checklist only when it adds chunk-relevant boundaries or state not restated in the prompt
 - include chunk-specific docs/artifacts the implementer actually needs
+- identify the current authoritative reading path, including any still-binding amendments; keep historical evidence accessible without routinely loading superseded narratives. Expand inspection when dependencies or findings require it.
 - do not include the prompt map by default; it is mainly a planner/reviewer sequencing artifact
 - do not include planner/reviewer process docs by default
 - do not list the prompt file itself in its own `Read these first:` block
@@ -252,9 +255,9 @@ Every implementer prompt must carry these default requirements unless the task p
 For contract-heavy chunks, add a contract checklist and self-audit requirement:
 
 ```text
-Before coding, extract the explicit MUST / invariant / field / response-shape / event / error-mapping requirements into a concrete checklist.
+Before coding, verify an existing applicable checklist against authoritative MUST / invariant / field / response-shape / event / error-mapping requirements. Reuse it when complete; add missing requirements or create a checklist if none is suitable.
-After coding, audit the actual diff against that checklist before finishing.
+After coding, audit the actual diff against those requirements. Shared requirement IDs do not merge implementer and independent-validator findings/evidence; keep each pass attributable and investigate obligations outside the checklist.
-In the final summary, include a contract verification matrix and explicitly confirm no out-of-scope work was included.
+Keep the contract verification matrix in durable evidence and link it in the final summary, with blocking findings, missing evidence and scope deviations visible. Include the full matrix in the response if explicitly requested; verify linked artifacts exist and are accessible.
 ```
 
 End implementer prompts by asking for a proposed commit message. When a chunk ID exists, require the commit message to start with that chunk ID prefix.

plugins/staged-implementation/skills/validator/SKILL.md

@@ -52,7 +52,8 @@ Follow the assigned acceptance level: local implementation, integration, or actu
 1. Read context.
    - Read project instructions first.
    - Read the assigned requirements, relevant plan/checklist sections, prompt, findings and changed-surface context; expand when dependencies or applicability are unclear, not to repeat unrelated planning audits.
-   - Identify the exact behavior and contracts to validate.
+   - Independently verify any supplied checklist against authoritative requirements; reuse complete requirement IDs, add omissions or create a checklist only if needed. Check obligations outside it and keep this pass's findings/evidence attributable separately from implementer results.
+   - Use targeted searches/relevant file sections and programmatic extraction from large logs/JSON; expand to full files/raw evidence whenever needed. Do not repeatedly load unchanged inventories, histories or successful logs merely to restate them.
    - Independently verify the candidate's baseline/scoped changes, relevant test/build inputs and build/artifact provenance. Reuse applicable verification helpers and a canonical candidate input record without trusting their scope or a previous verdict unexamined; do not rebuild evidence machinery per worker. Confirm writes to that scope and replacement of the target are held for the pass; do not assume a URL or HEAD alone identifies what is being tested.
 
 2. Create a validation plan.
@@ -67,6 +68,7 @@ Follow the assigned acceptance level: local implementation, integration, or actu
 
 3. Execute validation.
    - Use the real target when runtime behavior matters.
+   - Batch compatible independent checks and inspect every result. Preserve each underlying operation's exit status and distinguish success, failure, timeout, cancellation and unexecuted work. Tests sharing ports, fixtures, generated files or build destinations stay sequential unless isolated; preserve candidate-freeze and allocation rules. A filter/parser's success or absence of error text is not proof of execution success. Surface incomplete output/parser failures and inspect relevant raw evidence.
    - For UI validation, check visible state, relevant interactions, console output, and network/API requests.
    - For API validation, check status codes, response shape, error codes, auth behavior, and persistence side effects as specified.
    - For build/test validation, run the narrowest commands that cover the risk.
@@ -88,7 +90,9 @@ Follow the assigned acceptance level: local implementation, integration, or actu
    - Do not claim acceptance beyond what was validated.
    - Release owned runtime resources as authorized and hand off retained/disposable paths with reasons. Confirm required evidence remains accessible at its recorded durable location before its temporary workspace is removed; preserve failure identity and pending-gate/recovery needs.
 
-For a correction/revalidation, independently verify the change's impact and reuse only permitted evidence whose relevant source, harness, dependencies, build configuration and environment still match. Do not trust the implementer's PASS alone. Rerun affected checks, new failure cases and explicitly required fresh checks; rerun when applicability is uncertain. Preserve original failed evidence and avoid recreating unchanged reports/galleries. Shared-owner changes may require broader coverage.
+For a correction/revalidation, verify the original assignment/current candidate and independently assess the delta; reuse only permitted evidence whose relevant source, harness, dependencies, build configuration and environment still match. Do not trust the implementer's PASS alone. Rerun affected checks, new failure cases and explicitly required fresh checks; rerun when applicability is uncertain. Preserve original failed evidence without recreating valid matrices, setup audits or report packages. Shared-owner changes may require broader coverage.
+
+Complete assigned routine checks without repeated parent acknowledgements; promptly report blockers/material findings and coordinate candidate release, shared resources, scope changes and approvals. A completion notice does not release a workspace. Preserve required user updates. Correctness and acceptance obligations take priority over token savings.
 
 ## Browser/UI Validation
 
@@ -146,31 +150,33 @@ When invoked after implementation:
 
 ## Final Response Shape
 
-Use this structure:
+Use this compact structure, omitting empty optional sections. Keep blocking findings, missing evidence and resource disposition visible; link detailed matrices/results unless explicitly requested in full. Verify links exist and are accessible. This report supports parent review; it does not replace actual-diff review or acceptance.
 
 ```text
 Verdict:
 - pass | fail | blocked | partial
 
+Candidate:
+- baseline/scoped changes and relevant build identity
+
 Validated:
-- item: result, evidence
+- fresh/reused results and evidence links
 
 Not validated:
-- item: reason
+- missing/failed-to-run obligations and reasons
 
 Evidence:
-- commands/tools used
+- accessible detailed results, matrices and relevant logs/captures
-- screenshots/logs/network observations where relevant
 
 Failures:
-- what failed
+- what/where, consequence and whether the contract is clear enough to fix
-- where it failed
-- why it matters
-- whether the expected behavior is clear enough to fix without guessing
 
 Residual risk:
 - remaining risk or coverage gaps
 
+Resources:
+- owned paths/consumers and retention or release needs
+
 Recommendation:
 - accept | follow-up prompt needed | clarify contract | rerun with missing dependency
 ```