write-skill

agent-labs

Skills and agents for Claude Code.

Skills

• write-skill: draft a new skill, or rewrite an existing one, short and built on leading words. Method adapted from Matt Pocock's skills.
• factory-brainstorm: brainstorm an idea until it's concrete, inside the current project's limits or outside them: rounds of up to 3 questions with recommended answers, then one builder check that ends it, with a trace of every question and answer. Adapted from obra's superpowers brainstorming and Matt Pocock's grilling.
• factory-plan: Plan phase. Brainstorm a bug, idea or request into an intent in your words, proposed as intent/<id>-<slug>.md in a pull request (merge = go, close = no) and tracked in any tracker (GitHub, Linear, Plane, files). Follows the Plan phase of Anthropic's AI-native SDLC playbook.
• factory-design: Design phase. Turn an intent into a spec, what to build and how, in one unattended session: criteria, approach, build order and frames, reviewed while it's written by specialized agents (security by OWASP, risk by EBIOS RM and ISO 27005, privacy by GDPR, and each of your rules/), then one pull request: owners answer their questions in its review, and merging it is your approval. Unattended, so a CI job can start it when an intent's pull request is merged: claude -p "/factory-design <id>". Follows the Design phase of Anthropic's AI-native SDLC playbook.
• factory-build: Build phase. Turn an approved spec into code in two halves: a plan (plan.md: files, order, risks, the test that proves each criterion), drafted without touching the code and accepted by you (and your tech lead for a riskier change), then the code and its tests in one pass on a branch, done only when build, tests and lint pass and a verifier agent, in a fresh context, has run the app against the spec, with a draft pull request. Departures from the plan update it in the same commit. Follows the Build phase of Anthropic's AI-native SDLC playbook.
• grill-me-live: get grilled on an idea while its decision tree grows live in your browser: answer on the page or in chat, and dropped branches fade with everything under them. At the end: a receipt of every decision and a slide deck for the people who were not in the room. Runs a small local server (Node). Interview method from Matt Pocock's grilling.
• sail-fill-campaign: fill a SailPoint Identity Security Cloud certification campaign (manager, source owner, search, role composition): deduces the type from what you want to certify, follows your project's written rules and your tenant's existing campaigns, shows every field with where its value comes from, then hands you the sail commands to run yourself, or the filled form for the UI.
• grc-router: not sure which GRC skill you need? Ask in your own words: it reads grc/, sends the request to the skill that owns it, chains several in the right order (gaps, risks, register, attack chains, committee, policies), and tells you the next step. No grilling.
• grc-grill: get grilled on a governance, risk or compliance decision, one question at a time, each with a recommended answer cited to a clause (ISO 27001, NIS2, DORA, GDPR), within a question budget (hard 10, light 5, none), then pick the output format. Reads grc/ first so it never asks what your documents answer, and keeps a trace of who decided what for your auditors. Called by the GRC skills. Method from Matt Pocock's grilling.
• risk-assessment: assess a security risk as an EBIOS RM scenario, score it before and after treatment (ISO 27005), map its controls to ISO 27001, NIS2, DORA and GDPR, and record it in grc/risk-register.md, with the report in md, html, pdf, pptx, xlsx, csv, json or a Jira issue.
• risk-register: keep grc/risk-register.md as the one list of your risks: view and filter it, flag what is overdue, stale or above your risk appetite, update status, owner, due dates and controls, import from a spreadsheet or Jira, and export it with a portfolio heat map. No grilling; new scores go back to risk-assessment.
• committee-report: turn the risk register into a report for a committee or board: posture in one sentence, a heat map of what moved since last time, risks above appetite, fix progress and numbered decisions, as a 7-slide deck by default. After the meeting, records what was decided and updates the register.
• gap-analysis: check where you stand against ISO 27001 and any framework mapped to it (NIS2, DORA, GDPR, SOC 2, PCI DSS...), line by line from the fixed files in frameworks/ so no requirement is skipped: each one met, partial, missing, n/a or unknown with its evidence from grc/, then a ranked plan where one fix closes every clause it maps to (legal deadlines first). Shows coverage bars and an Annex A map; xlsx by default, usable as a statement of applicability.
• policy-writer: write or review a security policy in plain words, each rule traced to an ISO 27001 control, the NIS2, DORA or GDPR clauses in scope, and the register risks it reduces, after a hard grill on scope, owner, approver and the rules that are yours to decide. Shows a coverage map of duties met, gaps and conflicts, keeps grc/policies/index.md with review dates, and records the approval. Word document by default.
• attack-chain: chain risks from the register into one bigger attack, where what the attacker holds after one risk is the way in to the next. Scored by its hardest step and its final impact, so three medium risks can add up to one high; names the one fix that breaks the whole chain and draws it for managers. risk-assessment looks for new chains after every risk.
• vendor-risk: assess a supplier or SaaS before signing or at renewal: tier it by how much you depend on it, check its certificates, questionnaire, contract and DPA against what that tier requires, score it as one risk and give a verdict (approve, approve with conditions, reject) with owned, dated conditions. Keeps the vendor list in grc/vendors/ (DORA register of information fields included) and sends high-risk vendors to the risk register.
• raci-builder: build a RACI matrix (who does, signs off, is asked, is told) for a security process or the whole programme, each activity tied to an ISO 27001, NIS2, DORA or GDPR duty, after a hard grill on who answers for what. Then checks it for missing or double sign-off, conflicts of interest, empty seats, missing deputies and accountability handed to a supplier. Excel by default.
• audit-evidence: keep grc/evidence/ audit-ready: file each piece of evidence against the ISO 27001 controls it proves, with its hash and expiry date, see which controls are evidenced, stale or missing for ISO 27001, NIS2, DORA or GDPR, catch controls the register calls in place with nothing to prove it, send precise re