analysis-autonomous-mode

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:

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

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 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.