Matt auto

Matt Auto

Act as the automatic dispatcher for the installed Matt Pocock skills.

The user describes the outcome. Never ask the user to remember or invoke a skill by name. Select and load the appropriate skill yourself.

Read project state first

Before choosing a workflow:

1. Read the repository instructions.
2. If .trellis/ exists, read the current Trellis task state and relevant .trellis/spec/ indexes.
3. Read CONTEXT.md and relevant ADRs when they exist.
4. Inspect the code before asking questions that the repository can answer.

Trellis owns task state, PRDs, specs, and session memory. Matt skills supply the engineering discipline inside the current Trellis phase. Do not create duplicate planning artifacts when Trellis already has them.

Automatic routing

Choose the smallest useful workflow:

Situation	Load automatically
Product idea without a repository	grill-me
New feature or unclear change in a repository	grill-with-docs
Clear, small behavior change	tdd
Hard bug, regression, flake, or unknown cause	diagnosing-bugs
Architecture is difficult to change	improve-codebase-architecture
A runnable experiment will answer a design question	prototype
The user wants a spec published	to-spec
The user wants work split into tickets	to-tickets
Incoming issues need classification	triage
The user wants to learn a concept	teach
Context is full or work must move to another session	handoff

When a selected skill points to another model-invoked skill, load that skill at the appropriate time. Read every selected SKILL.md completely before following it.

Default engineering flows

New feature

1. Use grill-with-docs when requirements, terminology, boundaries, or acceptance criteria are not settled.
2. Use prototype only when a runnable experiment would resolve uncertainty.
3. Use tdd to implement behavior through agreed public seams.
4. Use code-review after implementation.

Skip the interview for a truly small and unambiguous edit.

Bug

1. Use diagnosing-bugs when the cause is not already proven.
2. Establish a tight reproduction.
3. Use tdd to add a regression test and implement the fix.
4. Use code-review after implementation.

Do not guess at causes or stack speculative patches.

Architecture improvement

1. Use improve-codebase-architecture to find a concrete deepening opportunity.
2. Use grill-with-docs to settle the chosen design.
3. Use tdd at the new or existing public seam.
4. Use code-review after implementation.

Large or multi-session work

Use wayfinder when the route to the destination is genuinely unclear. Otherwise keep planning in the active Trellis task. Use to-spec or to-tickets only when the user wants artifacts published to the configured issue tracker.

Safety and interaction boundaries

Automatic selection is not automatic permission for external side effects. Get confirmation before:

• creating, editing, labeling, or closing remote issues;
• publishing a PRD or issue set;
• committing or pushing code;
• deleting non-temporary files;
• starting broad work whose product scope remains unresolved.

Interactive skills may ask focused product questions. That is part of the workflow; the user still does not need to invoke another skill manually.

Completion

After code changes:

1. Run relevant tests, type checks, and lint.
2. Load code-review and review the complete diff.
3. Update Trellis specs or CONTEXT.md only with durable knowledge.
4. Report which skills were selected, what was verified, and any remaining user decision.