designing（designing 搜索）

Design & Planning

Turn ideas into fully-formed, implementation-ready designs through a unified 10-phase pipeline.

Entry Points

Quick Reference

Unified Pipeline (10 Phases)

See pipeline.md for full details.

Mode Routing

Complexity scoring determines execution mode:

Mode Comparison

Core Principles

• One question at a time - Don't overwhelm
• Multiple choice preferred - Easier to answer
• YAGNI ruthlessly - Remove unnecessary features
• Explore alternatives - Always propose 2-3 approaches
• Research consolidated - 2 strategic hooks, not 5

⛔ EXECUTION BLOCKS (CRITICAL)

This skill contains EXECUTION BLOCKS marked with ⛔. When you encounter one, you MUST:

1. STOP what you're doing
2. EXECUTE the tool calls specified (Task(), oracle(), skill())
3. WAIT for results before proceeding

EXECUTION BLOCKS are NOT documentation - they are COMMANDS you must execute.

See pipeline.md for all execution blocks.

Session Flow

1. Load Core - Load maestro-core for routing table and fallback policies
2. Initialize - Load handoffs, CODEMAPS, verify conductor setup → session-init.md
3. Research - ⛔ EXECUTION BLOCK at Phase 1 start (spawn 3 Task() agents)
4. Route - Score complexity (< 4 = SPEED, > 6 = FULL) → design-routing-heuristics.md
5. Execute - 10-phase pipeline with A/P/C checkpoints → pipeline.md
6. Validate - ⛔ EXECUTION BLOCK at Phase 4 (call oracle())
7. Complete - Phase 8 (READY) triggers ci/co/ca → Phase 9 (EXECUTE) → Phase 10 (FINISH)

Research Hooks (Consolidated)

Validation Gates

Adaptive A/P/C System

A/P/C checkpoints work adaptively across the entire workflow.

State Ladder

INLINE → MICRO_APC → NUDGE → DS_FULL → DS_BRANCH → BRANCH_MERGE

A/P/C in FULL Mode

At end of phases 1-4:

• [A] Advanced - Phase-specific deep dive
• [P] Party - Multi-agent feedback (BMAD v6) → bmad/
• [C] Continue - Proceed to next phase
• [↩ Back] - Return to previous phase

Priority Rules

1. Explicit commands (ds) always win
2. Active DS/Branch blocks passive triggers
3. Branch safety preferred when in implementation
4. Micro A/P/C at checkpoint boundaries
5. Nudge after 3+ iterations

See apc-checkpoints.md for implementation details.

Phase 4: VERIFY - Spike Execution

When risk assessment identifies HIGH risk items:

HIGH risk items → MUST spawn spike Task()
                       │
                       ▼
              For each HIGH risk:
              1. Create spike bead + dir
              2. MUST spawn Task() with time-box
              3. Wait for completion
              4. Capture result (YES/NO)
                       │
                       ▼
              MUST call oracle() for 6-dimension audit
                       │
               ┌───────┴───────┐
               │               │
        All spikes YES   Any spike NO
               │               │
               ▼               ▼
           Continue       HALT - user decision

⚠️ MANDATORY: You MUST call oracle() at Phase 4 - see pipeline.md

Phase 6: VALIDATE - Oracle Beads Review

⚠️ MANDATORY: After bv validation, you MUST call oracle() to review beads completeness.

See pipeline.md

Phase 8: READY - Auto-Orchestration

Ready to execute. Found N tracks:
• Track A (BlueLake): 4 beads
• Track B (GreenCastle): 3 beads

[O] Orchestrate (spawn workers)
[S] Sequential (run ci manually)
[R] Ralph (autonomous loop - ca)

Default: [O] after 30s

Note: [R] is available when ralph.enabled == true in track metadata.json.

⚠️ MANDATORY: If user selects [O] and ≥2 tracks exist, you MUST spawn Task() for each track.

See pipeline.md

pl Entry Gate

⚠️ MANDATORY: Before running pl, detect input and bootstrap if needed:

pl triggered
    │
    ▼
Input detection (priority order):
    1. design.md exists? → ALIAS mode (skip discovery)
    2. PRD file exists?  → STANDALONE mode (parse PRD)
    3. User file attached? → STANDALONE mode
    4. No input?         → BOOTSTRAP mode (prompt → create track)

BOOTSTRAP creates: conductor/tracks/<id>/ with design.md + metadata.json

pl Compatibility

Anti-Patterns

• ❌ Jumping to solutions before understanding the problem
• ❌ Skipping verification at Phase 4 (VERIFY)
• ❌ Asking multiple questions at once
• ❌ Over-engineering simple features (use SPEED mode)
• ❌ Running pl after ds completes (no longer needed)

Next Steps (after Phase 8: READY)

See maestro-core for full routing table.

Dependencies

Auto-loads: maestro-core for routing and fallback policies.

Related

• conductor - Track creation and implementation
• tracking - Issue tracking after design
• orchestrator - Parallel execution in Phase 9 (EXECUTE)