Pull requests

Once a repository is connected, Tekk watches its pull requests and ties each one to the spec it implements. Open a spec and you can see the PR that’s building it — its status, branch, and change size — and when that PR merges, the spec can move to done on its own.

There is nothing to configure. Connecting your GitHub repository wires this up; new pull requests link themselves from then on.

How a PR links to a spec

A pull request links to a spec by referencing the spec’s identifier — the TEK-123 code shown on every card. There are two ways to reference it, and they do different things:

• Mention — the identifier appears anywhere in the PR’s branch name, title, or body (for example, “builds on TEK-123”). A mention links the PR to the spec so it shows up there. That’s all it does.
• Closing reference — a closing keyword immediately before the identifier (Closes TEK-123, Fixes TEK-123, Resolves TEK-123) in the title or body, or the identifier carried in the branch name. A closing reference is the only signal allowed to move the spec’s status when the PR merges.

The split is deliberate: mentioning a spec for context should never risk completing it. A PR whose body says “this is the groundwork TEK-200 builds on” links to TEK-200 — but it can’t close it.

Tip: every spec has a Copy git branch name button that produces a branch like tek-123-add-rate-limiting. Because the identifier is in the branch name, a PR from that branch is automatically a closing reference — no keyword to remember.

What you see on the spec

A linked PR appears on the spec with, at a glance:

• a status badge — Draft, Open, Merged, or Closed;
• the PR number and title, linking straight to the pull request;
• the branch it’s on;
• the change size (+120 −34, 5 files) and author.

A spec can have more than one linked PR, and a single PR can link to more than one spec.

Merging closes the spec — if the checklist agrees

When a PR with a closing reference merges, Tekk moves the spec to completed — with one guardrail: the spec’s own build-order checklist has to be finished.

• Checklist complete (or the spec has none) → the spec moves to completed, and the merged PR is recorded on it.
• Checklist still has open items → the spec stays in progress, and Tekk notes the merge and how far along the checklist is (for example, “3/7 items”). It does not mark the spec done while its own acceptance criteria say it isn’t.

This is the point of the feature: done means done. A merge is a fact, so Tekk acts on it without asking — but it won’t complete a spec whose checklist disagrees. If you want a merge to close a spec cleanly, tick the boxes before you merge.

Closing several specs in one PR

Repeat the keyword before each identifier:

Closes TEK-62, Closes TEK-66

This matches GitHub’s own grammar. A bare identifier after a comma — Closes TEK-62, TEK-66 — only mentions the second spec; it won’t close it.

Reading a spec through its code

Because a spec now carries its pull requests, opening one tells you whether its status is trustworthy — not just what the status field says. If a spec is still marked in progress but its closing PR merged days ago, that gap is surfaced, so neither you nor an agent working through the MCP server acts on a stale status. When you connect Tekk to your coding agent, this reality check rides along on every read, and your board’s overview flags specs whose status has fallen behind the code.

The result is a tighter loop between the board and the repository: a spec reflects what actually shipped it, and it closes itself when the work truly lands.