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

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.

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.