<!-- Generated by mstack from Misbah's Build Like This workflow. Regenerate instead of editing. -->

spec-synthesis

This skill is part of Misbah Khursheed's Build Like This workflow. Thinking, evidence, and explicit trade-offs come before generated output.

Project identity and sources of truth

The repository where this skill is installed is the host project being built. Build Like This is the method used to build it; mstack only installs and reconciles method resources. Do not assume mstack or Build Like This is the product unless project-owned sources explicitly identify this repository as mstack itself.

Use project-owned docs/, decisions, executable code, and tests as sources of truth. .mstack/templates/ are reference scaffolds to copy and adapt into project-owned documents, not product requirements and not a replacement for docs/.

Purpose

Bridge confirmed planning decisions into a testable specification that product-definition, feature docs, or tickets can consume. Prefer project-owned docs over chat residue.

Required inputs

• Confirmed decision ledger from design-grilling or grill-with-docs, plus relevant research and current product/feature docs.
• planning-setup tracker location when the spec will be published as an issue.

If a missing input would materially change the result, state the gap and obtain or discover it before proceeding. Otherwise label the assumption and continue.

Process

1. Refuse to re-open settled decisions; list only gaps that block a publishable spec.
2. Synthesize problem, intended outcome, long user stories with acceptance criteria, actors/permissions, failure states, and out-of-scope items.
3. Check test seams with the user: what will prove the behavior without prescribing file paths or code snippets.
4. Publish to the configured tracker and/or docs/features/<name>.md; mark ready-for-agent only when acceptance criteria are testable.
5. Point write-product-definition or ticket-graph at the published artifact rather than pasting the full chat.

Output contract

• A publishable spec artifact with outcome, stories, acceptance criteria, non-goals, and open risks.
• Tracker or docs path plus readiness label.
• Explicit list of decisions still missing, if any.

Guardrails

• Do not invent acceptance criteria the user did not confirm.
• Do not embed file trees or implementation snippets except for an agreed prototype exception.
• Do not skip planning-setup when the publish target is ambiguous.

Delegation and parallel safety

• Material lifecycle work must delegate at least one bounded specialist lane when subagents are available. Prefer two or more concurrent lanes only for independent evidence gathering, analysis, or non-overlapping file ownership.
• The active lead owns integration and acceptance. Supporting agents do not recursively delegate unless explicitly promoted to lead a named lane.
• Assign distinct outputs and ownership. Serialize shared docs, contracts, schemas, migrations, deployments, external writes, and overlapping file edits.
• When subagents are unavailable, perform the same named specialist passes sequentially and state that constraint instead of implying parallel verification.
• Delegation never grants permission for outreach, consequential external actions, destructive changes, paid resources, or production operations.

End with the evidence gathered, verification performed, and any residual risk or unresolved decision.