Structured Analysis

name: structured-analysis description: Apply structured analytical frameworks to any artifact (prompts, systems, documents, code). 12 frameworks in 3 tiers: Core (4 universal), Auto-Invoke (specialized), On-Demand (advanced). Includes adversarial-review for finding blind spots and post-plan validation workflow.

Structured Analysis Skill

Auto-activate when: User mentions analyze, review, validate, critique, framework, deep-analyze, reasoning-scaffold, adversarial-review, or asks to evaluate a plan, system, prompt, architecture, or design. Should activate when user asks "what could go wrong" or "review this".

Apply structured analytical frameworks to ANY artifact: prompts, systems, documents, code, architecture.

12 Total Frameworks organized in 3 tiers for easy selection.

Framework Tiers

Tier 1: Core Frameworks (Use Most Often)

• deep-analyze: Verification, gaps, adversarial review
• reasoning-scaffold: Systematic decisions with clear criteria
• scope-boundary: Prevent scope creep, MVP validation [NEW]
• adversarial-review: Red-team attack to find flaws/blind spots [NEW]

Tier 2: Auto-Invoke (Triggered by Context)

• zero-warning-verification: Pre-commit quality gate (auto-runs)
• security-first-design: Auth/secrets/external data (conditional)
• idempotency-audit: Scripts/setup/migrations (conditional)

Tier 3: On-Demand (Explicit Request Only)

• meta-prompting: Design optimal prompts
• recursive-review: 3-pass refinement
• multi-perspective: Multiple conflicting viewpoints
• evidence-based-optimization: Require proof before optimizing
• deliberate-detail: Comprehensive documentation
• temperature-simulation: Confidence calibration

Selection Guide: Start with Tier 1 for most tasks. Tier 2 frameworks auto-invoke when relevant. Request Tier 3 explicitly when needed.

Technique Templates

meta-prompting

Best for: Unfamiliar domains, maximum quality, vague prompts

You're an expert prompt designer.

Task: {BASE_PROMPT}

Design the optimal prompt considering:
- Essential context vs optional
- Optimal output format
- Explicit reasoning steps needed
- Constraints to prevent bad outputs
- Examples to eliminate ambiguity
- Quality verification steps

Execute the designed prompt.

recursive-review

Best for: Building reusable templates, debugging prompts

{BASE_PROMPT}

Then optimize this through 3 versions:

Version 1: Add missing constraints
- What assumptions are implicit?
- What edge cases aren't covered?
- What outputs are undesirable?
- Add constraints to prevent these.

Version 2: Resolve ambiguities
- What terms need clearer definition?
- What scope is unclear (too broad/narrow)?
- What priorities might conflict?
- Clarify all ambiguities.

Version 3: Enhance reasoning depth
- What reasoning should be made explicit?
- Where would examples help?
- What verification steps should be built in?
- What quality bar should be set?

After all versions, execute the final optimized version.

deep-analyze

Best for: High-stakes decisions, security analysis, confidence calibration

{BASE_PROMPT}

Phase 1: Initial Analysis
Provide thorough analysis.

Phase 2: Chain of Verification
1. **Incompleteness Check**: 3 ways analysis might be incomplete/biased
2. **Challenging Evidence**: Specific counter-examples, alternative interpretations, conflicting data
3. **Revised Findings**: What changed, strengthened, or introduced new uncertainties
4. **Confidence Calibration**: 0-100% with justification and key uncertainties

Phase 3: Adversarial Review
1. **5 Failure Modes**: Likelihood (L/M/H) and Impact (1-10) for each
2. **Top 3 Vulnerabilities**: Prioritize failures by importance
3. **Mitigations**: Strengthening strategies

Phase 4: Final Synthesis
- Core findings (with confidence levels)
- Key uncertainties
- Recommended actions
- Follow-up questions

Be self-critical. If verification doesn't find problems, analysis wasn't rigorous enough.

multi-perspective

Best for: Complex trade-offs, stakeholder alignment, exploring options

{BASE_PROMPT}

Define 3 Expert Personas with conflicting priorities:

**Persona 1**: [Name/Role] - Priority: [X] - Background: [Expertise]
**Persona 2**: [Name/Role] - Priority: [Y conflicts with X] - Background: [Expertise]
**Persona 3**: [Name/Role] - Priority: [Z conflicts with X,Y] - Background: [Expertise]

Round 1: Opening Arguments
- **Persona 1**: [Priority justification, recommended approach]
- **Persona 2**: [Priority justification, recommended approach]
- **Persona 3**: [Priority justification, recommended approach]

Round 2: Critiques
- **Persona 1**: [Problems with 2 and 3]
- **Persona 2**: [Problems with 1 and 3]
- **Persona 3**: [Problems with 1 and 2]

Round 3: Refinement
- **Persona 1**: [Response to critiques, compromise area]
- **Persona 2**: [Response to critiques, compromise area]
- **Persona 3**: [Response to critiques, compromise area]

Synthesis:
- Points of Agreement
- Irreconcilable Differences
- Recommended Balanced Solution
- Sensitivity Analysis: If X priority dominates → Y approach

