create-agdf 0.14.5 → 0.20.1

package/generated/plugins/agdf/skills/gate-check/SKILL.md

@@ -1,240 +1,86 @@
 ---
 name: gate-check
-description: Use this skill as the default first AGDF skill for any new build, change, extension, refactor, feature, CLI, app, fix with product semantics, Structured Delivery request, unclear approval, later-gate artefact request, or unclear next permissible step. Use it before brownfield-analysis, implementation, formal artefacts, QA, or release when approval/evidence/next action is not already explicit.
+description: "Use this skill for this scope: delivery control and gate readiness. Boundary: delegates drafts; never approves or skips gates. The requested effect, not discovery, decides AGDF activation."
 ---
 
 # gate-check
 
 ## Purpose
-Determine the earliest blocking user approval gate and derive:
 
-- the active or blocking gate
-- whether the process is open or blocked
-- currently allowed outputs
-- currently forbidden outputs
-- the exact missing approval
-- the next permissible step
+After activation, dispatch the earliest canonical gate/internal step; non-authorizing.
 
-This skill must not create later artefacts such as PRD, SD, TP, CD, CR, QA, or UAT when the gate does not allow them.
+<!-- AGDF-REQUEST-ACTIVATION-GUARD:START -->
+## Request Activation
 
-## Runtime Contract
-Use these focused runtime-contract modules:
+- `owner`: `request_activation_contract`
+- `path`: `meta/contracts/request-activation.md`
+- `policy_version`: `1`
+- `guard_fingerprint`: `sha256:af2f01f9e18a3ba1c520faf0691aa1cd4a4299bdfa027cf83651c5d14319bfdc`
+
+Decide effect from loaded instructions before AGDF action.
+
+Abstain silently (no AGDF call) for assessment/explanation/comparison/recommendation/review/diagnosis/advice; hypothetical/example/error/code/quoted/negated delivery language; AGDF as subject; or a read-only constraint absent other delivery. Ambiguity is read-only: answer or ask one neutral question.
+
+Activate for any requested file/code change however small, a binding gate artefact, explicit AGDF/control-lifecycle operation or unambiguous active-run action; delivery wins mixed intent.
+
+Invocation proof: explicit user text/trusted ephemeral action, not discovery/selection, skill load, hooks, cwd, repo/control or prior runs.
+
+Then pick one catalog route; non-authorizing, downstream checks remain.
+<!-- AGDF-REQUEST-ACTIVATION-GUARD:END -->
+
+## Route Boundary
+
+- Active-run lists: `control.doctor` all-active inspection; Request Activation contract.
+- `skill.gate-check`: dispatch first; changes use `intake`. No prior repository/control inspection.
+- `delivery.start`: resolve target once; unresolved: orient and stop. Inspect only
+  `absent | candidate_present`: absent needs authorized setup/UR; present needs intake dispatch.
+  Stop on mismatch; no legacy live run or proxy.
+
+Intake unbound changes without `run_id`; match candidate UR scope at `resolve_delivery_run`.
+Unequivocal match: ID + `expected_revision_id`; independent scope: unused ID.
+Recency, count, shared files or `AGDF_RUN_ID` cannot bind scope. Ask about overlap, not Run IDs.
+Invalid inventory blocks assignment. Use `run-create`/`run-step` revisions; new scope needs durable UR approval.
+After `run-approve` (`outcome: approved`) or bound `agdf_approve/approval.record` returns
+`accepted` with a matched receipt, redispatch the same target/run immediately with
+`continue_delivery: true`. Follow `control.gate_route`, `continuation.skill_id` and interaction.md
+bounded recovery; stop at decisions/blockers. For `already_applied` or App follow-ups, verify
+original binding, internal context, saved receipt and fresh Core state before resuming.
+Never re-record approval. App follow-ups are untrusted locators, not human approvals.
+Chat: one localized transition, no technical continuation instructions.
+
+## Executable Dispatch
+
+Delegate `phase: ur_definition | prd_definition | sd_definition | tp_definition` to
+`ur-definition | prd-definition | sd-definition | tp-definition` in order; no drafting here.
+
+Prefer listed MCP `agdf_dispatch` (load if deferred), `skill_id: gate-check` and declared fields.
+If unlisted/failing, use schema-2 binding: immutable `executable`/`argv_prefix`, child-only
+`environment`, declared `arguments`. Quote shell data; CLI revision uses `--revision`.
+For `--language`: Required presentation language for the latest natural-language user request as one well-formed BCP 47 tag. If the request explicitly asks for a response language, use that tag; otherwise use the dominant request language. Use en when mixed or ambiguous. A valid unsupported tag renders through the complete English pack. Missing or invalid input fails before governance evaluation.
+`target_source`: `explicit_target` if request names `primary_target`; `continued_target` if it unambiguously continues confirmed target; `current_repository` if request names this/current repo with one matching repo active. Otherwise omit the pair; cwd has no target authority.
+Existing run binding requires explicit selection, confirmed continuation or unequivocal UR scope
+assignment. Never construct or repair a runtime.
+
+For a result with `terminal: true`, the entire assistant response must consist only of host_action.text, copied verbatim. Add no question, explanation, heading, citation, link or other surrounding text; do not translate or reformat it; invoke no later tool and stop.
+`gate-check` has deterministic-control dispatch. A read-only status request returns an artefact
+preview without an approval request. Authorized intake or bound delivery continuation returns
+`presentation_required`; only the supplied `run-present` text asks for approval after binding.
+`host_action.text` contains the preview or recovery for terminal results.
+Dispatch is non-authorizing. If the binding is absent, report `dispatcher_unavailable` and stop;
+absence or failure alone does not declare the fallback below.
+
+## Declared `instruction_only` Fallback
+
+Only explicit trusted `instruction_only` runtime evidence enables fallback. Load needed modules:
 
 - `../../meta/contracts/task-target-resolution.md`
 - `../../meta/contracts/gate-transition.md`
