高级输入/输出、领域与通信模式

Decompose ${input:subject} into a normalized relational model.
This is a mandatory first step before any code generation.

1. Identify Entities: List all distinct real-world objects or concepts
2. Classify Each Entity:
   - Lookup/Dimension tables: Relatively static reference data
   - Fact/Transaction tables: Event-driven records that reference lookups
3. Define Relationships: For every pair of related entities, specify:
   - Relationship type: one-to-one, one-to-many, or many-to-many
   - The foreign key column and which table it references
4. Determine Generation Order: Build a dependency graph so parent/lookup
   tables are generated before child/fact tables
5. Aim for 3-7 tables depending on domain complexity.

| Subject | Entities (Tables) | Key Relationships |
| Hospital patient records | Patients, Doctors, Departments, Visits, Diagnoses | Visits->Patients (FK) |
| E-commerce sales | Customers, Products, Categories, Orders, OrderItems | Orders->Customers (FK) |

Generate a database schema for ${input:subject}.
Create all necessary tables with appropriate columns and relationships.
Make sure to include primary keys and foreign keys.

Category comparison → bar or horizontal_bar (Plotly)
Value over time → time_series (Plotly)
Distribution → histogram or box_plot (Plotly)
Part-to-whole (2-7 categories) → pie (Plotly)
Distribution across groups (20+ points/group) → violin (Plotly)
Change decomposition (3-20 factors) → waterfall (Plotly)

## Two-Variable Routing
Two numeric columns?
  +-- Meaningful third numeric (size)? 5-100 entities? → bubble_scatter
  +-- Population shape/density? Row count >500? → density_2d
  +-- Individual points with selection? → scatter_brush (D3)
  +-- Grouped by category?
        +-- >20 pts/group? → violin
        +-- <20 pts/group? → box_plot

## Anti-Patterns — Avoid:
1. Pie chart with more than 7 slices — becomes unreadable
2. 3D charts — distort perception of values
3. Dual y-axes — confuse readers about axis mapping
4. Truncated y-axis on bar charts — exaggerates differences
5. Too many series on one line chart — >7 lines become spaghetti
6. Rainbow color palettes — lack perceptual ordering, fail for colorblind

Choose the best chart type for the data.
Options: bar, line, pie, scatter, histogram, box plot, violin, waterfall.
Pick whichever seems most appropriate for the user's data.

### Step 1: Understand the Report

Ask about context before selecting charts:
- Audience — who reads this? (technical team, management, external stakeholders)
- Purpose — what kind? (investigation, monitoring, comparison, status update)
- Key questions — what should the reader learn?

These answers drive chart selection and level of detail:
- Audit trail needs → chart_table_query (shows visualization + raw query results)
- Summary KPI metrics → kpi_query (headline numbers with source query)
- Investigation findings → narrative (multi-paragraph explanatory text)

### Step 1: Create the Report

Generate a report with appropriate charts and tables.
Include relevant KPIs and findings.
Use a professional tone suitable for business stakeholders.

This is NOT classic rubber duck debugging where you sit silently.
You are a full research partner who:
- Actively investigates the codebase using tools (Grep, Read, Task agents)
- Asks informed questions based on what you discover
- Guides them to insights through interactive exploration

### Investigation Loop
1. Research Before Asking
   - Evaluate relevance: which leads are "hot trail" vs "cold trail"?
   - Follow hot trail (1-3 most relevant sources)
   - Acknowledge cold leads: "I also see X, Y, Z — should I explore those?"
2. Brief Analysis (1-3 sentences)
3. Ask a Thoughtful Question (2-4 specific options based on research)
4. Process the Answer

Session guard: After 8-10 questions without converging, check in:
"We've explored quite a bit — should we keep digging or move forward?"

Help the user debug their issue using the Socratic method.
Ask clarifying questions to understand the problem.
Guide them toward the solution without giving the answer directly.
Use available tools to read code when needed.

1. Read <knowledge base>/INDEX.md — lightweight index with keywords & descriptions
2. Match user's question against index entries' keywords/descriptions
3. Only then read matching knowledge base file(s) in full
4. If no match: fall back to Grep across all .md files

INDEX.md structure:
| File | Data Source | Keywords | Description |
| get-active-action-items.md | GetActiveActionItems() | SFI, action items, person | Individual SFI queries |
| s360-active-action-items.md | ComplianceDashboard ActiveActionItems | SFI, action items, overdue | Aggregate SFI tracking |

Per-source disambiguation (inside each KB file):
| Need | Use |
| Individual action items for a person | GetActiveActionItems() (this) |
| Aggregated counts by KPI/wave | SFIFactTable or ComplianceDashboardSFISnapshot |
| Org-leader-level rollups | ActiveActionItems (turbologsna) |

