agentleFS
Sign inStart free
gclmgclm/super-stack/skills/planning/architecture-design/SKILL.md

architecture-design

Skill0 starsChanged 7 months agoMITView on GitHub

Compare and shape system structure, boundaries, dependencies, and scaling trade-offs before committing to a larger technical direction.

We split this skill into the rules it gives an agent

3 rules. 0 are common, 3 are distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 24 edited versions we read keep these.

  • 3

    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
  1. Distinctive:

    Use this skill when the real question is system shape: module boundaries, service decomposition, responsibility split, dependency …

    line 8
  2. Distinctive:

    avoid locking into architecture for the wrong reason

    line 22
  3. Distinctive:

    Call out what should stay simple and what actually deserves abstraction.

    line 36

“Common” is measured: kept by at least 6 in 10 of the 24 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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Architecture Design

Use this skill when the real question is system shape: module boundaries, service decomposition, responsibility split, dependency direction, or long-term structural trade-offs.

Read First

  • the current architecture map if it exists
  • key requirements, risks, and non-goals
  • integration boundaries and operational constraints
  • docs/overview/project-overview.md, docs/reference/requirements.md, and harness/state.md if they exist
  • harness/history.md if it exists

Goals

  • recommend a structure that matches the problem instead of abstract purity
  • make boundaries and dependency flow explicit
  • compare realistic options with trade-offs
  • avoid locking into architecture for the wrong reason

Steps

  1. Define the architectural decision that must be made.
  2. Identify the forces on the decision:
    • scale
    • team workflow
    • deployment model
    • reliability
    • change frequency
    • domain complexity
  3. Compare 2-3 credible structures.
  4. Explain why the recommended structure is better for this context.
  5. Call out what should stay simple and what actually deserves abstraction.
  6. Capture risks, migration cost, and follow-up implications.

Output

Report:

  • decision to make
  • options considered
  • recommended structure
  • dependency and boundary rules
  • trade-offs
  • migration or rollout implications

Download now (ZIP)

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.

Check your setup, free