Jaw 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. The full table is in references/skill-ownership.md — consult it before adding a rule area, and add a row when you do. A rule area with no recorded owner is how the same guidance ends up written twice in two skills at two different thresholds.

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

Family Invariants (apply to every dev-* skill)

Role boundary (canonical — identical in dev-frontend and dev-uiux-design): dev owns universal process, evidence, and safety rules. dev-uiux-design owns design intent, direction, and concept judgment. dev-frontend owns concrete frontend implementation and rendered tell enforcement. Anti-slop has three layers: dev = output/process hygiene (FAMILY-SLOP-01), dev-uiux-design = concept/taste judgment (is this direction generic or domain-wrong?), dev-frontend = rendered implementation tell detection and removal (FE-AI-TELL-01).

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 Evidence and Recall Routing

Canonical routing table for anything that is external, current, or previously decided. Surface routers point here instead of restating the policy.

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.

Routers that delegate here (dev-frontend, dev-uiux-design) inherit these rules in full; delegation is a pointer, never a weakening.

Recall lookup scope (DEV-RECALL-01, MUST)

When a prior term, file, or decision is unfamiliar — or context was lost to a compaction — search the durable record before asking the user: cli-jaw chat search <query>, then cli-jaw memory search <query> [--chat], then the owning unit and the commit that introduced the term. If all miss, ask, and state what you searched — that is what lets the user correct the vocabulary instead of re-explaining something already on disk under a name you did not try. Full routing table: references/recall-lookup.md.

Browse and QA tool routing (DEV-BROWSE-NATIVE-01, STRICT)

For ad-hoc browsing and exploratory QA — opening a page, checking a URL, eyeballing a screen, taking a screenshot — do not install a browser-automation framework or driver. Use the runtime's own browser capability first. A deliberate end-to-end test suite is a different task and belongs to jaw-dev-testing.

Two ladders exist and their orders are deliberately opposite: public-web proof leads with jaw browser fetch, QA of a surface you just built leads with the Manager embedded browser. Full rung tables and the reason the inversion is the content of the rule: references/browse-qa-ladders.md.

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).

Structure map first (DEFAULT — DEV-MAP-FIRST-01): for C2+ work in unfamiliar territory, run cli-jaw map <dir> (ranked structure map — see the repo-map skill) before deep Grep dives; then use Grep/Read to confirm the narrowed targets. Works on subtrees for large monorepos. Guidance, not enforced.

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. Repeated-friction rule (DEV-FRICTION-01, DEFAULT). When the same command class fails twice with the same normalized error, do not retry a third time unchanged: switch approach — a different tool, different flags, or root-cause the environment. Repeated identical failures are friction evidence, not bad luck.

Repeated-edit-shape rule (DEV-EDIT-SHAPE-01, DEFAULT). Three same-shaped edits in a row (the same structural transform applied at different sites) mean you are hand-running a codemod: stop and switch to an AST-based rewrite tool or a scripted transform, so the remaining sites are transformed deterministically. The third identical edit is the signal — by then the transform is known, and continuing by hand is where the divergent site gets missed.

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 (cli-jaw runtime): don't block the turn polling CI/deploys/ web-ai sessions — register cli-jaw bgtask add --cmd '[...]' --prompt "..." and end the turn; the server re-invokes the boss on completion. 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).

Reader deliverables — reports, phase summaries, devlog narrative — follow references/reader-documents.md: the answer first, evidence in an appendix.

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.

Git discipline

• Commit incrementally (DEV-GIT-COMMIT-01, DEFAULT) — each logically complete step (passing test, wired feature, fixed defect) gets its own commit, so progress is checkpointed on disk. This matters most in multi-cycle work, where the transcript is not durable: committed work survives a context flush, uncommitted work does not.
• Push requires explicit user approval (DEV-GIT-PUSH-01, ESCALATE) — committing locally is autonomous; pushing is an external state change the user must authorize. Holds even at completion, and covers force-push, remote branch creation, and tag push. Approval for a named scope ("push when done") is approval for that scope only.
• Stack dependent work instead of one oversized PR (DEV-STACK-01, DEFAULT) — each branch based on the one below, each PR's base pointing at its parent; cascade to every layer above before pushing (DEV-STACK-02, STRICT); merging is bottom-up and user-authorized (DEV-STACK-04, ESCALATE). Depth guidance, layer shape, review scope, anti-patterns, and tooling: references/stacked-prs.md.

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.

9. Sub-Agent Skill Injection and Skill Discovery

Two DEFAULT rules live in references/skill-injection-and-discovery.md:

• DEV-SKILL-INJECT-01 — name jaw-dev and every relevant surface skill explicitly in the dispatch packet. A sub-agent inherits none of yours, and nothing infers an omitted one; an omitted router is an ungoverned lane, not a lighter one.
• DEV-SKILL-DISCOVERY-01 — check the runtime's skill registry before improvising. jaw-dev keeps authority over a discovered skill, and the family wins name conflicts.