mcpField
W
write-readme

write-readme

github.com/gkwaDocuments091 installsUpdated 1d ago
Repository

About write-readme

A writing skill for concise project READMEs. It prescribes a single CLI cheatsheet code block, with each command introduced by a brief comment, and keeps prose outside the block.

Key features

  1. 01Keep README prose brief
  2. 02Show CLI examples in one code block
  3. 03Label commands with one-line comments
  4. 04Avoid separate blocks for each example
  5. 05Treat command output as optional

Use cases

  1. 01Create a concise README for a CLI
  2. 02Reorganize scattered command examples
  3. 03Document commands without invented output
  4. 04Keep explanatory prose separate from examples

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/gkwa/volcanicviper --skill write-readme

After installing, type/write-readmein Claude Code to confirm it loaded.

Bundled filestile.json

Details

From the project README

README: Be Brief

When writing a README, be brief. Do not include licensing or contribution sections.

Always show a cheatsheet that demonstrates the command-line interface. Show the CLI in a code block with a short one-line comment above it indicating its purpose.

The Shape

One code block holds every invocation, each under its own one-line comment.

Do not give each example its own fenced block, its own prose sentence, or its own heading.

# find files where tags include "python"
islandiguana ./notes '.tags[] == "python"'

# find files up to 1 level deep
islandiguana --max-depth 1 ./notes '.tags[] == "python"'

# delete a front matter key from all matched files
islandiguana ./notes '.filetype == "product"' --mutate 'del(.filetype)'

Prose belongs above or below the block, explaining what the tool is and any rule the reader cannot guess.

Prose does not belong between the commands.

Output

Showing output is optional, and most cheatsheets do not.

The rule that captured output must be real rather than invented governs any output you choose to show. It never requires an example to show output, and it never justifies pairing every command with an output block.

When a command's result is the point, such as a JSON record or a parse error, show that one.

Comments

Markdown supported