Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →notque/architecture-deepening
Proactive architecture improvement: find shallow modules, propose deepening opportunities, design conversation.
Passed 12 of 16 test cases with the skill, and 3 of 16 without it.
and 19 more in the full report
13 fixed3 passed either way5 still failing1 broke
Tokens, turns and time describe resource use, not a dollar price.
This benchmark measured an earlier version of the skill.
One of 12 test cases the skill fixed. Same model, same prompt, with and without the skill.
When persisting decision records in decision memory, what are the two supported storage paths for shared versus local ignored memory?
| Checked | Without skill | With skill |
|---|---|---|
| Specify docs/architecture-decisions.md for shared memory storage. | Missed | Passed |
| Specify .local/architecture-decisions.md for local ignored memory storage. | Missed | Passed |
The instructions your model reads when the skill loads.
Find shallow modules and propose deepening opportunities. Not a code review -- does not find bugs or style violations. Finds modules where the interface is too close to the implementation, where users must understand internals to use the API, and where small interface changes would absorb disproportionate complexity.
When to use: After codebase onboarding or review when improvement was requested, before a cross-module feature, after a fix exposes a missing test seam, or when callers repeatedly need source knowledge or multi-module coordination.
Differs from full-repo-review: Full-repo-review finds defects. This skill finds structural improvement opportunities. Pair well: run full-repo-review first to fix defects, then architecture-deepening to raise the bar.
Load on demand when working in the named phase.
| Phase | Reference | Content |
|---|---|---|
| Phase 1 | references/maintenance-lifecycle.md | Entry rules, recent-change scope, decision memory, candidate schema, typed handoff |
| Phase 1 | references/vocabulary.md | Shared vocabulary: module, depth, seam, leverage, locality, deletion test |
| Phase 2 | references/interface-design.md | Patterns for exploring alternative interfaces, deletion test |
| Phase 2-3 | references/deepening-strategies.md | Dependency categorization, safe deepening, testing strategies |
Run phases in order until a terminal gate. Survey and design keep source code read-only; Write/Edit apply only to user-approved decision records after selection. Existing delivery workflows own code changes. The user selects candidates and decides whether a handoff proceeds.
Language-agnostic. Vocabulary and strategies apply to Go, Python, TypeScript, or any codebase with module boundaries.
Goal: Identify shallow modules -- where the interface exposes too much implementation detail.
Step 1: Choose an evidence-fed scope
Read references/maintenance-lifecycle.md. Use the user's named directory/package first. Otherwise start from the review, overview, feature, or fixed-bug evidence that triggered the run. With no such artifact, rank module paths changed in the last 50 commits and inspect the top bounded set. Recent change raises priority; it is not proof of shallowness. Widen once only when the initial scope has no usable evidence and the request is repository-wide.
Read prior architecture decisions before producing candidates. Suppress a matching stable rejection unless its recorded assumptions changed.
Then scan the chosen scope for module boundaries.
test cases passed, vs 3 / 16 without
Published skills whose descriptions closely match this one, with their headline benchmark lift.
More skills from the same source and nearby in the registry, with their headline benchmark lift.