Engineering workflow

This is Mifal's execution contract for Matt Pocock's methodology, not an upstream Matt skill. Ask Matt supplies the route map; this adapter makes execution ordered and visible. Use it on every engineering request owned by Matt, including small fixes, research, plans and reviews.

Select the owner

Matt owns engineering in every harness.

Required entry

1. Read repository instructions and the existing task state. Declare the deliverable, authorized actions, acceptance criteria and one route: research, plan, build, debug or review.
2. Load the ask-matt skill completely, as step 4 loads a skill (fallback ~/.agents/skills/ask-matt/SKILL.md). Use its current map to select the procedure for the active phase. Do not copy the provider's route graph into harness rules. Before coordinating multiple workers, load the team-lead skill completely the same way (fallback ~/.agents/skills/team-lead/SKILL.md) and select its applicable references. Use Team Lead for explicit team requests, or for consequential coordination with independent tasks when delegation is already authorized. A bounded worker follows its brief's phase; it does not restart the parent lifecycle or recruit more workers outside its recursion envelope.
3. Before the first edit or dispatch, create or reconcile the route's ordered phase checklist in the existing task state. Read phase record and checks, keep one tracker, and record the active procedure, reads, evidence and applicability decisions there. Preserve the original required outcomes as named Done means; acceptance must reconcile them, not only dispatched tasks. A short request can keep its checklist in the conversation; declare that the file checker was not run. Existing valid research/plans can satisfy a gate after checking them against the current request.
4. Load the selected skill completely before performing its phase. Prefer the native skill tool; otherwise resolve ~/.agents/skills/<name>/SKILL.md and read it through the filesystem tool. Treat a provider's "call the Skill tool" as this loading operation, one skill per call. Never announce a skill as loaded after reading only its description. Bind its read record to the body hash; a changed body requires a reload, not reuse of an older session read. At entry and material scope/technology changes, use the existing stewardship inventory to discover applicable specialists as well as the phase procedure. Inspect descriptions and scopes, narrow candidates with who, and load only selected bodies. Record consequential omissions in the existing plan or brief prose. A solo agent uses the same selection; no team or new tracker is required.
5. Show Owner: Matt | Route: <route> | Phase: <phase> | Next gate: <evidence> at entry, consequential transitions and resume. Run the phase-record check (workflow <state> --gate entry|review|accept, and brief <brief> --matt for each brief) before every dispatch, every review and every acceptance, and log each pass first as Check: start <step> | passed | <evidence> at:<UTC>, a new one as each step begins (Check: start to-spec included, when you run to-spec yourself after the griller closes). <step> is a name from the workflow map's Required steps (scope, grilling, to-spec, to-tickets, implement, review, retro), or the route's phase word where the route has no such step; an unknown name (start entry) is refused. A dispatch with no passing Check above it never ran its gate. Continue automatically within authorization; a failed required check holds that gate. Record the passing check and identity, not only the status line.

Ordered phases and completion gates

Every request runs its route's full phase sequence by default, one phase at a time, each with its procedures. Scale depth, never the steps: a tiny fix can use a two-line plan and one relevant check. Only the human cuts a step. Before the first edit or dispatch, ask "full workflow or cut?" with the recommended answer (full workflow) and show any recorded branch that drops a main-flow step; silence is not a cut. Record a cut as Cut: <steps> | <quote> | <source> and Ask Matt's branch, which is not a cut, as Route decision: multi-session: no; reason: <why> at:<UTC> (the yes form is in the phase record), stamped before executing it. Field formats and what a cut lifts are in the phase record. Research and review do not require code changes. Build/debug review findings return to implementation; failed verification returns to diagnosis or implementation, followed by renewed review where the changed scope warrants it.

Solo form. With no team, the conversation holds the state. Show the entry line and the phase checklist there, naming the file gates that did not run (workflow <state> --gate, brief <brief> --matt). Before the first edit, ask the question above with its recommended answer, "Full workflow or cut? Recommended: full workflow."; after the answer, make no further stops except real scope or safety decisions. Review the work-in-progress snapshot (review-snapshot.py) against Standards and Spec, label the result self-review, report its findings or "none" with the scope examined, and keep the name independent review for a reviewer outside the session. Load retro and writing-for-agents before the retro findings and write them before the final answer. Team and independent-review assignments are unchanged.

