Skip to content
cccskills
FreePublished on GitHub

improve-codebase-architecture

Find deepening opportunities in a codebase, informed by the domain language in CONTEXT.md and the decisions in docs/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.

The English summary is being prepared. Showing the original description.

See how to install

Files included (4)

  • SKILL.md3.3 KB
  • DEEPENING.md1.3 KB
  • INTERFACE-DESIGN.md1.4 KB
  • LANGUAGE.md1.8 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

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. Full definitions are in LANGUAGE.md.

  • Module: anything with an interface and an implementation.
  • Interface: everything a caller must know to use the module correctly.
  • Implementation: the code inside.
  • Depth: leverage at the interface. Deep means high leverage; shallow means the interface is nearly as complex as the implementation.
  • Seam: where an interface lives; a place behavior can be altered without editing in place.
  • Adapter: a concrete thing satisfying an interface at a seam.
  • Leverage: what callers get from depth.
  • Locality: what maintainers get from depth.

Key principles:

  • Deletion test: imagine deleting the module. If complexity vanishes, it was a pass-through. If complexity reappears across many callers, it was earning its keep.
  • The interface is the test surface.
  • One adapter means a hypothetical seam. Two adapters means a real seam.

Process

1. Explore

Read the project's domain glossary and any ADRs in the area first. Then inspect the codebase organically and note where understanding creates friction:

  • Where does understanding one concept require bouncing between many small modules?
  • Where are modules shallow?
  • Where have pure functions been extracted only for testability, while real bugs hide in how they are called?
  • Where do tightly-coupled modules leak across seams?
  • Which parts are untested, or hard to test through their current interface?

Apply the deletion test to anything suspected of being shallow.

2. Present Candidates

Present a numbered list of deepening opportunities. For each candidate include:

  • Files: which files/modules are involved.
  • Problem: why current architecture causes friction.
  • Solution: plain-English description of what would change.
  • Benefits: explain locality, leverage, and how tests would improve.

Use CONTEXT.md vocabulary for the domain and LANGUAGE.md vocabulary for architecture. If a candidate contradicts an existing ADR, only surface it when the friction is real enough to warrant revisiting that ADR.

Do not propose interfaces yet. Ask: "Which of these would you like to explore?"

3. Grilling Loop

Once the user picks a candidate, walk the design tree: constraints, dependencies, the shape of the deepened module, what sits behind the seam, and what tests survive.

Side effects happen inline as decisions crystallize:

  • If naming a deepened module after a concept not in CONTEXT.md, add the term using CONTEXT-FORMAT.md.
  • If sharpening a fuzzy term, update CONTEXT.md immediately.
  • If the user rejects the candidate with a load-bearing reason, offer an ADR using ADR-FORMAT.md.
  • If exploring alternative interfaces, use INTERFACE-DESIGN.md.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when the user wants to stress-test a plan, get grilled on their design, or mentions "grill me" outside an Odoo-specific context.

The English summary is being prepared. Showing the original description.

mart337i/odoo-skills56Updated Oct 2, 2026

Grilling session that challenges your plan against the existing domain model, sharpens terminology, and updates documentation (CONTEXT.md, ADRs) inline as decisions crystallise. Use when the user wants to stress-test a plan against their project's language and documented decisions.

The English summary is being prepared. Showing the original description.

mart337i/odoo-skills56Updated Oct 2, 2026

odoo

Free

Odoo engineering workflows for addon development, codebase exploration, debugging, architecture/refactor review, manifest/docs sync, and routing to migration work. Use when the user mentions Odoo, addons, modules, manifests, models, XML views, security CSVs, record rules, Odoo shell, OWL/QWeb/assets, or when an Odoo codebase is detected.

The English summary is being prepared. Showing the original description.

mart337i/odoo-skills56Updated Oct 2, 2026

Odoo 17 development reference for Python models and ORM (search, domain, read_group, compute fields), XML/CSV data and views, OWL/JS client code, QWeb reports, security (ACL, record rules, groups), cron and server actions, migrations and module upgrades, tests, i18n, and performance. Use this skill whenever work involves Odoo 17 or custom addons, including traceback diagnosis, addons, manifests, XML errors, HTTP controllers, business rules, feature work, refactoring, or reviews.

The English summary is being prepared. Showing the original description.

mart337i/odoo-skills56Updated Oct 2, 2026

Odoo 18 development reference for Python models and ORM (search, domain, read_group, compute fields), XML/CSV data and views, OWL/JS client code, QWeb reports, security (ACL, record rules, groups), cron and server actions, migrations and module upgrades, tests, i18n, and performance. Use this skill whenever work involves Odoo 18 or custom addons, including traceback diagnosis, addons, manifests, XML errors, HTTP controllers, business rules, feature work, refactoring, or reviews.

The English summary is being prepared. Showing the original description.

mart337i/odoo-skills56Updated Oct 2, 2026

Odoo 19 development knowledge base covering actions, controllers, data files, API decorators, SQL constraints, indexes, modules, fields, manifests, mixins, ORM methods, migrations, OWL components, performance, QWeb reports, security, testing, transactions, translations, and XML views. Use when writing, reviewing, or debugging Odoo 19 Python, XML, or JavaScript code, creating or modifying modules, fixing performance issues, or looking up Odoo 19 API patterns and best practices.

The English summary is being prepared. Showing the original description.

mart337i/odoo-skills56Updated Oct 2, 2026

See all skills by mart337i

Report a problem with this skill