create-agdf 0.12.0 → 0.13.1

package/generated/submissions/openai/agdf/meta/contracts/quality.md

@@ -0,0 +1,157 @@
+# AGDF Runtime Contract — Quality
+
+## Quality Readiness Projection
+
+After CD+Tests, when any of the four review/QA artefacts exists, surfaces may show one compact
+derived `Quality Readiness` projection. It answers the user-facing question "what is the current
+quality outcome and what should happen next?" without replacing evidence or creating another
+decision authority.
+
+- It contains exactly four rows, in this order: `Plan coverage` from `task-plan-review`,
+  `Solution integrity` from `clean-implementation-review`, `Code quality` from `code-review`,
+  and `QA decision` from `qa-gate`.
+- `qa-gate` is always labeled as the sole decision owner. The other three rows are evidence
+  dimensions, not competing pass/revise/block decisions.
+- Overall status reuses canonical severity ordering. Missing or conflicting required evidence
+  must not render `pass`; surface `revise` or `block` with the decisive reason and one permitted
+  next action instead.
+- The projection is derived, non-persistent and non-authorizing. It cannot accept an approval,
+  advance a gate, suppress a report or replace the Run Status Card, Gate Transition Card, JSON
+  projection or durable review artefacts.
+- Show compact rows on `pass`. On `revise` or `block`, expand only the decisive row with its
+  canonical report reference; do not paste complete reports into chat.
+
+
+## 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.
+
+### Chat and Tool-Call Discipline
+
+Chat output shows decisions and outcomes. Files show evidence and detail. The agent
+minimises both the number of tool calls and the amount of accompanying chat text. This
+is surface-agnostic: it changes agent behaviour and framework text, not host rendering.
+Whether a host renders a tool-call block visibly is a host concern; the framework ensures
+the agent makes fewer calls and produces less text around them.
+
+Skill output compaction:
+
+- QA, Code Review, TP Review and Clean Implementation Review output is 1 line at `pass`:
+  `<skill>: pass — <one-line summary>`.
+- At `revise`/`block`: the decisive dimension, reason and next action. The Quality
+  Readiness projection is shown only at `revise`/`block`, not at `pass`.
+- Full reports remain in durable files; the chat references the path.
+
+Tool-call batching:
+
+- `RUN_STATE.md` is written once per user gate approval, not once per field change. The
+  agent keeps intermediate state in memory between gate approvals and writes the complete
+  updated state in one operation.
+- The agent does not `read` existing artefacts for format reference. Skill instructions
+  carry the format/structure inline. If a specific existing artefact must be inspected
+  for content (not format), the read has no accompanying commentary.
+- Artefact writes are silent: the agent names the path and a 1-line summary only when an
+  artefact is first created or significantly changed — not on every state update.
+- Validation commands (tests, integrity, diff) show pass/fail only. Full output appears
+  only on failure.
+
+Always visible:
+
+- Gate decisions (Run Status Card, Gate Transition Card, approval question).
+- Post-acceptance narration (1 line per gate transition).
+- Delivery summary (UAT/OR compact summary).
+- Errors, blockers and evidence at `revise`/`block`.
+
+
+## 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
+
+
+## Normalized Review Gaps
+
+This section is the sole normative owner for review-gap classification and routing. An applicable
+finding from Task Plan Review, Clean Implementation Review or Code Review carries exactly one
+normalized gap type and one routing target:
+
+| gap_type | meaning | routing_target |
+|---|---|---|
+| `requirements_gap` | approved product behavior or an acceptance criterion is missing or contradictory | `PRD`; use `UR` only when user intent or scope changed |
+| `design_gap` | technical ownership, architecture, fallback policy, exit criterion or a prohibited parallel structure was not decided | `SD` |
+| `plan_gap` | an approved requirement or design obligation lacks an executable task, test or evidence mapping | `TP` |
+| `implementation_gap` | code or a surface does not fulfil an approved requirement, design or task | `CD+Tests` |
+| `evidence_gap` | required test, runtime or visible evidence is absent or insufficient | `evidence_obligation` |
+| `emergent_risk` | implementation exposes a concrete risk not reasonably decidable from approved artefacts | earliest affected `UR | PRD | SD | TP | CD+Tests | evidence_obligation` target after explicit assessment |
+
+Normalized finding rows use these fields in order:
+
+`finding_id | gap_type | routing_target | gap_status | evidence | required_next_step`
+
+- `finding_id` is stable within the durable review report.
+- `gap_type` is exactly one type from the table above.
+- `routing_target` is exactly `UR | PRD | SD | TP | CD+Tests | evidence_obligation` and must agree
+  with the fixed route above. `requirements_gap` may use `UR` only with evidence of changed user
+  intent or scope. `emergent_risk` requires an explicit earliest-owner assessment.
+- `gap_status` is exactly `open | resolved`.
+- `evidence` names concrete source, diff, test, observation or missing proof.
+- `required_next_step` is exactly one executable action consistent with the routing target.
+
+Missing, unknown or contradictory fields fail closed as an open gap. Consumers must not silently
+reclassify a finding. Classification is non-authorizing: it cannot edit or approve UR, PRD, SD or TP,
+advance a gate or replace a review decision. `qa-gate` consumes the normalized findings and cannot
+return `pass` while any applicable finding is open or invalid.
+
+`none` is permitted only as a presentation sentinel on a fulfilled UX Intent Fidelity row.
+It is not a seventh normalized finding type and must not appear in a normalized finding row.
+
+A consumer may repeat the field order and allowed scalar values needed to emit valid output. It must
+reference this section for meanings and routes instead of maintaining a second complete mapping.
+
+## UX Intent Fidelity
+
+When an approved PRD contains applicable UX criteria, `task-plan-review` produces an additional
+evidence matrix with these columns in order:
+
+`prd_criterion | working_mode_state | task_id | visible_evidence | fidelity_status | gap_type`
+
+`fidelity_status` is exactly `fulfilled | partial | missing | not_verifiable`. A fulfilled row uses
+the `none` sentinel. Any non-fulfilled row uses the applicable normalized type from `Normalized
+Review Gaps`; it may also emit the normalized finding shape when routing detail is required.
+
+This matrix verifies PRD-to-TP coverage and TP-to-code/surface fulfilment. It does not create product
+requirements and does not decide QA. A missing implementation-relevant PRD requirement is a
+`requirements_gap` and routes to PRD revision. `qa-gate` consumes this evidence and cannot return
+`pass` while an applicable row is `partial`, `missing` or `not_verifiable`, or while a visible-behavior
+claim has code evidence without visible evidence. The four-row Quality Readiness projection and
+`qa-gate` sole decision ownership remain unchanged.
+
+A skill may briefly remind this shape, but must not duplicate a complete code or rule matrix.
+
+
+## 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

