agentleFS
varunk130varunk130/ai-workflow-playbooks/skills/production-awareness/SKILL.md

production-awareness

Skill2 starsChanged 6 months agoMITView on GitHub

Think about production consequences at every stage of development, not just at deployment time.

The file

We split this skill into the rules it gives an agent

10 rules. About 0 are common, 10 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈10

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Every external dependency will eventually fail.

    line 25
  2. Distinctive:

    Network calls: Always have a timeout, retry policy, and fallback behavior

    line 27
  3. Distinctive:

    Use connection pool limits with appropriate max/min

    line 37
  4. Distinctive:

    Check available space before large writes

    line 41
  5. Distinctive:

    Use atomic write patterns (write to temp, rename)

    line 42
  6. Distinctive:

    Treat production data with care at every level:

    line 46
  7. Distinctive:

    Can this be debugged?: - Add structured logging at decision points

    line 65
  8. Distinctive:

    Can this be scaled?: - Avoid server-local state.

    line 68
  9. Distinctive:

    Can this be configured?: - Use environment variables for values that differ across environments

    line 69
  10. Distinctive:

    Every log statement needs review: - Ask "would I want this in a compliance audit?"

    line 83

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Production Awareness

What This Skill Enables

An agent that considers how code will behave in production - under real load, with real data, facing real failures - while writing it, not after shipping it. Without this skill, agents write code that works in development but fails under production conditions: high concurrency, network failures, malformed data, resource exhaustion, and hostile input.

Core Competencies

1. Production Mental Model

While writing any code, ask these questions:

QuestionWhy It Matters
What happens at 100x current load?Linear algorithms become bottlenecks; database connections exhaust
What happens when this external call fails?Network timeouts, retries, and circuit breakers become essential
What happens with unexpected input?User-generated content includes Unicode, injection attempts, and extreme lengths
What happens when disk/memory fills up?Unbounded logs, caches, and queues cause cascading failures
What happens during a deploy?In-flight requests, database migrations, and cache invalidation need handling

2. Failure Mode Awareness

Every external dependency will eventually fail. Design for it:

Network calls: Always have a timeout, retry policy, and fallback behavior

GOOD: fetch(url, { signal: AbortSignal.timeout(5000) })
       .catch(err => fallbackResponse)

BAD:  fetch(url)  // hangs forever if the server doesn't respond

Database queries: Handle connection pool exhaustion, slow queries, and deadlocks

  • Set query timeouts
  • Use connection pool limits with appropriate max/min
  • Log slow queries above a threshold

File system: Handle disk full, permission denied, and race conditions

  • Check available space before large writes
  • Use atomic write patterns (write to temp, rename)
  • Handle ENOENT and EACCES explicitly

3. Data Safety

Treat production data with care at every level:

  • Never log sensitive data: passwords, tokens, PII, credit card numbers
  • Never trust input size: enforce limits on request bodies, file uploads, query parameters
  • Never expose internals: stack traces, database schemas, internal paths in error responses
  • Always validate at boundaries: data from users, APIs, message queues, and even your own database (data can be corrupted)

4. Resource Awareness

Know the resource profile of your code:

ResourceProduction Concern
MemoryUnbounded caches, large object allocations in loops, memory leaks from unclosed resources
CPUSynchronous heavy computation blocking the event loop, regex backtracking, JSON parsing of huge payloads
ConnectionsDatabase connection pool exhaustion, HTTP keep-alive limits, socket leaks
DiskLog rotation, temp file cleanup, upload storage limits
External rate limitsThird-party API quotas, email sending limits, OAuth token refresh rates

5. Operational Readiness Thinking

While writing code, consider operational needs:

  • Can this be debugged? - Add structured logging at decision points
  • Can this be monitored? - Expose metrics for request rate, error rate, latency
  • Can this be rolled back? - Database migrations should be reversible
  • Can this be scaled? - Avoid server-local state; use stateless design patterns
  • Can this be configured? - Use environment variables for values that differ across environments

6. Graceful Degradation

Design systems that bend instead of break:

  • Return cached/stale data when the live source is down (with a warning)
  • Disable non-critical features rather than crashing the entire service
  • Queue work for later when downstream systems are temporarily unavailable
  • Shed load intentionally (rate limiting) rather than collapsing under pressure

Behavioral Rules

  1. Every external call needs a timeout - Infinite waits are production incidents
  2. Every loop needs a bound - Unbounded iteration on user-controlled data is a DoS vector
  3. Every error needs handling - Unhandled exceptions crash processes
  4. Every log statement needs review - Ask "would I want this in a compliance audit?"
  5. Every feature needs a kill switch - Feature flags allow disabling code without deploying

Failure Modes

FailureSymptomCorrection
"Works on my machine" thinkingCode fails under production load, data volume, or network conditionsTest with realistic data sizes and failure scenarios
No timeouts on external callsRequests hang indefinitely; thread/connection pool exhaustsAdd timeouts to every network call, database query, and file operation
Logging sensitive dataCompliance violation discovered in production logsAudit every log statement for PII, tokens, and credentials
Unbounded resource usageMemory leaks, disk fills up, connection pools exhaustSet explicit limits on caches, queues, pools, and temporary storage
No fallback behaviorOne dependency failure cascades into full system outageImplement graceful degradation for every external dependency

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.