Strategy Plan Writing

Strategy & Operations Plan Writing

Write high-quality strategy documents, operations plans (运营策划案), market analysis reports, and business proposals. Covers non-software business domains: tourism/wenlv, retail, services, product launches, marketing campaigns, etc.

Triggers

通用领域触发矩阵

战略/运营策划案覆盖7大领域，25个子场景。

手动触发

Use this skill when the user asks for:

• 运营策划案 / 运营方案 / 营销策划案 / 策略方案
• Business strategy document / business plan / GtM plan
• 全链路分析 (full-chain analysis)
• Market entry strategy / competitive analysis / channel strategy
• Multi-dimensional business analysis across operational dimensions
• Any document that requires: data support, framework design, financial modeling, execution roadmap

Quality Standards (User's Explicit Requirements)

The user has articulated specific quality standards for this class of work. These are NON-NEGOTIABLE:

1. 第一性原则 (First Principles): Ground analysis in root causes and fundamental truths, not surface trends. Question every assumption. The core question: "What is the user/customer actually buying, and why?"

2. 可实践性 (Actionable): Every recommendation must include specific "how" — tools, team size, timelines, budget ranges, SOPs. No vague "consider doing X." If you recommend "AI content production," specify which tools, what workflow, expected output per day.

3. 严谨 (Rigorous): Logical chain must hold. Every strategy recommendation must trace back to a diagnosed pain point or opportunity from the source materials. No unsupported claims.

4. 务实 (Practical): Recommendations must fit the user's actual resource constraints (budget, team size, timeline). If they have a 3-person team, don't propose a 20-person organizational structure. If they have zero ad budget, don't lead with paid acquisition.

5. 有数据支持 (Data-Supported): Use industry benchmarks, conversion rate data, pricing references, market size figures. When exact data isn't available, use reasonable estimates clearly marked as "约" (approximately) or "参考" (reference). Never fabricate precise numbers.

6. 能拿到结果 (Results-Oriented): Every chapter should have measurable outcomes. Include KPI dashboards, milestone checkpoints, and success/failure criteria.

Two-Tier Delivery Pattern (Cold-Start / Complex Launches)

When the user asks for both strategy AND execution in one request (typical for cold-start / new product launch / online matrix planning), split into TWO documents, not one:

v1 — Strategy Plan (策略层):

• Market anchors & industry data
• First-principles analysis
• Core decisions (account strategy, platform selection, team, budget)
• 90-day roadmap at the milestone level
• KPI dashboard

v2 — Execution Plan (执行层):

• Per-platform account setup specs (names, bios, menu structures, POI)
• Content type breakdown with script templates
• 30-day editorial calendar (day-by-day)
• Publishing SOPs and best-time schedules
• Paid promotion strategy (DOU+, 薯条) with phased budgets
• Comment/interaction scripts and conversion funnels
• Cross-platform coordination workflow (一鱼多吃)
• Day 1-7 launch checklist

Why split: A single document that covers both strategy and per-platform execution detail becomes unreadable (>20K words) and neither layer gets done well. The strategy document is for decision-makers; the execution document is for operators. Two audiences, two docs.

Naming convention: {主题}_策划案_v1.md + {主题}_各平台执行方案_v1.md

Document Structure Pattern

For multi-dimensional business analysis, use this proven structure:

1. Market Overview & Data Anchors (宏观数据锚点)
2-12. Full-chain dimension-by-dimension analysis
13. Execution Roadmap + KPIs + Budget

Each dimension chapter should contain:

• Diagnosis: What's the current state / problem from source materials
• Strategy: What to do about it
• Tactics: Specific actions, tools, workflows
• Metrics: How to measure success
• Pitfalls: What could go wrong and how to mitigate

Research Workflow

When the user provides source materials (meeting notes, transcripts):

1. Deep-read all attachments first — Extract all strategic decisions, pain points, constraints, and data points. These are your primary source.

2. Attempt web research for supporting data — Market size, industry benchmarks, competitor examples, case studies. Use browser search or terminal curl. BUT: in WSL environments, Bing China often returns garbage results for Chinese business queries, and Google/DuckDuckGo may timeout behind proxies.

3. Pivot to training knowledge when search fails — If 2-3 search attempts yield nothing useful, STOP searching. Your training data contains substantial industry knowledge. Clearly mark training-knowledge data as "约" or "参考" rather than cited sources. The quality of your domain knowledge + the user's source materials is sufficient for a high-quality plan.

4. Never spend >5 minutes on research dead ends — If searches are not productive, pivot immediately to writing. The user's deadline matters more than perfect citations.

Deliverable Format

• Simple requests: single comprehensive markdown file
• Cold-start / complex launches: two-tier (strategy v1 + execution v2), see Two-Tier Delivery Pattern
• Use tables for data-heavy sections (market data, pricing models, team configs, KPI dashboards)
• Include an executive-level table of contents
• Save to the workspace directory with clear naming: {主题}_策划案_v{版本号}.md

Linked Resources

• references/china-research-pitfalls.md — WSL search workarounds for China-market business research
• references/execution-plan-template.md — Per-platform execution plan structure template (v2 tier)
• templates/strategy-plan-template.md — Starter template for strategy/operations plan documents

Common Pitfalls

1. Over-relying on search for data validation — In Chinese business contexts, web search often fails due to proxy/network issues. Trust your training knowledge when searches fail. Mark estimates honestly.

2. Making the plan too abstract — "Build a brand" is useless advice. "Post 3 Douyin videos/day targeting 25-35yo parents, measure CTR after 30 days, aim for >3% engagement rate" is actionable.

3. Ignoring resource constraints — Always ask: "Can they actually do this with their current team/budget?" If not, phase it.

4. Forgetting the "first principles" test — After writing each section, ask: "Would this still be true if all the industry jargon were stripped away?"

5. Over-structuring — Not every section needs sub-sections. If a dimension only needs 2 paragraphs and a table, that's fine. Don't inflate to fill space.

6. Over-cramming strategy + execution into one document — When the user needs both strategic decisions (账号策略, platform selection, budget) AND per-platform execution detail (script templates, 30-day calendars, SOPs), a single doc becomes bloated and unreadable (>20K words). Split into v1 (strategy, for decision-makers) and v2 (execution, for operators).