Project Brainstorming

# Deferred Capture

After Phase 5 (Decision & Rationale), non-selected approaches
may still have merit for future projects or pivots.
This module defines when and how to capture them as deferred
items.

## When to Run

Run after `docs/project-brief.md` has been written and before
Phase 6 (Workflow Continuation) auto-invokes
`Skill(attune:project-specification)`.

## User Prompt

Count the non-selected approaches from Phase 3.
If there is at least one, display this prompt before
continuing:

```
N non-selected approaches have merit. Capture as deferred
items? [Y/n/select]
```

- **Y** (default): capture all non-selected approaches.
- **n**: skip capture entirely.
- **select**: display a numbered list of approaches and capture
  only the ones the user chooses.

Do not block workflow continuation waiting for a response
beyond 30 seconds.
If no response is received, treat it as **n** and continue.

## Capture Command

For each approach to be captured, run:

```bash
python3 scripts/deferred_capture.py \
  --title "Alternative: <approach-name>" \
  --source brainstorm \
  --context "<pros summary>. Not selected because: <user rationale>"
```

The `<pros summary>` should be a single sentence drawn from
the approach's Pros list in the project brief.
The `<user rationale>` should be the rejection reason recorded
in Phase 5 under "Rejected Approaches".

## Behavior Rules

- Only capture on explicit confirmation (Y or select).
  Default behavior when the user skips the prompt is no
  capture.
- If `scripts/deferred_capture.py` is not present, log a
  warning and skip capture rather than blocking continuation.
- After capture (or skipping), proceed immediately to Phase 6
  without further prompts.


---
name: spec-review-loop
description: Automated adversarial review of planning
  documents to catch TBD sections, vague requirements,
  and missing acceptance criteria before implementation.
parent_skill: attune:project-brainstorming
category: quality-gate
estimated_tokens: 350
---

# Spec Review Loop

## When This Applies

After the brainstorming skill produces a project brief
or specification document, before handing off to the
next phase.

## Mechanism

1. Dispatch a haiku-model subagent with the spec content
2. Subagent returns numbered issue list or "APPROVED"
3. Main agent applies fixes to the spec document
4. Re-dispatch subagent with updated content
5. Repeat until approved or 3 iterations reached
6. After 3 iterations without approval, surface remaining
   issues to human

## Review Prompt Template

Use this prompt when dispatching the review subagent:

~~~
You are reviewing a specification document for
completeness and implementability. Read the document
and check for:

1. TBD/TODO/placeholder sections that would block
   implementation
2. Missing acceptance criteria on any requirement
3. Vague requirements without measurable outcomes
   (e.g., "should handle errors appropriately")
4. Inconsistent terminology (same concept named
   differently in different sections)
5. Missing edge cases referenced but not specified
6. Missing dependencies between components

Respond with EXACTLY one of:

**APPROVED** - if no issues found

**ISSUES FOUND** - followed by a numbered list:
  [N]. [Section reference] [blocking/non-blocking]
       Issue: [description]
       Suggested fix: [specific recommendation]

Be thorough but fair. Flag real problems, not style
preferences.
~~~

## Dispatch Configuration

```yaml
subagent:
  model: haiku
  type: general-purpose
  max_iterations: 3
  escalation: surface_to_human
```

## Integration

The main agent (not the human) fixes issues between
iterations. The subagent only identifies problems; it
does not modify files. If the loop exhausts 3 iterations,
present remaining issues as a structured list and ask
the human for guidance.


---
name: project-brainstorming
description: