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.
npx skills add dork-labs/dorkos --skill deps-weeklygit clone --depth 1 https://github.com/dork-labs/dorkosWrote 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/skills/dork-labs/dorkos/deps-weekly)<a href="https://agentmods.dev/skills/dork-labs/dorkos/deps-weekly"><img src="https://agentmods.dev/badge/skills/dork-labs/dorkos/deps-weekly/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/skills/dork-labs/dorkos/deps-weekly"><img src="https://agentmods.dev/badge/skills/dork-labs/dorkos/deps-weekly.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.00086 | $0.01068 |
| Opus 5.5 | $0.00034 | $0.00427 |
| Sonnet 5.5 | $0.00017 | $0.00214 |
| Haiku 4.5 | $0.00009 | $0.00107 |
Grade A, and why
deps-weekly 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 7d ago.
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 — 39 lines — stays where its author put it; the contents beside it link to each section on GitHub.
deps-weekly
The weekly dependency pass. It is /app:upgrade in its default auto mode, wrapped in the rules that make it safe to run from a heartbeat with nobody watching. It is a skill, not a schedule: @dorkos-qa's heartbeat calls it on Monday, so it runs with that agent's permissions and raises no approval cards.
The procedure is .claude/commands/app/upgrade.md; the judgment is the maintaining-dependencies skill (.claude/skills/maintaining-dependencies/SKILL.md). Read both before step 3. This file adds only what a heartbeat run needs on top.
Run
- Work in a throwaway copy, never a shared checkout.
git fetch origin, pinBASE=$(git rev-parse origin/main)and compare against$BASEfor the whole run. Clear a copy a killed run left behind (git worktree remove --force "$TMPDIR/deps-weekly" 2>/dev/null; git worktree prune), thengit worktree add --detach "$TMPDIR/deps-weekly" "$BASE"and run everything from there. Each lane branches from it. - Check room first. Count worktrees on this machine that hold a
node_modules. If two already do, stop and report "skipped: disk" rather than add a third. Checkdf -h /: under 20 GB free, stop and say so. Thenpnpm install --frozen-lockfile --prefer-offlineandpnpm --filter @dorkos/shared build, on Node 24. - Run the procedure in
.claude/commands/app/upgrade.mdwith no arguments (auto). In Claude Code that is/app:upgrade; in any other harness, read the file and follow it step by step. Its autonomous contract holds as written: one PR per lane, idempotent branch prefixes, the ledger edited with the override, nothing merged by hand. - Apply the DorkOS landing rules to every PR the run opens:
- Commits are
chore(deps), neverfix(orrefactor(, so no changelog fragment is seeded. Labelskip-changelogandreview:light. - A PR that touches auth, permissions, connectors, mini apps (extensions), relay or Cloud auth opens with the
holdlabel and stays unarmed. Post it in #dorkos for @security-auditor; only their OK there lifts it. - Arm your own green PR with
gh pr merge --auto <n>only when it needs no Security review. Never an admin merge, never an empty commit, never a branch update to satisfy a gate. - Patches and security fixes land on green. A major, or anything the run calls breaking, gets a ticket for @dorkos-pm and no commit.
- Commits are
- Leave the runtime SDKs alone. The families in
.claude/config/runtime-deps.json, plus the Pi packages inpackages/doe, are excluded by the procedure's rule 2. If the run sees them drift, it names them in the report and points atruntime-watch. - Escalate security by severity. A critical or high advisory that the run fixed: ask @dorkos-pm for a same-day patch release once its PR merges. Critical with no fix: a PR (or a ticket with the blocker) within 48 hours. High: within 7 days. Medium and low: the monthly batch.
- Clean up. Remove
$TMPDIR/deps-weeklyand any lane worktree whose PR is open and pushed. Spare nothing that holds unpushed work.
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.
- 7d ago First seen · 39 lines · 86 tokens per session scan A 5184d37114d6
deps-weekly is a skill published in the GitHub repository dork-labs/dorkos (12 stars, last pushed today), licensed MIT. It adds 86 tokens to every session and 1,068 once invoked, about $0.0003 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-21.
Other skills, from other repositories
github-flow-for-claude-on-web
Complete GitHub workflow for Claude Code on the web. ALL GitHub operations MUST use REST API (never gh CLI). Includes branch naming (claude/-sessionId), push retry logic, PR/issue management via API, and complete workflows. Use for all GitHub interactions in Claude Code web environment.
stacked-pr-merge
Merging a stack of dependent PRs in this repository — a branch cut from another PR's branch rather than from main. Covers the one merge API that is not 403 here, taking the head SHA from the API, and the stale-lineage rebase that produces mass conflicts if you use plain git rebase origin/main. Use when gh pr merge…
vibing-worktree-create
Create a new git-worktree-backed isolated work area for the current vibing.nvim chat via natural language — no separate UI. Use when the user wants to isolate work in its own worktree ("split this into its own worktree", "start this in isolation", "give this its own branch").
vibing-worktree-attach
Attach the current or a new vibing.nvim chat to an already-existing git worktree via natural language — no separate UI. Use when the user wants to switch/attach a chat to an existing worktree ("let's go into the auth-fix worktree", "attach to worktree X", "continue in the feature-y worktree").
vibing-worktree-finish
Remove a git-worktree-backed isolated work area for vibing.nvim chats via natural language — no separate UI. Use when the user wants to clean one up when done ("clean up this worktree", "I'm done with this branch's worktree", "remove the auth-fix worktree").
vibing-worktree-list
List git-worktree-backed isolated work areas for vibing.nvim chats via natural language — no separate UI. Use when the user wants to see what worktrees/branches exist ("what worktrees do I have", "what's in progress", "show me all worktrees").