design-tree-core

Original：🇺🇸 English

Translated

Internal/shared core rules for design-tree skills. Use only when maintaining the design-tree system itself or when another design skill needs shared governance rules for derivation, handoff, boundaries, or anti-bloat controls. Do not trigger for ordinary user design requests, and do not use as a replacement for design-orchestrator, design-structure, or design-refinement.

2installs

Sourcefreeacger/loom

Added on2026-04-26

NPX Install

npx skill4agent add freeacger/loom design-tree-core

SKILL.md Content

View Translation Comparison →

Design Tree Core

Overview

This skill is the shared governance core for the design-tree skill family.

It is not a general design skill. It is not a user-facing entrypoint for normal design work. It exists to define the minimum shared contract that all design-tree skills must honor.

Its job is to protect only the rules that stay stable across the family:

required
```
design_state
```
fields (including the mandatory
```
design_target_type
```
)
```
design_target_type
```
vocabulary and the prohibition on silent inference
derivation criteria
parent/child handoff contracts
anti-bloat governance

When to Use

Use this skill only when:

maintaining or revising the design-tree skill system itself
changing the shared
```
design_state
```
contract
aligning multiple design skills on
```
design_target_type
```
behavior
deciding whether a new design tree should be derived
checking whether shared design-tree rules belong in a common core
aligning multiple design skills on shared boundary or handoff rules
preventing design-tree drift, duplication, or bloat

Do not use this skill when:

the user needs normal design routing
the task is to create an initial design tree
the task is to refine an existing design tree
the task is to evaluate a bounded design decision
the task is to check whether a design is ready for planning
the task is to write a design doc, report, note, or plan
the task is to store project-specific conclusions, examples, or temporary guidance

Core Responsibility

This skill owns only rules that are all of the following:

Shared across at least two design-tree skills
Stable over time
Directly relevant to design-state boundaries, routing, derivation, handoff, or anti-bloat governance
Too central to leave implicit
Too shared to belong to only one skill

If a rule fails any of those tests, it does not belong here.

Forbidden Content

The following content must not be added to this skill or its references:

project-specific conclusions
one-off discussion outcomes
long examples or case studies
detailed templates
persistence adapters or repo-specific save workflows
release workflow details
single-skill-specific rules
content-production rules for reports, notes, or plans
FAQ-style patch accumulation
explanatory expansions that do not change shared design-tree behavior

If content is useful but not core, move it elsewhere.

Admission Rule

New content may enter this skill only if it satisfies all checks below:

It affects more than one design-tree skill.
It is a stable rule, not a local workaround.
It changes or protects shared boundaries, routing, derivation, handoff, or anti-bloat behavior.
Omitting it would cause shared drift or inconsistent decisions.
It cannot be placed more naturally in:
- a specific design skill
- a reference file for one skill
- an eval
- an example
- a design doc
- a report
- a checklist
- a script

If any check fails, reject the addition.

Eviction Rule

Content must be moved out of this skill when any of the following becomes true:

it is only used by one skill
it becomes project-specific
it is mainly explanatory rather than behavioral
it is better represented as an example, template, checklist, or script
it increases size without increasing shared governance value

Do not keep content here just because it was historically added.

Derivation Scope

This skill may define shared rules for when a design tree should be derived into a new tree.

It must not define the full operating logic of any derived tree. Once a derived tree has its own stable responsibility, that logic belongs in the derived tree, not here.

Shared Output Contract

Design-tree skills share one primary output contract: they produce or update

design_state

.

They do not share a default file-writing contract. If a specific skill or repository wants to persist a design file, that behavior belongs in that skill's local reference or adapter rules, not in the shared core.

Output Contract

When this skill is used, the output should be limited to one or more of:

shared
```
design_state
```
clarification
```
design_target_type
```
clarification
shared rule clarification
derivation decision criteria
handoff contract clarification
anti-bloat governance guidance
keep / move / derive recommendations for design-tree content

It should not produce a normal design tree as output.

Maintenance Rule

Keep this skill small and rigid.

Prefer the shortest rule that preserves shared behavior.
Prefer moving detail out over expanding this file.
Prefer reference files over inline accumulation.
Prefer deletion over historical clutter.

This skill is healthy only if it remains smaller and more stable than the skills that depend on it.

Mandatory Target Type Rule

design_target_type

is a mandatory field of

design_state

. No design-tree skill may silently infer, assume, default, or derive a

design_target_type

value. When it is missing, every design-tree skill must treat the state as invalid and either stop or route to the step that can set it explicitly.

See REFERENCE.md section 1.2 for the full rule.

Relationship to Other Skills

```
design-orchestrator
```
may use this skill when deciding whether to derive a new tree.
```
design-orchestrator
```
may use this skill when rejecting a design flow that is missing
```
design_target_type
```
.
```
design-structure
```
may use this skill when creating a derived tree.
```
design-structure
```
may use this skill when choosing the correct target-type skeleton.
```
design-refinement
```
may use this skill when a branch appears to be evolving into a separate stable decision system.
```
design-readiness-check
```
may use this skill only to detect missing required state, tree-structure drift, or mixed responsibilities.

This skill must not take over their normal responsibilities.

Reference Files

Detailed shared rules should live in companion reference files such as:

```
REFERENCE.md
```
```
CHANGELOG.md
```

Keep

SKILL.md

as the strict entry contract, not the full knowledge base.