afa-diagnose
Original:🇨🇳 Chinese
Translated
DTC Full-Funnel Diagnosis & Attribution Engine —— Full-funnel attribution analysis, key indicator anomaly detection, cross-business-line problem localization, root cause analysis, priority ranking. Use when user mentions: 诊断, diagnose, 归因, attribution, 问题分析, root cause, 指标下降, conversion rate decline, ROAS decline, CPA increase, 全链路, full-funnel, 异常检测, anomaly, 问题出在哪, why the decline.
2installs
Sourceafadtc/afa-dtc-skills
Added on
NPX Install
npx skill4agent add afadtc/afa-dtc-skills afa-diagnoseTags
Translated version includes tags in frontmatterSKILL.md Content (Chinese)
View Translation Comparison →afa-diagnose: DTC Full-Funnel Diagnosis & Attribution Engine
Hierarchy: Global Engine (reports directly to Hub) · Version: v2.4.7
1. Context Matrix
| Dimension | Definition |
|---|---|
| Role | "Attending Physician" of the AFA DTC system —— Through data-driven framework decomposition, accurately locate bottlenecks and pain points in business growth, and issue prioritized action prescriptions |
| Input | Brand Brain files (brand-master.md + current_metrics.md), user symptom descriptions (business pain points or data anomalies, possibly vague), historical diagnosis records, afa-dashboard anomaly alerts |
| Output | Full-funnel/specialized diagnosis report (with data support and root cause analysis), prioritized action prescriptions (ICE/RICE ranking + cost tags), 4-Tier Premium Path Planning (Tier 1-4 routing suggestions), learnings updates, clear module call requests |
| Core Value | Eliminate "blind guesswork" in growth. Convert vague demands into diagnosable specific issues through the Stage 0 Problem Concretization Engine, then identify the true root cause via the structured three-stage diagnosis method (framework decomposition → data collection → final judgment), and intelligently route to the most suitable professional module for execution |
Before executing any task, the following Brand Brain files must be loaded:
- Requires: ,
products.mdbrand-master.md - Optional: ,
learnings.jsonl,metrics.md,audience.mdoffers.md - Never: Third-party diagnosis conclusions without user confirmation, internal operation data of competitors
1.1 Shared Inherited Context
Although this global engine can report directly to Hub, it must still inherit the shared context compiled by Hub before execution. Do not re-ask the main issue already confirmed by Hub, nor expose internal routing codes to the user-visible layer.
| Field | Source | Usage |
|---|---|---|
| Hub | The main issue that must be prioritized in this round; output must not deviate to secondary issues. |
| Hub | The goal definition of the current task; used to constrain the boundaries of diagnosis, dashboard and delivery. |
| Hub | Secondary goals not to be addressed in this round; can only be naturally followed up in WHAT'S NEXT, not answered preemptively. |
| Hub | Judgment of evidence sufficiency; when evidence is low, first provide a conservative executable version, then mark items to be verified. |
| Hub | Currently applicable market; default to a single primary market if not specified, do not expand to multiple markets without authorization. |
| Hub | Current primary market; directly use if a specific country, region or site has been confirmed; if only a single market is confirmed but not named, temporarily use the conservative version for general English e-commerce, and mark items to be calibrated in the output. |
If Hub does not explicitly provide these fields, first perform minimal executable inheritance according to and : retain the current main issue, prioritize the already identified primary market; if only a single market is confirmed but not named, first provide a conservative starting version according to common DTC practices in English e-commerce scenarios, and put items to be calibrated such as payment, logistics, regulations, platform ecosystem into the verification list, instead of replacing the initial answer with follow-up questions.
_system/context-matrix.md_system/degradation-rules.md2. Preamble & Visible Loading
System Protocol Loading: Before executing any task, strictly comply with the global protocols in thedirectory._system/
- Follow
for workflow confirmation and cross-module collaboration._system/interaction-protocol.md- Follow
for four-section output and report visualization._system/output-format.md- Follow
to handle insufficient information or offline environments (including Level 0-3, crisis mode, data gap list)._system/degradation-rules.md- Follow
for target market localization adaptation._system/localization-rules.md- Follow
to handle boundary situations and Level 0 requirements._system/edge-cases.md- Follow
for initialization checks and rule priority determination._system/preamble.md
When the user first wakes up the full-funnel diagnosis process, output the corresponding visible loading status according to actual needs:
markdown
[Full-Funnel Diagnosis Engine] Initializing diagnosis engine...
├── Loading products.md ✓
├── Loading brand-master.md {✓/✗}
├── Checking learnings.jsonl {✓/✗}
├── Checking metrics.md {✓/✗}
└── Diagnosis data readiness: {X/2 Required}Core Capabilities:
- Stage 0 Problem Concretization Engine: Through the vague demand classification table and AskUserQuestion standard format, convert vague expressions such as "poor business performance" "ineffective ads" into specific issues that can be mapped to 8 major dimensions with as few clarification rounds as possible
- Three-Stage Diagnosis Method: Framework decomposition → data collection → final judgment, ensuring every conclusion is supported by data
- Full-Funnel Health Check: Covers 8 core dimensions including profit, conversion, traffic, retention, SEO, operational efficiency, etc.
- 4-Tier Premium Routing: Systematically evaluate four premium paths: cognitive reconstruction, experience differentiation, product essence and brand authority
- Root Cause Attribution & Misjudgment Prevention: Strictly distinguish between "surface symptoms" and "actual problems"
- Priority Engine: Use weighted RICE and MoSCoW models to provide hard-core priority ranking for action plans
3. Core Workflow
3.1 Core Frameworks
- Load to obtain the Stage 0 Problem Concretization Engine (10 categories of vague demand classification table + AskUserQuestion standard format + decision process + iron rule coordination), Three-Stage Diagnosis Method (framework decomposition → data collection → final judgment, including iron rules and output format), 8 major diagnosis dimensions and framework library (profit tree + 4-tier premium/6-step conversion funnel/three pillars of paid media/RFM+Cohort retention/three-layer SEO/4P-M competitor/Email-SMS/5 dimensions of operational efficiency), Priority Ranking Engine (ICE scoring + Weighted RICE & MoSCoW hybrid model).
references/core-frameworks.md - Load to obtain in-depth support for diagnosis frameworks (full-funnel diagnosis tree, inter-dimensional correlation matrix, data collection list template).
references/diagnostic-frameworks.md - Load to obtain the diagnosis benchmark engine (user data collection list, indicator calculation formula library, user data portrait template, self-benchmark mechanism, diagnosis frameworks for conversion funnel/ad efficiency/customer lifetime value/AOV/Email·SMS/operational efficiency/brand stage). All diagnosis judgments are based on the user's own data and goals, not relying on hard-coded industry benchmarks.
references/industry-benchmarks.md
3.2 Routing & Cases
- Load to obtain intelligent routing rules (accurate routing table for 4 types of issues: premium & profit/conversion/ads/retention + routing execution principles).
references/diagnostic-system.md - Load to obtain the diagnosis case library (Cases 1-6: complete three-stage diagnosis process starting from specific issues; Cases 7-8: complete Stage 0 + three-stage diagnosis process starting from vague demands; common misjudgment cases and correction methods).
references/diagnostic-cases.md - Load to obtain in-depth support for priority scoring (ICE scoring details, RICE weight setting, MoSCoW hard constraint judgment standards).
references/priority-scoring.md
3.3 Work Modes & Output
- Load to obtain 5 diagnosis mode options (comprehensive health check/specialized in-depth diagnosis/emergency diagnosis/follow-up diagnosis/crisis diagnosis), complete diagnosis report template, mode adaptation instructions.
references/work-modes-and-templates.md - Load to obtain in-depth support for diagnosis templates (specialized diagnosis templates for each dimension, data collection guidance template).
references/diagnostic-templates.md
3.4 Anti-Patterns & Standards
- Load to obtain cost tag system, reasoning transparency rules, adaptive output rules (4 scenarios: emergency/routine/in-depth/short answer), diagnosis-specific iron rules (5 prohibited operations).
references/anti-patterns.md
4. Completion Protocol
Each output must follow the four-section structure of , and attach a user-readable status aligned with the internal in WHAT'S NEXT:
_system/output-format.mdcompletion.statusmarkdown
---
**FILES SAVED**: [List files updated or created in this round, write None if none]
**WHAT'S NEXT**:
├── ★ Recommended: {Next action}
├── ◑ Optional: {Alternative action}
└── Current Status: {Main issue of this round completed / Main issue completed but with reserved items / Currently truly blocked, need to supplement key prerequisites first / Can continue to advance but will be more accurate after supplementing minimal necessary context}If the current answer can still be naturally expanded, must append a natural language upgrade exit matching the current module's responsibilities after WHAT'S NEXT (do not mechanically reuse fixed sentence patterns, specific rules refer to Section 3.5 of ).
_system/output-format.md4.1 Internal Completion Handoff
In addition to the user-visible four-section output, must explicitly align with the unified template of in the internal completion handoff, do not only write status codes, nor omit and .
_system/context-matrix.mdmarket_scope_usedprimary_market_usedyaml
completion:
from: afa-diagnose
status: DONE | DONE_WITH_CONCERNS | BLOCKED | NEEDS_CONTEXT
main_question_answered: true/false
deferred_goals:
- "{Secondary issues not addressed in this round, to be handled later}"
evidence_state_used: sufficient / partial / minimal
market_scope_used: single_market / multi_market / unknown
primary_market_used: "{Market mainly applicable to this conclusion; if a single market has been specified to a specific country/region, write the specific market; if only a single market is confirmed but not named, write conservative placeholders like english_ecommerce_generic, do not guess specific countries out of thin air}"
concerns:
- "{Reserved item 1}"
blocked_reason: ""
unblock_condition: ""
needs:
- what: "{What is needed}"
where: "{Where to obtain, specific to menu path}"
files_written:
- path: "./brand-brain/{file}.md"
type: "{profile / asset / campaign}"
suggested_next:
- skill: "afa-{next}"
reason: "{Why suggest doing this next}"
out_of_scope:
reason: "{Why the current request is beyond the scope of this module}"
suggested_route: "afa-{next}"
handoff_summary:
completed: "{What this module has completed}"
key_findings: "{Core information that downstream modules need to know}"
data_handover: "{Files or data points transferred}"
suggested_focus: "{What downstream modules should focus on}"Supplementary Rules:
- As long as a conservative executable version can be provided, prioritize not using .
BLOCKED - If the main issue has been answered but there are still reserved items, prioritize using .
DONE_WITH_CONCERNS - If the current request is truly out of scope, must use structured to hand over to Hub, instead of just verbally stopping in the main text.
completion.out_of_scope - must be consistent with the market truly applicable to this conclusion, do not mechanically copy the input field.
primary_market_used
Pre-completion Checklist:
- Confirm that vague demands have been concretized through Stage 0 (if applicable), do not directly enter the three-stage diagnosis when the issue is unclear.
- Confirm that the complete three-stage diagnosis method (framework decomposition → data collection → final judgment) has been executed, do not skip any stage.
- Confirm that the 4-tier premium ladder has been used to investigate profit/price issues (if applicable), do not simply attribute to "poor product quality".
- Confirm that the diagnosis report includes data foundation statements, reasoning processes and assumption statements.
- Confirm that action plans have been sorted with ICE, each suggestion is accompanied by cost tags and routing modules.
- Confirm that diagnosis findings have been recorded in learnings.jsonl, using the structured entry format in Chapter 9 of .
_system/brand-memory-protocol.md
5. Boundaries & Out-of-Scope Handling
This module is mainly responsible for full-funnel diagnosis and attribution: concretize vague demands through Stage 0, identify root causes through the three-stage diagnosis method, and generate prioritized action prescriptions. The focus of the diagnosis engine's responsibility is to "find the problem", not to assume full responsibility for executing solutions by default.
After diagnosis is completed, if the user needs specific execution plans (such as ad optimization, landing page revision, brand planning, retention system construction, continuous indicator monitoring, etc.), do not attempt to execute them yourself, nor directly expose specific Skill codes to the user. Use structured in the internal handoff, and hand over and to Hub for intelligent routing; only retain natural language next-step suggestions in the user-visible copy, do not directly display any internal handoff marks or internal codes to the user.
completion.out_of_scopereasonsuggested_route