ask-matt

Files (2)

• SKILL.md
• openai.yaml · agents/

SKILL.md (first lines)

# Ask Matt

Route one task at a time. Preserve the upstream idea-to-ship flow, then add a personal routing layer for evidence and external capabilities.

## Route in order

1. Identify the user's authorization: answer, research, plan, diagnose, change, validate, publish, or destructive cleanup.
2. Identify the destination and current stage: fog, decision, specification, execution, diagnosis, correctness, quality, performance, release, or operations.
3. Apply constraints first: scope, dirty worktree, ownership, external side effects, and evidence identity.
4. Select exactly one current router or an explicitly named leaf skill. Do not list a menu of plausible skills.
5. State the result in this form:

```markdown
## Destination

## Ownership branch

## Current stage

## Authority and constraints

## Selected router

## Use now

## Exit criterion

## Use next

## Missing evidence

## Out of scope
```

Use `Own` when the route is a personal skill, `External` when it is entirely Matt/Codex/plugin-managed, and `Mixed` when a personal router selects an external leaf skill.

## Own branch

Use a domain router for a multi-step task or when a choice among skills remains.

- **Planning and decisions** → `$route-planning`: research, ambiguous ideas, terminology, prototypes, Wayfinder, specs, or tickets.
- **Engineering and architecture** → `$route-engineering`: authorized code changes, TDD, reviews, merge conflicts, or codebase health.
- **Diagnostics** → `$route-diagnostics`: failures, regressions, CI, CUDA correctness, or performance symptoms. Diagnosis does not authorize a fix.
- **Evidence and release** → `$route-evidence`: identity, correctness, quality, performance, evidence packaging, patch decomposition, or upstream integration.
- **Artifacts and external operations** → `$route-operations`: documents, spreadsheets, browser work, GitHub, Gmail, Sites, or image/visual work.

When the next router can be selected reliably, invoke it in the current task. If invocation is unavailable, output its explicit `$route-*` command and the minimal context it needs.

## External branch

Use an explicit external leaf skill directly when the user's request already names it or is narrow enough to need no domain decision.

- **Matt Pocock**: retain the upstream flow: `grill-with-docs` or `grill-me` → `prototype` if necessary → `to-spec` → `to-tickets` → `implement`/`tdd` → `code-review`.
- **Large foggy work**: use `wayfinder` only when the destination spans more than one task and the route itself still requires decisions. It hands off to `to-spec`; it does not directly build.
- **Codex and plugins**: use the domain-specific skill for documents, PDF, slides, spreadsheets, browser, GitHub, Gmail, Sites, visualization, or image work.

## Guardrails

- Treat diagnosis, audit, planning, and implementation as different authorizations.
- Before modifying a repository, use `git-worktree-protection` when the worktree may be dirty or concurrent.
- Never claim release proof from a build, help output, UI exposure, or a single bounded test.
- For a direct leaf-skill request, do not interpose a router unless the leaf's own prerequisites are unresolved.

From linjuhon/codex-personal-skills, MIT.

More from linjuhon/codex-personal-skills