Architecture
npx -y skills add athal7/dotfiles --skill architectureAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 6 stars6 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Load before designing a new system, choosing between competing implementations, weighing tradeoffs across libraries or frameworks, or escalating an architectural question to a human. Fires at the moment a multi-option design decision appears, not during routine implementation.
The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
3.3 KB, as published. Nobody here has run it
Use this when facing a software design decision with multiple valid approaches, hard-to-reverse consequences, or system boundary implications.
Design prerequisite check
Before evaluating options, check whether a prerequisite refactor would simplify the work. For any change touching domain logic, authorization, state machines, or anything enforced in more than one layer — read the relevant code and answer:
- Scattered enforcement: is this concept already checked in multiple places? List callsites. If yes, is centralizing first a prerequisite?
- Coupling: does this add a new dependency between modules that had no prior relationship?
- Extensibility: is this the 2nd or 3rd instance of a pattern? Is there a single abstraction that serves all of them?
If a prerequisite refactor would simplify the work, surface it: propose a separate issue/PR, get user confirmation, do it first.
Steps
-
Gather context. State the problem, constraints, and options. Check issue history and prior decisions if relevant. Research patterns, prior art, library docs.
-
Present options as a table. Always include 2+ options — never one-option-as-fait-accompli.
Option A Option B … What it is … … … Pros … … … Cons … … … Best when … … … -
Score against software-architecture criteria:
- Reversibility: how painful to undo in 6 months?
- YAGNI: real present problem or hypothetical?
- Simplicity: which would a new team member understand fastest?
- Testability: which is easiest to test in isolation?
- Coupling: does it create hard dependencies that constrain future changes?
- Operational cost: what does it add to deploy, monitor, debug?
- DX: which is less annoying day-to-day?
Prefer reversibility and simplicity when criteria conflict. Complexity must earn its place.
-
Call out system-level anti-patterns by name when present in any option — use the code-quality catalog (Premature Abstraction, Wrong Layer, Leaky Abstraction, Distributed Monolith, Config as Code, Speculative Generality).
-
Escalate when any of these are true; do not recommend unilaterally:
- Irreversible at the data layer (schema changes, migration strategy)
- Crosses service/team boundaries
- Significant operational cost (new infrastructure, new external dependency)
- You are genuinely uncertain after applying the framework
-
Recommend with one concrete sentence naming the single most important reason. Never be vague. Never present one option as if no alternatives exist.
Writing the decision down
If the user asks for an ADR (architecture decision record), use templates/adr.md in this skill directory — covers status, context, decision, decision matrix, alternatives, consequences, and common mistakes. Apply the template to the user's situation; don't repeat it verbatim.