agentleFS
Baba01hacker666Baba01hacker666/dummyskills/skills/readme-writer/SKILL.md

readme-writer

Skill0 starsChanged 2 months agoMITView on GitHub

Generates an accurate, standard README.md based strictly on verified repository facts, prerequisites, and runnable commands.

  • Installs packages

23 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use security-audit.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • CloudflareSkill

    security-audit

    Security guidance and vulnerability review for codebases, APIs, services, CLI tools, libraries, and daemons. Use for security questions, focused reviews, vulnerability research, security audits, or pen tests. Run the complete workflow only for explicit codebase audit or pen-test requests, full/comprehensive/end-to-end reviews, or requested report artifacts.

    Also in 3 projects that use this

The file

We split this skill into the rules it gives an agent

10 rules. 0 are common, 5 are distinctive, and 5 are very specific to this project.

  • 0

    Common

    Most of the 18 edited versions we read keep these.

  • 5

    Distinctive

    This author's own choices. Worth a look.

  • 5

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use this skill when:

    line 14
  2. Very specific:

    Do not use to write a narrative walkthrough tutorial.

    line 20
  3. Very specific:

    Do not use to map codebase internals without writing docs.

    line 21
  4. Very specific:

    If commands (install, test, build) are not provided: inspect package.json, Cargo.toml, pyproject.toml, or Makefile in workspace_root.

    line 29
  5. Distinctive:

    Do not document CLI flags or options that cannot be verified in the source code.

    line 30
  6. Very specific:

    If license is unknown, check LICENSE file on disk before specifying.

    line 31
  7. Distinctive:

    Follow these numbered actions:

    line 34
  8. Very specific:

    If no test command exists: omit "Running Tests" or write No automated tests configured.

    line 49
  9. Distinctive:

    Keep total length concise (< 500 lines).

    line 50
  10. Distinctive:

    Stop and ask the user when:

    line 99

“Common” is measured: kept by at least 6 in 10 of the 18 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

README Writer

Creates a factual, developer-ready README.md. Gathers information exclusively from verified repository manifests and commands—never inventing imaginary features or unverified flags.

1. Purpose

Provide newcomers with a clean, truthful overview of a codebase. A "README" covers project goal, prerequisites, quickstart installation, basic usage, and test commands.

2. When to Use

Use this skill when:

  • Creating a new project or open-source repository.
  • Overhauling a missing or outdated README.md.
  • User asks: "Generate a README for this repository."

3. When Not to Use

  • Do not use to write a narrative walkthrough tutorial; use step-by-step-tutorial.
  • Do not use to map codebase internals without writing docs; use repo-inspector.

4. Required Inputs

  • project_name: Name of the project (string).
  • workspace_root: Directory of the project to inspect for package manifests.
  • description: 1-2 sentences on what the project does.

5. Missing-Input Behavior

  1. If commands (install, test, build) are not provided: inspect package.json, Cargo.toml, pyproject.toml, or Makefile in workspace_root.
  2. Do not document CLI flags or options that cannot be verified in the source code.
  3. If license is unknown, check LICENSE file on disk before specifying.

6. Procedure

Follow these numbered actions:

  1. Action 1: Verify Stack & Prerequisites
    • Identify required runtime (Node.js, Python, Rust, Go) and minimum version from manifests.
  2. Action 2: Verify Key Commands
    • Confirm install command (npm install), build command (npm run build), and test command (npm test).
  3. Action 3: Structure Standard Sections
    • Title & description.
    • Prerequisites.
    • Quickstart (Installation & Usage).
    • Running Tests.
    • Contributing & License.
  4. Action 4: Emit Markdown Document
    • Format using Section 8.

7. Decision Rules

  • If no test command exists: omit "Running Tests" or write No automated tests configured. Do not invent a command.
  • Keep total length concise (< 500 lines); link to subdocuments for detailed manuals.

8. Output Format

Emit the README content using this template:

# [Project Name]

[Short, clear summary of what the project does in 1-2 paragraphs.]

## Features
- [Verified Feature 1]
- [Verified Feature 2]

## Prerequisites
- [Runtime and version, e.g. Node.js >= 20.0.0]
- [Package manager, e.g. npm or pnpm]

## Installation
```bash
[Verified installation command]

Quickstart / Usage

[Verified minimal usage command or code snippet]

Running Tests

[Verified test command]

License

[License type, e.g. MIT - see LICENSE file]


## 9. Verification Checklist
- [ ] Every listed command exists in project configuration.
- [ ] Prerequisites match actual engine/runtime constraints.
- [ ] No fake badges, fake metrics, or ungrounded claims.
- [ ] Code examples are syntactically complete.

## 10. Common Failures and Recovery
| Failure Symptom | Cause | Recovery Action |
| :--- | :--- | :--- |
| Hallucinating CLI flags | Assuming common flags exist | Run `<bin> --help` or check source code parser. |
| Inaccurate prerequisites | Guessing version | Read `package.json -> engines` or `.nvmrc` / `runtime.txt`. |

## 11. Stop or Escalation Conditions
Stop and ask the user when:
- Project purpose cannot be deduced from repository files.

## 12. Examples

### Example 1: Successful Execution
**Input:**
```text
Project: logger-lite
Stack: Node.js, package.json scripts: { "test": "mocha tests" }
Description: Zero-dependency JSON logger for microservices.

Output:

# logger-lite

Zero-dependency JSON logger for microservices. Formats structured logs with timestamp, log level, and process ID.

## Features
- Zero external dependencies.
- Automatic ISO-8601 timestamps.
- NDJSON output for log ingestion pipelines.

## Prerequisites
- Node.js >= 18.0.0
- npm

## Installation
```bash
npm install logger-lite

Quickstart

const { Logger } = require('logger-lite');
const log = new Logger();

log.info('Application started', { port: 8080 });

Running Tests

npm test

License

MIT


### Example 2: Ambiguous or Missing Input
**Input:**
```text
Write README for unknown project in empty folder.

Output:

### README Writer: Halted - No Project Data

- **Status**: Halted

Cannot generate an accurate README for an empty workspace. Please provide:
1. The project name and purpose.
2. The programming language / runtime.
3. The expected build and test commands.

Example 3: Expected Final Output

Output:

# csv-cleaner

Fast CLI utility to clean trailing spaces and normalize delimiters in CSV files.

## Prerequisites
- Python >= 3.10

## Installation
```bash
pip install -e .

Usage

csv-cleaner input.csv --output clean.csv

Running Tests

pytest tests/

License

MIT

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.