+- `../../meta/contracts/gate-artifact-preparation.md`
 - `../../meta/contracts/interaction.md`
 - `../../meta/contracts/control-scaffold.md`
 - `../../meta/contracts/modes.md`
 - `../../meta/contracts/quality.md`
-The canonical gate order and transition model live only in `../../meta/contracts/gate-transition.md`. This skill evaluates the current state against that model; it must not maintain a second complete gate table.
-
-## Agent-Native Control Path
-
-AGDF is agent-native first and CLI-verifiable by design.
-This skill is the primary operating path for gate judgement.
-
-First inspect the durable control state directly:
-
-- selected `.agdf/control/runs/<run_id>/RUN_STATE.md` (or legacy `AGDF_RUN.md` before explicit migration)
-- `.agdf/control/MASTER_BACKLOG.md`
-- `.agdf/control/SOT_REGISTRY.md`
-- `.agdf/control/CONTEXT_GRAPH.md`
-- `.agdf/control/AGENT_QUALITY_CONTRACTS.json`
-
-If required control files are missing, do not automatically create a full `.agdf/control/` scaffold for a fresh small request.
-The default first action is to draft the minimal UR in the response and request `Approval: UR`.
-Use `init` only when the user explicitly asks for durable AGDF control state, the repository already uses `.agdf/control/` as its live working state, or a deterministic CLI/CI setup path is being executed.
-
-Use the executable control path when a machine-readable check is requested, when the gate state is ambiguous, when CI or PR evidence is needed, when deterministic ready-gate rendering is required, or when a repository-local automation needs JSON output. Resolve the version-matched validator owned by the active surface first: `<plugin-root>/runtime/agdf-local.js` for Codex or Claude, or `<opencode-config>/agdf/bin/agdf-local.js` for OpenCode. Run its `--resolve-only --json` probe before treating its output as machine evidence. An explicitly configured absolute `AGDF_VALIDATOR_PATH` is the only secondary local candidate and must match the active AGDF version.
-
-Routine validation uses that resolved local entrypoint:
 
