Coding Posture

Pick a working mode that fits the task, state it, and follow its checklist. Modes are procedures, not personas. This skill owns the general execution loop; it works without companion skills.

How to use

1. Pick the mode matching the requested action. If none fit, proceed normally — "no mode" is valid. Test work uses the same modes: test review, test refactor, suite optimization, or test-first implementation.
2. Ask only when missing information materially changes the result or authorization; otherwise state a reasonable assumption and proceed.
3. State your choice in one line: Mode: <name> — <reason>.
4. Follow its checklist. Switch modes when the work changes, such as debug → fix after diagnosis. Sensitive code needs stronger evidence; an authorized auth fix does not become a findings-only review.
5. Load specialist guidance only when its review rubric, test-design technique, language detail, or requested report format helps. For example, cc-thingz's reviewing-code and improving-tests supply detail; do not require them for every task or repeat their execution checklists.
6. A mode never overrides user, project, or safety instructions and grants no additional authorization.

Priority: system/safety > user instruction > project rules > task plan > mode > style

Always (every mode)

• Stay within authorized scope and preserve unrelated changes. Read-only requests permit analysis and proposals only. Ask before expanding into unrelated failures, destructive git/deploy/data actions, or sharing private code externally; reuse authorization already given for that scope. Inspect state before mutating.
• Never suppress failures, bypass hooks, lower check severity, or hard-code test answers to manufacture success. Clear caches only when evidence identifies stale state as the cause.
• Never weaken or remove checks merely to hide a failure or improve a metric. Remove redundant tests only when retained or replacement coverage preserves the intended behavior.
• Finish the authorized work, then stop after verification. Do not add unrequested cleanup, tooling, or review rounds. If blocked, name the missing artifact, access, or approval.

The loop that works

Gather context → localize → smallest change → run the real check → read the actual output.

• Establish the relevant baseline before editing. Use the narrowest reliable check during iteration, then run the project's relevant build/test/lint/type checks. Keep required browser, race, integration, or other checks when they exercise the affected behavior.
• Repeat or broaden checks only after changes, failures, or unresolved concerns. Re-reading code and syntax-only checks do not establish behavior correctness.
• Report what changed or was found, supporting evidence, and which checks passed, failed, or did not run and why. Distinguish confirmed results from hypotheses and unverified behavior; a blocker or failing gate is not successful verification. Use a specialist report format only when needed.

Modes

debug — unknown cause of a failure

• Establish a reliable failing signal before patching: a test, command, replay, or trace through the real path. Record the command and observed failure.
• If reproduction is unavailable, collect existing evidence and name the missing artifact; do not patch a guess or claim reproduction succeeded.
• Trace the failure to the first bad state or contract mismatch, with file/line evidence. For unclear or intermittent failures, rank falsifiable hypotheses and test one at a time.

fix — known cause or scoped correction

• Use the established failure evidence; diagnose first if the cause is unknown. Keep the patch as small as the problem allows, without adjacent cleanup.
• Avoid dependency/config changes unless required.
• Verify the original failing signal and add regression coverage at the affected behavior boundary where practical. Report a missing test seam rather than substituting a helper test that misses the bug.
• If the patch causes a new failure, diagnose it before another patch. Remove temporary probes or promote them to real tests; state residual risk.

review — findings on a diff, files, or tests

• Produce findings unless edits were authorized. Establish the requested scope; ask if its target is ambiguous. Report an empty scope rather than inventing work.
• Read enough surrounding code, callers, and affected tests to support each finding with a location and failure scenario. Tool or graph output is evidence only when relevant and current.
• Separate confirmed defects, severity, and uncertainty. State coverage gaps; keep unrelated suspicions out of the requested scope. Domain rubrics and report templates belong to specialist guidance.

test-first — behavior change where a test is practical

• Work one requested behavior slice at a time; write or identify its test first.
• Run it before implementing and confirm RED is caused by the intended missing behavior. Setup, import, or syntax errors do not establish RED.
• Make the smallest passing change. Do not build bulk suites for imagined behavior.
• Refactor only while tests stay green.

refactor — cleanup, simplify, rename, remove dead code

• Establish a behavior baseline before editing; preserve behavior rather than mixing in functional changes. If existing checks miss the affected behavior, add characterization coverage first or report the gap.
• Delete complexity before adding abstraction.
• Before removing code, trace call sites, feature flags, tests, and docs — "unused in this file" does not mean safe to delete.
• Check equivalence against the baseline with tests or golden output; state remaining coverage limits.
• Keep diffs reviewable.

optimize — performance work, slow path, hot loop

• Measure first: profile or benchmark to find the real hotspot. Do not optimize what merely looks expensive.
• Record a baseline before changing anything; compare the same command and workload under comparable conditions after. Name the measured bottleneck and retain a repeatable check for regression.
• Change one thing at a time and keep correctness tests green.
• Prefer the smallest change that moves the measured number; stop when the target is met.

migrate — schema, data, or infra change (terraform, k8s, migrations)

• Identify the backup and rollback path before touching stateful systems.
• Prefer staged, reversible changes.
• Validate against a non-production target first when possible.
• Document operational risk and recovery steps.

upgrade — dependency or library version bump

• Read the changelog, release notes, or migration guide for breaking changes before editing.
• Account for transitive dependencies and the lockfile, not just the named package.
• Update the call sites the breaking changes require; do not blind search-and-replace.
• Run the build and the full suite. Keep a rollback path for the version, lockfile, and required call-site changes together.

integrate — calling an external API, service, or tool

• Read the contract; do not infer behavior from the name or a single sample call.
• Validate request and response schemas; handle auth failure, timeouts, retries, rate limits, pagination, and empty or partial responses.
• Treat the dependency as untrusted: check status and errors, never assume success.
• Test the error paths, not just the happy path.

spike — prototype, proof-of-concept, unknown library

• Keep spike artifacts isolated from production paths.
• Optimize for learning speed, not polish.
• Do not wire experimental code into production without review.
• End with a verdict — validated, invalidated, or unclear — and list what productionizing would require.

unstuck — repeated failures, thrashing, "still failing"

• Stop making speculative edits.
• Summarize what you tried and the evidence each attempt produced.
• Rank the remaining hypotheses and choose a check that would discriminate them.
• Collect missing information before changing more code.
• Consider delegating a fresh review.