define-mission

Skill: Define Mission

Role: First layer of the strategy chain, defines the fundamental purpose of the project's existence WHAT: A single mission statement (1–3 sentences, stating only "why it exists") HOW: Elicit the purpose from README/docs/users, confirm with the user, then write to the agreed path Distinction: Vision (future state) → define-vision; metrics → define-north-star; goals → design-strategic-goals

Purpose

Define and record the mission: the enduring reason the project or organization exists. The mission statement answers "why does this exist?", focuses on outcomes (the purpose we serve) rather than implementation (how we do it or what we build), and remains stable across roadmap or feature changes.

Core Objective

Primary objective: Generate a single, user-confirmed mission statement and persist it to the agreed path.

Success criteria：

1. ✅ Mission statement exists: 1–2 sentences (3 at most), stating only the fundamental purpose
2. ✅ User explicitly approves ("approved", "looks good", etc.)
3. ✅ Written to the agreed path (default docs/project-overview/mission.md, overridden per project norms)
4. ✅ Does not mix in vision, metrics, goals, milestones, or implementation details
5. ✅ Wording is stable: independent of features or timelines

Acceptance test: Can a new team member understand why the project exists by reading only the mission?

Scope boundaries

This skill is responsible for: Eliciting the fundamental purpose; drafting a 1–2 sentence mission; confirming with the user; writing to the agreed path.

This skill is not responsible for(hand off to the designated skill):

• Vision → define-vision
• North-star metric → define-north-star
• Strategic goals → design-strategic-goals
• Milestones/roadmap → define-roadmap

Handoff point: After mission approval → recommend define-vision。

Use cases

• Define "why we exist" for a new project or during a strategy refresh
• The team has inconsistent understanding of direction and needs a single source
• Starting point of the strategy chain (mission → vision → north-star → goals → roadmap)

Behavior

Execution：

1. Load context: project name, domain, existing understanding of the purpose (README, existing docs, user description)
2. Elicit: for whom? What fundamental problem does it solve? Why is it worth doing?
3. Draft the mission statement (1–2 sentences, purpose only, no future state/metrics/goals/features)
4. User confirms; if the candidate contains buzzwords or implementation details, prompt for a rewrite
5. Persist to the agreed path; must confirm before overwriting an existing file

Inputs and Outputs

Input: Project identifier; existing understanding of the purpose (from README, docs, or the user).

Output: Mission statement Markdown document; for the path see frontmatter output_schema.path_pattern; lifecycle living.

Constraints

• MUST NOT Include vision, metrics, goals, milestones, features, or implementation details in the mission statement
• MUST NOT Overwrite an existing mission.md without user confirmation
• MUST Apply YAGNI: the statement is the core; add optional sections ("for whom", "what problem it solves") only when truly needed

Anti-patterns

✅ Correct: outcome-focused

Input: README says "We built a CLI that supports YAML configuration, rollback, and audit logs" Mission draft: "We exist to give teams a reliable, auditable way to deploy, with rollback and a clear history."

Why it is correct: Focuses on purpose (reliable deployment), does not list features (YAML, CLI).

❌ Incorrect: mixing in features or future state

Incorrect draft: "We built a CLI that supports one-click deployment, and by 2027 will achieve the industry's fastest rollback."

Problem: Lists features ("one-click CLI") and metrics/future state ("fastest by 2027"). Features belong in product documentation, and future state belongs in the vision.

Examples

Example 1: Mission only, separate from vision

Context: The user says, "Our deployment tool needs a mission; we'll think about the vision later."

Process: Elicit who (engineering team), the problem (manual deployment is error-prone), and why (reliability, safety). Draft: "We exist to give engineering teams a single, reliable way to deploy services from code to production, minimizing manual steps and maximizing safety." User confirms → write to docs/project-overview/mission.md。

Example 2: A mission already exists, request to rewrite (edge case)

Context: The existing mission.md contains a product feature description.

Process: Read the existing version and identify the feature description parts. Extract the purpose: why do customers need this product? Draft a concise version (purpose only). User confirmation is required before overwriting; keep the old version in git history for traceability.

AI refactoring instructions

Problem: The mission statement contains future state or metrics

Identify: The statement contains "by YYYY", "achieve X% improvement", "become the fastest/largest", etc.

Correct：

1. Identify the future state/metric fragment
2. Prompt the user: "This part belongs to the vision or north star; it is recommended to remove it from the mission"
3. Rewrite as a pure purpose statement
4. Recommend running define-vision or define-north-star to take on the removed content

Problem: The mission statement lists features

Identify: The statement contains "We built X", "includes A, B, C features", etc.

Correct: Rewrite "We built X" as "We exist to Y", converting the feature perspective into a purpose perspective.

Self-check

• Mission statement is 1–2 sentences (at most 3 sentences), purpose only
• User has confirmed
• Written to the agreed path
• No vision/metrics/goals/milestones/features mixed in
• Wording is independent of any timeline