Skip to content
Back to skills

Design Rules

ASecurity

Design phase rules for /designer command. Load at /designer startup (step 0). Covers spec quality, design checklist, approach evaluation criteria.

  • 46 stars
  • 0 votes
  • 0 copies
  • 4 views
  • Added May 27, 2026
documentationgo

Security analysis

A100/100

Pro scans all 3 files and shows the line behind each finding

Scanned May 27, 2026

npx -y skills add hex0xdeadbeef/claude-kit --skill design-rules --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Design Rules?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Design Rules
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/hex0xdeadbeef-design-rules/badge)](https://www.skillsdirectory.com/skills/hex0xdeadbeef-design-rules)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: design-rules
description: Design phase rules for /designer command. Load at /designer startup (step 0). Covers spec quality, design checklist, approach evaluation criteria.
disable-model-invocation: true
---

# 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

### 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](spec-quality.md) — detailed quality criteria, approach evaluation matrix
- [Design Checklist](design-checklist.md) — phase-by-phase self-verification

Files in this skill

  • SKILL.md2.5 KB
  • design-checklist.md1.2 KB
  • spec-quality.md1.4 KB

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.