brachnha-insight/_bmad/bmb/workflows/agent/steps-c/step-06-activation.md

name, description, agentPlan, criticalActions, simpleBuild, expertBuild, moduleBuild, expertExample, advancedElicitationTask, partyModeWorkflow

name	description	agentPlan	criticalActions	simpleBuild	expertBuild	moduleBuild	expertExample	advancedElicitationTask	partyModeWorkflow
step-06-activation	Plan activation behavior and route to build	{bmb_creations_output_folder}/agent-plan-{agent_name}.md	../data/critical-actions.md	./step-07a-build-simple.md	./step-07b-build-expert.md	./step-07c-build-module.md	../data/reference/expert-examples/journal-keeper/journal-keeper.agent.yaml	{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml	{project-root}/_bmad/core/workflows/party-mode/workflow.md

STEP GOAL

Define activation behavior through critical_actions and route to the appropriate build step based on agent complexity.

MANDATORY EXECUTION RULES

1. MUST Load Reference Documents Before any discussion

   • Read criticalActions.md to understand activation patterns
   • Read agentPlan to access all accumulated metadata
   • These are non-negotiable prerequisites

2. MUST Determine Route Before Activation Discussion

   • Check module and hasSidecar from plan metadata
   • Determine destination build step FIRST
   • Inform user of routing decision

3. MUST Document Activation Decision

   • Either define critical_actions array explicitly
   • OR document deliberate omission with rationale
   • No middle ground - commit to one path

4. MUST Follow Routing Logic Exactly

   # Route determination based on module and hasSidecar
   # Module agents: any module value other than "stand-alone"
   module ≠ "stand-alone" → step-07c-build-module.md
   # Stand-alone agents: determined by hasSidecar
   module = "stand-alone" + hasSidecar: true → step-07b-build-expert.md
   module = "stand-alone" + hasSidecar: false → step-07a-build-simple.md
   

5. NEVER Skip Documentation

   • Every decision about activation must be recorded
   • Every routing choice must be justified
   • Plan file must reflect final state

EXECUTION PROTOCOLS

Protocol 1: Reference Loading

Execute BEFORE engaging user:

1. Load criticalActions.md
2. Load agentPlan-{agent_name}.md
3. Extract routing metadata:
   • hasSidecar (boolean)
   • module (string)
   • agentType (if defined)
4. Determine destination build step

Protocol 2: Routing Disclosure

Inform user immediately of determined route:

"Based on your agent configuration:
- hasSidecar: {hasSidecar}
- module: {module}

→ Routing to: {destinationStep}

Now let's plan your activation behavior..."

Protocol 3: Activation Planning

Guide user through decision:

1. Explain critical_actions Purpose

   • What they are: autonomous triggers the agent can execute
   • When they're useful: proactive capabilities, workflows, utilities
   • When they're unnecessary: simple assistants, pure responders

2. Discuss Agent's Activation Needs

   • Does this agent need to run independently?
   • Should it initiate actions without prompts?
   • What workflows or capabilities should it trigger?

3. Decision Point

   • Define specific critical_actions if needed
   • OR explicitly opt-out with rationale

Protocol 4: Documentation

Update agentPlan with activation metadata:

# Add to agent metadata
activation:
  hasCriticalActions: true/false
  rationale: "Explanation of why or why not"
  criticalActions: []  # Only if hasCriticalActions: true
routing:
  destinationBuild: "step-06-{X}.md"
  hasSidecar: {boolean}
  module: "{module}"

CONTEXT BOUNDARIES

In Scope

• Planning activation behavior for the agent
• Defining critical_actions array
• Routing to appropriate build step
• Documenting activation decisions

Out of Scope

• Writing actual activation code (build step)
• Designing sidecar workflows (build step)
• Changing core agent metadata (locked after step 04)
• Implementing commands (build step)

Routing Boundaries

• Simple agents: No sidecar, straightforward activation
• Expert agents: Sidecar + stand-alone module
• Module agents: Sidecar + parent module integration

MANDATORY SEQUENCE

CRITICAL: Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.

1. Load Reference Documents

# Read these files FIRST
cat {criticalActions}
cat {agentPlan}

2. Discuss Activation Needs

Ask user:

• "Should your agent be able to take autonomous actions?"
• "Are there specific workflows it should trigger?"
• "Should it run as a background process or scheduled task?"
• "Or will it primarily respond to direct prompts?"

3. Define critical_actions OR Explicitly Omit

If defining:

• Reference criticalActions.md patterns
• List 3-7 specific actions
• Each action should be clear and scoped
• Document rationale for each

If omitting:

• State clearly: "This agent will not have critical_actions"
• Explain why: "This agent is a responsive assistant that operates under direct user guidance"
• Document the rationale

4. Route to Build Step

Determine destination:

# Check plan metadata
hasSidecar: {value from step 04}
module: "{value from step 04}"

# Route logic
if hasSidecar == false:
  destination = simpleBuild
elif hasSidecar == true and module == "stand-alone":
  destination = expertBuild
else:  # hasSidecar == true and module != "stand-alone"
  destination = moduleBuild

5. Document to Plan

Update agentPlan with:

---
activation:
  hasCriticalActions: true
  rationale: "Agent needs to autonomously trigger workflows for task automation"
  criticalActions:
    - name: "start-workflow"
      description: "Initiate a predefined workflow for task execution"
    - name: "schedule-task"
      description: "Schedule tasks for future execution"
    - name: "sync-data"
      description: "Synchronize data with external systems"

routing:
  destinationBuild: "step-06-build-expert.md"
  hasSidecar: true
  module: "stand-alone"
  rationale: "Agent requires sidecar workflows for autonomous operation"
---

6. Present MENU OPTIONS

Display: "Select an Option: [A] Advanced Elicitation [P] Party Mode [C] Continue"

Menu Handling Logic:

• IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
• IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
• IF C: Save content to {agentPlan}, update frontmatter, determine appropriate build step based on hasSidecar and module values, then only then load, read entire file, then execute {simpleBuild} or {expertBuild} or {moduleBuild} as determined
• IF Any other comments or queries: help user respond then Redisplay Menu Options

EXECUTION RULES:

• ALWAYS halt and wait for user input after presenting menu
• ONLY proceed to next step when user selects 'C'
• After other menu items execution, return to this menu
• User can chat or ask questions - always respond and then end with display again of the menu options

CRITICAL STEP COMPLETION NOTE

This is the ROUTING HUB of agent creation. ONLY WHEN [C continue option] is selected and [routing decision determined with activation needs documented], will you then determine the appropriate build step based on hasSidecar/module values and load and read fully that build step file to execute.

Routing logic:

• hasSidecar: false → step-06-build-simple.md
• hasSidecar: true + module: "stand-alone" → step-06-build-expert.md
• hasSidecar: true + module: ≠ "stand-alone" → step-06-build-module.md

You cannot proceed to build without completing routing.

---

SUCCESS METRICS

✅ COMPLETION CRITERIA:

• criticalActions.md loaded and understood
• agentPlan loaded with all prior metadata
• Routing decision determined and communicated
• Activation needs discussed with user
• critical_actions defined OR explicitly omitted with rationale
• Plan updated with activation and routing metadata
• User confirms routing to appropriate build step

✅ SUCCESS INDICATORS:

• Clear activation decision documented
• Route to build step is unambiguous
• User understands why they're going to {simple|expert|module} build
• Plan file reflects complete activation configuration

❌ FAILURE MODES:

• Attempting to define critical_actions without reading reference
• Routing decision not documented in plan
• User doesn't understand which build step comes next
• Ambiguous activation configuration (neither defined nor omitted)
• Skipping routing discussion entirely

⚠️ RECOVERY PATHS: If activation planning goes wrong:

1. Can't decide on activation?

   • Default: Omit critical_actions
   • Route to simpleBuild
   • Can add later via edit-agent workflow

2. Uncertain about routing?

   • Check hasSidecar value
   • Check module value
   • Apply routing logic strictly

3. User wants to change route?

   • Adjust hasSidecar or module values
   • Re-run routing logic
   • Update plan accordingly