Using architect

Skill Yco-0314/strata/skills/using-architect

Use at the very start of any conversation, and before responding to any build, code, debug, or refactor request — establishes which skills auto-fire and which are human-invoked, and routes coding work through the complexity gate. Read this before EnterPlanMode and before writing any code.From its SKILL.md

Install

npx -y skills add Yco-0314/strata --skill using-architect

Assembled 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 file declares

Copied from the file, not written here

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.9 KB, 871 tokens by cl100k_base, as published. Nobody here has run it

Using Architect

The entry point for the framework. It resolves the one rule that lets ponytail, superpowers, and mattpocock coexist: who is allowed to auto-fire a skill.

The invocation law

Every skill is exactly one of two kinds:

model-invoked — has a rich description; the model may reach for it autonomously. Reserved for discipline skills (cheap, always-safe behaviors).
user-invoked — has disable-model-invocation: true and no trigger description; only the human can start it. Reserved for orchestrators (anything that changes scope or process).

Three kinds of skill

This replaces superpowers' "even a 1% chance → you MUST invoke" rule, which caused invocation storms and defeated the point of human-controlled orchestrators.

Kind	Invocation	Auto-fires?	Examples
Discipline	model-invoked	yes — the model reaches for it	L0 `ponytail`; L4 `debugging`, `review`, `verification-before-completion`
Primitive	model-invoked	no — reached only via the router or a parent skill	L1 `complexity-router`, `grilling`, `domain-modeling`
Orchestrator	user-invoked (`disable-model-invocation: true`)	never — the human types it	L2 `to-prd`, `to-issues`, `writing-plans`; L3 `subagent-driven-development`

The scoped rule:

Auto-invoke only discipline skills. Reach a primitive only via the router or a parent skill, never spontaneously. Never start an orchestrator yourself — name it in one line and let the user choose.

Primitives are model-invoked (not user-invoked) for exactly one reason: composition. A user-invoked skill cannot reach another user-invoked skill, so the shared engines (grilling, domain-modeling) must be model-invoked for to-prd / to-issues to call them. Being model-invoked makes them reachable, not spontaneous — the rule above keeps them from firing on trivial messages.

If a discipline skill turns out wrong for the situation, you don't have to use it — but you must have checked. If an orchestrator looks relevant, say so ("This looks like it wants a plan — run /writing-plans?") and stop.

On any coding task: gate first

Before writing code for a build/feature/refactor request, consult the L1 complexity-router. It decides whether the task is trivial (apply L0 ponytail and go) or whether it crosses the threshold into the design→plan→TDD→review pipeline. Do not skip the gate, and do not over-fire the pipeline on a one-liner.

Order of operations

New conversation → this skill is your first read.
Build/code request → run complexity-router (L1).
Router says trivial → apply ponytail (L0), make the change, leave the one runnable check if the logic is non-trivial, verification-before-completion.
Router says escalate → run grilling (L1 primitive) to align, then name the user-invoked orchestrators for the user to start (to-prd / to-issues or writing-plans → subagent-driven-development → review). ponytail (L0) still governs the size of every diff inside it.
Bug/failure at any point → debugging (L4) auto-fires.

What this skill is not

It does not itself plan, design, or write code. It is the traffic rule. Keep it small — everything else loads lazily via the Skill tool, never by reading skill files directly.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most architecture codebase skills give in 871 tokens

Counted across 811 of the 1,134 authors here whose files we hold, read 2026-08-07

Ask the user which candidate to explorein 45 of 811, across 15 files
Apply the deletion test to suspected shallow modulesin 43 of 811, across 15 files
Read any relevant architecture decision records firstin 31 of 811, across 8 files
Use exact glossary terms in every suggestionin 30 of 811, across 10 files
Accept dependencies instead of creating themin 24 of 811, across 5 files
Include before and after visualisations for each candidatein 24 of 811, across 5 files
Read the domain glossary before exploringin 24 of 811, across 6 files
Return results instead of producing side effectsin 23 of 811, across 4 files
Explore the codebase for shallow modules and frictionin 23 of 811, across 3 files
Introduce seams only where things varyin 22 of 811, across 3 files
Reduce the number of methodsin 21 of 811, across 2 files
Design deep modules with small interfacesin 21 of 811, across 3 files

Said here and by no other author read

read this skill first in any conversation
consult complexity-router before writing code
apply ponytail for trivial routing tasks
run verification before completion for trivial tasks
run grilling for escalated routing tasks
name relevant orchestrators for the user to start

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.