write-tech-getting-started
Writes or revises a getting-started tutorial that takes a new user through one verified path to an early, visible success.
Synopsis
User-invoked. Name this skill when you want the agent to apply it. disable-model-invocation is true.
Source file: skills/write-tech-getting-started/SKILL.md.
Front matter
- name
write-tech-getting-started- description
- Writes or revises a getting-started tutorial that takes a new user through one verified path to an early, visible success.
- disable-model-invocation
true
Full contents
---
name: write-tech-getting-started
description: Writes or revises a getting-started tutorial that takes a new user through one verified path to an early, visible success.
disable-model-invocation: true
---
# Write a getting-started guide
Read [write-tech-core](../write-tech-core/SKILL.md) first.
A getting-started guide is a lesson. Its product is the learner's first
successful experience, not complete product coverage.
## Define success
Record privately:
- the learner and the knowledge they bring;
- the exact starting state;
- one observable end state;
- the shortest verified path between them;
- the environment where the path was tested.
If several platforms or methods exist, choose one supported default. Put
alternatives in another page or after the first success.
## Output contract
Use this order:
1. **Outcome.** State what the learner will make or observe.
2. **Prerequisites.** List only items the steps actually require.
3. **Install.** Give one verified method and a command or state check.
4. **Do.** Use numbered steps. Each step has one action, the exact command or
edit, and the expected result.
5. **Confirm.** Show the end state and how the learner knows it worked.
6. **Next steps.** Link to verified how-to, explanation, and reference pages
only when those pages exist.
Give the learner a meaningful result early. Explain only enough to make the
next action intelligible. Point out what changed after each important step.
This contract overrides a request for comprehensive product coverage. Before
returning the draft, delete `Architecture`, `Configuration`, and `Deployment`
headings and their contents. Delete `Troubleshooting` unless every entry has a
supplied or observed symptom, verified cause, and tested recovery. Do not turn
missing evidence into content.
## Scope gate
Architecture, full configuration, deployment, alternatives, and exhaustive
troubleshooting are separate reader needs. Omit them from the first-success
path. If the prompt asks for one of these without supplying verified material,
do not create its heading. At most, use one final sentence naming the deeper
docs the reader needs. A caveat-filled section is still out of scope.
Add troubleshooting only for a verified failure the learner may encounter on
this exact path. Include the observed symptom, cause, and tested recovery.
## Verification gate
Run the sequence from the stated starting state when safe. Test commands in
order, not separately. Match expected output exactly enough for recognition.
Check that names, paths, versions, and working directories remain consistent.
If the sequence was not run, state that outside the guide when commentary is
allowed. Never make an untested guide sound tested.
## Example
```markdown
# Get started with Flint
Install Flint and start a new project.
## Install
Run:
`curl -fsSL https://flint.example/install.sh | sh`
Check the install:
`flint --version`
Expected output: `flint 1.2.0`.
## Create and run a project
1. Run `flint init demo`.
Flint creates `demo/flint.toml`.
2. Run `cd demo`.
3. Run `flint run`.
Flint prints `Listening on http://localhost:4040`.
```
This is complete at the first verified result. It does not infer what listens
at the URL, how to stop it, what `flint.toml` means, or how to deploy it.
Return the guide only.