arch
Skill5 starsChanged 7 months agoMITView on GitHub
Use when the user wants architecture-first product and system design with explicit stack rationale, boundaries, tradeoffs, data model choices, and phased delivery planning.
5 other projects use a version of this, 1 of them edited.
Adopted by
Most recently taken up by
- NazmusSayad/skillstheir own version, first seen Nov 1, 2026
- replybr/plugadvpltheir own version, first seen Nov 1, 2026
- flexprice/flexpricetheir own version, first seen Oct 8, 2026
- tonydzi/second-brain-starter-kittheir own version, first seen Sep 8, 2026
- JustineDevs/premortemedited, first seen Jun 9, 2026
Other versions5 projects use a version of this.
Word for word · 0
None found.
Edited · 1
- JustineDevs/premortem★ 294% same
Wrote their own version · 4
- flexprice/flexprice★ 6.9ksame name
- tonydzi/second-brain-starter-kit★ 6same name
- NazmusSayad/skills★ 2same name
- replybr/plugadvpl★ 1same 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
5 rules. 0 are common, 5 are distinctive, and 0 are very specific to this project.
0
Common
Most of the 4 edited versions we read keep these.
5
Distinctive
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 inside Codex to turn a product idea into a concrete architecture brief.
- Distinctive: line 31
Ask only for constraints that materially change the architecture.
- Distinctive: line 32
Keep the design biased toward the simplest system that can satisfy the stated requirements.
- Distinctive: line 41
Use glossary terms for the relevant domain, reliability, security, data, and delivery concepts.
- Distinctive: line 47
Every subsystem has one responsibility and a clear interface.
“Common” is measured: kept by at least 6 in 10 of the 4 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Arch
Use this skill inside Codex to turn a product idea into a concrete architecture brief.
Load the machine-readable data/system-design-glossary.json
and use its terms consistently. The glossary is a bounded vocabulary, not a
universal catalog; qualify and cite any term that is not present.
Output
Produce:
- problem framing
decision,status,evidence,blockers,next_allowed_triggers- user and workload assumptions
- system architecture and subsystem boundaries
- stack recommendation with tradeoffs
- rejected alternatives with rationale
- data model and storage choices
- auth, security, and operational concerns
- phased delivery plan
- top risks and open questions
- exact next trigger, usually
$sage
Rules
- Ask only for constraints that materially change the architecture.
- Keep the design biased toward the simplest system that can satisfy the stated requirements.
Procedure
- State the problem, users, constraints, non-goals, and measurable definition of done.
- Map the major components, data flows, trust boundaries, and ownership boundaries.
- By default, classify the candidate architecture against the Software Architecture Guild style catalog: layered, modular, pipeline, microkernel, service-oriented, event-driven, space-based, orchestration-driven, and microservices.
- Select the simplest applicable style or composition, explain its fit to functional and quality requirements, and record the rejected styles and their tradeoffs.
- Cite the source-backed style guidance in the architecture decision. Use the pinned GitMCP source
software-architecture-guild/software-architecture-guild.github.io; never present the catalog as a universal prescription. - Use glossary terms for the relevant domain, reliability, security, data, and delivery concepts; record why each term matters to the decision.
- Define the smallest phased delivery plan, including migration and rollback considerations.
- Hand the decision to
$sagewith open questions, the detected technology inventory, and evidence requirements.
Quality bar
- Every subsystem has one responsibility and a clear interface.
- Operational, security, failure, and data-retention concerns are addressed.
- Recommendations distinguish known facts, assumptions, and decisions still requiring evidence.
- Architecture-style selection is evidence-backed, requirement-driven, and reversible; style names alone are not evidence.
- Glossary definitions never unlock an evidence gate; source receipts and project-specific reasoning remain required.
Example
For a hosted MCP integration, cover endpoint transport, tool contracts, authentication, domain verification, skill distribution, deployment ownership, failure behavior, and the submission boundary before selecting a stack.
- Be explicit about tradeoffs, failure modes, and what should stay out of the first version.
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.