create-agdf 0.2.7 → 0.2.9

package/generated/.opencode/agents/agdf-delivery-closeout.md

@@ -0,0 +1,115 @@
+---
+description: commit/PR-near handoff after QA/OR/UAT
+mode: subagent
+---
+
+---
+name: agdf-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 `agdf-qa-gate`, `agdf-release-or`, user approvals, or gate decisions.
+
+## Runtime Contract
+Use `../agdf-runtime-contract.md` for closeout discipline, gate terms, Context Graph fields, and non-duplication rules.
+
+## 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.
+
+## 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 `agdf-qa-gate`, `agdf-release-or`, or `agdf-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. Derive Git handoff only when code changes exist.
+3. 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
+4. Set quality outlook:
+   - no further technical follow-up
+   - more tests
+   - refactoring
+   - documentation sharpening
+   - monitoring/runtime verification
+5. If `Approval: UAT` exists and code changes were delivered, 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/.opencode/agents/agdf-gate-check.md

@@ -0,0 +1,155 @@
+---
+description: new build/change intent, unclear approval, Structured Delivery, later-gate artefact requested
+mode: subagent
+---
+
+---
+name: agdf-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 `../agdf-runtime-contract.md` for gate terms, closeout discipline, and non-duplication rules.
+The canonical gate order and transition model live only in the Runtime Contract. 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:
+
+- `.agdf/control/AGDF_RUN.md`
+- `.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, or when a repository-local automation needs JSON output:
+
+```bash
+npm create agdf@latest -- init
+npx --yes create-agdf@latest doctor --json
+npx --yes create-agdf@latest gate-check --json
+npx --yes create-agdf@latest delivery-map --json
+```
+
+`init` creates the control scaffold. `doctor` checks whether `.agdf/control/` is actionable. `agdf-gate-check` consumes that result and `AGDF_RUN.md` 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.
+
+## 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 | 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.
+
+## 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 `agdf-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
+
+If a status is not explicit, do not assume it is satisfied.
+
+## Workflow
+1. Check exact approvals.
+2. Check artefact status.
+3. Determine the earliest blocking user gate or internal mandatory step.
+4. Derive allowed and forbidden outputs.
+5. Name the exact missing approval, if any.
+6. If consent was only implicit, say it is not yet approval and provide the exact formula.
+7. Ensure the next step follows the gate transition table. In particular, never jump from `Approval: UR` to implementation.
+8. Treat a generic "start", "continue" or "leg los" request as a request to perform only the current next allowed action.
+9. After Brownfield Review, choose the smallest safe process path before creating later artefacts.
+10. If the selected path is not visibly recorded with scope reason and evidence, keep the run at `Mode/Slice Decision`.
+11. 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.
+
+## Output
+Keep the result short and operational:
+
+- **Current gate:** `<GateName or internal step>`
+- **Status:** `open | blocked`
+- **Allowed:** `<allowed outputs>`
+- **Forbidden:** `<forbidden outputs>`
+- **Missing approval:** `Approval: <GateName> | none`
+- **Next step:** `<single permissible next step>`
+
+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.
+
+## 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/.opencode/agents/agdf-qa-gate.md

