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
Added on

NPX Install

npx skill4agent add afadtc/afa-dtc-skills afa-diagnose

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

DimensionDefinition
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
InputBrand 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
OutputFull-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 ValueEliminate "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.md
    ,
    brand-master.md
  • Optional:
    learnings.jsonl
    ,
    metrics.md
    ,
    audience.md
    ,
    offers.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.
FieldSourceUsage
main_question
HubThe main issue that must be prioritized in this round; output must not deviate to secondary issues.
goal
HubThe goal definition of the current task; used to constrain the boundaries of diagnosis, dashboard and delivery.
deferred_goals
HubSecondary goals not to be addressed in this round; can only be naturally followed up in WHAT'S NEXT, not answered preemptively.
evidence_state
HubJudgment of evidence sufficiency; when evidence is low, first provide a conservative executable version, then mark items to be verified.
market_scope
HubCurrently applicable market; default to a single primary market if not specified, do not expand to multiple markets without authorization.
primary_market
HubCurrent 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
_system/context-matrix.md
and
_system/degradation-rules.md
: 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.

2. Preamble & Visible Loading

System Protocol Loading: Before executing any task, strictly comply with the global protocols in the
_system/
directory.
  • Follow
    _system/interaction-protocol.md
    for workflow confirmation and cross-module collaboration.
  • Follow
    _system/output-format.md
    for four-section output and report visualization.
  • Follow
    _system/degradation-rules.md
    to handle insufficient information or offline environments (including Level 0-3, crisis mode, data gap list).
  • Follow
    _system/localization-rules.md
    for target market localization adaptation.
  • Follow
    _system/edge-cases.md
    to handle boundary situations and Level 0 requirements.
  • Follow
    _system/preamble.md
    for initialization checks and rule priority determination.
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:
  1. 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
  2. Three-Stage Diagnosis Method: Framework decomposition → data collection → final judgment, ensuring every conclusion is supported by data
  3. Full-Funnel Health Check: Covers 8 core dimensions including profit, conversion, traffic, retention, SEO, operational efficiency, etc.
  4. 4-Tier Premium Routing: Systematically evaluate four premium paths: cognitive reconstruction, experience differentiation, product essence and brand authority
  5. Root Cause Attribution & Misjudgment Prevention: Strictly distinguish between "surface symptoms" and "actual problems"
  6. 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
    references/core-frameworks.md
    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).
  • Load
    references/diagnostic-frameworks.md
    to obtain in-depth support for diagnosis frameworks (full-funnel diagnosis tree, inter-dimensional correlation matrix, data collection list template).
  • Load
    references/industry-benchmarks.md
    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.

3.2 Routing & Cases

  • Load
    references/diagnostic-system.md
    to obtain intelligent routing rules (accurate routing table for 4 types of issues: premium & profit/conversion/ads/retention + routing execution principles).
  • Load
    references/diagnostic-cases.md
    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).
  • Load
    references/priority-scoring.md
    to obtain in-depth support for priority scoring (ICE scoring details, RICE weight setting, MoSCoW hard constraint judgment standards).

3.3 Work Modes & Output

  • Load
    references/work-modes-and-templates.md
    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.
  • Load
    references/diagnostic-templates.md
    to obtain in-depth support for diagnosis templates (specialized diagnosis templates for each dimension, data collection guidance template).

3.4 Anti-Patterns & Standards

  • Load
    references/anti-patterns.md
    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).

4. Completion Protocol

Each output must follow the four-section structure of
_system/output-format.md
, and attach a user-readable status aligned with the internal
completion.status
in WHAT'S NEXT:
markdown
---
**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.md
).

4.1 Internal Completion Handoff

In addition to the user-visible four-section output, must explicitly align with the unified template of
_system/context-matrix.md
in the internal completion handoff, do not only write status codes, nor omit
market_scope_used
and
primary_market_used
.
yaml
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
    completion.out_of_scope
    to hand over to Hub, instead of just verbally stopping in the main text.
  • primary_market_used
    must be consistent with the market truly applicable to this conclusion, do not mechanically copy the input field.
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
completion.out_of_scope
in the internal handoff, and hand over
reason
and
suggested_route
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.