Engineering bar

Apply this to the current diff, not the whole product. Walk each section and assess each applicable item using the shared evidence statuses. The invoking skill controls whether edits are authorized: reviews report failures; implementation fixes failures within scope. Only the user may waive a failure or verification gap. Do not invent extra standards this repo does not use.

If AGENTS.md exists, follow it. Repo-specific commands win when they conflict with examples here. You still must not commit secrets or claim unverified results.

How to load

Other skills load this file, first readable:

1. ../engineering-bar/SKILL.md (sibling of the calling skill)
2. .agents/skills/engineering-bar/SKILL.md from the workspace
3. ~/.agents/skills/engineering-bar/SKILL.md

Secret files

Fail commit and ready-to-merge (and any secret scan) if the change adds:

• .env, .env.* except a tracked .env.example
• private keys, *.pem, *.p12, id_rsa, id_ed25519
• credential files, keystores, dumped tokens
• secrets pasted into otherwise-normal files

Shared procedures

Load references/change-scope.md and references/evidence.md relative to this skill directory for change collection, base selection, result statuses, and evidence reuse. These are the shared procedures for all checks. If a required procedure is unavailable, report the assessment as incomplete rather than inventing a pass.

Repository defaults

Always-on defaults belong to the repository's AGENTS.md. If missing, use ../explore-codebase/references/agents-template.md when available; do not maintain a second defaults list here. Apply this bar even when no template is available.

Correctness

• Acceptance checks from shape-work (if any) are met, or the task is not done.
• Happy path, edge cases, and error paths that this change can hit are handled.
• No empty catch / swallowed rejection / ignored error return.

Minimum path

Understand the problem first (read the code the change touches). Then stop at the first rung that holds:

1. Need? If the request is speculative, skip it and say so.
2. Already here? Reuse the helper, type, or pattern in this repo. Do not rewrite it.
3. Stdlib? Use the language or runtime library.
4. Native platform? Prefer a built-in (HTML control, CSS, DB constraint, OS API) over a new component or dependency.
5. Already installed? Use a dependency that is already in the lockfile. Do not add a new one for a few lines of code.
6. One line? Prefer it when it stays correct on edge cases.
7. Only then write the minimum that works.

Do not climb past a rung that already solves it. The smallest change in the wrong place is a second bug.

Never cut to win a smaller diff: validation at trust boundaries, error handling that prevents data loss, authorization, secret handling, or accessibility of new interactive UI. User-requested behavior stays.

If you accept a known ceiling (global lock, naive scan, in-memory only), say the ceiling and the trigger to revisit in the summary. Do not invent a comment brand.

Change hygiene

• Diff is the smallest change that satisfies the request after the Minimum path.
• No unused code, no commented-out blocks, no unrelated cleanup.
• No interface/factory/config for a single implementation or a value that never changes.

Structure

• Logic lives in the layer that already owns that concept.
• Do not grow a hard-to-scan file when a split is obvious.
• Do not add a flag or mode that turns one function into two programs.

Failure

• I/O (network, disk, subprocess, queue) has a timeout or the repo's equivalent.
• Retries are bounded and safe to repeat, or there are no retries.
• Failures carry enough context to debug (what failed, which id) and never carry secrets.

Data

• Input is validated where it enters the system (handler, edge, parser).
• Schema and public contract changes are expand, then deploy, then contract — not both in one step.
• Lists, pages, and jobs are bounded. Unbounded load is a fail.

Security (this delta only)

• New reachable surface has authorization, not only authentication, if this repo uses auth.
• Untrusted input stays untrusted (query, path, HTML, command, header, file name).
• Secrets are not in source, logs, client bundles, or fixtures.

Performance (guard, not heroics)

• No new query/RPC inside a loop (N+1).
• No unbounded work on a request or UI path.
• No accidental full-collection scan.
• No huge eager import on a hot route.

Do not "optimize" without a measurement unless the diff clearly adds one of the above. Guess-caching is a fail.

UI

When the diff adds or changes interactive UI, routes, views, or layout:

• New controls have an accessible name, are reachable from the keyboard, and are not unreadable.
• No layout jump from images, embeds, or fonts with no reserved size.
• Empty, error, and loading states the change can hit are handled (or already were).

The walk-through is verify-ui. This section is the bar.

Operability

• A new failure mode is visible with whatever this repo already uses (log, metric, trace, error report).
• Risky behavior has a rollback sentence you can say out loud (revert, flag, prior artifact).
• Docs, types, or generated clients that this change made wrong are updated in the same work.

Output

Report failures, unverified requirements, and user waivers, then the checks and evidence used. Explicitly identify remaining assessed sections as pass or not applicable; silence is not evidence of a pass.