Name: iterate
Author: asabocinski

Prompt file imported from asabocinski/bravo-edd (.codex/prompts/iterate.md). Copyright stays with the author.

Iterate Command

Update any phase document when requirements or design changes (Cross-Phase)

Usage

/iterate <file> "<change-description>"

Examples

/iterate BRAINSTORM_SEARCH_API.md "Consider ElasticSearch instead of PostgreSQL full-text search"
/iterate DEFINE_SEARCH_API.md "Add support for fuzzy matching, not just exact search"
/iterate DESIGN_SEARCH_API.md "Services need to be self-contained, no shared common/"
/iterate .codex/sdd/features/DEFINE_AUTH.md "Change from JWT to session-based auth"

Overview

The /iterate command works with document phases of the AgentSpec workflow:

Phase 0: /brainstorm → BRAINSTORM_{FEATURE}.md ← /iterate can update
Phase 1: /define     → DEFINE_{FEATURE}.md     ← /iterate can update
Phase 2: /design     → DESIGN_{FEATURE}.md     ← /iterate can update
Phase 3: /build      → (code)                  ← Update DESIGN, then /build
Phase 4: /ship       → (archive)               ← N/A

Use /iterate when you discover something that needs to change mid-stream.

Important: To change code during Phase 3, update the DESIGN document first. The cascade to code triggers a rebuild via /build. This ensures traceability.

What This Command Does

Detect Phase - Identify which phase document is being updated
Analyze Impact - Determine downstream effects
Update Document - Apply changes with version tracking
Cascade - Propagate changes to downstream documents if needed

Process

Step 1: Load Target Document

Read(<target-file>)

# Identify document type:
# - BRAINSTORM_*.md → Phase 0
# - DEFINE_*.md → Phase 1
# - DESIGN_*.md → Phase 2

Step 2: Analyze Change

Determine the change type:

Change Type	Example	Impact
Additive	"Also support PDF"	Low - adds to existing
Modifying	"Change from X to Y"	Medium - updates existing
Removing	"Remove feature Z"	Medium - simplifies
Architectural	"Use different pattern"	High - may require redesign

Step 3: Apply Changes

Update the document with:

Change Applied - The actual modification
Version Bump - Increment version in revision history
Change Note - What changed and why

Step 4: Assess Cascade Need

Source	Cascades To
DEFINE change	May need DESIGN update
DESIGN change	May need code update

Determine if downstream documents need updates based on cascade rules.

Step 5: Execute Cascade (if needed)

If cascade needed, prompt user:

"This DEFINE change affects the DESIGN. Options:
(a) Update DESIGN automatically to match
(b) Just update DEFINE, I'll handle DESIGN manually
(c) Show me what would change first"

Step 6: Save Updates

Write(<target-file>)
# If cascade:
Write(<downstream-document>)

Output

Artifact	Location
Updated Document	Same location as input
Cascade Updates	Downstream documents (if applicable)

Cascade Rules

DEFINE Changes → DESIGN Impact

DEFINE Change	DESIGN Impact
New requirement	May need new component
Changed success criteria	May need different approach
Scope expansion	Needs new sections
Scope reduction	Can simplify
New constraint	Must be accommodated

DESIGN Changes → Code Impact

DESIGN Change	Code Impact
New file in manifest	Create file
Removed file	Delete file
Changed pattern	Update affected files
New decision	May need refactor
Architecture change	Significant updates needed

Version Tracking

Each document maintains revision history:

## Revision History

| Version | Date | Author | Changes |
|---------|------|--------|---------|
| 1.0 | 2026-01-25 | define-agent | Initial version |
| 1.1 | 2026-01-25 | iterate-agent | Added PDF support per user request |

Tips

Iterate Early - Catch changes before coding starts
Be Specific - "Add X" is better than "make it better"
Check Cascade - Changes ripple downstream
Keep History - Version tracking shows evolution
Don't Fight It - Requirements change, that's normal

