Don't write code in design doc

[LukeLIN-web]

Describe the bug

The brainstorming skill's design doc output (saved to
docs/plans/YYYY-MM-DD--design.md) often includes inline code blocks and code snippets
(Python, bash, etc.). Design docs should focus on ideas, architecture, and rationale — not
implementation details that belong in the implementation plan phase.

To Reproduce

1. Start a new session and describe a feature to build
2. Go through the brainstorming flow (clarifying questions → approach selection → design)
3. Approve the design
4. The skill writes the design doc to docs/plans/
5. The resulting .md file contains code blocks (python, bash, etc.) with
   implementation snippets

Expected behavior

The design doc should only contain:

• Design ideas and architecture
• Component descriptions and data flow
• Trade-offs and rationale
• Success criteria

Code blocks and file paths should be deferred to the implementation plan (via the
writing-plans skill), not embedded in the design doc. File paths in design docs also go
stale when files are moved.

Additional context

The writing-plans skill already exists as the next step after brainstorming specifically for
implementation details. Having code in both the design doc and the implementation plan
creates duplication and makes design docs harder to read as high-level references.

A simple fix would be adding a rule to the "Presenting the design" section in
skills/brainstorming/SKILL.md:

[obra]

Can you post an example of a spec file where you're seeing this?

[LukeLIN-web]

Can you post an example of a spec file where you're seeing this?

I don't have one, I just observe there are a lot of block codes in markdown and stale very fast.

[Seanbo5386]

I feel like that may be by design?
I can reproduce the issue:

### Task 6: Add amber glow filter on dgx-03

**Files:**
- Modify: `docs/cluster-animation.svg`

**Step 1: Add SVG filter definition**

Inside `<defs>`, add a glow filter:
```xml
<filter id="amberGlow" x="-20%" y="-20%" width="140%" height="140%">
  <feGaussianBlur in="SourceGraphic" stdDeviation="3" result="blur"/>
  <feFlood flood-color="#D4A017" flood-opacity="0.3" result="color"/>
  <feComposite in="color" in2="blur" operator="in" result="glow"/>
  <feMerge>
    <feMergeNode in="glow"/>
    <feMergeNode in="SourceGraphic"/>
  </feMerge>
</filter>

**Step 2: Add a glow overlay rect on dgx-03**

Add a `<rect>` matching the dgx-03 card dimensions with `filter="url(#amberGlow)"`, `fill="none"`, `stroke="#D4A017"`, `stroke-width="1"`, initially at `opacity: 0`, class `node3-glow`.

```css
@keyframes glowFadeIn {
  0%, 46.7% { opacity: 0; }
  66.7%, 86.7% { opacity: 1; }
  100% { opacity: 0; }
}
.node3-glow {
  animation: glowFadeIn 15s ease-in-out infinite;
}

[Gamarsoft]

I feel like that may be by design? I can reproduce the issue:

### Task 6: Add amber glow filter on dgx-03

**Files:**
- Modify: `docs/cluster-animation.svg`

**Step 1: Add SVG filter definition**

Inside `<defs>`, add a glow filter:
```xml
<filter id="amberGlow" x="-20%" y="-20%" width="140%" height="140%">
  <feGaussianBlur in="SourceGraphic" stdDeviation="3" result="blur"/>
  <feFlood flood-color="#D4A017" flood-opacity="0.3" result="color"/>
  <feComposite in="color" in2="blur" operator="in" result="glow"/>
  <feMerge>
    <feMergeNode in="glow"/>
    <feMergeNode in="SourceGraphic"/>
  </feMerge>
</filter>

**Step 2: Add a glow overlay rect on dgx-03**

Add a `<rect>` matching the dgx-03 card dimensions with `filter="url(#amberGlow)"`, `fill="none"`, `stroke="#D4A017"`, `stroke-width="1"`, initially at `opacity: 0`, class `node3-glow`.

```css
@keyframes glowFadeIn {
  0%, 46.7% { opacity: 0; }
  66.7%, 86.7% { opacity: 1; }
  100% { opacity: 0; }
}
.node3-glow {
  animation: glowFadeIn 15s ease-in-out infinite;
}

That is a plan file from writing-plans, not a design spec.