skilldrop-cli 0.16.3__py3-none-any.whl

skilldrop_cli/data/packs/ai-engineering/skills/ai-readiness-assessment/evals/evals.json

@@ -0,0 +1,17 @@
+{
+  "skill_name": "ai-readiness-assessment",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "We're a 200-person fintech. Engineering has Copilot licences that about a third of people use, we have no written AI policy, our docs are spread across Confluence and Notion, and leadership keeps asking when we'll 'be an AI company'. Are we ready?",
+      "assertions": [
+        "All six dimensions (data, tooling, skills, governance, process, culture) are scored 0-4 — none is omitted",
+        "Every score carries a one-line evidence reference drawn from the input, or is marked [insufficient evidence: <what to collect>]",
+        "Gaps are ranked by what blocks adoption first, with the dependency named — not simply sorted by lowest score",
+        "Every gap has a concrete first action and an owner expressed as a role, not a person's name",
+        "The posture sentence takes a position and names the condition that would change it",
+        "No facts are invented beyond what the prompt supplies"
+      ]
+    }
+  ]
+}

skilldrop_cli/data/packs/ai-engineering/skills/ai-readiness-assessment/manifest.json

@@ -0,0 +1,35 @@
+{
+  "name": "ai-readiness-assessment",
+  "version": "0.1.1",
+  "description": "Score an organisation's or team's readiness to adopt AI tooling across six gating dimensions — data, tooling, skills, governance, process, and culture — with an evidence line per score and the blocking gaps ranked by what stops adoption first. Use when the user asks \"are we ready for AI\", wants an AI maturity or readiness baseline, or needs to know what to fix before rolling tools out. Do NOT use to pick which use cases to build (that's ai-use-case-triage) or to plan the rollout itself (that's ai-adoption-rollout).",
+  "entrypoint": "SKILL.md",
+  "deps": {
+    "npm": [],
+    "pip": []
+  },
+  "env": {
+    "required": [],
+    "optional": []
+  },
+  "related": [
+    "agent-adoption-stage",
+    "ai-adoption-rollout",
+    "ai-usage-policy",
+    "ai-usage-report",
+    "ai-use-case-triage",
+    "strategy-analysis",
+    "tech-comparison-matrix"
+  ],
+  "tags": [
+    "ai-adoption",
+    "readiness",
+    "maturity-assessment",
+    "governance",
+    "change-management",
+    "baseline"
+  ],
+  "model": {
+    "tier": "standard",
+    "rationale": "Scores six fixed dimensions against a rubric and ranks gaps by blocking order. Bounded structured judgment, not adversarial reasoning; escalate via ambiguous-input when the evidence is thin or contested."
+  }
+}

skilldrop_cli/data/packs/ai-engineering/skills/ai-usage-policy/SKILL.md

@@ -0,0 +1,67 @@
+---
+name: ai-usage-policy
+description: Draft an organisation's AI acceptable-use policy — three data-sensitivity tiers with what may be put into a tool at each, permitted and prohibited uses stated as behaviours, a human-review matrix keyed to consequence, an approved-tool list with an exception route, and a named owner per rule. Use when a team needs rules for what people may put into AI tools, or asks for an AI acceptable-use or governance policy. Do NOT use to write a repo's agent-tooling policy (that's agents-md-generator) or to analyse one agent's capability surface (that's agent-threat-model).
+---
+
+# ai-usage-policy
+
+Write the policy people will actually follow: **what may go in, what must be checked before it goes out, and who to ask when the rule doesn't fit.** The audience is every employee, not the security team — so it reads as rules for a job, not controls for an auditor.
+
+A policy that prohibits without offering a permitted path doesn't reduce risk; it moves the same work onto personal accounts where nobody can see it. Every prohibition here carries an alternative.
+
+## How to respond
+
+1. **Establish scope and the regulatory floor.** Which population, which tools, and any regime already binding (sector rules, customer contracts, an existing data-classification scheme). If the organisation already classifies data, **reuse those tier names** rather than inventing a parallel scheme — two classification systems means neither is followed. Cap clarifying questions at 2.
+
+2. **Define three data tiers and what may enter a tool at each.** Three, because five is not memorable and one is not a policy:
+
+   | Tier | Examples | Rule |
+   |---|---|---|
+   | **Open** | public docs, published marketing, open-source code | any approved tool |
+   | **Internal** | internal docs, non-personal telemetry, private repo code | approved tools with data-retention off / enterprise terms |
+   | **Restricted** | personal data, credentials, customer content under contract, regulated records | never pasted; only via a named reviewed integration, if at all |
+
+   Give each tier **two concrete examples from this organisation's actual work** — abstract tiers are the reason policies get ignored.
+
+3. **State permitted and prohibited uses as behaviours.** ✅ "Drafting a first version of a customer email, then editing before sending." ❌ "Inappropriate use." Every prohibition names the **permitted alternative**: "Do not paste customer records to summarise them — use the approved integration, which does the same thing without the data leaving."
+
+4. **Build the human-review matrix on consequence, not on technology.** What must a human check before an AI-assisted output is acted on? Key it to blast radius: reaches a customer · commits money or a legal position · changes production · informs a personnel decision. Each row says who reviews and what "reviewed" means. Low-consequence internal drafting needs no gate — say so, or the policy loses credibility everywhere else.
+
+5. **List approved tools, and give an exception route.** Named tools with the tier they're cleared to. Then the route for anything else: who approves, what they check, and a target turnaround. **A policy with no exception path is a policy people route around** — the turnaround time is the part that makes it real.
+
+6. **Name an owner per section, a review date, and the disclosure rule.** Owners as roles. A review date, because tool terms change. And one line on whether AI assistance must be disclosed, and where — the question every employee actually has.
+
+## Quality bar
+
+- **Every rule has a named owner role** and the document has a review date. An unowned policy is a document, not a control.
+- **Every prohibition names a permitted alternative**, or it drives the work into the shadows.
+- **Data tiers carry concrete examples from this organisation**, not generic labels.
+- **The review matrix is keyed to consequence, not to tool or model.** Model names age out in months; consequences don't.
+- **There is an exception route with a turnaround time.**
+- **Written for the whole staff.** If a non-technical reader hits an unexplained term, rewrite it — the audience is everyone, and unread rules govern nothing.
+- **No invented regulation.** Cite only regimes the user named; where applicability is unclear, mark `[confirm with counsel]` rather than asserting a legal position.
+
+## When to use this skill
+
+- ✅ "What are people allowed to put into these tools?" — the question every rollout hits in week one.
+- ✅ Standing up governance before or alongside an AI rollout.
+- ✅ Replacing an informal "be sensible" norm with something reviewable.
+
+## When NOT to use this skill
+
+- ❌ Writing a repository's agent-tooling policy (`AGENTS.md` — build commands, conventions, what agents may edit) — that's `agents-md-generator`.
+- ❌ Threat-modelling one agent's data reach and exfiltration paths — that's `agent-threat-model`.
+- ❌ Planning how the tool reaches people — that's [`ai-adoption-rollout`](../ai-adoption-rollout/SKILL.md).
+- ❌ Assessing whether governance is mature enough yet — that's [`ai-readiness-assessment`](../ai-readiness-assessment/SKILL.md).
+- ❌ A security review of a design — that's `threat-model`.
+
+## Anti-patterns to avoid
+
+- ❌ **Prohibition without an alternative.** "Never paste customer data" with no sanctioned path moves the work to a personal account and removes your visibility entirely.
+- ❌ **Naming models and versions in the rules.** They change quarterly; consequence-based rules survive. Keep tool names in the approved-list appendix where they're cheap to update.
+- ❌ **Five or more tiers.** Nobody classifies correctly against a scheme they can't recall at the moment of pasting.
+- ❌ **Writing for auditors.** A policy in control language gets filed, not followed. Plain rules for a working day.
+- ❌ **No exception route.** Guarantees either shadow usage or a queue of blocked work — and you find out about neither.
+- ❌ **Requiring review of everything.** A gate on low-consequence drafting trains people to ignore gates that matter.
+
+**Non-interactive:** with no user to ask, assume no sector-specific regime beyond general data-protection practice and tag it `[assumption]`, listing what to confirm. If the input names no organisation type or data context, emit `BLOCKED: need the population covered and the kinds of data they handle` — a fabricated policy is worse than none, because it will be circulated as if it were reviewed.

skilldrop_cli/data/packs/ai-engineering/skills/ai-usage-policy/evals/eval_queries.json

@@ -0,0 +1,34 @@
+[
+  {
+    "query": "Write our AI acceptable-use policy",
+    "should_trigger": true
+  },
+  {
+    "query": "What are people allowed to put into these AI tools?",
+    "should_trigger": true
+  },
+  {
+    "query": "We need AI governance rules before we roll this out",
+    "should_trigger": true
+  },
+  {
+    "query": "Draft data-handling tiers for AI tool usage",
+    "should_trigger": true
+  },
+  {
+    "query": "Generate the AGENTS.md for this repository",
+    "should_trigger": false
+  },
+  {
+    "query": "Threat model our agent's data access and exfiltration paths",
+    "should_trigger": false
+  },
+  {
+    "query": "Plan the rollout cohorts and enablement",
+    "should_trigger": false
+  },
+  {
+    "query": "Assess whether our governance is mature enough",
+    "should_trigger": false
+  }
+]

skilldrop_cli/data/packs/ai-engineering/skills/ai-usage-policy/evals/evals.json

@@ -0,0 +1,19 @@
+{
+  "skill_name": "ai-usage-policy",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Write an AI acceptable-use policy for our 500-person company. We handle customer support data including names and order history, and people are already pasting things into chatbots.",
+      "assertions": [
+        "Exactly three data tiers are defined, each with concrete examples drawn from the organisation described",
+        "Permitted and prohibited uses are stated as behaviours, not abstractions like 'inappropriate use'",
+        "Every prohibition names a permitted alternative path for the same work",
+        "The human-review matrix is keyed to consequence (customer-facing, financial, production, personnel) rather than to tool or model names",
+        "An approved-tool list is accompanied by an exception route with an approver and a turnaround time",
+        "Every section names an owner role and the document carries a review date",
+        "The disclosure rule states whether and where AI assistance must be declared",
+        "No regulation is asserted beyond what the prompt names; unclear applicability is marked [confirm with counsel]"
+      ]
+    }
+  ]
+}

