How do I use one of these templates?

Open it and the editor loads a copy pre-filled, named and ready to edit. It becomes an ordinary document in your list of open tabs: rename it, rewrite it, export it, or close it without saving.

Do I need an account?

No. There are no accounts on this site at all. The template is fetched by your browser and filled into the editor locally; nothing about it reaches a server.

Will my edits be saved?

Yes, in this browser. Documents autosave to local storage on your own device, so closing the tab and coming back keeps your work. They are not synced anywhere and are not readable by us.

Can I export the finished document?

Yes, PDF, Word, standalone HTML or Markdown, all from the editor's Export menu. Every conversion runs in your browser, which is what keeps an unpublished draft or a private resume off the network.

Are the AI templates different from the others?

Only in subject. CLAUDE.md, AGENTS.md and llms.txt are ordinary Markdown files that happen to be read by coding assistants and language models rather than by people, so the conventions around them are newer and less settled.

Can I suggest a template?

The list follows what people actually search for, so the useful ones tend to surface on their own. A template earns a place here when it has a real structure worth getting right, rather than being a blank file with a heading.

Markdown templates

Every file a project is expected to have, ready to take. Fill in a few boxes and the placeholders update across the whole document, then copy it, download it, or open it in the editor. No repository to clone, no account, and nothing leaves your browser.

Set up a repository in one go

Tick what you need and fill these in once: the same project name and contact go into every file, and the zip keeps the paths, so .github/pull_request_template.md lands where GitHub looks for it. Built here in the page; nothing is uploaded.

Project name

GitHub owner/repo

Contact email

README.md what it is and how to run it

# Project Name

> One sentence saying what this does and who it is for.

