motspilot

Example task — csv-export-reports-listing

This is a synthetic-but-realistic walkthrough of a motspilot task end-to-end. It exists so you can see what each phase actually produces before installing the plugin and running it on your own codebase.

Synthetic = the artifacts below were not generated by a live pipeline run; they were written to demonstrate the conventions, gates, and output shape motspilot produces. The structure, completion checklists, severity tiers, and consistency checks are real. The fictional app is a CakePHP 4.x web application (demo-app) — the same patterns apply to Laravel, Django, Rails, etc., via the matching framework guide.

The feature

Add a “Download CSV” button to the reports listing page. The export should respect whatever filters and sort order the user has applied, only include reports the user is authorized to see, cap at 10,000 rows, and include a timestamp in the filename.

This is the entire requirements input the user wrote — a short paragraph. Everything else below is what motspilot produced from it.

The artifacts

#	Phase	File	What’s interesting in it
0	Requirements	01_requirements.md	The user’s input, stamped into a task
1	Consensus	consensus/04_synthesis.md	3-LLM fan-out → 9-section synthesis with Agreed / Split / Risks / Scope. One Split was auto-resolved by majority.
2	Architecture	02_architecture.md	File map, blast-radius analysis, 6-unit decomposition. Decides between adding a new action on ReportsController vs a dedicated ReportsExportController — picks the former for parity with how filters are wired.
3	Development	03_development.md	Layer-by-layer build (Foundation → Logic → Interface). Calls out an existing BoundedRowLimit constant in the codebase and reuses it instead of hard-coding 10,000.
4	Testing	04_testing.md	Runtime-path classification table — pure-logic vs plumbing-dependent vs external-I/O. Catches that auth middleware must be exercised through a real HTTP request, not a reflection-based unit test.
5	Verification	05_verification.md	One MUST FIX (untested seam) found and quoted at file:line, plus a SHOULD FIX about a missing constant alignment. VERDICT: NOT READY. Development re-ran and the second draft passed.
6	Delivery	06_delivery.md	Smoke tests executed with both entry-point AND side-effect checks (parsed CSV body, asserted row count). Rollback plan, deploy steps, git commit message draft.

What this is meant to show

• The verification phase actually verifies. Look at 05_verification.md — every finding quotes a file path, line number, and the surrounding code. Findings without evidence are rejected by the prompt itself.
• The testing phase classifies runtime paths. The table at the top of 04_testing.md tells verification what was exercised by real framework plumbing (auth middleware, request lifecycle) vs what was unit-tested in isolation. The MUST FIX in verification refers directly back to that classification.
• The delivery phase executes smoke tests, not documents them. The “Smoke test execution results” section of 06_delivery.md shows real stdout/stderr/DB-query output (synthetic here, but the shape is what a real run produces). Status-code-only tests are rejected at the prompt level.
• The consensus phase catches what one model misses. In consensus/04_synthesis.md, GPT-4o flagged the auth-on-export concern that Claude initially under-weighted. The synthesis surfaces it as an Agreed risk.

What this is not

• Not a tutorial. If you want to learn motspilot, run /mots:init and /mots:pilot on a real feature in your own codebase.
• Not a benchmark. The artifacts here are crafted to demonstrate the format; a real run on a real codebase will be longer, messier, and reference real files in your project.
• Not exhaustive. A real medium-complexity feature usually produces 2–4× the prose volume below.

This site is open source. Improve this page.