skilldrop_cli/data/packs/ai-engineering/skills/ai-usage-policy/manifest.json

@@ -0,0 +1,33 @@
+{
+  "name": "ai-usage-policy",
+  "version": "0.1.0",
+  "description": "Draft an organisation's AI acceptable-use policy — three data-sensitivity tiers with what may be put into a tool at each, permitted and prohibited uses stated as behaviours, a human-review matrix keyed to consequence, an approved-tool list with an exception route, and a named owner per rule. Use when a team needs rules for what people may put into AI tools, or asks for an AI acceptable-use or governance policy. Do NOT use to write a repo's agent-tooling policy (that's agents-md-generator) or to analyse one agent's capability surface (that's agent-threat-model).",
+  "entrypoint": "SKILL.md",
+  "deps": {
+    "npm": [],
+    "pip": []
+  },
+  "env": {
+    "required": [],
+    "optional": []
+  },
+  "related": [
+    "agent-threat-model",
+    "agents-md-generator",
+    "ai-adoption-rollout",
+    "ai-readiness-assessment",
+    "threat-model"
+  ],
+  "tags": [
+    "ai-adoption",
+    "governance",
+    "acceptable-use",
+    "policy",
+    "data-classification",
+    "compliance"
+  ],
+  "model": {
+    "tier": "standard",
+    "rationale": "Drafts a policy document against a fixed structure (tiers, behaviours, review matrix, exception route). Bounded generation; escalate via ambiguous-input where a regulatory regime is named or contested."
+  }
+}

skilldrop_cli/data/packs/ai-engineering/skills/ai-usage-report/SKILL.md