• Complete a phase only when its evidence exists and meets the criteria. A delegate's claim or a successful command unrelated to the requirement is insufficient.
• The executing agent loads and applies its assigned phase procedure. A coordinating lead loads Ask Matt, Team Lead and its selection/acceptance procedures, checks worker loads and behavior, and need not read every worker's technical reference. Late reading cannot establish earlier compliance.
• Record exact check commands, exit status and the revision/content checked. After edits, rerun affected checks; stale results cannot close the final gate.
• Pin the actual review snapshot before dispatch. For committed work, use the named commit comparison. For work in progress, use ~/.agents/mifal/tools/review-snapshot.py --repo <repo> --base <fixed-point> and explicit --path arguments for owned untracked files. Its working-tree, index and untracked scope replace a provider's HEAD-only diff and nonempty-diff precondition for this review. Give reviewers the snapshot identity, commands and file list; check the same identity after review. Report omitted untracked files, distinguish the staged version from working-tree changes, and never commit merely to make a review diff exist.
• If evidence fails or cannot be obtained, keep the phase incomplete, repair within scope, or report the concrete blocker. Never substitute confidence for a result.
• Persist material decisions and multi-session state in the repository's existing task/document location. After compaction, reload this adapter, Ask Matt, the active specialist and the existing state, and add a new Loaded: line beside the original for each body you reload (never rewrite the first); validate evidence and resume at the first incomplete phase.
• Before a whole-task success claim, run the phase-record accept check against the authoritative state: named required outcomes, final evidence and completed execution phases. A worker receipt is not parent completion. Keep the final Report item open until delivery. End with delivered behavior/findings, phase disposition, checks/results and remaining gaps; required blockers remain incomplete.
• After a build or fix, load retro and its writing-for-agents dependency, inspect the actual session or logs, and record its findings before acceptance. A coordinated build has one parent retrospective; a worker receipt does not close it. Record the pinned Retro artifact and passed check as defined in the phase reference. Present proposals; apply environment changes only under actual authorization.

Harness integration

Harnesses use their existing task tools and this entry contract. These instructions require evidence, but do not install universal action interception. Distinguish configured entry, observed skill-body loading and verified behavior when reporting setup health.

Workflow ownership

Matt's current Ask Matt file owns semantic routing. This adapter owns the common execution contract, automatic continuation and tool compatibility. A native interpreter can own mechanical transitions. Specialists supply focused procedures; they do not introduce another default workflow.

• Explanation and research-only requests remain read-only. Review-only requests produce findings; implement remediation only when requested.
• A build starts with Matt's interview unless the existing plan/ticket already supplies accepted scope and settled design decisions. Record Grilling with that evidence and its digest before implementation; the phase reference defines the check. A task being called concrete is insufficient. Unsettled decisions follow Matt's planning branch; reuse accepted decisions rather than repeating their interview. Workers inherit the parent's evidence.
• DDD is Mifal's documentation-driven validation layer, not a legacy workflow. Select it when the user asks for DDD, technology is unfamiliar, a consequential API/lifecycle/security assumption lacks evidence, or observed behavior contradicts an assumption. Ordinary settled work needs only its relevant documentation checks.
• For changed user journeys, visual direction or interaction, including backend changes with user-visible effects, read UI/UX acceptance during planning and before final acceptance. Select only applicable UI, UX and motion procedures. A single agent uses the same relevant checks in its existing plan; no team, multiplexer or second tracker is required. Research/plan-only work defines these checks without executing a build.
• When DDD applies, load ddd and the relevant phase procedure as step 4 loads a skill: ddd-scope during research/context, ddd-ground during planning, and ddd-verify during final review/verification. Follow its version/source discovery, cited decisions, actual post-change source comparison and independent review requirements for consequential work. Show Validation: DDD at entry. Reenter research when a failure challenges a technology assumption.
• Bind each DDD procedure to the current Matt phase and existing task plan or Pi journal. DDD owns the documentation-validation procedure inside that route; Matt owns lifecycle progression. Do not create another tracker, repeat settled interviews, or let the DDD sequence advance beyond the selected deliverable. Full DDD remains explicitly available; even then preserve the single existing task state and authorization boundaries.
• For a multi-ticket build, use implement-spec when its parallel execution is explicitly authorized for the task or by the standing project agreement and the harness supports it. Otherwise retain one writer in dependency order. Do not start implement-spec inside an active Pi run. Team Lead owns briefs, capacity and acceptance; implement-spec owns the ticket frontier and integration order. Record one scheduler and one integration owner; workers start from the integration branch and inherit the selected methodology.
• Mifal's skills are model-invoked by default: none declares an invocation blocker. Upstream content stays provenance-tracked. Eligibility does not prove native runtime discovery or authorize external actions; installing a competing full workflow does not select it for the task.
• Automatic selection preserves the procedure's real inputs and authority. Grilling can start automatically but unanswered human decisions remain unresolved. Retro produces evidence-backed improvement proposals; applying durable environment changes uses the actual task's authorization. Do not invent a user request to justify a selected skill's actions.
• Repository setup is a prerequisite, not permission to create an external tracker. Load setup-matt-pocock-skills when needed and use the repository's configured tracker and document layout. Resolve missing external access with the user.
• Commit, publish, deploy, messaging, and durable rule changes retain the user's existing authorization boundaries. A specialist's shipping instructions do not expand them.
• retro may propose environment improvements. Apply durable rule or memory changes only when explicitly authorized.
• Local overrides of Matt's procedures: under Team Lead, the grilled user is the lead, so an agent other than the lead grills the lead and only what the lead cannot settle goes to the human; distributed grilling feeds to-spec, so the lead runs to-spec and to-tickets itself, reading the round and answer files as the conversation.
• Keep local compatibility decisions in this adapter and the invocation policy; preserve Matt's upstream procedures and record any intentional override. Installing a skill, reading its metadata, loading its body and verifying its behavior are four separate claims.