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

feature-planning

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

Create a plan that connects a validated, agreed capability to observable behavior and the smallest safe sequence of engineering changes. This follows feature-design (or an equivalent product decision). It is not plan-mvp: plan-mvp shapes a hypothesis into an MVP experiment, while feature-planning slices an agreed capability for implementation.

Required inputs

• Target user, problem evidence or labeled hypothesis, desired outcome, and non-goals.
• Current behavior and relevant product, architecture, contract, and operational context.
• Constraints on permissions, data, compatibility, rollout, accessibility, reliability, and time.

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. Restate the problem, outcome, evidence, assumptions, and explicitly excluded scope.
2. Describe the end-to-end journey and enumerate success, empty, validation, denial, degraded, and failure states.
3. Define testable acceptance criteria, actors/permissions, state transitions, and contract/data changes before tasks.
4. Map affected modules and external boundaries; identify security, privacy, migration, observability, and rollback needs.
5. Slice delivery vertically so each step proves useful behavior and preserves compatibility; order dependencies explicitly.
6. Define verification at unit, integration, contract, and end-to-end levels in proportion to risk.

Output contract

• Outcome, scope, non-goals, assumptions, and acceptance criteria.
• User-visible state table plus contract, data, permission, and failure impact.
• Ordered vertical slices with affected ownership, tests, rollout/recovery, and completion evidence.

Guardrails

• Do not produce a file-by-file task list before defining behavior and contracts.
• Do not disguise unanswered product decisions as implementation details.
• Do not add speculative platform work without a current acceptance criterion.

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.