AI engineering pack reference

Every skill in the AI engineering pack — what it makes, when to use it, what it needs, its quality bar, and what it hands off to.

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.

Skills

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.

Tier standard · v0.1.2 · SKILL.md · skill page

Use it 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).

A good result:

• Exactly one stage, cited to observables. No ranges, no "between 2 and 3" — and never a placement asserted from ambition or licence count.
• Placement is on the median engineer, with the distribution named when it's lopsided.
• Exactly one unlock. A list of ten is a backlog, and it guarantees none of them happens.
• The bottleneck is the one gating the next step, not a general complaint about AI.
• A guardrail to retire is named, not only one to add — stage-appropriateness cuts both ways.
• Every unlock routes to a concrete implementation, never to a product name.
• Vendor-neutral throughout. Capabilities, not SKUs; a skill that names this quarter's products is wrong by next quarter.
• The source framework is credited.

Not for:

• Assessing organisational preconditions — data, policy ownership, incentives — that's ai-readiness-assessment, a different axis (a team can be governance-ready and stuck at stage 1).
• Planning how a tool reaches people — cohorts, enablement, comms — that's ai-adoption-rollout.
• Choosing which use cases to build — that's ai-use-case-triage.
• Reporting measured usage from telemetry — that's ai-usage-report.
• Designing one specific loop or fleet — that's agent-loop-design / subagent-design, which this skill routes to.

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.

Tier standard · v0.1.1 · SKILL.md · skill page

Use it 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.

A good result:

• The outcome unit is named and every cost in the doc divides by it.
• Every stage has tier + rationale + three numbers (expected, cap, on-cap action). No stage rides free.
• Heavy tiers survive. No verification or judgment stage was downgraded to make the total look better.
• Caps are hard. Every on-cap action is abort or degrade — "warn and continue" appears nowhere.
• The run cap is less than the sum of stage caps, and the doc says why.
• Verification is last on the degradation ladder, explicitly.
• The comparison line exists — cost-per-outcome sits next to what the outcome costs without the agents.
• Estimates are tagged. [assumption] until measured; the calibration step is scheduled, not implied.

Not for:

• Infra/cloud cost modeling (compute, storage, egress) — capacity-cost-model
• Choosing a model tier for a single skilldrop skill — that's model-routing.json's table, already decided
• Designing the loop or the fan-out itself — agent-loop-design / subagent-design; this skill prices what they draw
• Negotiating provider contracts or rate limits — procurement, not a spec

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.

Tier standard · v0.1.1 · SKILL.md · skill page

Use it 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.

Needs: Python 3 for its scripts (standard library only).

A good result:

• The first line is the verdict and names the worst finding in plain words.
• The effective setting is reviewed, with the winning scope named; scopes not read are listed under "To confirm".
• Every finding has file:line, its effect in one sentence, and replacement config that can be pasted.
• Every wildcard allow entry is read as what it can run, and the deny list is tested against it.
• Every hook and command-running setting is quoted and judged; none is waved through as "tooling".
• Every literal secret says rotate, masked in the reply, never quoted whole.
• No invented facts: no package version, publisher, host, scope or script name the input didn't contain; replacement allow entries use only commands the input shows.
• No claim about what wasn't read: plugins, git history, user or managed scopes are "To confirm".

Hands off to: agent-threat-model when the configuration puts untrusted content, private data and a way to send data out in one session; mcp-pairing when the servers themselves are the wrong ones for the work, not just configured too widely; agent-incident-response when the review finds signs the exposure was already used: a token in a pushed or public repo, a hook or server that already ran downloaded code.

Not for:

• Choosing which MCP servers and token scopes a workflow should have — mcp-pairing
• Threat-modelling an agent's design for prompt injection and exfiltration paths — agent-threat-model
• Deciding what each subagent should be told and given in a new design — subagent-design
• Writing the organisation's rules for AI tools and data — ai-usage-policy
• A token already leaked or an agent already did damage — agent-incident-response; review the config after containment

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.

Tier standard · v0.2.0 · SKILL.md · skill page

Use it 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".

Needs: Python 3 for its scripts (standard library only).

A good result:

• The first line answers the question asked; the second names the kind of incident and its evidence.
• Every figure and time matches the files, sums computed, times in UTC as written.
• What the person didn't mention is found: the second table, caller or repo, the live process.
• Recovery is exact: SHAs, the restore point, the deadline, the caveats, an owner on each action.
• An exposed credential is revoked before cleanup, every one the thing held, with sharing services warned.
• Nothing invented: no environment facts, URLs, figures or attacker actions not in the files.

Hands off to: postmortem-generator when the credential is revoked, the agent is contained and the incident's 'is it over' test passes; incident-comms when customers or users may be affected and need an update.

Not for:

• Designing an agent's controls before anything has gone wrong — agent-threat-model
• Setting token, spend or loop limits ahead of time — agent-budget
• Reviewing an agent's settings, permissions or MCP config when nothing has gone wrong — agent-config-review
• Writing the customer status page or stakeholder update — incident-comms
• The blameless write-up once it's contained — postmortem-generator
• A standing procedure for credential rotation or on-call — runbook-generator

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.

Tier standard · v0.1.2 · SKILL.md · skill page

Use it 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".

A good result:

• The done-condition is observable — a person who didn't watch the run can check it in minutes.
• Verifier ≠ generator, structurally: different persona, prompt, or program — stated in the spec, not implied.
• Both caps are numbers. "Reasonable number of iterations" is not a cap; 3 is.
• Every irreversible action has a human gate, and every gate has a decision-shaped digest format.
• Generate consumes findings. The spec shows the findings flowing into the next round's input.
• All three failure routes are specified — cap-hit, can't-judge, systemic — each with a destination.
• The Mermaid renders and contains only generate/verify/gate states plus the human-gate and escalate exits — no "polish"/"reflect" states without a verdict.

Not for:

• Implementing one feature right now — run feature-implement-loop; it is the loop
• Splitting one task across parallel agents — subagent-design
• Deciding what the loop may spend — agent-budget
• One-off tasks — a loop for something that runs once is ceremony

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.

Tier heavy · v0.2.1 · SKILL.md · skill page

A good result:

• Every capability path is scored on all three legs. A row with a blank leg wasn't analyzed, it was skipped.
• No prompt-level mitigation is presented as a control. "The system prompt instructs the model to ignore injected instructions" mitigates nothing — it is precisely what the attack defeats. It may appear as defense in depth, never as the broken leg.
• No classifier is a broken leg either. Injection detectors raise cost for the attacker; they do not remove a leg. Architecture beats instructions.
• Egress is enumerated past the network tool. A model that lists only http_request failed the sweep — rendered markdown, error text, logs, and file writes are all channels.
• Every 🟥 is broken or signed off by a named role with a revisit trigger. No silent acceptance.
• Every fix has a verification step a reviewer can actually run — a config assertion, a test, an observed denial.
• Every 🟥 and 🟧 carries its OWASP IDs, taken from the mapping table, not guessed from a risk's title.
• "Read-only" is never a safety claim. Reading is how data reaches the attacker; the question is only where it goes next.

Not for:

• STRIDE on the surrounding system's architecture — that's threat-model
• Reviewing written code for vulnerabilities — that's devils-advocate or sonar-review
• Runaway loops, token burn, or infinite retries — that's agent-budget (a cost incident, not a security one)
• Output quality, hallucination, or eval design — that's llm-eval-harness
• After a confirmed leak — that's postmortem-generator

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.

Tier standard · v0.1.0 · SKILL.md · skill page

Use it 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).

A good result:

• Cohorts get smaller-to-larger with a stated reason each, and the plan refuses a single big-bang wave.
• Every wave has an adoption gate with an observable, a threshold, and a bake time — plus a rollback if it fails.
• The outcome is a behaviour, not a usage number. Licences activated is not adoption.
• The comms plan states explicitly what will not change (headcount, evaluation, how work is judged). Omitting it is a defect, not a tone choice.
• Champions are roles with protected hours, never names, and never unbudgeted.
• Enablement is per cohort and hands-on with the participant's own work — a single deck for everyone is the failure mode.
• The friction loop names an owner and a cadence.

Not for:

• Phasing a technical cutover (schema, API version, datastore) — that's migration-plan, which sequences systems, not people.
• Choosing which use case to roll out — that's ai-use-case-triage.
• Deciding whether the organisation is ready at all — that's ai-readiness-assessment.
• Writing the rules for what may be put into the tool — that's ai-usage-policy.
• Reporting on adoption that already happened — that's ai-usage-report.

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.

Tier standard · v0.1.3 · SKILL.md · skill page

Use it 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).

A good result:

• Every score carries an evidence line. A number with nothing behind it is the failure mode this skill exists to prevent — cut it or mark it [insufficient evidence].
• All six dimensions appear, including the ones the input is thin on. Silence on a dimension reads as a pass, and that's how readiness reports mislead.
• Gaps are ranked by blocking order, not by score. The lowest number is not automatically the first problem, and the plan must say why.
• Every gap has a first action and an owner role — a role, never a person's name, so the assessment doesn't go stale when someone changes teams.
• The posture sentence takes a position and names the condition that would change it. "It depends" is a refusal to do the job.
• No invented facts. Where the input is silent, say so; a fabricated observation is worse than an admitted gap.

Not for:

• Choosing which workflows to automate — that's ai-use-case-triage.
• Planning the rollout once you've decided to go — that's ai-adoption-rollout.
• Writing the rules for what people may put into a tool — that's ai-usage-policy.
• A market or competitive question ("should we enter this space?") — that's strategy-analysis.
• Measuring adoption that has already happened — that's ai-usage-report.
• Assessing how far an engineering team's agent practice has actually got — agents in flight, who writes the code, what still gets reviewed — that's agent-adoption-stage. It's the orthogonal axis: this skill scores whether the organisation can adopt at all; that one scores how far the practice has got. A team can be governance-ready and stuck at stage 1, or running ten agents with no policy at all — run both when the answers disagree.

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.

Tier standard · v0.2.0 · SKILL.md · skill page

Use it 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).

A good result:

• Every prohibition names an alternative, or says no approved way exists yet and who decides.
• There is a line on what to do if it has already happened.
• Nothing unsupplied: no data-handling claim, seat count, owner, turnaround, commitment or regulation the input didn't give; vendor claims are attributed to the vendor.
• The tool list is checked against the input and mismatches are named.
• The length, voice and labels fit the audience asked for.
• No notes, tags or questions to the requester inside the policy.

Not for:

• 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.
• Assessing whether governance is mature enough yet — that's ai-readiness-assessment.
• A security review of a design — that's threat-model.

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.

Tier standard · v0.1.2 · SKILL.md · skill page

Use it 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.

Needs: Python 3 for its scripts (standard library only).

A good result:

• 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.

Not for:

• 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.

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.

Tier standard · v0.1.0 · SKILL.md · skill page

Use it 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).

A good result:

• The weights are shown and justified in one line. A ranking with hidden weights is an opinion wearing a table.
• Every score has a one-line reason. A bare 4 is not a judgement anyone can challenge.
• The not-yet list is non-empty, and every entry carries a promotion condition. If nothing was rejected, the triage didn't happen.
• Each candidate names a workflow and a person, not a technology.
• The first slice has a kill condition with an observable and a time box.
• Unknown numbers are marked directional, never invented — a fabricated ROI figure poisons every decision downstream.

Not for:

• Assessing whether the organisation can adopt anything yet — that's ai-readiness-assessment.
• Pricing one option properly (build vs buy, Option 0, cost layers) — that's business-case.
• Planning the human rollout of a chosen use case — that's ai-adoption-rollout.
• Writing requirements for the thing you picked — that's prd-draft.

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).

Tier standard · v0.3.1 · SKILL.md · skill page

Use it 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.

Needs: Python 3 for its scripts (standard library only).

A good result:

• The first line answers the question asked: ship or not, which judge, which arm it favours.
• The criterion is the user's; with none, no invented pass mark decides anything.
• Statistics are stratified by the compared variable before any pooled figure is quoted.
• Ordinal scores get weighted kappa, named as quadratic or linear.
• A rare class gets its count, confusion, recall and precision with intervals, not accuracy.
• Each run is reported on its own, with the flips, joined on item id.
• Every number matches the output for the subset and run it is labelled with, n included.
• What the data cannot measure is named, never estimated.

