To run loops on your product, give each loop four things: a trigger (your code changed, an error fired, or an area went unexamined), one narrow job, an output with a stop condition — a spec with acceptance criteria — and a human gate before anything is built. Point a coding agent at the approved specs and feed every merge back in as the next trigger.

You can wire that up yourself, or connect your repo to Tekk and switch on loops that already exist. Both paths are below.

Anatomy of one loop

Every loop that holds up in practice has the same parts. Miss one and it either never stops, never starts, or floods you with noise.

  • Trigger — what wakes it. The diff since its last run is the best default: it is cheap and it catches problems while the author still remembers the code.
  • Brief — what it knows before it starts: what changed, what it proposed before, and what you declined and why. Without the last part it re-proposes the same thing every week.
  • Method — one way of looking, not "review everything". "Can one tenant read another tenant's rows?" finds bugs. "Check security" finds lint.
  • Output — one finding, written as a spec: what to change, where, and acceptance criteria. Or an honest "nothing found", recorded so the next run doesn't redo the same ground.
  • Gate — a person accepts or declines. The decline reason goes back into the brief.
  • Close — the coding agent builds the accepted spec, the PR merges, the spec is marked done, and that merge is the next trigger.

Option 1: build the loops yourself

  1. Pick three areas where a missed problem hurts most — usually security, payments and reliability.
  2. Schedule a job per area in CI (a nightly or per-merge workflow) that collects the diff since the last run.
  3. Run a coding agent headless with a prompt per area: the diff, the area's definition of a finding, and the list of past declines. Ask for at most one finding.
  4. Force the output into a spec template — title, files, acceptance criteria, out of scope — and file it as an issue with a "proposed" label.
  5. Review the proposed issues once a day. Approve by relabelling; decline by closing with a reason, and append the reason to that area's decline list.
  6. Hand approved issues to your coding agent, and close them from the PR (Closes #123).

This works, and it's a good way to learn loop engineering. Expect to spend real time on the parts that aren't the prompt: dedupe, decline memory, cost control, and keeping each area's definition of a finding sharp enough that you trust what it files.

Option 2: switch on Tekk's loops

  1. Connect your GitHub repository at app.tekk.coach.
  2. Turn on the loops you want. Twelve are available: Security, Reliability, Backend, Payments, Performance, Testing, React, Code quality, AI engineering, Observability, Alerts and Product analytics. They are opt-in per workspace.
  3. Optionally connect Sentry so an error spike or slow transaction wakes the loop that owns it (integrations).
  4. Set a goal if you want the loops aimed somewhere specific.
  5. Review proposals. Each run brings at most one. Accept and it becomes a spec on your board; decline with a reason and the loops learn.
  6. Build with your coding agent. Connect Claude Code, Codex or Cursor to the board through the Tekk MCP server. A PR that says Closes TEK-123 completes the spec when it merges — if its checklist is done (how linking works).

Under the hood each Tekk loop is a shelf of skills — two to five methods, one per kind of question. A run reads its brief, opens exactly one skill, works it end to end, and records which one it used, so the loop learns which of its methods actually land on your project. Tekk never writes or ships code; it decides what's worth doing and writes it down so your agent can do it well.

Which to choose

Build your own if you have one narrow loop in mind and want full control of the prompt. Use Tekk if you want several areas watched at once without maintaining the machinery — or start DIY, learn what a good finding looks like, and switch when the upkeep starts to cost more than the loops save.

Part of the Loop Engineering guide. Its other half is spec-driven development: the spec is how a loop knows it's done.