[![Build](https://img.shields.io/badge/build-passing-brightgreen)](https://example.com)
[![License](https://img.shields.io/badge/license-MIT-blue)](LICENSE)

Two or three sentences of context. What problem does this solve, and why would
someone pick it over the obvious alternative? Answer that here and most of your
issue tracker never gets written.

## Install

```sh
npm install project-name
```

## Usage

```js
import { thing } from 'project-name';

const result = thing('input', { option: true });
console.log(result);
```

## API

### `thing(input, options?)`

| Parameter | Type | Default | Description |
| :--- | :--- | :--- | :--- |
| `input` | `string` | None | The thing to process. Required. |
| `options.option` | `boolean` | `false` | What this switches on. |

Returns a `Result` object.

## Configuration

Create a `project.config.js` in your project root:

```js
export default {
  option: true,
};
```

## Contributing

Pull requests are welcome. For anything larger than a typo fix, open an issue
first so we can agree on the approach before you spend time on it.

```sh
git clone https://github.com/you/project-name
npm install
npm test
```

## License

[MIT](LICENSE) © Your Name

CONTRIBUTING.md how to send a change

# Contributing

<!--
  CONTRIBUTING.md is linked automatically by GitHub from the new-issue and
  new-pull-request pages. Its job is to answer the questions a first-time
  contributor would otherwise have to ask: how do I run this, what will you
  accept, and how long will you take.
-->

Thanks for considering it. This file covers how to get the project running and
what happens to a pull request once you open one.

## Getting set up

```sh
git clone https://github.com/you/project.git
cd project-name
npm install
npm test
```

If `npm test` does not pass on a clean checkout, that is a bug: please open an
issue rather than working around it.

## Before you start something large

Open an issue first. A short conversation about the approach saves a large pull
request being turned down for a reason that had nothing to do with the code.

Small fixes (a typo, a broken link, an obvious bug) need no discussion. Send
them straight in.

## Making a change

1. Branch from `main`
2. Make the change, with tests
3. Run `npm test` and `npm run lint`
4. Write a commit message that says what changed and why

<!-- If you use conventional commits, semantic versioning or a changelog file,
     say so here: it is the single most common reason a first pull request
     needs a second round. -->

## Opening the pull request

Fill in the template. The section reviewers read first is *how to test it*, so
say what they should observe rather than just which command to run.

Expect a first response within a week. If it has been longer, a comment on the
pull request is welcome and not rude.

## What gets accepted

- Bug fixes, with a test that fails without the fix
- Documentation, including small corrections
- Features that were discussed in an issue first

## What usually does not

- Reformatting unrelated files, which makes the real change unreviewable
- New dependencies, unless the alternative is genuinely worse
- Changes to the public API without a deprecation path

## Reporting a bug

Include the version, what you expected, what happened instead, and the smallest
example that reproduces it. A reproduction is worth more than a description.

Security issues go to **security@example.com** rather than to the issue
tracker.

## Code of conduct

Taking part means following the [Code of Conduct](CODE_OF_CONDUCT.md).

CODE_OF_CONDUCT.md and how to report a problem

# Code of Conduct

<!--
  Most projects adopt the Contributor Covenant rather than writing their own: it is the version maintainers and contributors already recognize, and
  recognition is most of the value. This is a shorter document in the same
  spirit. Whichever you use, the part that matters is the reporting address:
  a code of conduct with no working way to report is decoration.
-->

## Our commitment

This project is a place to work on software. Everyone taking part should be
able to do that without harassment, whoever they are.

## Expected behavior

- Assume the other person is acting in good faith
- Give feedback on the work, not on the person who wrote it
- Accept that a decision can go against you and the discussion is still over
- Take responsibility for mistakes and fix them

## Unacceptable behavior

- Harassment, whether in public or in private
- Sexualised language, imagery or attention
- Personal or political attacks, insults, and sustained disruption
- Publishing someone's private information without their permission

## Scope

This applies in every project space (the repository, issues, pull requests,
discussions and chat) and in any place where someone is representing the
project.

## Reporting

Report a problem to **conduct@example.com**. Reports go to the maintainers
listed below and are handled in confidence.

<!-- Name the people, not just the address. A report goes to someone. -->

- Maintainer Name (@handle)
- Maintainer Name (@handle)

Anyone reporting in good faith will not face consequences for having done so.

## What happens next

1. **Acknowledged** within a few days, in writing
2. **Reviewed** by maintainers not involved in the incident
3. **Decided**, and the outcome shared with the person who reported it

Depending on what happened, the outcome may be a private warning, a temporary
ban from project spaces, or a permanent one.

## Attribution

Adapted in spirit from the [Contributor Covenant](https://www.contributor-covenant.org).

.github/pull_request_template.md what a reviewer needs

<!--
  .github/pull_request_template.md

  GitHub loads this into the description box of every new pull request in the
  repository. Keep it short: a template long enough to skim past is a template
  people delete without reading.

  Comments like this one are invisible in the rendered description, so they can
  carry instructions without cluttering the result.
-->

## What this changes

<!-- One or two sentences. What is different after this merges? -->

## Why

<!-- The problem, or a link to the issue. Reviewers who know why can spot a fix
     that solves the wrong thing. -->

Closes #

## How to test it

<!-- The steps a reviewer follows to see it working. "Run the tests" is not
     enough, say what they should observe. -->

1.
2.
3.

## Screenshots

<!-- Before and after, for anything visible. Delete this section otherwise. -->

## Notes for the reviewer

<!-- Anything that would otherwise arrive as a review comment: a decision you
     are unsure about, a file worth reading first, a follow-up you deliberately
     left out. -->

## Checklist

- [ ] Tests cover the change, and pass
- [ ] Documentation updated, or not needed
- [ ] No secrets, keys or personal data in the diff
- [ ] Breaking changes called out above

SECURITY.md where to report a vulnerability

# Security Policy

<!--
  SECURITY.md goes in the repository root, .github/ or docs/. GitHub links it
  from the Security tab and shows it to anyone about to open a public issue
  about a vulnerability, which is the whole point. Without this file, the
  first report you get will be a public issue describing how to exploit you.
-->

## Reporting a vulnerability

Please **do not open a public issue**.

Email **security@example.com** with:

- what the issue is, and what an attacker could do with it
- the smallest steps that reproduce it
- the version or commit you tested
- whether it is already public anywhere

<!--
  GitHub's private vulnerability reporting is the better route if the
  repository has it enabled: Settings > Code security > Private vulnerability
  reporting. It gives the reporter a tracked, private thread and a draft
  advisory, with no shared inbox to secure. If you enable it, say so here and
  keep the email as a fallback.
-->

You can also report privately through the repository's **Security** tab, under
*Report a vulnerability*.

## What happens next

| When | What |
| :--- | :--- |
| Within 3 working days | We acknowledge the report |
| Within 10 working days | We confirm the issue and give a rough timeline |
| On release | We publish a fix and credit you, unless you prefer otherwise |

If a report goes unacknowledged past that first window, send a follow-up: it
means the mail went astray, not that it was ignored.

## Supported versions

<!-- Be honest here. "Latest only" is a perfectly good answer and far better
     than a table implying support you will not provide. -->

| Version | Supported |
| :--- | :--- |
| 2.x | Yes |
| 1.x | Security fixes until 2027-01-01 |
| < 1.0 | No |

## Scope

In scope: the code in this repository, and its published packages.

Out of scope:

- Anything in a dependency: report those upstream, and tell us if we should
  pin or patch in the meantime
- Findings from automated scanners with no demonstrated impact
- Missing hardening headers on the project website, absent an actual attack
- Social engineering, physical access, and denial of service by brute volume

## Disclosure

We aim to release a fix before any public detail. If you plan to publish,
please give us **90 days**, or less by agreement if the fix ships sooner. We
will credit you in the advisory and the changelog unless you would rather stay
anonymous.

We do not run a paid bug bounty.

CHANGELOG.md what changed, per release

# Changelog

All notable changes to this project are documented here.

The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).

## [Unreleased]

### Added

- Anything already merged but not yet released goes here, so the release notes
  write themselves on the day.

## [2.1.0]: 2026-07-14

### Added

- Export to PDF from the command line (`--export pdf`).
- `--quiet` flag for use in scripts.

### Changed

- Config files are now resolved from the project root rather than the working
  directory. Running from a subdirectory picks up the same config as running
  from the root.

### Deprecated

- `--legacy-parser`. It still works and will be removed in 3.0.

### Fixed

- Files over 2 GB no longer fail with a misleading "permission denied".
- Windows paths containing spaces are handled correctly.

## [2.0.0]: 2026-05-02

### Removed

- **Breaking:** dropped Node 18. The minimum is now Node 20.
- **Breaking:** `parse()` no longer accepts a callback. Use the returned promise.

### Security

- Updated a transitive dependency with a prototype-pollution advisory
  ([CVE-2026-1234](https://example.com)).

## [1.4.2]: 2026-03-11

### Fixed

- Restored the exit code on parse failure, which 1.4.1 changed by accident.

[Unreleased]: https://github.com/you/project/compare/v2.1.0...HEAD
[2.1.0]: https://github.com/you/project/compare/v2.0.0...v2.1.0
[2.0.0]: https://github.com/you/project/compare/v1.4.2...v2.0.0
[1.4.2]: https://github.com/you/project/releases/tag/v1.4.2

AGENTS.md what a coding agent needs

# AGENTS.md

Instructions for any coding agent working on Project Name (a single,
predictable place for the things it needs) the
things a new human contributor would be told on their first day, written down
once instead of repeated in every prompt.

## Project overview

What this repository contains, what it is for, and the constraint that matters
most. Keep it to a paragraph.

## Setup

```sh
npm install
cp .env.example .env
npm run db:migrate
```

Node 20 or later. The `.env` defaults point at local services; nothing here
talks to production.

## Commands

| Command | What it does |
| :--- | :--- |
| `npm run dev` | Dev server on port 3000 with hot reload |
| `npm test` | Full test suite: must pass before committing |
| `npm run lint` | Lint and format check |
| `npm run build` | Production build into `dist/` |

## Code style

- TypeScript, strict mode, no implicit `any`.
- Two-space indent, single quotes, semicolons. Prettier decides; do not argue
  with it in review.
- Named exports. Default exports only where a framework demands one.
- Match the surrounding file's idiom over any rule in this list.

## Testing

Run `npm test` before every commit. New behavior needs a test; a bug fix needs
a test that fails without the fix. Do not mark a task complete with failing
tests, say what is failing instead.

## Pull requests

- One logical change per PR.
- Imperative title: `Add retry to the export queue`.
- The body explains why the change is needed and what you considered instead.
- Never commit secrets, `.env` files, or anything under `tmp/`.

## Boundaries

- Do not modify `db/migrations/` without asking: migrations are irreversible
  in production.
- Do not add dependencies without asking.
- `src/vendor/` is generated. Edit the generator, not the output.

## Where to ask

Open a draft PR with your question in the description, or ask in `#project-dev`.

Prefer one at a time? Every file below has its own page, with the same boxes and a preview.

AI and agent files

The files coding assistants and language models read instead of guessing. New enough that the conventions are still settling: these follow what the tools actually look for.

CLAUDE.md file

CLAUDE.md 57 lines

What Claude Code reads before it touches your repository: commands, conventions and traps.
- What this project is
- Commands
- Layout
- Conventions
- Testing
- Things that will bite you
- +1 more
Fill it in or open it in the editor
AGENTS.md file

AGENTS.md 63 lines

One instructions file the coding agents agreed on, instead of one per vendor.
- Project overview
- Setup
- Commands
- Code style
- Testing
- Pull requests
- +2 more
Fill it in or open it in the editor
llms.txt file

llms.txt 33 lines

A Markdown map of your site for language models: one file, at the root.
- Docs
- Examples
- Optional
Fill it in or open it in the editor
Copilot instructions file

copilot-instructions.md 57 lines

What Copilot reads before every request in the repo, and the one line that keeps it from drifting.
- What this project is
- Stack
- Commands
- Conventions
- Do not
- Things that will bite you
Fill it in or open it in the editor
SKILL.md file

SKILL.md 68 lines

The file that defines an agent skill, and the one field that decides whether it ever gets used.
- When to use this
- Workflow
- Conventions
- Reference
Fill it in or open it in the editor

Project files

The documents a repository is expected to have. Each one answers a question a newcomer arrives with, which is the only reason any of them are worth writing.

README template

README.md 61 lines

Install, usage, an API table and contributing notes: the sections that stop your issue tracker filling up.
- Install
- Usage
- API
- Configuration
- Contributing
- License
Fill it in or open it in the editor
Changelog template

CHANGELOG.md 58 lines

Keep a Changelog structure, semantic version headings, and comparison links that stay correct.
- [Unreleased]
- [2.1.0]: 2026-07-14
- [2.0.0]: 2026-05-02
- [1.4.2]: 2026-03-11
Fill it in or open it in the editor
CONTRIBUTING.md template

CONTRIBUTING.md 74 lines

How to run it, what gets accepted, and how long a review takes: the three questions people ask first.
- Getting set up
- Before you start something large
- Making a change
- Opening the pull request
- What gets accepted
- What usually does not
- +2 more
Fill it in or open it in the editor
Code of conduct template

CODE_OF_CONDUCT.md 58 lines

Expected behavior, unacceptable behavior, and a reporting route that names actual people.
- Our commitment
- Expected behavior
- Unacceptable behavior
- Scope
- Reporting
- What happens next
- +1 more
Fill it in or open it in the editor
SECURITY.md template

SECURITY.md 73 lines

Where to send a vulnerability, what happens next, and what is out of scope.
- Reporting a vulnerability
- What happens next
- Supported versions
- Scope
- Disclosure
Fill it in or open it in the editor

GitHub workflow

The files GitHub reads from special locations and turns into part of the interface.

Pull request template

pull_request_template.md 47 lines

What changed, why, and how to check it: short enough that nobody deletes it before typing.
- What this changes
- Why
- How to test it
- Screenshots
- Notes for the reviewer
- Checklist
Fill it in or open it in the editor
GitHub profile README

profile-README.md 41 lines

A business card, not a CV: one screen, with the special repository name that makes it appear.
- What I'm working on
- What I know well
- Elsewhere
Fill it in or open it in the editor

Writing

Documents that are read by people rather than by tooling, where the structure is the hard part and the words are yours.

Markdown resume template

resume.md 48 lines

A CV in plain text: version it, diff it, and export a clean PDF whenever you need one.
- Experience
- Skills
- Education
- Projects
Fill it in or open it in the editor
Meeting notes template

meeting-notes.md 51 lines

Decisions first, discussion second, actions in a table with owners and dates.
- Agenda
- Decisions
- Discussion
- Actions
- Next meeting
Fill it in or open it in the editor
Blog post template

blog-post.md 59 lines

Front matter, a structure that opens with the answer, and the sections readers actually quote.
- The problem
- What I tried first
- What actually worked
- Results
- What I would do differently
Fill it in or open it in the editor

Which file do I need?

You want to…	The file
Explain what a project is and how to run it	`README.md`
Tell contributors how to send a change	`CONTRIBUTING.md`
Set expectations for behavior, and how to report	`CODE_OF_CONDUCT.md`
Give reviewers what they need on every pull request	`pull_request_template.md`
Tell people where to report a vulnerability	`SECURITY.md`
Record what changed, per release	`CHANGELOG.md`
Tell any coding agent how to work in the repo	`AGENTS.md`
The same, specifically for Claude Code	`CLAUDE.md`
Package a capability an agent loads on demand	`SKILL.md`
The same, specifically for GitHub Copilot	`copilot-instructions.md`
Point language models at the right pages of a site	`llms.txt`
Put something on your GitHub profile page	profile `README.md`
Write a CV you can export to PDF	`resume.md`

If a repository needs several of these, the box above builds them together: one project name into every file, and the paths already right.

What a template is here

A starting document, not a wizard. Opening one creates an ordinary tab in the editor with the text already in it: you rewrite the parts that matter, delete the parts that do not, and export whatever you end up with. There is no lock-in and nothing to undo, because it is just a Markdown file from the first keystroke.

The structures are opinionated on purpose. A README template that is only a heading and a blank line saves nobody any time; the value is in knowing which sections earn their place and what order a reader wants them in.

Each page carries the whole file, not an excerpt, so you can read it before deciding, and copy it by hand if you would rather not use the form. The form only saves typing: it replaces the placeholders in one pass, so a project name entered once fills the title, the install line and every URL that mentions it.

Why plain text for documents like these

A resume, a changelog and a set of meeting notes have the same three problems in common: they are edited under time pressure, they need to outlive whichever app you wrote them in, and they are often private. Markdown answers all three: the layout cannot break while you type, the file opens in anything, and here the conversion to PDF or Word happens on your own device rather than on someone's server.

Common questions

How do I use one of these templates?: Open it and the editor loads a copy pre-filled, named and ready to edit. It becomes an ordinary document in your list of open tabs: rename it, rewrite it, export it, or close it without saving.
Do I need an account?: No. There are no accounts on this site at all. The template is fetched by your browser and filled into the editor locally; nothing about it reaches a server.
Will my edits be saved?: Yes, in this browser. Documents autosave to local storage on your own device, so closing the tab and coming back keeps your work. They are not synced anywhere and are not readable by us.
Can I export the finished document?: Yes, PDF, Word, standalone HTML or Markdown, all from the editor's Export menu. Every conversion runs in your browser, which is what keeps an unpublished draft or a private resume off the network.
Are the AI templates different from the others?: Only in subject. CLAUDE.md, AGENTS.md and llms.txt are ordinary Markdown files that happen to be read by coding assistants and language models rather than by people, so the conventions around them are newer and less settled.
Can I suggest a template?: The list follows what people actually search for, so the useful ones tend to surface on their own. A template earns a place here when it has a real structure worth getting right, rather than being a blank file with a heading.