waypoint-codex 1.0.14 → 1.0.16

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "waypoint-codex",
-  "version": "1.0.14",
+  "version": "1.0.16",
   "description": "Make Codex better by default with stronger planning, code quality, reviews, tracking, and repo guidance.",
   "license": "MIT",
   "type": "module",

package/templates/.agents/skills/collapse-fragmented-modules/SKILL.md

@@ -1,56 +1,35 @@
 ---
 name: collapse-fragmented-modules
-description: Consolidate over-fragmented existing code within a defined scope. Use when a feature, module, or directory has been split into too many tiny files, thin wrappers, pass-through layers, single-use helpers, local-only types, local-only constants, or other low-value fragments that make future changes harder. Reduce file count by merging code that changes together, removing unnecessary indirection, and reorganizing the scope into a smaller number of cohesive files without changing intended behavior.
+description: Consolidate internal file fragmentation inside an existing module, feature, or directory when the code is split into too many tiny files, thin wrappers, pass-through layers, single-use helpers, or local-only types/constants. Use when the task is to reduce file count and remove low-value indirection without changing schemas, public contracts, persisted formats, or cross-boundary behavior.
 ---
 
-Refactor the given scope to reduce unnecessary file fragmentation.
-
-Treat this as consolidation work, not feature work. Preserve behavior while making the code easier to change.
-
-Within the requested scope:
-
-1. Identify files that should be merged, removed, or kept.
-   Target especially:
-   - tiny files with little logic
-   - single-use helpers
-   - local-only types
-   - local-only constants
-   - thin wrappers
-   - pass-through adapters
-   - split files that always change together
-
-2. Merge code that belongs to the same feature or responsibility into a smaller number of cohesive files.
-
-3. Remove low-value indirection.
-   Collapse wrappers, adapters, and helper layers that do not enforce a real boundary or protect meaningful complexity.
-
-4. Keep splits only when they are justified by one of these:
-   - real shared reuse
-   - clear architectural boundary
-   - meaningful file size
-   - clearly separate responsibility that does not usually change with neighboring code
-
-5. Prefer edit locality over theoretical separation.
-   A routine change in this scope should touch as few files as reasonably possible.
-
-6. Preserve external behavior and stable public contracts unless the user asked for behavioral change.
-
-7. Update imports, exports, and tests to match the new structure.
-
-8. Delete obsolete files as part of the same work. Do not leave dead fragments behind.
-
-Rules:
-- Do not keep tiny files just because they already exist.
-- Do not preserve thin wrappers, pass-through hooks, local-only type files, or local-only constants files unless they provide real value.
-- Do not split by category alone.
-- Do not create a new abstraction while trying to remove fragmentation.
-- Prefer one cohesive file over several microscopic files when the code changes together.
-- Keep public boundaries clean, but aggressively collapse internal fragmentation.
-- If unsure whether two files should be merged, merge them unless there is a clear boundary reason not to.
-
-Before finishing, do a consolidation pass:
-- remove newly obsolete files
-- collapse redundant exports
-- simplify import paths
-- check whether the same feature is still spread across too many files
-- reduce file count further if behavior and clarity allow
+# Collapse Fragmented Modules
+
+## Core Instruction
+Consolidate internal fragmentation into the smallest cohesive file set that preserves current behavior.
+
+## Default Workflow
+1. Map the scope and classify each file as merge, keep, or delete.
+2. Merge code that changes together or serves one local responsibility.
+3. Remove thin wrappers, pass-through layers, and local-only helper/type/constant files.
+4. Update imports, exports, and tests to match the new file shape.
+5. Delete obsolete fragments and rerun a consolidation pass for any remaining avoidable splits.
+
+## Rules
+- Do not create new abstractions to justify keeping fragmentation.
+- Do not keep a split file unless at least one is true: multiple live callers reuse it, it sits on a real public or cross-boundary interface, it protects a distinct runtime or lifecycle boundary, or merging would create an unreasonably large file.
+- Do not preserve local-only types, constants, or helpers in separate files unless they are reused outside the consolidation scope.
+- Do not split code by category alone.
+- Do not leave obsolete wrappers, adapters, re-export layers, or dead fragment files in place after the merge.
+- Do not change schemas, wire formats, persisted state, or public contracts in this skill.
+
+## Exception Rule
+If a file is tied to a real external boundary that must remain separate, keep only that boundary file and consolidate everything else around it. If the requested work requires schema, contract, migration, or compatibility changes to proceed, stop and hand off to the appropriate redesign or hard-cut skill instead of stretching this one.
+
+## Output Contract
+Report:
+- files merged
+- files deleted
+- files kept with the specific boundary reason
+- imports, exports, or tests updated
+- any remaining split that is still justified

