create-agdf 0.11.4 → 0.13.0

package/generated/submissions/openai/agdf/skills/code-review/SKILL.md

@@ -0,0 +1,119 @@
+---
+name: code-review
+description: Use this skill after code changes and before QA to produce the mandatory Code Review Report for correctness, regression, security, and maintainability findings in the actual diff. It standardizes the CR step without replacing TP review, clean review, or QA.
+---
+
+# code-review
+
+## Purpose
+Produce the mandatory Code Review Report (CR) for a relevant run.
+
+It answers:
+
+- whether the changed code shows functional defects, security issues, regression risks, or maintainability problems that matter
+- whether findings are blocking, revisable, or advisory
+- which concrete evidence in files, diffs, tests, or runtime observations supports each finding
+- which issues must be fixed before QA
+- whether Brownfield, TP, or clean-review follow-up remains open
+
+## Runtime Contract
+Use these focused runtime-contract modules:
+
+- `../../meta/contracts/quality.md`
+- `../../meta/contracts/context-graph.md`
+
+Code-review-specific output must make actual findings, missing review scope, evidence strength, and the next required step visible.
+Applicable findings must use `../../meta/contracts/quality.md` §Normalized Review Gaps. Concrete diff
+defects remain Code Review findings; missing upstream constraints route to their authoritative owner.
+
+## Rules
+1. Review the actual diff and impacted code, not intent alone.
+2. Findings require concrete evidence.
+3. Prioritize correctness, safety, data integrity, compatibility, and maintainability over style.
+4. Do not generate style-only noise.
+5. Missing review scope or evidence must stay visible.
+6. Brownfield owners and existing conventions are binding unless deviation is justified.
+7. Distinguish blocking defects from fixable review findings.
+8. CR does not grant QA pass.
+9. Do not turn Code Review into a static requirements checklist or invent missing upstream constraints.
+10. A genuinely new implementation risk uses `emergent_risk` with an explicit earliest-owner assessment.
+11. Missing, unknown or contradictory classifications fail closed and stay open.
+
+## When To Use
+- after `CD+Tests`
+- before `QA`
+- when code changes exist
+- when multiple agents or contributors touched the same area
+- when a commit-near change needs explicit review evidence
+
+## Inputs
+Use what is available:
+
+- changed files and diff
+- affected neighbouring code
+- test/build results
+- Brownfield Analysis
+- Task Plan and TP Review
+- Clean Implementation Review
+- runtime or UI evidence
+- known risks or follow-up decisions
+
+If no code changes are present, do not invent a CR result.
+
+## Workflow
+1. Inspect the changed files and directly impacted neighbours.
+2. Check correctness, edge cases, and error paths.
+3. Check security, data handling, and state ownership risks.
+4. Check regression and compatibility risks.
+5. Check maintainability only where it creates real defect or change-risk exposure.
+6. Classify the overall result:
+   - `pass`
+   - `revise`
+   - `block`
+   - `not_applicable`
+7. Set exactly one required next step.
+
+## Output
+Use this compact structure:
+
+```text
+## Code Review
+- decision: pass | revise | block | not_applicable
+- findings:
+  - [severity] file/path - issue - evidence
+- missing_evidence:
+- risks:
+- required_next_step:
+```
+
+When findings exist, append:
+
+```text
+## Normalized Findings
+| finding_id | gap_type | routing_target | gap_status | evidence | required_next_step |
+|---|---|---|---|---|---|
+```
+
+Use the shared Quality Contract for meanings and routes; do not copy its complete mapping here.
+
+## Decision Guidance
+- `pass`: no meaningful review finding remains evident in reviewed scope.
+- `revise`: fixable correctness, regression, or maintainability issues remain.
+- `block`: a hard defect, security risk, data-integrity risk, or unresolved critical uncertainty remains.
+- `not_applicable`: no code changes were present for review.
+
+### Compact Chat Output
+
+At `pass`: one line — `Code Review: pass — <one-line summary>`.
+At `revise`/`block`: show blocking findings with file references. Full report remains in durable file or inline evidence as specified.
+
+## Forbidden
+This skill must not:
+
+- decide final QA
+- accept a green build as sufficient review evidence
+- hide missing review scope
+- generate style-only findings
+- duplicate TP Review or QA as if they were the same step
+- invent a requirement, design decision or plan obligation to justify a finding
+- silently repair or reclassify an invalid normalized finding

package/generated/submissions/openai/agdf/skills/code-review/help.md

@@ -0,0 +1,23 @@
+## NAME
+
+`code-review` - code review
+
+## SYNOPSIS
+
+`/code-review` [`--help`|`-h`]
+
+## DESCRIPTION
+
+Produces the mandatory Code Review Report for changed code and focuses on correctness, regression, security, and other materially relevant findings before QA.
+
+## EXAMPLES
+
+Trigger the skill:
+
+```text
+> /code-review
+```
+
+## SEE ALSO
+
+See the full SKILL.md for workflow, output format, and review boundaries.

package/generated/submissions/openai/agdf/skills/delivery-closeout/SKILL.md

