mship context: add --for <audience> and --kind <type> for audience-shaped output

[atomikpanda]

Problem

mship context emits task-aware state for a single default audience (general consumption). The subagent-driven-development flow dispatches multiple downstream audiences — implementer subagents, spec-compliance reviewers, code-quality reviewers, human readers — and each wants a DIFFERENT shape of the same underlying task state.

Today this shaping lives in hand-rolled prompt templates inside the subagent-driven-development skill. The skill hard-codes boilerplate (worktree path, cwd discipline, commit rules) that mship's own state knows authoritatively. The duplication drifts.

Proposal

Extend mship context with audience- and kind-specific rendering. No new command — mship context already emits task-aware output; we just shape it per audience.

mship context --for claude-code
mship context --for codex
mship context --for human
mship context --for reviewer --kind spec
mship context --for reviewer --kind code-quality

Each audience gets the same factual base payload plus an audience-specific instruction block:

• claude-code / codex — implementer framing: "work from <worktree>, never commit to main, commit via mship commit, journal via mship debug hypothesis when investigating."
• human — prose summary for a developer reading the task.
• reviewer --kind spec — review-for-spec-compliance framing: "verify the implementation matches the task description and plan; flag over/under-building."
• reviewer --kind code-quality — "inspect the diff for maintainability, naming, test quality, regressions."

Strictly factual, no inference

The output MUST NOT include inferred fields:

• No "current hypothesis" beyond what's verbatim in the journal.
• No "next recommended action" — that's the agent's job, not mship's.

The audience-specific block contains factual INSTRUCTIONS for that audience, not synthesized SUMMARIES of task state. State is quoted verbatim from the journal, breadcrumbs, worktree metadata.

Suggested payload shape (JSON)

{
  "task": "fix-auth-timeout",
  "resolved_via": "cwd",
  "phase": "dev",
  "repos": [
    {"name": "api", "worktree": "api/.worktrees/feat/fix-auth-timeout"}
  ],
  "recent_journal_entries": [...],
  "open_debug_thread": {
    "hypotheses": [...],
    "ruled_out": [...]
  },
  "test_evidence": {...},
  "diff_range": {"base": "main", "head": "feat/fix-auth-timeout"},
  "audience": {
    "for": "reviewer",
    "kind": "spec",
    "instructions": "Verify the implementation matches ..."
  }
}

TTY rendering: markdown-ish text block for humans and cat-friendly inspection.

Why this is the right substrate move

• Audience shaping is real value (the subagent-driven-development skill already needs it).
• Keeps factual/methodology split clean — mship emits state; agent consumes and acts.
• Lets the skill drop its hand-rolled prompt templates in favor of mship context --for reviewer --kind spec.
• Interoperable: external tooling that doesn't know about mship's skill can still request the context for its audience.

Out of scope

• No new mship handoff command — this obsoletes the need for one while staying substrate-level.
• No inference of hypotheses or next actions.
• No LLM calls.

Related

• Closes gap acknowledged during the 2026-04-24 design feedback discussion.
• Builds on mship context: one-shot agent-readable JSON of current workspace state #50 (closed — original mship context).
• Integrates with mship dispatch: agent-agnostic subagent launch into an mship worktree #52 (closed — mship dispatch).