service-boundary-review
Skill0 starsChanged 7 months agoMITView on GitHub
Review whether module or service boundaries are correctly drawn, highlighting coupling, ownership drift, and misplaced responsibilities before architecture debt hardens.
We split this skill into the rules it gives an agent
2 rules. About 0 are common, 2 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 8
Use this skill when the question is whether responsibilities sit in the right module, package, service, or domain boundary.
- Distinctive: line 28
Check for boundary smells:
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Service Boundary Review
Use this skill when the question is whether responsibilities sit in the right module, package, service, or domain boundary.
Read First
- architecture map or current module layout
- dependency graph or import paths
- cross-boundary calls and shared types
docs/overview/project-overview.mdandharness/state.mdif they existharness/history.mdif it exists
Goals
- expose unclear ownership and accidental coupling
- prevent boundary decisions from drifting into shared-everything design
- recommend the smallest structural correction that improves clarity
- distinguish real boundary problems from simple code smell
Steps
- Define the boundary under review.
- Identify responsibility, data ownership, and dependency direction.
- Check for boundary smells:
- shared mutable models
- cross-layer leakage
- circular knowledge
- chatty service calls
- Compare:
- keep as is
- redraw module boundary
- extract shared kernel
- merge split-by-accident units
- Recommend the least disruptive correction that improves ownership.
- Capture migration cost and expected wins.
Output
Report:
- boundary reviewed
- observed smells
- recommendation
- dependency direction rules
- migration cost
- risks if unchanged
In this repository42 other files it gives its agents.
- AGENTS.mdAGENTS.md
- codex/AGENTS.mdAGENTS.md
- claude/CLAUDE.mdCLAUDE.md
- backend-refactorSkill
- buildSkill
- discussSkill
- docSkill
- frontend-designSkill
- frontend-refactorSkill
- low-altitude-interviewerSkill
- pdfSkill
- repo-bootstrapSkill
- skill-maintenanceSkill
- tdd-executionSkill
- architecture-guardrailsSkill
- closed-loop-testingSkill
- harness-marathonSkill
- task-harnessSkill
- api-designSkill
- architecture-designSkill
- brainstormSkill
- codex-record-retrospectiveSkill
- database-designSkill
- integration-designSkill
- map-codebaseSkill
- migration-designSkill
- observability-designSkill
- planSkill
- query-optimizationSkill
- scalability-checkSkill
- api-change-checkSkill
- browseSkill
- bugfix-verificationSkill
- debugSkill
- incident-debugSkill
- performance-investigationSkill
- qaSkill
- reviewSkill
- security-reviewSkill
- verifySkill
- release-checkSkill
- shipSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.