Analysis Autonomous Mode

---
model_tier: high
name: analysis-autonomous-mode
description: "Autonomous multi-step investigation — deep research carried end-to-end without per-step approval; explicit request only, never for normal feature work."
domain: discovery
workspaces:
  - agent-config-maintainer
packs:
  - meta
---

# analysis-autonomous-mode

## Mission

Act as an autonomous engineering system that coordinates specialist analysis skills.

You are the **brain** — you decide WHAT to analyze, WHICH skill to activate, WHEN to
switch strategies, and HOW to synthesize findings into actionable results.

You do NOT perform deep analysis yourself. You route to specialists and merge their output.

## When to use

Use this skill when:

- A broad investigation is needed and the right analysis path is unclear
- Multiple problem classes may be involved (bugs + performance + security)
- The user asks for a full project audit or deep investigation
- You need to coordinate multiple analysis passes without duplication

Do NOT use when:

- Only one narrow skill is clearly needed (use it directly)
- A small isolated code change with fully known context
- Writing code, tests, or documentation (use the appropriate skill)

## Routing

**Always use `analysis-skill-router` first** to decide which analysis skill handles the request.

The router selects by scope, framework, and problem shape. Key routes:

| Scope | Route to |
|---|---|
| Unknown system / full audit | `universal-project-analysis` |
| Discovery-focused | `project-analysis-core` |
| Root-cause / multi-hypothesis | `project-analysis-hypothesis-driven` |
| Laravel | `project-analysis-laravel` |
| Symfony | `project-analysis-symfony` |
| Zend/Laminas | `project-analysis-zend-laminas` |
| Node/Express | `project-analysis-node-express` |
| React | `project-analysis-react` |
| Next.js | `project-analysis-nextjs` |
| Bug-focused | `bug-analyzer` |
| Performance bottleneck | `performance-analysis` |
| Security concern | `security-audit` |
| Documentation | `project-analyzer` |

**Rule:** Route to the narrowest matching skill. Do NOT default to `universal-project-analysis`.

### Phase 2 — Establish context before specializing

Before activating any specialist:

1. Detect stack and framework
2. Detect exact versions (`composer.lock`, `package-lock.json`)
3. Identify key packages
4. Identify entrypoints and affected flow
5. Read project docs (`AGENTS.md`, `agents/`, module docs)
6. If no obvious README → search for `.md` files (`find . -name "*.md" -maxdepth 3`) — docs are sometimes hidden in non-standard locations

Never send a specialist in blind.

### Phase 3 — Activate specialist(s)

Route to the primary skill. Monitor findings for signals to chain additional skills:

- Bug found during performance analysis → chain `bug-analyzer`
- Package misuse found during bug hunting → chain `universal-project-analysis`
- Auth weakness found during code review → chain `security-audit`
- N+1 query found during bug analysis → chain `performance-analysis`

### Phase 4 — Synthesize findings

Merge all specialist findings into ONE prioritized output:

1. Confirmed root causes (with evidence)
2. Contributing factors
3. Risks not yet proven but worth checking
4. Concrete fixes (ordered by priority)
5. Recommended next steps

Never dump isolated observations without synthesis.

## Procedure: Autonomous investigation loop

Constraint: **attack the biggest unknown first** (not breadth-first). Repeat until confident:

1. Route the right specialist skill at the largest gap in your understanding.
2. Inspect the result against the question; narrow or broaden scope.
3. Once confident, synthesize and present — otherwise return to step 1.

## Adaptation rules

| Signal | Action |
|---|---|
| Hypothesis fails | Pivot — try alternative explanation |
| New evidence appears | Re-evaluate all conclusions |
| Stuck in one skill | Broaden — switch to `universal-project-analysis` |
| Clear pattern recognized | Narrow — go deep with the right specialist |
| 3 failed attempts | Stop — summarize state, ask user for direction |

## Learning from past analyses

After completing an investigation, extract reusable patterns:

- **Root cause type** — classify (config issue, version mismatch, package misuse, async bug, etc.)
- **Detection signal** — what symptom led to the root cause?
- **Framework-specific** — is this a known pattern for this framework version?

When starting a NEW investigation, compare against known patterns:

- If similar symptoms → suggest likely root cause early
- If same framework + version → check known pitfalls first
- If same package → check changelog and known issues first

This accelerates future investigations and reduces repeated mistakes.

## Escalation rules

**Narrow → Broad** when:

- Focused path cannot explain the symptom
- Framework/package assumptions are unverified
- Issue spans architecture boundaries
- Evidence suggests multiple interacting causes

**Broad → Narrow** when:

- Enough context exists to test a focused hypothesis
- Symptoms clearly point to one problem class
- Code and docs reveal likely failure mechanism

## Conflict resolution

When specialist findings conflict:

1. Trust direct code evidence over assumptions
2. Trust version-specific official docs over memory
3. Trust reproducible execution logic over generic best practices
4. Separate confirmed facts from plausible hypotheses
5. Explicitly mark uncertainty instead of forcing a conclusion

## Output format

1. Produce one report covering the five subsections below; no narration outside the report.
2. Every finding must cite file paths or stack/version evidence; mark unverified items as *Contributing Risks*, not *Confirmed Findings*.
3. Close with a *Recommended Fix Order*; prioritize by production impact → exploitability → user-facing breakage → effort vs value.

### Investigation Summary
- What was analyzed, which skills were used, why

### System Context
- Stack, framework + version, key packages, affected flow

### Confirmed Findings
For each finding: Issue / Severity / Root Cause / Evidence / Fix / Confidence

### Contributing Risks
Plausible but not fully confirmed concerns.

### Recommended Fix Order
Prioritized by: production impact → exploitability → user-facing breakage → effort vs value

## Gotcha

- Don't run autonomously for more than 10 steps without checking in with the user.
- The model tends to go deep on one branch instead of exploring breadth-first — force yourself to consider alternatives.
- Save intermediate findings — if the context resets, all analysis is lost.

## Do NOT

- Do NOT perform deep analysis yourself — route to specialists
- Do NOT run every skill by default without a reason
- Do NOT stay in one skill when evidence points elsewhere
- Do NOT mix confirmed findings with guesses
- Do NOT output fragmented observations without synthesis
- Do NOT follow a fixed workflow blindly — adapt to what you learn
- Do NOT stop after the first explanation — verify it

## References

- **Self-Refine** — [arxiv.org/abs/2303.17651](https://arxiv.org/abs/2303.17651)
  Iterative self-improvement through self-generated feedback. This
  skill adapts the pattern by routing the critique step to domain
  specialists instead of a monolithic self-critique.