create-agdf 0.2.7 → 0.2.9

package/generated/.opencode/agdf-runtime-contract.md

@@ -0,0 +1,219 @@
+# AGDF Runtime Contract
+
+This contract centralizes recurring runtime rules for AGDF skills.
+It is the operational reference for skill outputs, but it is not a second copy of the framework documentation.
+
+## Mode Selection
+
+| Mode | Default | Escalate When |
+|---|---|---|
+| Quick Task Mode | small questions, reviews, debugging, local fixes without new product semantics | a new user capability, architecture/policy/persistence impact, formal artefacts, or approvals are involved |
+| Structured Delivery Mode | formal delivery runs, gate-relevant work, release-critical changes | always use gate discipline, internal reviews, and OR |
+
+Quick Task Mode must not become ritual gate overhead.
+Structured Delivery must not bypass missing approvals.
+New product semantics, functional change, user-visible behaviour, policy, persistence, architecture or release-critical work requires a durable UR in `.agdf/control/` or a linked authoritative repository SoT before later artefacts or implementation.
+UR, PRD, SD, TP and QA report approvals require durable artefacts or linked authoritative repository SoT entries before the next gate can open.
+
+## Quick Task Output
+
+Quick Tasks are intentionally lightweight, but they must not become invisible.
+Use this compact output shape when no formal gate artefact is required:
+
+- `result`: what changed or was concluded
+- `evidence`: files, commands, observations, or reasoning that support the result
+- `risk`: remaining risk or `none`
+- `next_step`: the single next useful action or `none`
+
+Do not add a separate `Quality outlook` line for pure Quick Tasks unless the task became a relevant run.
+
+## Chat Output Discipline
+
+Durable artefacts are for the repository, not for flooding the chat.
+When a skill creates or updates `.agdf/control/` files, gate artefacts, reviews, QA reports or OR reports, the chat response must stay compact:
+
+- name the artefact path and status
+- summarize the decision or content in a few lines
+- state the current gate, forbidden work and next permissible step
+- mention validation evidence when available
+
+Do not paste full control files, full artefact bodies, full templates or full generated reports into the chat unless the user explicitly asks to see the full content.
+For larger or more formal work, create or update the durable artefacts fully, then reference them by path and summarize what changed.
+
+## Relevant Run
+
+A relevant run is any run that changes durable state, creates or updates an AGDF artefact, changes code or runtime behaviour, performs a gate decision, blocks on a governance condition, produces QA/UAT/release evidence, or closes a delivery slice.
+
+OR is not mandatory for a pure explanation, read-only inspection, small review, or local debugging step that produces no durable state change and no gate consequence.
+When in doubt, use a short OR-lite only if it clarifies gate state, evidence, risk, or the next permissible step.
+
+## Gate Rules
+
+- User gates: `UR -> PRD -> SD -> TP -> QA -> UAT`
+- Internal mandatory steps: `Brownfield Review -> Mode/Slice Decision -> Brownfield Analysis -> CD+Tests -> CR -> OR`
+- Exact approval formula: `Approval: <GateName>`
+- Legacy alias: `Freigabe: <GateName>` may be accepted when reviewing older German runs, but all new outputs must use `Approval: <GateName>`.
+- Implicit consent is not approval. Phrases such as "ok", "go ahead", "do it", "approved", "continue", "leg los" or "looks good" are work intent, not gate approval.
+- The earliest blocking gate wins.
+- For UR, PRD, SD, TP and QA, approval and durable artefact presence are separate requirements. A gate is not satisfied by approval text alone when its artefact is missing from `.agdf/control/` or not linked to the authoritative repository SoT.
+- Approval of one user gate permits work on the next allowed gate artefact or required internal step only. It does not permit implementation unless the approved gate is `TP` and required internal implementation prerequisites are satisfied.
+- Gates must never be skipped or inferred from urgency, tone, chat history, task wording or an instruction to "start". The next allowed action is always the next unsatisfied gate or internal mandatory step.
+- Missing control files or missing current-state fields do not forbid the agent from preparing the current allowed artefact. They forbid later-gate work and implementation. For a fresh request, the default allowed work is to draft a minimal UR in the response and request `Approval: UR`. Initialize or write `.agdf/control/` 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.
+- `Approval: UR` permits Brownfield Review after G-00 first, then a Mode/Slice Decision. It never permits implementation by itself.
+- PRD, SD and TP depth is chosen after Brownfield Review through the Mode/Slice Decision, not before existing-system impact is understood.
+- The Mode/Slice Decision must be visible before any PRD shortcut, Quick Task execution or implementation: record the decision, required next gate, scope reason and evidence in `AGDF_RUN.md` or an equivalent linked control artefact.
+- `Approval: PRD` permits Solution Design drafting, not implementation.
+- `Approval: SD` permits Task/Test Plan drafting, not implementation.
+- `Approval: TP` permits implementation-preparation Brownfield Analysis and then CD+Tests when Brownfield evidence supports it.
+- `CD+Tests` is implementation and test status only, not a delivery signal.
+- `agdf-code-review` standardizes the mandatory `CR` step, but does not replace QA.
+- `agdf-qa-gate` decides final `pass | revise | block`.
+- `agdf-release-or` reports the run, but does not replace QA or produce the operative commit/PR handoff.
+- `agdf-delivery-closeout` owns the operative Git handoff text when QA/OR/UAT state allows it.
+
+## Brownfield Review After G-00
+
+After an approved and durable UR, perform a lightweight `Brownfield Review` before PRD when Brownfield, UI, UX, admin, runtime, policy, persistence, architecture, ownership or source-of-truth impact is possible.
+
+This review is not a new user approval gate, not PRD, not SD, not TP and not implementation permission.
+It is the sizing and routing step that decides how much later gate discipline is actually needed.
+
+Its output is limited to:
+
+- workstream or follow-up-slice classification
+- `Mode/Slice Decision`: `quick_task | structured_slice | structured_delivery | block`
+- affected existing owners, source-of-truth artefacts, contracts, policies, runtime paths or tests
+- reuse-before-create risks and parallel-structure risks
+- open questions that PRD or SD must resolve
+- whether implementation-preparation Brownfield Analysis will also be needed after TP
+
+Mode/Slice Decision rules:
+
+- `quick_task`: use only when Brownfield Review shows a narrow local change, no new product semantics beyond the approved UR, no architecture/policy/persistence/contract expansion, and evidence is sufficient to proceed with a small implementation plus relevant checks.
+- `structured_slice`: use when some formal artefacts are needed, but they can stay intentionally small and scoped to the approved slice.
+- `structured_delivery`: use when the change has broad product, architecture, runtime, policy, persistence, release or cross-owner impact.
+- `block`: use when ownership, SoT, impact, evidence or product direction is not clear enough to choose a safe path.
+
+A Mode/Slice Decision without scope reason and evidence is not recorded. Treat it as missing and keep the next step at `Mode/Slice Decision`.
+
+## Gate Transition Model
+
+This table is the canonical transition model. Skills may reference it, but must not carry a second complete copy.
+
+| State | Current gate or step | Allowed | Forbidden | Missing approval |
+|---|---|---|---|---|
+| No approved UR | `UR` | clarify user need, formulate and persist UR, request `Approval: UR` | PRD, SD, TP, Brownfield Analysis, implementation, QA, release | `Approval: UR` |
+| `UR` approved and UR artefact persisted or linked, Brownfield Review missing | `Brownfield Review` | classify workstream, existing owners, SoT, reuse risks, change size and PRD/SD open questions; mark review done or not_applicable | PRD, SD, TP, implementation, QA, release | none |
+| Brownfield Review done or not_applicable, Mode/Slice Decision missing or incomplete | `Mode/Slice Decision` | decide `quick_task`, `structured_slice`, `structured_delivery` or `block`; record scope reason, evidence and required next gate depth | PRD, SD, TP, implementation, QA, release | none |
+| Mode/Slice Decision is `quick_task` | `Quick Task Execution` | implement only the narrow approved UR scope, run relevant checks, record evidence and OR-lite when the run is relevant | broad PRD/SD/TP by ritual, scope expansion, QA or release claims without evidence | none |
+| Mode/Slice Decision is `structured_slice` or `structured_delivery`, PRD missing or draft | `PRD` | draft/refine PRD at the smallest justified depth, define scope, acceptance criteria and non-goals, persist/link PRD, request `Approval: PRD` | SD, TP, implementation-preparation Brownfield Analysis, implementation, QA, release | `Approval: PRD` |
+| `PRD` approved and PRD artefact persisted or linked, SD missing or draft | `SD` | draft/refine Solution Design, ownership and architecture, persist/link SD, request `Approval: SD` | TP, implementation, QA, release | `Approval: SD` |
+| `SD` approved and SD artefact persisted or linked, TP missing or draft | `TP` | draft/refine Task/Test Plan, task IDs, evidence plan, persist/link TP, request `Approval: TP` | implementation, QA, release | `Approval: TP` |
+| `TP` approved and TP artefact persisted or linked, Brownfield Analysis missing | `Brownfield Analysis` | run Brownfield Analysis for approved TP scope | implementation, QA, release | none |
+| Brownfield Analysis passed for approved TP | `CD+Tests` | implement approved TP tasks and run tests | QA pass, UAT, release | none |
+| `QA` approved but QA report missing or not pass | `QA` | persist/link QA report with `pass` decision or revise/block evidence | UAT, release | none |
+
+## Brownfield Modes
+
+The `agdf-brownfield-analysis` skill has two explicit modes:
+
+- `post_ur_review`: lightweight sizing and routing after approved durable UR; decides Mode/Slice Decision before PRD depth or implementation is chosen.
+- `pre_implementation_analysis`: implementation-preparation analysis after approved durable TP; verifies reuse path, owners, regression risk and fit before `CD+Tests`.
+
+Do not mix the modes silently. Name the active mode in Brownfield output.
+
+## Quality Contract Output
+
+Structured Delivery skills use this shape when relevant:
+
+- `decision`: `pass | revise | block | not_applicable`
+- `evidence`: concrete artefacts, files, tests, logs, diffs, or observations
+- `missing_evidence`: missing proof needed for a stronger claim
+- `risks`: remaining risks, assumptions, fallbacks, drift, or blockers
+- `required_next_step`: exactly the next clean step
+- `impact_codes`: affected Quality Contract codes, if the target repo has a registry
+
+A skill may briefly remind this shape, but must not duplicate a complete code or rule matrix.
+
+## Context Graph Output
+
+When a run affects project memory or a Context Graph, use:
+
+- `Situation:` short plain-language summary when the impact is non-trivial
+- `context_graph_impact`: `none | link_only | update_existing_node | new_node_required | sot_drift`
+- `context_graph_refs`
+- `context_graph_required_action`: `none | link | update | create | resolve_drift`
+- `context_graph_gate_effect`: `none | warning | revise | block`
+- `context_graph_evidence`
+
+Do not create a new node for a mere version, a general chat summary, or a local observation without a concrete next clean step.
+`sot_drift` must not pass silently as a warning.
+
+## Control Scaffold
+
+When a repository needs durable AGDF state, use the plugin-local `control/` scaffold as the starting point.
+
+- `config.json` stores project language preferences. Use `artifact_language` for generated AGDF artefacts and `chat_language` for user-facing responses unless the user explicitly asks otherwise. Runtime rules remain English.
+- `AGDF_RUN.md` is the current run dashboard.
+- `MASTER_BACKLOG.md` is the living pointer for active delivery work.
+- `BROWNFIELD_REVIEW.md` records the post-UR existing-system view and Mode/Slice Decision before PRD depth or Quick Task execution is chosen.
+- `SOT_REGISTRY.md` prevents parallel sources of truth.
+- `CONTEXT_GRAPH.md` stores durable Brownfield findings, decisions, risks, evidence and exit criteria.
+- `AGENT_QUALITY_CONTRACTS.json` stores reusable block, revise and warning conditions.
+- OR reports live under `.agdf/control/artefacts/<key>/OR.md` when a run closeout is steering-relevant or should be auditable beyond the chat.
+
+The scaffold is not a second documentation site. Link to authoritative artefacts instead of copying them.
+
+## Agent-Native Runtime And CLI Verification
+
+AGDF is agent-native first and CLI-verifiable by design.
+
+The primary operating path is the active skill plus the live `.agdf/control/` artefacts.
+Agents should read the repository state, apply this Runtime Contract, create or update only the currently allowed artefact, and make the next permissible step explicit.
+When control state is missing for a fresh request, keep the first step lightweight: draft the minimal UR in the response and request `Approval: UR`.
+Initialize a control scaffold only when durable AGDF control state is explicitly requested, already used by the repository, or required by a deterministic CLI/CI setup path.
+
+Helper commands are deterministic proof and automation interfaces, not the normal-work ritual:
+
+- `init` creates the machine-readable control scaffold.
+- `doctor --json` checks whether `.agdf/control/` is consistent and actionable; it is not the reviewer.
+- `gate-check --json` reports reproducible gate state; it does not replace the gate-check skill judgement.
+- `delivery-map --json` reports the delivery picture for CI, PRs, regression checks and audit trails.
+
+Machine-readable outputs should stay agent-friendly: stable decisions, blocking gate or current gate, missing approval, allowed outputs, forbidden outputs, next step, evidence and findings.
+They make the repository state checkable, but they do not replace the native skill workflow or the durable control artefacts.
+
+## Delivery Map
+
+`delivery-map --json` is the machine-readable delivery picture for the active control state.
+It derives, but does not replace, the live `.agdf/control/AGDF_RUN.md` and `MASTER_BACKLOG.md` state.
+
+It must expose:
+
+- approved or active artefacts and approvals
+- `UR -> PRD -> SD -> TP -> QA_REPORT` relationships
+- evidence refs, missing evidence and declared risks
+- Context Graph impact and gate effect
+- findings that explain why the delivery picture is `pass | warn | revise | block`
+
+Missing relationship evidence in the Artefact Chain is at least `revise` once the related gate artefact is approved or passed.
+Declared missing evidence, declared risk or Context Graph gate effect may escalate the delivery map to `warn`, `revise` or `block`.
+
+## Skill Output
+
+Every skill output should be as short as possible and as concrete as needed.
+It must distinguish:
+
+- facts
+- evidence
+- assumptions
+- interpretations
+- missing evidence
+- the next permissible step
+
+## Do Not Duplicate
+
+The explanatory framework lives in `docs/`.
+The operating philosophy lives in `plugin/meta/agdf-constitution.md`.
+The principles live in `plugin/meta/agdf-tenets.md`.
+This contract is only the compact runtime interface for skills.