Hands off to: llm-eval-harness when the verdict is DO NOT RELY ON IT and the judge, its rubric or its labelled set has to be rebuilt.

Not for:

• Designing the eval set, grading methods and pass bar for an LLM feature — llm-eval-harness
• Generating eval cases for a skill's evals/ folder — eval-harness-generator
• Measuring how much teams use AI tools — ai-usage-report
• Inter-rater reliability for humans only, with no model in the loop — the statistics transfer, but the bias checks here assume a model

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.

Tier standard · v0.1.2 · SKILL.md · skill page

Use it 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.

A good result:

• Golden cases are real and labeled, sourced honestly. Count per bucket stated; synthetic-input + model-graded sets are flagged as the weak evidence they are.
• Each case names its grading method, and the cheapest adequate one was chosen. LLM-judge is the exception that justifies itself, not the default.
• The metric and both gates (no-regression + critical-subset-100%) are set before the first run. Post-hoc bars don't count.
• LLM-judges are validated against human labels and bias-controlled. An unvalidated judge score is presented as such.
• A held-out split exists and the no-tuning-on-test rule is stated. Reporting the number you optimized against is the cardinal eval sin.
• Cost and latency are tracked beside quality, so quality gains that blow the budget are visible.

Not for:

• Tabulating AI usage/adoption telemetry — that's ai-usage-report
• Product-outcome metrics for a feature (adoption, handle time) — that's success-metrics
• Picking which model/vendor to buy on price, terms or support — this measures quality on your task, which is one input to that decision
• The provider-specific API mechanics (token counting, streaming, tool-call format) — consult the provider's own reference; this skill is the eval methodology

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.

Tier standard · v0.1.0 · SKILL.md · skill page

Use it 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.

A good result:

• Every stage has a row, including the ones that get None. A plan that lists only servers hides which stages hold nothing.
• No verify or gate stage holds a write scope. Not comment, not approve, not label.
• Every write grant names the stage whose output it is and sits on its own credential.
• No invented names. Every server, package, URL and scope in the plan came from the user or is a vendor's own server with the confirm step written beside it.
• Every grant is narrower than "read-only": a scope, a project or repository, a role.
• Every stage that reads untrusted content is checked against write, exec and network tools in the same session, and the combination is split or dropped.
• Every stage has an export-file fallback a person can produce today.
• At least one server is argued against or the plan says why each one earns its place.
• No token value appears anywhere, and the config placement keeps tokens out of git.

Hands off to: agent-threat-model when the pairing still puts private data, untrusted content and any way to send data out in one session, or before the setup is connected at work.

Not for:

• Threat-modelling a finished agent's tools and data for exfiltration paths — agent-threat-model
• Designing the loop itself: stages, exit criteria, caps, human gates — agent-loop-design
• Deciding how to split work across subagents and what each one is told — subagent-design
• Writing the organization's rules for which AI tools and data are allowed — ai-usage-policy
• Setting up one tracker step by step (Jira, Linear, GitHub Projects) — that is the per-tracker integration guide in the skilldrop docs, not a plan

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.

Tier standard · v0.1.3 · SKILL.md · skill page

Use it 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".

A good result:

• The fan-out is justified by one of the three reasons, by name — or the plan says "one agent" and means it.
• Every mission is one sentence with no "and". Two jobs, two cards.
• Every output contract is typed. A reader could write the JSON schema from the card.
• Isolation lines are explicit — each card says what the agent is denied and why.
• The topology has its reason attached, and any barrier names the cross-item dependency that earns it.
• Verification is adversarial and separate — never the generator, never "the orchestrator double-checks".
• The budget line exists — per-agent tier + fleet cap, sourced or tagged.

Not for:

• Designing the loop that wraps the fan-out (caps, gates, exits) — agent-loop-design
• Setting the spend policy — agent-budget
• Running a multi-perspective review right now — council-review is the panel, ready-made
• Implementing one story — feature-implement-loop

Included from core

Installed with this pack. Details: Core pack reference.

• 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.
• 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.
• 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."
• 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.
• 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.

Edit this page on GitHub · View source