session-recall

Rebuild working context from recent sessions, tickets, and live repository state.

SKILL.md

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

session-recall

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

Recover goals, open problems, and next moves when chat memory is gone, using parallel cheap reads and live verification.

Required inputs

  • Recent handoff notes, issues/PRs, error logs, and the current branch.
  • Optional topic filter from the user.

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. Mine recent handoffs, ticket/PR titles, and session notes in parallel with cheap readonly commands.
  2. Verify promising threads against live git status, diffs, and tracker state.
  3. Produce a short capsule: active goal, open problems, relevant pointers, and the recommended next skill.
  4. Prefer links and IDs over long quotations; redact secrets.

Output contract

  • Context capsule with threads, problems, pointers, and next move.
  • Confidence labels where evidence is thin.

Guardrails

  • Do not treat a single transcript as authoritative over the repository.
  • Do not paste secrets or unnecessary personal data into the capsule.
  • Do not start implementation inside recall.

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.