AI engineering
- When to use it
- Adopt and build AI systems: readiness assessment, use-case triage, rollout and acceptable-use policy, plus agent loop design, subagent orchestration, spend budgets, agent security review, eval harnesses, and AI-usage reporting.
- Covers
- Govern AI use (8), Design the system (5), Build and review software (2)
- Where you decide
- No gated loop of its own; the skills run one at a time.
- Size
- 20 skills · 0 loops
npx skilldrop-cli install --pack ai-engineering
Installs 20 skills, including core.
Other ways to install
The pack's loops too, each as an invokable skill:
npx skilldrop-cli install --loop --pack ai-engineering
In Claude Code, as a plugin (after /plugin marketplace add sananthanarayan/skilldrop):
/plugin install ai-engineering@skilldrop
Into Cursor, Kiro or another IDE:
npx skilldrop-cli install --pack ai-engineering --ide cursor
Start here: Find out whether a team is ready to adopt AI tools, and what blocks it first
Paste this into your agent:
Are we ready for AI? Our support team has 12 people on Zendesk, no AI tools today, and a legal team worried about customer data.
- How to tell it worked
- ai-readiness-assessment scores six dimensions (data, tooling, skills, governance, process, culture) with evidence for each, and ranks the gaps that block adoption first.
- If nothing happens
- If ai-readiness-assessment does not activate, ask for it by name and check that its folder exists in your skills folder (
~/.claude/skills/by default).
A typical session
When: A team wants to adopt AI tools and needs to know whether it is ready, where to start, what the rules are, and how to roll out.
You bring:
- the team or organisation in scope and what the answer will feed (a go/no-go, a budget, a sequence)
- evidence about current tools, data, policies and practices
- the candidate AI use cases
- any regulatory or contractual limits on data
-
- You
- Describe the team, its tools and data, and the concerns already raised.
- You get
- Scores from 0 to 4 on data, tooling, skills, governance, process and culture, each with an evidence line, the gaps ranked by what blocks first, and a one-sentence posture.
- You decide
- Decide whether to go ahead, and at what scope, from the stated posture.
-
- You
- List the candidate use cases.
- You get
- A ranked portfolio scored on value, feasibility and risk with the weights shown, one first slice with the observable that proves or kills it, and a not-yet list with promotion conditions.
- You decide
- Confirm the first slice.
-
- You
- Give the population, the tools and any data rules already in force.
- You get
- A policy at the length your audience needs: what's allowed first, every restriction paired with what to do instead or who decides, what to do if data has already gone in, and no claim about a tool, owner or law that you didn't give it.
-
- You
- Name the chosen tool or workflow and who it is for.
- You get
- A rollout in waves with enablement per cohort, named champions, a comms plan that says what will not change, and an adoption gate on every wave.
- You decide
- Each wave's gate must be met before the next cohort opens.
You end with: A readiness baseline, a chosen first use case, a usage policy, and a gated rollout plan.
Compare AI engineering with another pack
Skills in this pack (15)
- agent-adoption-stage Place an engineering team on the agentic-coding adoption ladder (0 gated → 4 intent-steered) using observables like agents-in-flight per engineer and who writes the code, name the one bottleneck gating the next step, prescribe the single next unlock, and state which current guardrail must change. Use when a leader asks "how far along are we with coding agents", "why has our AI adoption plateaued", or "what do we do next to get more out of this". Do NOT use to assess organisational preconditions like data, policy, and culture (that's ai-readiness-assessment) or to plan a tool's human rollout (that's ai-adoption-rollout). standard
- agent-budget Write the spend spec for an agentic workflow — per-stage model tiers, token caps with hard abort rules, a graceful-degradation order, and cost-per-outcome as the governing metric. Use when the user asks what an agent loop or multi-agent workflow should be allowed to spend, wants token/cost budgets and caps for AI automation, or got a surprise bill from an agent fleet. standard
- agent-config-review Review a coding agent's configuration for access broader than the work needs and give a verdict — SAFE AS CONFIGURED, TIGHTEN BEFORE USE or DO NOT USE — reading what actually wins across every scope (Claude Code user, project, local and managed settings; permission allow/deny/ask lists, defaultMode, sandbox, hooks, plugins, env; .mcp.json; subagent tool lists; Codex sandbox_mode and approval_policy and the profile in use; Cursor and Copilot agent settings), with each finding's file and line, what it lets happen in plain words, and the exact replacement config. Use when the user asks "is this Claude Code / Codex / Cursor setup safe", "review our .claude/settings.json", "audit our agent permissions", "is Bash(npm:*) OK in the allow list", "check this repo's agent config before we open it", or wants an agent's permissions tightened before use. standard
- agent-incident-response Plan the first hour after something went wrong with an AI coding agent or its tooling — a leaked or stolen API key, a destructive command (a dropped table, a force-push), a runaway bill, a malicious MCP server or skill, an agent prompt-injected into sending data out. It answers the person's actual question first, reads their logs for what they didn't mention, splits a bill from the usage export, gives the exact recovery for what was destroyed, revokes at the provider before cleanup when the evidence says the credential is in someone else's hands, and lays out the first 15 minutes, the next hour and who to tell. Use when the user says "I leaked my API key", "the agent committed a secret", "the agent deleted / force-pushed / dropped something", "is the table gone for good", "huge bill overnight", "we installed a malicious MCP server", "our agent platform was breached", or "what do I do now". standard
- agent-loop-design Design a supervised agent loop — the generate→verify→gate cycle, observable exit criteria, hard iteration cap, human gates at irreversible steps, and failure routes — as a loop spec a team can implement in any agent harness. Use when the user wants to automate a recurring task with an AI agent loop, design a work loop / review loop / research loop, or asks "how do I stop my agent from running forever or shipping junk". standard
- agent-threat-model Threat-model an AI agent deployment against the lethal trifecta — private data, untrusted content, and an exfiltration vector — producing a per-capability matrix, a named architectural fix for every unsafe path, and a pre-launch checklist. Use before shipping an agent, when reviewing MCP server or tool permissions, when the user asks about prompt injection or data exfiltration risk, or when deciding whether an agent's capability surface is safe to expose. heavy
- ai-adoption-rollout Plan the human rollout of an AI tool or workflow to an organisation — sized cohorts, enablement per cohort, named champions, a comms plan that states what will not change, and an adoption gate every wave must pass before the next one opens. Use when a tool has been chosen and the question is how it reaches people without stalling or backlash. Do NOT use to phase a technical cutover (that's migration-plan) or to choose which use case to roll out (that's ai-use-case-triage). standard
- ai-readiness-assessment 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). standard
- ai-usage-policy Draft an organisation's AI use policy or staff guidance from what it has told you about its people, tools, data and worries — every "don't" paired with what to do instead (or who decides, when no approved way exists yet), what to do if data has already gone into a tool, and no claim about a tool, licence, owner, regulation or commitment the input didn't give. Written in the length, labels and voice the audience needs. 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). standard
- ai-usage-report 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. standard
- ai-use-case-triage Turn a pile of candidate AI use cases into a ranked portfolio — each scored on value, feasibility, and risk with the weights shown, a recommended first slice that can prove or kill the thesis, and an explicit not-yet list with the condition that would promote each entry. Use when a team has more AI ideas than capacity and needs to choose, or asks "where should we actually start with AI". Do NOT use to assess whether the organisation is ready at all (that's ai-readiness-assessment) or to price a single decision (that's business-case). standard
- judge-audit Audit whether an LLM-as-judge, or a panel of judges, can be trusted for the decision its scores drive, before anyone acts on them — above all whether the judge errs differently on the variants being compared (prompt v1 vs v2, model A vs B, short vs long inputs), plus chance-corrected and weighted agreement with expert labels, precision and recall on a rare class, each run reported separately with the items that flipped, position and length bias, and confidence intervals, checked against the user's own gate or criterion and ending in a direct answer (ship or not, which judge to use). Use when the user asks "can we trust our LLM judge", "is our grader reliable enough to gate releases", "the grader says v2 is better, can we ship it", "which is the cheapest judge we can switch to", "our two judges agree 90%, is that good", "can we turn on auto-remove", "check our judge for position bias", or has a file of judge scores and wants to know whether to act on them. standard
- llm-eval-harness Design an evaluation harness for an LLM-powered feature — a versioned golden set (representative + adversarial + regression cases), the cheapest adequate grading method per case, a metric with a pre-set pass bar and regression gate, and a failure taxonomy that targets iteration. Use when the user is building or tuning an LLM feature (prompt, RAG, agent, classifier) and needs evals, a way to test prompt/model changes, or to stop shipping quality regressions on vibes. standard
- mcp-pairing Recommend which MCP servers to connect for a loop, workflow or task, stage by stage, with the narrowest access that works — what outside context or action each stage needs, the server that provides it (only ones the user named or the vendor officially publishes), the scopes to grant (read-only by default, never write on a review or gate stage), what it must not be able to do, the export-file fallback that keeps the stage running without it, and which stages need no server at all. Use when the user asks "which MCP servers should we hook up for this loop", "what should our agent connect to", "what token scopes does this stage need", "is this MCP setup too broad", or wants to wire GitHub, GitLab, Jira, Linear, Slack, Sentry, Grafana or a database into an agent workflow. standard
- subagent-design Decompose a task into an orchestrator and subagents — one-mission role cards with typed output contracts, a topology (pipeline / parallel / judge panel) chosen with a reason, context-isolation rationale, and a verification stage that is never a generator. Use when the user wants to fan work out across multiple agents, design a multi-agent workflow or orchestration, or asks "should this be one agent or several". standard
Included from core (5)
- brief-intake Turn raw mess — a Slack thread, meeting transcript, Jira ticket, half-written Notion page, email chain, or paragraph of free-form context — into a structured brief that the downstream skill (adr-generator, design-doc, runbook-generator, exec-summary, slide-outliner) can consume without further intake. Use whenever the user has unstructured source material and is about to invoke another skilldrop skill, or when a draft is missing the load-bearing context the next step will need. standard
- context-graph Map the decisions behind a codebase from its ADRs, RFCs and design records — each record's status and date, what supersedes or amends what, which records cite which, the files and folders each decision governs, and with git the commits that implemented it and the commits that changed each decision's code since it was made, and who made them — then answer "why is it like this?" from the record and check the record is still true. Finds supersessions only one side records, current decisions pointing at code that is gone, code that has drifted from its decision, two current decisions governing the same path, and references to records that don't exist. Use when the user asks "why do we use X", "which decisions govern this file or service", "is this ADR still current", "has the code drifted since we decided this", "are our ADRs out of date", "what was decided before I change this", wants a map of the architecture decisions, or is onboarding onto a codebase's history. standard
- council-review Convene a council of distinct senior-engineer personas (Architect, Security, Operator/SRE, Pragmatist, User-Advocate, plus optional bench seats) to deliberate a decision, design, or code change — each takes an independent stance, the genuine disagreements are surfaced as named cruxes, and a Chair issues a reconciled verdict that records dissents and states what would change the decision. The "Claude Council." Use when a choice has real tradeoffs and one reviewer's voice isn't enough: architecture decisions, risky changes before merge, RFC/design scrutiny, "should we adopt X?", rewrite-vs-refactor, or a pre-mortem. heavy
- doc-critique Review an existing document — ADR, design doc, runbook, exec summary, tech-comparison matrix, deck outline, decision log — and produce a structured critique against the same quality bars the skilldrop generators enforce. Categorizes findings by severity (blocker / major / minor / nit), points to the exact section/line, and suggests a concrete fix for each. Use when the user wants a second-pair-of-eyes review before sharing a doc, or has been handed someone else's artifact and wants to know what to push back on. heavy
- output-hygiene Review agent-written text before it ships and strip the machine artifacts it carries — invisible Unicode, non-breaking spaces, homoglyphs, harness-added provenance trailers, trailing chat closers — then flag the prose tells a script cannot catch, each quoted with a rewrite. Use when the user wants to clean up AI-generated output, asks to remove a Claude watermark, attribution footer, or "Generated with" line, wants a draft that does not read as machine-written, or needs a pre-ship hygiene pass on a document, commit message, or pasted chat answer. standard