Borrowing it
Nothing to install: this file belongs to mick-gsk/drift. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/mick-gsk/drift/main/.github/skills/drift-adr-workflow/SKILL.mdgit clone --depth 1 https://github.com/mick-gsk/driftWrote 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/mick-gsk/drift/drift-adr-workflow)<a href="https://agentmods.dev/skills/mick-gsk/drift/drift-adr-workflow"><img src="https://agentmods.dev/badge/skills/mick-gsk/drift/drift-adr-workflow.svg" alt="Measured on agentmods" 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.00060 | $0.01405 |
| Opus 5 | $0.00030 | $0.00702 |
| Sonnet 5 | $0.00012 | $0.00281 |
| Haiku 4.5 | $0.00006 | $0.00140 |
Grade A, and why
drift-adr-workflow 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 8d 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 — 169 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Drift ADR Workflow Skill
Use this skill when a Drift change needs a documented architectural or product decision before implementation.
When To Use
- A signal is added or materially changed
- Scoring logic or weights are changed
- Output formats or output contracts are changed
- An architecture boundary, trust boundary, input path, or output path changes
- An existing ADR draft must be completed or validated
Core Rules
- Run the Drift Policy Gate first. If the task is not admissible, stop.
- ADR first, implementation second. For signal, scoring, output-format, or architecture-boundary changes, prepare the ADR before coding.
- Agents may draft, not accept. Agents may create or update ADRs with status
proposed; only the maintainer changes status toacceptedorrejected. - Validation must be testable. Every ADR needs a concrete validation section with measurable checks or outcomes.
- Do not blur bugfixes and architectural decisions. Pure bugfixes and pure refactorings do not automatically require a new ADR.
Step 0: Run The Drift Policy Gate
Before drafting an ADR, use the mandatory gate format from .github/instructions/drift-policy.instructions.md.
If the task fails the gate, do not create an ADR to legitimize inadmissible work.
Step 1: Decide Whether An ADR Is Required
Create or update an ADR when the change affects one of these categories:
- signal design or signal behavior
- scoring or prioritization logic
- output schema or result format
- architecture or trust boundaries
Do not force a new ADR for:
- typo fixes
- isolated test-only work
- pure refactors without behavior change
- contained bugfixes that preserve the existing design decision without materially changing signal behavior, scoring logic, output contracts, or trust assumptions
If unsure, prefer a draft ADR that states the uncertainty explicitly.
Interface-Design-Tipp: Vor dem Festschreiben eines Signal- oder API-Interface-Designs lohnt es sich, 2–3 Sub-Agenten mit explizit verschiedenen Constraints parallel zu spawnen (z. B. „minimiere das Interface", „maximiere Flexibilität", „optimiere für den häufigsten Caller"). Radikale Constraint-Divergenz erzwingt qualitativ unterschiedliche Designs — parallele Agenten ohne Vorgaben konvergieren meist zu ähnlichen Lösungen. Das subagent-driven-development-Skill liefert den operativen Rahmen.
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.
- 8d ago First seen · 169 lines · 60 tokens per session scan A 13213cec4a6a
drift-adr-workflow is a skill published in the GitHub repository mick-gsk/drift (15 stars, last pushed 1mo ago), licensed MIT. It adds 60 tokens to every session and 1,405 once invoked, about $0.0003 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-30.
Other skills, from other repositories
dispatcher
Use this skill when running a Taniwha build from the main Claude Code session. The skill turns the main session into a thin, mechanical executor that follows instructions from ephemeral orchestrator subagents. Trigger this whenever the user wants to start a Taniwha build, resume an interrupted one, or work on a…
contract-derivation
Use this skill after a design document exists and before any module is implemented. It takes a design doc and derives per-module contracts (manifests) that are complete enough for an implementor working in isolation to build each module correctly without seeing the rest of the system. Trigger this whenever the user…
design-doc
Use this skill before writing any non-trivial code, especially when starting a new feature, service, or codebase. It produces a structural design document that commits to module boundaries, contracts, and data shapes BEFORE implementation begins. Trigger this whenever the user describes building something new, asks to…
verifier
Use this skill when verifying that a completed Taniwha implementation or composition satisfies its contract's acceptance criteria. The verifier reads the contract, the implementation's source files, and the project context, then writes its own tests against the contract's acceptance criteria, runs them, and reports…
composition
Use this skill when wiring two completed modules together to satisfy a parent contract, especially in a compartmentalised setting. Trigger this whenever the user has two implemented modules (each with its manifest) and a parent contract that says how they should compose, when the user asks to "compose these modules"…
leaf-implementation
Use this skill when implementing a single module against a contract manifest, especially in a compartmentalised setting where the implementor should NOT see the rest of the system. Trigger this whenever a manifest exists and the user wants to implement that module, asks to "implement this module", "build against this…