package/generated/submissions/openai/agdf/meta/contracts/task-target-resolution.md

@@ -0,0 +1,102 @@
+# AGDF Runtime Contract — Task Target Resolution
+
+## Purpose And Ordering
+
+Resolve the user's primary work target before repository activation, Scope Classification, mode
+selection or gate evaluation. Repository governance is downstream of the task target; the current
+working directory, an inspected repository or a source mentioned as evidence must never become the
+work target by accident.
+
+The canonical order is:
+
+1. resolve or revalidate the task target;
+2. derive the governance target from that resolved target;
+3. activate repository-local AGDF control only for that governance target;
+4. then apply read-only orientation, Scope Classification, mode selection and gate evaluation.
+
+If task-target resolution is unresolved, steps 2–4 and every mutation are forbidden.
+
+## Resolution Result
+
+Use one normalized result:
+
+- `resolution_state`: `resolved | unresolved`
+- `reason_code`: `explicit_target | continued_target | multiple_plausible_targets |
+  target_content_mismatch | target_unavailable | no_reliable_target`
+- `primary_target`: exactly one requested work object when resolved, otherwise empty
+- `evidence_sources`: zero or more mentioned or inspected sources that do not gain mutation authority
+- `working_directory`: execution context only, never target authority by itself
+- `governance_target`: the repository whose control state applies to the primary target, otherwise empty
+- `target_changed`: whether an explicit new target replaced the previously confirmed target
+- `next_action`: required clarification, supply or retry action when unresolved
+
+A resolved result requires a non-empty `primary_target` and a reason code of `explicit_target` or
+`continued_target`. An unresolved result requires an empty `primary_target`, an empty
+`governance_target`, one of the four unresolved reason codes and a non-empty `next_action`.
+Contradictory or incomplete results fail closed.
+
+## Target Authority Precedence
+
+Resolve in this order:
+
+1. an explicit file, artefact or repository named as the work target in the current user turn;
+2. a previously confirmed target only when the current turn unambiguously continues the same action,
+   object and scope;
+3. the current repository or working directory only when the request explicitly or deictically asks
+   for work on "this project", "this repository" or an equivalent current-scope reference;
+4. otherwise `no_reliable_target`.
+
+An explicit current-turn target always replaces an inherited target. Make the change visible when
+the previous target could otherwise remain plausible.
+
+Do not fall back to the working directory, a neighboring file or an evidence source when the
+explicit target is unavailable or its content does not support the requested change.
+
+## Evidence And Mutation Boundary
+
+Reading, inspecting, mentioning or relying on a repository or artefact makes it an evidence source,
+not a mutation target. Evidence access never grants mutation authority and never activates that
+repository's AGDF control state.
+
+Derive `governance_target` only from:
+
+- the repository containing the resolved `primary_target`; or
+- an explicit user statement that a named repository governs the target.
+
+An external standalone artefact may have no repository governance target. In that case the router
+continues with the applicable non-repository path; it must not borrow governance from the current
+working directory.
+
+## Continuation And Target Change
+
+A confirmed target may continue across related turns only when the current request remains
+unambiguous. Revalidate it before every mutation or gate decision. New explicit target evidence wins.
+New ambiguity ends the inherited binding and produces `multiple_plausible_targets`.
+
+When a durable AGDF run exists, its Source And Scope State may record the confirmed target as
+evidence. It does not override a newer explicit user target. Outside a run, continuation remains
+transient conversation state; do not create a global target store or a second run-state owner.
+
+## Fail-Closed States
+
+- `multiple_plausible_targets`: more than one work target remains plausible; list the candidates and
+  request the smallest clarification.
+- `target_content_mismatch`: the requested content change is not supported by the explicit target's
+  observable content; name the mismatch and ask whether the target or requested change should change.
+- `target_unavailable`: the named file, attachment or artefact cannot be inspected; request supply or
+  access and offer a visible retry.
+- `no_reliable_target`: neither an explicit target nor an unambiguous continuation exists; request a
+  target.
+
+These states forbid repository activation, Scope Classification, gate evaluation and mutation.
+Never silently expand scope to make the request fit a different project.
+
+## Presentation Boundary
+
+`contracts/interaction.md` owns the visible, non-authorizing Task Target Orientation.
+`create-agdf/lib/interaction-presentation.js` owns its rendering. The renderer projects a normalized
+result; it must not resolve targets, derive governance or become a state store.
+
+Show orientation when target/context separation is material, when the target changes, or when the
+result is unresolved. Avoid redundant presentation for an obvious unchanged target. Presentation
+never grants mutation or gate authority.

