AI Blocks › Write down how work gets done

Project requirement tracker

Share your project requirements, priorities and progress notes. It links each need to an owner, a build choice and a specific test. You get a compact tracking table, an approval log and a clear list of work that remains open.

Track project requirements from owner to build, test and sign-off in one table. Find what is still open before go-live.

Free · No account · MIT licence · Made by erphq · Tested · Updated 28 Oct 2026

What you get

What goes in

Your list of project requirements, with a priority for each (Must, Should or Nice)
The names of owners and the stakeholders who approve work
How each need will be built, such as setup, custom work or a third-party tool
Your test evidence and approval records, if you have them (optional)

What comes out

Requirements table: One row per requirement with its ID, priority, owner, build choice, test plan, status and sign-off.
Sign-off log: Who approved each requirement and the date, where you gave them.
Open requirements: The requirements not yet signed off, so nothing is lost after launch.
Requirements-completion summary: A short wrap-up of what was built, tested and approved, and what remains.

Is it for you?

Skip it when

You are buying a SaaS tool and changing very little. A simple task list is enough.
Your change takes under one week. Use a short checklist and skip the table.
You need to decide what work each need requires first. Use the Fit-Gap Matrix, then come back here.

Fill it in

Add what this task works from, then copy the request.

Business requirements and their priorities.
Owners, build choices, test evidence and approval records.

Run it

Download the complete instructions and supporting files. Add them to Claude, ChatGPT or Gemini once, then ask for it by name in any chat. Pasting the instructions into a chat works too.

Download all files

Before and after this skill

Choose the steps you need. Bring your own material when you have it.

Before

Bring the material listed under Fill it in.

This skill

Project requirement tracker

Open builder

After

Medical billing and coding specialist
Use it if you have the document.

Specialists who do this

Each one uses this as one of its methods for a bigger job. Hire one for free and give it the job in your own AI.

Hire an AI client project closeout and acceptance tracker

Details

From erphq. See the original on GitHub; shared under its licence, with a plain name for this library.

What it does

What goes in and out

You give it

Business requirements and their priorities.
Owners, build choices, test evidence and approval records.

You get

A requirement-to-build-and-test table.
An approval log with names and dates where known.
Open requirements and a completion summary.

More for Write down how work gets done

Every write down how work gets done skill

How the task works

Step 1. Write one clear requirement per row and assign an owner.
Step 2. Link each row to how it will be built and tested.
Step 3. Track built, tested and approved states separately.

Full instructions

Open Claude, ChatGPT or Gemini and paste the skill instructions into a new chat.
Paste your requirement list. Add a priority for each one: Must, Should or Nice.
Add the names of your owners and stakeholders, and the test evidence you have.
Add any approval records, with names and dates. Say which are missing.
Ask your AI to build the tracking table, the sign-off log and the open list.
Check that every row has an owner and a specific test plan. Fix any gaps, then keep the table up to date.

Full instruction file

Requirements Traceability — Under 100 People

Before you start

Use the material below to do this job. If facts or tool access are missing, explain what you can finish and what must wait.

What you need (use your own material or the linked skill):

The product spec (yours): what to build and how to tell it's done: a requirements doc or user stories.

How to start:

Look first. Use what they've already attached, pasted or put in their about-me note. In a coding assistant with file access, look in the project too for these by name.
Check what's missing. Look for the product spec. They can attach files, paste the details, or share a file path your assistant can read. Ask only for missing facts that change the result. If they ask you to start with what they have, complete the parts you can and mark the gaps.
Do the job. Follow the skill below with the facts and tools you have. Mark each gap with MISSING: where it belongs and never invent a fact to fill it.

Purpose

At under-100 people, a full enterprise Requirements Traceability Matrix (RTM) with 20-column rigor is overkill. This is the trim version: a simple table that shows, for every business requirement, what was built + how it was tested + who signed off. It's the answer when someone asks "wait, did we ever actually build the invoice-export feature?" three months after go-live.

Use when:

Implementing a new SaaS platform with material configuration work
Custom-building an internal tool or workflow
Making a material process change requiring cross-team agreement
Any scope where "did we ship what we said?" matters

