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

session-handoff

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

Preserve pointers, decisions, and next actions across context limits while leaving durable truth in the repository.

Required inputs

• Current goal, branch, ticket/spec pointers, decision ledger, verification already run, and blockers.
• Configured handoff location from planning-setup, or a path outside durable product docs when unset.

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. Summarize outcome sought, done versus pending, and the single next action.
2. Prefer pointers (paths, ticket IDs, ADR numbers, commit SHAs) over pasted file contents.
3. List suggested skills or prompts for resume; redact secrets, tokens, and unnecessary personal data.
4. Write the handoff artifact; do not dump it into product.md or architecture.md.
5. Stop without starting new implementation work.

Output contract

• A handoff note with goal, pointers, verification, risks, and next action.
• Explicit resume skill suggestion (usually session-pickup).

Guardrails

• Do not store credentials, prompt bodies with secrets, or production data dumps.
• Do not treat the handoff as a source of truth over docs/, code, and tickets.
• Do not open PRs or deploy as part of handoff.

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.