mstack

Mstack

Select the matching playbook and briefly name it. Playbooks define procedures; principles guide decisions. Load supporting files only as needed, resolving relative links from the containing file.

Track the playbook’s completion conditions in a checklist. If no playbook fits, define a task-specific checklist with an explicit deliverable and stopping condition.

For delegation or independent review, read orchestration.

If an explicit @mstack invocation cannot load this entry, report that rather than substituting another skill.

Playbooks

Request	Playbook
New or changed behavior	Feature
Repair a reported defect	Bug fix
Behavior-preserving restructuring	Refactoring
New proposal, sketch or spec	Planning
Refine an existing proposal	Spec refinement
Implement a spec	Spec implementation
Read-only investigation of code or architecture	Investigation
Prototype or visual-parity work	Prototype
Performance measurements, fixes, or hillclimbing	Performance
Diagnose a live symptom or captured trace	Forensics
Independent review or blast-radius analysis	Review
Architecture, competing designs, or partitioned exploration	Exploration
Publish, rewrite, triage, fix feedback, inspect checks, or monitor	PR workflows
Rebase a PR or tidy merged branches and worktrees	PR workflows
Explicit stack or merge	Advanced delivery
Long active-session task or project-scale run	Autonomous run
Keep or audit a reviewable decision trail	Decision trail
Resume prior work	Pickup
Hand off or pause work	Pause
Create a project verification skill	Create
Maintain a project verification skill	Maintain
Stress-test a proposal through questions	Grilling
Clarify domain terms or record a glossary/decision	Domain modeling
Explain with a diagram or code-shape sketch	Show me
Explain in HTML with large visuals and minimal text	Big pictures, little words
Walk a reader through a change or data model as a shared tour	Tour
Assess complexity without changing code	Show complexity
Review recent work and live state	Recall
Retro the current session for skill lessons	Reflect
Summarize progress in the current conversation	Catch up
Clean up the scoped change (code, prose, comments)	Code cleanup
Improve prose	Prose cleanup
Review comment value	Comments
Find, apply, or survey project coding standards	Coding standards
Capture lessons about project code as rules or checks	Capture
Explain mstack usage or dependencies	Help

Investigation

Establish the question and the decision it informs. Remain read-only unless the user separately requests an artifact or implementation.

• Runtime mechanics and ownership: use how.
• Design rationale and historical constraints: use why.
• Choosing between design options: use Architecture, not Why.
• Timing trends, slow tests, and benchmarks: use performance, read-only until implementation is approved.
• A teaching conversation: use teach.
• Essential versus accidental complexity: use show-complexity.

Trace the important path, inspect material failure cases, and cite the actual source. Delegate independent deep evidence gathering when useful. Stop once the question has a supported answer or a deciding fact is explicitly unavailable. Recommend a next action only when it follows from the findings; an investigation does not automatically become a prototype, refactor, or PR.

Shared rules

• Scope: Mstack applies to the invoked task. The selected playbook defines its work and stopping condition; reading another file supplies guidance, not authority to start another workflow. Explicit user instructions and repository rules govern the task. Preserve unrelated work and the selected delivery branch. A branch whose PR has merged or closed is no longer a delivery branch.
• Approval: Implementation, including code-writing experiments, requires an approved sketch or spec. Reuse an agreed sketch, spec, or feedback fix; seek renewed approval when new evidence materially changes the outcome. Read-only investigation, requested planning, and diff inspection need no implementation approval. Keep experiments in isolated, explicitly disposable targets. Before writing code, find and apply project standards.
• Delivery: Approved coding work starts in a prepared workspace. Approved coding playbooks authorize scoped commits, pushes, one PR, and required-CI repair. Ordinary delivery stops before merging. Stacks and merging require explicit requests.
• Completion: Support completion claims with observed evidence against the requested outcome; use verification for implementation and review. Report unmet requirements and unavailable or unrun checks. When blocked, preserve a resumable state and seek help rather than changing the goal or silently weakening a requirement.

Principles

Read relevant principles before applying them within the task's scope. Cite each principle that materially changed a decision by name and link, explaining the choice it changed.

When deciding	Read
Core data, states, signatures, or ownership	Model the domain
Validation, errors, framework or network adapters	Boundary discipline
Refactoring, abstraction, deletion, or reader burden	Minimize reader load
Integrating a requirement or repeating failed fixes	Question the premise
User-visible behavior and product tradeoffs	Experience first
Novel designs with consequential uncertainty	Explore alternatives
Declaring a task complete	Prove it works
Designing or judging tests	Test behavior
Benchmarks, performance claims, or eval scores	Explain the number
Multi-step work, commits, migrations, or stacks	Verifiable units
Parallel writers or shared mutable state	Separate ownership
Large evidence, exploration, or handoffs	Guard context
Retryable commands and partial failure	Idempotent operations
Recurring mistakes or repeated manual work	Encode lessons

Tools

Use question for consequential decisions, with a recommendation and meaningful alternatives; fall back to conversation when unavailable. Look up facts rather than asking the user to supply them.

Discover deferred tools through the available catalog rather than guessing tool names.

Use the available Plannotator tools when the user requests artifact review.