Core pack reference

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

The cross-role toolkit every pack builds on: structured intake, document critique, the review council, output hygiene, and the decision graph behind a codebase, plus the ship-a-draft wrapper. Installed automatically with every role pack.

Skills

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.

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

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

A good result:

• Quote, don't paraphrase, when extracting. When a field is [explicit] or [implied], include a 5–15 word verbatim snippet from the source so the downstream skill (and the user) can verify nothing was hallucinated.
• Convert relative dates to absolute dates. "Next Friday", "EOQ", "the sprint after this one" all become YYYY-MM-DD with (implied) if you had to compute it. Today's date is in the system context — use it.
• Don't invent people. If the source says "someone from platform should…", the owner is unowned, not a guess.
• Don't merge across sources unless the user asked. If the user pastes a Slack thread and a doc, ask whether you should treat them as one brief or extract separately.
• Strip noise aggressively. Greetings, off-topic banter, "lol", and emoji reactions get dropped. The brief is the signal, not the conversation.

Not for:

• When the user has already given a clean, structured brief — go straight to the downstream skill.
• For pure summarization — that's not what this is. The output is shaped for a specific next step, not a generic summary.
• For raw transcript cleanup. If the user wants meeting notes cleaned up, use decision-log.

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.

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

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

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

A good result:

• The answer names the governing record by id, status and date, and the rationale is quoted or closely paraphrased from that record. No reason is supplied that the record doesn't give.
• A superseded record is never presented as current, including one whose own Status line wasn't updated.
• "No recorded decision" is said when it's true, and any reading of the code is labelled as inferred.
• Every problem names its record id and the exact fix. Problems come before warnings.
• Two current records on the same path are raised as a possible conflict, not silently resolved by date.
• The deciding record is checked against the code it governs, claim by claim, with the line quoted, and drift is reported with both sides. A line number is given only when read from the file.
• Every script finding in the reply has been confirmed by reading; one that doesn't hold is dropped.
• A removal or change question lists every use of the thing in the code, recorded or not.
• Related records are read before they're called unrelated: amendments, and rules for the same concern elsewhere in the codebase.
• A moved path is reported as moved, with its new location; only a path with no successor is "gone".
• Drift is a requirement the code no longer meets, with the record's words, the line, and the commit when the history shows one. A count of commits is a reason to look, never a finding by itself.
• A mid-rollout pair of records is a missing cross-reference, not a contradiction.
• The reply fits the size asked for (a stated limit is obeyed exactly), and never mentions a script, a graph or a tool.
• Statuses, links and governed paths come from the script's output, or are marked as read by hand when it couldn't run.
• No invented records, ids, dates, paths or commits.

Hands off to: adr-generator when a decision is live but unrecorded, or a record needs superseding, deprecating or correcting.

Not for:

• Writing a new ADR or fixing one: use adr-generator
• How the code works now, with no decision history: use codebase-tour
• Recovering the architecture from code with no records: use reverse-architecture
• A record of business or product decisions for stakeholders: use decision-log

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

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

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

A good result:

• Real disagreement, or honest consensus — never theater. Manufactured conflict between personas is the cardinal sin. If they agree, say "unanimous" and give the one reason; spend the words on the cruxes that are real.
• Every seat point is concrete and attached to evidence. file:line for code, the named assumption for a decision. ❌ "Security has concerns." ✅ "Security 🔴: exec(\tar ${path}\) at jobs/export.ts:28 — path is user-controlled; command injection."
• Stances are explicit and scannable. The reader sees the split (🟢/🟡/🔴/⚪) at a glance, before reading a word of argument.
• Seats stay in their lane. The Pragmatist doesn't relitigate the threat model; Security doesn't lecture on naming. Overlap means the roster is wrong — cut or merge.
• The Chair decides, doesn't average. ❌ "There are good points on both sides." ✅ "PROCEED WITH CONDITIONS — we accept the added operational load (Operator's dissent noted) because the security gain is load-bearing; revisit if on-call pages exceed X."
• Dissent is preserved. The minority seat's strongest point survives into the verdict. A council that erases dissent is just one opinion wearing five hats.
• Falsifiable verdict. "What would change our mind" is mandatory — it turns a verdict into a decision the team can revisit when facts change.

Not for:

• A trivial or one-line change — convening five voices is noise. Use devils-advocate or just review it.
• A single-lens task. Pure code review → devils-advocate. Pure doc review → doc-critique.
• When you need one expert answer fast, not a deliberation. The council is for when the disagreement is the point.
• Greenfield spike/throwaway code — deliberation wastes effort on what won't survive.
• As a rubber stamp to manufacture consensus for a decision already made. If the call is final, don't stage a fake trial.

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.

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

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

A good result:

• Severity is calibrated. If your output has more blockers than major issues, you're inflating. Reread and demote.
• Findings are local, not global. "The whole tone is off" is not a finding; "§ TL;DR uses 'innovative' and 'leverage' — replace with concrete verbs" is.
• Fixes are paste-able where possible. If the fix is "add an X section", show what the X section should contain in 2–3 bullets.
• Don't review the topic, review the doc. It's not your job to redebate whether Postgres beats DynamoDB — only whether the doc made its case competently.
• Quote the doc, don't paraphrase. Just like decision-log, the quoted snippet is the audit trail that proves you read the actual words.

Not for:

• For evaluating the underlying decision (is Postgres the right choice?). That's a tech debate, not a doc review — argue the decision itself, or put it to council-review.
• For grammar / spelling pass on a doc that's otherwise solid. Use a normal editor.
• For evaluating code. This skill reviews documents; for code review, the user has other tools.
• For generating the doc. If the user wants a draft, that's the matching generator skill.

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.

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

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

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

A good result:

• Every mechanical finding names a codepoint or quotes the matched line. "Contains invisible characters" is unverifiable; 3:18 U+00A0 NO-BREAK SPACE is checkable in one keystroke.
• Every prose finding quotes the span it is judging. The quote is the evidence. A finding that paraphrases is an opinion.
• The auto and review tiers stay separate in the report. Merging them means the user approves a homoglyph guess while approving a zero-width-space deletion.
• The medium is stated before the first finding. Half the classes are medium-dependent; a report that skips it is asserting a default it never disclosed.
• Rewrites are paste-able. "Tighten this" is not a rewrite. The replacement sentence is.
• The report says what it left alone. Including the provenance trailer when disclosure is owed, and why.

Hands off to: doc-critique when the surface is clean and the draft is still weak.

Not for:

• The document's argument, structure, or evidence is the problem — that is doc-critique.
• The goal is to pass work off as unassisted where a policy requires disclosure. The skill stops on the provenance class and names the policy.
• The text is source code. Invisible-character scanning is worth running, but prose tells do not apply and the rewrite advice will be wrong.
• The user wants the text shortened or re-pitched for a different audience. That is a rewrite, not a hygiene pass.

Loops

ship-a-draft

Take raw mess to a stakeholder-ready artifact by wrapping any skilldrop generator in the two passes either side of it — structured intake before, critique and machine-residue scrub after.

Cap: 3 returns before BLOCKED. LOOP.md

Edit this page on GitHub · View source