improve-codebase-architecture

name	improve-codebase-architecture
description	Find deepening opportunities in a codebase, informed by the domain language in CONTEXT.md and the decisions in context/adr/. Use when the user wants to improve architecture, find refactoring opportunities, consolidate tightly-coupled modules, or make a codebase more testable and AI-navigable.

Improve Codebase Architecture

Surface architectural friction and propose deepening opportunities — refactors that turn shallow modules into deep ones. The aim is testability and AI-navigability.

Glossary

Use these terms exactly in every suggestion — don't drift into "component," "service," "API," or "boundary." See LANGUAGE.md for full definitions, principles, and rejected framings.

Terms: Module, Interface, Implementation, Depth (deep/shallow), Seam, Adapter, Leverage, Locality.

Key tests: Deletion test, "the interface is the test surface", "one adapter = hypothetical seam, two = real."

This skill is informed by the project's domain model. The domain language gives names to good seams; ADRs record decisions the skill should not re-litigate.

Calibration

Two failure modes to guard against:

• Lazy assessment: declares everything "fine" without honestly applying the deletion test or scenario analysis. If nothing surfaces, the analysis was shallow — not the codebase.
• Overengineered proposals: adds seams, adapters, and indirection that increase interface surface without adding leverage. More architecture is not more depth.

Ask: what structure would the top 10% of similar codebases use? Not the most sophisticated — the simplest that produces real depth. A deep module is already the most AI-navigable structure: small interface means less context to load, fewer files to understand, one place to test.

Prioritize simplicity of the final code, not how easy it is to get there.

Process

1. Explore

Read context/CONTEXT.md (always), PFLOW.md (repo constraints that carry ADR weight — enforced invariants, testing doctrine, deliberate shapes), and any ADRs in context/adr/ related to the area you're examining.

If the area overlaps with previously completed tasks, use subagents to examine relevant .taskmaster/tasks/task_<id>/task-review.md files and ADR files for prior decisions and context. Do not read these yourself — delegate to pflow-codebase-searcher subagents and explicitly ask them to return only information clearly relevant to the architectural question, not a summary of the file contents.

Then use the runner's subagent tool with the pflow-codebase-searcher agent type to walk the codebase (subagent_type in Claude, agent_type in Codex). Launch multiple searchers in parallel for independent questions. Don't follow rigid heuristics — explore organically and note where you experience friction:

• Where does understanding one concept require bouncing between many small modules?
• Where are modules shallow — interface nearly as complex as the implementation?
• Where have pure functions been extracted just for testability, but the real bugs hide in how they're called (no locality)?
• Where do tightly-coupled modules leak across their seams?
• Which parts of the codebase are untested, or hard to test through their current interface?

Apply the deletion test to anything you suspect is shallow: would deleting it concentrate complexity, or just move it? A "yes, concentrates" is the signal you want.

Scenario analysis — ground depth in evidence

Pick 5-6 real tasks someone would perform on the module (bug fixes, feature additions, debugging) and trace which files each task requires. Classify every file as MUST-READ, SCAN, or NOT-NEEDED. This turns subjective "is this module deep?" into concrete evidence: how many files must a developer load to work on one concern? If every task requires reading across many small modules, the concern is too scattered — a deepening candidate.

2. Present candidates as an HTML report

Write a self-contained HTML file to 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 a fresh 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 uses Tailwind via CDN for layout and styling, and Mermaid via CDN for diagrams where a graph/flow/sequence reliably communicates the structure. Mix Mermaid with hand-crafted CSS/SVG visuals — use Mermaid when relationships are graph-shaped (call graphs, dependencies, sequences), and hand-built divs/SVG when you want something more editorial (mass diagrams, cross-sections, collapse animations). Each candidate gets a before/after visualisation. Be visual.

For each candidate, the same template as before, but rendered as a card:

• Files — which files/modules are involved
• Problem — why the current architecture is causing friction
• Solution — plain English description of what would change
• Benefits — explained in terms of locality and leverage, and how tests would improve
• Before / After diagram — side-by-side, custom-drawn, illustrating the shallowness and the deepening
• Recommendation strength — one of Strong, Worth exploring, Speculative, rendered as a badge

End the report with a Top recommendation section: which candidate you'd tackle first and why.

Use context/CONTEXT.md vocabulary for the domain, and LANGUAGE.md vocabulary for the architecture. If context/CONTEXT.md defines "Order," talk about "the Order intake module" — not "the FooBarHandler," and not "the Order service."

ADR conflicts: if a candidate contradicts an existing ADR, only surface it when the friction is real enough to warrant revisiting the ADR. Mark it clearly in the card (e.g. a warning callout: "contradicts ADR-0007 — but worth reopening because…"). Don't list every theoretical refactor an ADR forbids.

See HTML-REPORT.md for the full HTML scaffold, diagram patterns, and styling guidance.

Do NOT propose interfaces yet. After the file is written, ask the user: "Which of these would you like to explore?"

3. Grilling loop

Once the user picks a candidate, drop into a grilling conversation. Walk the design tree with them — constraints, dependencies, the shape of the deepened module, what sits behind the seam, what tests survive.

Side effects happen inline as decisions crystallize:

• Naming a deepened module after a concept not in CONTEXT.md? Add the term to context/CONTEXT.md using the format in CONTEXT-FORMAT.md. Create the file lazily if it doesn't exist.
• Sharpening a fuzzy term during the conversation? Update context/CONTEXT.md right there.
• User rejects the candidate with a load-bearing reason? Offer an ADR, framed as: "Want me to record this as an ADR so future architecture reviews don't re-suggest it?" Only offer when the reason would actually be needed by a future explorer to avoid re-suggesting the same thing — skip ephemeral reasons ("not worth it right now") and self-evident ones. Use the format in ADR-FORMAT.md.
• Want to explore alternative interfaces for the deepened module? See INTERFACE-DESIGN.md.
• Design agreed and ready for execution? Hand off per PFLOW.md § Execution handoff: capture the design as a task spec (create-task), then optionally author the implementation plan (create-plan). Never start automatically — the user decides when the design is complete and all unknowns are resolved.

Context directory

context/ is located at the root of the project.