APromptAura

#production

Top prompts tagged production.

0
p/metaAauraNovice4 days agohas example⁂auto-checked

Write a changelog entry when you revise a production prompt

I'm about to ship a change to a production prompt. Help me write a proper changelog entry so future me (or a teammate) understands why this changed, not just what changed. Given the old prompt, new prompt, and the reason for the change: old_prompt / new_prompt / reason_for_change 1. Write a one-line summary of the behavioral change (what output difference a user would actually notice), not a description of the wording diff. 2. State the specific evidence that motivated this change (a failure example, a user complaint, an eval regression), quoting or referencing it concretely, not 'seemed like it could be better'. 3. List what you tested this new version against before shipping (which inputs, how many, what the pass rate was) so there's a record of validation, not just intent. 4. Flag any known tradeoff this change introduces (e.g. fixes case A but might make case B slightly worse, or increases average token count) so it's not discovered as a surprise later. 5. Note the rollback condition: what signal in production would indicate this change should be reverted. Old prompt: old_prompt New prompt: new_prompt Reason for change: reason_for_change Test results if any: test_results
ClaudeGPT#prompt-versioning#changelog#production
0
0
p/agentsAauraNovice4 days agohas example⁂auto-checked

Postmortem prompt for analyzing a production agent failure

Help me write a postmortem for an agent failure in production: failure_description. Unlike a typical software incident, agent failures often involve reasoning errors, not just code bugs, so structure this specifically for that: 1. Reconstruct what the agent actually 'believed' at each decision point leading to the failure, based on the transcript/logs, not what the system prompt intended it to believe - these can diverge and that gap is often the real root cause. 2. Classify the failure type: was it a tool-use error (wrong tool, wrong args), a reasoning error (correct tools, faulty logic connecting them), a grounding error (hallucinated a fact not in its context), or a scope error (did something outside its intended authority)? Pick the primary one, don't hedge across all four. 3. Identify whether this was a one-off (bad luck, a genuinely ambiguous edge case) or systemic (the prompt/design would produce this again given a similar input) - if systemic, what's the smallest input class that reliably triggers it. 4. Propose a fix at the right layer: prompt change, tool design change, or added guardrail/verification step, and explain why a fix at a different layer (e.g. 'just tell it to be more careful') wouldn't actually prevent recurrence. 5. Propose a regression test: a specific input that should be added to an eval set to catch this class of failure before future deploys. Failure transcript/logs: failure_transcript System prompt at time of failure: system_prompt
Claude#postmortem#agent-debugging#production
0
0
p/codingAauraNovice4 days agohas example⁂auto-checked

Zero-downtime database schema migration plan

I need to make this schema change: change_description on table table_name in database (production, actively serving traffic, row_count rows). Produce a plan that avoids locking the table for writes and avoids breaking currently-deployed application code during the rollout. Structure: 1. Break the change into safe, backward-compatible steps (e.g. add-nullable-column before backfill before add-constraint before drop-old-column), each deployable independently. 2. For each step, specify: the exact DDL, whether it takes a lock and for how long is acceptable, and what application code version must already be deployed before this step runs. 3. Backfill strategy: batched, with a way to pause/resume, and an estimate of how long it will take given the row count. 4. The order in which application code changes and migration steps must be deployed relative to each other (expand/contract pattern), stated explicitly as a sequence. 5. A rollback plan for each step that doesn't require restoring from backup. 6. What to monitor during the backfill (replication lag, lock wait time, error rate) to know if it's safe to keep going.
ClaudeGPT#sql#migration#database#production
0