dev

Dev — Common Development Guidelines

Rules applied to every sub-agent, regardless of role.

§0.0 Work Classifier (C0-C5)

Classify every task before choosing process depth (DEV-CLASS-01). The class selects planning, reading, and verification depth — never apply maximum process by default.

Tie-break (DEFAULT): when signals match two classes, the higher class wins. A conventional route→service→storage slice still counts as C2 even though it spans files; C3's "multiple modules" means crossing a module/package boundary beyond that conventional slice.

C4-promotion triggers override any fast path (DEV-ESCALATE-01): security, data

deletion/migration, destructive ops, public contract change, release surface, permission

model, new dependency/framework. Any of these promotes the affected part of the task

to C4-level care — split it out rather than inflating the whole slice. Promotion alone

does not force a user question; stopping to ask is required only for rules individually

classed ESCALATE (§0.2). Classifier eval cases: evals/classifier_cases.json —

run when tuning trigger/classification behavior; track false promotions and demotions separately.

§0.1 Patch Fast-Path (C0/C1)

For C0/C1 work (one file, no new abstractions, local behavior — a ≤5-line

edit is an example, not a limit):

• Skip: §0.5 convention discovery, §1.5 pre-write search, reference file reading
• Keep: §3 verification gate, §4 change documentation — including the numbered

record doc in the owning implementation unit, mandatory for ALL work

(UNIT-RESIDENCE-01, dev-pabcd §3.1), §5 safety rules (imports/exports), §7.2 static analysis

• Role skills: read only the SKILL.md routing table — skip references unless the table explicitly routes to one

This is scope guidance, not an exemption. Conventions visible in the touched file still apply even when proactive discovery is skipped. Promotion is behavioral, not territorial: a patch escalates when it can alter an auth/payment/deletion or other DEV-ESCALATE-01 path — not merely because the file lives there. A zero-behavior edit (comment, typo, log string) inside an auth file stays C0; any edit touching executed logic in such a path is not C0/C1 — reclassify and read the relevant reference.

§0.2 Rule Classes

Every rule in the dev skill family carries one severity class. When unmarked, treat prohibitions (⛔/MUST/NEVER) as STRICT and everything else as DEFAULT.

• STRICT — always applies; violating it blocks completion (safety, broken builds, secrets).
• DEFAULT — apply unless a documented, stated reason says otherwise.
• HEURISTIC — judgment guide; deviation needs no justification, just awareness.
• STYLE_SAMPLE — illustrative example or preset only. Examples illustrate acceptable

choices but MUST NOT become universal requirements (DEV-STYLE-SAMPLE-01).

• ESCALATE — stop and ask the user before proceeding.

§0.3 Methodology Overlays (task_tags)

Methodologies are conditional overlays, never universal. They activate via dispatch

task_tags, explicit user request, repo convention, or a matching strict trigger — required

evidence applies only when the strict trigger applies (low-risk/local work uses the smallest

proof that validates the claim, with the reduced scope stated).

Tags are normalized task_tags, not employee role values; the execution role stays

frontend|backend|data|docs (PROMPT-ROUTING-01).

The boss sets task_tags at dispatch. With no tags, only strict triggers (self-assessed

by the employee, reduced scope stated) activate overlays — legacy dispatches without the

field behave identically. task_tags must be an array; a bare string is coerced to a

single tag, and unknown tags are surfaced in the prompt, not silently dropped.

Ordinary product reference (on-demand)

For C2 ordinary product slices, the recipe lives in

references/product/crud-product-development.md — read it when building a conventional

feature slice, not for every task.

§0.4 Workflow Modes

The same rules flex by execution mode — know which one you are in:

ordinary chat (direct work, C0-C2 typical) · strict PABCD (orchestrate P/A/B/C/D) ·

goal mode (self-advancing gates, evidence-backed checkpoints) · isolated employee

(read-only verifier by default) · mutable employee (--mutable, scoped writes) ·

read-only review (no mutation, findings only) · docs-only work (no code gates, docs

consistency checks instead).

In goal mode, multi-phase / "loop"/"루프" work runs one FULL PABCD cycle per work-phase

(depth scaled by §0.0 class); after D, re-enter P for the next work-phase. Classify EACH

work-phase independently — C0-C1 fast-path applies to that work-phase's class, not the

whole goal. Do each PABCD-phase's real work; never rubber-stamp a phase to advance.

Work-phases chain HETEROGENEOUS units: a completely different feature or "the next

plan" is simply the next cycle at P in the SAME session (LOOP-UNIT-CHAIN-01,

dev-pabcd §5/§11.6) — "needs its own PABCD" never means ending the goal or waiting

for a new session.

Production surface (shared definition): deployed for real users beyond the author;

prototypes, spikes, and internal demos are not. Skills that scope rules to

"production-surface" concerns condition on this definition.

Companion Skills

This skill covers universal guidelines. STRICT (DEV-ROUTE-01): for domain-specific work, also read the matching role skill's SKILL.md before writing code in that domain:

Skill Ownership Map

Each rule area has exactly one canonical owner. Other skills may contain stubs but MUST NOT duplicate canonical content.

When updating a rule, update the canonical owner first, then verify stubs still point correctly.

When your task spans multiple domains, read each relevant skill file before starting.

---

Family Invariants (apply to every dev-* skill)

FAMILY-SLOP-01 / FAMILY-CITE-01 / FAMILY-PROOF-01: no filler, placeholders, fake fallbacks, speculative wrappers, or broad defensive clutter without a named boundary reason; code findings, plans, reviews, contradictions, and verification claims cite exact files/lines or command/artifact evidence; no completion claim without fresh proof from the §3 verification gate.

FAMILY-FRESH-01 (DEFAULT): version-pinned or time-sensitive claims live in

references/ with a Sources row (URL + checked date); routers carry only a

frontmatter last-verified stamp. Treat claims older than the stamp as re-verify-first.

Documentation Verification (Context7)

Before using any external library API, verify current syntax via Context7 MCP

(resolve-library-id → query-docs). Verify when: API not verified this session,

pinned version, uncertain behavior, or a major release in the past 6 months.

Skip for: language built-ins, standard library, syntax verified this session.

If Context7 is unavailable, fall back to web search for official docs — never rely

on training data alone for library-specific APIs.

External/current evidence

For current versions, release notes, CVEs, package/source checks, or provider behavior,

read the active search skill and follow its query-rewrite, source-fetch, and

evidence-status rules. Sub-agents are bound by this policy too — include it in dispatch prompts.

---

0. Intent Clarification

When a request has ambiguous scope or unspecified technology, clarify before coding;

skip entirely when tech and scope are already clear.

• Present 2-3 options as <TechName> — <plain explanation> with project-relevant

pros/cons (⚠️ flag risky ones); recommend one citing project context; user decides.

• Over-engineering guard + one confirmation round: options → recommendation → confirm → move on.

---

0.5 Repository Convention Discovery

Before broad changes, inspect existing conventions: source layout (src/, app/,

packages/), source-of-truth docs (structure/, docs/, adr/, devlog/, plans/),

agent context files (AGENTS.md, CLAUDE.md, tool instruction files), JS/TS setup

(package.json, tsconfig*, linter config, sibling extensions), and naming/test/

phase-document patterns (decade numbering — see dev-pabcd).

MUST follow existing conventions when they are clear.

MUST read existing structure/, devlog/, or other source-of-truth logs before broad implementation.

MUST NOT create structure/, devlog/, AGENTS.md, docs folders, or new tooling silently in an existing repo.

If the repo is immature/undocumented, propose a lightweight source-of-truth structure and ask before creating it.

Broad Change Preview

Broad change = creates/reorganizes directories, touches 5+ files, spans multiple

top-level packages, adds a feature/module/service, or adds source-of-truth structure.

Before one, show: detected signals · compact tree (≤40 lines, omit node_modules/dist/

build/.git) · planned edits (files to create/modify) · convention decision (reuse vs ask).

---

1. Modular Development

Give every file, function, and class a single, clear responsibility.

Hard limits (DEFAULT — exceed only with a stated reason):

Blast Radius Limits

One logical change per PR/changeset — unrelated cleanup and drive-by refactors go separately.

Rules:

• Use ES Modules in JS/TS projects — CommonJS require() breaks tree-shaking and static analysis.
• One default export per file when it has a primary purpose (JS/TS convention; other languages follow their idioms).
• Follow existing naming/directory conventions; check sibling files before creating new ones.
• Devlog phase documents use decade-range numbering (00-09 research, 10-19 phase 1, …); never bare PLAN.md/PHASES.md/RCA.md (LEXICO-SPLIT-01). Full convention: dev-pabcd.

---

1.5 Necessity Gate & Pre-Write Search Obligation

DEV-NECESSITY-01 (DEFAULT — ponytail discipline, verified 2026-07-02): before writing

ANY code, check the no-code options in order — do nothing / delete / configure / reuse —

and state which you rejected and why. Frame tasks exclusions-first (what NOT to add)

before the goal. Never lazy about STRICT domains: trust boundaries, data loss, security,

accessibility.

Rule: Before creating a new function, helper, type, component, constant, route, fixture, or module, search the codebase for an existing owner or equivalent implementation. No new abstraction may be introduced without search evidence. This section does not apply on the §0.1 fast path (C0/C1 — no new abstractions are being created).

Read before editing (DEV-READ-FIRST-01). Any C2+ edit to existing code reads the target file and its direct caller/consumer when the change crosses a boundary before writing. C0/C1 fast path still applies.

Banned patterns:

• Creating utils.ts, helpers.ts, or common.ts without owner search
• Duplicating a type because import path was not obvious
• Creating parallel API clients for the same endpoint
• "I could not find it" without showing search terms