package/generated/submissions/openai/agdf/skills/brownfield-analysis/SKILL.md

@@ -0,0 +1,175 @@
+---
+name: 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 these focused runtime-contract modules:
+
+- `../../meta/contracts/gate-transition.md`
+- `../../meta/contracts/modes.md`
+- `../../meta/contracts/context-graph.md`
+- `../../meta/contracts/quality.md`
+
+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`, `verified_change`, `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.
+
+In `post_ur_review`, also record `delivery_context`, `ui_ux_impact`, `ui_ux_impact_reason` and
+`ux_intent_definition_required` using the single classification and routing contract in
+`../../meta/contracts/gate-transition.md`. Greenfield records make existing-system evidence explicitly
+not applicable; Brownfield records cite repository evidence. Do not create a second Greenfield router.
+
+## 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`, `verified_change`, `structured_slice`, `structured_delivery`, or `block` before PRD depth or implementation is chosen. Persist the completed review and its decision, scope reason, evidence and required next gate in the same internal operation; mark the review `done` only after both the artefact and canonical run projection are complete. An interrupted, incomplete or legacy record stays at fail-closed `Mode/Slice Decision` recovery without another user approval.
+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.
+14. In `post_ur_review`, evaluate unchanged compact paths first. For a structured candidate, apply
+    only the `Structured Depth Decision` in `modes.md`; do not recreate its trigger/check matrix in
+    this skill.
+15. A positive structured decision requires `depth_policy_version: 1`,
+    `depth_facts_status: complete`, complete evidence for all seven bounded-slice checks, a primary
+    reason code, rejected alternative and evidence references. A decisive full-depth trigger may
+    support `structured_delivery`; `structured_slice` requires every bounded-slice check to pass.
+16. Missing or conflicting decisive facts without an already-evidenced full-depth trigger persist
+    the existing `block` decision with `depth_facts_missing | depth_facts_conflicting`, named facts,
+    their evidence owner where known, a Brownfield Review link and a precise next action for evidence
+    completion and Brownfield/Mode-Slice re-evaluation.
+17. Owner, file, consumer, task or derived-path counts must never select a structured depth by
+    themselves.
+
+## When To Use
+- after `gate-check` permits `Brownfield Review` or the selected canonical run record names Brownfield Review as the next allowed action
+- after `gate-check` permits implementation preparation or the selected canonical run record 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 `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 `../../meta/contracts/context-graph.md`.
+11. Recommend the minimal clean implementation path.
+12. In `post_ur_review`, record `depth_policy_version`, `depth_facts_status`,
+    `primary_reason_code`, `decisive_full_depth_triggers`, `rejected_alternative`,
+    `missing_or_conflicting_facts`, `depth_evidence_refs` and evidence for all seven bounded-slice
+    check IDs in the Brownfield Review. Then persist the completed review and the existing
+    Mode/Slice Decision atomically.
+
+## 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 | verified_change | 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:
+```
+
+For `post_ur_review`, include the four UI/UX routing fields immediately after `scope`. If UX intent
+definition is required, its `ready | blocked | not_applicable` result must be visible before PRD
+readiness. A required `blocked` result is at least `revise` for this routing step.
+
+For a structured `post_ur_review` candidate, also include the complete `Structured Depth Evidence`
+section from `BROWNFIELD_REVIEW.md`. The decision projection must show the primary reason, decisive
+dimensions, bounded-slice result, rejected alternative, evidence and required next gate. For
+missing/conflicting facts, show product-language `depth_unresolved` while persisting `block`; name
+the gap and exact recovery action. Structural instruction checks can detect missing contract
+elements but do not prove semantic model compliance or live-host behavior.
+
+## 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/submissions/openai/agdf/skills/brownfield-analysis/help.md