@@ -0,0 +1,111 @@
+---
+name: ai-usage-report
+description: Generate a per-user or team-level report on how AI tools are being used — volume, breadth, and effectiveness signals (e.g. whether AI outputs landed in shipped artifacts vs were generated and discarded). Consumes usage-event logs exported from an MCP server or other telemetry source. Use when a manager or team lead needs to understand AI adoption beyond raw counts — including spotting "AI theater" where people invoke AI to claim usage but don't act on the outputs.
+---
+
+# ai-usage-report
+
+You help the user turn a raw AI-usage log into a readable, useful report — one that distinguishes "people doing real work with AI" from "people pressing the button to be seen pressing the button."
+
+This skill **consumes** telemetry that someone else collected (an MCP server, an IDE telemetry pipeline, a manual CSV export). It does **not** collect the data itself. Your job is to:
+
+1. Take the input file from the user.
+2. Run the report script to compute aggregates and effectiveness signals.
+3. Wrap the output with a short executive narrative tailored to the requesting audience.
+
+## How to respond
+
+1. **Confirm three inputs** before generating anything:
+
+   - **Input file.** A CSV or JSONL of usage events. Schema lives in [`templates/usage-event-schema.md`](templates/usage-event-schema.md). If the user's file columns don't match the schema, *map the columns with them* before running — don't guess at field names.
+
+   - **Reporting period.** `week`, `month`, or explicit `--from <date> --to <date>`. If the user gives a fuzzy period ("recently"), pick the last 7 calendar days and call out your choice.
+
+   - **View.** Exactly one of:
+     - `per-user` — named breakdown, manager view, includes effectiveness scores
+     - `team-rollup` — aggregate-only, no individual names, safe for staff/exec audiences
+     - `effectiveness` — focused on AI-theater flags and outputs-not-consumed signals
+
+     If the user hasn't picked a view, **ask**. Defaults aren't safe here — the wrong view in the wrong audience's hands creates a workplace problem.
+
+2. **Call out what the data does NOT support before running.** If the events have no `output_consumed` field, you cannot compute effectiveness — say so. If `session_id` is missing, you cannot compute breadth-per-session. The report should not invent numbers it doesn't have evidence for. Read the input's header (CSV) or first object (JSONL) and list which optional fields are present.
+
+3. **Run the build script.**
+
+   ```bash
+   # Claude Code
+   python3 "${CLAUDE_SKILL_DIR}/scripts/build_report.py" /path/to/events.csv \
+     --view per-user --period week --out ./out/ai-usage-week.md
+
+   # Other IDEs (from the skill folder)
+   cd path/to/ai-usage-report && python3 scripts/build_report.py /path/to/events.csv \
+     --view per-user --period week --out ./out/ai-usage-week.md
+   ```
+
+   The script writes a markdown file using the matching template in `templates/`. Read it before handing back — sanity-check that the numbers reconcile with the input row counts.
+
+4. **Add a 3-sentence handoff** above the report when delivering:
+   - **One sentence on volume** — total invocations, distinct users, period covered.
+   - **One sentence on what the data does and doesn't show** — flag missing signals explicitly.
+   - **One sentence on the most actionable pattern** — usually either "X users haven't engaged" or "Y% of outputs were generated but never consumed."
+
+   Then the report itself.
+
+5. **Do not make a recommendation about specific named individuals** in the handoff. The report shows what it shows; turning patterns into HR-style judgments is the manager's call, not the skill's.
+
+## Useful references in this skill
+
+- [`templates/usage-event-schema.md`](templates/usage-event-schema.md) — the input event schema (required vs optional fields, graceful-degradation rules)
+- [`templates/report-per-user.md`](templates/report-per-user.md) — per-user named-report layout
+- [`templates/report-team-rollup.md`](templates/report-team-rollup.md) — aggregate team-level layout
+- [`examples/weekly-engineering-team.md`](examples/weekly-engineering-team.md) — worked example: stub events → both report views
+- [`scripts/build_report.py`](scripts/build_report.py) — the generator (stdlib only)
+
+## Effectiveness signals (what "performative vs effective" actually means here)
+
+The skill has **no magic classifier**. It exposes a set of signals the user interprets. Each signal is a column or counter in the report.
+
+| Signal | What it means | When it's reliable |
+|---|---|---|
+| **`output_consumed` rate** | % of AI invocations whose output landed in a shipped artifact (commit, PR, doc) | Only if telemetry tracks downstream consumption. If absent, this column is omitted, not faked. |
+| **Single-shot rate** | % of sessions with exactly one invocation and no follow-up | High single-shot + low effectiveness = a starting place to ask about engagement |
+| **Breadth** | Number of distinct tools/skills the user invoked | Low breadth + high volume = one-trick usage pattern |
+| **Session depth** | Avg invocations per session | High depth often correlates with iterative, engaged use |
+| **Output-to-shipped lag** | Median hours between AI invocation and artifact ship | Only meaningful if downstream consumption is tracked |
+| **Discard rate** | % of outputs explicitly rejected (IDE-level signal) | Requires IDE instrumentation; many sources lack this |
+
+**None of these signals is a verdict.** A high single-shot rate could mean theater, or it could mean the user solved their problem in one prompt. Low breadth could mean focused expertise. The report's job is to surface patterns; the manager's job is to interpret them.
+
+## Quality bar
+
+- **Numbers are computed from the input, not estimated.** If the script cannot compute a metric (missing field), the column is omitted with a note. Never fill with `~` or `est.` placeholders.
+- **Per-user reports include only users present in the input.** Don't infer missing users from elsewhere.
+- **The "AI theater" framing lives in section headers, not in per-user judgments.** Say "Single-shot rate: 87%" — never "Alice is doing AI theater."
+- **Privacy posture matches the view.** `per-user` names individuals; `team-rollup` never names anyone, even in passing.
+- **Recommendations target patterns, not people.** "Consider a deeper-engagement workshop for the team" — never "Coach Alice to engage more deeply."
+- **Period is explicit on the report header.** Every report shows the dates it covers.
+- **Sample size is honored.** If `n_users < 5` in a team-rollup, the report is no longer anonymous — refuse to generate the team-rollup view and tell the user why.
+
+## When to use this skill
+
+- ✅ A manager has a CSV/JSONL of AI usage events and wants a weekly/monthly read.
+- ✅ A team lead wants to spot adoption gaps without naming individuals.
+- ✅ An exec needs an AI-adoption rollup that doesn't read like a control panel.
+- ✅ Building a baseline before/after rolling out a new AI tool or training.
+
+## When NOT to use this skill
+
+- ❌ You don't have usage telemetry yet — the skill consumes data, doesn't collect it. The collection-side spec (event schema, MCP server) lives in the skilldrop repo at `docs/designs/ai-usage-telemetry-design.md`.
+- ❌ You want to *judge* specific named people. The skill surfaces patterns; performance judgments based on AI usage are a different (and harder) decision.
+- ❌ The input lacks every effectiveness field. You can still produce a volume report, but call out the limitation explicitly — don't ship a report that looks like effectiveness analysis when it isn't.
+- ❌ Your team is < 5 people *and* the view is team-rollup. Aggregate views aren't anonymous at that size.
+
+## Anti-patterns to avoid
+
+- ❌ Inferring effectiveness from prompt length, prompt count, or session count alone. These measure *activity*, not *value*.
+- ❌ Naming individuals in a team-rollup report — once a name appears in aggregate context, the report has crossed into per-user territory.
+- ❌ Reporting on periods with too little data ("Mon–Tue only") and presenting it as a trend.
+- ❌ Faking effectiveness columns when the input lacks them. Omit, don't estimate.
+- ❌ Generating an "AI theater leaderboard" of named users. That's a workplace incident, not a report.
+- ❌ Embedding the input prompts verbatim in the report. Prompts often contain sensitive content (code, customer data); the report works from metadata only.
+- ❌ Comparing two periods that aren't normalized (e.g. a 7-day week against a 10-business-day window). If the script can't normalize, say so.

