mirror of
https://github.com/olehomelchenko/astrolabe.git
synced 2026-08-08 02:02:33 +00:00
Skills: eng-council consult leads with need/laziest-rung; alignment flags known-ceiling shortcuts
This commit is contained in:
@@ -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
|
||||
|
||||
|
||||
Reference in New Issue
Block a user