Skip to content
maenifold
GitHub

Agentic SLC Sprint (Wave Orchestration)

17 steps

Multi-agent sprint execution using synchronized waves with RTM validation and git-tracked delivery

Triggers

agentic slc sprintwave orchestrationmulti agent sprintslc sprintagent swarmsynchronized sprintcascade validationagent orchestrationsprint executionteam sprint

Steps

  1. 1.

    🚀 Sprint Setup + Git Branch

    Initialize sprint with PM role, git branch, and RTM foundation.

    📋 PM RESPONSIBILITIES:

    1. Adopt PM role and blue hat for orchestration
    2. Read TODO.md for priorities
    3. Select 3-5 items for sprint scope
    4. Create sequential thinking session: sprint-[YYYYMMDD]-planning
    5. Document goals and constraints
    6. Initialize RTM.md with template:

    ⚠️ You are the orchestrator - you create branches, dispatch agents, and control integration.

    Tools:Bash*Read*Write*
    Effort:low
    Guardrails
    • pm_only: Only PM creates branches and RTM
    • rtm_template: Must use exact RTM template format
    • git_discipline: Must track baseline and create clean branch
  2. 2.

    🌊 Discovery Wave

    🚫 BLOCKING: Dispatch ALL agents for collective analysis

    ⚠️ CRITICAL: ALL TASKS BELOW MUST BE IN ONE MESSAGE FOR PARALLEL EXECUTION!

    ❌ WRONG: Dispatching agents in separate messages (sequential blocking) ✅ RIGHT: All Task tool calls in ONE message (parallel execution)

    🎯 AGENTS MUST:

    • Use serana for ALL C# analysis (not grep/search)
    • Work in PM's branch only
    • Report findings linked to potential RTM items
    • NO commits during discovery

    Agents collaborate in shared sequential thinking session. ⏱️ Block duration: 30-45 minutes

    Tools:Task*serana*
    Effort:medium
    Guardrails
    • parallel_execution: MUST dispatch all agents in ONE message, never sequential
    • serana_only: Agents must use serana, not grep/search for C# analysis
    • no_commits: No commits during discovery phase
    • shared_session: All agents work in same sequential thinking session
  3. 3.

    📝 Create Specifications

    Read discovery and create detailed specifications for implementation.

    🧠 ENHANCED THINKING REQUIRED

    📚 FIRST: Check memory://patterns/sprint-retrospectives/ for past learnings

    ⚠️ PRE-FLIGHT VERIFICATION (MANDATORY - USE serana NOT GREP):

    1. Read sequential thinking session: sprint-[YYYYMMDD]-discovery
    2. Create sequential thinking session: sprint-[YYYYMMDD]-specs
    3. Create detailed specifications document:
    1. Specifications MUST include:
      • Clear functional requirements
      • Non-functional constraints
      • File paths verified with serana
      • Acceptance criteria

    ❌ Vague specifications = INVALID ✅ Clear, testable specifications = Proceed to RTM creation

    Enhanced Thinking
    Tools:SequentialThinking*SearchMemories*serana*Read*Write*Bash*
    Effort:high
    Guardrails
    • specification_clarity: All requirements must be clear and testable
    • serana_verification: File paths MUST be verified with serana, not grep
    • no_rtm_creation: This step creates specifications only, not RTM
  4. 4.

    📋 Create RTM from Specifications

    Transform specifications into atomic RTM functionality units.

    🧠 ENHANCED THINKING REQUIRED

    📚 FIRST: Read specifications document from previous step

    1. Read specifications document
    2. Create sequential thinking session: sprint-[YYYYMMDD]-rtm
    3. Transform each specification into atomic RTM items:
    1. COMMIT RTM (PM ONLY):
    1. Verify RTM traceability:
      • Each RTM item traces to specification
      • Each RTM item is atomic (one behavior)
      • Each RTM item is testable

    ❌ Non-atomic RTM items = INVALID ✅ Every RTM item is atomic functionality = Proceed

    Enhanced Thinking
    Tools:SequentialThinking*Read*Write*Bash*
    Effort:high
    Guardrails
    • atomic_requirement: Every RTM item MUST be atomic functionality
    • specification_traceability: Every RTM item MUST trace to specification
    • git_commit_discipline: RTM must be committed before proceeding
  5. 5.

    📋 RTM User Confirmation

    Present finalized RTM to user for explicit approval.

    🛑 CRITICAL CHECKPOINT: User must approve RTM before ANY implementation

    1. Present complete RTM to user:

      • List each MUST HAVE requirement clearly
      • List each MUST NOT HAVE constraint
      • Show escape hatches
      • Include file paths and line numbers

    2. Ask explicitly: "Here is the complete RTM for this sprint: [Show RTM] Is this correct? Should I proceed with implementation?"

    3. User responses:

      • YES/APPROVED → Continue to validation wave
      • NO/CHANGES NEEDED → Return to specifications step
      • ABORT → Stop sprint immediately

    4. Check for existing solutions:

      • "Could any of these requirements use existing features?"
      • "Could configuration solve any of these?"
      • "Is building new code the right approach?"

    ⚠️ NO IMPLEMENTATION WITHOUT EXPLICIT APPROVAL

    This checkpoint prevents building the wrong thing.

    Tools:Read*
    Effort:low
    Guardrails
    • explicit_approval: Must have clear YES/APPROVED from user
    • existing_features_check: Must ask about using existing features or configuration
    • no_assumptions: Do not proceed without explicit approval
  6. 6.

    🌊 Validation Wave + RTM Check

    🚫 BLOCKING: Agents validate RTM feasibility

    ⚠️ CRITICAL: DISPATCH BOTH AGENTS IN ONE MESSAGE!

    🚨 ESCAPE HATCH: If ANY RTM item unclear → STOP SPRINT

    Incorporate feedback or abort sprint. ⏱️ Block duration: 20-30 minutes

    Tools:Task*serana*
    Effort:medium
    Guardrails
    • parallel_validation: MUST dispatch both agents in ONE message
    • escape_hatch: STOP sprint if ANY RTM item unclear
    • binary_decision: Either all RTM validated or sprint aborted
  7. 7.

    📋 Task Decomposition & Agent Planning

    Break down RTM items into specific tasks and plan agent assignments.

    🧠 ENHANCED THINKING REQUIRED

    📚 FIRST: Read RTM.md to understand atomic functionality requirements

    1. For each RTM item, decompose into specific implementation tasks
    2. Plan agent assignments and coordination strategy
    3. Define task dependencies and execution order
    4. Plan wave structure (how many agents per wave, parallel execution)
    5. Document complete task breakdown and agent dispatch strategy

    Create sequential thinking session: sprint-[YYYYMMDD]-task-planning

    🎯 COMPLETION CRITERIA:

    • Each RTM item broken into specific tasks
    • Agent assignments planned (Agent-A does Task-X, Agent-B does Task-Y)
    • Wave structure defined (Discovery: 6 agents, Implementation: N agents per RTM)
    • Dispatch strategy documented with exact agent count and roles
    • Parallel execution plan ready

    ⚠️ ESCAPE HATCH: If task breakdown unclear → STOP and clarify RTM

    ⏱️ Block duration: 20-30 minutes

    Enhanced Thinking
    Tools:SequentialThinking*Read*Write*
    Effort:medium
    Guardrails
    • planning_only: NO agent dispatch in this step - planning only
    • task_decomposition: Must break each RTM into specific implementation tasks
    • agent_strategy: Must plan exact agent count and role assignments
  8. 8.

    🌊 Implementation Dispatch

    Execute agent dispatch based on task planning strategy.

    ⚠️ CRITICAL: DISPATCH ALL AGENTS IN ONE MESSAGE!

    📋 DYNAMIC AGENT DISPATCH:

    1. Read task breakdown and agent assignments from previous step
    2. Dispatch agents according to documented plan
    3. Execute planned wave structure with exact agent count
    4. All agents dispatch in SINGLE message for parallel execution

    ⚠️ AGENT RULES:

    • Follow exact task assignments from planning
    • Commit after EACH RTM item
    • Include RTM-XXX ID in commit message
    • If git diff > RTM scope → STOP

    ⏱️ Block duration: 1-3 hours

    Tools:Task*Read*
    Effort:low
    Guardrails
    • parallel_execution: ALL agents must be dispatched in ONE message
    • rtm_boundary_enforcement: Agents MUST only implement their assigned RTM item
    • git_commit_discipline: One commit per RTM item with RTM-XXX ID in message
    • no_scope_creep: STOP if any agent attempts to exceed RTM scope
  9. 9.

    � Red Team Verification

    Dispatch red team agents to assume implementation is half-baked and find all issues.

    🚫 BLOCKING: Red team assumes EVERYTHING is broken

    ⚠️ CRITICAL: DISPATCH RED TEAM AGENTS IN ONE MESSAGE!

    🔴 RED TEAM MINDSET: Assume implementation is half-baked, incomplete, and wrong

    🎯 RED TEAM RULES:

    • Assume implementation is 50% complete at best
    • Look for what's broken, not what works
    • Find edge cases and failure modes
    • Question every implementation choice
    • Assume agents cut corners

    📊 RED TEAM FINDINGS:

    ⏱️ Block duration: 20-30 minutes

    Tools:Task*Bash*
    Effort:medium
    Guardrails
    • red_team_mindset: Agents MUST assume implementation is broken and half-baked
    • comprehensive_audit: Find ALL issues, not just obvious ones
    • no_gentle_feedback: Red team provides harsh, thorough criticism
  10. 10.

    🔧 Remediation Wave

    Fix all issues found by red team verification.

    🚫 BLOCKING: Address EVERY red team finding

    ⚠️ CRITICAL: DISPATCH REMEDIATION AGENTS IN ONE MESSAGE!

    📋 REMEDIATION STRATEGY:

    1. Read red team findings from previous step
    2. Categorize issues by severity (Critical → Minor)
    3. Dispatch agents to fix each category of issues
    4. All remediation agents dispatch in parallel

    ⚠️ REMEDIATION RULES:

    • Address EVERY red team finding
    • One commit per fix with clear description
    • No new features - only fix reported issues
    • Verify each fix resolves the specific concern

    📊 REMEDIATION REPORT:

    ⏱️ Block duration: 45-90 minutes

    Tools:Task*Read*
    Effort:medium
    Guardrails
    • complete_remediation: MUST address EVERY red team finding
    • no_new_features: Only fix reported issues, no scope expansion
    • commit_discipline: One commit per fix with clear RTM reference
  11. 11.

    ✅ Implementation Verification

    Verify all RTM items implemented and committed.

    🔍 VERIFICATION CHECKLIST:

    📊 VERIFICATION SCORECARD:

    ❌ ANY missing implementation = FAIL ✅ ALL verified = Proceed to test wave

    ⏱️ Block duration: 10-15 minutes

    Tools:Bash*LS*
    Effort:low
    Guardrails
    • verification_only: NO creation or modification - verification only
    • binary_check: Either ALL RTM items implemented or step fails
    • git_discipline: Must verify clean git history with RTM-XXX commits
  12. 12.

    🌊 Test Wave

    🚫 BLOCKING: Test creation and execution

    Read audit first! If RTM violated, skip to cleanup.

    ⚠️ CRITICAL: DISPATCH ALL IN ONE MESSAGE!

    ⏱️ Block duration: 45-60 minutes

    Tools:Task*Read*
    Effort:medium
    Guardrails
    • parallel_execution: ALL three agents must be dispatched in ONE message
    • rtm_specific_testing: Tests must verify RTM item behavior exactly
    • git_verification: Must verify one commit per RTM item
  13. 13.

    🔍 RTM Verification Gate

    PM verification of RTM compliance.

    📊 RTM Scorecard:

    ❌ ANY violation = Sprint fails ✅ ALL checked = Proceed to cleanup

    Tools:Bash*
    Effort:low
    Guardrails
    • binary_decision: ANY violation = Sprint fails, ALL checked = Proceed
    • rtm_scorecard: Must complete full RTM scorecard verification
    • pm_only: Only PM makes integration decision
  14. 14.

    🌊 Cleanup Wave

    🚫 BLOCKING: Final cleanup with RTM boundary

    ⚠️ CRITICAL: BOTH AGENTS IN ONE MESSAGE!

    ⏱️ Block duration: 30-45 minutes

    Tools:Task*
    Effort:medium
    Guardrails
    • rtm_boundary: Cleanup ONLY RTM-modified files, no scope expansion
    • parallel_execution: BOTH agents must be dispatched in ONE message
    • final_validation: Must confirm build and test success
  15. 15.

    ⚖️ RTM Justification Review

    Justify every line of code - why not use existing features or configuration?

    🔍 CRITICAL: Every change must justify its existence

    1. For EACH file changed:

      • Could this use an existing feature?
      • Could this be solved with configuration?
      • Is this the simplest solution?
      • Why build instead of configure?

    2. Check for alternatives:

      • Search: "Does [framework/library] already have this?"
      • Review: Documentation for existing solutions
      • Question: "Why custom code instead of library?"

    3. Document justifications:

    1. Red flags to catch:
      • "I built this to be helpful" → REMOVE
      • "This might be useful later" → REMOVE
      • "I improved the existing code" → REMOVE if not in RTM

    ❌ Unjustified code = Must be removed ✅ All code justified = Proceed to sprint review

    This prevents another AIShell.Ma.Agent disaster.

    Enhanced Thinking
    Tools:SequentialThinking*WebSearchRead*
    Effort:high
    Guardrails
    • zero_tolerance_extras: ANY code not justified must be removed
    • existing_first: Must check for existing solutions before accepting custom
    • config_over_code: Configuration solutions preferred over new code
  16. 16.

    ✅ Sprint Review + Integration Decision

    PM DECISION POINT: Integrate or reject?

    Read in order:

    1. RTM Scorecard - All items complete?
    2. audit-sprint-[YYYYMMDD] - RTM compliance?
    3. sprint-[YYYYMMDD]-test-results - All tests pass?
    4. sprint-[YYYYMMDD]-final - Build succeeds?
    5. Git verification:

    🎯 INTEGRATION DECISION (PM ONLY):

    No partial credit - sprint delivers RTM or fails.

    Tools:Bash*Read*
    Effort:low
    Guardrails
    • pm_only_decision: Only PM makes integration decision
    • binary_outcome: No partial credit - sprint delivers RTM or fails
    • evidence_based: Decision must be based on actual reports, not assumptions
  17. 17.

    📊 Sprint Retrospective + RTM Analysis

    Extract patterns and RTM effectiveness.

    🧠 ENHANCED THINKING REQUIRED

    Create sequential thinking session: sprint-[YYYYMMDD]-retrospective

    1. RTM Analysis:

      • Which requirements were clear?
      • What was added beyond RTM?
      • Which escape hatches triggered?
      • Git history clean?

    2. Process Analysis:

      • Did agents respect RTM boundaries?
      • Were specs linked to RTM items?
      • Did git tracking help?

    3. Common Violations:

      • "Helpful" additions beyond scope
      • Missing git commits
      • RTM items too vague

    📝 MANDATORY: Save to memory://patterns/sprint-retrospectives/ Include:

    • RTM template that worked
    • Git workflow issues
    • Agent boundary violations
    • Escape hatch triggers

    Example entries:

    • ❌ "Agent added backward compatibility not in RTM-X01"
    • ✅ "RTM-001 clearly specified lines 75-121 for removal"
    • ⚠️ "Escape hatch triggered: ambiguous 'use built-in' requirement"

    This compounds sprint over sprint!

    Enhanced Thinking
    Tools:SequentialThinking*Write*WriteMemory*SearchMemories
    Effort:high
    Guardrails
    • knowledge_preservation: Must save specific actionable patterns, not generic observations
    • pattern_specificity: Include exact examples like RTM-001 line specifications
    • compounding_effect: This knowledge compounds sprint over sprint - critical for improvement