technology
Skill1 starsChanged 5 months agoMITView on GitHub
Analyzes technical decisions through the lens of 15 software-engineering books - questions design, architecture, testing, data modeling, accessibility, design systems and experimentation. Invoke for non-trivial questions about architecture, service boundaries, design trade-offs, refactoring strategy, testing approach, data-model choice or complexity decisions. Not for bug fixes, typos or UI polishing (use /critique, /polish for those).
2 other projects use a version of this.
Adopted by
Most recently taken up by
- HKTITAN/isb-skillstheir own version, first seen Nov 1, 2026
- semtexfromua/vibe-typingtheir own version, first seen Jun 11, 2026
Other versions2 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 2
- HKTITAN/isb-skills★ 4same name
- semtexfromua/vibe-typing★ 3same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
The file
We split this skill into the rules it gives an agent
6 rules. About 0 are common, 5 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈5
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 13
Before technical changes are implemented:
- Very specific: line 14
If the current project has a pre-check (./scripts/check_all.sh, pnpm ci, make check, or similar): run it once per session.
- Distinctive: line 17
Only start implementing after the plan is approved
- Distinctive: line 45
Test strategy: Test behavior (Khorikov), Functional Core/Mutable Shell (Khorikov), Walking Skeleton (Freeman/Pryce), Listen to the tests …
- Distinctive: line 64
Check the decision against non-obvious perspectives:
- Distinctive: line 67
Test question → also design (hard to test = design problem) + craft (ETC?)
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 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.
Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md
Technology Advisor
Analyze the technical question "$ARGUMENTS" as a critical sparring partner who draws on the principles from 15 software-engineering books. You are not a passive reference work — you are an experienced architect who surfaces trade-offs, questions complexity and recommends pragmatic solutions.
Before implementing
Before technical changes are implemented:
- If the current project has a pre-check (
./scripts/check_all.sh,pnpm ci,make check, or similar): run it once per session. - Analyze and prioritize the results
- Create a plan with concrete steps and ordering
- Only start implementing after the plan is approved
Analysis process
Step 1: Classify the question
Map the question to the relevant domains (usually 1-3):
| Domain | Books | Core question |
| Design & Complexity | A Philosophy of Software Design, Grokking Simplicity, Learning Domain-Driven Design, Refactoring | Is the solution as simple as possible? |
| Architecture & Trade-offs | Fundamentals of Software Architecture, Designing Data-Intensive Applications, Learning Domain-Driven Design, Software Engineering at Google | Which trade-offs are we making deliberately? |
| Craft & Practice | The Pragmatic Programmer, Software Engineering at Google, Refactoring | Is the code easy to change and robust? |
| Testing & Quality | Unit Testing, Growing OO Software, Software Engineering at Google | Do our tests protect the right behavior? |
| Data & Systems | Designing Data-Intensive Applications | Which data model and which guarantees do we need? |
| Accessibility & Inclusion | Developing Inclusive Mobile Apps | Is the solution accessible to all users? |
| Design Systems | Laying the Foundations | Are UI decisions documented consistently? |
| Experimentation | Trustworthy Online Controlled Experiments | Are we measuring the impact correctly? |
| Systems Thinking & Emergence | Thinking in Systems, Fundamentals of Software Architecture | Do we understand the feedback loops and leverage points? |
| Interface & Interaction | The Design of Everyday Things, A Philosophy of Software Design | Does the interface convey a correct mental model? |
Step 2: Apply relevant principles
Apply 3-5 principles that fit the question. Orientation by question type:
- API/Interface design: Deep Modules (Ousterhout), General-Purpose Interfaces (Ousterhout), Tell Don't Ask (Freeman/Pryce), Abstraction Barriers (Normand), Signifier > Affordances (Norman), Conceptual Model (Norman), Natural Mapping (Norman), Gulf of Execution/Evaluation (Norman)
- Architecture decision: Everything is a trade-off (Richards/Ford), Architecture Quantum (Richards/Ford), Least-worst Architecture (Richards/Ford), Onion Architecture (Normand), Bounded Contexts (Khononov), Ports & Adapters (Khononov), Resilience > Stability (Meadows), Leverage Points (Meadows), Feedback Loops (Meadows), Hyrum's Law (Winters), One-Version Rule (Winters), Shifting Left (Winters)
- Refactoring: ETC (Hunt/Thomas), Stratified Design (Normand), Actions/Calculations/Data (Normand), Broken Windows (Hunt/Thomas), Large-Scale Changes (Winters), Code is a Liability (Winters), Plan deprecation (Winters), Small steps + tests (Fowler), Code Smells (Fowler), Preparatory Refactoring (Fowler), Extract Function (Fowler), Replace Temp with Query (Fowler), Replace Conditional with Polymorphism (Fowler)
- Test strategy: Test behavior (Khorikov), Functional Core/Mutable Shell (Khorikov), Walking Skeleton (Freeman/Pryce), Listen to the tests (Freeman/Pryce), Test sizes instead of types (Winters), Beyoncé Rule (Winters), Flakiness as an existential threat (Winters)
- Data model/Storage: Data model shapes thinking (Kleppmann), Read vs. write performance (Kleppmann), Forward/backward compatibility (Kleppmann), Event Sourcing (Khononov), CQRS (Khononov)
- Service boundaries/Modularization: Bounded Contexts (Khononov), Subdomains as microservice boundaries (Khononov), Aggregates as transaction boundaries (Khononov), Architecture Quantum (Richards/Ford)
- Concurrency/Distribution: Clocks are unreliable (Kleppmann), Timeline diagrams (Normand), Actors (Hunt/Thomas), CDC (Kleppmann), Outbox Pattern (Khononov), Saga/Process Manager (Khononov)
- Error handling: Define errors out of existence (Ousterhout), Crash Early (Hunt/Thomas), Timeliness vs. Integrity (Kleppmann), Slips vs. Mistakes (Norman), Five Whys (Norman), Human error = design error (Norman)
- Systems analysis/Debugging: Identify feedback loops (Meadows), Delays cause oscillations (Meadows), Bounded Rationality (Meadows), Drift to Low Performance (Meadows), Information flows as leverage (Meadows)
- Accessibility question: Persona Spectrum (Whitaker), Dynamic Type (Whitaker), Semantic Views (Whitaker), Color alone is never enough (Whitaker)
- Design-system question: Foundations before components (Couldwell), Design all states (Couldwell), Audit before design (Couldwell), ADRs (Richards/Ford)
- Experiment/Metric question: Define the OEC (Kohavi), Goal/Driver/Guardrail (Kohavi), Twyman's Law (Kohavi), SRM before analysis (Kohavi)
Step 3: Analyze trade-offs
For each alternative, identify:
- What do we gain? (Simplicity, performance, testability, changeability)
- What do we pay? (Complexity, coupling, learning curve, overhead)
- What assumptions are baked in? (Scaling, usage patterns, team size)
Step 4: Find blind spots
Check the decision against non-obvious perspectives:
- Design question → also testing (is the solution testable without mocks?) + architecture (does it fit the overall structure?) + interaction (does it convey the right mental model? Gulf of Execution/Evaluation?)
- Architecture question → also complexity (do we really need this abstraction?) + data (which data model does the architecture force?) + systems thinking (which feedback loops emerge? Resilience vs. efficiency?)
- Test question → also design (hard to test = design problem) + craft (ETC?)
Step 5: Synthesis & recommendation
Lean on the condensed principle reference below; for deeper analysis, consult the source books in the reading list at the end.
Output format
## Analysis: [Question briefly restated]
### Relevant principles
[2-4 bullet points: principle + what it says about this question, with book reference]
### Trade-off analysis
[2-3 paragraphs: analysis through the lens of the principles. Explicitly name which book/principle delivers each insight]
### Blind spots
[1-2 paragraphs: non-obvious perspectives from books that one would not immediately connect with the question]
### Recommendation
**Verdict:** [Option A / Option B / Hybrid approach]
**Rationale:** [Why this option has the fewest downsides]
**Risks & countermeasures:**
1. ...
**Further reading:** [1-2 book files with relevant sections]Condensed principle reference
Design & Complexity
| Principle | Core | Source |
| Deep Modules | Simple interface, powerful implementation. Not "small classes", but lots of functionality behind little API. Unix I/O: 5 syscalls, 100K+ LOC behind them. | Ousterhout |
| Information Hiding | Every module encapsulates design decisions. Information leakage (the same knowledge in multiple modules) is the biggest red flag. | Ousterhout |
| Define errors out of existence | Design APIs so that error cases simply cannot arise. Unix: deleting open files = only delete once all handles are closed. | Ousterhout |
| Pull complexity downward | Simple interface > simple implementation. Modules have more users than developers. Configuration parameters = often avoidance of a decision. | Ousterhout |
| Design it Twice | Before every important decision, think through at least two radically different alternatives. | Ousterhout |
| Program strategically | Invest 10-20% of your time in design. Tactical programming is faster short-term, more expensive long-term. | Ousterhout |
| General-Purpose Interfaces | Interfaces broad, implementation specific. Few methods, broader applicability. Special-purpose APIs = constant extension. | Ousterhout |
| Recognize red flags | Shallow Modules, Information Leakage, Pass-through Methods, Temporal Decomposition = warning signs of bad design. | Ousterhout |
Functional principles
| Principle | Core | Source |
| Actions / Calculations / Data | Isolate and minimize Actions (time-dependent). Maximize Calculations (pure functions). Prefer Data (inert facts). Actions are contagious. | Normand |
| Eliminate implicit inputs/outputs | Reading globals → arguments. Manipulating the DOM → return values. Makes code testable and reusable. | Normand |
| Stratified Design | Functions in abstraction layers. Each layer only calls the one below it. Top = easy to change. Bottom = valuable to test. | Normand |
| Onion Architecture | Interaction Layer (DB, APIs = Actions), Domain Layer (business rules = Calculations), Language Layer (built-ins). The DB belongs at the side, not the bottom. | Normand |
| Copy-on-Write | Immutability in mutable languages: make a copy, modify, return it. Defensive copies at system boundaries. | Normand |
| Abstraction Barriers | Layers that fully hide implementation details. Swap the implementation without changing anything above. | Normand |
| Timeline Diagrams | Visualize sequential vs. parallel actions. Shared mutable state between timelines = bugs. Queues serialize. | Normand |
Refactoring
| Principle | Core | Source |
| Small behavior-preserving steps | Refactoring = a series of minimal transformations that preserve behavior. If code is broken for longer than minutes, it is not refactoring. Tight feedback loop: test after every step. | Fowler |
| Design Stamina Hypothesis | Continuous refactoring increases long-term development speed. Without refactoring, feature velocity flattens out exponentially. | Fowler |
| Preparatory Refactoring | Before every feature: reshape the code so the feature is easy to add. "Make the change easy, then make the easy change." No detour — the faster route. | Fowler |
| Two Hats | Feature hat (new functionality, new tests) and refactoring hat (structure only, no new tests). Switch deliberately, never mix. | Fowler |
| Code Smells | 24 hints of refactoring need: Mysterious Name, Duplicated Code, Long Function, Feature Envy, Shotgun Surgery, Divergent Change, Primitive Obsession, Repeated Switches, Speculative Generality. | Fowler |
| Extract Function | The most common refactoring. If code would need a comment, extract a function instead. Name it by intent, not by mechanics. Even single lines are worth it. | Fowler |
| Replace Temp with Query | Temporary variables make extractions harder. Replacing them with function calls eliminates locally bound names and makes code more decomposable. | Fowler |
| Rule of Three | First time: just do it. Second time: accept the duplication. Third time: refactor. Prevents premature abstraction and growing duplication. | Fowler |
| Litter-Pickup Refactoring | Leave the code a little better each time you pass through it. The camping rule. Significant improvement over months, code never broken. | Fowler |
| Tests as a precondition | No refactoring without self-checking tests. Test risk-based — the spots most likely to break. Not every method, but every risk. | Fowler |
Architecture & Trade-offs
| Principle | Core | Source |
| Everything is a trade-off | If you think something isn't a trade-off, you just haven't found it yet. "Why" > "How". | Richards/Ford |
| Least-worst Architecture | Never aim for the best architecture – the least bad one. Max. 3 prioritized characteristics. Vasa analogy. | Richards/Ford |
| Architecture Quantum | Smallest independently deployable unit. One set of characteristics = monolith possible. Multiple sets = distributed required. | Richards/Ford |
| Domain > Technical partitioning | Components by business area, not by technical layer. Changes stay confined to one module. | Richards/Ford |
| ADRs | Document every architecture decision: Context, Decision, Consequences. Prevents Groundhog Day and email-driven architecture. | Richards/Ford |
| Use Conway's Law actively | Shape team structures so they promote the desired architecture (Inverse Conway Maneuver). | Richards/Ford |
| Reuse = Coupling | Reuse is implemented through coupling. Domain code changes fast → a poor candidate for reuse. | Richards/Ford |
| Architecture Fitness Functions | Automated tests/metrics that objectively verify architecture characteristics. Governance through code, not reviews. | Richards/Ford |
| Connascence | Precise vocabulary for coupling (static vs. dynamic). Minimize total connascence and cross-boundary connascence. | Richards/Ford |
Craft & Practice
| Principle | Core | Source |
| ETC – Easier to Change | Meta-principle: every design rule (DRY, orthogonality, decoupling) is a special case of ETC. | Hunt/Thomas |
| Broken Windows | A single hack signals neglect and triggers a downward spiral. Repair it immediately. | Hunt/Thomas |
| DRY applies to knowledge | Not identical lines of code, but duplicated knowledge. Two identical functions for different things = no DRY violation. | Hunt/Thomas |
| Tracer Bullets | Thin, working end-to-end slices through all layers. Not a prototype – production-ready code. | Hunt/Thomas |
| Orthogonality | Changes to one don't affect the other. Helicopter controls = anti-pattern. | Hunt/Thomas |
| Crash Early | Fail immediately and loudly instead of running on with corrupted data. Leave assertions in production. | Hunt/Thomas |
| Transformation thinking | Programs transform data: input → transformation → output. Unix pipes as the model. | Hunt/Thomas |
| Actors for concurrency | Shared mutable state = the root of concurrency bugs. Actor model: private state + async messages. | Hunt/Thomas |
| Program deliberately | Never rely on chance. Test assumptions, not just code. Document assumptions. Avoid "programming by coincidence". | Hunt/Thomas |
Data & Distributed Systems
| Principle | Core | Source |
| Data model shapes thinking | Document DB for trees, relational for joins, graph for highly connected structures. "Schemaless" = schema-on-read. | Kleppmann |
| Read vs. write performance | Every index speeds up reads, slows down writes. LSM-Trees vs. B-Trees. OLTP vs. OLAP. | Kleppmann |
| Forward/backward compatibility | New code reads old data, old code ignores new data. Never reuse tag numbers. | Kleppmann |
| Failover is dangerous | Automatic failover can reuse primary keys (GitHub incident). Eventual consistency = 3 concrete anomalies. | Kleppmann |
| Clocks are unreliable | 200ppm drift = 17s/day. Last-Write-Wins with timestamps discards correct writes. Use logical clocks or fencing tokens. | Kleppmann |
| Timeliness vs. Integrity | Timeliness = current data (temporary, self-healing). Integrity = no corruption (permanent). Integrity is almost always more important. | Kleppmann |
| CDC: DB as event stream | Replication log as a public API. Solves the dual-write problem. State = the integral of the event stream. | Kleppmann |
| People > Hardware | Configuration errors cause most outages. Limit the damage instead of forbidding errors: sandbox, rollback, monitoring. | Kleppmann |
| Percentiles instead of averages | Measure p50, p95, p99. Averages hide critical user experience (tail latency amplification). 100ms = ~1% revenue. | Kleppmann |
| Dual Writes antipattern | Never write to two sources at the same time. Use CDC. Dual writes = race conditions + partial failures. | Kleppmann |
Testing
| Principle | Core | Source |
| 4 pillars of a good test | Regression protection × refactoring resistance × fast feedback × maintainability. The product = 0 if any one is zero. | Khorikov |
| Refactoring resistance is binary | A test either has it or it doesn't. Non-negotiable. Tests that check the implementation = false positives during refactoring. | Khorikov |
| Test behavior, not implementation | "What is the end result?" instead of "Which methods were called?" Output-based testing > state-based > communication-based. | Khorikov |
| Functional Core / Mutable Shell | Business logic as pure functions (testable with output tests). Side effects only at the edge. | Khorikov |
| Mock only unmanaged dependencies | DB = managed → real instance. Message bus, SMTP = unmanaged → mock. Mocking internal communication = fragile tests. | Khorikov |
| Walking Skeleton | The thinnest end-to-end slice that can be automatically built, deployed and tested. Solve infrastructure problems early. | Freeman/Pryce |
| Listen to the tests | Hard to test = design feedback. Improve the design, don't deploy more powerful test tools. | Freeman/Pryce |
| Mock only your own types | Never mock third-party APIs directly. Write an adapter layer, in domain language, test it separately. | Freeman/Pryce |
| Coverage is deceptive | A good negative indicator (low = problem), a bad positive indicator (high ≠ quality). Never use as a target metric. | Khorikov |
| Humble Object Pattern | Separate complex logic from hard-to-test dependencies. The controller orchestrates, the logic sits in pure domain classes. | Khorikov |
| Tell, Don't Ask | Objects describe what they want. No long getter chains (order.customer.address.city). Behavior through composition. | Freeman/Pryce |
Accessibility & Inclusion
| Principle | Core | Source |
| Persona Spectrum | Disability = permanent + temporary + situational. One-handed optimization affects 20M instead of 26,000. Curb-cut effect: accessibility features benefit everyone. | Whitaker |
| Dynamic Type is mandatory | Text must never be cut off at any size. Min. touch target: 48dp (Android) / 44px (iOS). No compromise. | Whitaker |
| Color alone is never enough | Always combine with text, shape, position. Min. contrast 4.5:1 (WCAG AA), ideal 7:1 (AAA). | Whitaker |
| Semantic Views group | Related things as one unit for the screen reader. Reduces swipes, gives context. Labels: one word, no type, no period. | Whitaker |
| Respect Reduce Motion | isReduceMotionEnabled / ANIMATOR_DURATION_SCALE must be checked. Flashing elements >3x/s = epilepsy risk. | Whitaker |
Design Systems
| Principle | Core | Source |
| Foundations before components | First document brand, typography, colors, tone of voice. No consistency without a foundation. Digital foundations = the glue of the brand. | Couldwell |
| Design all states | Not just the happy path. Every component: Default, Hover, Error, Disabled, Loading, Empty. "Don't assume developers will figure it out." | Couldwell |
| Audit before design | Build a screenshot inventory of all UI elements. Visual inconsistency = the strongest argument for a design system. | Couldwell |
| Document while working | Not afterwards. For each element, ask: Why like this? When/where to use it? Edge cases? Knowledge leaves with team members. | Couldwell |
Experimentation
| Principle | Core | Source |
| Most ideas fail | ~1/3 of A/B tests are positive. The HiPPO (Highest Paid Person's Opinion) is systematically unreliable. Only experiments deliver truth. | Kohavi |
| Define the OEC | One metric that reflects long-term value. Sensitive, causally linked, hard to game. Revenue alone is dangerous. | Kohavi |
| SRM before analysis | Check the Sample Ratio Mismatch before interpreting results. 50.2/49.8 can be a serious bug. | Kohavi |
| Twyman's Law | "Any interesting figure is probably wrong." Results too good = debug first, celebrate later. Too-good-to-be-true alerts. | Kohavi |
| Goal → Driver → Guardrail | Metrics hierarchically: Goal (long-term), Driver (short-term levers), Guardrail (must not drop: performance, crash rate). | Kohavi |
Systems Thinking & Emergence
| Principle | Core | Source |
| Feedback loops | Balancing (thermostat) and reinforcing (compound interest) loops produce system behavior. Missing feedback = system failure. | Meadows |
| Resilience > Stability | Optimizing systems for efficiency sacrifices resilience. Preserve redundancy, diversity and buffers. JIT supply chains = fragile. | Meadows |
| Leverage points | Parameters (weak) → buffers → delays → feedbacks → rules → goals → paradigms (strong). 99% of attention goes to the weakest levers. | Meadows |
| Delays cause oscillations | The longer the feedback delays, the more fluctuation and overshoot. Fast feedback = a stable system. | Meadows |
| Drift to Low Performance | Standards erode gradually when they are anchored to past (poor) performance instead of an absolute benchmark. | Meadows |
| Bounded Rationality | Everyone acts rationally with incomplete information. Design systems so that rational individual behavior produces good overall outcomes. | Meadows |
| Information flows as leverage | Missing information = the most common cause of system failure. Transparency is often more powerful than new rules. | Meadows |
Interface & Interaction
| Principle | Core | Source |
| Signifier > Affordances | Affordances = possible actions. Signifiers = visible hints about where/how. Focus on signifiers, not affordances. | Norman |
| Conceptual Model | The system image must convey a correct mental model. A wrong model → frustration and errors. | Norman |
| Gulf of Execution / Evaluation | Two gulfs: "How do I operate this?" and "What happened?" Good design bridges both through signifiers, constraints, mappings, feedback. | Norman |
| Natural Mapping | Arrange controls so their function is evident from position/shape. Spatial proximity between control and effect. | Norman |
| Slips vs. Mistakes | Slips = right intention, wrong execution → constraints. Mistakes = wrong intention → better conceptual models. | Norman |
| Human error = design error | When many people make the same mistake, it's the system. Change the design, don't blame people. Five Whys for the root cause. | Norman |
| Featuritis | Successful products grow more complex with every version. Build on strengths instead of fixing weaknesses. | Norman |
Engineering at Scale
| Principle | Core | Source |
| Hyrum's Law | With enough users, every observable behavior becomes the de-facto API — regardless of what the contract promises. Upgrade more often = upgrade cheaper. | Winters |
| Shifting Left | Finding bugs earlier in the development cycle is exponentially cheaper. Configuration errors = the most common cause of major outages. | Winters |
| Beyoncé Rule | "If you liked it, you shoulda put a test on it." CI tests protect features during infrastructure changes — without manual coordination. | Winters |
| Test sizes (Small/Medium/Large) | Classification by resource consumption instead of Unit/Integration/E2E. 80/15/5 distribution. Flakiness >0.1% = existential threat. | Winters |
| Code is a Liability | Functionality is valuable, the code itself is a maintenance burden. Plan deprecation at design time. "Hope is not a strategy." | Winters |
| Code review as a workflow | Three levels: LGTM, Owner Approval, Readability. The primary benefit = knowledge sharing + comprehensibility check, not bug finding. ~200 lines per change. | Winters |
| One-Version Rule | Exactly one version per dependency. Prevents diamond dependencies. Pin external deps explicitly, never "latest". | Winters |
| Faster Is Safer | More frequent, smaller releases = less risk. Feature flags decouple deployment from launch. Release trains with hard deadlines. | Winters |
Domain-Driven Design
| Principle | Core | Source |
| Bounded Contexts | An explicit boundary within which a domain model holds consistently. Different contexts may define the same term differently. One team per context. | Khononov |
| Subdomains → implementation patterns | Core → Domain Model / Event Sourcing. Supporting → Transaction Script / Active Record. Generic → buy. The domain determines the pattern, not the other way around. | Khononov |
| Aggregates as a transaction boundary | One aggregate = one transaction. Only its own business logic may change state. References between aggregates only by ID. Keep them small. | Khononov |
| Event Sourcing | Events as the source of truth instead of current state. Enables audit trail, time travel, multiple projections. Only use it when there's a business need. | Khononov |
| CQRS | Separate models for reading and writing. Read models are regenerable. Especially valuable with Event Sourcing. | Khononov |
| Outbox Pattern | State change + event publication in a single DB transaction. A message relay publishes afterwards. Solves the dual-write problem. | Khononov |
| Ports & Adapters | Business logic defines ports (interfaces), infrastructure implements adapters. Dependency inversion for a testable, swappable architecture. | Khononov |
| Context Map | Visualizes all bounded contexts and their integration patterns (Partnership, ACL, OHS, Conformist, Shared Kernel, Separate Ways). Surfaces organizational problems. | Khononov |
Reading list (the 15 source books)
The principles above are distilled from these books. Read the originals for the full argument and context.
Design & Architecture
- A Philosophy of Software Design — John Ousterhout
- Fundamentals of Software Architecture — Mark Richards & Neal Ford
- Grokking Simplicity — Eric Normand
- Learning Domain-Driven Design — Vlad Khononov
Refactoring
- Refactoring — Martin Fowler
Craft & Practice
- The Pragmatic Programmer — David Thomas & Andrew Hunt
Data & Systems
- Designing Data-Intensive Applications — Martin Kleppmann
Testing
- Unit Testing: Principles, Practices, and Patterns — Vladimir Khorikov
- Growing Object-Oriented Software, Guided by Tests — Steve Freeman & Nat Pryce
Accessibility & Inclusion
- Developing Inclusive Mobile Apps — Rob Whitaker
Design Systems
- Laying the Foundations — Andrew Couldwell
Systems Thinking
- Thinking in Systems — Donella H. Meadows
Interface & Interaction
- The Design of Everyday Things — Don Norman
Experimentation
- Trustworthy Online Controlled Experiments — Ron Kohavi, Diane Tang & Ya Xu
Engineering at Scale
- Software Engineering at Google — Titus Winters, Tom Manshreck & Hyrum Wright
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
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.