| name | specrew-code-rules |
| description | Guide the coding agent with this feature's chosen implementation-craft rules WHILE it writes code. Use during implement: before and while writing source, and RE-INVOKE per task / file type. It resolves the active feature, reads the per-feature implementation-rules.yml manifest + the canonical code-rules.yml catalog (+ any code-rules.local.yml overlay), and composes a BASELINE (always-on craft defaults) + the feature's OVERLAY (selected decision-prompt rules + decisions + custom rules + dependency policy), surfaced task-scoped (service / client / concurrency / API) so the code reflects the agreed posture. Triggers: implement, writing code, code rules, code quality, DI, naming, error handling, dependency, add a package, refactor, concurrency, API design, before I write the implementation. |
| domain | lifecycle-implementation |
| confidence | high |
| source | Specrew Feature 177 (Code & Implementation Lens, Proposal 163) — the implement-time half: read the design-time manifest and actively guide the coding agent. No 145 mechanical gate; guidance, not a gate. |
specrew-code-rules
Type: Implement-time Guidance Skill
Schema: v1
Status: Active implementation conduct
Purpose
The code-implementation design lens captured this feature's implementation-craft rules at design time (the
implementation-rules.yml manifest). This skill is the implement-time half: while you write code, it
surfaces the chosen rules so the code reflects the agreed posture (DI, naming, size, error handling,
security-context, copy semantics, dependency stance, …) without the maintainer re-pasting rules. It is
guidance, not a gate — there is no mechanical conformance check; the value is that you actually follow
the rules as you write.
The Big Picture (read this first, every time)
You are a static reader. You carry NO per-feature content yourself — you resolve it at read time:
- Resolve the active feature. Read
.specrew/start-context.json (session_state.feature_ref /
feature_path) to find the active feature's specs/<feature>/ directory.
- Read the per-feature manifest
specs/<feature>/implementation-rules.yml — the selected rule ids
(checked/unchecked), per-rule decisions, the resolved stack, custom rules, and the dependency_policy.
- Read the canonical catalog
extensions/specrew-speckit/knowledge/design-lenses/code-rules.yml
(deployed under the project's design-lens catalog) to resolve each selected rule id to its text, and the
optional project overlay code-rules.local.yml (additive + per-rule override; never drops a shipped
rule) for the ingested company guideline / reusable custom rules.
- Compose BASELINE + OVERLAY (below) and surface it task-scoped for the current work.
Compose: baseline + overlay
- BASELINE — the catalog's
baseline-default group ALWAYS applies (intent-revealing names, short
methods, low nesting, DI as a principle, no magic numbers, guard object invariants, don't leak mutable
internals, SOLID, idiomatic errors, …). Apply it even when there is no manifest (baseline-only mode).
- OVERLAY — when a manifest exists, layer the feature's choices on top: the selected
decision-prompt
rules + the human's per-rule decision, the applicable applicability-filtered rules, any custom_rules,
and the dependency_policy. An unchecked baseline rule is a recorded exception — honor the exception.
Surface it task-scoped (never a flat dump)
Pull only the group relevant to the current task/file, keyed by the manifest's selected groups + the
resolved stack:
- writing a service -> DI · DTO boundaries · idiomatic error handling + bounded retries ·
authz / security-context flow · robustness/state boundaries.
- writing a client / UI -> render purity · never-block-the-event-loop · validation placement ·
input controls that prevent invalid input.
- writing concurrency -> prefer concurrency over locks · explicit ordering/idempotency · normalize state.
- writing an API / contract -> protocol by shape · versioning · pagination/delivery · idempotency ·
error envelope · public-API/reusable-code design posture.
- repeated conditionals / polymorphism -> Strategy/State over repeated branching; choose the
polymorphism mechanism (functional vs inheritance/interfaces) deliberately.
- per-stack -> the
language:<stack> rules for the resolved stack (e.g. C# nullable/file-scoped +
analyzers; Go small interfaces + gofmt; Python typing + ruff/mypy; C/C++ ownership + clang-tidy/safety).
State the rules that bind THIS task, then write the code following them. Re-invoke for the next task/file.
Dependency policy (FR-013)
Honor the manifest's dependency_policy:
- Default stance is use existing project tools / no new dependency — do NOT silently add a package.
- If the policy lists an approved dependency, follow its captured constraints (version, license posture,
coupling/replaceability notes). If you believe a NEW dependency is needed and it is not in the policy,
surface that to the human (it is a dependency-selection decision), do not just add it.
Fail-open (never block, never crash)
- No manifest -> baseline-only mode (the catalog
baseline-default rules). Say so briefly.
- Unknown rule id in the manifest (catalog changed) -> note it and skip that id; keep going.
- Malformed manifest / overlay -> warn and fall back to the shipped catalog baseline; never crash.
When to Use
- At implement time — before and while writing source files. Re-invoke per task / file type so the
surfaced rules match what you are writing.
- It is a reader: it never edits the manifest, the catalog, or itself. The workshop (design-time) writes the
manifest; this skill only reads it.
Review note
This skill is doing its job when, in a dogfood: the generated code visibly reflects the manifest's chosen
rules (DI posture, naming, size, the decided forks), the human did not have to re-paste rules, and a new
dependency was never added without surfacing the decision. That dogfood (on the deployed module) is the
acceptance gate (SC-004 / SC-007 / SC-008) — not unit-green.