When to Use /iterate vs Starting Over

Situation	Action
< 30% change	`/iterate`
Add/modify features	`/iterate`
Change constraints	`/iterate`
> 50% different	New `/define`
Different problem entirely	New `/define`
Different target users	New `/define`

References

Agent: .codex/skills/iterate-agent.md
Contracts: .codex/sdd/architecture/WORKFLOW_CONTRACTS.yaml

Install iterate and it becomes one more candidate the router can pick - when it fits.

A listing is a routing target with a manifest: what it does, which domains it covers, what it costs and who publishes it. Once installed it sits beside your own models and tools, is scored like any other candidate for each request, and shows up in the trace when it wins. Ratings come from workspaces that installed it, one per account.

# Iterate Command > Update any phase document when requirements or design changes (Cross-Phase) ## Usage ```bash /iterate <file> "<change-description>" ``` ## Examples ```bash /iterate BRAINSTORM_SEARCH_API.md "Consider ElasticSearch instead of PostgreSQL full-text search" /iterate DEFINE_SEARCH_API.md "Add support for fuzzy matching, not just exact search" /iterate DESIGN_SEARCH_API.md "Services need to be self-contained, no shared common/" /iterate .codex/sdd/features/DEFINE_AUTH.md "Change from JWT to session-based auth" ``` --- ## Overview The `/iterate` command works with **document phases** of the AgentSpec workflow: ```text Phase 0: /brainstorm → BRAINSTORM_{FEATURE}.md ← /iterate can update Phase 1: /define → DEFINE_{FEATURE}.md ← /iterate can update Phase 2: /design → DESIGN_{FEATURE}.md ← /iterate can update Phase 3: /build → (code) ← Update DESIGN, then /build Phase 4: /ship → (archive) ← N/A ``` Use `/iterate` when you discover something that needs to change mid-stream. **Important:** To change code during Phase 3, update the DESIGN document first. The cascade to code triggers a rebuild via `/build`. This ensures traceability. --- ## What This Command Does 1. **Detect Phase** - Identify which phase document is being updated 2. **Analyze Impact** - Determine downstream effects 3. **Update Document** - Apply changes with version tracking 4. **Cascade** - Propagate changes to downstream documents if needed --- ## Process ### Step 1: Load Target Document ```markdown Read(<target-file>) # Identify document type: # - BRAINSTORM_*.md → Phase 0 # - DEFINE_*.md → Phase 1 # - DESIGN_*.md → Phase 2 ``` ### Step 2: Analyze Change Determine the change type: | Change Type | Example | Impact | |-------------|---------|--------| | **Additive** | "Also support PDF" | Low - adds to existing | | **Modifying** | "Change from X to Y" | Medium - updates existing | | **Removing** | "Remove feature Z" | Medium - simplifies | | **Architectural** | "Use different pattern" | High - may require redesign | ### Step 3: Apply Changes Update the document with: 1. **Change Applied** - The actual modification 2. **Version Bump** - Increment version in revision history 3. **Change Note** - What changed and why ### Step 4: Assess Cascade Need | Source | Cascades To | |--------|-------------| | DEFINE change | May need DESIGN update | | DESIGN change | May need code update | Determine if downstream documents need updates based on cascade rules. ### Step 5: Execute Cascade (if needed) If cascade needed, prompt user: ```markdown "This DEFINE change affects the DESIGN. Options: (a) Update DESIGN automatically to match (b) Just update DEFINE, I'll handle DESIGN manually (c) Show me what would change first" ``` ### Step 6: Save Updates ```markdown Write(<target-file>) # If cascade: Write(<downstream-document>) ``` --- ## Output | Artifact | Location | |----------|----------| | **Updated Document** | Same location as input | | **Cascade Updates** | Downstream documents (if applicable) | --- ## Cascade Rules ### DEFINE Changes → DESIGN Impact | DEFINE Change | DESIGN Impact | |---------------|---------------| | New requirement | May need new component | | Changed success criteria | May need different approach | | Scope expansion | Needs new sections | | Scope reduction | Can simplify | | New constraint | Must be accommodated | ### DESIGN Changes → Code Impact | DESIGN Change | Code Impact | |---------------|-------------| | New file in manifest | Create file | | Removed file | Delete file | | Changed pattern | Update affected files | | New decision | May need refactor | | Architecture change | Significant updates needed | --- ## Version Tracking Each document maintains revision history: ```markdown ## Revision History | Version | Date | Author | Changes | |---------|------|--------|---------| | 1.0 | 2026-01-25 | define-agent | Initial version | | 1.1 | 2026-01-25 | iterate-agent | Added PDF support per user request | ``` --- ## Tips 1. **Iterate Early** - Catch changes before coding starts 2. **Be Specific** - "Add X" is better than "make it better" 3. **Check Cascade** - Changes ripple downstream 4. **Keep History** - Version tracking shows evolution 5. **Don't Fight It** - Requirements change, that's normal --- ## When to Use /iterate vs Starting Over | Situation | Action | |-----------|--------| | < 30% change | `/iterate` | | Add/modify features | `/iterate` | | Change constraints | `/iterate` | | > 50% different | New `/define` | | Different problem entirely | New `/define` | | Different target users | New `/define` | --- ## References - Agent: `.codex/skills/iterate-agent.md` - Contracts: `.codex/sdd/architecture/WORKFLOW_CONTRACTS.yaml`

