mstar-strategy(全局战略方向)

SkillDocs & knowledge

Morning Star global strategic direction, creates and maintains `STRATEGY.md` (a project-level strategy document) as the upstream anchor for brainstorm/plan. Defines product vision, technical direction, non-goals, and decision principles. Triggered by: project initialization, changes to directional

Use mstar-strategy(全局战略方向) in Claude, ChatGPT or Ahel Desktop

Free. Sign in, add mstar-strategy(全局战略方向) and connect your AI. About a minute.

Also: Claude Code · Cursor · Codex

Then ask your AI: use the mstar-strategy(全局战略方向) skill

Details

Instructions available. Your AI can read the instructions. Execution depends on the setup they require.

Add Ahel to your AI once: Claude, ChatGPT, Cursor, Claude Code or Codex. Then ask it to use this.

mstar-strategy(全局战略方向)Start free

What this skill tells your AI

The instructions your AI receives, as published by btspoony/mstar-harness in skills/mstar-strategy/SKILL.md and read by Ahel’s review.

Load order

Read mstar-harness-core first. Path symbols → mstar-conventions. On conflict, mstar-harness-core wins.

Purpose

STRATEGY.md is the project's upstream anchor — a concise declaration of what the project is, where it's going, and what principles guide decisions. It is read as grounding by brainstorm, plan, and ideation phases so strategic choices flow into every feature.

Without a strategy document, decisions are made in isolation — each plan misses the larger context.

产物存储位置

SSOT: mstar-conventions/references/artifact-storage-paths.md。STRATEGY.md → <repo-root>/STRATEGY.md(与 .git/、AGENTS.md 同级)。禁止放入 {HARNESS_DIR}、docs/ 或任何子目录。

When to use

TriggerExample
Project initialization"Create STRATEGY.md for this new project"
Directional change"We're pivoting from monolith to microservices"
PM requests alignment"Check if this plan aligns with our strategy"
Periodic review"Review and update STRATEGY.md"

STRATEGY.md structure

A good strategy document is opinionated and concise. It should fit in one screen of reading.

Required sections

# Strategy

## Vision
<1-2 sentences: what the project aims to become>

## What we build
<Core product/users/use cases>

## What we don't build
<Explicit non-goals — as important as goals>

## Guiding Principles
- <Principle 1>
- <Principle 2>
- <Principle 3>

## Technology Direction
<Key tech choices and rationale>

## Decision Log
<Major past decisions with context — why, not just what>

Engine check (when available): run mstar lint <STRATEGY.md> (or import { lintStrategySections } from "@mstar-harness/engine" in a host hook) to check the six required sections above (Vision, What we build, What we don't build, Guiding Principles, Technology Direction, Decision Log). On fail -> do not proceed; fix and re-run. Skill text below remains authoritative when the runtime is absent.

Optional sections

  • Current Focus — what the team is working on now
  • Risks & Mitigations — known strategic risks
  • Competitive Context — what alternatives exist and how we differ

Creating STRATEGY.md

Creating and maintaining STRATEGY.md follows the project knowledge bootstrap: mstar-compound-refresh → references/project-knowledge-bootstrap.md Phase 2 (Distill STRATEGY.md) — survey context → interview → draft/review → stale/partial/current handling. The six-section structure and the engine check above stay authoritative here.

Interview (ask PM the 5 questions one at a time)

  1. "What is the one-sentence vision for this project?"
  2. "Who are the primary users and what do they need most?"
  3. "What are you explicitly NOT building? What's out of scope permanently?"
  4. "What 2-3 principles should guide every technical decision?"
  5. "What technology bets have you made, and why?"

Maintenance

Review triggers: after a major architectural decision, when a plan introduces a new technology stack, or quarterly (PM-scheduled). Update rules: be decisive about direction changes (replace, don't keep old strategy alongside new); log decisions with context (why, not just what); keep it current — stale strategy is worse than no strategy.

STRATEGY.md vs other docs

DocumentPurposeAudience
STRATEGY.mdProduct/technical direction, principles, decisionsPM, architect, all implementers
AGENTS.mdRepo maintenance policy, conventionsContributors and agents
CONCEPTS.mdDomain vocabularyAnyone reading/writing project docs
Plans in {PLAN_DIR}/Feature-level implementation planImplementers, reviewers

NOT to do

  • Do not write STRATEGY.md as a novel — it should be scannable
  • Do not include implementation details or file paths
  • Do not create without PM/architect input (ask the questions)
  • Do not keep outdated strategy as "historical reference" — git preserves it
  • Do not conflate strategy (direction) with conventions (how-to)

Workflow

主链:创建/维护(survey → 访谈 = 五问 → draft/review → 更新/替换/跳过)细节 → mstar-compound-refresh references/project-knowledge-bootstrap.md Phase 2。作为 brainstorm / plan 的上游锚点被引用。

Evidence

正确结果 = <repo-root>/STRATEGY.md 通过 lintStrategySections 六节检查(Vision / What we build / What we don't build / Guiding Principles / Technology Direction / Decision Log,mstar lint <STRATEGY.md>),一屏可读完,且 Decision Log 记录的是理由而非仅结论。

References

  • 迭代级战略对齐(iteration-start §1.1 读 STRATEGY.md)→ mstar-iteration
  • 知识维护 / bootstrap(战略变更后的知识对账)→ mstar-compound-refresh
  • 路径符号与产物存储 SSOT → mstar-conventions

Signals

GitHub stars
62
Forks
4
Last commit
Oct 2026
Advanced
Item type
skill
Key
mstar-strategy
Source
github.com/btspoony/mstar-harness