Free Guide

Stop Retyping Your Status Report

The Governance Starter Kit is a set of six plain-text files a project manager sets up on day one and an AI assistant maintains from then on: context, decisions, validations, risks, a catalog, and a capture folder. It takes about twenty minutes to set up. This is governance of the project, not governance of the AI — the assistant does the typing, you keep the authority.

For: Project & Product Managers

Setup: ~20 minutes

You need: A place for text files

Before you start

You need a place to keep text files that your AI assistant can read and write. A repository, a synced folder, or a workspace your assistant has access to. If your organization lives entirely in a wiki, you still need this layer underneath it. The wiki is where facts go to be read, not where they live.

You do not need to be technical. You need to be willing to let the assistant do the typing.

Part 1

Setup

Paste the block below into your AI assistant on day one of the project. Answer its questions. It will create the scaffold.

setup-prompt.txt

I am starting a new project and I want to set up a lightweight governance layer
that you and I will maintain together. Before creating anything, ask me these
questions one at a time and wait for my answer:

1. What is the project called, and what outcome does it exist to deliver?
2. What are the phases or gates between now and done, with rough dates?
3. Who are the named decision makers, and what do they each own?
4. Where do delivery teams actually go first for answers: wiki, tracker, chat?
5. What work tracker are we using, and what is the top-level item ID?

Then create these files and nothing else:

- context.md         Project name, outcome, phases, decision makers, tracker
                     link. This is what you read at the start of every session.
- decisions.md       Table: ID, date, decision, rationale, rejected option,
                     owner, status (proposed | decided | reversed).
- validations.md     Table: ID, date, what was proven, evidence link, decision
                     ID it supports, status.
- risks.md           Table: ID, risk or dependency, impact, owner, decision ID
                     if one exists, status.
- catalog.md         Table: file, purpose, audience, owner, last reviewed.
- capture/           Empty folder for raw notes. Nothing here is true yet.

Rules for how you maintain these:

- Every row gets a stable ID that never changes. Prefix by type: D-001, V-001,
  R-001.
- Status is an explicit value, never implied by wording. If I say something
  ambiguous, ask whether it is proposed or decided.
- Never invent an owner or a date. Write TBD and flag it to me.
- Anything I paste that is raw or unconfirmed goes in capture/ with today's
  date. It does not enter a governed file until I say promote it.
- When any governed file changes, update catalog.md last-reviewed and tell me
  what else now needs to change.

Confirm the scaffold back to me as a list before you write anything.

The Six Governed Files

File / Folder	What it holds
context.md	Project name, outcome, phases, decision makers, tracker link. Read at the start of every session.
decisions.md	Table: ID, date, decision, rationale, rejected option, owner, status (proposed \| decided \| reversed).
validations.md	Table: ID, date, what was proven, evidence link, decision ID it supports, status.
risks.md	Table: ID, risk or dependency, impact, owner, decision ID if one exists, status.
catalog.md	Table: file, purpose, audience, owner, last reviewed.
capture/	Empty folder for raw notes. Nothing here is true yet.

Worked Examples

Here is what realistic governed files look like once populated. Note the rejected option recorded in decisions.md and the explicit TBD owner flagged in risks.md:

# decisions.md

| ID | Date | Decision | Rationale | Rejected Option | Owner | Status |
|---|---|---|---|---|---|---|
| D-001 | 2026-09-02 | Store audit logs in Postgres JSONB | Avoids managed service overhead at <20 QPS | DynamoDB + OpenSearch pipeline ($800/mo base cost, extra pipeline) | Sarah T. | decided |
| D-002 | 2026-09-10 | Enforce 90-day retention on raw events | Satisfies privacy policy; keeps table size <50GB | Indefinite S3 archive (fails compliance active-deletion audit) | Marcus K. | proposed |

# risks.md