package/templates/.agents/skills/collapse-fragmented-modules/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Collapse Fragmented Modules"
+  short_description: "Consolidate internal file fragmentation without changing contracts"
+  default_prompt: "Use $collapse-fragmented-modules when an existing module, feature, or directory is split into too many tiny files, thin wrappers, pass-through layers, single-use helpers, or local-only types/constants. Merge the internal pieces, delete obsolete fragments, and keep only splits that are justified by reuse or a real public or cross-boundary boundary."

package/templates/.agents/skills/edit-at-the-right-layer/SKILL.md

@@ -1,26 +1,33 @@
 ---
 name: edit-at-the-right-layer
-description: Make changes at the true ownership layer instead of patching nearby call sites. Use when implementing features, bug fixes, or refactors where behavior should be corrected at its source of truth rather than through wrappers, flags, or duplicated logic.
+description: Use when a change should be implemented at the owning layer of an existing behavior, not in callers, wrappers, adapters, or duplicated checks. Trigger only when the main decision is which layer owns the contract. Examples: moving validation into the domain model, fixing serialization in the owning mapper, or deleting a controller workaround after the service layer can enforce the rule.
 ---
 
-Identify where this behavior is actually owned, then edit there.
+# Edit At The Right Layer
 
-## Goal
+## Core Instruction
+Change the layer that owns the contract, not the layer that merely observes the failure.
 
-Fix or extend behavior at the layer that owns the contract so future changes stay local and coherent.
-
-## Workflow
-
-1. Trace the path from entry point to ownership.
-2. Identify the contract owner (domain/service/model/state boundary) for the requested behavior.
-3. Prefer changing that owner over adding patches in callers, controllers, views, adapters, or wrappers.
-4. Remove compensating logic that became unnecessary after the ownership-layer fix.
-5. Update boundary tests at the owning layer and only add higher/lower-layer tests when they cover a distinct risk.
+## Default Workflow
+1. Trace the request path to the first layer that can enforce the behavior once.
+2. Name the owning layer and the exact contract it must own.
+3. Implement the behavior at that layer.
+4. Remove caller-side workarounds, duplicate checks, and pass-through code made obsolete by the fix.
+5. Update tests at the owning layer first; add outer-layer tests only for distinct integration risk.
 
 ## Rules
-
-- Do not patch symptoms in outer layers when the source-of-truth layer can be fixed directly.
-- Do not add pass-through wrappers or compatibility branches as a default response.
+- Do not patch symptoms in controllers, views, clients, wrappers, or adapters when the source-of-truth layer can enforce the behavior.
 - Do not duplicate the same rule across multiple layers.
-- If a temporary cross-layer patch is unavoidable, mark it as transitional and remove it in the same phase whenever possible.
-- Prefer one clear owner per rule.
+- Do not add compatibility branches, feature flags, or fallback paths unless a bounded migration requires them and they are removed in the same phase.
+- Do not leave temporary cross-layer patches in place after the owning-layer fix is available.
+- Do not use this skill for pure redesign, greenfield architecture, or broad refactors whose goal is to rebase the system; use the more appropriate skill for that work.
+
+## Exception Rule
+If the owning layer cannot be changed in the current phase because of an external dependency, a hard compatibility constraint, or an unowned migration boundary, allow a temporary outer-layer patch only when it is isolated, explicitly time-bounded, and paired with a tracked follow-up to move the rule inward.
+
+## Output Contract
+- Owning layer identified
+- Change made at that layer
+- Obsolete outer-layer logic removed or retained with a reason
+- Tests updated at the owning layer
+- Exception used, if any, with the follow-up plan