Read all knowledge base files at the start of every conversation.
Match the user's question against the full content of each file.
If multiple files match, combine their guidance into a single answer.

### Problem Statement (1-5)
| Score | Heuristic Signals |
| 1 | No section matching "problem", "background", "overview", "context" |
| 2 | Section found but <30 words, no user focus |
| 3 | Has user focus (mentions user/customer/developer) OR >80 words |
| 4 | Has specific numbers OR research evidence, AND user focus |
| 5 | Has research evidence AND >=2 specific numbers AND user focus |

Research evidence patterns: "interviewed N", "surveyed N", "research shows",
"based on data/research/feedback", "support ticket", "NPS score"

Scoring philosophy:
- AI-generated boilerplate caps at 2-3; real substance required for 4-5
- Near-perfect (48-55) requires: user research, competitive analysis, metrics with baselines

### Problem Statement (1-5)
| Score | Description |
| 1 | Poor — missing or very weak problem statement |
| 2 | Below average — problem statement lacks depth |
| 3 | Adequate — reasonable problem statement |
| 4 | Good — strong problem statement with clear user focus |
| 5 | Excellent — comprehensive, evidence-backed problem statement |

EAGER TOOL INVOCATION (CRITICAL)
Do NOT wait until the end to create plan items. Instead:
1. Create plan shell IMMEDIATELY when user provides product name
2. Create epics AS THEY EMERGE during discussion
3. Add features AS THEY'RE DEFINED

Why: Each tool call triggers a real-time WIP spinner in the plan tray,
giving immediate visual feedback that the plan is taking shape.

You CAN and SHOULD create items while still asking clarifying questions.

Gather all requirements from the user first.
Once you have a complete picture, create the plan with all epics and features.
Make sure everything is finalized before making any tool calls.

When source_type is "kusto", run pattern detection:

| Pattern Signal | Chart Type | Confidence |
| AD_score/AD_flag columns | time_series with anomaly highlights | high |
| Percentile columns (p50, p95, p99) | time_series with threshold highlights | high |
| render areachart in query | area or stacked_area | 0.9 (ADX hint) |
| Grouped continuous data (>50 rows) | violin (requires 20+ pts/group) | medium |
| Mixed pos/neg deltas (3-20 rows) | waterfall | medium |
| Source/target columns (<50 rows) | mermaid diagram | low |

Present ALL matches with confidence. Auto-populate from highest match.
User confirms, overrides, or rejects before proceeding.

Analyze the data and choose the best chart type.
Consider the number of rows and columns to determine
whether a bar chart, line chart, or scatter plot is appropriate.

### Passive voice detection
Can you add "by zombies" after the verb and it still makes sense? → passive

### Jargon substitution (26 entries)
| Instead of | Use |
| commence | start, begin |
| comply with | keep to, follow |
| ensure | make sure |
| utilise | use |

### Nominalisation detection
Words ending in -tion, -sion, -ment, -ence, -ance with a simpler verb inside:
| Avoid | Use |
| We made an arrangement | We arranged |
| We reached an agreement | We agreed |

### Quality targets
- Average sentence length: 15-20 words
- Active verbs: ≥80%
- Zero remaining jargon with simpler alternatives

Write in plain English. Avoid jargon and complex language.
Use short sentences and active voice where possible.
Keep the tone professional but accessible.

| Source Surface | Target Surface | Issues | Resolution |
| Teams (v1.5+) | Outlook (v1.4) | Table, Carousel unsupported | transform_card with downgrade to 1.4 |
| Generic (v1.6) | Windows (v1.3) | Action.Execute, Table | transform_card with downgrade to 1.3 |

Bounded retry:
- Max 2 retry cycles for fix-and-revalidate loops
- MCP server unreachable → do NOT attempt to hand-write card JSON
- Tool-call budget: max 3 primary calls per user request

Ensure the card is compatible with the target platform.
If validation fails, fix the card and try again.
If the MCP server is unavailable, generate the card JSON directly.

## Overlap Resolution (specificity-first)

1. Specific product area named (ProductA, ProductB, ProductC) → domain plugin
2. "Flight" + "ProductC bug" → productc-investigation (has flight classification rules)
   "Flight" standalone → flight-investigation
3. General Excel telemetry → kql-reference
4. Bug ID mentioned → classify by tag/title pattern:
   - BugTracker/Triage → fetch-bug
   - ProductC → productc-investigation
   - Unknown → ask user
5. "Pipeline" → "CI/CD health" vs "ADF query" → ask if unclear
6. Still ambiguous → present top 2-3 candidates and ask user to pick

If target plugin not installed:
"The {domain} capability requires {plugin-name}.
Install with: /plugin install {plugin-name}@marketplace"

Route the user's request to the most relevant plugin.
If the request mentions a product name, use that product's plugin.
If unclear, ask the user which plugin they want.