review

Name: review
Author: vladikk

495stars30forks

How to install review?

vladikk/modularity/review

$npx -y skills add vladikk/modularity --skill review

Installs into the current project.

Summary

Analyzes a codebase's modularity imbalances using the Balanced Coupling model and produces a review of design issues. Use when reviewing existing code for coupling problems, assessing architecture quality, identifying distributed monolith risks, or finding areas where changes are

Files · 1

View on GitHub

SKILL.md

1	# Modularity Review
2
3	You analyze codebases for modularity imbalances using the Balanced Coupling model by Vlad Khononov (preloaded from the balanced-coupling skill). You produce a review that identifies concrete design issues and explains each one in terms of knowledge encapsulation, complexity, cascading changes, and how to improve the design.
4
5	Use TaskCreate to track these 4 steps: Understand the Problem Domain, Map Integrations, Apply the Balance Rule, Write the Review.
6
7	## Interaction Rules
8
9	Always use `AskUserQuestion` for user input. Follow these principles:
10
11	- One question at a time. Never batch multiple questions into one message.
12	- Multiple choice preferred. Provide 2-4 concrete options. Easier to answer than open-ended.
13	- "Other" is automatic. The tool always provides a free-text "Other" option — do not add one manually.
14	- Use headers. Short labels (max 12 chars) like "Scope", "Domain", "Teams", "Pain points".
15
16	## Process
17
18	### Step 1: Understand the Problem Domain
19
20	1. Use `AskUserQuestion` to ask which parts of the codebase to analyze. Header: "Scope". Options: "Entire codebase — Analyze all components", "Specific directory — I'll tell you which path", "Specific components — I'll name them". If the user picks a specific scope, follow up to collect details.
21
22	2. Read before asking. Read all functional requirements documents in the `docs/` folder and then read the code itself. Understand the components, their responsibilities, and how they integrate. Use LSP (findReferences, goToDefinition), Grep, and Glob to navigate — do not guess.
23
24	3. Surface your understanding. Before asking domain questions, present a brief synthesis of what you learned from the code and requirements:
25	- Components you found and their responsibilities
26	- Integration patterns you observed (shared types, API calls, database access, event flows)
27	- Your best guess at domain classification (core / supporting / generic) with reasoning and confidence level — low confidence areas are the strongest candidates for follow-up questions
28	- Assumptions you're making about team structure, deployment topology, or design intent
29
30	Use `AskUserQuestion` to validate. Header: "Summary". Options: "Looks right", "Some things are off — I'll correct", "Missing important context". If the user corrects or adds context, incorporate it before proceeding.
31
32	4. Discover what you still need. You know the Balanced Coupling model. You know you need volatility (from domain classification), distance (from organizational structure), and strength (from code). Think about what would change your coupling assessment if you knew it — then ask about those gaps. One question at a time via `AskUserQuestion`. Do not ask questions whose answers would not change your analysis — every question should fill a gap that matters for the assessment.
33
34	Common information gaps to consider (skip any you can already answer from code, requirements, or the user's corrections above):
35	- Domain classification gaps — areas where you can't tell if something is core (competitive advantage, high volatility) vs supporting vs generic. Propose your best guess and ask the user to confirm or correct.
36	- Organizational context — team ownership boundaries, deployment topology, shared infrastructure. These affect effective distance beyond what code structure shows.
37	- Known pain points — areas where changes are unexpectedly expensive, where deployments break things, or where the design feels wrong. These focus the analysis where it matters most.
38	- Strategic direction — upcoming migrations, business shifts, or planned changes that affect which areas are volatile.
39	- Surprising patterns — things you found in the code that could be intentional design choices or accidental complexity. Ask before assuming.
40
41	You are not limited to these categories. If you discovered something in the code that needs clarification for a proper coupling assessment, ask about it. Ground your questions in specific code observations — reference the components, patterns, or integrations you actually found.
42
43	### Step 2: Map Integrations
44
45	For each pair of components that interact, identify:
46
47	- What knowledge is shared — implementation details, business rules, domain models, or integration contracts?
48	- Integration strength level — intrusive, functional, model, or contract coupling?
49	- Is the shared knowledge implicit or explicit? Implicit coupling (duplicated business rules, direct databas

People who liked this also viewed

6 picks

Type

review

495stars30forks

View on GitHub

How to install review?

vladikk/modularity/review

$npx -y skills add vladikk/modularity --skill review

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Modularity Review
2
3	You analyze codebases for modularity imbalances using the Balanced Coupling model by Vlad Khononov (preloaded from the balanced-coupling skill). You produce a review that identifies concrete design issues and explains each one in terms of knowledge encapsulation, complexity, cascading changes, and how to improve the design.
4
5	Use TaskCreate to track these 4 steps: Understand the Problem Domain, Map Integrations, Apply the Balance Rule, Write the Review.
6
7	## Interaction Rules
8
9	Always use `AskUserQuestion` for user input. Follow these principles:
10
11	- One question at a time. Never batch multiple questions into one message.
12	- Multiple choice preferred. Provide 2-4 concrete options. Easier to answer than open-ended.
13	- "Other" is automatic. The tool always provides a free-text "Other" option — do not add one manually.
14	- Use headers. Short labels (max 12 chars) like "Scope", "Domain", "Teams", "Pain points".
15
16	## Process
17
18	### Step 1: Understand the Problem Domain
19
20	1. Use `AskUserQuestion` to ask which parts of the codebase to analyze. Header: "Scope". Options: "Entire codebase — Analyze all components", "Specific directory — I'll tell you which path", "Specific components — I'll name them". If the user picks a specific scope, follow up to collect details.
21
22	2. Read before asking. Read all functional requirements documents in the `docs/` folder and then read the code itself. Understand the components, their responsibilities, and how they integrate. Use LSP (findReferences, goToDefinition), Grep, and Glob to navigate — do not guess.
23
24	3. Surface your understanding. Before asking domain questions, present a brief synthesis of what you learned from the code and requirements:
25	- Components you found and their responsibilities
26	- Integration patterns you observed (shared types, API calls, database access, event flows)
27	- Your best guess at domain classification (core / supporting / generic) with reasoning and confidence level — low confidence areas are the strongest candidates for follow-up questions
28	- Assumptions you're making about team structure, deployment topology, or design intent
29
30	Use `AskUserQuestion` to validate. Header: "Summary". Options: "Looks right", "Some things are off — I'll correct", "Missing important context". If the user corrects or adds context, incorporate it before proceeding.
31
32	4. Discover what you still need. You know the Balanced Coupling model. You know you need volatility (from domain classification), distance (from organizational structure), and strength (from code). Think about what would change your coupling assessment if you knew it — then ask about those gaps. One question at a time via `AskUserQuestion`. Do not ask questions whose answers would not change your analysis — every question should fill a gap that matters for the assessment.
33
34	Common information gaps to consider (skip any you can already answer from code, requirements, or the user's corrections above):
35	- Domain classification gaps — areas where you can't tell if something is core (competitive advantage, high volatility) vs supporting vs generic. Propose your best guess and ask the user to confirm or correct.
36	- Organizational context — team ownership boundaries, deployment topology, shared infrastructure. These affect effective distance beyond what code structure shows.
37	- Known pain points — areas where changes are unexpectedly expensive, where deployments break things, or where the design feels wrong. These focus the analysis where it matters most.
38	- Strategic direction — upcoming migrations, business shifts, or planned changes that affect which areas are volatile.
39	- Surprising patterns — things you found in the code that could be intentional design choices or accidental complexity. Ask before assuming.
40
41	You are not limited to these categories. If you discovered something in the code that needs clarification for a proper coupling assessment, ask about it. Ground your questions in specific code observations — reference the components, patterns, or integrations you actually found.
42
43	### Step 2: Map Integrations
44
45	For each pair of components that interact, identify:
46
47	- What knowledge is shared — implementation details, business rules, domain models, or integration contracts?
48	- Integration strength level — intrusive, functional, model, or contract coupling?
49	- Is the shared knowledge implicit or explicit? Implicit coupling (duplicated business rules, direct databas

People who liked this also viewed

6 picks

Type