package/templates/.agents/skills/edit-at-the-right-layer/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "Edit At The Right Layer"
-  short_description: "Apply changes at the true ownership layer"
-  default_prompt: "Use $edit-at-the-right-layer to locate the source-of-truth ownership layer, implement the change there, and remove outer-layer patches or duplicated logic."
+  short_description: "Implement existing behavior at its owning layer"
+  default_prompt: "Use $edit-at-the-right-layer when the main decision is where an existing behavior should be owned. Trace to the source-of-truth layer, change it there, remove outer-layer workarounds or duplicate checks, and avoid using this skill for broad redesigns."

package/templates/.agents/skills/execution-reset/SKILL.md

@@ -1,28 +1,72 @@
 ---
 name: execution-reset
-description: Recover momentum in long-running implementation plans when progress degrades into tiny local edits, repeated patching, or phase drift. Use when working from a referenced plan or roadmap and the current session is stalled, compacted, or no longer completing meaningful milestones. Reconstruct actual progress from the codebase, detect whether the current phase is stuck, and choose the next substantial work package that advances or completes the phase.
+description: Recover stalled mid-execution work on a referenced implementation plan when progress has degraded into local edits, repeated patching, or phase drift. Use only after a phase has already started and the current session is no longer advancing a concrete milestone. Reconstruct actual progress from the codebase, test for a stall, and select the next substantial work package that advances or completes the active phase.
 ---
 
-Rebuild state from the current codebase and the referenced plan, not from memory.
-
-1. Identify the active phase and its intended outcome.
-2. Inspect the current implementation and determine:
-   - complete
-   - partial
-   - missing
-   - broken or stale
-3. Decide whether execution is stalled.
-4. If stalled, restate the current phase as concrete system behavior.
-5. Pick exactly one substantial work package that will:
-   - complete a sub-milestone
-   - unblock the main dependency
-   - or finish the end-to-end path
-6. Execute that package.
-7. Re-check whether system capability materially increased.
-
-Use this output shape:
-
-## Execution Reset
+## Core Instruction
+Reset execution from evidence, not memory, when an in-progress phase has stalled and the next meaningful unit of work is unclear.
+
+## Required Inputs
+You must have all of the following before you act:
+1. A referenced plan or roadmap.
+2. The active phase or checkpoint within that plan.
+3. The relevant workspace or codebase context needed to inspect current state.
+
+## Blocked Behavior
+If any required input is missing, do not infer it, do not continue, and do not propose a reset package.
+State exactly which input is missing and request it.
+
+## Trigger Boundary
+Use this skill only when:
+1. Work on the current phase has already started.
+2. The current session is not advancing the phase toward completion.
+3. The problem is execution drift, not plan creation, backlog grooming, or initial scoping.
+
+Do not use this skill at plan start or for ordinary planning questions.
+
+## Stall Test
+Treat execution as stalled when inspection shows at least one of the following:
+- Three consecutive implementation attempts have changed files or run checks without moving any acceptance condition from missing or partial to complete.
+- The same local area has been patched twice or more in the current phase without producing a measurable milestone change.
+- The current state is still partial, broken, or stale after a review of the codebase, and no next step can be named that clearly advances the phase end-to-end.
+- Progress is limited to micro-edits, reformatting, or cleanup that does not change the phase outcome.
+
+The stall test is objective: if none of the conditions above hold, do not declare a reset.
+
+## Workflow
+1. Identify the active phase and its intended outcome from the plan.
+2. Inspect the codebase and classify the phase state as complete, partial, missing, or broken/stale.
+3. Apply the stall test.
+4. If stalled, restate the phase as concrete system behavior and identify one work package that will complete a sub-milestone, unblock the main dependency, or complete the end-to-end path.
+5. Execute only that work package.
+6. Re-check whether the change moved at least one acceptance condition from missing or partial to complete.
+
+## Rules
+- Do not continue with micro-edits unless they directly unblock the selected work package.
+- Do not polish incomplete phases.
+- Do not trust prior session context over the codebase.
+- Do not select more than one work package per reset cycle.
+- Do not expand scope to adjacent cleanup unless it is required for the chosen package to finish.
+
+## Exception Rule
+You may relax the stall test only when the workspace evidence shows a phase-critical blocker outside the current code path, such as a missing prerequisite, unavailable dependency, or an upstream change that makes the current plan invalid. This exception is bounded:
+- The blocker must be named.
+- The blocker must be evidenced in the inspected state.
+- The response must switch to blocker resolution, not continued execution.
+
+## Stop Condition
+Stop the reset cycle immediately when one of these is true:
+- The selected package cannot be executed because a required input is still missing.
+- The selected package fails to move at least one acceptance condition from missing or partial to complete after a concrete attempt.
+- The inspected codebase shows the phase is no longer the right unit of work.
+
+## Next Action If Reset Package Fails
+If the chosen package fails, do not chain into a second package. Report the blocker, the evidence, and the smallest next question or dependency needed to continue.
+
+## Output Contract
+Use this shape:
+
+### Execution Reset
 ### Active Phase
 [phase]
 
