How it works
Loops and their skills
The sixteen loops Tekk can run on your project, the skills each one carries, and how a run picks the one method it will work with.
A loop is not one big prompt. Each loop is a shelf of skills: a short file that says what the loop is and what counts as a finding in its domain, plus its skills, each a self-contained method for one kind of question inside that domain: two on the smallest shelf, eleven on Security. A run opens exactly one skill and works it end to end.
This page lists what is on each shelf. The skills are written in the open Agent Skills format — one SKILL.md per loop, with each method bundled beside it as a reference file — and they are the same files a Tekk run mounts when it works on your code.
Work your board from your agent
The ten skills for driving Tekk itself install as one plugin that also connects the Tekk MCP server. Four work the board: sweep the proposal inbox, blitz specs into parallel coding sessions, triage the board against git, and write specs that can actually close. Six more aim the loops and keep the work moving: grill-to-steer points them at what you care about, steer-loops sets what runs and when, feedback tells them what the last round was worth, grill-to-loop and ideate-loops design new ones, and night-shift works the board while you sleep.
/plugin marketplace add guccikudo92615/tekk-skills
/plugin install tekk@tekk
For Codex, Cursor and other agents, take the skills and add the MCP server as described in the MCP server docs:
npx skills add guccikudo92615/tekk-skills -a codex
Those ten are how you operate Tekk. The review skills documented below are a different thing: they are the methodology the loops apply to your code, they run inside Tekk rather than in your terminal, and they are not distributed separately.
What the loops add on top of any single method is everything around it: deciding which loop is worth waking and when, assembling the brief that says what changed and what you have already declined, choosing the skill against that skill’s own track record on your project, and turning a finding into a spec on your board.
How a run chooses a skill
When a loop wakes, nothing pre-selects its method. The run is handed its brief — what changed since it last ran, what it and every other loop proposed recently and what you did with each, how each of its skills has performed on your project, and a snapshot of your product’s measured scale — and then it opens the shelf. Two things weigh the choice:
- What the change is actually about. A diff that touches a webhook receiver is a question for
retry-safetyorwebhooks-and-fulfillment, notrender-performance. - The track record. A skill whose proposals keep landing has earned another turn. One whose proposals you keep declining is not owed a turn just because it has gone longest without one.
The run opens with a short bearings statement — what this run is about, which skill it is opening and why, and what it will check — then reads the code with that one method. If reading changes its mind it may switch once. Every run records the skill it actually worked, so the next run knows which of the loop’s methods has really been exercised.
One run produces at most one proposal, and a run that finds nothing is a complete run — it is recorded as an honest negative so the loop does not re-audit the same ground tomorrow.
The loops
Sixteen loops are available today. Each one is opt-in per workspace. Fifteen of them work on your repository alone; where one gets sharper with a connected tool, its section says so. Customer feedback is the exception: it reads what your customers report, so it runs only when a connected feedback tool delivers a new report.
Security
Audits recent code changes for security holes — auth gaps, exposed data, injection, tenant leaks — and proposes fixes. It audits like an attacker who wants free service or another tenant’s data, not like a checklist, and holds every finding to a traced request rather than a pattern match. Five of its skills each cover one trust boundary; the other six go a level deeper beneath one of those five, for when the first check holds and the question is what lies underneath.
| Skill | What it audits |
|---|---|
auth-and-access | Who is allowed to do what — ownership and role checks on every route, IDOR, check-then-act races, entitlement enforcement — and the signup, login, reset and session flows that hand out identity in the first place. |
identity-protocols | Beneath auth-and-access: whether the layer under a correct access check can attach a request to the wrong person, session or token — CSRF, session fixation, JWT verification, OAuth callbacks and account linking, MFA and recovery, trusted Host and Origin headers, credentialed CORS. |
tenant-isolation | Whether one customer can reach another’s data: row-level security coverage, the service-role bypass, tenant scope taken from the session rather than the request, and leaks through joins, caches, exports and admin paths. |
rls-patterns | Beneath tenant-isolation: the shape a correct fix takes once a hole is found — isolation enforced by a row-level security policy in the database rather than a filter someone has to remember, and roles with no more privilege than they need. |
data-lifecycle | Beneath tenant-isolation: every copy of a record, not just the guarded table — cache keys and storage paths, signed links, search indexes and embeddings, exports and imports, and whether deletion, revocation and restore really reach them. |
money-and-webhooks | Whether someone can get paid features without paying, and whether inbound provider webhooks can be forged, replayed, or pointed at another account. |
logic-and-spend | Beneath money-and-webhooks: the bypasses no scanner finds — steps skipped or replayed in a flow that ends in a grant, races with money at the end, numbers that can be twisted, events taken out of order — and a valid account turned into someone else’s bill through unbounded paid calls. |
injection-and-input | Untrusted input reaching a dangerous sink — SQL, shell, SSRF, path traversal, unsafe deserialization — and the agent-era version of the same bug: prompt injection, unverified tool authorization, model output trusted downstream. |
agents-and-browsers | Beneath injection-and-input: the sinks a model or a page holds — content reaching another user’s context, a tool exercising authority the requester lacks, MCP and sub-agent identity, model output acted on unchecked, and sources only the browser sees. |
secrets-and-crypto | How credentials are stored, exposed and rotated — keys in code, secrets in logs, error bodies and client bundles — plus password hashing, token randomness and the supply-chain surface underneath. |
ci-and-supply-chain | Beneath secrets-and-crypto: whose code runs with which secrets — untrusted pull-request code in a privileged workflow, injection into CI expressions, caches and artifacts crossing trust levels, over-broad tokens, dependency confusion and what actually ships in a release. |
Reliability
Audits your code for the ways it breaks under real-world failure — a dependency that times out with no deadline, a retry that runs a charge twice, a swallowed error that looks like success, an unbounded operation that exhausts memory — and proposes the fix. Sharper with Sentry connected; works without it.
| Skill | What it audits |
|---|---|
dependency-boundary | Every call that leaves the process — HTTP, database, cache, queue — for deadlines, retry policy, backoff and blast-radius containment. |
retry-safety | State changes that can run more than once — a redelivered webhook, a re-run job, a double-submit — for the dedupe that makes the second execution harmless. |
resource-limits | What runs out under load: pool starvation, a connection held across an await, unbounded queries and accumulators, uploads with no size limit, leaked handles. |
failure-handling | What the code does once something has already failed — empty catches, errors logged and continued past on a write, a failure that returns success, half-applied multi-step work. |
Backend
Audits everything behind your API for the bugs a founder can’t see — unvalidated input, a retry that charges twice, two requests racing into a duplicate, a swallowed failure, a query with no index, a migration that could break the next deploy — and proposes the fix.
| Skill | What it audits |
|---|---|
api-correctness | The trust boundary of a request handler: input validated where it enters, errors that fail loudly, and the defaults that decide behaviour under load — pagination caps, timeouts, body limits, rate limits, CORS. |
idempotency-and-jobs | Anything that can happen twice or interleave — non-idempotent writes under retry, check-then-act races, multi-step writes with no transaction, queue and cron consumers with no retry, dead-letter or lock discipline. |
query-and-index | How the app reads — N+1 queries, filters on unindexed columns, unbounded scans, over-fetching, and ORM calls that emit something pathological. |
index-choices | Beneath query-and-index: the form the fix takes once a slow read is found — the foreign key nobody indexed, composite column order, partial and covering indexes, and cursor pagination instead of a deep offset. |
schema-and-migrations | The shape of the data and how it changes — migrations that must survive a non-atomic deploy, constraints that keep bad rows out, data types, pool configuration. |
Payments
Audits your billing code for the bugs that lose money — a paid signup that provisions nothing, a retry that double-charges, access that’s never revoked on cancel, a drifted price id — and proposes the fix.
| Skill | What it audits |
|---|---|
webhooks-and-fulfillment | Whether every money-critical provider event is handled and fulfilment runs exactly once — at-least-once delivery with no dedupe, out-of-order updates, the trial path that provisions nothing. |
entitlements | What the customer can actually do after the money moves — every grant with a matching revoke, cancellation and failed renewal reaching a defined state, access decided from real subscription state rather than a stale cache. |
billing-config | The configuration that decides what gets sold — price and plan ids split between env and code, test-mode versus live-mode keys, plan-to-feature maps that drift from the provider. |
Performance
Hunts slow queries, slow endpoints and latency spikes and proposes targeted speedups — and the infrastructure spend that buys nothing: a poll that should be a webhook, an always-on service, needless egress. Sharper with Sentry connected.
| Skill | What it audits |
|---|---|
query-latency | How the app reads under load — a query inside a loop, a per-row lookup that should be one batched query, unindexed queries on a hot path, pagination that scans the whole table. |
hot-path-blocking | What a request waits on — synchronous I/O or heavy CPU in a handler, an external call with no timeout, work that should be queued, a response built without a cache. |
infra-spend | The machine bill — a cron where an event would do, a schedule far tighter than its inputs change, an always-on service that could be on-demand, paid services still wired but unused. |
algorithmic-cost | The code itself — a nested loop turning linear into quadratic, a list scanned where a map would index it, a whole collection loaded to count it, pure work redone instead of memoized. |
Testing
Finds risky changed behaviour with no tests, tests that can never fail or only pin how the code is written, tests that fail at random, and tests that cost more time than the confidence they buy — and proposes the fix, deleting and merging as readily as adding.
| Skill | What it audits |
|---|---|
coverage | Changed behaviour and the tests it does not have — new branches and error paths, bug fixes with no regression test, contracts whose tests no longer assert them. |
flakiness | Non-determinism — fixed sleeps instead of waits, state shared across tests, order dependence, real clocks, unseeded randomness, real network I/O — and a stabilization or an honest quarantine. |
pruning | Tests that cost upkeep and buy no confidence — tests that cannot fail, tests that pin implementation instead of behaviour, mocks asserted against themselves, duplicates, skipped tests, whole-tree snapshots — and whether to delete, merge or rewrite each one. |
suite-speed | Wall-clock the suite does not need to spend — real I/O that should be faked, heavy per-test setup that could be shared, serial-but-independent cases — keeping every check. |
React
Checks React components for bugs and wasted renders — stale state, effect misuse, needless re-renders — and proposes fixes.
| Skill | What it audits |
|---|---|
state-and-effects | Where state lives and when effects run — index keys, missing or unstable effect dependencies, state that should be derived, effects doing an event handler’s job, async races. |
render-performance | What a component costs to render and how widely it re-renders others — unstable props and context values, over-broad subscriptions, long unvirtualised lists, updates that block typing. |
markup-safety | What the rendered markup does to the user — unsanitised HTML injected into the DOM, and controls without an accessible name, keyboard path or correct semantics. |
Code quality
Cleans up what AI coding agents leave in your code — narrating comments, needless wrappers and defensive checks, type escapes, leftover debug output, half-finished renames and migrations — without changing what your app does, so its fixes need little review. How modules divide the work belongs to Architecture.
| Skill | What it audits |
|---|---|
deslop | The statement level — narrating and stale comments, debug leftovers, defensive checks no sibling needs, pass-through wrappers, single-use helpers, dead and speculative code, near-duplicate logic and copies that drifted apart. |
propagation | What a rename or a migration left behind — every place still using the old form of a value that changed identity (env vars, constants, config keys, API routes, the docs that cite them), and code still on the old API or library after a move to a new one. |
types | Type escapes — any used to silence the compiler, chained assertions, suppression comments with no reason, enums bypassed by raw literals — replaced with the type the code could actually state, without changing what runs. |
Architecture
Finds the places where your codebase’s structure makes every change cost more than it should, ranked by where changes actually land, and proposes the restructuring that pays off. What the app does at its edges stays the same; the interfaces inside it are free to change. It wakes when a change grows a file past a thousand lines, adds an import cycle, reaches into another module’s internals or re-implements logic that already exists, and when a busy area has not been read whole in a while.
| Skill | What it audits |
|---|---|
coupling | The dependencies that make a change spread — layer boundaries crossed, provider specifics leaking past their seam, import cycles, files that always change together with no import between them, hubs that are both heavily imported and constantly changed. |
decomposition | Files and functions that grew more jobs than they can hold, split along a seam the change history supports, and logic written twice across modules or entry points. |
deepening | Shallow modules whose interface is nearly as complex as what they hide — pass-through layers, a decision known in two places, a shared helper growing a flag per caller — and the deeper module that absorbs what callers now assemble themselves. |
AI engineering
Researches how the best teams build with LLMs today — provider docs, engineering write-ups and papers — and proposes the upgrade your agent harness, tools, context, memory, retrieval, evals or guardrails could make next, or the change that buys the same output for less money.
| Skill | What it audits |
|---|---|
harness | The agent loop itself — whether the “agent” is a real harness with tool use, state, planning and error recovery, and whether the work is divided right between plain code, one agent and several. |
safety | The tools an agent holds and what keeps it in bounds — the right tools, described and typed so the model uses them well, untrusted content that could steer it, unchecked actions and output, and the guardrail that would let you hand it more work. |
context-engineering | What fills the model’s context and what it keeps between calls — dead weight in the window, memory written but never read, prompts demanding facts nothing supplies, blocks that grew past their usefulness. |
retrieval | How knowledge gets into the model’s context — whether retrieval is the right shape at all, and whether it surfaces the right material or merely the nearest. Ships a catalog of retrieval methods. |
evals | Whether you can change a prompt, model or retrieval setting and know it improved things, whether production misbehaviour is diagnosable, and what each call costs for what it buys — agent turn tax, missing prompt caching, an oversized model for a bounded task, retries with no ceiling. |
Compliance
Audits the code that touches personal data for the gaps that bring GDPR fines and lose EU deals — tracking that fires before consent, personal data kept forever or impossible to erase, data sent to a vendor that didn’t need it, data landing outside the EU when your customers were told it stays there — and proposes the fix. It wakes when code that handles personal data changes: analytics wiring, a table holding personal data, deletion or export code, a call to a third party, a region or host in config.
| Skill | What it audits |
|---|---|
consent | Collection that happens before or without agreement — analytics, pixels, cookies, session replay and marketing started at app load or ahead of the consent check, consent assumed rather than recorded, no way to withdraw, a reject path that still collects. |
data-residency | Where personal data is stored and processed — database, bucket, queue and function regions, SDKs left on a US default host when the vendor offers an EU one, model providers receiving user content, and config that contradicts the “hosted in the EU” your customers were promised. |
retention-and-erasure | How long personal data lives and whether a user can really be removed — stores with no retention or purge, a missing or partial deletion path, a soft delete that leaves the data in place, copies in caches, search indexes and exports that erasure misses, and no way to export what you hold on someone. |
third-party-transfer | Personal data leaving the system — to analytics, model providers, error tracking, email or support — in a bigger shape than the job needs: whole user objects where an id would do, identifiers in URLs, user content sent to a model unminimized. |
Observability
Finds parts of production you can’t see — unwatched services, silent jobs, vanished crashes, swallowed errors, untraced critical paths — and proposes the missing check, log, or span.
| Skill | What it audits |
|---|---|
uptime-and-heartbeats | Unattended work with nothing watching it — a service with no health endpoint or a shallow always-green one, a scheduled job with no check-in. |
crash-reporting | Every application entrypoint for error reporting — a server, worker or client runtime with no error-tracking SDK, an init that misses unhandled rejections, an SDK with no release or environment. |
log-quality | What the code leaves behind when it fails — an error branch with no record, unstructured messages with no correlation id, levels that bury real failures, secrets written into a log line. |
tracing-and-metrics | Whether flight-critical paths — payments, auth, outbound calls, queue work — emit spans and metrics that record success, failure and latency. |
Alerts
Finds critical paths with no alert — payment failures, broken webhooks, auth errors — and proposes the exact Sentry rule to catch them. Sharpest with Sentry connected, because it reads the rules you already have there; without it, it flags the gap and says a rule may already exist.
| Skill | What it audits |
|---|---|
coverage-gaps | The critical paths that exist in the code minus the alert rules that exist in the project, and the missing rule with a concrete condition and threshold. |
rule-quality | Alert rules that already exist — thresholds too tight to survive normal traffic or too loose to ever fire, duplicate rules, alerts with no owner or route, coverage that drifted after the code moved. |
Product analytics
Checks whether analytics is even wired up and, if not, sets you up — what to track, where, and a tracking plan — so you can see your funnel. Sharper with PostHog connected.
| Skill | What it audits |
|---|---|
event-coverage | The product’s real user journeys — signup, the activation moment, the core repeated action, conversion — and whether anything captures them, with the specific capture calls and where they go. |
event-hygiene | Whether what is captured can be used — an SDK really initialized and firing, consistent machine-parseable names, the properties a question needs, no PII sent as a property, a tracking plan rather than a pile. |
Documentation
Keeps the text your coding agents read accurate, short and easy to follow — the agent instruction files, the map of where things live, docs that no longer match the code, and the missing “why” beside code that is easy to break. Every finding names the wrong turn it prevents, and fewer words often beat more. It wakes when a change moves something a doc, an instruction file or a comment describes, and when an area’s docs have not been read against its code in a while.
| Skill | What it audits |
|---|---|
agent-context | The instruction files every agent session loads first, such as CLAUDE.md and AGENTS.md — whether each line is true, earns its place, and points at the detail in a way an agent will actually follow. |
drift | Guides, READMEs and design docs that say something the code no longer does — commands, paths, names, numbers, flows and behaviour. |
wayfinding | Whether an area can be entered cold — a clear place to start, one name for each domain concept, and the deliberate, surprising decisions recorded where the next agent will meet them. |
why-comments | The missing reason beside code whose obvious edit breaks something — an ordering, a workaround, a deliberate duplicate — and comments that describe code that has since changed. |
Customer feedback
Reads what your customers report in the tools you connect — bug reports, support chats, feature requests, posts — groups the reports that are about the same problem, traces each problem to the code behind it, and proposes the fix, the build or the answer. It is the one loop that does not run on your repository alone: it wakes only when a connected feedback tool (Jam, Intercom, Gmail, Canny, Zendesk, Freshdesk, Plain or X) delivers a new report, and it never runs if none is connected. A complaint still open after weeks counts as much as a new one.
| Skill | What it audits |
|---|---|
bug-report | A report that something is broken — from a Jam’s console, network and user steps, a support thread or a ticket — traced to the line that fails, and whether it fails for everyone who does the same thing. |
feature-request | What customers ask for, checked against the code — missing, half-built, or built but impossible to find — and weighed by how many different customers want it. |
repeated-question | The same question asked again and again about something the product already does, turned into the change that stops it being asked — the docs, onboarding copy, empty state or error message that is missing. |
Where the seams are
Several skills sound alike from the outside, and the shelves are deliberate about who owns what:
- Retries.
retry-safety(reliability) owns the dedupe that makes a second execution harmless;idempotency-and-jobs(backend) owns the transaction and lock discipline around jobs and webhook handlers;webhooks-and-fulfillment(payments) owns the money-critical events specifically. - Queries.
query-and-index(backend) is about correctness and the index that should exist;query-latency(performance) is about what the same query costs on a hot path. - Webhooks and money.
money-and-webhooks(security) asks whether an attacker can forge or replay one;webhooks-and-fulfillment(payments) asks whether an honest one is handled exactly once. - Accessibility.
markup-safety(react) keeps the accessibility half of the former UX loop. - Structure and cleanup.
deslop(code quality) simplifies statements without changing what they do;coupling,decompositionanddeepening(architecture) change how modules divide the work. - Docs.
propagation(code quality) owns the sweep after one rename;drift(documentation) owns the guides that no longer match the code.deslopdeletes comment noise;why-comments(documentation) adds the reason that is missing. - Copies of personal data.
data-lifecycle(security) asks whether another tenant can reach a copy of a record;retention-and-erasure(compliance) asks whether that copy ever goes away. - Agents.
agents-and-browsers(security) asks whether untrusted content can push a model across a line it must not cross;safety(AI engineering) asks whether an agent’s tools and guardrails are good enough to hand it more work.
A finding on the wrong shelf is still raised; the seam decides which loop’s standard it is held to, not whether you hear about it.
Last updated November 6, 2026