agentleFS
Sign inStart free
diegopachecodiegopacheco/agent-skills/readme-skill/SKILL.md

readme-skill

Skill0 starsChanged 3 months agoUnlicenseView on GitHub

When need to create README.md for a project, use this skill to create a README.md file. IF user mentiond README.md, use this skill.

4 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

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

  • 0

    Common

    Most of the 3 edited versions we read keep these.

  • 8

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Never do ACII ART for architecture diagrams

    line 8
  2. Distinctive:

    Always do Excalidraw-style diagram.

    line 9
  3. Distinctive:

    When there is UI always use Playwright MCP to take print screens, add on printscreens/ folder on the project and always load, refer, render …

    line 10
  4. Distinctive:

    IF there is a logo, always display/render in the begining of the README

    line 11
  5. Distinctive:

    Never leak information from the local machine into README.md.

    line 25
  6. Distinctive:

    Never write absolute paths, home directories (/Users/<name>, /home/<name>, ~), machine names, usernames, IPs, ports bound to the local …

    line 26
  7. Distinctive:

    Only use paths relative to the root of the current GitHub repo.

    line 27
  8. Distinctive:

    Never reference files, folders or projects outside the current repo.

    line 28

“Common” is measured: kept by at least 6 in 10 of the 3 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.md

  • Never do ACII ART for architecture diagrams
  • Always do Excalidraw-style diagram. Rendered a hand-drawn flow diagram (wobble filter + "Caveat" handwriting font, pastel boxes, solid capture path). Makle sure nothing overlaps.
  • When there is UI always use Playwright MCP to take print screens, add on printscreens/ folder on the project and always load, refer, render the images and explain on README.md
  • IF there is a logo, always display/render in the begining of the README
  • README of solutions must have:
    • Logo (display/render in the begining of the README)
    • What the project is/dos after the logo.
    • How it Works? (3-15 lines max)
    • Architecture
    • Features (list of features with 1-2 lines MAX explaining why)
    • Stack (list list with 1 line explaining why)
    • Contracts/APIs (Swagger if apply other wise simple REST API description)
    • key datastructures and software design decision if any
    • How to run the app/tests
    • Printscreens of the UI (all tabs), render/display the printscreens on README.md and explain what is happening on each printscreen.

Privacy

  • Never leak information from the local machine into README.md.
  • Never write absolute paths, home directories (/Users/<name>, /home/<name>, ~), machine names, usernames, IPs, ports bound to the local network, emails, tokens, keys or env values.
  • Only use paths relative to the root of the current GitHub repo.
  • Never reference files, folders or projects outside the current repo.
  • Printscreens and images are a leak risk by default: capture only the app window/viewport, never the full screen.
  • Printscreens must not show anything outside the app window: no desktop, no dock, no menu bar, no notifications, no other windows or tabs, no browser bookmarks, no address bar with local paths, no personal data.
  • Printscreens must never show local paths, terminals, shells, IDEs, file explorers, or processes/services running on the machine outside the current git repo.
  • Crop or retake any printscreen that captured something outside the repo app, and delete the original file.
  • Strip image metadata (EXIF, author, device, location) before committing printscreens.
  • Scrub command outputs and logs pasted into the README of any local path or personal information.
  • The only exception is when the user explicitly asks and acknowledges the leak.

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.

Check your setup, free