Define and develop plugin mission statements — purpose, values, anti-patterns, and trade-offs. Use when creating a new plugin, auditing an existing plugin's alignment, or providing a reference for the alignment check loop to evaluate decisions against. Produces mission.json with [draft] status and creates a backlog interview task for the human to refine it.
<invocation_args>$ARGUMENTS</invocation_args>
A plugin mission statement is a decision-making anchor, not a feature description. It states what the plugin values, what it refuses to do, and how it resolves trade-offs — enabling AI agents to evaluate alignment without asking the human each time.
| Mission Statement Is | Mission Statement Is Not |
|---|---|
| A decision-making anchor | A feature list or capability overview |
| An explicit anti-pattern registry | A marketing or sales description |
| A trade-off resolution guide | A roadmap or version history |
| A verifiable alignment reference | A technical specification |
mission.json FormatThe file lives at the plugin root (not in ).
.claude/plan/{
"status": "draft",
"mission": "One sentence. What this plugin is trying to be — not what it does.",
"values": [
"Value statement 1 — concrete, verifiable",
"Value statement 2"
],
"anti_patterns": [
"Specific behavior this plugin refuses to do",
"Another explicit refusal"
],
"escalation_triggers": [
"keyword", "another keyword phrase"
],
"trade_offs": {
"correctness_vs_speed": "correctness",
"breadth_vs_depth": "depth",
"explicit_vs_implicit": "explicit"
},
"out_of_scope": [
"Thing that looks related but belongs elsewhere"
],
"interview_backlog_item": "#NNN",
"validated_scenarios": []
}
Field definitions:
status — "draft" until interview completes and human approves; then "active"mission — single sentence; must pass the "bad twin" test (a bad version of this plugin could not claim the same statement)values — observable principles that guide decisions; must be verifiable against behavioranti_patterns — explicit refusals; what this plugin will not do even when askedescalation_triggers — keyword list for fast string-match in alignment checks; no LLM neededtrade_offs — when forced to choose, which side does this plugin takeout_of_scope — things that look adjacent but belong in other pluginsinterview_backlog_item — GitHub issue number of the interview task (added after backlog creation)validated_scenarios — list of known past decisions that this statement correctly predictsThree phases:
mission.json with status: "draft". The [draft] tag signals this is a hypothesis, not a decision.mission.json with human-verified values.validated_scenarios populated; status: "active".These questions surface actual values, not stated ones. Ask them in order.
Q1 — The Non-Negotiable
"What is the one thing this plugin must never sacrifice, even to ship faster?"
Anchors values[0] — the primary principle.
Q2 — The Bad Twin
"What would a superficially similar but wrong version of this plugin do? What makes it wrong?"
Populates anti_patterns. A good mission statement the bad twin cannot also claim.
Q3 — The Trade-off
"When forced to choose between [breadth vs depth / correctness vs speed / explicit vs implicit], which does this plugin choose, and why?"
Ask all three. If the human says "both" — ask "if you could only have one." Answers populate trade_offs.
Q4 — The Removal Trigger
"What would make you remove this plugin from the marketplace entirely?"
Populates the most severe anti_patterns and escalation_triggers.
Q5 — The Anti-Pattern Example
"Give me a specific example of a 'fix' or 'improvement' this plugin should refuse to make, even if asked."
Most useful for alignment checks. Concrete refusals become escalation_triggers keywords.
When invoked (during Phase 0.6 of plugin lifecycle, or standalone):
plugin.json or .claude-plugin/plugin.json, CLAUDE.md if present, SKILL.md filesdiscuss-CONTEXT.md if this is a new plugin creationmission.json with status: "draft". Populate all fields from observed design choices and stated preferences.mission.json to the plugin root directorymcp__plugin_dh_backlog__backlog_add with title "Mission interview: {plugin-name}" and body containing the 5 questions and the current draft mission fieldmission.json with "interview_backlog_item": "#NNN" using the created issue numberAfter interview, validate by running known decisions through the statement. Add each to validated_scenarios:
{
"validated_scenarios": [
{
"decision": "Refused to add blanket noqa suppression to a linting plugin",
"predicted_by": "anti_patterns[0] + escalation_triggers",
"outcome": "correct"
}
]
}
Status becomes "active" when it correctly predicts at least 3 known decisions.
Arguments: <invocation_args/>
<plugin-path> — Draft mission for an existing plugin. Read plugin files, draft mission.json, create backlog interview item.<plugin-path> --interview — Conduct the interview synchronously in this session. Ask Q1-Q5, update mission.json from answers, move to validation.<plugin-path> --validate — Run validation scenarios. Ask human to confirm 3 past decisions, check predictions.The escalation_triggers list is the fast path for alignment checking — pure string matching, no LLM:
escalation_triggers — if any keyword matches, escalate immediatelyanti_patterns with LLM reasoning against mission and valuesanti_patterns or moves away from values, return alignment: LOW with the specific violated principleThe mission statement answers "what would the human say if they were watching?" — codified in advance.