@@ -0,0 +1,116 @@
+---
+description: final QA decision
+mode: subagent
+---
+
+---
+name: agdf-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.
+---
+
+# qa-gate
+
+## Purpose
+Make the formal QA gate decision.
+
+This skill is the only final QA decision point for `pass | revise | block`.
+
+It answers:
+
+- whether `QA pass` is allowed
+- whether the implementation must be revised
+- whether a hard blocker remains
+- whether relevant TP tasks are sufficiently verified
+- whether P0/P1 tasks are complete
+- whether Brownfield fit is sufficient
+- whether solution integrity is sufficient
+- whether blockers, critical risks, or missing evidence remain
+
+## Runtime Contract
+Use `../agdf-runtime-contract.md` for Quality Contract output, Context Graph fields, gate terms, and non-duplication rules.
+
+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.
+
+## Rules
+1. No QA pass without strong evidence.
+2. TP is the reference, not merely working code.
+3. P0/P1 gaps block `pass`.
+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`.
+8. Open risks, missing tests, partial TP coverage, or side effects must be visible.
+
+## When To Use
+- after `CD+Tests`
+- after `agdf-code-review`
+- after `agdf-task-plan-review`
+- after `agdf-clean-implementation-review`
+- before UAT
+- before any claim that implementation is done, releasable, or QA-ready
+- when evidence from Brownfield, TP, or clean-review skills exists
+
+Important:
+
+- `CD+Tests` is implementation and test status only.
+- Without review evidence and TP coverage, `QA pass` is not allowed.
+
+## Inputs
+Use what is available:
+
+- approved TP and TP Review
+- Brownfield Analysis
+- Clean Implementation Review
+- `agdf-code-review` or Code Review Report
+- test/build results
+- documentation impact review
+- runtime or UI evidence
+- known blockers and risks
+
+If evidence is missing, lower the decision accordingly.
+
+## Workflow
+1. Confirm the relevant gate context.
+2. Verify TP coverage.
+3. Verify P0/P1 completion.
+4. Verify Brownfield fit.
+5. Verify solution integrity.
+6. Verify tests and evidence strength.
+7. Verify documentation and Context Graph impact if relevant.
+8. Decide:
+   - `pass`
+   - `revise`
+   - `block`
+9. State the single required next step.
+
+## Output
+Use this shape:
+
+```text
+## QA Gate
+- decision: pass | revise | block
+- evidence:
+- missing_evidence:
+- risks:
+- required_next_step:
+- impact_codes:
+```
+
+If Context Graph impact is relevant, include the fields from `../agdf-runtime-contract.md`.
+
+## Decision Guidance
+- `pass`: required TP tasks are done, evidence is strong, no blocking Brownfield or solution-integrity risk remains.
+- `revise`: implementation is plausible but missing evidence, partial tasks, UX gaps, or fixable integrity issues remain.
+- `block`: hard prerequisite, approval, product semantics, security/compliance, SoT drift, or critical behaviour is unresolved.
+
+## Forbidden
+This skill must not:
+
+- grant QA pass from a green build alone
+- hide partial task completion
+- replace UAT
+- treat missing reviews as completed
+- downgrade SoT drift to harmless warning
+

package/generated/.opencode/agents/agdf-release-or.md

@@ -0,0 +1,130 @@
+---
+description: auditable closeout for every relevant run
+mode: subagent
+---
+
+---
+name: agdf-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.
+---
+
+# release-or
+
+## Purpose
+Produce the Orchestration Report (OR) as the mandatory closeout for a relevant run.
+
+It reports:
+
+- current user gate
+- whether the run is `pass`, `revise`, `block`, or not yet QA-decided
+- what was delivered
+- what was intentionally not delivered
+- missing approvals
+- TP coverage status
+- Brownfield fit
+- solution integrity
+- documentation impact
+- Context Graph impact
+- open risks, blockers, retained fallbacks, and exit criteria
+- next permissible step
+- whether further quality follow-up or a separate delivery closeout is useful
+
+## Runtime Contract
+Use `../agdf-runtime-contract.md` for Quality Contract output, Context Graph fields, gate terms, and non-duplication rules.
+
+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 `AGDF_RUN.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.
+
+## Rules
+1. OR is always allowed and mandatory for relevant runs as defined in the Runtime Contract.
+2. OR is an audit report, not a blocking gate.
+3. Do not leak artefacts from blocked later gates.
+4. Use OR-lite when early gates block.
+5. Use OR-full only within the allowed scope.
+6. Report status, not marketing language.
+7. Name missing approvals, partial implementation, risks, fallbacks, Brownfield issues, and open defects.
+8. Retained fallbacks require visible exit criteria and cleanup path.
+9. End with the immediately permissible next step.
+10. `CD+Tests` is not completion.
+
+## When To Use
+- at the end of every relevant run
+- after artefact creation
+- when a gate blocks
+- after `CD+Tests`
+- after `agdf-code-review`
+- after QA
+- after UAT
+- whenever a compact audit closeout is needed
+
+Do not force OR onto a pure explanation, read-only inspection, small review, or local debugging step that produces no durable state change and no gate consequence.
+
+## Inputs
+Use what is available:
+
+- current gate
+- existing approvals
+- artefacts created in this run
+- intentionally not delivered content
+- Task Plan
+- `agdf-task-plan-review`
+- `agdf-brownfield-analysis`
+- `agdf-clean-implementation-review`
+- `agdf-code-review`
+- QA Report
+- UAT Report
+- documentation impact review
+- Context Graph impact
+- known risks, defects, fallbacks, and open questions
+- test/build status and relevant metrics
+
+If information is missing, state the gap instead of guessing.
+
+## Workflow
+1. Determine the current gate and earliest blocker.
+2. Determine report depth:
+   - `OR-lite`: gate status, allowed/forbidden outputs, missing approval, next step
+   - `OR-full`: also delivered artefacts, TP coverage, Brownfield fit, solution integrity, risks, fallbacks, QA/UAT status
+3. Record the selected `Report mode` and durable OR target or link when `.agdf/control/` exists.
+4. Record delivered vs intentionally not delivered content.
+5. Summarize TP coverage if a TP exists.
+6. Summarize Brownfield fit and solution integrity if reviewed.
+7. Summarize tests and verification.
+8. Summarize documentation and Context Graph impact if relevant.
+9. Name retained fallbacks and exit criteria.
+10. Set exactly one next permissible step.
+11. Set exactly one quality outlook.
+12. State whether `agdf-delivery-closeout` is the next operational handoff step when code changes exist and the delivery state allows it.
+
+## Output
+Use a compact structure:
+
+```text
+## OR
+- gate:
+- report_mode:
+- artefact:
+- status:
+- delivered:
+- intentionally_not_delivered:
+- evidence:
+- missing_evidence:
+- risks:
+- retained_fallbacks:
+- required_next_step:
+- quality_outlook:
+```
+
+When Context Graph impact is relevant, include the fields from `../agdf-runtime-contract.md`.
+
+## Forbidden
+This skill must not:
+
+- decide QA in place of `agdf-qa-gate`
+- call `CD+Tests` complete, QA-ready, or release-ready
+- hide missing approvals
+- provide later-gate content while an earlier gate blocks
+- produce the operative commit/PR handoff owned by `agdf-delivery-closeout`
+- execute commit, push, or PR actions
+