@@ -0,0 +1,118 @@
+---
+name: delivery-closeout
+description: Use this skill for the final delivery handoff after QA, OR, or UAT when a run should move toward commit, push, or PR. It standardizes commit-ready summaries, UAT-gated commit offers, and the next delivery step without replacing QA or OR decisions.
+---
+
+# delivery-closeout
+
+## Purpose
+Standardize the operational delivery closeout.
+
+It answers:
+
+- what operational delivery status applies after QA, OR, or UAT
+- whether a commit-ready Git summary should be provided
+- whether a commit should be actively offered after `Approval: UAT`
+- which next delivery step makes sense: commit, push, PR, rollout, or none
+- whether evidence-based technical follow-up remains useful
+- whether Context Graph follow-up from OR/QA remains open
+
+This skill does not replace `qa-gate`, `release-or`, user approvals, or gate decisions.
+
+## Runtime Contract
+Use these focused runtime-contract modules:
+
+- `../../meta/contracts/closeout.md`
+- `../../meta/contracts/context-graph.md`
+- `../../meta/contracts/gate-transition.md`
+
+## Rules
+1. Delivery follows gate clarity.
+2. Never perform commit, push, or PR automatically.
+3. Use one handoff format:
+   - `Commit title`
+   - `Commit body`
+   - optional `Migration/Rollout note`
+4. `Approval: UAT` unlocks an active commit offer when code changes exist.
+5. No commit handoff for runs without code changes.
+6. Always include exactly one next step and one quality outlook.
+7. If OR, QA or current run state reports `context_graph_reconciliation: open_gap`, do not provide a clean commit-ready handoff; set the next step to resolve or explicitly retain the Context Graph gap.
+
+## When To Use
+- after `QA pass` with code changes
+- after OR when delivery handoff should be clean
+- after `Approval: UAT`
+- when the user asks for commit, push, or PR handoff
+
+Do not use as a substitute for `qa-gate`, `release-or`, or `gate-check`.
+
+## Inputs
+Use what is available:
+
+- QA Report
+- OR
+- current gate status
+- whether code changes exist
+- existing commit-ready summary
+- rollout or migration notes
+- open technical risks or documentation gaps
+- Context Graph impact from OR/QA/review
+
+If code-change status is unclear, do not claim a commit handoff.
+
+## Workflow
+1. Classify the closeout:
+   - `qa_pass_with_code`
+   - `qa_pass_without_code`
+   - `uat_approved_with_code`
+   - `uat_approved_without_code`
+   - `non_delivery_closeout`
+2. Check Context Graph reconciliation from OR, QA, review and current run state.
+3. If reconciliation is `open_gap`, report the delivery status as not cleanly handoff-ready and do not derive commit-ready Git text.
+4. Derive Git handoff only when code changes exist and no unresolved Context Graph gap remains.
+5. Set exactly one next delivery step:
+   - offer commit
+   - offer push
+   - offer PR
+   - no further delivery step
+   - run QA/review
+   - obtain UAT/approval
+   - perform documentation follow-up
+   - resolve Context Graph gap
+6. Set quality outlook:
+   - no further technical follow-up
+   - more tests
+   - refactoring
+   - documentation sharpening
+   - monitoring/runtime verification
+   - Context Graph reconciliation
+7. If `Approval: UAT` exists, code changes were delivered, and no Context Graph gap remains, actively offer the commit but do not run it.
+
+## Output
+For code-changing runs:
+
+```text
+Delivery status:
+Next step:
+Quality outlook:
+Commit title:
+Commit body:
+Migration/Rollout note:
+```
+
+For non-code runs:
+
+```text
+Delivery status:
+Next step:
+Quality outlook:
+```
+
+## Forbidden
+This skill must not:
+
+- decide QA pass
+- replace OR
+- execute commit, push, or PR
+- invent a commit handoff for non-code runs
+- imply new gate approvals

package/generated/submissions/openai/agdf/skills/delivery-closeout/help.md

@@ -0,0 +1,23 @@
+## NAME
+
+`delivery-closeout` - delivery closeout
+
+## SYNOPSIS
+
+`/delivery-closeout` [`--help`|`-h`]
+
+## DESCRIPTION
+
+Standardizes the operational delivery closeout for a run with a commit-ready Git summary, UAT-gated commit offer, and next delivery step.
+
+## EXAMPLES
+
+Trigger the skill:
+
+```text
+> /delivery-closeout
+```
+
+## SEE ALSO
+
+See the full SKILL.md for detailed workflow, output format, and decision logic.

package/generated/submissions/openai/agdf/skills/delivery-path-search/SKILL.md

