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 agentmods add skills/uvwt/agentdock-skills/code-debriefnpx skills add uvwt/agentdock-skills --skill code-debriefgit clone --depth 1 https://github.com/uvwt/agentdock-skillsWhat 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 | $0.00078 | $0.01288 |
| Opus 5 | $0.00039 | $0.00644 |
| Sonnet 5 | $0.00016 | $0.00258 |
| Haiku 4.5 | $0.00008 | $0.00129 |
Grade A, and why
code-debrief 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 2d 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 — 120 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Read the real code before explaining it. Do not guess paths, behavior, dependencies, runtime order, or design intent. If a fact can be established from the codebase, Git diff, configuration, or minimal runtime observation, inspect it instead of asking the user.
The goal is learning: help the user understand and retain control of code produced through vibecoding. Start from the current project and then extract transferable engineering knowledge. Do not turn the session into a generic code review, refactoring backlog, test audit, or project-management report.
Scope
Determine the learning scope in this order:
- An explicitly supplied PR, commit, commit range, diff, file, directory, symbol, or feature.
- Current staged changes.
- Current unstaged changes.
- The most recent relevant commit.
- The user's natural-language target.
Use the selected change as the center, then inspect only the upstream and downstream code needed to explain it: entry points, direct callers, direct dependencies, important types, data/state transitions, configuration that changes behavior, and critical failure paths.
Do not mechanically explain the whole repository or every changed file.
Default interaction
Default to continuous explanation. Do not force questions after every section.
Only ask a single optional learning question when it materially helps verify a core mental model, and let the user skip it. If the user asks to be quizzed or taught interactively, switch to learning mode and ask one question at a time.
Explanation order
Use this flexible learning skeleton, adapting the order to the code type and real execution path:
- What problem or capability this code implements.
- Where execution enters.
- The main call chain or state flow.
- The smallest set of core code that makes the behavior work.
- Inputs, outputs, side effects, and state/data changes.
- Important failure or alternate paths.
- Why the code is organized this way.
- The general engineering idea that can be transferred elsewhere.
- Where to start when the user later wants to modify the behavior.
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.
- 2d ago First seen · 120 lines · 78 tokens per session scan A 42f53339dc30
code-debrief is a skill published in the GitHub repository uvwt/agentdock-skills (2 stars, last pushed 3d ago), licensed Apache-2.0. It adds 78 tokens to every session and 1,288 once invoked, about $0.0004 per session on Opus 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-08-31.
Other skills, from other repositories
offensive-vuln-classes
Exploit development curriculum covering core vulnerability classes with real-world CVE case studies: stack/heap buffer overflows, use-after-free, integer overflows, format strings, type confusion, and race conditions. Use when learning or teaching vuln classes, researching specific CVE patterns, or building exploit…
coding-tutor
Personalized coding tutorials that build on your existing knowledge and use your actual codebase for examples. Creates a persistent learning trail that compounds over time using the power of AI, spaced repetition and quizes.
practice-cognition
触发：当你提出了方案、假设或判断，需要通过实践验证、试错迭代或复盘升级认知时调用；常见信号包括 experiment、prototype、validate、iterate、feedback loop。 English: Trigger when an idea, hypothesis, or plan must be tested in practice and improved through iteration. Use this skill to move from action to understanding and back to action in a spiral learning loop.
offensive-exploit-dev-course
Full exploit development course roadmap and syllabus: weekly topics, recommended reading, lab setup, and learning path from vulnerability classes through advanced exploitation. Use to structure exploit dev training or onboard new researchers.
80-livekit-agents-majiayu000-claude-skill-registr
Create your LiveKit Agents skill from official documentation, then learn to improve it throughout the chapter.
34-openai-agents-sdk-panaversity-agentfactory-8f59f147
Create your OpenAI Agents SDK skill in one prompt, then learn to improve it throughout the chapter.