package/generated/.opencode/agents/agdf-brownfield-analysis.md

@@ -0,0 +1,142 @@
+---
+description: after gate-check permits Brownfield Review or implementation preparation, before non-trivial changes in existing systems
+mode: subagent
+---
+
+---
+name: agdf-brownfield-analysis
+description: Use this skill after gate-check or live AGDF control state confirms that Brownfield Review or implementation preparation is allowed. Use it after Approval: UR as the lightweight Brownfield Review after G-00 before PRD when existing systems may be affected, and again before non-trivial implementation after TP. Do not use it as the first AGDF skill for a fresh "I want to build/change X" prompt when approval, scope, or next allowed action is unclear.
+---
+
+# brownfield-analysis
+
+## Purpose
+Ensure delivery in an existing system is Brownfield-oriented, not Greenfield-style.
+
+The skill answers:
+
+- which existing artefacts matter
+- what already exists fully or partially
+- what can be reused, extended, or refactored
+- whether new artefacts are really needed
+- architecture, compatibility, migration, and regression impact
+- the minimal clean next step
+- whether Context Graph impact exists without automatically creating a node
+
+## Runtime Contract
+Use `../agdf-runtime-contract.md` for Quality Contract output, Context Graph fields, gate terms, and non-duplication rules.
+
+Brownfield-specific output must make evidence, missing existing-system view, parallel-structure risk, reuse strategy, and the minimal next step visible.
+When `.agdf/control/` is present, persist or link `post_ur_review` output under `.agdf/control/artefacts/<key>/BROWNFIELD_REVIEW.md`.
+
+## Modes
+
+- `post_ur_review`: use after approved durable UR to size and route the work. Output must decide `quick_task`, `structured_slice`, `structured_delivery`, or `block` with scope reason and evidence.
+- `pre_implementation_analysis`: use after approved durable TP to verify the implementation path before `CD+Tests`. Output must focus on reuse path, owners, regression risk, test impact and minimal clean implementation.
+
+Do not mix both modes silently. Name the active mode in the output.
+
+## Rules
+1. Brownfield first: understand the existing codebase before PRD/SD decisions when existing-system impact is possible, and again before implementation.
+2. Brownfield Review after `Approval: UR` is a sizing and routing step. It must visibly decide `quick_task`, `structured_slice`, `structured_delivery`, or `block` before PRD depth or implementation is chosen.
+3. Reuse-before-create: prefer existing modules, services, components, tables, endpoints, tests, and configuration.
+4. Minimal clean slice: choose the smallest durable intervention, not merely the smallest technical diff.
+5. No silent parallel structures.
+6. Existing architecture, naming, error handling, logging, security, and test conventions are binding unless deviation is justified.
+7. What is not visibly evidenced does not count as existing.
+8. Async execute paths must not become a second product-policy decision point.
+9. Visible state ownership must be checked for chat, rendering, scrolling, recovery, and status problems.
+10. SoT/runtime/product-semantics drift must be named; if official behaviour must be decided first, recommend UR or equivalent product direction.
+11. Large UI surfaces and state hooks must be checked for mixed render, view-model, derived state, orchestration, persistence, and recovery ownership.
+12. Context Graph impact must be curated; it is not a review log or version index.
+13. Specification archive migrations must follow the archive index if present.
+
+## When To Use
+- after `agdf-gate-check` permits `Brownfield Review` or live `.agdf/control/AGDF_RUN.md` names Brownfield Review as the next allowed action
+- after `agdf-gate-check` permits implementation preparation or live `.agdf/control/AGDF_RUN.md` already names Brownfield Analysis as the next allowed action
+- after `Approval: UR` when existing owners, SoT, contracts, policies, persistence, runtime paths, tests, UI, UX or architecture may affect PRD/SD scope
+- before `CD+Tests`
+- before changes to an existing repository
+- bug fixes in existing modules
+- feature extensions in existing architecture
+- refactorings
+- unclear existing coverage
+- risk of new parallel structures
+- a TP is clear but its connection to the existing system is not
+
+## Inputs
+Use what is available:
+
+- approved UR, Task Plan, `task_id`, `story_id`
+- project structure
+- affected files, modules, services, APIs, data models
+- existing tests
+- architecture notes from PRD or SD
+- repository conventions
+
+If inputs are missing, work only from observable evidence and mark gaps explicitly.
+If gate status, approval, scope or next allowed action is unclear, stop and route to `agdf-gate-check` instead of recommending PRD/SD detail or starting implementation.
+When used as Brownfield Review after `Approval: UR`, do not recommend PRD, SD, TP, or implementation until the Mode/Slice Decision is explicit, evidenced and recorded.
+
+## Workflow
+1. Identify affected tasks and scope.
+2. Find relevant existing artefacts.
+3. Assess current coverage before new implementation:
+   - `fully_done`
+   - `partially_done`
+   - `not_done`
+4. Choose reuse strategy:
+   - `extend`
+   - `refactor`
+   - `replace`
+   - `new`
+5. Assess change impact:
+   - files/modules
+   - interfaces
+   - data model/migrations
+   - backwards compatibility
+   - regression tests
+   - side effects
+6. Check parallel-structure risk.
+7. Check SoT/runtime/product-semantics drift.
+8. Check primary visible ownership for UI/status/recovery paths.
+9. Check UI monolith risk for large surfaces or central hooks.
+10. Check Context Graph impact according to `../agdf-runtime-contract.md`.
+11. Recommend the minimal clean implementation path.
+
+## Output
+Use a concise structure:
+
+```text
+## Brownfield Analysis
+- mode: post_ur_review | pre_implementation_analysis
+- decision: pass | revise | block | not_applicable
+- mode_slice_decision: quick_task | structured_slice | structured_delivery | block
+- required_next_gate: none | PRD | SD | TP | Brownfield Analysis
+- artefact: .agdf/control/artefacts/<key>/BROWNFIELD_REVIEW.md | none
+- scope:
+- evidence:
+- transparency: why later artefacts are skipped, shortened or required
+- missing_evidence:
+- current_coverage:
+- reuse_strategy:
+- risks:
+- context_graph_impact:
+- required_next_step:
+```
+
+## Pass / Revise / Block Guidance
+- `pass`: existing owners are understood, reuse path is clear, and no blocking drift or parallel structure risk remains.
+- `revise`: relevant evidence, tests, ownership, or reuse path is incomplete.
+- `block`: implementation would create a second SoT, second owner, unresolved product semantics, or hard unmitigated risk.
+
+## Forbidden
+This skill must not:
+
+- propose a Greenfield replacement without evidence
+- silently accept overlapping ownership
+- convert product-semantics drift into a mere refactor
+- create Context Graph nodes automatically
+- treat archive links as active current specification signals
+- recommend broad PRD/SD/TP or implementation by reflex before Mode/Slice Decision is recorded
+