| ID | Risk or Dependency | Impact | Owner | Decision ID | Status |
|---|---|---|---|---|---|
| R-001 | SMS gateway sandbox has no delivery webhooks | High — staging tests require manual verification until v2 API | TBD (Flagged: needs owner) | D-004 | open |

Review what it produces. Delete any file you cannot name an owner for. Fewer files that stay true beat more files that rot.

Part 2

The eight moves

These are the recurring moves. Say them in your own words. The assistant does the writing.

Daily or as things happen

"Capture this."

Paste the meeting notes, the chat thread, the email. It lands in capture/ with a date. Nothing is claimed to be true. This should be effortless or you will stop doing it.

"Promote this to a decision."

Turns a capture into a row in decisions.md with rationale and the option you rejected. The assistant should ask you for the rejected option if you did not give it one, because that is the part future-you actually needs.

"This is a proposal, not a decision."

Sets status explicitly. Use it often. Most of what feels decided in a meeting is not.

Weekly

"What is stale?"

The assistant lists captures older than your window and asks, for each one, whether to promote it, fold it in, or delete it. Answer all of them. This is the habit that keeps the system from silently dying.

"Draft the tracker update."

Produces the status comment or board update from what actually changed in the governed files this week. You read it, edit it, and post it yourself.

Before a gate or steering review

"Run a consistency check."

The assistant looks for: risks referencing decision IDs that do not exist, validations with no linked decision, rows with TBD owners, and anything marked proposed that people have started treating as decided. It reports. It does not fix without asking.

"Build the gate pack."

Assembles the minimum evidence set a skeptic would accept: decisions made since the last gate, validations supporting them, open risks with owners. You take it from there.

When the project changes shape

"Update context."

New phase, new decision maker, changed dates. Do this immediately. A stale context.md misleads at machine speed, because the assistant reads it first and acts on it without hesitating.

Part 3

What should an AI assistant never do?

Write this down before you automate anything, because the pressure to let it take one more step is constant and it only moves one direction.

The assistant drafts, organizes, validates, summarizes, and exports.

The assistant does not:

Post the tracker update. You post it.
Send the email or the status report. You send it.
Mark anything decided. Only you change a status to decided.
Sign off a gate, approve a risk acceptance, or close a dependency.
Invent an owner, a date, or a decision to fill a gap in a table.

If you find yourself wanting to relax one of these, that is the moment to reread the list, not to edit it.

Part 4

The nine principles

You do not need these to use the kit. You need them when you want to change it.

Capture fast, promote deliberately.

Promotion is an explicit act with an owner and a date, not something that happens by drift.

Let working docs expire.

A defined window, enforced by the weekly check, not by goodwill.

III

Match density to phase risk.

Heavy before the first gate, thinner once scale begins. If the artifact set is not shrinking, you are documenting scale before you have proof.

Name the bridge between repo truth and reader truth.

Most readers never open the repository. The sync to where they stand is a first-class job. Distribution artifacts link back. They never become the source.

If automation can execute from it, it is production code.

Validate before you present.

Confidence is a field, not a tone.

Machines cannot read a hedge. Fact, proposal, and open are values you can filter on.

VII

Stable IDs are join keys.

Without them a traceability chain cannot close and reviewers argue from memory.

VIII

Version bumps are trigger events.

Changelog, catalog, consistency check, and tracker sync fire together or the change did not happen.

Name what a human must sign.

Part 3 is this principle. It is the only one you write down before you need it.

What do you do when it stops working?

The failure is almost always the same: captures pile up and nobody promotes them. The system does not break loudly. It goes quiet.

Two fixes, in order. Shrink the governed set until maintaining it is trivial. Then make the weekly "What is stale?" pass a standing fifteen minutes on your own calendar, owned by you, not by the team.

Point an agent at this page

Point your AI assistant directly at this guide to scaffold the governance layer automatically:

Read triforceagility.com/resources/governance-starter-kit/ and set up this governance layer for my project.