Personas must have genuine tension.

deliberate-detail

Best for: Learning complex topics, comprehensive documentation

{BASE_PROMPT}

Do NOT summarize or be concise. Provide for every point:
- **Implementation details**: Step-by-step how it works
- **Edge cases**: Where it breaks/behaves unexpectedly
- **Failure modes**: What goes wrong and why
- **Historical context**: Why it exists, what it replaced
- **Trade-offs**: What you sacrifice
- **Alternatives**: Other approaches and why not chosen

Prioritize completeness over brevity.

reasoning-scaffold

Best for: Systematic decisions, reproducible analysis

{BASE_PROMPT}

Step 1: Core Question
[Fundamental question being asked]

Step 2: Key Components
[Essential variables, entities, components - define each]

Step 3: Relationships
[Dependencies and interactions between components]

Step 4: Possible Approaches
[3-5 approaches with Description, Pros, Cons]

Step 5: Decision Criteria
[Criteria with relative weights/importance]

Step 6: Optimal Approach
[Selection justified against Step 5 criteria]

Step 7: Risk Analysis
[Risks and mitigation strategies]

Step 8: Final Recommendation
[Recommendation, confidence 0-100%, justification]

temperature-simulation

Best for: Confidence calibration, catching mistakes

{BASE_PROMPT}

