agentleFS
Sign inStart free
jdanigojdanigo/hydraia/skills/greenfield-architect/SKILL.md

greenfield-architect

Skill8 starsChanged 2 months agoMITView on GitHub

Use when the user wants a new app, service, or system designed from scratch — greenfield work with no existing code to anchor to. Interactive architect: elicits requirements one question at a time, drives architecture proposals, recommends a stack with rationale, designs the API contract, and records every decision as an ADR. Never assumes scale, stack, or constraints.

The file

We split this skill into the rules it gives an agent

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

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈4

    Distinctive · estimate

    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:

    Never pick a stack silently: recommendation + rationale + explicit human confirmation.

    line 12
  2. Distinctive:

    Default architecture is a well-structured monolith.

    line 13
  3. Distinctive:

    Every load-bearing decision becomes an ADR (adr skill).

    line 14
  4. Distinctive:

    API surface: If the system exposes an API, run the api-design skill now — the contract file becomes part of the spec.

    line 28

≈ “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

Greenfield Architect — design the system before the first line

Runs in the MAIN session (interactive). The "app from scratch" route of the Hydraia pipeline: everything here happens BEFORE the normal Phase 2 spec, and feeds it.

<HARD-RULES> - One question at a time (AskUserQuestion, multiple-choice preferred). Never a questionnaire wall. - Never pick a stack silently: recommendation + rationale + explicit human confirmation. - Default architecture is a well-structured monolith. Splitting into services requires EVIDENCE from elicitation (scale, team topology); splitting without it is over-engineering and must be named as such. - Every load-bearing decision becomes an ADR (adr skill). No decision lives only in chat. - "No sé" is a valid human answer: propose a safe default, state the assumption explicitly in the ADR's Context, and set a revisit trigger. </HARD-RULES>

Flow

  1. Elicit (in this order, one question each, skip what the request already answers):
    • Problem + primary users — what pain, who feels it.
    • Scale honesty — expected users/data/requests as ranges (10? 10k? 10M?). Push back on fantasy numbers.
    • Constraints — team size and skills (weighs heavily on stack), budget, deploy target (cloud/on-prem/serverless), compliance (PII? payments? health?).
    • Non-functional requirements — latency targets, availability, security posture.
    • Integration landscape — what existing systems it must talk to.
  2. Architecture proposal. Dispatch the architect agent (system shape, trade-offs) and code-architect agent (concrete file/interface blueprint). Apply the microservices-architect skill ONLY if elicitation produced evidence for a split. Present 2–3 shapes with trade-offs and one recommendation.
  3. Stack recommendation. Anchored to elicited constraints — team skills first, ecosystem fit second, hype never. Confirm with the human. Name the Phase 4 pattern skill that will govern implementation (react-patterns / node-patterns / dotnet-patterns / golang-patterns / springboot-patterns / python-patterns).
  4. API surface. If the system exposes an API, run the api-design skill now — the contract file becomes part of the spec.
  5. Record decisions. Architecture shape, stack, data store, auth approach, hosting — each gets an ADR via the adr skill, committed with the spec.
  6. Hand off to the normal pipeline: Phase 2 spec references the ADRs by number and embeds/links the contract; Phases 3–6 run unchanged.

Anti-patterns to refuse

  • Microservices for a 2-person team "to be ready for scale" → monolith + ADR with the split trigger.
  • Choosing the stack the model likes over the stack the team knows.
  • Designing for 10M users when elicitation said 500.
  • Skipping the API contract because "we can document it later".

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.

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.

Check your setup, free