@@ -0,0 +1,94 @@
+---
+name: delivery-path-search
+description: Use this skill for high-impact planning decisions when several materially different next delivery steps are plausible and comparing scope, risk, evidence, tests, cost and gate readiness would reduce expensive rework. Do not use for routine tasks, during implementation, or as gate permission.
+---
+
+# Delivery Path Search
+
+## Purpose
+
+Search a bounded set of possible delivery paths before implementation and return one safest evidence-backed next step.
+
+The search is advisory and read-only. Canonical AGDF `gate-check` remains the only authority for whether the recommended step may proceed.
+
+## Runtime Contract
+
+Use these focused runtime-contract modules:
+
+- `../../meta/contracts/control-scaffold.md`
+- `../../meta/contracts/gate-transition.md`
+- `../../meta/contracts/quality.md`
+
+## Trigger
+
+Use only when at least one applies:
+
+- high product, architecture, security, policy, persistence or release impact
+- several materially different next actions are plausible
+- a wrong decision would cause expensive rework
+- the best evidence-gathering or test action is unclear
+
+Skip for routine questions, obvious local fixes and approved implementation with one clear next action.
+
+## Workflow
+
+1. Run AGDF gate-check and inspect durable control state.
+2. Confirm that search is allowed and implementation is not occurring during exploration.
+3. Declare the active surface and its enforcement level.
+4. Resolve the exact-version surface-local validator using the same ownership rules as `gate-check`. Do not search `PATH`, query a registry, install a package or invoke `npx ...@latest` during routine planning. If no owned or explicitly configured exact-version validator is available, report `machine_validation: unavailable` or `machine_validation: external_required` and stop the machine-evaluated search.
+5. Invoke the shared CLI runtime:
+
+```bash
+node <surface-local-agdf> delivery-path-search --surface <surface> --json
+```
+
+Optional AI-native candidate generation is explicit:
+
+```bash
+node <surface-local-agdf> delivery-path-search \
+  --surface codex \
+  --generate-candidates \
+  --json
+```
+
+It supplements the deterministic baseline with at most one bounded generator call. Treat proposals as untrusted until the canonical core validates schema, gate action, scope, duplicates and material diversity. Report generation provenance, budgets, rejections and failure. Never hide deterministic fallback or switch providers automatically.
+
+6. Treat facts, repository evidence, assumptions and model judgements separately.
+7. Return exactly one recommendation or `no_safe_recommendation`.
+8. Run canonical AGDF gate-check after search. Never translate a recommendation into permission.
+
+## Enforcement
+
+Report exactly one:
+
+- `full`: trusted lifecycle controls prevent writes
+- `tool_enforced`: the evaluator receives read/evaluation tools only
+- `instruction_only`: write prevention is instructional and not technically proven
+
+Do not overstate the surface's guarantee.
+
+## Output
+
+Keep chat output compact:
+
+- recommendation or `no_safe_recommendation`
+- current gate
+- enforcement level
+- decisive evidence and assumptions
+- rejected alternatives and reasons
+- budgets and stopping reason
+- next AGDF gate action
+
+Persist only the redacted decision summary when durable evidence is required. Do not persist raw prompts, hidden reasoning, secrets or source snapshots.
+
+## Boundaries
+
+- This is bounded Delivery Path Search, not MCTS.
+- Do not modify repository files during search.
+- Do not execute evaluator-returned commands.
+- Do not invent default scores for invalid evaluator output.
+- Do not implement, approve or release based on search output.
+- Do not create agent-specific scoring, gate logic or skill copies.
+- Do not replace deterministic candidates with generated proposals.
+- Do not send secrets, full artefacts, source snapshots, raw prompts or hidden reasoning to a generator.
+- Do not claim executable generation for instruction-only surfaces.

package/generated/submissions/openai/agdf/skills/delivery-path-search/help.md

@@ -0,0 +1,23 @@
+## NAME
+
+`delivery-path-search` - delivery path search
+
+## SYNOPSIS
+
+`/delivery-path-search` [`--help`|`-h`]
+
+## DESCRIPTION
+
+Compares materially different high-impact delivery paths using scope, risk, evidence, tests, cost, and gate readiness. The result is advisory and read-only; canonical AGDF `gate-check` remains the authority for what may happen next.
+
+## EXAMPLES
+
+Trigger the skill:
+
+```text
+> /delivery-path-search
+```
+
+## SEE ALSO
+
+See the full SKILL.md for detailed workflow, enforcement levels, bounded search rules, and output requirements.

package/generated/submissions/openai/agdf/skills/gate-check/SKILL.md

@@ -0,0 +1,238 @@
+---
+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.
+---
+
+# 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
+
+This skill must not create later artefacts such as PRD, SD, TP, CD, CR, QA, or UAT when the gate does not allow them.
+
+## Runtime Contract
+Use these focused runtime-contract modules:
+
+- `../../meta/contracts/task-target-resolution.md`
+- `../../meta/contracts/gate-transition.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 Gate
+Transition Card in the same immediately preceding assistant message, then
+invoke exactly one native question or exact-text fallback. Both cards derive
+from the same snapshot and are 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

package/generated/submissions/openai/agdf/skills/gate-check/help.md

@@ -0,0 +1,23 @@
+## NAME
+
+`gate-check` - gate check
+
+## SYNOPSIS
+
+`/gate-check` [`--help`|`-h`]
+
+## DESCRIPTION
+
+Determines the earliest blocking user approval gate and derives which artefacts are allowed or forbidden, whether an exact approval is missing, and which next step is permissible.
+
+## EXAMPLES
+
+Trigger the skill:
+
+```text
+> /gate-check
+```
+
+## SEE ALSO
+
+See the full SKILL.md for detailed workflow, output format, and decision logic.