Architecture ideation
Skill andresnator/agents-orchestrator/skills/architecture-ideation
npx -y skills add andresnator/agents-orchestrator --skill architecture-ideationAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 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
Trigger: architecture refactor ideas, target architecture, modular monolith, architecture patterns, restructure the system. Question-driven architecture refactor ideation producing an ADR plus a ready-for-sdd OpenSpec bundle.
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.1 KB, as published. Nobody here has run it
Architecture Ideation
Activation Contract
Use this skill to ideate an architecture-level refactor with the user: target styles (e.g. modular monolith, hexagonal), module boundaries, and architecture-scoped design patterns.
Do not use it for class/method-level refactors — route those to /refactor-plan.
Hard Rules
- Question-driven: run the interview through
native-question-ux, one focused round at a time, grounded in the verified current state (fromarchitecture-state). - Always present 2-3 candidate target architectures with explicit trade-offs and a recommendation — never a single take-it-or-leave-it answer. For monoliths, modular monolith is the default first candidate; microservices must earn their operational cost.
- Every proposed pattern passes
design-patterns-pragmaticandkiss-yagnigates: it must resolve a named force in evidence, not decorate the design. - Ideation is plan-only: no code edits.
Ideation Flow
- Current state in: start from the
architecture-stateoutput (style, modules, gaps). Missing state = establish it first. - Bounded contexts: slice the domain with
domain-modeling; candidate module boundaries come from the domain, not the folder layout. - Candidates: draft 2-3 target architectures. For each: the shape, what it fixes (tied to gap IDs), migration cost, and the first reversible step.
- Question rounds: converge with the user on candidate, boundaries, and migration appetite (big-bang is never offered; strangler-fig/incremental only).
- Decision: record the chosen target and the rejected candidates with reasons.
Outputs
Two artifacts, produced in this order:
- ADR via the
adrskill, saved under<docfolder>/architecture/adr/— the decision, alternatives, and consequences. - Ready-for-sdd bundle per
docs/plan-handoff.md, composed with thesdd-draft-*templates: proposal, design (target architecture + migration order rationale), delta specs, and tasks.tasks.mdrequirements:- First group establishes guardrails: the fitness functions proposed by
architecture-statefor the decided boundaries (see itsreferences/fitness-functions.md). - Migration tasks are incremental and each leaves the build green.
- Test tasks honor the
code-conventionscontract.
- First group establishes guardrails: the fitness functions proposed by
Verification
- 2-3 candidates were presented with trade-offs; the rejected ones are recorded in the ADR.
- Every task ties to a gap ID or a decision in the ADR.
- Bundle passes the plan-handoff self-check: marker first line, four artifacts,
- [ ] X.Ytasks naming real files, forecast guard lines, no Mode/TDD/Judgment line.
Output Contract
Return: chosen target architecture, ADR path, bundle path, first reversible step, and the adoption hint ("ejecuta el plan <change>").