Aped Design Twice

---
name: aped-design-twice
keep-coding-instructions: true
description: 'Use when user says "design twice", "alternative design", "explore options", "what else could we do", "second opinion on architecture", or invokes aped-design-twice. Generates two competing designs before committing to one. Prevents premature lock-in.'
allowed-tools: "Read Write Bash Grep Glob"
allowed-paths:
  write: ["{{OUTPUT_DIR}}/**", "{{APED_DIR}}/**"]
  read-only: ["src/**", "tests/**", "package.json"]
---
<!-- AUTO-GENERATED from SKILL.md.tmpl. Edits will be overwritten. Run: npm run gen:skill-docs -->

**Activation guard (6.2.0):** Before any other action, run `bash {{APED_DIR}}/scripts/check-enabled.sh`. If it exits non-zero, print "APED disabled — run aped-method enable" and HALT.

# aped-design-twice — Dual Design Exploration

## Purpose

Generate two genuinely different designs for the same requirement BEFORE committing to one. The first design is rarely the best — it's the most obvious. The second design, forced by constraint, often reveals trade-offs the first hid.

## Iron Laws

See [`ETHOS.md` § aped-design-twice](../ETHOS.md#aped-design-twice) — three laws: two designs minimum; Design B must be structurally different; decision is explicit.

## Pipeline

### Step 1: Read the requirement

Read `{{OUTPUT_DIR}}/prd.md` and/or `{{OUTPUT_DIR}}/architecture.md`. Identify the component or decision being designed.

### Step 2: Design A — the obvious solution

Sketch the first design. This is what you'd build if you had 5 minutes to decide:
- Data model
- Key interfaces / API surface
- Dependencies
- Estimated complexity (S/M/L)

### Step 3: Design B — the forced alternative

Now design an alternative that differs on at least ONE structural axis:

| Axis | Design A | Design B |
|---|---|---|
| Data storage | SQL normalized | Document store denormalized |
| API style | REST | GraphQL |
| State management | Server-side sessions | Client-side JWT |
| Architecture | Monolith | Microservices |
| Concurrency | Locks | Event sourcing |

Design B must be VIABLE — not a strawman. If you can't make B viable, you haven't explored the space enough.

### Step 4: Trade-off matrix

| Dimension | Design A | Design B |
|---|---|---|
| Complexity | ... | ... |
| Performance | ... | ... |
| Maintainability | ... | ... |
| Migration risk | ... | ... |
| Team familiarity | ... | ... |

### Step 5: Recommendation + user choice

Present both designs with the trade-off matrix. State your recommendation and WHY, but make it clear the user decides:

"I recommend Design [A/B] because [trade-off reason]. Design [B/A] would be better if [condition]. Which should we proceed with?"

### Step 6: Emit to architecture

Write the chosen design into `{{OUTPUT_DIR}}/architecture.md` (if it doesn't exist yet) or feed it to `aped-arch` as input. Record the rejected design in `{{OUTPUT_DIR}}/design-alternatives.md` for future reference.

## Stop Conditions

- Both designs sketched → trade-off matrix → user chose → written to arch → DONE.
- User says "just go with A" before Step 3 → record the skip → proceed with A → DONE.