design-rules

Design Community

Repo stars 43
Author repo claude-kit

Interpretation is structured for decision-making; original keeps the upstream SKILL.md unchanged.

Decide Fit First

Core job: Design phase rules for /designer command. Load at /designer startup (step 0). Covers spec quality, design checklist, approach ev…
Best fit: Use it when the task has reusable inputs, steps, and validation criteria rather than a one-off answer.
Avoid forcing it: If the source lacks commands, platform support, or external-service evidence, keep those fields unknown instead of guessing.

Design Intent

Structure: The skill is organized around “Purpose”, “Instructions”, “Step 1: Load at /designer startup”, “Step 2: Use phase-driven loading”, showing how the author expects the agent to judge fit, collect context, and produce verifiable output.
Trigger evidence: Prioritize the author’s wording around when to use it, what context to collect, and what output shape to produce.
Evidence boundary: Author text states facts, repository files prove commands and paths, and Fluxly only adds fit, limits, and usage judgment.

How To Use It

Inputs: Provide target material, scope, expected result, forbidden changes, and validation method.
Invocation: Name design-rules directly; if the source includes slash commands, start with the command and then add task context.
Validation: Start small and check whether the result follows “Purpose / Instructions / Step 1: Load at /designer startup” before expanding.

Boundaries And Review

Dependencies: It usually needs no extra API key, so start with a small validation task.
Permissions: Declared permissions include read / write; ask the agent to state file, command, and rollback boundaries before acting.
Quality bar: A useful result names the deliverable, evidence, and next action. Generic prose means the task needs tighter context.

Design Rules

Purpose

Guidelines for the /designer command to produce high-quality design specs that reduce plan-review iterations.

Instructions

Step 1: Load at /designer startup

Read this SKILL.md for overview. Supporting files loaded on-demand per phase.

Step 2: Use phase-driven loading

Phase 3 (PROPOSE) → read Spec Quality for approach evaluation criteria
Phase 4 (WRITE SPEC) → read Design Checklist for self-verification
Phase 5 (USER GATE) → verify checklist before presenting to user

Spec Quality Criteria

Criterion	Required	Check
Context describes current state	Yes	Not just "add X" but "currently Y exists, need X because Z"
Scope has IN and OUT	Yes	OUT items have explicit reasons
At least 2 approaches compared	Yes	With pros/cons for each
Selected approach has rationale	Yes	References constraints from requirements
Key decisions are numbered	Yes	Each has rationale and impact
Risks have severity and mitigation	Yes	HIGH risks must have concrete mitigation
Acceptance criteria are verifiable	Yes	Each can be checked as pass/fail

Anti-Patterns

Anti-Pattern	Why Bad	Fix
"The obvious approach is..."	Skips exploration, may miss better options	Always compare at least 2
Spec without OUT scope	Scope creep during planning	Explicitly list what's excluded
Vague acceptance criteria ("works well")	Can't verify	Make criteria concrete and testable
No risks identified	Every design has risks	Identify at least 1 per approach
Copying task description as context	No analysis	Describe current state, not just goal

Common Issues

Designer skips CLARIFY phase

Cause: Task seems clear. Fix: Even "clear" tasks benefit from scope IN/OUT confirmation. At minimum, confirm scope.

User rejects all approaches

Cause: Missing constraint not captured. Fix: Ask: "What constraint am I missing?" — don't generate more approaches without new information.

References

Spec Quality — detailed quality criteria, approach evaluation matrix
Design Checklist — phase-by-phase self-verification

Fluxly profile Author and license come from source; runtime, permissions, and network are Fluxly detections or estimates

Fluxly category: Design
Author-declared agents: No explicit declaration found; this is not inferred or tested compatibility
Static check: 88 / 100 · heuristic scan, not runtime safety proof
Author / version / license: @hex0xdeadbeef · no license declared
Fluxly token estimate: Lean
Fluxly setup estimate: Plug-and-play
External API key: No requirement detected
Detected OS requirements: Unspecified
Runtime requirements: Unspecified
Detected file/system behavior: Read-only
Write / modify
Detected network behavior: Local-only
Install commands: None (reference only)

Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.

Heads up: 未限定 allowed-tools，默认拥有全部工具权限。

Output preview design-rules.preview

The current SKILL.md does not define a fixed output example.

SKILL.md SKILL.md

# Design Rules

## Purpose
Guidelines for the /designer command to produce high-quality design specs that reduce plan-review iterations.

## Instructions

### Step 1: Load at /designer startup
Read this SKILL.md for overview. Supporting files loaded on-demand per phase.

### Step 2: Use phase-driven loading
- Phase 3 (PROPOSE) → read [Spec Quality](spec-quality.md) for approach evaluation criteria
- Phase 4 (WRITE SPEC) → read [Design Checklist](design-checklist.md) for self-verification
- Phase 5 (USER GATE) → verify checklist before presenting to user

## Spec Quality Criteria

| Criterion | Required | Check |
|-----------|----------|-------|
| Context describes current state | Yes | Not just "add X" but "currently Y exists, need X because Z" |
| Scope has IN and OUT | Yes | OUT items have explicit reasons |
| At least 2 approaches compared | Yes | With pros/cons for each |
| Selected approach has rationale | Yes | References constraints from requirements |
| Key decisions are numbered | Yes | Each has rationale and impact |
| Risks have severity and mitigation | Yes | HIGH risks must have concrete mitigation |
| Acceptance criteria are verifiable | Yes | Each can be checked as pass/fail |

## Anti-Patterns

| Anti-Pattern | Why Bad | Fix |
|---|---|---|
| "The obvious approach is..." | Skips exploration, may miss better options | Always compare at least 2 |
| Spec without OUT scope | Scope creep during planning | Explicitly list what's excluded |
| Vague acceptance criteria ("works well") | Can't verify | Make criteria concrete and testable |
| No risks identified | Every design has risks | Identify at least 1 per approach |
| Copying task description as context | No analysis | Describe current state, not just goal |

## Common Issues

…

Evidence boundary and execution chain

Author text anchors workflow facts; Fluxly only indexes current sections, terms, files, and commands.

sections -> Purpose → Instructions → Step 1: Load at /designer startup → Step 2: Use phase-driven loading → Spec Quality Criteria → Anti-Patterns
terms    -> Cause · Fix
files/cmd -> spec-quality.md · design-checklist.md · pros/cons · pass/fail · IN/OUT
body sha256 -> 4f9c48bce1ee