INDEX.md

Template index

Every template in the repository, with what each one is for. Use this when you know the document you want and not where it lives.

If you don't know what you need yet, start from the README and read the group README for your area — it tells you which documents earn their place and which to skip.

Areas: General software engineering · Web development · Game development · Data engineering · Platform engineering · AI-assisted development

---

General software engineering

Documents any software team needs, whatever the domain. → general-swe/

Foundations — methodology-agnostic

→ general-swe/foundations/

Document	What it's for
Architecture decision record	Record one significant decision, the options weighed, and why this one won.
Architecture overview	Explain how the system fits together to someone who has never seen it.
Branching strategy	State how code moves from a developer's machine to production.
Bug report	Describe a defect so someone else can reproduce and fix it.
Changelog	Tell users what changed in each release, in their terms.
Code review guidelines	Set what reviewers look for, so review stops being personal taste.
Coding standards	Settle the style arguments once, in writing.
Configuration management plan	Define what is version-controlled, how it's identified, and who can change it.
Contributing guide	Tell outside contributors how to make a change you'll accept.
Data model	Document the entities, their fields, and the rules connecting them.
Deployment plan	Set out the steps, checks, and rollback for a specific release.
Deprecation plan	Retire something without stranding the people using it.
Feature request	Ask for something the software doesn't do, starting from the problem.
Glossary	Fix what the team's domain words mean, so two people don't use one word differently.
Governance	Say what happens when people disagree, before they do.
Incident postmortem	Learn from an outage without assigning blame.
Interface control document	Pin down the contract between two systems built by different teams.
Onboarding guide	Get a new engineer to their first useful change.
Pull request template	Give a reviewer the context the diff cannot supply.
Release notes	Announce a release to the people affected by it.
RFC	Propose a change and gather informed disagreement before building it.
Runbook	Give the on-call engineer the steps to fix this at 3am.
Security policy	Tell a stranger who found a flaw where to send it privately.
Service README	Answer, in one file, what a service does and how to run it.
Support policy	Route questions away from the issue tracker, to a channel that answers them.
Technical design document	Work out how something will be built before building it.
Test case specification	Write a test someone else can run and get the same result.
Test strategy	Set how the team tests, at what level, and what it deliberately doesn't test.
Test summary report	Say what was tested, what was found, and whether it's fit to ship.
Threat model	Find what an attacker would go for, before they do.

Requirements

→ general-swe/requirements/

Document	What it's for
Non-functional requirements	Make speed, availability, and security testable instead of aspirational.
Product requirements document	State what to build and why, before anyone designs it.
Use case specification	Describe one goal a user achieves, step by step, including what goes wrong.
Vision and scope	Agree what the product is for and where its edges are.

Agile / Scrum

→ general-swe/agile-scrum/

Document	What it's for
Definition of done	Agree what "finished" means, so it stops being negotiated per item.
Product backlog item	Describe one piece of work well enough to plan and accept it.
Product goal	Name the single objective the backlog is working toward.
Sprint backlog	Hold the sprint goal and the plan for reaching it.
Sprint retrospective	Turn what the team noticed into one change it will actually make.
Sprint review notes	Record what was shown, what stakeholders said, and what it changes.
Team working agreement	Write down how the team works together, so new members don't guess.

Kanban

→ general-swe/kanban/

Document	What it's for
Blocker log	Track what stops work, so repeat causes become visible.
Definition of workflow	State what each column means and when an item may move.
Flow review	Look at the flow metrics and decide what to change.
Kanban system design	Design the board, its limits, and its policies deliberately.
Work item types	Define the kinds of work on the board and how each is handled.

Lean

→ general-swe/lean/

Document	What it's for
A3	Fit a problem, its cause, and the fix onto one sheet.
Experiment record	State the prediction before the change, so the result can't be reinterpreted after.
Improvement kata	Move toward a target condition one obstacle at a time.
Value stream map	See where the time actually goes between idea and production.

Shape Up

→ general-swe/shape-up/

Document	What it's for
Cool-down guide	Protect the weeks between cycles from being filled with new work.
Kick-off message	Hand a shaped pitch to a team with the context it needs.
Pitch	Present a shaped idea with its appetite and its limits attached.
Scope map	Break work into scopes the team discovers, not ones assigned upfront.

Waterfall / plan-driven

→ general-swe/waterfall/

Document	What it's for
Change request	Get a change to a baselined document assessed and approved.
Master test plan	Plan testing across the whole project, not one release.
Phase gate review	Decide, on evidence, whether the project may enter the next phase.
Requirements traceability matrix	Prove every requirement is designed, built, and tested.
Software design description	Describe the design that satisfies the requirements specification.
Software requirements specification	Specify what the system must do, in a form you can test against.
User acceptance test plan	Define what the customer must see to accept delivery.

Project management

→ general-swe/project-management/

Document	What it's for
Project brief	Get enough agreement to justify planning the project at all.
Project charter	Authorise the project and name who can decide what.
Risk register	Track what could go wrong, how likely, and who owns the response.
Stakeholder register	Know who cares about this project and what each of them needs.

