write-tech-readme
Writes or revises a repository README that helps the intended reader understand, try, use, and navigate a technical project.
Synopsis
User-invoked. Name this skill when you want the agent to apply it. disable-model-invocation is true.
Source file: skills/write-tech-readme/SKILL.md.
Front matter
- name
write-tech-readme- description
- Writes or revises a repository README that helps the intended reader understand, try, use, and navigate a technical project.
- disable-model-invocation
true
Full contents
---
name: write-tech-readme
description: Writes or revises a repository README that helps the intended reader understand, try, use, and navigate a technical project.
disable-model-invocation: true
---
# Write a README
Read [write-tech-core](../write-tech-core/SKILL.md) first.
A README is the repository's front door. It should help the intended reader
decide whether the project fits, reach one useful result, and find the next
authoritative document.
## Inspect the repository
Before writing, identify:
- the project's exact name, audience, and verified purpose;
- its maturity and support status, when stated;
- one supported installation and usage path;
- tested prerequisites and observable output;
- existing docs, contribution policy, support policy, license, and badges.
Prefer manifests, tests, CI, release files, and current commands over old README
copy. Do not infer policy from common repository conventions.
## Output contract
Use the smallest supported subset of this order:
1. Project name and one plain sentence explaining what it does.
2. A minimal verified example that shows its value.
3. Requirements and one supported installation method.
4. Basic usage and expected result.
5. Links to existing guides or reference material.
6. Verified compatibility, project status, contributing, support, and license
information.
Optimize the first screen for recognition and first use. Use concrete nouns and
commands. Keep detailed tutorials, full reference, architecture, and project
history in linked documents.
This contract overrides requests to complete a generic README template. Before
returning the README, delete unsupported badges, features, install methods,
benchmarks, architecture, configuration, roadmap, contribution rules, support
channels, and acknowledgments. Do not keep empty headings or "not published"
sections. Do not invent repository URLs, package pages, files, commands,
policies, performance claims, or future work.
Do not create a Features, Motivation, or Architecture section merely to
rephrase the one-sentence purpose or usage example. A heading must add verified
information that helps the reader decide, use, or navigate.
When the input is a closed fact set and no repository was inspected, limit the
README to the name, purpose, verified example, requirements, installation,
usage, and license. Use only the applicable items. Do not add badges, links,
files, or process commentary in this mode.
## Badges and links
Every badge is a live factual claim. Include it only when its image, target,
repository, branch, and metric are verified. Prefer a few useful badges over a
status wall.
Use relative links for files in the repository. Check every local path and
anchor. Link to one canonical location for details instead of copying content
that will drift.
## Verification gate
Run the quick example and installation path when safe. Check the minimum
version against project configuration. Confirm output, filenames, links,
license identity, package name, and executable name. Do not call an example
quick, safe, portable, or fast without evidence.
## Example
```markdown
# Pebble
Pebble removes duplicate blank lines from standard input.
## Install
Requires Rust 1.80.
`cargo install pebble`
## Use
`printf 'a\n\n\nb\n' | pebble`
Output: `a\n\nb`
## License
MIT
```
Return the README only.