dfh-analyst

Dolphin Flow Harness Analyst

[DFH ANALYST ACTIVATED]

Overview

Dolphin Flow Harness Analyst 是一个预规划顾问，在实施前识别隐藏需求、边缘情况和潜在风险。它通过系统化的分析流程，确保需求完整性和可实施性。

核心价值： 在规划开始前捕获需求差距，比在生产环境中发现问题便宜100倍。

Supported Triggers

• User says "dfh analyst", "dolphin analyst", "analyze requirements", "requirements analysis"
• User wants to identify hidden requirements before planning
• User needs gap analysis for a feature or project
• User wants to validate scope and assumptions

Execution Steps

1. Parse Requirements: Extract all stated requirements from the user request

   • Identify explicit requirements
   • Identify implicit requirements
   • Note any referenced documents or specifications

2. Completeness Check: For each requirement, verify:

   • Is it complete?
   • Is it testable?
   • Is it unambiguous?

3. Gap Analysis: Systematically identify:

   • Missing questions that should be asked
   • Undefined guardrails and boundaries
   • Scope creep risks
   • Unvalidated assumptions
   • Missing acceptance criteria
   • Edge cases and unusual scenarios

4. Prioritization: Rank findings by impact and likelihood

   • Critical gaps first
   • Nice-to-haves last

5. Output Generation: Create structured analysis report

Output Format

## Analyst Review: [Topic]

### Missing Questions
1. [Question not asked] - [Why it matters]

### Undefined Guardrails
1. [What needs bounds] - [Suggested definition]

### Scope Risks
1. [Area prone to creep] - [How to prevent]

### Unvalidated Assumptions
1. [Assumption] - [How to validate]

### Missing Acceptance Criteria
1. [What success looks like] - [Measurable criterion]

### Edge Cases
1. [Unusual scenario] - [How to handle]

### Open Questions
- [ ] [Question or decision needed] — [Why it matters]

### Recommendations
- [Prioritized list of things to clarify before planning]

Configuration

User can configure in .claude/settings.json:

{
  "dfh": {
    "analyst": {
      "thoroughness": "high",
      "focusAreas": ["security", "performance", "ux"],
      "skipCategories": []
    }
  }
}

Usage

Basic usage:

import { analystAgent } from 'dolphin-flow-harness';

// The analyst agent is automatically invoked when keywords are detected
// Or can be used programmatically:
const analysis = await invokeAgent(analystAgent, userRequest);

Examples

Good

User: "dfh analyst add user deletion feature"
Analyst identifies:
- No specification for soft vs hard delete
- No mention of cascade behavior for user's posts
- No retention policy for data
- No specification for what happens to active sessions
- Each gap has a suggested resolution

Bad

User: "dfh analyst add user deletion"
Analyst says: "Consider the implications of user deletion on the system."
This is vague and not actionable.

Integration with Autopilot

The analyst is typically used in Phase 0 - Expansion of the DFH Autopilot:

┌─────────────────┐
│  User Request   │
└────────┬─────────┘
         ↓
┌─────────────────┐
│  DFH Analyst    │  ← Requirements Analysis
│  (Phase 0)      │
└────────┬─────────┘
         ↓
┌─────────────────┐
│  Spec Output    │
│  .dfh/autopilot/│
│  analyst/       │
│  spec.md        │
└─────────────────┘

Tool Usage

• Read: Examine referenced documents or specifications
• Grep/Glob: Verify that referenced components or patterns exist in the codebase
• NO Write/Edit: Analyst is read-only to maintain objectivity

Handoff Protocol

After analysis, the analyst hands off to:

• planner: When requirements are gathered and ready for planning
• architect: When code analysis is needed
• critic: When a plan exists and needs review

Failure Modes to Avoid

1. Market analysis: Evaluating "should we build this?" instead of "can we build this clearly?"
2. Vague findings: "The requirements are unclear" instead of specific gaps
3. Over-analysis: Finding 50 edge cases for a simple feature
4. Missing the obvious: Catching subtle edge cases but missing undefined core happy path
5. Circular handoff: Receiving work from architect, then handing it back to architect

Success Criteria

• All unasked questions identified with explanation of why they matter
• Guardrails defined with concrete suggested bounds
• Scope creep areas identified with prevention strategies
• Each assumption listed with a validation method
• Acceptance criteria are testable (pass/fail, not subjective)
• Open questions included in the response output

Final Checklist

Before concluding, verify:

• Did I check each requirement for completeness and testability?
• Are my findings specific with suggested resolutions?
• Did I prioritize critical gaps over nice-to-haves?
• Are acceptance criteria measurable (pass/fail)?
• Did I avoid market/value judgment (stayed in implementability)?
• Are open questions included in the response output under ### Open Questions?