@@ -36,20 +80,13 @@ Use this output shape:
 - Broken/stale: [...]
 
 ### Stall Diagnosis
-[why progress is not advancing]
+[why the stall test passed, or why it did not]
 
 ### Next Work Package
-[one substantial chunk]
+[one substantial chunk, or the blocker if execution is stopped]
 
 ### Definition of Done
-[concrete completion conditions]
+[concrete completion conditions for the package]
 
 ### Plan Correction
 [only if the plan is locally stale]
-
-Rules:
-- Do not continue with micro-edits unless they directly unblock the chosen work package.
-- Do not polish incomplete phases.
-- Do not trust prior session context over the codebase.
-- Prefer end-to-end completion over local cleanup.
-- Revise the current phase if the original plan no longer matches reality, but do not rewrite the whole roadmap unless necessary.

package/templates/.agents/skills/execution-reset/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "Execution Reset"
-  short_description: "Reset stalled plan execution and restore phase progress"
-  default_prompt: "Use $execution-reset with the active plan path and current phase to reset execution momentum and drive meaningful checklist progress."
+  short_description: "Recover stalled mid-execution work on an active plan phase"
+  default_prompt: "Use $execution-reset only after a plan phase has already started and execution has stalled; provide the referenced plan, the active phase, and the relevant workspace context so the skill can inspect current state, test for a stall, and pick one substantial next work package."

package/templates/.agents/skills/find-duplicate-ownership/SKILL.md