package/generated/.opencode/agents/agdf-task-plan-review.md

@@ -0,0 +1,121 @@
+---
+description: after implementation and before QA, verify TP coverage
+mode: subagent
+---
+
+---
+name: agdf-task-plan-review
+description: Use this skill after code changes and before QA to verify whether the approved Task Plan was actually fulfilled. It checks each task_id against implementation, acceptance criteria, tests, visible evidence, and deviations, and provides TP coverage for QA.
+---
+
+# task-plan-review
+
+## Purpose
+Verify whether implementation actually satisfies the approved Task Plan.
+
+For each relevant task, this skill determines:
+
+- whether the task is fully, partially, or not completed
+- which acceptance criteria are done, partial, missing, or not verifiable
+- which files, tests, runtime evidence, or UI evidence support the finding
+- evidence strength
+- which gaps must be handed to `agdf-qa-gate`
+
+This skill provides TP coverage. It is not the final QA decision.
+
+## Runtime Contract
+Use `../agdf-runtime-contract.md` for Quality Contract output, Context Graph fields, gate terms, and non-duplication rules.
+
+TP-specific output must evaluate every relevant `task_id` with completion status, AC coverage, evidence, missing evidence, and QA-relevant gaps.
+If `context_graph_required_action` is not `none`, the affected task is complete only if follow-up, evidence, or an intentionally open gap is visible.
+
+## Rules
+1. The Task Plan is the reference, not plausible code.
+2. No assumptions without evidence.
+3. Evaluate each relevant `task_id` individually.
+4. `fully_done` requires strong evidence.
+5. A green build alone does not prove TP completion.
+6. UI/state/render/recovery tasks need visible evidence, not only code.
+7. Partial implementation must be marked `partially_done`.
+8. P0/P1 gaps must be handed to QA.
+9. Out-of-scope changes must be reported.
+10. When evidence is unclear, fail closed to at least `partially_done`.
+
+## Clarifications
+### TP Slice Before Target State
+If the TP explicitly defines a preparatory, additive, or limited slice, evaluate that exact scope.
+`fully_done` is allowed for a completed slice even if the larger target state remains open.
+
+### Missing Priorities
+If no priorities are defined, do not invent them. Mark the gap and treat QA relevance conservatively.
+
+### Missing Acceptance Criteria
+If ACs are unclear, derive only obvious expectations from title, goal, and scope. Mark AC basis as incomplete and lower evidence confidence as needed.
+
+## When To Use
+- after `CD+Tests`
+- before `QA`
+- when TP completion is unclear
+- when the user asks for TP fulfilment
+- when UI/state/runtime invariants are affected
+- when several agents or work steps touched the same TP
+
+## Inputs
+Use what is available:
+
+- Task Plan
+- `task_id`, `story_id`, priorities
+- acceptance criteria or success goals
+- changed files
+- tests and test results
+- build results
+- runtime/UI evidence
+- known deviations and scope decisions
+
+If TP or relevant tasks are missing, do not claim reliable TP coverage.
+
+## Output
+Use this compact structure:
+
+```text
+## TP Coverage
+| task_id | status | evidence | missing_evidence | QA impact |
+|---|---|---|---|---|
+
+## Summary
+- fully_done:
+- partially_done:
+- not_done:
+- out_of_scope_changes:
+- risks:
+- required_next_step:
+```
+
+Completion status:
+
+- `fully_done`
+- `partially_done`
+- `not_done`
+
+AC status:
+
+- `done`
+- `partial`
+- `missing`
+- `not_verifiable`
+
+Evidence confidence:
+
+- `high`
+- `medium`
+- `low`
+
+## Forbidden
+This skill must not:
+
+- decide final QA
+- mark tasks fully done from code existence alone
+- hide partial work
+- upgrade missing evidence into confidence
+- reinterpret the TP scope
+

