Skills: eng-council consult leads with need/laziest-rung; alignment flags known-ceiling shortcuts

This commit is contained in:
2026-06-16 21:44:43 +03:00
parent 5d3aba608a
commit a833e019d6
2 changed files with 43 additions and 28 deletions
+21 -5
View File
@@ -1,6 +1,6 @@
---
name: eng-council
description: Convene the engineering council — an evidence-grounded review of codebase structure, consistency, layering altitude, subtraction (what should be deleted), and documentation altitude. Modes - whole-codebase sweep (milestone boundary or backfill), refactor review, new-functionality review, and a pre-build consult. Auto-invoke only the consult mode - before introducing a new module/store/modal/service/hook shape, ask the council for the canonical shape and what already exists to reuse. All other modes run on demand.
description: Convene the engineering council — an evidence-grounded review of codebase structure, consistency, layering altitude, subtraction (what should be deleted), and documentation altitude. Modes - whole-codebase sweep (milestone boundary or backfill), refactor review, new-functionality review, and a pre-build consult. Auto-invoke only the consult mode - before introducing a new module/store/modal/service/hook shape, ask the council whether it needs to exist and the laziest rung that meets the need (stdlib/native/already-shipped dep before new code), then the canonical shape and what already exists to reuse. All other modes run on demand.
disable-model-invocation: false
---
@@ -109,10 +109,26 @@ not a move-by-move log).
### Consult — before writing code
The cheapest and most preventive mode; the only one that auto-fires. Before building a
new instance of a kind (a modal, store, service, hook, persistence path): line up the
existing instances, name the canonical shape, list what already exists to reuse, and flag
what the new work might make deletable. Two paragraphs, no report scaffolding.
The cheapest and most preventive mode; the only one that auto-fires. Two questions, in
order, before a line is written.
**Does it need to exist — and at what rung?** Stop at the first rung that holds: (1) the
need is speculative → say so and skip it (YAGNI); (2) stdlib or a language built-in does
it; (3) a native platform feature covers it — `<input type="date">` over a picker lib, CSS
over JS, an IndexedDB/DB constraint over app code; (4) an already-shipped dependency solves
it — Monaco, vega/vega-lite, Zustand are already in the bundle, so never add a dependency,
or hand-roll, for what one of them or a few lines covers (a new dependency owes the
justification `/alignment` demands). Only past the rungs is fresh structure earned. Lazy is
less code, not a flimsier algorithm: between two equal-size options take the one correct on
edge cases, and never simplify away input validation at trust boundaries, error handling
that prevents data loss, or accessibility.
**If it must be built — what shape?** Line up the existing instances of the kind (modal,
store, service, hook, persistence path), name the canonical shape, list what to reuse, and
flag what the new work might make deletable. An abstraction is earned only by ≥ 2 call
sites that would use it today (deletion rule 3).
No report scaffolding — these two answers are the output.
## Report format