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 nthnclrk/enablement-skills --skill partner-enablement-packagegit clone --depth 1 https://github.com/nthnclrk/enablement-skillsWrote 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/nthnclrk/enablement-skills/partner-enablement-package)<a href="https://agentmods.dev/skills/nthnclrk/enablement-skills/partner-enablement-package"><img src="https://agentmods.dev/badge/skills/nthnclrk/enablement-skills/partner-enablement-package/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/nthnclrk/enablement-skills/partner-enablement-package"><img src="https://agentmods.dev/badge/skills/nthnclrk/enablement-skills/partner-enablement-package.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.00087 | $0.00967 |
| Opus 5.5 | $0.00035 | $0.00387 |
| Sonnet 5.5 | $0.00017 | $0.00193 |
| Haiku 4.5 | $0.00009 | $0.00097 |
Grade A, and why
partner-enablement-package 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 24d 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 — 71 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Partner enablement package
Prepare partners to carry out the activities their agreement permits, using claims and materials approved for that audience.
Partners get only what they may say and do under the agreement. Channel managers get the economics, conflict rules, and restricted proof in a separate internal pack.
Partner-safe. "You may position MosaicOps to mid-market ops buyers and register the lead. You may not quote discount, promise custom ERP, or share the four-customer pilot."
Copied pack. The AE battlecard, our win rate versus Competitor X, and the Q3 discount grid, with "partner" find-replaced in.
Keep restricted numbers in the channel manager's internal material, separate from the partner's file.
Inputs
Reuse supplied context first. If a missing company fact would change the result, check the relevant sections of .enablement/context.md when available. Preserve source dates and approval limits.
Ask only for the inputs that change the package:
- Partner type and what they are actually allowed to do
- The job after enablement: position, qualify, demo, sell, or hand off
- Approved partner-facing claims, proof, and branding
- What must stay internal: economics, discounts, account strategy, restricted proof
If a right, claim, or economic rule is missing, leave it unknown. Do not invent partner claims, discounts, territories, or readiness.
Supporting material
Read references/partner-package-blueprint.md for the copy-paste tell, claim classification, and the partner-facing versus internal split. Skip it if they already handed you a classified source list and only want assembly.
Procedure
- Define the permitted motion. Map what this partner may position, qualify, demonstrate, sell, deliver, and hand off. Partner type is context, not permission. Done when each activity has a scope, a prohibited commitment, and a handoff owner.
- Classify every source.
Mark
partner_safe,internal_only, orunverified. Direct-seller approval does not approve partner use. Done when nothing unverified sits in a partner-facing artifact. - Build the partner-facing package from
partner_safeonly. Positioning, qualification, handoff, approved proof, and the learning they need for this motion. Cut anything a direct AE uses that this partner cannot defend. - Build the internal operator pack separately. Rights, lead registration, split rules, discount authority, conflict escalation, restricted content, exceptions, and support obligations. Never nest this inside a partner document.
- Define observable readiness.
Practise the permitted task with realistic partner constraints and feedback. Specify the evidence, standard, assessor, and remediation needed for independent work. Attendance alone cannot establish readiness. If the decision is a formal pass/fail, use
certification-program-builderand consume that artifact; do not recreate it. - Review the boundary. Block unverified claims, expired assets, and content outside this partner's rights. Done when a channel manager can hand the external file to a partner without redacting.
What ships with it
2 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- 24d ago Changed · +2 lines a0a4f5724ec2
- 2mo ago First seen · 69 lines · 87 tokens per session scan A 58ba65d0b150
partner-enablement-package is a skill published in the GitHub repository nthnclrk/enablement-skills (16 stars, last pushed 25d ago), licensed MIT. It adds 87 tokens to every session and 967 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-08-30.
partner-enablement-package compared with skills from other repositories
| Mod | Type | Stars | Last push | Licence | Scan | Tokens | Works with |
|---|---|---|---|---|---|---|---|
| partner-enablement-packagenthnclrk/enablement-skills | Skill | 16 | 25d ago | MIT | A | 87 | Codex |
| imagegenopenai/codex | Skill | 133k | yesterday | Apache-2.0 | A | 113 | Codex |
| playwright-climicrosoft/playwright | Skill | 99k | yesterday | Apache-2.0 | A | 19 | Claude Code |
| local-ai-agentsmicrosoft/ai-agents-for-beginners | Skill | 79k | 4d ago | MIT | A | 200 | Claude Code, Codex |
| systematic-debuggingobra/superpowers | Skill | 313k | 3d ago | MIT | A | 21 | Claude Code |
| next-cache-components-adoptionvercel/next.js | Skill | 143k | yesterday | MIT | A | 95 | Claude Code |
| next-partial-prefetching-adoptionvercel/next.js | Skill | 143k | yesterday | MIT | A | 103 | Claude Code |