Update to DXD Skills

{
  "name": "dxd-code-review",
  "description": "Use when the user asks for DXD code review, dxd-code-review, harsh maintainability review, deep code quality audit, abstraction review, giant-file review, spaghetti-code review, or structural critique of current branch changes.",
  "included_files": [],
  "skill_md_contents": "---\nname: dxd-code-review\ndescription: >-\n  Use when the user asks for DXD code review, dxd-code-review, harsh maintainability review, deep code quality audit, abstraction review, giant-file review, spaghetti-code review, or structural critique of current branch changes.\ndisable-model-invocation: true\n---\n\n# DXD Code Review\n\nUse this skill for an unusually strict DXD-style review focused on implementation quality, maintainability, abstraction quality, and codebase health.\n\nAbove all, be ambitious about structure. Search for behavior-preserving changes that make the implementation smaller, simpler, and more inevitable instead of merely cleaner.\n\n## Goal\n\nPerform a deep code-quality audit of the current branch's changes, with an unusually high bar for maintainability. Push for structural simplification, stronger abstraction boundaries, smaller files, less branching complexity, and more direct implementation without changing behavior.\n\n## When to Use\n\nUse this skill when the user asks for:\n\n- DXD code review or `dxd-code-review`.\n- A deep code quality audit.\n- An especially harsh maintainability review.\n- A review focused on abstraction quality, giant files, or spaghetti-condition growth.\n\nFor a \"thermo-nuclear\" / thermonuclear review, use the `thermo-nuclear-code-quality-review` skill from cursor-team-kit instead.\n\n## Review Lens\n\nReview the current branch through these blockers before spending time on style:\n\n| Blocker | What It Looks Like | Cleaner Direction |\n|---------|--------------------|-------------------|\n| Missed simplification | The diff preserves concepts, branches, helpers, or modes that could disappear. | Reframe the model so the simpler flow becomes obvious. |\n| Spaghetti growth | New one-off conditionals, booleans, nullable modes, or special cases land in busy paths. | Move behavior behind a focused abstraction, state model, policy, or pure helper. |\n| File sprawl | A changed file crosses or approaches 1000 lines without a strong structural reason. | Split by ownership, feature boundary, or pure logic boundary before it hardens. |\n| Wrong layer | Feature logic leaks into shared paths or the package that owns the concept is bypassed. | Move logic to the canonical owner and reuse existing helpers. |\n| Weak contracts | Casts, `any`, `unknown`, unnecessary optionality, or silent fallbacks hide invariants. | Make the boundary explicit with typed models, schemas, or narrower APIs. |\n| Hollow abstraction | Wrappers, generic magic, or pass-through helpers add indirection without reducing complexity. | Delete the abstraction or replace it with a direct, boring flow. |\n| Brittle orchestration | Independent work is serialized or related updates can be left half-applied. | Parallelize or make updates atomic when it also makes the code easier to reason about. |\n\nDo not be satisfied with feedback like \"rename this\" when the real issue is structural.\n\n## Preferred Fixes\n\nWhen you flag a problem, point toward behavior-preserving changes such as:\n\n- Delete a layer of indirection instead of polishing it.\n- Collapse duplicate branches into one clearer flow.\n- Reframe the state model so conditionals disappear.\n- Extract a focused helper, module, component, or pure function.\n- Move feature logic to the package, service, or module that owns the concept.\n- Replace condition chains with a typed model, dispatcher, or explicit policy.\n- Reuse the existing canonical helper instead of adding a near-duplicate.\n- Make contracts explicit so callers do not need casts, optionality, or silent fallbacks.\n\n## Review Tone\n\nBe direct, serious, and demanding about quality.\nDo not be rude, but do not soften major maintainability issues into mild suggestions.\nIf the code is making the codebase messier, say so clearly.\nIf the implementation missed an opportunity for a dramatic simplification, say that clearly too.\n\nUseful phrases:\n\n- `this pushes the file past 1k lines. can we decompose this first?`\n- `this adds another special-case branch into an already busy flow. can we move this behind its own abstraction?`\n- `this works, but it makes the surrounding code more spaghetti. let's keep the behavior and restructure the implementation.`\n- `this feels like feature logic leaking into a shared path. can we isolate it?`\n- `this abstraction seems unnecessary. can we just keep the direct flow?`\n- `why does this need a cast / optional here? can we make the boundary more explicit instead?`\n- `this looks like a bespoke helper for something we already have elsewhere. can we reuse the canonical one?`\n- `i think there's a simpler framing here that makes these branches disappear.`\n- `this refactor moves complexity around, but doesn't really delete it. is there a way to make the model itself simpler?`\n\n## Workflow\n\n1. Inspect the current branch diff and identify every meaningful changed area before reviewing individual files.\n2. Check whether any changed file crosses or approaches 1000 lines.\n3. For each changed area, search for an existing canonical helper, layer, module, or pattern that should own the behavior.\n4. Review the structure before the syntax: ask whether the implementation can delete branches, reduce concepts, or move logic to a clearer boundary.\n5. Flag structural regressions and missed simplifications before legibility or naming concerns.\n6. For every finding, include the file and line, why the design is worse, and the cleaner direction.\n7. State whether the approval bar is met.\n\n## Output Expectations\n\nLead with findings, ordered by severity. Prioritize structural regressions, missed simplifications, spaghetti growth, boundary problems, file-size concerns, then legibility. Prefer a smaller number of high-conviction comments over a long list of cosmetic notes.\n\n## Approval Bar\n\nDo not approve merely because behavior seems correct. The bar for approval is:\n\n- no clear structural regression\n- no obvious missed opportunity to make the implementation dramatically simpler\n- no unjustified file-size explosion\n- no obvious spaghetti-growth from special-case branching\n- no obviously hacky or magical abstraction that makes the code harder to reason about\n- no unnecessary wrapper/cast/optionality churn obscuring the real design\n- no clear architecture-boundary leak or avoidable canonical-helper duplication\n- no missed opportunity for an obvious decomposition that would materially improve maintainability\n\nTreat violations as presumptive blockers unless the author can justify them clearly. If the bar is not met, leave explicit, actionable feedback and push for a cleaner decomposition.\n\n## Guardrails\n\n- Never turn the review into a cosmetic naming pass while larger structural issues are present.\n- Never approve a diff that clearly makes the codebase harder to maintain just because behavior appears correct.\n- Never recommend broad rewrites without explaining the smaller behavior-preserving restructuring path.\n- Never ignore existing project conventions or canonical helpers when proposing decomposition.\n- Never conflate performance micro-optimization with maintainability unless the orchestration also becomes simpler.\n\n## Completion Checklist\n\n- [ ] Current branch changes were inspected before reviewing individual files.\n- [ ] File-size growth and the 1000-line threshold were checked.\n- [ ] Existing abstractions, canonical helpers, and ownership layers were considered.\n- [ ] Findings prioritize structural maintainability over cosmetic style.\n- [ ] Each finding includes a concrete cleaner direction, not just criticism.\n- [ ] The review explicitly states whether the approval bar is met.\n"
}