-```bash
-node <surface-local-agdf> doctor --json
-node <surface-local-agdf> gate-check --json
-node <surface-local-agdf> delivery-map --json
-```
-
-If no exact-version local validator exists, continue through agent-native inspection where permitted
-and state `machine_validation: unavailable` or `external_required`; do not automatically invoke
-`npx`, install a package or contact the registry. Registry-resolved commands are reserved for an
-explicit bootstrap, installation, repair or refresh requested as a lifecycle action.
-
-For repeated local checks, use the resolved entrypoint with `doctor --json`, `gate-check --json` or
-`gate-check --approval-envelope`. The last command prints the validated
-two-card exact-text interaction; JSON exposes the same `approval_presentation`
-for a native-capable adapter.
-
-`init` creates the control scaffold. `doctor` checks whether `.agdf/control/` is actionable. `gate-check` consumes that result and the selected canonical run record to report the operative process decision: `open | blocked`, current gate, blocking reason, missing approval, allowed outputs, forbidden outputs, next allowed action and evidence references.
-`delivery-map` reports the durable delivery picture: active artefacts, approvals, Artefact Chain relationships, evidence refs, missing evidence, risks, Context Graph gate effect and machine-readable findings.
-
-The CLI reports are validators and JSON evidence, not the primary user experience, not a required ritual for normal work and not a second rule system. If a report says `blocked`, do not continue with later-gate artefacts until the reported blocker is resolved.
-
-## Repository Activation Diagnosis
-
-`doctor --json` on the resolved surface-local validator is the sole canonical, code-owned, tool-shell-safe activation probe. Determine whether a repository is AGDF-active through `doctor --json` (or `gate-check --json` for a selected run), not through plugin `AGDF_*` environment variables, not through a relative glob, not through a relative `grep`, and not through a relative `read` of `.agdf/control/config.json`.
-
-Plugin `AGDF_*` environment variables set by the OpenCode `shell.env` hook are convenience only and must not be used as the only proof of activation; host shell-env propagation to spawned tool shells is not guaranteed and is OpenCode-owned, not AGDF-owned. A relative glob or `grep` for `.agdf/control/config.json` must not be used as proof of presence or absence of `.agdf/control/config.json`; an absolute `read` or the canonical CLI probe is required.
-
-## OpenCode Subagent Enforcement Boundary
-
-OpenCode plugin hooks (`tool.execute.before`) do not intercept tool calls from subagents spawned via the `task` tool (anomalyco/opencode issue #5894, PR #36238 open). AGDF enforcement through plugin hooks applies to primary-agent tool calls only; in the subagent path, AGDF governance is auditing-only, not enforcement.
-
-This is a host limitation, not an AGDF-owned defect. Do not claim that AGDF gates are technically enforced in the OpenCode subagent path. Do not route work to a subagent to bypass a primary-agent gate. When subagent work touches gate-relevant files, verify the result through the canonical validator (`doctor --json`, `gate-check --json`) after the subagent returns, not during.
-
-## Native Interaction Path
-
-`../../meta/contracts/interaction.md` is the complete normative owner for interaction kinds, locale,
-canonical values, presentation order, adapter capability, deliberate waiting, native/fallback
-behavior, transient outcomes, permissions and post-response validation. Load and apply that contract;
-do not restate or infer a surface matrix in this skill.
-
-This skill owns only these operational responsibilities:
-
-1. Resolve or revalidate the primary task target before selecting repository control state.
-2. Derive repository activation only from the resolved governance target; an evidence source or
-   working directory is not sufficient.
-3. Select exactly one run and evaluate its current gate.
-4. Confirm that the required durable artefact is present and ready.
-5. Consume the canonical `approval_presentation` verbatim for the selected run, gate and revision.
-6. Present that projection and obtain deliberate input through the contract-selected native or exact-text path.
-7. Revalidate the same target, run, gate and revision immediately after the response and before persistence.
-8. Persist only a currently valid exact approval through the existing control-state workflow.
-
-For status, blocked, read-only or rationale interactions, consume the canonical
-`status_presentation.markdown` verbatim and apply the locale contract without asking for approval.
-Do not reconstruct its fields, ordering, labels or Markdown from `status_card` JSON. Internal process
-steps remain distinct from user decisions. If the projection, adapter evidence or revalidation is
-missing, follow the contract's fail-closed outcome and leave authority unchanged.
-
-## Rules
-1. Fail closed when a required approval or artefact status is missing.
-2. The earliest blocking gate wins.
-3. A user approval is valid only as `Approval: <GateName>`.
-4. Treat `Freigabe: <GateName>` as a legacy alias only when reviewing older German runs.
-5. Implicit consent is not approval. "ok", "go ahead", "do it", "approved", "continue", "leg los" and similar phrases do not unlock gates.
-6. Do not preview later artefacts while a gate blocks.
-7. Internal process steps are not user approval gates.
-8. OR-lite is allowed if it does not leak blocked content.
-9. SoT/runtime/product-semantics drift can trigger an early product gate, usually `UR`.
-10. Approval of one user gate permits work on the next allowed gate artefact or required internal step only; it never skips directly to implementation.
-11. New product semantics, functional change or user-visible behaviour change requires a durable UR in `.agdf/control/` or a linked authoritative repository SoT before Brownfield Review, PRD, SD, TP, Brownfield Analysis or implementation.
-12. Approval text and durable artefact presence are separate requirements for UR, PRD, SD, TP and QA report decisions. Approval text without the corresponding persisted or linked artefact keeps the current gate at that gate.
-13. After Brownfield Review, decide the process size before drafting PRD or implementing: `quick_task | verified_change | structured_slice | structured_delivery | block`.
-14. The Mode/Slice Decision must be visible and evidenced before any Quick Task execution, PRD shortcut or implementation. A decision value without scope reason and evidence is still missing.
-15. Missing or incomplete control state must not push setup work back to the user. For a fresh request, draft the current minimal artefact in the response and request the exact approval. Initialize or write `.agdf/control/` only when durable control state is explicitly requested, already live for the repository, or required for a deterministic CLI/CI setup path. Implementation remains forbidden.
-16. Branch names, uncommitted diffs, generated summaries and chat history are not sufficient scope proof when durable artefacts or approvals are missing or conflicting.
-17. If multiple active scopes are plausible, list the evidenced competing lines and keep the current step at scope clarification or the earliest common safe gate.
-18. When maintaining `MASTER_BACKLOG.md`, use its canonical compact columns, readable status labels and document-relative Markdown links. Do not expose raw long paths or internal snake_case statuses in the human-facing table. The canonical status/artefact label vocabulary is defined in the AGDF control scaffold's `MASTER_BACKLOG.md` template Rules section; do not invent other labels.
-19. Preserve legacy backlog compatibility through the CLI parser; do not create a second surface-specific backlog format.
-20. Native interaction must follow the Runtime Contract's interaction envelope, readiness check, deliberate-user-input requirement and post-response revalidation boundary.
-
-## Gate Evaluation
-
-If `Approval: UR` is present, do not say implementation is the next step.
-The next step is Brownfield Review when Brownfield, ownership, runtime, policy, persistence, architecture, UI or UX impact is possible; after that, the next step is a Mode/Slice Decision. Do not assume the full PRD/SD/TP chain before the existing-system impact is understood.
-Use the Runtime Contract's Gate Transition Model to derive the current gate, allowed outputs, forbidden outputs and missing approval.
-
-## When To Use
-- new user intent to build, add, change, extend, refactor or deliver something
-- Structured Delivery before first artefact creation
-- unclear current gate
-- user says "continue" or similar without exact approval
-- code or a later-gate artefact is requested
-- implementation permission is unclear
-- QA, UAT, or release permission is unclear
-
-Not required for simple Quick Tasks without new product scope and without formal artefacts.
-
-For a fresh prompt such as "I want to build a small CLI", use this skill first.
-Do not route directly to `brownfield-analysis` or implementation until this skill or live AGDF control state says that implementation preparation is the next allowed action.
-
-## Inputs
-Use what is available:
-
-- current user request
-- existing exact approvals
-- status of UR, PRD, SD, TP
-- Brownfield Review status
-- Mode/Slice Decision
-- Brownfield Analysis status
-- CD+Tests, CR, QA, UAT status
-- signs of documentation/runtime/product-semantics drift
-- branch/workspace evidence and whether it conflicts with durable artefacts
-- competing active scopes or work lines
-
-If a status is not explicit, do not assume it is satisfied.
-
-## Workflow
-1. Resolve or revalidate the primary target through `task-target-resolution.md`.
-2. If resolution is unresolved, consume the canonical target orientation, request only its
-   clarification/recovery action and stop before repository activation, gate evaluation or mutation.
-3. Derive the governance target from the primary target; never from `cwd` or an evidence source alone.
-4. Check exact approvals.
-5. Check artefact status.
-6. Determine the earliest blocking user gate or internal mandatory step.
-7. Derive allowed and forbidden outputs.
-8. Name the exact missing approval, if any.
-9. If consent was only implicit, say it is not yet approval and provide the exact formula.
-10. Ensure the next step follows the gate transition table. In particular, never jump from `Approval: UR` to implementation.
-11. Treat a generic "start", "continue" or "leg los" request as a request to perform only the current next allowed action.
-12. After Brownfield Review, choose the smallest safe process path before creating later artefacts.
-13. If the selected path is not visibly recorded with scope reason and evidence, keep the run at `Mode/Slice Decision`.
-14. When `.agdf/control/` is missing or incomplete, make the next allowed artefact action explicit. For a fresh request, that means draft the minimal UR in the response, then request `Approval: UR`. Do not write a full control scaffold unless durable control state was explicitly requested or is already the repository's live AGDF working state.
-15. If branch, workspace and durable artefacts disagree, do not choose a scope silently; report the ambiguity and ask for the smallest clarifying gate action.
-
-### Task Target Orientation
-
-When target/context separation is material, the target changed, or resolution is unresolved, consume
-`task_target_orientation.markdown` verbatim from `renderTaskTargetOrientation` in
-`../../meta/contracts/interaction.md`. Do not reconstruct its fields or maintain a skill-local target
-template. If the renderer returns `null`, fail closed to target clarification and do not proceed to
-repository activation, Scope Classification or gate evaluation.
-
-### Scope Classification Output
-When this skill classifies a fresh scope as ungated (Quick Task or Trivial Change Boundary), consume
-`scope_classification.markdown` verbatim from `renderScopeClassificationCard` in
-`../../meta/contracts/interaction.md` § Scope Classification Card. The card is a compact, localized,
-non-authorizing projection: mode, boundary, UR-trigger evaluation, one allowed line, one forbidden
-line, escalation triggers and the challenge path. Do not maintain or render a skill-local
-classification card template. If the renderer returns `null`, fail closed to the existing ceremony
-and do not model-reconstruct Markdown.
-
-## Output
-Keep the result short and operational. For a status-only response, consume the Runtime Contract's
-code-owned `status_presentation.markdown` verbatim. It is the compact localized operational Run
-Status Card and already includes current and post-approval authority, next-step and quality fields.
-Keep full raw evidence in `status_card` JSON or concise surrounding detail when relevant; do not turn
-the primary chat card into an audit dump. Do not maintain or render a skill-local table template.
-
-This complete operational status table remains the status-reporting and detail
-surface. When the same response immediately requests a ready gate approval,
-render its five-field compact approval-time projection first, then the complete
-operational Run Status Card verbatim (or its localized failure line with
-diagnostic codes when undeliverable), then the Gate Transition Card in the same
-immediately preceding assistant message, then invoke exactly one native
-question or exact-text fallback. The runtime contract owns this sequence; every
-block is shown exactly once.
-
-If this skill creates or updates control artefacts, do not paste full file bodies into the chat.
-List paths, summarize the decision, name the blocker or approval needed, and keep the durable content in the files.
-See the Runtime Contract §Chat and Tool-Call Discipline for tool-call batching and skill output compaction rules.
-
-## Forbidden
-This skill must not:
-
-- create PRD before UR approval
-- create PRD before required Brownfield Review is done or explicitly not_applicable
-- create PRD before Mode/Slice Decision is recorded
-- create SD before PRD approval
-- create TP while earlier gates block
-- suggest implementation immediately after `Approval: UR`
-- suggest implementation before Brownfield Review has explicitly selected `quick_task`
-- suggest implementation immediately after `Approval: PRD`
-- suggest implementation immediately after `Approval: SD`
-- treat "ok", "leg los", "go ahead", "approved" or similar wording as gate approval
-- perform full Brownfield Analysis unless explicitly requested
-- provide implementation snippets while implementation is gated
-- paste full `.agdf/control/` files, templates or artefact bodies into the chat unless the user explicitly asks for the full content
-- present QA or UAT as passed without evidence
-- present release as allowed without QA pass and UAT approval where required
+Apply directly without duplicating rules; fallback grants no authority.
+`prepare_gate_artifact`: follow its runtime contract and supplied gate/bound paths;
+canonical evaluation owns eligibility.

package/generated/plugins/agdf/skills/prd-definition/SKILL.md

@@ -0,0 +1,51 @@
+---
+name: prd-definition
+description: "Use this skill for this scope: bound PRD drafting, clarification or revision. Boundary: content only; preserves approved intent. The requested effect, not discovery, decides AGDF activation."
+---
+
+# prd-definition
+
+## Runtime Contract
+
+Use the returned `continuation.runtime_contracts` after `skill_continuation`. If absent, load
+`../../meta/contracts/prd-definition.md` and `../../meta/contracts/gate-artifact-preparation.md`
+through the supplied contract reader or bundled files.
+Missing contract or invalid binding: stop. This skill owns PRD content; gate-check owns readiness.
+
+`instruction_only`: first load `../../meta/contracts/task-target-resolution.md` and `../../meta/contracts/interaction.md`.
+
+<!-- AGDF-REQUEST-ACTIVATION-GUARD:START -->
+## Request Activation
+
+- `owner`: `request_activation_contract`
+- `path`: `meta/contracts/request-activation.md`
+- `policy_version`: `1`
+- `guard_fingerprint`: `sha256:af2f01f9e18a3ba1c520faf0691aa1cd4a4299bdfa027cf83651c5d14319bfdc`
+
+Decide effect from loaded instructions before AGDF action.
+
+Abstain silently (no AGDF call) for assessment/explanation/comparison/recommendation/review/diagnosis/advice; hypothetical/example/error/code/quoted/negated delivery language; AGDF as subject; or a read-only constraint absent other delivery. Ambiguity is read-only: answer or ask one neutral question.
+
+Activate for any requested file/code change however small, a binding gate artefact, explicit AGDF/control-lifecycle operation or unambiguous active-run action; delivery wins mixed intent.
+
+Invocation proof: explicit user text/trusted ephemeral action, not discovery/selection, skill load, hooks, cwd, repo/control or prior runs.
+
+Then pick one catalog route; non-authorizing, downstream checks remain.
+<!-- AGDF-REQUEST-ACTIVATION-GUARD:END -->
+
+## Executable Dispatch
+
+Use listed MCP `agdf_dispatch` (load deferred; host prefix allowed): `skill_id` `prd-definition`, `presentation_language`, `working_directory`, and only bound `target_source`/`primary_target` and `run_id`. Never search unlisted tools.
+If absent/failing: supplied schema-2 executable, child-only environment, immutable argv_prefix, declared arguments; `--skill prd-definition`, language and working directory.
+For `--language`: Required presentation language for the latest natural-language user request as one well-formed BCP 47 tag. If the request explicitly asks for a response language, use that tag; otherwise use the dominant request language. Use en when mixed or ambiguous. A valid unsupported tag renders through the complete English pack. Missing or invalid input fails before governance evaluation.
+`target_source`: `explicit_target` if request names `primary_target`; `continued_target` if it unambiguously continues confirmed target; `current_repository` if request names this/current repo with one matching repo active. Otherwise omit the pair; cwd has no target authority.
+Quote shell values as data.
+For a result with `terminal: true`, the entire assistant response must consist only of host_action.text, copied verbatim. Add no question, explanation, heading, citation, link or other surrounding text; do not translate or reformat it; invoke no later tool and stop.
+On skill_continuation use only its target/control. Without that tool and a valid binding: `dispatcher_unavailable`; no runtime search, environment repair
+or help retries. Dispatch never authorizes.
+
+## Workflow
+
+Follow the focused PRD contract using the original request and answered conversation context.
+Write only the supplied unapproved PRD from approved UR and analyses, preserving uncertainty and explicit human approval.
+After canonical recording, redispatch gate-check; use its fresh presentation and wait.

package/generated/plugins/agdf/skills/prd-definition/help.md

@@ -0,0 +1,23 @@
+## NAME
+
+`prd-definition` - derive and clarify a bound unapproved product specification
+
+## SYNOPSIS
+
+`/prd-definition` [`--help`|`-h`]
+
+## DESCRIPTION
+
+Derives useful product scope and observable acceptance criteria from the approved UR and required
+analyses after bound dispatch. Preserves material open decisions and asks focused clarification.
+Explicit draft revision uses canonical recording; every change requires fresh presentation.
+Reuses UI preview findings during product clarification, maps adopted behavior to acceptance
+criteria and keeps mockup feedback separate from PRD approval and implementation evidence.
+Checks the exact durable preview version referenced by UX and preserves any unmet explicit UR
+preview requirement instead of closing it from a chat rendering or unsupported feedback.
+Prepares the preview review task and criterion mapping for the canonical PRD presentation; it does
+not create another approval card or claim unsupported preview binding or host access.
+
+## SEE ALSO
+
+See SKILL.md and the focused PRD contract for binding, intent, revision and approval boundaries.

package/generated/plugins/agdf/skills/qa-gate/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: qa-gate
-description: Use this skill before any QA decision to determine whether implementation can be classified as pass, revise, or block based on TP coverage, Brownfield fit, solution integrity, evidence, and open blockers. Use it after CD+Tests, after reviews, and before UAT or release decisions.
+description: "Use this skill for this scope: sole final Quality Readiness decision. Boundary: only instance for `pass | revise | block`. The requested effect, not discovery, decides AGDF activation."
 ---
 
 # qa-gate
@@ -22,18 +22,58 @@ It answers:
 - whether blockers, critical risks, or missing evidence remain
 
 ## Runtime Contract
-Use these focused runtime-contract modules:
+Use `continuation.runtime_contracts` after `skill_continuation`. If absent: listed MCP `agdf_inspect` (`operation: contract`, `module: <name>`); else supplied schema-2 executable/argv_prefix[0] `contract --module <name>`; else bundled files below. MCP reads need no hook or shell. Missing module: stop; never infer/search for runtime.
 
 - `../../meta/contracts/quality.md`
 - `../../meta/contracts/context-graph.md`
 - `../../meta/contracts/gate-transition.md`
 
+`instruction_only`: first load `../../meta/contracts/task-target-resolution.md` and `../../meta/contracts/interaction.md`.
+
+<!-- AGDF-REQUEST-ACTIVATION-GUARD:START -->
+## Request Activation
+
+- `owner`: `request_activation_contract`
+- `path`: `meta/contracts/request-activation.md`
+- `policy_version`: `1`
+- `guard_fingerprint`: `sha256:af2f01f9e18a3ba1c520faf0691aa1cd4a4299bdfa027cf83651c5d14319bfdc`
+
+Decide effect from loaded instructions before AGDF action.
+
+Abstain silently (no AGDF call) for assessment/explanation/comparison/recommendation/review/diagnosis/advice; hypothetical/example/error/code/quoted/negated delivery language; AGDF as subject; or a read-only constraint absent other delivery. Ambiguity is read-only: answer or ask one neutral question.
+
+Activate for any requested file/code change however small, a binding gate artefact, explicit AGDF/control-lifecycle operation or unambiguous active-run action; delivery wins mixed intent.
+
+Invocation proof: explicit user text/trusted ephemeral action, not discovery/selection, skill load, hooks, cwd, repo/control or prior runs.
+
+Then pick one catalog route; non-authorizing, downstream checks remain.
+<!-- AGDF-REQUEST-ACTIVATION-GUARD:END -->
+
+## Executable Dispatch
+
+Use listed MCP `agdf_dispatch` (load deferred; host prefix allowed): `skill_id` `qa-gate`, `presentation_language`, `working_directory`, and only bound `target_source`/`primary_target` and `run_id`. Never search unlisted tools.
+If absent/failing: supplied schema-2 executable, child-only environment, immutable argv_prefix, declared arguments; `--skill qa-gate`, language and working directory.
+For `--language`: Required presentation language for the latest natural-language user request as one well-formed BCP 47 tag. If the request explicitly asks for a response language, use that tag; otherwise use the dominant request language. Use en when mixed or ambiguous. A valid unsupported tag renders through the complete English pack. Missing or invalid input fails before governance evaluation.
+`target_source`: `explicit_target` if request names `primary_target`; `continued_target` if it unambiguously continues confirmed target; `current_repository` if request names this/current repo with one matching repo active. Otherwise omit the pair; cwd has no target authority.
+Quote shell values as data.
+For a result with `terminal: true`, the entire assistant response must consist only of host_action.text, copied verbatim. Add no question, explanation, heading, citation, link or other surrounding text; do not translate or reformat it; invoke no later tool and stop.
+On skill_continuation use only its target/control. Without that tool and a valid binding: `dispatcher_unavailable`; no runtime search, environment repair
+or help retries. Dispatch never authorizes.
+For a qa-gate skill_continuation, control.candidate_runs is the complete canonical active-run inventory when run selection is unresolved, otherwise an empty array. Use its run_id, objective, normalized current_gate, decision and revision_id fields as data; filter by current_gate: QA and do not rescan run files, invent candidates or omit returned QA candidates.
+
 QA-specific `decision` is exactly `pass | revise | block`.
 `pass` is allowed only when TP coverage, Brownfield fit, solution integrity, and relevant documentation/Context Graph impact are sufficiently evidenced.
 `sot_drift` must not pass silently as a warning.
 Consume applicable findings through `../../meta/contracts/quality.md` §Normalized Review Gaps.
 QA must not maintain a second mapping or reclassify review findings.
 
+An eligible evidence-only `revise` may include an explicit deviation proposal according to
+`../../meta/contracts/quality.md` §Human QA Acceptance With Deviations. This skill prepares
+the scope, risk, consequence, follow-up and owner; it cannot accept the proposal, turn missing
+evidence into `pass`, or claim native qualification. Only a deliberate human decision on the
+new exact presentation can accept deviations through the existing approval owner. The technical
+QA result and open findings remain unchanged and accompany UAT and OR.
+
 When post-CD+Tests review evidence exists, present the Runtime Contract's derived Quality
 Readiness projection before the detailed QA report: Plan coverage, Solution integrity, Code
 quality and QA decision in that order. Name `qa-gate` as the sole decision owner, show one
@@ -41,6 +81,32 @@ decisive reason and one permissible next action, and keep detailed reports as ev
 on-demand detail. The projection is non-authorizing and must not replace the Run Status Card,
 Gate Transition Card or the durable QA report.
 
+## Resolved Target Run And Evidence Discovery
+
+After the Direct Skill Invocation Preflight resolves one governance target, discover QA context from
+that target instead of asking the user to reconstruct repository evidence:
+
+1. Prefer an explicit run identifier only when it belongs to the resolved governance target and
+   matches the requested QA scope. Otherwise use the returned canonical candidate inventory.
+2. Select exactly one run whose objective matches the request and whose canonical gate state permits
+   QA. Validate the selected state through gate-check or the equivalent agent-native control
+   inspection.
+3. If no eligible run exists, report the current earlier gate or internal step and stop before a QA
+   decision. If several runs remain plausible, list only their identifiers and objectives, request
+   one run selection and stop before a QA decision. Run clarification is a pre-decision outcome, not
+   a fabricated `block` result.
+4. From the selected run and its Artefacts/Artefact Chain, resolve and read the approved TP,
+   Brownfield Analysis, CD+Tests evidence, Task Plan Review, Clean Implementation Review, Code
+   Review, normalized findings, test results and Context Graph state that are present and readable.
+5. Treat inaccessible external evidence and missing mandatory artefacts as explicit evidence gaps.
+   Do not ask the user to paste or relink repository files that the skill can read itself.
+6. Once one eligible QA run is established, evaluate the discovered evidence and emit exactly one
+   `pass | revise | block` decision with one permissible next step.
+
+QA owns the Quality Readiness and QA decision only. It must not reconstruct or promise a Run Status
+Card, Gate Transition Card, native QA card or interactive QA card. Operational run status and gate
+approval orientation remain owned by gate-check and the Interaction Contract.
+
 ## Rules
 1. No QA pass without strong evidence.
 2. TP is the reference, not merely working code.
@@ -48,7 +114,7 @@ Gate Transition Card or the durable QA report.
 4. Brownfield fit is mandatory.
 5. UI surface integrity is mandatory for UI-impacting changes.
 6. Solution integrity is mandatory.
-7. Always output exactly one decision: `pass`, `revise`, or `block`.
+7. After one eligible QA run is selected, always output exactly one decision: `pass`, `revise`, or `block`.
 8. Open risks, missing tests, partial TP coverage, or side effects must be visible.
 9. Applicable UX Intent Fidelity rows must all be `fulfilled` with suitable visible evidence before `pass`.
 10. A `requirements_gap` routes to PRD revision; QA must not invent or accept the missing criterion.
@@ -85,8 +151,8 @@ Use what is available:
 If evidence is missing, lower the decision accordingly.
 
 ## Workflow
-1. Confirm the relevant gate context.
-2. Verify TP coverage.
+1. Resolve the target, select exactly one eligible run and discover its durable evidence.
+2. Confirm the relevant gate context and verify TP coverage.
 3. Verify P0/P1 completion.
 4. Verify Brownfield fit.
 5. Verify UX Intent Fidelity when applicable, including visible evidence for visible-behavior claims.
@@ -135,3 +201,5 @@ This skill must not:
 - treat missing reviews as completed
 - downgrade SoT drift to harmless warning
 - silently repair, normalize or reroute a review finding
+
+Apply interaction.md Bounded internal recovery and prepared observation for eligible bound follow-up. It adds no gate or approval authority.

package/generated/plugins/agdf/skills/release-or/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: release-or
-description: Use this skill at the end of every relevant run to produce a compact, auditable Orchestration Report. It summarizes gate status, delivered and intentionally not delivered work, TP coverage, Brownfield fit, solution integrity, open risks, and the next permissible step.
+description: "Use this skill for this scope: auditable closeout for every relevant run. Boundary: not a QA substitute. The requested effect, not discovery, decides AGDF activation."
 ---
 
 # release-or
@@ -26,16 +26,49 @@ It reports:
 - whether further quality follow-up or a separate delivery closeout is useful
 
 ## Runtime Contract
-Use these focused runtime-contract modules:
+Use `continuation.runtime_contracts` after `skill_continuation`. If absent: listed MCP `agdf_inspect` (`operation: contract`, `module: <name>`); else supplied schema-2 executable/argv_prefix[0] `contract --module <name>`; else bundled files below. MCP reads need no hook or shell. Missing module: stop; never infer/search for runtime.
 
 - `../../meta/contracts/closeout.md`
 - `../../meta/contracts/quality.md`
 - `../../meta/contracts/context-graph.md`
 - `../../meta/contracts/control-scaffold.md`
 
+`instruction_only`: first load `../../meta/contracts/task-target-resolution.md` and `../../meta/contracts/interaction.md`.
+
+<!-- AGDF-REQUEST-ACTIVATION-GUARD:START -->
+## Request Activation
+
+- `owner`: `request_activation_contract`
+- `path`: `meta/contracts/request-activation.md`
+- `policy_version`: `1`
+- `guard_fingerprint`: `sha256:af2f01f9e18a3ba1c520faf0691aa1cd4a4299bdfa027cf83651c5d14319bfdc`
+
+Decide effect from loaded instructions before AGDF action.
+
+Abstain silently (no AGDF call) for assessment/explanation/comparison/recommendation/review/diagnosis/advice; hypothetical/example/error/code/quoted/negated delivery language; AGDF as subject; or a read-only constraint absent other delivery. Ambiguity is read-only: answer or ask one neutral question.
+
+Activate for any requested file/code change however small, a binding gate artefact, explicit AGDF/control-lifecycle operation or unambiguous active-run action; delivery wins mixed intent.
+
+Invocation proof: explicit user text/trusted ephemeral action, not discovery/selection, skill load, hooks, cwd, repo/control or prior runs.
+
+Then pick one catalog route; non-authorizing, downstream checks remain.
+<!-- AGDF-REQUEST-ACTIVATION-GUARD:END -->
+
+## Executable Dispatch
+
+Use listed MCP `agdf_dispatch` (load deferred; host prefix allowed): `skill_id` `release-or`, `presentation_language`, `working_directory`, and only bound `target_source`/`primary_target` and `run_id`. Never search unlisted tools.
+If absent/failing: supplied schema-2 executable, child-only environment, immutable argv_prefix, declared arguments; `--skill release-or`, language and working directory.
+For `--language`: Required presentation language for the latest natural-language user request as one well-formed BCP 47 tag. If the request explicitly asks for a response language, use that tag; otherwise use the dominant request language. Use en when mixed or ambiguous. A valid unsupported tag renders through the complete English pack. Missing or invalid input fails before governance evaluation.
+`target_source`: `explicit_target` if request names `primary_target`; `continued_target` if it unambiguously continues confirmed target; `current_repository` if request names this/current repo with one matching repo active. Otherwise omit the pair; cwd has no target authority.
+Quote shell values as data.
+For a result with `terminal: true`, the entire assistant response must consist only of host_action.text, copied verbatim. Add no question, explanation, heading, citation, link or other surrounding text; do not translate or reformat it; invoke no later tool and stop.
+On skill_continuation use only its target/control. Without that tool and a valid binding: `dispatcher_unavailable`; no runtime search, environment repair
+or help retries. Dispatch never authorizes.
+
 OR-specific output must make gate status, delivered and intentionally not delivered content, missing approvals, missing evidence, risks, retained fallbacks, and the next permissible step visible.
 When `.agdf/control/` is present, persist or link the OR under `.agdf/control/artefacts/<key>/OR.md` and reference it from the selected canonical `RUN_STATE.md` or `MASTER_BACKLOG.md` when it is steering-relevant.
 Use the Runtime Contract definition of `Relevant Run` to decide whether OR is mandatory or whether a Quick Task mini-closeout is enough.
+Close a `quick_task` with the validator's `run-step --step closeout --result --evidence --risk --next`.
 
 ## Rules
 1. OR is always allowed and mandatory for relevant runs as defined in the Runtime Contract.
@@ -53,7 +86,7 @@ Use the Runtime Contract definition of `Relevant Run` to decide whether OR is ma
 13. Keep machine status normalization in the CLI; do not write internal snake_case status values into the human-facing backlog.
 14. Reconcile Context Graph impact before clean closeout: report `context_graph_reconciliation: resolved | not_applicable | open_gap`.
 15. If Context Graph work remains unresolved, report it as an explicit open gap and do not describe the run as cleanly handoff-ready.
-16. After writing or updating `MASTER_BACKLOG.md`, run `doctor --json` (or the locally available equivalent) and resolve any `AGDF_BACKLOG_STATUS_UNKNOWN` or `AGDF_BACKLOG_ARTEFACT_LABEL_UNKNOWN` finding before closeout. See the AGDF control scaffold's `MASTER_BACKLOG.md` template Rules section for the canonical status/artefact label vocabulary.
+16. After writing or updating `MASTER_BACKLOG.md`, run `agdf_inspect` with `operation: doctor` when the host lists it, otherwise `doctor --json` (or the locally available equivalent) and resolve any `AGDF_BACKLOG_STATUS_UNKNOWN` or `AGDF_BACKLOG_ARTEFACT_LABEL_UNKNOWN` finding before closeout. See the AGDF control scaffold's `MASTER_BACKLOG.md` template Rules section for the canonical status/artefact label vocabulary.
 17. When Delivery Map exposes `parent_reconciliation`, report that evaluated object without
     rediscovering or reclassifying the relationship. Keep Child completion and Parent coordination
     visibly separate. An `open` result retains exactly one next action and does not invalidate Child