package/generated/.opencode/agents/agdf-clean-implementation-review.md

@@ -0,0 +1,106 @@
+---
+description: inspect workarounds, fallbacks, parallel structures or symptom fixes
+mode: subagent
+---
+
+---
+name: agdf-clean-implementation-review
+description: Use this skill to determine whether an implementation is a clean primary solution or whether fallbacks, workarounds, guards, defaults, shims, or parallel structures have made it unnecessarily complex. Use it after code changes, before QA, or whenever symptom treatment is suspected.
+---
+
+# clean-implementation-review
+
+## Purpose
+Evaluate implementation integrity.
+
+This skill answers:
+
+- was the task solved with a clean primary solution
+- was the root cause fixed or only masked
+- were unnecessary fallbacks, workarounds, guards, defaults, or shims introduced
+- were unnecessary parallel structures introduced
+- does the solution fit the existing architecture
+- is it maintainable or workaround-heavy
+
+## Runtime Contract
+Use `../agdf-runtime-contract.md` for Quality Contract output, Context Graph fields, gate terms, and non-duplication rules.
+
+Clean-review-specific output must make the primary solution, fallbacks, workarounds, parallel structures, exit criteria, and next cleanup/review step visible.
+
+## Rules
+1. Clean primary solution before fallback.
+2. Root cause before symptom masking.
+3. Fallbacks are exceptions, not target architecture.
+4. Every retained fallback needs rationale, target state, and exit condition.
+5. No silent parallel structures.
+6. Brownfield fit is mandatory.
+7. Maintainability matters; "works somehow" is not enough.
+8. Async execute paths must not decide product rules again.
+9. Shared finalization or merge rules belong in one owner.
+
+## When To Use
+- after `CD+Tests`
+- before QA
+- when a solution contains many guards, defaults, or special paths
+- when wrappers or helper layers were introduced
+- when symptom treatment is suspected
+- when fallback, retry, or compatibility-shim logic was added
+- when code works but the architecture looks questionable
+
+## Inputs
+Use what is available:
+
+- Task Plan
+- Code Deliverables
+- changed files
+- tests and test results
+- `agdf-code-review` or Code Review Report
+- QA Report
+- Brownfield Analysis findings
+- PRD or SD architecture notes
+
+If evidence is missing, mark it explicitly.
+
+## Workflow
+1. Understand the intended change.
+2. Identify the primary implementation path.
+3. Identify fallbacks, guards, defaults, shims, retries, wrappers, and catch-all branches.
+4. Decide whether each is justified.
+5. Check for parallel ownership.
+6. Check Brownfield fit.
+7. Assess whether the implementation fixes the root cause.
+8. Assign a decision:
+   - `pass`
+   - `revise`
+   - `block`
+   - `not_applicable`
+
+## Output
+Use this compact structure:
+
+```text
+## Clean Implementation Review
+- decision:
+- primary_solution:
+- evidence:
+- fallbacks_retained:
+- workaround_or_shim_risk:
+- parallel_structure_risk:
+- brownfield_fit:
+- missing_evidence:
+- required_next_step:
+```
+
+## Pass / Revise / Block Guidance
+- `pass`: primary solution is clean, tested, and integrated with existing owners.
+- `revise`: solution works but contains avoidable fallback, unclear ownership, or missing evidence.
+- `block`: solution creates a second SoT, a second owner, unbounded fallback, or masks unresolved product semantics.
+
+## Forbidden
+This skill must not:
+
+- accept fallback-heavy logic as target architecture
+- hide unjustified workarounds
+- treat green tests as proof of solution integrity
+- decide final QA
+

package/generated/.opencode/agents/agdf-code-review.md

@@ -0,0 +1,100 @@
+---
+description: mandatory CR step after code changes, focused on defects, regression and security findings
+mode: subagent
+---
+
+---
+name: agdf-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 `../agdf-runtime-contract.md` for Quality Contract output, Context Graph fields, gate terms, and non-duplication rules.
+
+Code-review-specific output must make actual findings, missing review scope, evidence strength, and the next required step visible.
+
+## 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.
+
+## 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:
+```
+
+## 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.
+
+## 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
+