Response 1 - Junior Analyst (Uncertain, Over-Explains)
- Hedged language, caveats
- Step-by-step basic concepts
- Uncertain conclusions
[Junior's response]

Response 2 - Senior Expert (Confident, Direct)
- Bottom-line up front
- Assumes domain knowledge
- Concise, telegraphic
[Expert's response]

Synthesis - Balanced Integration
- What junior catches that expert glosses over
- What expert sees that junior misses
- Appropriately-calibrated answer
[Integrated response]

adversarial-review [NEW]

Best for: Red-team attack on plans/systems to find flaws, edge cases, blind spots

{BASE_TARGET}

Phase 1: Challenge Assumptions
- What assumptions does this make?
- Which assumptions are most likely wrong?
- What happens if each assumption fails?

Phase 2: Edge Case Mining
- Boundary conditions (empty, null, max, negative)
- Timing issues (race conditions, ordering)
- Environment variations (OS, versions, permissions)
- Data quality issues (malformed, missing, duplicate)

Phase 3: Failure Mode Analysis
- List 5 ways this could fail
- For each: Likelihood (H/M/L), Impact (1-10), Mitigation
- Which failures are catastrophic?

Phase 4: Hidden Dependencies
- Undocumented state assumptions
- External service dependencies
- Implicit ordering requirements
- Configuration assumptions

Phase 5: Attack Vectors & Blind Spots
- What did we not consider?
- What expertise are we missing?
- Where could malicious input cause issues?
- What would break this in production?

Be adversarial. If you don't find issues, you weren't critical enough.

scope-boundary [NEW]

Best for: Preventing scope creep, validating MVP, feature prioritization

{BASE_PLAN}

Phase 1: Core vs Nice-to-Have
- What is the ABSOLUTE minimum to solve the user's problem?
- What features are "just in case" rather than "must have"?
- What can be deferred to v2?

Phase 2: YAGNI Audit (You Aren't Gonna Need It)
- What abstractions/patterns aren't justified yet?
- What configuration/flexibility isn't required?
- What edge cases can be handled later?

Phase 3: Dependency Bloat
- What libraries/tools add unnecessary complexity?
- What can be done with stdlib/built-ins?
- What dependencies have large transitive footprints?

Phase 4: Simplification Opportunities
- Can this be split into smaller, independent pieces?
- What's the simplest implementation that works?
- What assumptions simplify the problem space?

Phase 5: Scope Recommendation
- **Keep**: Essential features (justify each)
- **Defer**: Nice-to-have for later
- **Remove**: YAGNI, premature optimization, over-engineering

Bias toward simplicity. Complexity requires strong justification.

idempotency-audit [NEW]

Best for: Scripts, setup, migrations, state-changing operations

{BASE_SCRIPT}

Phase 1: Re-run Analysis
- What happens if this runs twice?
- What operations are not idempotent?
- What state does it assume?

Phase 2: Failure Recovery
- If this fails halfway, what's left in a broken state?
- Can it be safely retried?
- What cleanup is needed?

Phase 3: Detection Patterns
- Check-then-act (if not exists, create)
- Declarative operations (set to X, not increment)
- Cleanup old state before creating new

Phase 4: Idempotency Issues
List non-idempotent operations:
- **Operation**: [What it does]
- **Problem**: [Why it fails on re-run]
- **Fix**: [How to make it idempotent]

Phase 5: Recommendations
- What checks to add before operations
- What state detection is needed
- What rollback/cleanup logic is missing

All setup/install/migration scripts MUST be safely re-runnable.

zero-warning-verification [NEW]

Best for: Pre-commit quality gate, test validation

{BASE_CHANGES}

Phase 1: Warning Audit
- Run relevant quality checks (make test, lint, type-check)
- Document ALL warnings (not just errors)
- Zero warnings is the requirement

Phase 2: Test Coverage
- Are new code paths tested?
- Do tests actually verify behavior (not just run)?
- Are edge cases covered?

Phase 3: Hidden Quality Issues
- Commented-out code to remove
- Debug prints/logging to clean up
- TODOs that should be addressed now
- Hardcoded values that need config

Phase 4: Breaking Changes
- API contract changes
- Backward compatibility issues
- Migration requirements

Phase 5: Quality Gate
- **PASS**: Zero warnings, tests pass, coverage adequate
- **FAIL**: Document specific issues blocking commit

`make test` showing warnings/failures is ALWAYS a blocking issue.

security-first-design [NEW]

Best for: Authentication, secrets, external data, user input

{BASE_DESIGN}

Phase 1: Attack Surface
- What user input is accepted?
- What external data sources are used?
- What authentication/authorization is needed?
- What secrets/credentials are involved?

Phase 2: OWASP Top 10 Review
- Injection attacks (SQL, command, XSS)
- Broken authentication
- Sensitive data exposure
- XXE (XML External Entities)
- Broken access control
- Security misconfiguration
- Cross-Site Scripting (XSS)
- Insecure deserialization
- Using components with known vulnerabilities
- Insufficient logging & monitoring

Phase 3: Secret Management
- Where are secrets stored? (NEVER in code/git)
- How are secrets accessed? (env vars, vault)
- Are secrets rotatable?
- What happens if secrets leak?

Phase 4: Input Validation
- What input validation is applied?
- Are allow-lists used (not deny-lists)?
- Is input sanitized before use?
- Are file uploads restricted?

Phase 5: Security Recommendations
- **CRITICAL**: Must-fix security issues
- **HIGH**: Should-fix vulnerabilities
- **MEDIUM**: Defense-in-depth improvements

Default to paranoid. Security issues are blocking.

evidence-based-optimization [NEW]

Best for: Performance work, refactoring, architectural changes

{BASE_OPTIMIZATION}

Phase 1: Problem Validation
- What specific problem does this solve?
- What evidence shows this is a problem?
- What metrics demonstrate the issue?

Phase 2: Baseline Measurement
- What's the current performance?
- How was it measured?
- Is the measurement methodology valid?

Phase 3: Alternative Solutions
For each alternative:
- **Approach**: [Description]
- **Complexity**: [Implementation effort]
- **Expected Impact**: [Quantified improvement]
- **Risks**: [What could go wrong]

Phase 4: Proof Requirement
- What benchmarks prove this optimization works?
- What's the expected improvement (quantified)?
- How will we verify it in production?

Phase 5: Optimization Decision
- **Recommended**: [Approach with best effort/impact ratio]
- **Evidence Required**: [What to measure before/after]
- **Success Criteria**: [Quantified improvement goal]

NEVER optimize without measuring. Premature optimization is evil.

Post-Plan Validation Workflow

Trigger: After user approves plan via ExitPlanMode

Process:

1. Always spawn: adversarial-review agent (find flaws/blind spots)
2. Conditional spawn:
   • idempotency-audit (if plan touches scripts/setup/migrations)
   • security-first-design (if plan involves auth/secrets/external data)
3. Run in parallel: 30-60 seconds total
4. Categorize findings:
   • 🚨 CRITICAL: Blocks execution (security, data loss, breaking changes)
   • ⚠️ IMPORTANT: Should address (edge cases, missing validation)
   • 💡 SUGGESTIONS: Nice to have (optimizations, improvements)
5. Present to user:
   • If CRITICAL: Block execution, require fixes
   • If only IMPORTANT/SUGGESTIONS: Show findings, user decides to proceed/adjust

Benefits: Fast planning (no bloat), thorough validation (catches issues early), user control (advisory findings don't block)

Technique Combinations

• meta-prompting,recursive-review - Design then refine
• deep-analyze,multi-perspective - Rigorous multi-angle analysis
• reasoning-scaffold,deliberate-detail - Structured exploration with depth
• multi-perspective,reasoning-scaffold - Multiple viewpoints, systematic comparison
• adversarial-review,scope-boundary - Challenge plan, trim scope
• security-first-design,adversarial-review - Security review with red-team attack
• Order: meta-prompting → recursive-review → deep-analyze → multi-perspective

Anti-Patterns

Effectiveness Indicators

Strong: Analysis finds real problems, personas conflict, confidence varies, verification changes conclusions, approaches differ, scope gets trimmed, security issues found Weak: No issues found, personas agree, perspectives identical, no constraints added, superficial application, rubber-stamp approval

Integration Notes

• /optimize-prompt [techniques] <prompt> - Apply techniques
• /prompt-help [technique] - View documentation
• Auto-selection uses decision tree when techniques unspecified
• Balance token cost vs value
• These scaffold reasoning processes, not magic keywords
• Post-plan validation runs automatically after plan approval
• Tier 2 frameworks auto-invoke based on context detection