Prompts and skills

Turn call notes into a scoped ticket

Convert messy notes from a customer call into a ticket an engineer can start on.

Prompt · works with Any coding agent

Below are my raw notes from a call with a customer. Turn them into one ticket an engineer could pick up tomorrow.

Use this structure:

- Problem: what the customer is trying to do and what stops them, in their words where possible.
- Evidence: numbers, examples or screenshots mentioned in the notes. Do not invent any.
- Proposed change: the smallest change that would unblock them.
- Out of scope: what they asked for that this ticket deliberately does not cover.
- Acceptance check: how we will know it works, as something we can observe in their environment.
- Open questions: anything I need to ask them before work starts.

Keep it under 300 words. Flag anything in the notes that contradicts itself.

Notes:
<paste notes here>

Deploy readiness check

Checks a change is ready to deploy into a customer’s environment and writes a go or no-go note. Use before deploying, or when the user asks whether a branch is safe to ship.

Skill · works with Claude Code, or any agent that loads SKILL.md files

Install it for your user (or swap ~/.claude for .claude to add it to one project):

mkdir -p ~/.claude/skills/deploy-readiness && curl -fsSL https://imsus.dev/skills/deploy-readiness/SKILL.md -o ~/.claude/skills/deploy-readiness/SKILL.md

---
name: deploy-readiness
description: "Checks a change is ready to deploy into a customer’s environment and writes a go or no-go note. Use before deploying, or when the user asks whether a branch is safe to ship."
---

# Deploy readiness check

Decide whether the current branch is ready to deploy into a customer environment, and say why.

## Checks

Run each check and record the command and its result. Do not skip a check because it is slow.

1. **Builds and tests**: run the project's build and test commands. Any failure is a no-go.
2. **Configuration**: list every environment variable, secret or file the change reads. Mark which ones are new and confirm each exists in the target environment, or say it cannot be confirmed.
3. **Data**: find migrations or schema changes. For each, state whether it can be rolled back and what happens to data written in between.
4. **Dependencies**: list added or upgraded packages and any new network destinations.
5. **Rollback**: write the exact steps to undo the deploy.

## Output

Finish with a note of at most 15 lines:

- **Go** or **No-go**, first.
- The reason, in one sentence.
- Each failed or unconfirmed check, with what is needed to clear it.
- The rollback steps.