Don't use when:

Buying + configuring a SaaS tool with minimal customization
Small iterative product changes
Anything where the scope is trivial (< 1 week effort)

Template Structure

A spreadsheet or Notion table. 5–8 columns max. Goal: one row per requirement, trackable through lifecycle.

Columns

Column	Content
Req ID	R1, R2, R3…
Requirement	One sentence — what does this need to do?
Priority	Must / Should / Nice
Owner	Who's accountable
Implementation	Config / custom / third-party / skip
Test plan	How will we validate it works?
Status	Not started / In progress / Built / Tested / Signed off
Sign-off	Who approved + date

Sample Row

The Workflow

Phase 1: Capture (Week 1)

Interview stakeholders — 30 min each with department heads affected
Extract requirements — list 10–50 items
Prioritize — Must / Should / Nice split (force reasonable ratio, ~30/50/20)
Assign owners

Phase 2: Design (Week 2)

For each requirement, decide implementation path — native, configuration, third-party, custom, defer
Add effort estimate — rough: S (hours), M (days), L (weeks)
Review with stakeholders — scope-agreement meeting

Phase 3: Build (Week 3–N)

Developers / admins / consultants work through requirements
Status updated per requirement as work progresses
Blockers surfaced early

Phase 4: Test (Pre-Go-Live)

Each requirement tested against its test plan
Failures logged; fix + re-test
Stakeholder sign-off per requirement

Phase 5: Post-Launch

Requirements not yet signed-off → tracked as open
New requirements surfacing → separate change-request log (don't bloat the original RTM)

Sample Requirements

For a CRM implementation:

ID	Req	Priority	Impl
R1	Track contact activity (emails, calls, meetings)	Must	Native + Gmail plugin
R2	Multi-pipeline management (new biz, renewals, referrals)	Must	Native configuration
R3	Custom field: Revenue potential	Should	Config
R4	Auto-sync with QuickBooks for closed deals	Must	Third-party (Zapier)
R5	Dashboard: Weekly pipeline health	Should	Native reporting
R6	Forecast by territory (we don't have territories yet)	Nice	Skip

Common Mistakes

Listing too many requirements: 100 entries, nobody reads it, scope creeps. Cap at ~30 for small-org implementations.
Everything "Must": Defeats prioritization. If everything matters equally, nothing does.
No test plan per requirement: "We'll test it before go-live." Vague. Specific test plan per row.
No owner: Requirement orphaned; nothing happens.
Sign-off meetings never happen: Requirements "complete" without validation. Post-launch surprises.
Requirement-spec not updated: Reality diverges from document; document becomes fiction.
Over-formal with a small team: 20-column enterprise RTM for a 3-person config project = massive time sink.

When to Upgrade

Move to the 100–1k org version when:

Multi-team / multi-workstream implementation (5+ parallel tracks)
External consultant engagement with formal contract scope
Audit / compliance-driven implementation (SOX, GDPR, HIPAA) where traceability is legally required
Multi-phase rollout across geographies / business units

Output

Living RTM (spreadsheet or Notion)
Sign-off log
Post-launch "requirements-completion" summary

After this

When you've handed it back, suggest what they could do next in one short question. It's a suggestion: if they're done, that's fine. Offer these, and say they can type their own:

The Medical billing and coding specialist. It takes the document. If they pick one and that skill is added here, carry straight on with what you just made. If not, give the link and say what to bring.

Fit-Gap Matrix (source reference: ../fit-gap-matrix/SKILL.md) — precedes RTM (fit-gap identifies which requirements need what work)
Go-Live Checklist (source reference: ../go-live-checklist/SKILL.md) — RTM sign-off feeds into go-live readiness
Migration Runbook (source reference: ../migration-runbook/SKILL.md) — data migration often has its own traceability
Mid-Market Requirements Traceability (100–1k) (source reference: ../../02-org-100-to-1k/requirements-traceability/SKILL.md)
Enterprise Requirements Traceability (1k+) (source reference: ../../03-org-1k-plus/requirements-traceability/SKILL.md)