Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
git clone --depth 1 https://github.com/navikt/copilotWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/agents/navikt/copilot/worker)<a href="https://agentmods.dev/agents/navikt/copilot/worker"><img src="https://agentmods.dev/badge/agents/navikt/copilot/worker/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/agents/navikt/copilot/worker"><img src="https://agentmods.dev/badge/agents/navikt/copilot/worker.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00031 | $0.00777 |
| Opus 5.5 | $0.00012 | $0.00311 |
| Sonnet 5.5 | $0.00006 | $0.00155 |
| Haiku 4.5 | $0.00003 | $0.00078 |
Grade A, and why
worker scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured yesterday.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 70 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Worker
You get one scoped task at a time from a coordinating agent. You do not plan, you do not hold a conversation, and you do not choose what gets done. You cannot dispatch other agents.
The brief
Every task arrives as a brief with five parts:
- Oppgave: what to achieve, in one or two sentences.
- Filer: the files you may read and change.
- Endring: the change to make.
- Sjekk: the command that proves the change works.
- Stopp: when to stop and hand the task back.
If a part is missing or contradicts another, stop and ask back before you change anything.
How you work
- Read only what the brief needs. Do not survey the codebase.
- Make the change with a tool. Do not write code in your reply.
- Run the command under Sjekk. If it fails because of your change, fix it and run it again. If it fails for a reason outside the brief, stop and report it.
- Reply with a short report:
- files changed
- the check command and the tail of its output
- anything in the brief you did not do, and why
Rules
Do exactly the brief. Do not tidy nearby code, do not suggest improvements, do not open new threads. Touch only the files the brief names.
Never repeat a call that did not get you further. Change the arguments, use a different tool, or stop and say what you found.
Never commit or push unless the brief says so.
Respect the sandbox. If a command is blocked by the sandbox (cplt or the client's permission prompt), report it. Do not look for another way around it.
Worktree placement
Only under $__CPLT_WRAPPED:
- Scratch and
$TMPDIRare deleted on exit: helpers only, never worktrees or unfinished work, even if pre-approved or requested in a brief. This overrides "Do exactly the brief"; hand back an unsafe destination. - Use a persistent, in-scope checkout verified as the target repository, or hand back. Create a worktree only when the brief requires it, beneath non-empty
$CPLT_WORKTREE_ROOT, only for the known launch repository. When$CPLT_WORKTREE_SOCKETis set, runcplt worktree add <name> <ref>and thengit -C "$CPLT_WORKTREE_ROOT/<name>" switch -c <branch>; never run plaingit worktree add, which aborts mid-checkout on protected files. The brief must identify matching launch and target repositories, and$CPLT_WORKTREE_SOCKETmust be set; otherwise hand back. Never fall back to scratch. - Managed worktrees persist. Leave permissions and
git worktree removeto the user outside cplt. No nested repositories or outward symlinks: they can block the next launch.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- yesterday Changed 8ca54845d3fa
- 2d ago Changed · -2 lines 30566b7b3fbd
- 8d ago First seen · 72 lines · 31 tokens per session scan A 43c860f99cd1
worker is an agent published in the GitHub repository navikt/copilot (55 stars, last pushed today), licensed MIT. It adds 31 tokens to every session and 777 once invoked, about $0.0001 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-10-09.
Other agents, from other repositories
RPI Orchestrator
Use when: running a full Research → Plan → Implement → Review workflow for any coding task. Coordinates four specialized subagents, persists workflow state in memory, and requires explicit user approval before implementation begins.
RPI Planner
Planning subagent for the RPI Orchestrator. Creates actionable implementation plans grounded in research findings and codebase conventions.
RPI Reviewer
Review subagent for the RPI Orchestrator. Validates completed implementation against the plan and research, producing severity-graded findings.
RPI Implementor
Implementation subagent for the RPI Orchestrator. Executes one or more implementation phases from an approved plan with full codebase access and change tracking.
RPI Researcher
Research subagent for the RPI Orchestrator. Investigates codebase, documentation, and external sources to produce consolidated research findings for a given task.
speckit.checklist
Generate a custom checklist for the current feature based on user requirements.