Borrowing it
Nothing to install: this file belongs to khaoss85/agent-crm. 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/khaoss85/agent-crm/main/.agents/skills/build-delivery-handover/SKILL.mdgit clone --depth 1 https://github.com/khaoss85/agent-crmWrote 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/khaoss85/agent-crm/build-delivery-handover)<a href="https://agentmods.dev/skills/khaoss85/agent-crm/build-delivery-handover"><img src="https://agentmods.dev/badge/skills/khaoss85/agent-crm/build-delivery-handover/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/khaoss85/agent-crm/build-delivery-handover"><img src="https://agentmods.dev/badge/skills/khaoss85/agent-crm/build-delivery-handover.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.00186 | $0.03111 |
| Opus 5 | $0.00093 | $0.01555 |
| Sonnet 5 | $0.00037 | $0.00622 |
| Haiku 4.5 | $0.00019 | $0.00311 |
Grade A, and why
build-delivery-handover 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 12d 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 — 108 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Orient yourself first
npm run crm -- app inspect --json
Read valid, then problems[], then limitations[], in that order. Every problem is fixed or reported before anything is built on top of it, and every limitation is a hard boundary on what you may claim. Then read packages[], capabilities[], resources[], actions[], policies[] and providers[]: that list is what exists. A capability absent from the report does not exist, whatever a record name, a label or a document suggests.
If the repository documents this skill names are absent, you are in a project built from this framework rather than in the framework itself. The inspection report is then the source of truth and those documents are optional background — do not guess at their contents, and do not assume a path exists because this skill names it.
This skill depends on one capability, so check it in the report before anything else: capabilities[] must carry delivery-obligations with status: "resolved". A missing or provider-mismatch edge is the answer to why nothing here will work, and it is reported rather than worked around.
Background, where they exist: ARCHITECTURE.md, DECISIONS.md (ADR-018 and its addenda, and ADR-019 with addendum 1), docs/DELIVERY_HANDOVER.md, docs/DELIVERY_ECONOMICS.md, docs/DELIVERY_CHANGE_ACCEPTANCE.md, docs/MODULE_EVOLUTION.md and docs/PACKAGE_AUTHORING.md. They are the deeper source for the rules below, not a prerequisite for them — the rules stand on their own.
It plans and runs; it does not cost, bill or accept
- Milestone 13 records a handover: a Delivery Project (
pending_kickoff), one Work Package per delivery obligation, a milestone plan and an optional partner engagement. Milestone 14a runs it. Nothing schedules, staffs, costs, bills or accepts — and no text may imply otherwise. - A planned milestone is not a contractual or billing milestone. Say so wherever one is shown.
- Target dates are post-sale planning data (
datesSource: "post-sale-delivery-planning"), not signed terms and not a customer commitment. Nothing fires on them; there is no scheduler.
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.
- 12d ago First seen · 108 lines · 186 tokens per session scan A 24b7c493ce90
build-delivery-handover is a skill published in the GitHub repository khaoss85/agent-crm (2 stars, last pushed today), licensed MIT. It adds 186 tokens to every session and 3,111 once invoked, about $0.0009 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
flowai-live-dashboard-template
Team-management dashboard skill in the FlowAI aesthetic — three tabs (Team Members, Team Details, Activity Log), KPI stat row, member table, role distribution bar chart, online presence and activity sparklines, and a top-contributors panel, all in a single self-contained HTML file with light/dark theming, hoverable…
weekly-update
OpenDesign's weekly metrics standup: this week's numbers, the one anomaly, and the single decision it forces. Built as a decision-grade data & finance deck for ops & growth team.
code-import
Read an existing repository's structure into the project cwd as a normalised snapshot the agent can analyse without re-walking the tree on every turn.
pm-spec
A product-specification page skill for documenting a feature's problem, goals, user stories, success measures, rollout plan, and open questions. A PRD is a document that explains what a product feature should achieve and why.
team-okrs
OKR tracker page — quarter banner, three objectives with their key results as progress bars, owner avatars, status pills, and a "this quarter at a glance" sidebar. Use when the brief mentions "OKRs", "key results", "objectives", or "目标".
huashu-keynote-black
OpenDesign's all-hands: the year in review, the three priorities, and what every team owns next quarter. Built as a decision-grade corporate strategy deck for whole company.