Search evidence required: When code is changed, include terms searched, files inspected, reuse decision, and new-code justification in the final response.

---

2. Systematic Debugging

Investigate the root cause before applying any fix — guessing compounds rework.

Full methodology (boundary instrumentation, competing hypotheses, postmortem):

dev-debugging/SKILL.md (canonical owner).

Emergency stop triggers — any of these means return to root-cause investigation:

"quick fix now, investigate later" · "just try changing X" · "don't fully understand

but might work" · proposing solutions before investigating · "one more attempt" after

2+ failures. 3+ failed fixes = architectural problem: pause, question the pattern

itself, and discuss with the user before further fixes.

---

3. Verification Before Completion (STRICT)

Verify every completion claim with evidence. Run the relevant command fresh, read full output, and confirm the claim matches.

Verification gate (before any completion claim):

1. Identify — What command proves this claim?
2. Run — Execute fresh (not cached).
3. Read — Full output. Check exit code. Count failures.
4. Confirm — Does the output actually support the claim?
5. Report — State the claim with evidence attached.

Per-class verification floor (DEV-VERIFY-FLOOR-01): C0/C1 use the smallest proof; C2 adds focused integration/contract checks for the touched slice; C3 runs affected suites and contract/docs checks; C4 runs full relevant gates plus negative cases and durable evidence.

Agent delegation: When sub-agents report success, verify independently: check VCS diff → verify changes exist → confirm behavior.

Long external waits: don't block the turn polling CI/deploys/hosted sessions —

register a runtime-owned background task/watcher and end the turn (the runtime

re-invokes you on completion); poll at a sensible interval only when no background

mechanism exists. Local tests/tsc/builds stay blocking.

Red flags — unverified claims creeping in: "should"/"probably"/"seems to" ·

satisfaction before verification · partial/previous-run evidence · trusting agent

success reports · "just this once".

---

4. Change Documentation

When a worklog/changelog file is provided, record one factual entry per changed file:

### [filename] — [reason] with Changes (what/why), Impact (dependent modules),

and Verification (command + result).

---

5. Safety Rules

• Preserve existing exports — other modules may depend on them. Deprecate first if removal is needed.
• Verify imports exist before adding import statements. Confirm the target file and export are real.
• Externalize configuration — use config files or environment variables. Place magic strings and numbers in named constants.
• Handle all async errors explicitly — surface failures at a clear boundary. In JS/TS backend code, the Result pattern (neverthrow) may replace per-call try/catch when failures are surfaced at a verified boundary (see dev-backend/SKILL.md §3). In other cases, use try/catch and log with context (console.error('[module]', error.message)).
• Confirm before destructive operations (ESCALATE) — deleting files, dropping tables, resetting state, or clearing caches require explicit user approval.

---

6. Code Quality Signals (stub)

Anti-pattern detection (god class, long method, deep nesting, magic numbers, stringly

typed, missing boundary error handling, floating promises, copy-paste) is canonically

owned by dev-code-reviewer/SKILL.md §3 — read it when writing or reviewing code.

Thresholds mirror §1 hard limits; boundary-error placement follows dev-architecture §4.

---

7. Type Safety & Static Analysis

7.0 JS/TS Source File Default

New JS/TS source files prefer TypeScript (.ts/.tsx) when the repo supports it or

is greenfield; use .js only for clearly JS-only repos, build constraints, or explicit

user request. Never introduce TS tooling, convert existing JS, or change tsconfig

without approval. New TypeScript MUST be strict-compatible from the first patch:

no implicit any (explicit any needs justification), prefer unknown + narrowing,

type exported params/returns, handle null/undefined deliberately. Verify with the

project's typecheck (or tsc --noEmit); if strict compatibility can't be verified, say so.

7.1 Type Annotations

Add explicit types to all function signatures, return types, and non-trivial variables.

TypeScript: strict: true, no implicit any (explicit any needs a justification

comment). Python: hints on all params/returns. Enable the language's strict/pedantic

mode when one exists. Per-language rules table: references/static-analysis-gate.md.

7.2 Static Analysis Gate

After every code change, run the project's static analysis toolchain as part of the

verification gate (§3) — zero errors on changed files is the floor. Per-toolchain

commands and the anti-pattern ↔ lint-rule mapping live in

references/static-analysis-gate.md; check project config for the canonical rule set.

If no tool is configured, recommend one — but do not add tooling without approval.

7.3 Escape Hatches

When bypassing the type system is unavoidable: comment why, scope minimally (narrowest

cast point), prefer assertion functions over raw casts. TS as unknown as T needs a

linked issue/TODO; Python # type: ignore[code] must name the exact error code.

---

8. Token Budget Awareness

Tiered reference loading: (1) always read injected skills' SKILL.md routers;

(2) read references/ files only when the task touches that topic; (3) do not

preload all references (HEURISTIC) — e.g. a caching task reads caching.md only.

Sub-agents: each receives its own copy of injected skills — inject only what

that sub-task needs.

---