# Release Notes Writer Runbook

## Project Context To Prepare
- Project goal
- Current repository or workflow context
- Current context
- Goal
- Audience or stakeholder
- Constraints
- Available notes or data

## Input Template
Project:

Goal:

Current context:

Constraints:

Available files, notes, or data:

Expected output:
- Release notes
- User-facing changes
- Internal notes
- Caveats

## Starter Inputs
### First useful run
Use this when you know the goal but still need a structured first draft.

Write release notes for the install kit and evaluation feature phase.

Context:
- Current state:
- Constraints:
- Audience:
- Success criteria:

### Project handoff run
Use this when the output will be pasted into a ticket, PR, document, or project brief.

Goal: produce release notes for a real project.
Source material:
- 
Constraints:
- 
Review needs:
- Go deep on the risks and constraints listed above.
- Mark assumptions.
- Flag missing context.

### Boundary check
Use this when the request may be under-specified and you want the agent to narrow it safely.

Announce a release from raw commit hashes with no descriptions.

Before producing the final answer, identify missing required context and propose a stronger prompt if needed.

## Setup Context Notes
- Bring merged changes, release date or boundary, audience, caveats, and support notes.
- Include the target audience, output destination, and any examples of acceptable or unacceptable work.
- Name what should remain out of scope so the agent does not broaden the task.

## Good Input Example
이번 주 배포 내용을 고객과 내부팀에 공유해야 하는 상황

Goal: produce release notes for a real project.
Constraints: keep the result specific, structured, and ready for handoff.

## Weak Input Example
Help me with Release Notes Writer.

## Weak Input Diagnostics
### Help me with Release Notes Writer.
- Why it fails: It does not name the project, source material, constraints, audience, or success criteria.
- Stronger input: Write release notes for the install kit and evaluation feature phase. Include current context, constraints, expected output, and review criteria.

### Make this better.
- Why it fails: The agent cannot tell whether better means clearer, safer, faster, more complete, or easier to hand off.
- Stronger input: Improve the output for 이번 주 배포 내용을 고객과 내부팀에 공유해야 하는 상황. Optimize for release notes, keep assumptions explicit, and list the changes made.

## Expected Output Shape
- Notes for each requested audience, ready to paste
- User notes grouped by what users can now do or what behaves differently, with any action they need to take
- Internal notes, when requested: workflow, tooling, and rule changes contributors must know
- Placeholders such as [version TBD] for anything not yet decided

## Output Checklist
- Every user-visible change appears and each claim traces to a given PR or commit
- Length, language, and format limits are met exactly
- Internal-only changes stay out of the user notes unless they change behavior
- Caveats and trust-affecting changes are stated plainly with what users should do
- No version numbers, dates, metrics, or features were invented

## Failure Modes
- A user-visible change is missing or a claim has no source PR or commit
- Length, language, or format limits are not met
- Dependency bumps or refactors clutter the user notes
- The notes invent a version, date, metric, or unshipped feature, or hide a trust-affecting change

## Handoff Tips
- Paste relevant project files, notes, or constraints before asking for the final output.
- Ask for a first draft, then request a stricter revision using the checklist.
- Keep the generated output with the project ticket, PR, proposal, or team document.