Skip to content
cccskills
FreePublished on GitHub

production-engineering-practices

Error-handling, security, logging and performance bar for production code. Use when writing or changing production code, before the run ends.

The English summary is being prepared. Showing the original description.

See how to install

Files included (1)

  • SKILL.md4.1 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

Production Engineering Practices

Overview

Acceptance criteria describe the happy path. Production is the unhappy paths: bad input, failed dependencies, concurrent access, hostile users. This skill is the non-negotiable bar every change clears in addition to its AC — the things a reviewer at code_review will bounce you for even when the feature "works."

Core principle: Code isn't done when it works; it's done when it fails safely, leaves a trace, and can't be abused.

The bar

Error handling

  • No swallowed errors. Every error is either handled explicitly or propagated with context. An empty catch/if err != nil { } that continues is a review-blocking defect.
  • Wrap with context at each layer so the log names where it broke: fmt.Errorf("create task: %w", err).
  • User-facing errors are actionable and safe; internal detail (stack, ids) goes to logs, never to the client.

Logging & observability

  • Log at the failure site with structured fields (entity id, operation, not free-text).
  • Never log secrets, tokens, passwords, or full request bodies that may contain them.
  • Log the decision, not the novel — one structured line beats ten prose lines.

Security

  • Validate and bound every external input at the boundary: length, type, range, allowed set. Reject early.
  • Secrets come from config/env — never hardcoded, never committed, never logged.
  • A new endpoint/route gets the SAME auth/authorization guard as its neighbors. Copy the guard, don't omit it.

Performance

  • No N+1 queries or requests — batch, join, preload, or cache. A loop issuing one call per row is a defect.
  • Bound every result set: pagination or explicit limits on list endpoints and list views.
  • Don't load unbounded data into memory; stream or page.

Per stack

StackAdds
BackendParameterized queries only — no string-concatenated SQL, ever.
WebNo dangerouslySetInnerHTML / innerHTML with unsanitised data. Nothing secret in VITE_* / NEXT_PUBLIC_* — those ship to the browser. Every fetch has error and timeout/abort handling, and every route has an error boundary. No token in localStorage unless the repository already does it that way.
MobileTokens in Keychain/Keystore (flutter_secure_storage), never in plain prefs. Explicit offline and timeout paths — a request with no network is a state, not a crash. No PII in logs. Permissions requested at the point of use, not on launch.

Quick self-review before code_review

CheckPass condition
ErrorsNone swallowed; all wrapped with context
InputEvery external field validated and bounded
SecretsNone in code, logs, or commits
AuthNew endpoints/routes guarded like neighbors
Queries/requestsNo N+1; result sets bounded
TestsBehavior change ships with a test in this task

Worked Example

Adding GET /projects/:id/tasks. The AC just says "return the project's tasks." The production bar adds:

  • Validate :id is a UUID → 400 on garbage, before any DB call.
  • The query filters by project_id with a bound parameter and a LIMIT/offset — not SELECT * FROM tasks.
  • The handler reuses the project's auth middleware so a user can't read another tenant's tasks.
  • A structured log line on the DB error path with project_id.
  • Tests: happy path, invalid id → 400, and the pagination bound.

The feature "worked" after the first bullet; it was done after all five.

Handoff

See your prompt's closing step for how to end the run — this skill only sets the bar the diff clears before you get there.

Red Flags

  • "I'll add validation/error handling later" — later is the review bounce.
  • A catch/if err != nil block that does nothing.
  • A list endpoint or list view with no limit.
  • Copying an endpoint or screen but dropping its auth guard.
  • A secret read from VITE_*/NEXT_PUBLIC_*, or a token written to plain prefs on mobile.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

Use when writing acceptance criteria for a task - express each as an observable Given/When/Then that QA can execute, including negative cases

The English summary is being prepared. Showing the original description.

makifbaysal/tasktrooper117Updated Oct 20, 2026

Use when the diff adds or changes an endpoint, resolver, RPC, job or query that takes an object id, a role check, a request binding or a tenant filter - BOLA/IDOR, function-level authorization, mass assignment and tenant scoping

The English summary is being prepared. Showing the original description.

makifbaysal/tasktrooper117Updated Oct 20, 2026

Use on every UI change - semantic HTML, labels for controls, keyboard-navigable dialogs/menus, visible focus, and never color as the only signal

The English summary is being prepared. Showing the original description.

makifbaysal/tasktrooper117Updated Oct 20, 2026

Use when a task changes any screen, form, dialog, menu or control - Lighthouse/axe scan of the changed screens, a keyboard walk, and the thresholds that fail a task

The English summary is being prepared. Showing the original description.

makifbaysal/tasktrooper117Updated Oct 20, 2026

How to work a task returned with review, QA or UAT findings. Use when a task is in need_revision or PR review comments are in your context.

The English summary is being prepared. Showing the original description.

makifbaysal/tasktrooper117Updated Oct 20, 2026

Use when the repository keeps its alerting in code, or a person asks for alerts outside TaskTrooper - PrometheusRule YAML, a Cloud Monitoring alert policy in Terraform, a Datadog monitor, each routed to TaskTrooper's alert ingest URL so it opens an incident here

The English summary is being prepared. Showing the original description.

makifbaysal/tasktrooper117Updated Oct 20, 2026

See all skills by makifbaysal

Report a problem with this skill