@@ -0,0 +1,120 @@
+---
+name: find-duplicate-ownership
+description: Find duplicate ownership, hidden second sources of truth, and contract drift in layered codebases. Use when reviewing normalization, validation, defaulting, canonicalization, persistence mapping, runtime-vs-durable state, duplicated helpers, query or cache ownership, or any "who owns this rule?" architecture question. Especially useful for SSOT audits across frontend, backend, shared core, and adapter layers, and when the user explicitly asks for duplicate-ownership exploration with subagents.
+---
+
+# Find Duplicate Ownership
+
+## Overview
+
+Audit the codebase for multiply-owned rules instead of blindly grepping `normalize`.
+Classify each case as real SSOT drift, local dedupe cleanup, legitimate boundary work, or legitimate domain constraint.
+
+## Workflow
+
+1. Define the audit target before searching.
+   Narrow by feature, contract, package, service, or file slice when possible.
+   Good targets: session state, persistence contracts, runtime geometry, provider options, path helpers, JSON canonicalization.
+
+2. Build a taxonomy first.
+   Use these buckets:
+   - `architecture / SSOT bug`: same business rule owned in more than one layer
+   - `local dedupe cleanup`: same helper semantics copied nearby
+   - `legitimate boundary adapter`: wire, vendor, or untrusted input transformation with one clear owner
+   - `legitimate domain constraint`: runtime clamp, math, security, or path logic that cannot be removed architecturally
+
+3. Search for ownership smells, not words.
+   Look for:
+   - validation, defaults, or clamps duplicated across frontend and backend
+   - generated bindings or shared type aliases hiding the real contract owner
+   - runtime mutators calling boundary repair or coercion
+   - persisted shape differing from runtime shape and requiring glue
+   - query, store, or cache logic re-owning domain policy
+   - two helpers with the same semantics but different names
+   - thin wrapper functions that hide a second path
+   - copied deterministic serializers or hash inputs
+   - local component, hook, or service helper clones instead of one domain owner
+
+4. Separate true duplicates from valid boundaries.
+   Do not flag these by default:
+   - pure UI formatting or presentation transforms
+   - provider or protocol adapters with one clear boundary owner
+   - security or path canonicalization with one clear security owner
+   - runtime-only clamp or math logic with one clear runtime owner
+
+5. For each finding, name the winning owner.
+   Always answer:
+   - what exact rule is multiply owned
+   - who owns it today
+   - who should own it
+   - what gets deleted in a hard cut
+   - whether anything remains as real boundary adapter code
+
+## Heuristics
+
+- Be suspicious when frontend and backend both shape or repair the same contract.
+- Be suspicious when trusted runtime state is "normalized" after every mutation.
+- Be suspicious when query glue, cache glue, or store glue maps between two supposedly canonical state shapes.
+- Be suspicious when multiple languages or services define the same min, max, enum, or default constants independently.
+- Be suspicious when a helper exists in a domain library and again in a hook, component, controller, or service.
+
+## Subagent Use
+
+Only use subagents when the user explicitly asks for them or asks for parallel exploration.
+
+Reusable read-only agent definitions live in `.codex/agents/`:
+
+- `ownership_taxonomy_mapper.toml`
+  Use first for broad slice mapping and taxonomy.
+- `duplicate_ownership_explorer.toml`
+  Use one per independent slice: persistence, runtime state, contracts, helpers, adapters.
+- `ssot_judge.toml`
+  Use after explorers when you need one strict verdict on winning owner and hard-cut cleanup.
+
+Recommended fan-out:
+
+- 1 taxonomy mapper
+- 2 to 5 explorers for disjoint slices
+- 1 SSOT judge to merge and challenge findings
+
+Tell subagents:
+
+- stay read-only
+- cite files and symbols
+- do not propose compatibility shims
+- distinguish duplicate ownership from legitimate boundary work
+- return winner owner plus delete or keep plan
+
+## Output Contract
+
+For each finding, return:
+
+1. severity
+2. rule or contract being multiply owned
+3. competing owners
+4. why it is a duplicate-owner bug or why it is legitimate boundary work
+5. exact files or symbols
+6. recommended single owner
+7. hard-cut cleanup:
+   - delete
+   - keep
+   - rename
+8. classification:
+   - architecture / SSOT bug
+   - local dedupe cleanup
+   - legitimate boundary adapter
+   - legitimate domain constraint
+
+Order findings by severity, then finish with a prioritized backlog by impact versus effort.
+
+## Prompting
+
+Use prompt patterns from references/audit-prompts.md.
+
+## Guardrails
+
+- Do not reduce the audit to `rg normalize`.
+- Do not flag every adapter or clamp as bad architecture.
+- Do not recommend wrappers, fallbacks, shims, or dual paths.
+- Prefer deleting the losing owner, not introducing a mediator.
+- If ownership is ambiguous because the diff is mixed or the contract is unclear, say so explicitly.

package/templates/.agents/skills/find-duplicate-ownership/references/audit-prompts.md