@@ -0,0 +1,23 @@
+## NAME
+
+`brownfield-analysis` - brownfield analysis
+
+## SYNOPSIS
+
+`/brownfield-analysis` [`--help`|`-h`]
+
+## DESCRIPTION
+
+Ensures implementation in an existing system is Brownfield-oriented rather than Greenfield-style. Analyzes existing artefacts, current coverage, reuse strategy, risks, and the minimal clean implementation path.
+
+## EXAMPLES
+
+Trigger the skill:
+
+```text
+> /brownfield-analysis
+```
+
+## SEE ALSO
+
+See the full SKILL.md for detailed workflow, output format, and decision logic.

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

@@ -0,0 +1,126 @@
+---
+name: 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 these focused runtime-contract modules:
+
+- `../../meta/contracts/quality.md`
+- `../../meta/contracts/context-graph.md`
+
+Clean-review-specific output must make the primary solution, fallbacks, workarounds, parallel structures, exit criteria, and next cleanup/review step visible.
+Applicable findings must use `../../meta/contracts/quality.md` §Normalized Review Gaps. This skill
+must distinguish a missing upstream decision from implementation that violates an approved decision.
+
+## 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.
+10. Missing canonical ownership, fallback policy, exit criteria or parallel-structure decisions are
+    upstream gaps; do not invent those decisions during review.
+11. Actual code that violates an approved design or plan is an implementation gap.
+12. Missing, unknown or contradictory classifications fail closed and stay open.
+
+## 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
+- `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:
+```
+
+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.
+
+## 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.
+
+### Compact Chat Output
+
+At `pass`: one line — `Clean Review: pass — <one-line summary>`.
+At `revise`/`block`: show the specific fallback/workaround/parallel-structure risk with file references.
+
+## 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
+- create a missing design, plan or product decision during review
+- silently repair or reclassify an invalid normalized finding

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

@@ -0,0 +1,23 @@
+## NAME
+
+`clean-implementation-review` - clean implementation review
+
+## SYNOPSIS
+
+`/clean-implementation-review` [`--help`|`-h`]
+
+## DESCRIPTION
+
+Evaluates solution integrity: whether the implementation is a clean primary solution or has become unnecessarily complex through fallbacks, workarounds, guards, defaults, shims, or parallel structures.
+
+## EXAMPLES
+
+Trigger the skill:
+
+```text
+> /clean-implementation-review
+```
+
+## SEE ALSO
+
+See the full SKILL.md for detailed workflow, output format, and decision logic.