Skill Context Detection

---
name: skill-context-detection
description: "Auto-detect work context (Dev vs Knowledge) — use to tailor workflows based on current task type"
disable-model-invocation: true
---

> **Host: Codex CLI** — This skill was designed for Claude Code and adapted for Codex.
> Cross-reference commands use installed skill names in Codex rather than `/octo:*` slash commands.
> Use the active Codex shell and subagent tools. Do not claim a provider, model, or host subagent is available until the current session exposes it.
> For host tool equivalents, see `skills/blocks/codex-host-adapter.md`.


# Context Detection - Internal Skill

## Purpose

This skill provides **automatic context detection** to determine whether the user is working in a **Development context** (code-focused) or **Knowledge context** (research/strategy-focused). This replaces the manual `/octo:km` toggle with intelligent auto-detection.

## Detection Algorithm

When a workflow skill activates, detect context using these signals:

### Step 1: Check for Explicit Override

If user has explicitly set mode via `/octo:km on` or `/octo:km off`, respect that setting.

```bash
# Check if knowledge mode is explicitly set
if [[ -f ~/.claude-octopus/config/knowledge-mode ]]; then
  EXPLICIT_MODE=$(cat ~/.claude-octopus/config/knowledge-mode)
  if [[ "$EXPLICIT_MODE" == "on" ]]; then
    echo "knowledge"
    exit 0
  elif [[ "$EXPLICIT_MODE" == "off" ]]; then
    echo "dev"
    exit 0
  fi
fi
# If "auto" or not set, proceed with auto-detection
```

### Step 2: Analyze Prompt Content (Strongest Signal)

**Knowledge Context Indicators** (check prompt for these terms):
- Business/strategy: "market", "ROI", "stakeholders", "strategy", "business case", "competitive"
- Research: "literature", "synthesis", "academic", "papers", "research question"
- UX: "personas", "user research", "journey map", "pain points", "interviews"
- Deliverables: "presentation", "report", "PRD", "proposal", "executive summary"

**Dev Context Indicators** (check prompt for these terms):
- Technical: "API", "endpoint", "database", "function", "class", "module"
- Actions: "implement", "debug", "refactor", "test", "deploy", "build"
- Artifacts: "code", "tests", "migration", "schema", "controller"

**Scoring:**
- Count knowledge indicators in prompt
- Count dev indicators in prompt
- Higher count wins
- If tied, check project context (Step 3)

### Step 3: Analyze Project Context (Secondary Signal)

**Dev Project Indicators:**
- Has `package.json`, `Cargo.toml`, `go.mod`, `pyproject.toml`, `pom.xml`
- Has `src/`, `lib/`, `app/` directories with code files
- Recent files are `.ts`, `.js`, `.py`, `.go`, `.rs`, `.java`

**Knowledge Project Indicators:**
- Has `docs/`, `research/`, `strategy/`, `reports/` directories
- Majority of files are `.md`, `.docx`, `.pdf`, `.pptx`
- No code package managers detected

### Step 4: Default Fallback

If signals are ambiguous or equal:
- In a git repo with code files → Default to **Dev Context**
- No code files detected → Default to **Knowledge Context**


## Context Output Format

Return detected context as a structured object for use by workflow skills:

```json
{
  "context": "dev" | "knowledge",
  "confidence": "high" | "medium" | "low",
  "signals": {
    "prompt_indicators": ["API", "endpoint", "database"],
    "project_type": "node_typescript",
    "explicit_override": false
  }
}
```


## How Workflow Skills Use Context

### flow-discover (Research)

| Aspect | Dev Context | Knowledge Context |
|--------|-------------|-------------------|
| **Research Focus** | Technical implementation, library comparison, code patterns | Market analysis, academic synthesis, competitive research |
| **Primary Agents** | Codex (implementation), Antigravity (ecosystem) | Antigravity (analysis), research-synthesizer |
| **Output Format** | Code examples, API comparisons, tech recommendations | Reports, frameworks, strategic recommendations |
| **Visual Banner** | `🔍 [Dev] Discover Phase: Technical research` | `🔍 [Knowledge] Discover Phase: Strategic research` |

### flow-develop (Build)

| Aspect | Dev Context | Knowledge Context |
|--------|-------------|-------------------|
| **Build Focus** | Code generation, implementation, architecture | PRDs, strategy docs, presentations |
| **Primary Agents** | Codex (code), backend-architect, tdd-orchestrator | product-writer, strategy-analyst, exec-communicator |
| **Output Format** | Source files, tests, migrations | Documents, frameworks, action plans |
| **Visual Banner** | `🛠️ [Dev] Develop Phase: Building code` | `🛠️ [Knowledge] Develop Phase: Building deliverables` |

### flow-deliver (Review)

| Aspect | Dev Context | Knowledge Context |
|--------|-------------|-------------------|
| **Review Focus** | Code quality, security, performance | Document quality, argument strength, completeness |
| **Primary Agents** | code-reviewer, security-auditor | exec-communicator, strategy-analyst |
| **Quality Gates** | OWASP, test coverage, maintainability | Evidence quality, clarity, actionability |
| **Visual Banner** | `✅ [Dev] Deliver Phase: Code review` | `✅ [Knowledge] Deliver Phase: Document review` |