@@ -0,0 +1,89 @@
+# Audit Prompts
+
+## Generic Full Audit
+
+```text
+Use $find-duplicate-ownership to audit this codebase for duplicate ownership and hidden second sources of truth.
+
+Goal:
+Find places where the same business rule, normalization, validation, canonicalization, defaulting, mapping, or persistence policy is owned in more than one place.
+
+Focus on:
+- frontend and backend owning the same contract differently
+- runtime mutators re-applying boundary repair or coercion
+- duplicate helpers with the same semantics but different names
+- thin wrappers that hide a second path
+- validation or default constants duplicated across layers
+- serialization or canonicalization logic copied across modules
+- local helper clones in hooks, components, controllers, or services instead of one domain owner
+- persistence shapes that differ from runtime shapes and require translation glue
+- query, cache, or store logic acting as a second owner of domain rules
+
+Do not flag as problems by default:
+- pure UI-only formatting
+- security or path sandbox canonicalization with one clear owner
+- vendor or protocol adapters that are clearly boundary-only
+- necessary runtime clamp or math logic with one clear owner
+
+For each finding, output:
+1. severity
+2. rule or contract being multiply owned
+3. current competing owners
+4. why this is duplicate ownership rather than legitimate boundary work
+5. exact files or symbols
+6. recommended single owner
+7. hard-cut cleanup plan: delete / keep / rename
+8. classification
+
+Start with a taxonomy, then concrete findings ordered by severity.
+```
+
+## Layered-App Audit
+
+```text
+Use $find-duplicate-ownership to audit this layered application for duplicate ownership.
+
+Primary targets:
+- runtime state versus durable state
+- API contract ownership
+- persistence mapping
+- query, cache, or store ownership
+- duplicated helper ownership in UI, services, domain libraries, and adapters
+
+Repository policy:
+- hard cut only
+- one canonical current-state implementation
+- no shims
+- no fallbacks
+- no compatibility glue
+- fail fast
+- one source of truth per business rule
+
+Deliver:
+- a taxonomy first
+- then concrete findings with file paths and symbols
+- then a prioritized refactor backlog by impact versus effort
+- clearly separate real SSOT bugs from harmless local utilities
+
+Be especially suspicious of code that normalizes after reading trusted state or after mutating already-canonical runtime state.
+```
+
+## Parallel Subagent Audit
+
+```text
+Use $find-duplicate-ownership to audit this codebase for duplicate ownership.
+Spawn one `ownership-taxonomy-mapper`, three `duplicate-ownership-explorer` agents for disjoint slices, and one `ssot-judge`.
+Wait for all of them and merge the result.
+
+Slices:
+1. runtime state and persistence
+2. contracts, helpers, and canonicalization
+3. adapters, queries, and caches
+
+Return:
+- shared taxonomy
+- concrete findings by slice
+- merged severity order
+- winning owner for each finding
+- hard-cut delete or keep or rename plan
+```

package/templates/.agents/skills/foundational-redesign/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: foundational-redesign
-description: Use for code changes, refactors, and migrations when quality matters. Treat the request as if it had been a foundational assumption from day one, inspect the current system, choose the clean target shape, implement direct replacement, and aggressively delete obsolete legacy code unless coexistence is explicitly required.
+description: Use for non-trivial code changes, refactors, or migrations where the right answer is to redesign the system around a new or corrected assumption instead of patching the current shape. Use when the change affects architecture, data flow, interfaces, or long-lived abstractions; do not use for trivial bug fixes, cosmetic edits, or one-line patches.
 ---
 
 # Foundational Redesign
@@ -20,19 +20,24 @@ For each change, examine the existing system and redesign it into the most elega
 5. Implement with direct replacement and aggressively delete legacy seams or compatibility scaffolding unless coexistence is explicitly required.
 6. Before stopping, re-read every changed file (mandatory), compare against the current plan and agreed scope, and continue working if any gap remains.
 
-## Output contract for non-trivial changes
+## Rules
 
-Summarize:
+- Do not start redesigning until you have inspected the current shape and the approved scope.
+- Do not preserve legacy branches, adapters, or compatibility scaffolding unless coexistence is explicitly required.
+- Do not execute a non-trivial architecture, interface, or data-model redesign unless the user has seen and agreed to the redesign decision.
+- Do not call the work complete unless every changed file has been re-read and the result matches the agreed scope.
 
-- current shape
-- target shape
-- redesign decision confirmed with user (for non-trivial redesign)
-- what legacy code was deleted
-- what verification was run
-- any remaining gap to close
+## Exception Rule
+
+Relax the direct-replacement and legacy-deletion rules only when the approved scope explicitly requires coexistence, migration bridging, or phased rollout. In that case, keep the bridge minimal, state the removal condition, and do not extend the exception beyond the approved scope.
 
-## Gotchas
+## Output Contract
 
-- Do not preserve legacy branches by default "just in case".
-- Do not call work complete before the mandatory final file re-read.
-- Do not stop at partial scope; continue until approved scope is actually satisfied.
+Always report:
+
+- current shape
+- target shape
+- redesign decision confirmed with user, or `not needed`
+- legacy code removed, or `none`
+- verification run
+- remaining gap, or `none`