skilldrop_cli/data/packs/ai-engineering/skills/ai-usage-report/evals/eval_queries.json

@@ -0,0 +1,30 @@
+[
+  {
+    "query": "Build me a monthly AI adoption report from this usage-event CSV",
+    "should_trigger": true
+  },
+  {
+    "query": "Which teams are generating AI output but never shipping it? Here's the telemetry export",
+    "should_trigger": true
+  },
+  {
+    "query": "Turn this JSONL of MCP usage events into a team rollup I can show execs",
+    "should_trigger": true
+  },
+  {
+    "query": "I suspect some people are invoking Copilot just to hit a usage target — can the logs show that?",
+    "should_trigger": true
+  },
+  {
+    "query": "Design a golden set and regression gate for our support-bot prompt",
+    "should_trigger": false
+  },
+  {
+    "query": "Define the product success metrics for our new AI summarization feature",
+    "should_trigger": false
+  },
+  {
+    "query": "Write the policy on which AI tools staff may use with customer data",
+    "should_trigger": false
+  }
+]

skilldrop_cli/data/packs/ai-engineering/skills/ai-usage-report/evals/evals.json

@@ -0,0 +1,19 @@
+{
+  "skill_name": "ai-usage-report",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Here's our AI usage export for September 1-30: northwind-ai-events.csv, 4,212 rows, 14 engineers on the platform team. Columns are timestamp, user_email, tool_name, session_id, output_consumed. There's no discard field. I want the team-rollup view for our VP's monthly staff meeting — she wants to know whether people are actually using what the AI gives them or just clicking the button.",
+      "assertions": [
+        "The report header states the exact period covered (2026-09-01 to 2026-09-30)",
+        "The team-rollup names no individual anywhere — no emails, names, or per-person rows, even in passing",
+        "The handoff is three sentences above the report: volume, what the data does and doesn't show, and the most actionable pattern",
+        "The discard-rate signal is omitted with a note that the input has no discard field, rather than estimated or shown with '~' or 'est.' placeholders",
+        "The output-consumed rate and other numbers are computed from the input rows and reconcile with the 4,212-row count; no metric is invented",
+        "The 'AI theater' framing appears only in section headers and pattern-level observations, never as a judgment about a person",
+        "Recommendations target team patterns (e.g. a workshop), not specific people",
+        "No prompt text is embedded in the report; it works from metadata only"
+      ]
+    }
+  ]
+}