{ "prompt": "# Iterate Command\n\n> Update any phase document when requirements or design changes (Cross-Phase)\n\n## Usage\n\n```bash\n/iterate <file> \"<change-description>\"\n```\n\n## Examples\n\n```bash\n/iterate BRAINSTORM_SEARCH_API.md \"Consider ElasticSearch instead of PostgreSQL full-text search\"\n/iterate DEFINE_SEARCH_API.md \"Add support for fuzzy matching, not just exact search\"\n/iterate DESIGN_SEARCH_API.md \"Services need to be self-contained, no shared common/\"\n/iterate .codex/sdd/features/DEFINE_AUTH.md \"Change from JWT to session-based auth\"\n```\n\n---\n\n## Overview\n\nThe `/iterate` command works with **document phases** of the AgentSpec workflow:\n\n```text\nPhase 0: /brainstorm → BRAINSTORM_{FEATURE}.md ← /iterate can update\nPhase 1: /define → DEFINE_{FEATURE}.md ← /iterate can update\nPhase 2: /design → DESIGN_{FEATURE}.md ← /iterate can update\nPhase 3: /build → (code) ← Update DESIGN, then /build\nPhase 4: /ship → (archive) ← N/A\n```\n\nUse `/iterate` when you discover something that needs to change mid-stream.\n\n**Important:** To change code during Phase 3, update the DESIGN document first. The cascade to code triggers a rebuild via `/build`. This ensures traceability.\n\n---\n\n## What This Command Does\n\n1. **Detect Phase** - Identify which phase document is being updated\n2. **Analyze Impact** - Determine downstream effects\n3. **Update Document** - Apply changes with version tracking\n4. **Cascade** - Propagate changes to downstream documents if needed\n\n---\n\n## Process\n\n### Step 1: Load Target Document\n\n```markdown\nRead(<target-file>)\n\n# Identify document type:\n# - BRAINSTORM_*.md → Phase 0\n# - DEFINE_*.md → Phase 1\n# - DESIGN_*.md → Phase 2\n```\n\n### Step 2: Analyze Change\n\nDetermine the change type:\n\n| Change Type | Example | Impact |\n|-------------|---------|--------|\n| **Additive** | \"Also support PDF\" | Low - adds to existing |\n| **Modifying** | \"Change from X to Y\" | Medium - updates existing |\n| **Removing** | \"Remove feature Z\" | Medium - simplifies |\n| **Architectural** | \"Use different pattern\" | High - may require redesign |\n\n### Step 3: Apply Changes\n\nUpdate the document with:\n\n1. **Change Applied** - The actual modification\n2. **Version Bump** - Increment version in revision history\n3. **Change Note** - What changed and why\n\n### Step 4: Assess Cascade Need\n\n| Source | Cascades To |\n|--------|-------------|\n| DEFINE change | May need DESIGN update |\n| DESIGN change | May need code update |\n\nDetermine if downstream documents need updates based on cascade rules.\n\n### Step 5: Execute Cascade (if needed)\n\nIf cascade needed, prompt user:\n\n```markdown\n\"This DEFINE change affects the DESIGN. Options:\n(a) Update DESIGN automatically to match\n(b) Just update DEFINE, I'll handle DESIGN manually\n(c) Show me what would change first\"\n```\n\n### Step 6: Save Updates\n\n```markdown\nWrite(<target-file>)\n# If cascade:\nWrite(<downstream-document>)\n```\n\n---\n\n## Output\n\n| Artifact | Location |\n|----------|----------|\n| **Updated Document** | Same location as input |\n| **Cascade Updates** | Downstream documents (if applicable) |\n\n---\n\n## Cascade Rules\n\n### DEFINE Changes → DESIGN Impact\n\n| DEFINE Change | DESIGN Impact |\n|---------------|---------------|\n| New requirement | May need new component |\n| Changed success criteria | May need different approach |\n| Scope expansion | Needs new sections |\n| Scope reduction | Can simplify |\n| New constraint | Must be accommodated |\n\n### DESIGN Changes → Code Impact\n\n| DESIGN Change | Code Impact |\n|---------------|-------------|\n| New file in manifest | Create file |\n| Removed file | Delete file |\n| Changed pattern | Update affected files |\n| New decision | May need refactor |\n| Architecture change | Significant updates needed |\n\n---\n\n## Version Tracking\n\nEach document maintains revision history:\n\n```markdown\n## Revision History\n\n| Version | Date | Author | Changes |\n|---------|------|--------|---------|\n| 1.0 | 2026-01-25 | define-agent | Initial version |\n| 1.1 | 2026-01-25 | iterate-agent | Added PDF support per user request |\n```\n\n---\n\n## Tips\n\n1. **Iterate Early** - Catch changes before coding starts\n2. **Be Specific** - \"Add X\" is better than \"make it better\"\n3. **Check Cascade** - Changes ripple downstream\n4. **Keep History** - Version tracking shows evolution\n5. **Don't Fight It** - Requirements change, that's normal\n\n---\n\n## When to Use /iterate vs Starting Over\n\n| Situation | Action |\n|-----------|--------|\n| < 30% change | `/iterate` |\n| Add/modify features | `/iterate` |\n| Change constraints | `/iterate` |\n| > 50% different | New `/define` |\n| Different problem entirely | New `/define` |\n| Different target users | New `/define` |\n\n---\n\n## References\n\n- Agent: `.codex/skills/iterate-agent.md`\n- Contracts: `.codex/sdd/architecture/WORKFLOW_CONTRACTS.yaml`", "variables": [], "notes": "Update any phase document when requirements or design change (Cross-Phase)", "metadata": { "source": { "provider": "github-codex-prompts", "repository": "https://github.com/asabocinski/bravo-edd", "path": ".codex/prompts/iterate.md", "ref": "ae4c539580470e782ac67d2dc4a4eabe9fc68336", "url": "https://github.com/asabocinski/bravo-edd/blob/ae4c539580470e782ac67d2dc4a4eabe9fc68336/.codex/prompts/iterate.md", "key": "asabocinski/bravo-edd/.codex/prompts/iterate.md" } } }

iterate

About