package/templates/.agents/skills/foundational-redesign/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "Foundational Redesign"
-  short_description: "Redesign from first principles and delete legacy seams"
-  default_prompt: "Use $foundational-redesign for this change: inspect the existing system, design the clean target shape as if this requirement were foundational from the start, replace directly, and aggressively remove obsolete legacy code unless coexistence is explicitly required."
+  short_description: "Use for non-trivial redesigns that should replace the current shape"
+  default_prompt: "Use $foundational-redesign for this change if it alters architecture, data flow, interfaces, or long-lived abstractions: inspect the current system, design the clean target shape as if this requirement were foundational from the start, replace directly, and remove legacy seams unless coexistence is explicitly required."

package/templates/.agents/skills/hard-cut/SKILL.md

@@ -0,0 +1,78 @@
+---
+name: hard-cut
+description: "Enforce a hard-cut cleanup policy: keep one canonical implementation and delete compatibility, migration, fallback, adapter, coercion, and dual-shape code. Use for pre-release or internal-draft refactors where the goal is one final shape, especially when changing schemas, contracts, persisted state, routing, configuration, feature flags, enum/value sets, or architecture."
+---
+
+# Hard-Cut Policy
+
+Apply a hard-cut policy by default for refactors or behavior changes that alter schemas, contracts, persisted state, routing, configuration, feature flags, enum/value sets, or architecture where old-state preservation might otherwise be retained.
+
+Keep one canonical codepath. Remove old-shape handling. Do not preserve draft or legacy behavior unless there is concrete evidence of a real external compatibility boundary.
+
+## Default assumption
+
+Treat previous shapes as internal draft shapes unless there is concrete evidence they are already:
+- persisted external or user data
+- on-disk or database state that must still load
+- a wire format used across process or service boundaries
+- a documented or publicly supported contract
+- actively depended on outside the refactor boundary
+
+Mere existence of old code is not proof of a compatibility obligation.
+
+## Core policy
+
+When an old shape appears, remove that path and convert the codebase to the canonical shape. Do not add code to support it. Do not add code specifically to reject it just because it once existed.
+
+## Hard rules
+
+Apply these rules in order:
+
+1. Do not add fallback behavior.
+2. Do not add compatibility branches.
+3. Do not add shims, adapters, coercions, aliases, or dual-shape support.
+4. Do not add fail-fast guards whose purpose is to detect or reject old shapes.
+5. Do not add tests whose purpose is to assert rejection of old or legacy shapes.
+6. Prefer deleting old-shape handling over preserving or policing it.
+7. Update producers, consumers, fixtures, and tests to use only the canonical shape.
+8. Remove dead code, dead conditionals, obsolete comments, and translation helpers related to old shapes.
+9. Keep validation only for the current canonical contract. Validation may reject malformed current-shape input, but must not branch on legacy discriminators, old field names, aliases, old enum members, or draft formats.
+10. When choosing between backward compatibility and simplification, choose simplification.
+
+## Execution workflow
+
+1. Identify the canonical target shape.
+2. Trace every producer and consumer of that shape.
+3. Update all live codepaths to emit and consume only the canonical shape.
+4. Update fixtures, test data, builders, and snapshots to the canonical shape.
+5. Delete legacy handling, branching, comments, and helpers.
+6. Keep only current-shape validation that is still required for correctness.
+7. If a real external compatibility boundary exists, isolate it and call out the exact file, function, boundary, and reason it cannot be removed yet.
+
+## Review checklist
+
+- Reject changes that preserve old-shape behavior behind conditionals.
+- Reject translation layers between old and new shapes.
+- Reject validation branches added only to reject legacy inputs.
+- Reject tests added only to memorialize abandoned draft formats.
+- Remove dead helpers and comments that describe removed draft formats.
+- Keep one owner for the canonical contract.
+
+## Deliverables
+
+Deliver only:
+- a minimal implementation that supports the canonical shape
+- updated tests for the canonical shape only
+- removal of obsolete legacy-shape tests
+- no new rejection tests for old shapes
+- no runtime logic dedicated to recognizing legacy formats
+
+## Exception rule
+
+Make an exception only when removing the old shape would break already persisted external or user data, on-disk or database state, cross-boundary wire formats, or a real public contract.
+
+If such a boundary exists:
+- do not invent new compatibility layers elsewhere
+- name the exact file and function
+- describe the concrete persisted or public dependency
+- limit any compatibility discussion to that boundary only