/skill-based-architecture
This skill should be used when the user asks to "organize the project rules", "clean up scattered documentation", "把规则迁移到 skills 目录", "优化 skill 路由", "提高 description 命中率", or "减少薄壳重复维护". Activate when a SKILL.md is too large, rules are duplicated across agent entry files, task
$ npx -y skills add WoJiSama/skill-based-architecture --skill skill-based-architecture --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/skill-based-architecture
Context preview
The summary Claude sees to decide when to auto-load this skill.
This skill should be used when the user asks to "organize the project rules", "clean up scattered documentation", "把规则迁移到 skills 目录", "优化 skill 路由", "提高 description 命中率", or "减少薄壳重复维护". Activate when a SKILL.md is too large, rules are duplicated across agent entry files, task
SKILL.md
skill-based-architecture.SKILL.mdname: skill-based-architecture
description: >
This skill should be used when the user asks to "organize the project rules",
"clean up scattered documentation", "把规则迁移到 skills 目录", "优化 skill 路由",
"提高 description 命中率", or "减少薄壳重复维护".
Activate when a SKILL.md is too large, rules are duplicated across agent entry
files, task routing or trigger_examples miss natural user language, or
templates / thin shells / validation scripts need drift-resistant maintenance.
Skill-Based Architecture
Restructure oversized single-file Skills or scattered project rules into a well-organized Skill directory. Builds on the official minimal Agent Skill contract (`name` + `description`) and kicks in when a single small `SKILL.md` is no longer enough.
When to Use
- A single `SKILL.md` exceeds ~150 lines, mixing rules, workflows, and background material; or project rules are scattered across `AGENTS.md`, `CLAUDE.md`, `CODEX.md`, `.cursor/rules/`, `.claude/`, etc.
- Recurring tasks need procedures, fitted verification, or reliable completion checks; or the user explicitly requests Skill-based architecture or rule consolidation.
- Skip temporary repos with no durable routing need, teams with a working compact instruction system, and small projects; an explicit SBA request may still materialize a complete direct `SKILL.md` carrier.
Progressive Rigor
Grow only under pressure. The materializer derives **Single-file**, **Folder-light**, or **Full/broad** internally from target evidence; users do not select a tier, profile, capability pack, or install mode. `routing.yaml`, Task Execution, Task Closure, maintenance checks, and each harness surface need their own routing/loading/ownership pressure. **Split by abstraction (骨架/肉)** when content tangles invariant design theory with current-code facts: abstract theory → `architecture/`, code maps → `references/`, house style → `conventions/`, per-module landmines → `gotchas/` (methodology stays in `rules/`). Downgrade when content shrinks. Details: [references/progressive-rigor.md](references/progressive-rigor.md).
Evidence-Selected Structure
# direct
skills/<name>/SKILL.md
# folder-light or broad: only admitted owners/directories
skills/<name>/{SKILL.md,rules/,workflows/,references/,scripts/}`routing.yaml` appears only when route data has an independent owner; root/tool entry and registration surfaces appear only for proven readers. Existing root entries are preserved. Emitted routed entries use a generated `routing.yaml` bootstrap; direct entries point to the sole `SKILL.md` procedure. Cursor registration exists only when Cursor is detected, declared, currently used, or explicitly requested. See [REFERENCE.md](REFERENCE.md) for sources.
Core Principles
1. **Single concise entry** — `SKILL.md` keeps a dual budget: description ≤ 25 lines (trigger phrases + activation) + body ≤ 90 lines (navigation); it navigates, not exhausts. ✓ Check: smoke-test reports both separately; over either → split intent clusters / move detail to sub-files. 2. **One skill folder when a folder is admitted** — folder-light and broad results keep formal docs under `skills/<name>/`; a direct result may remain a complete single `SKILL.md` carrier. ✓ Check: no emitted root entry becomes a second rule/workflow owner. 3. **Rules ≠ Flows** — `rules/` for constraints, `workflows/` for procedures. ✓ Check: any numbered steps in `rules/`, or "always/never" in `workflows/`, = mixing. 4. **Routing.yaml as source when admitted** — a direct carrier owns its sole route in `SKILL.md`; multiple/shared routes live only in `routing.yaml`, with routed shells generated from it. ✓ Check: is there an independent selector or consumer that justifies the manifest, and does its fitted sync check pass? 5. **Harness surfaces follow readers** — create/merge only entries and registrations supported by existing files/config, the current harness, repository/team declaration, or an explicit request. ✓ Check: can every emitted surface name its reader, and was every existing entry preserved? 6. **Progressive Rigor** — three carriers (Single-file / Folder-light / Full) grow only under pressure and are not user package choices. ✓ Check: can you name the independent responsibility that forced every generated file? 7. **Description = coarse activation** — domain boundary + real user trigger phrases; never enumerate workflow keywords nor summarize a workflow's steps. ✓ Check: can `routing.yaml` task routes change without rewriting the description, and does no description/label carry HOW an agent could act on without opening the body? 8. **Gotchas are highest-value** — maintain costly pitfalls actively; keep them discoverable. ✓ Check: is each high-cost gotcha activated by the admitted route owner (`SKILL.md` or `routing.yaml`), not only buried in `references/`? 9. **Progressive disclosure** — every loaded file needs an independent task-time reason; conditional content leaves the startup read set; files every real caller co-loads should merge unless ownership/generation requires separate storage. ✓ Check: for each route read, can you name a request that needs it now and a next action it changes? No → conditionally route, merge, or remove. 10. **Task Execution + Closure** — only one clear read-only or fixed-contract maintenance action with no new desired behavior executes directly; anything that adds or changes user-visible behavior, a business flow/state, or an external contract follows `requirement-ready -> Task Anchor -> implementation-ready -> Native Plan -> mutation`; Present alignment proportionally and run a compact Anchor Checkpoint before each main step. Workflow is the domain procedure; Native Plan is only this Session's runtime step owner, with no planning-file persistence. Full protocol: [references/protocols.md § Task Execution Protocol](references/protocols.md#task-execution-protocol). 11. **Durable-record rule** — generic records generalize across projects; business global
Read more
name: skill-based-architecture description: > This skill should be used when the user asks to "organize the project rules", "clean up scattered documentation", "把规则迁移到 skills 目录", "优化 skill 路由", "提高 description 命中率", or "减少薄壳重复维护". Activate when a SKILL.md is too large, rules are duplicated across agent entry files, task routing or trigger_examples miss natural user language, or templates / thin shells / validation scripts need drift-resistant maintenance.
Skill-Based Architecture
Restructure oversized single-file Skills or scattered project rules into a well-organized Skill directory. Builds on the official minimal Agent Skill contract (`name` + `description`) and kicks in when a single small `SKILL.md` is no longer enough.
When to Use
- A single `SKILL.md` exceeds ~150 lines, mixing rules, workflows, and background material; or project rules are scattered across `AGENTS.md`, `CLAUDE.md`, `CODEX.md`, `.cursor/rules/`, `.claude/`, etc.
- Recurring tasks need procedures, fitted verification, or reliable completion checks; or the user explicitly requests Skill-based architecture or rule consolidation.
- Skip temporary repos with no durable routing need, teams with a working compact instruction system, and small projects; an explicit SBA request may still materialize a complete direct `SKILL.md` carrier.
Progressive Rigor
Grow only under pressure. The materializer derives **Single-file**, **Folder-light**, or **Full/broad** internally from target evidence; users do not select a tier, profile, capability pack, or install mode. `routing.yaml`, Task Execution, Task Closure, maintenance checks, and each harness surface need their own routing/loading/ownership pressure. **Split by abstraction (骨架/肉)** when content tangles invariant design theory with current-code facts: abstract theory → `architecture/`, code maps → `references/`, house style → `conventions/`, per-module landmines → `gotchas/` (methodology stays in `rules/`). Downgrade when content shrinks. Details: [references/progressive-rigor.md](references/progressive-rigor.md).
Evidence-Selected Structure
# direct
skills/<name>/SKILL.md
# folder-light or broad: only admitted owners/directories
skills/<name>/{SKILL.md,rules/,workflows/,references/,scripts/}`routing.yaml` appears only when route data has an independent owner; root/tool entry and registration surfaces appear only for proven readers. Existing root entries are preserved. Emitted routed entries use a generated `routing.yaml` bootstrap; direct entries point to the sole `SKILL.md` procedure. Cursor registration exists only when Cursor is detected, declared, currently used, or explicitly requested. See [REFERENCE.md](REFERENCE.md) for sources.
Core Principles
1. **Single concise entry** — `SKILL.md` keeps a dual budget: description ≤ 25 lines (trigger phrases + activation) + body ≤ 90 lines (navigation); it navigates, not exhausts. ✓ Check: smoke-test reports both separately; over either → split intent clusters / move detail to sub-files. 2. **One skill folder when a folder is admitted** — folder-light and broad results keep formal docs under `skills/<name>/`; a direct result may remain a complete single `SKILL.md` carrier. ✓ Check: no emitted root entry becomes a second rule/workflow owner. 3. **Rules ≠ Flows** — `rules/` for constraints, `workflows/` for procedures. ✓ Check: any numbered steps in `rules/`, or "always/never" in `workflows/`, = mixing. 4. **Routing.yaml as source when admitted** — a direct carrier owns its sole route in `SKILL.md`; multiple/shared routes live only in `routing.yaml`, with routed shells generated from it. ✓ Check: is there an independent selector or consumer that justifies the manifest, and does its fitted sync check pass? 5. **Harness surfaces follow readers** — create/merge only entries and registrations supported by existing files/config, the current harness, repository/team declaration, or an explicit request. ✓ Check: can every emitted surface name its reader, and was every existing entry preserved? 6. **Progressive Rigor** — three carriers (Single-file / Folder-light / Full) grow only under pressure and are not user package choices. ✓ Check: can you name the independent responsibility that forced every generated file? 7. **Description = coarse activation** — domain boundary + real user trigger phrases; never enumerate workflow keywords nor summarize a workflow's steps. ✓ Check: can `routing.yaml` task routes change without rewriting the description, and does no description/label carry HOW an agent could act on without opening the body? 8. **Gotchas are highest-value** — maintain costly pitfalls actively; keep them discoverable. ✓ Check: is each high-cost gotcha activated by the admitted route owner (`SKILL.md` or `routing.yaml`), not only buried in `references/`? 9. **Progressive disclosure** — every loaded file needs an independent task-time reason; conditional content leaves the startup read set; files every real caller co-loads should merge unless ownership/generation requires separate storage. ✓ Check: for each route read, can you name a request that needs it now and a next action it changes? No → conditionally route, merge, or remove. 10. **Task Execution + Closure** — only one clear read-only or fixed-contract maintenance action with no new desired behavior executes directly; anything that adds or changes user-visible behavior, a business flow/state, or an external contract follows `requirement-ready -> Task Anchor -> implementation-ready -> Native Plan -> mutation`; Present alignment proportionally and run a compact Anchor Checkpoint before each main step. Workflow is the domain procedure; Native Plan is only this Session's runtime step owner, with no planning-file persistence. Full protocol: [references/protocols.md § Task Execution Protocol](references/protocols.md#task-execution-protocol). 11. **Durable-record rule** — generic records generalize across projects; business global
A meta-skill that produces skills. Point it at any codebase and it distills the project's rules, workflows, and hard-won lessons into a dedicated skills/<name>/ directory — a project skill that becomes the single source of truth every AI agent (Cursor, Claude Code, Codex, Windsurf, Gemini) consults before every task.