Security and compliance

→ general-swe/security-and-compliance/

Document	What it's for
Data protection impact assessment	Assess a high-risk processing activity before it starts, as the GDPR requires.
Data retention policy	Say how long each kind of data is kept and what happens after.
Incident response plan	Decide who does what during a breach, before there is one.
Record of processing activities	Keep the Article 30 record of what personal data you process and why.
Security review checklist	Check a change for the failures that actually cause breaches.

User documentation

→ general-swe/user-documentation/

Document	What it's for
Documentation style guide	Make documentation written by many people read as one voice.
Explanation	Give the reader the understanding behind the instructions.
How-to guide	Take a competent user through one real task.
Installation guide	Get the software running on the reader's machine.
Reference page	Describe one thing precisely, for someone who already knows what they want.
Troubleshooting guide	Match a symptom to a cause and a fix.
Tutorial	Teach a beginner by getting them a working result.

---

Web development

Browser and API-facing work. → web-development/

Foundations

→ web-development/foundations/

Document	What it's for
API design guide	Make separately built endpoints feel like one API.
Brand and visual guidelines	Keep the product looking like itself across surfaces.
Browser support policy	Say which browsers you support, so testing and bug triage have an answer.
Design system guide	Document the components so people use them instead of rebuilding them.
Frontend architecture	Explain how the client application is structured and why.
Rollout plan	Ship a change to users gradually, with a way back.

Accessibility

→ web-development/accessibility/

Document	What it's for
Accessibility conformance report	Report conformance against WCAG success criteria, claim by claim.
Accessibility statement	Tell users where the product stands and how to report a barrier.
Accessibility test plan	Plan the manual and automated checks that find real barriers.

Performance

→ web-development/performance/

Document	What it's for
Performance budget	Set the numbers a change must not exceed, and what happens if it does.
Performance review	Look at real user metrics and decide what to fix.

---

Game development

Games and interactive media. → game-development/

Foundations

→ game-development/foundations/

Document	What it's for
Art bible	Give artists one visual target so the game looks coherent.
Business plan	Show how the game makes money and what it costs to make.
Game design document	Hold the design the team is actually building, as it changes.

Production

→ game-development/production/

Document	What it's for
Asset and contribution log	Track where every asset came from and what licence it carries.
Cycle retrospective	Review a milestone or cycle and change one thing about the next.

Live operations

→ game-development/live-operations/

Document	What it's for
Age rating compliance record	Keep the evidence behind your PEGI, ESRB, or IARC rating.
Balance log	Record what was tuned, why, and what the numbers did after.
Deployment plan	Ship a build to a live game with players in it.
Live-ops plan	Plan the events and content the live game runs on.
Privacy ledger	Track what player data every SDK in the build collects.
Release notes	Tell players what changed, especially when it affects how they play.

---

Data engineering

Pipelines, warehouses, and models. → data-engineering/

Foundations

→ data-engineering/foundations/

Document	What it's for
Data contract	Make the producer's promise to consumers explicit and enforceable.
Data pipeline design document	Work out how data moves and what happens when it doesn't.
Dataset catalog entry	Let someone find a dataset and know whether to trust it.

Governance

→ data-engineering/governance/

Document	What it's for
Data classification and access policy	Decide what's sensitive and who may see it.
Data lineage record	Show where a field came from and what breaks if it changes.
Data quality specification	Define the checks that decide whether data is fit to use.

Operations

→ data-engineering/operations/

Document	What it's for
Backfill and reprocessing plan	Rerun history without corrupting what's already downstream.
Freshness and SLA log	Track whether data arrived when consumers were promised it would.
Pipeline runbook	Give whoever gets paged the steps to fix a failed run.

---

Platform engineering

Infrastructure and operations. → platform-engineering/

Foundations

→ platform-engineering/foundations/

Document	What it's for
Platform onboarding guide	Get a team from nothing to a running service on your platform.
Service catalog entry	Answer who owns a service and how to reach them, at a glance.

Reliability

→ platform-engineering/reliability/

Document	What it's for
Error budget policy	Agree in advance what happens when reliability runs out.
SLO document	Set a reliability target users would actually notice.
Toil log	Make repetitive manual work visible enough to justify automating.

Resilience

→ platform-engineering/resilience/

Document	What it's for
Capacity plan	Know when you run out of headroom, before you do.
Disaster recovery plan	Recover from the failure you hope never happens.

---

AI-assisted development

Working with coding agents and language models. → ai-assisted-development/

Foundations

→ ai-assisted-development/foundations/

Document	What it's for
Agent instructions file	Tell a coding agent the project conventions it can't infer.
Task plan	Agree the approach with an agent before it writes code.

Specification

→ ai-assisted-development/specification/

Document	What it's for
Agent task specification	Specify a task precisely enough that the result can be checked.

Evaluation

→ ai-assisted-development/evaluation/

Document	What it's for
Evaluation plan	Decide how you'll measure whether the system is good enough.
Eval run log	Record what was evaluated, against which version, and what it scored.