frappe-agent-interpreter（冰沙 Agent 翻译）

Frappe Code Interpreter Agent

Transforms vague or incomplete Frappe/ERPNext development requests into clear, actionable technical specifications mapped to the full 61-skill catalog.

Purpose: Bridge the gap between "what the user wants" and "what needs to be built"

When to Use This Agent

USER REQUEST ANALYSIS
|
+-- Request is vague/incomplete
|   "Make the invoice do something when submitted"
|   --> USE THIS AGENT
|
+-- Request lacks technical specifics
|   "Add approval before order confirmation"
|   --> USE THIS AGENT
|
+-- Multiple implementation paths possible
|   "Automate inventory updates"
|   --> USE THIS AGENT
|
+-- Request has clear technical specs already
|   "Create Server Script on validate for Sales Invoice"
|   --> Skip agent, use relevant frappe-* skills directly

Interpretation Workflow

STEP 1: EXTRACT INTENT
  - What is the business problem?
  - What should happen? When? To what data?
  - Who should be affected (roles/users)?

STEP 2: IDENTIFY TRIGGER CONTEXT
  - Document lifecycle event? (save/submit/cancel)
  - User action? (button click, field change)
  - Time-based? (daily, hourly, cron)
  - External event? (webhook, API call)

STEP 3: DETERMINE MECHANISM
  - Client Script, Server Script, or Controller?
  - Hooks configuration needed?
  - Custom app required?
  - v16 extend_doctype_class applicable?

STEP 4: GENERATE SPECIFICATION
  - DocType(s), event/trigger, mechanism, data flow
  - Error handling requirements
  - Version compatibility (v14/v15/v16)

STEP 5: MAP TO SKILLS
  - List required frappe-* skills from full catalog
  - Note dependencies between skills

See references/workflow.md for detailed steps.

Mechanism Selection Matrix

Clarifying Questions Framework

1. WHAT Questions

• What DocType(s) are involved?
• What data needs to change?
• What should the outcome be?

2. WHEN Questions

• On form load? On field change? Before/after save?
• Before/after submit? On a schedule? Button click?

3. WHO Questions

• All users? Specific roles? Document owner only?

4. WHERE Questions

• In the form (UI)? Database only? Report? External system?

5. ERROR Questions

• Block the operation? Show warning? Log silently?

6. VERSION Questions (v16 considerations)

• Target single version or multi-version compatibility?
• Can we use extend_doctype_class (v16) or need doc_events (v14+)?
• Type annotations desired? (v16 best practice)

Output Specification Template

ALWAYS generate specifications in this format:

## Technical Specification

### Summary
[One sentence describing what will be built]

### Business Requirement
[Original user request, clarified]

### Implementation

| Aspect | Value |
|--------|-------|
| **DocType(s)** | [List] |
| **Trigger** | [Event/action] |
| **Mechanism** | [Client Script / Server Script / Controller / etc.] |
| **Version** | [v14 / v15 / v16 / all] |

### Data Flow
1. [Step 1]
2. [Step 2]

### Error Handling
[Strategy]

### Required Skills
- [ ] frappe-skill-name - for [purpose]

### Validation Criteria
[How to verify it works]

Complete Skill Catalog (61 skills)

Syntax Layer (11 skills)

Core Layer (7 skills)

Implementation Layer (12 skills)

Error Layer (7 skills)

Ops Layer (8 skills)

Testing Layer (2 skills)

Agent Layer (5 skills)

Skill Dependencies Map

Common Pattern Recognition

Version Awareness

ALWAYS consider version compatibility:

Agent Output Checklist

Before completing interpretation, ALWAYS verify:

• Business requirement is clear and unambiguous
• Trigger/event is identified
• Mechanism is selected with justification
• DocType(s) are specified
• Data flow is documented
• Error handling approach is defined
• Version compatibility is noted (v14/v15/v16)
• Required frappe-* skills are listed from full catalog
• Validation criteria are defined
• v16 considerations noted (extend_doctype_class, type annotations)

See references/checklists.md for detailed checklists. See references/examples.md for interpretation examples.