## Visual Indicator Update

When context is detected, update the visual banner to show context:

**Dev Context:**
```
🐙 **CLAUDE OCTOPUS ACTIVATED** - Multi-provider research mode
🔍 [Dev] Discover Phase: Researching OAuth implementation patterns

Providers:
🔴 Codex CLI - Technical implementation analysis
🟡 Antigravity CLI - Ecosystem and library comparison
🔵 Claude - Strategic synthesis
```

**Knowledge Context:**
```
🐙 **CLAUDE OCTOPUS ACTIVATED** - Multi-provider research mode
🔍 [Knowledge] Discover Phase: Researching market entry strategies

Providers:
🔴 Codex CLI - Data analysis and modeling
🟡 Antigravity CLI - Market and competitive research
🔵 Claude - Strategic synthesis
```


## Implementation in Workflow Skills

Each flow skill should:

1. **Before executing workflow**, run context detection
2. **Show detected context** in visual banner
3. **Adjust behavior** based on context:
   - Agent selection
   - Prompt framing for external CLIs
   - Output format expectations
   - Quality gate criteria

### Example Integration (Pseudocode)

```markdown
When this skill activates:

1. **Detect context**
   - Analyze user's prompt for knowledge vs dev indicators
   - Check project type (code repo vs doc-heavy)
   - Check for explicit override (~/.claude-octopus/config/knowledge-mode)
   - Determine: "dev" or "knowledge" with confidence level

2. **Show context-aware banner**
   ```
   🐙 **CLAUDE OCTOPUS ACTIVATED** - Multi-provider [research|implementation|validation] mode
   [Phase Emoji] [Context] [Phase Name]: [Description]
   
   Detected Context: [Dev|Knowledge] (confidence: [high|medium|low])
   ```

3. **Execute workflow with context-appropriate behavior**
   - Frame prompts for external providers based on context
   - Select appropriate synthesis approach
   - Apply context-specific quality gates
```


## Override Mechanism

Users can still explicitly set context when auto-detection is wrong:

```bash
# Force knowledge mode
/octo:km on

# Force dev mode  
/octo:km off

# Return to auto-detection
/octo:km auto
```

When explicit override is set, context detection respects it until user resets to "auto".


## Confidence Levels

- **High**: Strong signals in prompt AND project context agree
- **Medium**: Signals in prompt OR project context (not both)
- **Low**: Ambiguous signals, using fallback default

When confidence is "low", consider briefly mentioning the detected context to user:
> "I detected this as a [dev/knowledge] task. If that's wrong, you can use `/octo:km` to override."


## Testing Context Detection

To verify context detection is working:

1. In a code repository, ask "octo research caching patterns" → Should detect **Dev Context**
2. In same repo, ask "octo research market opportunities" → Should detect **Knowledge Context**
3. With `/octo:km on` set, ask "octo research API patterns" → Should use **Knowledge Context** (explicit override)


## Proactive Skill Suggestions

When detecting the user's work stage, surface relevant command suggestions:

| Detected Context | Suggestion |
|-----------------|------------|
| Brainstorming / exploring ideas | Consider `/octo:brainstorm` for structured ideation |
| Reviewing a plan or strategy | Consider `/octo:plan` for strategic planning |
| Debugging errors or failures | Consider `/octo:debug` for systematic investigation |
| Writing or running tests | Consider `/octo:tdd` for test-driven development |
| Code review before merge | Use Claude-native `/review` for ordinary review; suggest `/octo:review` for multi-AI escalation |
| Ready to deploy or ship | Consider `/octo:deliver` for quality-gated delivery |
| Researching a topic | Consider `/octo:research` for multi-source synthesis |
| Working on security | Use Claude-native `/security-review` for ordinary security review; suggest `/octo:security` for escalated OWASP or adversarial audit |

### Suggestion Format

Suggestions should be non-intrusive, appended as a brief note:

```
💡 Tip: You appear to be debugging — `/octo:debug` provides systematic investigation with multi-AI support.
```

### Persistent Opt-Out

- If user says "stop suggesting" or "no more tips": set `OCTO_PROACTIVE_SUGGESTIONS=off` in `.claude-octopus/preferences.json`
- If user says "be proactive" or "turn on tips": set `OCTO_PROACTIVE_SUGGESTIONS=on`
- Check preference at suggestion time — never suggest when opted out
- Respect current mode: dev mode suggestions differ from knowledge work suggestions

### Re-Enable Suggestions

Users who previously opted out can re-enable suggestions at any time:
- Say "be proactive", "turn on tips", or "enable suggestions"
- Manually edit `~/.claude-octopus/preferences.json` and set `OCTO_PROACTIVE_SUGGESTIONS` to `on`
- Default state (no preference set) is suggestions enabled

### Detection Signals

Detect work stage from:
- Recent tool usage (many Bash calls = likely implementing/debugging)
- File types being edited (.test.ts = testing, .md = documentation)
- Error patterns in recent output (stack traces = debugging)
- Git state (uncommitted changes = implementing, clean tree = ready to review/ship)