Setup Guide
Turns code, config files and install logs into a setup guide where every step shows the command and the result to expect.
When to use itUse it when a project works on your machine but nobody else can get it running from the docs. Paste a terminal log of a working install if you can: the model cannot run the steps, so expected results come from what you supply or get flagged.
- Type
- Playbook
- Inputs it asks for
- 05
- Sections it returns
- 06
- Quality checks
- 08
On this page5 sections
Asks for
What you hand it before it runs. Required ones are marked.
- 01Source materialLong textRequired
What the guide is built from: README fragments, package manifest, Dockerfile or compose file, .env.example, install scripts, CLI --help output, a terminal log of a working install. Only what is here gets documented.
- 02Tested againstText
Version, commit or release the material describes, and the date the steps were last run, e.g. v2.4.1, run on 2026-10-10. Left blank, the guide flags it.
- 03ReaderText
Who follows the guide and what they already know, e.g. backend developers comfortable with Docker but new to this service.
- 04Platforms and shellsText
Operating systems and shells to cover, e.g. macOS and Linux with bash or zsh, Windows with PowerShell. Left blank, the guide follows the source.
- 05Known issuesLong text
Errors people actually hit and their fixes, from issues, support threads or your own runs. Troubleshooting uses only these and errors visible in the source.
Method
The instruction the model follows, word for word as it ships in the SKILL.md.
You write a setup guide from the Source material. The Technical Documentation Writer rules apply throughout (source only, [VERIFY] flags and the To verify list, show then explain, action plus expected result, ALL_CAPS placeholders, labelled shell syntax, precise verbs). This method adds only what is specific to setup guides.
The guide succeeds when a reader matching the Reader field can go from a machine without the software to a confirmed working install using only this page.
Structure:
- H1: the project name from the source followed by "setup", for example "# billing-service setup". Directly under it, one line: "Tested against: " followed by the Tested against value. If Tested against is blank, write "Tested against:
[VERIFY: version and date last run]". - Prerequisites: everything needed before step 1, as bullets: tools with minimum versions, accounts, access rights, API keys, free ports. State a version only when the source gives one (an engines field, .nvmrc, a Dockerfile base image, existing docs); otherwise name the tool and flag the version. Nothing the reader needs may first appear later in the guide.
- Installation: numbered steps, one action each. Each step is a short imperative sentence, the code block, then a line starting "Expected result:". Take expected output from logs in the source where they exist. Where the Platforms and shells listed need different commands, give each in its own labelled block under the same step.
- Configuration: a table with the columns Name, Required, Default, Description, covering every environment variable or config key the source defines and no others. Follow it with one complete example file (such as .env) using placeholders for secrets. If the source shows no configuration, write "No configuration found in the supplied material." and flag it.
- Verify the installation: one or two commands or requests that prove the install works end to end, each with its exact expected result.
- Troubleshooting: up to five issues, taken only from Known issues and from error messages visible in the source. Give each an H3 with the exact error text or symptom, then a Cause line and a Fix. If neither supplies any, write "No known issues supplied." Generic "common problems" are guesses, so leave them out.
- To verify: the numbered list of every
[VERIFY]flag, each with its section or step and what would settle it.
The shape of one installation step (shape only; the content must come from the source):
Example
bash
docker compose up -d db
`
Expected result: docker compose ps lists db with the status running`.Length: as short as the steps allow, and under about 900 words of prose excluding code. If the Source material shows no way to install or run the software, ask up to three specific questions instead of writing the guide.
Returns
Every reply comes back in this shape, in this order.
- 01Prerequisites
- 02Installation
- 03Configuration
- 04Verify the installation
- 05Troubleshooting
- 06To verify
Quality checks
Read the reply against these before you use it. Tick them off as you go; nothing is saved.
0 of 8 checked
SKILL.md
The whole playbook as one skill file, for Claude, Codex or any tool that reads SKILL.md.
---name: "setup-guide"description: "Turns code, config files and install logs into a setup guide where every step shows the command and the result to expect."--- # Setup Guide You write a setup guide from the Source material. The Technical Documentation Writer rules apply throughout (source only, [VERIFY] flags and the To verify list, show then explain, action plus expected result, ALL_CAPS placeholders, labelled shell syntax, precise verbs). This method adds only what is specific to setup guides. The guide succeeds when a reader matching the Reader field can go from a machine without the software to a confirmed working install using only this page. Structure:- H1: the project name from the source followed by "setup", for example "# billing-service setup". Directly under it, one line: "Tested against: " followed by the Tested against value. If Tested against is blank, write "Tested against: [VERIFY: version and date last run]".- Prerequisites: everything needed before step 1, as bullets: tools with minimum versions, accounts, access rights, API keys, free ports. State a version only when the source gives one (an engines field, .nvmrc, a Dockerfile base image, existing docs); otherwise name the tool and flag the version. Nothing the reader needs may first appear later in the guide.- Installation: numbered steps, one action each. Each step is a short imperative sentence, the code block, then a line starting "Expected result:". Take expected output from logs in the source where they exist. Where the Platforms and shells listed need different commands, give each in its own labelled block under the same step.- Configuration: a table with the columns Name, Required, Default, Description, covering every environment variable or config key the source defines and no others. Follow it with one complete example file (such as .env) using placeholders for secrets. If the source shows no configuration, write "No configuration found in the supplied material." and flag it.- Verify the installation: one or two commands or requests that prove the install works end to end, each with its exact expected result.- Troubleshooting: up to five issues, taken only from Known issues and from error messages visible in the source. Give each an H3 with the exact error text or symptom, then a Cause line and a Fix. If neither supplies any, write "No known issues supplied." Generic "common problems" are guesses, so leave them out.Used together with
- 01Technical Documentation WriterWrites setup guides, API references, READMEs and runbooks from your source material, and flags anything it cannot confirm.Operator
- 02API Endpoint ReferenceTurns route code, schemas or captured requests into endpoint reference docs with parameter tables, full examples and error fixes.Playbook
- 03READMEWrites a README from your manifest, code and tests: what it does, a quick start of five steps or fewer, real usage examples and licence.Playbook
Free to use and adapt under CC BY 4.0. Credit MyPromptVerse.
Built in MyPromptVerse. Follow the build →