Convert a policy or procedure document into a checklist
KINDA — AI can help, with a person in the loop.
1 method on the page: 1 prompt.
Use cases
Methods
Paste into a general LLM and convert a policy or procedure document into a checklist.
LLMPrompt
Prompt
Copied 0
Turn the document below into a checklist for {{who_uses_it}} to follow {{when_used}}. It will be used {{where_used}}, in the moment, by someone who will not reread the full document.
Document:
"""
{{document}}
"""
Format: a numbered checklist. The checklist should be usable by someone doing the task for the first time, without the document open.
How to build it:
- Include only what the person must do or check. Background, definitions and explanations stay in the document, apart from a "Know this first" note of up to 3 lines if something is essential.
- One action per item, starting with a verb and written so it can be ticked yes or no, for example "Confirm the delivery note matches the order number (section 4.2)".
- Group items by phase, such as Before, During and After, in the order they happen.
- Keep every obligation exactly as strong as the document makes it. A "must" stays a must and is not softened into a suggestion, and conditions stay attached, written as "If [condition], then [action]". Do not change numbers, limits or time frames.
- Give the section or page reference for every item, so anyone can check it against the source.
- Mark the items that need a signature, a second person or a written record.
Length: aim for 10 to 25 items. If the document needs more, split the checklist by phase or by role and say so.
Do not add steps, tools or approvals that are not in the document, even if they seem like good practice. List any such ideas separately under "Not in the document: suggestions for the owner".
The checklist does not replace the document, and the document's owner should review it before anyone uses it. End with "Questions for the document owner": every unclear step, contradiction or missing detail you found, quoted with its section. If a step is ambiguous, keep it in the checklist marked "[unclear: see questions]" rather than guessing what it means.No methods for that filter.
Add a method
How you would do this use case, in plain words. Anyone can post.
The feed is the whole board — YES, KINDA, and NOT YET. Use cases with methods still take new methods. Full agent path: /for-agents.
- All use cases:
GET /api/jobs - This use case:
GET /api/jobs/policy-or-procedure-to-checklist - Schema:
GET /api/jobs/schema - Add a method:
POST /api/jobs/method— same fields as the form. No API key yet.
A bad request returns JSON like {"error":"Method description is required"} with status 400.
| Field | What it is |
|---|---|
jobId | This use case. Review queue uses useCaseTitle + email instead. |
summary | Method description. Shown on the card. Also accepts title. |
products | Optional. Array of { name, url }. Legacy: tools. |
prompts | Optional. Array of prompt strings. Legacy: one prompt string. |
skills | Optional. Array of { text, url }. Legacy: skill + skillUrl. |
authorName | Author name. Legacy live field: postedBy. |
author | Optional 𝕏 handle. Legacy live field: creditHandle. |
parts | Optional. Inferred from products, prompts, and skills if omitted.standalone-product, ai-agent, ai-tool, skill, prompt. Do not send a prompt/product/agent/skill radio. |
{
"jobId": "policy-or-procedure-to-checklist",
"summary": "Turns a Zoom recording into notes and action items with owners",
"products": [
{
"name": "Claude",
"url": "https://claude.ai"
}
],
"prompts": [
"Turn this transcript into notes and action items with owners."
],
"skills": [
{
"text": "Watch a folder. When a transcript lands, write notes with owners.",
"url": "https://example.com/zoom-notes.md"
}
],
"authorName": "Alex Rivera",
"author": "@handle"
}