# Operations SOP Agent 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:
- SOP document
- Step checks
- Exceptions
- Done criteria

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

Write an SOP for installing and validating project agent kits.

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 SOP document 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.

Standardize a new process nobody has performed yet.

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

## Setup Context Notes
- Bring the trigger, owner, repeated steps, handoff points, exceptions, and quality checks.
- 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
Process: adding a new project-ready agent.
Owner: content maintainer.
Inputs: approved slug, agent metadata, runbook, evaluation, sample runs.
Quality bar: check:data, lint, build pass before handoff.
Output: step-by-step SOP with review checkpoints and rollback notes.

## Weak Input Example
Write an SOP for agent stuff.

## Weak Input Diagnostics
### Help me with Operations SOP Agent.
- Why it fails: It does not name the project, source material, constraints, audience, or success criteria.
- Stronger input: Write an SOP for installing and validating project agent kits. 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 SOP document, keep assumptions explicit, and list the changes made.

## Expected Output Shape
- Trigger, owner, and roles
- Prerequisites: access, inputs, and data
- Numbered steps, one action each, with the exact tool or field and a "Check:" line
- Exceptions: situation, action, and who decides
- Done criteria and rollback
- Unrequested improvements kept to one line each under "Optional improvements"

## Output Checklist
- Every step, rule, common mistake, and exception the request names appears in the step where it happens
- Each named mistake has a check that catches it
- Missing tools, thresholds, or contacts are written as [TBD: ...], not invented
- Legal, financial, and policy decisions are routed to the responsible person
- Includes trigger, owner, exceptions, and done criteria

## Failure Modes
- The SOP omits the trigger or owner
- Steps have no check showing they worked
- Exceptions are missing or have no decision owner
- The SOP states legal or policy rulings instead of routing them

## 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.