package/generated/opencode.json

@@ -0,0 +1,13 @@
+{
+  "$schema": "https://opencode.ai/config.json",
+  "plugin": [
+    "create-agdf"
+  ],
+  "instructions": [
+    ".opencode/AGDF.md"
+  ],
+  "permission": {
+    "edit": "ask",
+    "bash": "ask"
+  }
+}

package/generated/plugins/agdf/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "agdf",
-  "version": "0.2.7",
+  "version": "0.2.9",
   "description": "Codex-first workflow skills for gated, auditable AI-assisted software delivery.",
   "author": {
     "name": "AI-native Governance & Delivery Framework",

package/generated/plugins/agdf/control/README.md

@@ -49,15 +49,21 @@ Keep these files small and reviewable. They are control artefacts, not a second
 Create the live files with:
 
 ```bash
-npm create agdf@latest init
+npm create agdf@latest -- init
+```
+
+If only the project language preference is missing or should change after plugin installation, write just the config file:
+
+```bash
+npm create agdf@latest -- config --language en
 ```
 
 Then check whether the live state is actionable:
 
 ```bash
-npm create agdf@latest doctor
-npm create agdf@latest doctor --json
-npm create agdf@latest gate-check --json
+npm create agdf@latest -- doctor
+npx --yes create-agdf@latest doctor --json
+npx --yes create-agdf@latest gate-check --json
 ```
 
 `doctor` does not replace agent judgment. It catches basic control failures: missing live files, missing current gate, missing next allowed action, empty evidence, empty backlog pointer, empty source-of-truth registry, duplicate active SoT rows and invalid quality contracts.