# Security Checklist 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:
- Security checklist
- Check methods
- Pass criteria
- Gaps

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

Review risks for a public submit-agent form before adding persistence.

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 security checklist 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.

Certify that a payments integration is compliant.

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

## Setup Context Notes
- Prepare feature scope, data handled, trust boundaries, dependencies, and deployment context.
- 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
사용자 입력 폼과 API route를 배포하기 전 점검하는 상황

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

## Weak Input Example
Help me with Security Checklist Agent.

## Weak Input Diagnostics
### Help me with Security Checklist Agent.
- Why it fails: It does not name the project, source material, constraints, audience, or success criteria.
- Stronger input: Review risks for a public submit-agent form before adding persistence. 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 사용자 입력 폼과 API route를 배포하기 전 점검하는 상황. Optimize for security checklist, keep assumptions explicit, and list the changes made.

## Expected Output Shape
- Checklist grouped by the surfaces the user named: the risk in one line, how to check it (file, command, config, or test), the pass criterion, and severity if it fails
- Gaps: risks the architecture cannot mitigate under the stated constraints, and what compensates
- One-line notes where a common risk does not apply to this architecture
- Generic hardening ideas kept to one line each under "Also consider"

## Output Checklist
- Every component, data flow, and permission the user described has a concrete attack and an exact check
- Each item has a pass criterion and a severity
- Risks that do not apply are dismissed in one line with the reason
- No configuration, versions, or findings were invented
- Does not certify the system as secure or write a "no issues" statement

## Failure Modes
- Items name generic categories instead of the concrete attack on the named component
- An item has no way to check it or no pass criterion
- The checklist invents configuration, versions, or findings
- The output certifies the system as secure or writes a "no issues" statement

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