Run any Skill in Manus with one click

readme

Stars2

Forks0

UpdatedJune 25, 2026 at 09:35

Use when the user asks to write or fix a README following the Standard Readme spec, add the Serokell public-repo promo blurb, or set up per-component READMEs in a multi-package repo. Triggers on phrases like "write a README", "fix the README", "Standard Readme", "short description for readme", "promo blurb", "README per package", "README required sections".

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

serokell

serokell/metatemplates

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

name	readme
description	Use when the user asks to write or fix a README following the Standard Readme spec, add the Serokell public-repo promo blurb, or set up per-component READMEs in a multi-package repo. Triggers on phrases like "write a README", "fix the README", "Standard Readme", "short description for readme", "promo blurb", "README per package", "README required sections".

README.md

Every Serokell repository must have a README.

Standard Readme

The README must comply with the Standard Readme spec.

Standard Readme distinguishes required sections (must be present) from optional sections (include only when applicable).

Required (in spec order):

Title — single # Name heading.
Short description — a single line, <120 characters, immediately after the title. Should match the package-manager description field and the GitHub repo description.
Install — how to install / build.
Usage — how to use it; CLI examples; the most common operations.
Contributing — link to CONTRIBUTING.md if it exists, or inline guidance.
License — SPDX identifier and link to LICENSE.

Optional (include when applicable, in spec order between short-description and license):

Banner — logo / illustration.
Badges — license, CI status, package-registry presence. (Start with just a license badge if there is nothing else yet.)
Long description — what the project does and why, in more detail.
Table of contents — required if the README is over ~100 raw lines (count .md file lines, not rendered output).
Security — when applicable.
Background — when context is needed.
API / CLI — when the project exposes one.
Maintainers — list of people responsible.
Thanks — acknowledgements.

Public-repo additions

If the repository is public, include the standard Serokell promotional blurb at the end. The template README in this repo (look for the "About Serokell" section) is the reference for that text.

Multi-component repos

If the repo contains multiple independent components (e.g. several packages / libraries in subdirectories), each component's directory must also contain its own Standard-Readme-compliant README. Treat "independent component" as a semi-formal criterion — use your judgement.

Forks

If the repository is a fork, explain why the fork exists at the very top of the README (in the master branch). Without this, nobody will know whether the fork is still needed two months later.

Pitfall: do not mirror the metatemplates README shape

The README in the serokell/metatemplates repository itself is not Standard-Readme-compliant — it is a placeholder template. Do not copy its shape into your real README. Rewrite from scratch to match the spec.

When customising the README for a new repo created from this template, strip every [//]: # (...) meta-comment. Verify with:

git grep '\[\/\/\]:'

The above should return nothing in a finished README.

More from this repository

same repository

bootstrap-repo

serokell/metatemplates

Use when the user asks to create a new Serokell repository, bootstrap a fresh repo from `metatemplates`, fork an external repo into the Serokell org, initialize a new project, or sequence the full new-repo setup (create → customise → license → CI → settings). Triggers on phrases like "create a new Serokell repo", "bootstrap this repo", "set up a fresh repo", "fork this repo into serokell", "initialize new project", "new repo from metatemplates", "start a new project", "first commit on a new repo".

2026-06-252

changelog

serokell/metatemplates

Use when the user asks to add a changelog entry, set up a `CHANGES.md` / `CHANGELOG.md` file, document user-facing changes in a release, or write a migration note for a breaking change. Triggers on phrases like "add to changelog", "CHANGES.md entry", "document this release", "release notes", "breaking change migration note", "what's new", "user-facing changes".

2026-06-252

code-review

serokell/metatemplates

Use when the user asks to review a pull request, leave review comments, decide between approve / request changes / comment, or resolve conversations on someone else's PR. Triggers on phrases like "review this PR", "leave a code review", "approve or request changes", "review someone's PR", "resolve this conversation", "PR review comments", "comment on the PR".

2026-06-252

code-testing

serokell/metatemplates

Use when the user asks to add tests, write a regression test for a bug, set up CLI execution tests or coverage in CI, or pick the kind of test (unit / property / blackbox / acceptance) to write. Triggers on phrases like "add a test for this", "write a regression test", "add test coverage", "test this CLI", "property-based test", "fuzzing", "what kind of test should I write", "edge-case test".

2026-06-252

committing-work

serokell/metatemplates

Use when the user asks to commit work, draft a commit message, create a branch for an issue, or make a fixup commit in a Serokell repo. Triggers on phrases like "commit these changes", "draft a commit message", "create a branch for this issue", "make a fixup commit", "git commit", "what should the branch be called", "Problem/Solution".

2026-06-252

gitignore

serokell/metatemplates

Use when the user asks to add patterns to `.gitignore`, fix imprecise ignore patterns, decide between project / global / local-only ignores, or set up `.gitignore` for a new Haskell or multi-language repo. Triggers on phrases like "add to gitignore", "ignore these files", "fix gitignore", "what goes in gitignore", "global git ignore", "ignore build output", ".stack-work", "dist-newstyle", "editor files in gitignore".

2026-06-252

name	readme
description	Use when the user asks to write or fix a README following the Standard Readme spec, add the Serokell public-repo promo blurb, or set up per-component READMEs in a multi-package repo. Triggers on phrases like "write a README", "fix the README", "Standard Readme", "short description for readme", "promo blurb", "README per package", "README required sections".

README.md

Every Serokell repository must have a README.

Standard Readme

The README must comply with the Standard Readme spec.

Standard Readme distinguishes required sections (must be present) from optional sections (include only when applicable).

Required (in spec order):

Title — single # Name heading.
Short description — a single line, <120 characters, immediately after the title. Should match the package-manager description field and the GitHub repo description.
Install — how to install / build.
Usage — how to use it; CLI examples; the most common operations.
Contributing — link to CONTRIBUTING.md if it exists, or inline guidance.
License — SPDX identifier and link to LICENSE.

Optional (include when applicable, in spec order between short-description and license):

Banner — logo / illustration.
Badges — license, CI status, package-registry presence. (Start with just a license badge if there is nothing else yet.)
Long description — what the project does and why, in more detail.
Table of contents — required if the README is over ~100 raw lines (count .md file lines, not rendered output).
Security — when applicable.
Background — when context is needed.
API / CLI — when the project exposes one.
Maintainers — list of people responsible.
Thanks — acknowledgements.

Public-repo additions

If the repository is public, include the standard Serokell promotional blurb at the end. The template README in this repo (look for the "About Serokell" section) is the reference for that text.

Multi-component repos

Forks

If the repository is a fork, explain why the fork exists at the very top of the README (in the master branch). Without this, nobody will know whether the fork is still needed two months later.

Pitfall: do not mirror the metatemplates README shape

When customising the README for a new repo created from this template, strip every [//]: # (...) meta-comment. Verify with:

git grep '\[\/\/\]:'

The above should return nothing in a finished README.