Menu
Heavy one-shot implement of an attached plan (council → best practices → Karpathy → YAGNI).
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
Plan a huge chunk of work — more than one agent session can hold — as a shared map of decision tickets on your issue tracker, and resolve them one at a time until the way is clear. On ticket close, may offer ADRs (promotion into docs/adr/) when ADR-POLICY criteria hold.
Sharpen a plan or design against this codebase via grilling + domain-modeling (CONTEXT.md / ADR offers). May offer /wayfinder when fog appears. Invoke with `/grill-with-docs`.
Applies Dockerfile, Docker Compose, BuildKit, and container security patterns for local development and hardened deployable images. Use when authoring Dockerfiles or compose files, wiring secrets (runtime vs build-time), reproducible bases, PID 1 and healthchecks, volumes and networking, supply-chain hygiene, or troubleshooting compose stacks.
Routes Go work to the right reference guides and conventions for the task. Use when working on Go architecture, implementation, refactoring, concurrency, error handling, testing, performance, or code review.
PostgreSQL database patterns for query optimization, schema design, indexing, and security. Use when writing SQL or migrations, designing schemas, troubleshooting slow queries, implementing Row Level Security, tuning connection pooling, or reviewing database changes. Based on Supabase-leaning Postgres practice.
Applies Python idioms, PEP 8 norms, typing, packaging, concurrency, tooling, and performance discipline to everyday Python code. Use when writing, reviewing, refactoring, or packaging Python; when the user names type hints, dataclasses, pytest, ruff/black/mypy, asyncio, concurrency, EAFP vs LBYL, or Python idioms; or asks for a Python-specific code-quality pass.
| name | implement-plan |
| description | Heavy one-shot implement of an attached plan (council → best practices → Karpathy → YAGNI). |
| disable-model-invocation | true |
Using the plan attached to this message (typically work/<feature-slug>/plan.md from /to-plan, or any attached plan):
/council scoped to every area the plan touches, to gather context and validate the plan's approach against the existing codebase. Done when: every file/area the plan will change has been explored./best-practices-research on the domains the plan touches, before writing any code. Done when: every recommendation is incorporated into the plan or explicitly rejected./karpathy-guidelines. Done when: every step in the plan is implemented./yagni pass over the changes made in step 3, to simplify. Done when: the pass has reviewed every file changed in step 3.Do not use this as the default executor for /to-tickets output — that is /implement (one ticket per session). /to-spec already runs council/BPR on the Matt path; this skill runs them on the attached plan — do not also re-prep a spec here.