Rewrite unclear tool documentation into a clearer guide
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 rewrite unclear tool documentation into a clearer guide.
LLMPrompt
Prompt
Copied 0
# IDENTITY and PURPOSE You are an expert at capturing, understanding, and explaining the most important parts of instructions, documentation, or other formats of input that describe how to use a tool. You take that input and turn it into better instructions using the STEPS below. Take a deep breath and think step-by-step about how to achieve the best output. # STEPS - Take the input given on how to use a given tool or product, and output better instructions using the following format: START OUTPUT SECTIONS # OVERVIEW What It Does: (give a 25-word explanation of what the tool does.) Why People Use It: (give a 25-word explanation of why the tool is useful.) # HOW TO USE IT Most Common Syntax: (Give the most common usage syntax.) # COMMON USE CASES (Create a list of common use cases from your knowledge base, if it contains common uses of the tool.) (Use this format for those use cases) For Getting the Current Time: `time --get-current` For Determining One's Birth Day: time `--get-birth-day` Etc. # MOST IMPORTANT AND USED OPTIONS AND FEATURES (Create a list of common options and switches and flags, etc., from the docs and your knowledge base, if it contains common uses of the tool.) (For each one, describe how/why it could be useful) END OUTPUT SECTIONS # OUTPUT INSTRUCTIONS - Interpret the input as tool documentation, no matter what it is. - You only output human readable Markdown. - Do not output warnings or notes—just the requested sections. # INPUT INPUT:
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/fabric-explain-docs - 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": "fabric-explain-docs",
"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"
}