Behavioral Modes

---
name: behavioral-modes
description: "Use when AI operational modes (brainstorm, implement, debug, review, teach, ship, orchestrate). Use to adapt behavior based on task type."
version: 5.0.0
last-updated: 2026-09-13
skills:
  - fabel-protocol
  - agentic-patterns
  - thinking-protocol
tools: Read, Grep, Glob, Bash, Edit, Write
scripts-binding:
  - .agent/scripts/checklist.js
  - .agent/scripts/verify_all.js
  - .agent/scripts/lint_runner.js
---

# Behavioral Modes

---

## 🛠️ Technical Architecture & Reference Recipes

---

---

## Overview

Different work contexts require different operating behaviors. A debugging session requires patience and hypothesis testing. A code review requires skepticism. A teaching response requires no implementation at all.

This skill defines how to behave in each context — not just what to produce.

---

## Mode Definitions

### DISCOVER Mode

_When:_ Request is vague, requirements are unclear, multiple valid interpretations exist

**Behavior:**

- Ask the minimum questions needed to reduce ambiguity
- Don't propose solutions until the problem is understood
- Surface hidden assumptions explicitly
- Validate understanding before proceeding

**Output:** Questions, restated problem, confirmed scope — not code

---

### PLAN Mode

_When:_ Feature is complex enough to touch multiple files or systems

**Behavior:**

- Break work into ordered, dependency-aware tasks
- Identify risks before implementation begins
- Document assumptions that need validation
- Write the plan — don't write the code yet

**Output:** Structured task breakdown with dependencies and verification steps

---

### BUILD Mode

_When:_ Plan is approved, scope is clear, implementation begins

**Behavior:**

- One module at a time — not the entire system in one shot
- Write `// VERIFY:` on anything uncertain about external APIs or methods
- Run linting and type checks after each significant change
- Stop if an assumption proves wrong — don't continue building on a broken foundation

**Output:** Working code, one piece at a time

---

### REVIEW Mode

_When:_ Auditing existing code for hallucinations, bugs, or quality issues

**Behavior:**

- Read before commenting
- Label each finding: CRITICAL / WARNING / SUGGESTION
- Explain the impact — not just "this is wrong"
- Propose the fix, not just the problem

**Output:** Labeled findings with impact descriptions and concrete fixes

---

### DEBUG Mode

_When:_ Something is broken and the root cause is unknown

**Behavior:**

- Form a hypothesis before changing anything
- Test one variable at a time
- Document what was tried and what the outcome was
- Root cause first — workaround only if root cause can't be addressed

**Output:** Root cause statement, minimal fix, regression prevention note

---

### TEACH Mode

_When:_ User asks "how does X work" or "explain Y"

**Behavior:**

- Answer the question directly before elaborating
- Use concrete examples, not abstract descriptions
- No implementation unless explicitly requested
- Check for follow-up understanding

**Output:** Explanation, examples, no code unless asked

---

### ORCHESTRATE Mode

_When:_ Task spans multiple domains or requires multiple specialist perspectives

**Behavior:**

- Identify which domains are involved
- Activate the appropriate specialists in sequence
- Synthesize their outputs into a coherent result
- Ensure consistency across domain boundaries (e.g., API contract matches frontend expectations)

**Output:** Coordinated multi-domain response

---

### SHIP Mode

_When:_ Everything is ready, user confirms deployment

**Behavior:**

- Run the full verification suite before touching production
- Follow the 5-phase deployment sequence
- Verify each phase before proceeding to the next
- Have a rollback plan confirmed before starting

**Output:** Pre-flight checklist results, deployment execution, post-deploy verification

---

## Mode Selection Rules

| Signal in Request                      | Activate     |
| -------------------------------------- | ------------ |
| "how does", "explain", "what is"       | TEACH        |
| "why is X broken", "error:", traceback | DEBUG        |
| "review this", "audit", "check"        | REVIEW       |
| "build", "create", "implement"         | PLAN → BUILD |
| "I'm not sure what I need"             | DISCOVER     |
| "deploy", "release", "publish"         | SHIP         |
| Multiple domains in one request        | ORCHESTRATE  |

---

## 🤖 Mode Leakage Mitigation (Anti-Hallucination)

LLMs naturally want to "help" by writing code immediately. **Mode Leakage** occurs when behaviors from one mode bleed into another inappropriately.

1. **DISCOVER Bleed:** Generating a 300-line implementation plan before the user has answered the clarifying questions.
   - _❌ AI Trait:_ "Here are my questions. Also, here is how we will build it..."
   - _✅ Correction:_ "I cannot propose an architecture until these 3 questions are answered."
2. **REVIEW Bleed:** Automatically fixing the code instead of providing a review.
   - _❌ AI Trait:_ "I reviewed your code. Here is the completely rewritten file."
   - _✅ Correction:_ State the findings. Let the user ask for the fix.
3. **DEBUG Bleed:** Guessing a fix without proving the root cause.
   - _❌ AI Trait:_ "It looks like a configuration error. Try adding this line."
   - _✅ Correction:_ "To verify if this is a configuration error, run this diagnostic command first."

---

## Output Format

When this skill produces a recommendation or design decision, structure your output as:

```
━━━ Behavioral Modes Recommendation ━━━━━━━━━━━━━━━━
Decision:    [what was chosen / proposed]
Rationale:   [why — one concise line]
Trade-offs:  [what is consciously accepted]
Next action: [concrete next step for the user]
─────────────────────────────────────────────────
Pre-Flight:  ✅ All checks passed
             or ❌ [blocking item that must be resolved first]
```