Menú
Scan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
Recurring maintenance pass over automated dependency-bump PRs (Dependabot, Renovate, or similar) — rebase, relock, verify, and report what's ready to merge. Meant to be handed to a time-based loop or schedule, not run once.
Post-deploy verification loop — poll a rollout until every instance is on the new version and healthy, then run one smoke check against a real user path. Meant to be handed to a time-based loop with a timeout, not polled by hand.
Reference for designing agent loops — cycles of work that repeat until a stop condition is met. Covers the four loop shapes, writing completion criteria, carrying state and isolating work across cycles, and what running unattended still leaves on you.
Recurring check-in on a stack of dependent PRs — rebase children onto updated parents, surface CI state, flag anything waiting on a human-only gate, and report only what changed since last time. Meant to be handed to a time-based loop, not run once.
Pick the skill or flow that fits your situation. A router over the skills in this repo.
Review the changes since a fixed point (commit, branch, tag, or merge-base) along two axes — Standards (does the code follow this repo's documented coding standards?) and Spec (does the code match what the originating issue/PRD asked for?). Runs both reviews in parallel sub-agents and reports them side by side. Use when the user wants to review a branch, a PR, work-in-progress changes, or asks to "review since X".
| name | improve-codebase-architecture |
| description | Scan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick. |
| disable-model-invocation | true |
Surface architectural friction and pitch deepening opportunities — refactors that turn shallow modules into deep ones. The goal is testability and AI-navigability.
This command draws on the project's domain model and rests on a shared design vocabulary:
/codebase-design skill for the architecture vocabulary (module, interface, depth, seam, adapter, leverage, locality) and its principles (the deletion test, "the interface is the test surface", "one adapter = hypothetical seam, two = real"). Use those exact terms in every suggestion — don't slide into "component," "service," "API," or "boundary."CONTEXT.md names the good seams; the ADRs in docs/adr/ record decisions this command must not re-open.Read the project's domain glossary (CONTEXT.md) and any ADRs covering the area you're touching first.
Then use the Agent tool with subagent_type=Explore to walk the codebase. Skip rigid heuristics — explore organically and mark wherever you feel friction:
Apply the deletion test to anything you suspect is shallow: would deleting it concentrate complexity, or merely shuffle it elsewhere? A "yes, concentrates" is the signal you're after.
Write a self-contained HTML file into the OS temp directory so nothing lands in the repo. Resolve the temp dir from $TMPDIR, falling back to /tmp (or %TEMP% on Windows), and write to <tmpdir>/architecture-review-<timestamp>.html so each run gets its own file. Open it for the user — xdg-open <path> on Linux, open <path> on macOS, start <path> on Windows — and tell them the absolute path.
The report pulls Tailwind from a CDN for layout and styling, and Mermaid from a CDN for diagrams wherever a graph, flow, or sequence carries the structure reliably. Blend Mermaid with hand-built CSS/SVG visuals — Mermaid when the relationships are graph-shaped (call graphs, dependencies, sequences), hand-crafted divs/SVG when you want something more editorial (mass diagrams, cross-sections, collapse animations). Every candidate earns a before/after visualisation. Be visual.
For each candidate, render a card carrying:
Strong, Worth exploring, Speculative, shown as a badgeClose the report with a Top recommendation section: the candidate you'd take on first and why.
Use CONTEXT.md vocabulary for the domain, and the /codebase-design vocabulary for the architecture. If CONTEXT.md defines "Order," talk about "the Order intake module" — not "the FooBarHandler," and not "the Order service."
ADR conflicts: if a candidate cuts against an existing ADR, raise it only when the friction is real enough to justify reopening the ADR. Mark it plainly on the card (say, a warning callout: "contradicts ADR-0007 — but worth reopening because…"). Don't catalogue every theoretical refactor an ADR rules out.
See HTML-REPORT.md for the full HTML scaffold, diagram patterns, and styling guidance.
Do NOT propose interfaces yet. Once the file is written, ask the user: "Which of these would you like to explore?"
Once the user picks a candidate, run the /grilling skill to walk the design tree with them — constraints, dependencies, the shape of the deepened module, what sits behind the seam, which tests survive.
Side effects happen inline as decisions firm up — run the /domain-modeling skill to keep the domain model current as you go:
CONTEXT.md doesn't hold? Add the term to CONTEXT.md. Create the file lazily if it's missing.CONTEXT.md on the spot./codebase-design skill and use its design-it-twice parallel sub-agent pattern.