canonical

Evaluates documentation against the team's brand guidelines. Use when reviewing docs for tone, terminology, sentence structure, and phrasing consistency.

Evaluates whether documentation sections have substantive content. Use when checking whether planned sections are complete, thin, placeholders, or missing.

Evaluates grammar, spelling, and formatting in design systems' documentation. Use when checking mechanics like spelling, punctuation, heading hierarchy, and list formatting.

Explore Canonical's Vanilla Framework design system documentation. Covers 49 UI constructs and 26 concepts including their properties, anatomy, usage guidelines, and relationships. Use when answering questions about Vanilla constructs, concepts, design patterns, or implementation details.

Pulls design context from Figma via the Figma desktop MCP server during documentation workflows. Use when a user provides a Figma URL, selects a node in the Figma desktop app, or references existing designs during discovery, drafting, or review.

Scores and evaluates documentation readability using Flesch-Kincaid metrics and qualitative analysis. Use when reviewing docs for sentence length, passive voice, jargon, and reading level.

Evaluates documentation against the team's brand guidelines. Use when reviewing docs for tone, terminology, sentence structure, and phrasing consistency.

Evaluates whether documentation sections have substantive content. Use when checking whether planned sections are complete, thin, placeholders, or missing.

Canonical Go coding standards and best practices. Use when writing, reviewing, or refactoring Go code. Covers formatting, naming, errors, functions, structs, interfaces, and testing conventions.

Canonical code review guidelines. Use when reviewing code, preparing PRs for review, or giving feedback on changesets. Covers tone, procedures, code quality, changeset scope, and review process.

Security code review for vulnerabilities. Use when asked to "security review", "find vulnerabilities", "check for security issues", "audit security", "OWASP review", or review code for injection, XSS, authentication, authorization, cryptography issues. Provides systematic review with confidence-based reporting.

Iterate on a PR until CI passes. Use when you need to fix CI failures, address review feedback, or continuously push fixes until all checks are green. Automates the feedback-fix-push-wait cycle.

Scan an agent skill for security and quality issues. Use when asked to "scan a skill", "audit a skill", "review skill security", "check a skill for prompt injection", "validate SKILL.md", or assess whether a skill is safe to install. Checks for prompt injection, scope bloat, description drift, malicious scripts, secret exposure, excessive permissions, and supply-chain risk.

Author, structure, and validate an agent skill. Use when creating a new SKILL.md, substantially rewriting an existing one, deciding what to bundle as scripts vs references, or importing an external skill. Covers frontmatter, body structure, depth gates (when to split a skill), the script-vs-checklist decision, prompt-injection hygiene, validation, and testing.

Canonical CLI design standards. Use when designing, implementing, or reviewing command-line interfaces. Covers grammar, commands, flags, parameters, feedback, colours, tables, verbosity, and tone of voice.

GitHub Actions security review for workflow exploitation vulnerabilities. Use when asked to "review GitHub Actions", "audit workflows", "check CI security", "GHA security", "workflow security review", or review .github/workflows/ for pwn requests, expression injection, credential theft, and supply chain attacks. Exploitation-focused with concrete PoC scenarios.

Creates well-formed Jira issues in the LNDENG project (warthogs.atlassian.net) — stories, epics, objectives, tasks, spikes, bugs, and more — with correct field mappings, sprint assignment, and acceptance criteria.

Builds and parses structured retrospective artifact folders for troubleshooting, incident review, and delivery retros. Use this skill when capturing session context, synthesizing external context (GitHub, Jira, Mattermost, logs), querying prior retrospectives, or preparing downstream inputs for OKB entries, postmortems, and agent/skills/instruction improvements.

Migrates legacy ops.testing Harness suites to state-transition tests by enumerating Harness usages, defining explicit State objects, and recreating assertions per Juju event so charms stay compatible with modern ops releases.

Generates Custom Agent files (.github/agents/*.agent.md) with persona-based configurations, specialized tool sets, and role-specific cognitive architectures. Use when the user requests a specialized role or perspective (Security Auditor, Documentation Writer, Release Engineer, etc.). Creates agents with defined identity, constrained tools, and thinking processes aligned to their role. Not for general capabilities—use generate-agent-skills for those.

Architects, generates, and validates Agent Skills. Enforces specification and best practices. Used any time an agent skill must be created or updated.

Generates path-specific instruction files (.github/instructions/*.md) with JIT loading via applyTo glob patterns. Performs LLM-driven repository analysis to discover file patterns and extract scope-specific rules. Use when the user requests scoped, framework-specific, or directory-specific rules for testing, components, docs, config files, or language-specific files to prevent context pollution. Works for code, documentation, configuration, and data files.

Generates reusable Prompt Template files (.github/prompts/*.prompt.md) with variable substitution for ad-hoc, high-frequency tasks. Use when the user needs quick, repeatable prompts for common operations (explain code, fix bug, add tests, refactor, document). Creates templates with handlebars variables, optimized context structure, and strict output constraints. Not for complex workflows (use skills) or persistent roles (use agents).

Generates the global repository constitution file (.github/copilot-instructions.md). Works for code repositories, documentation repositories, data repositories, and mixed repos. Performs LLM-driven deep repository analysis including docs, code patterns, build systems, documentation generators, and data schemas. Generates constitutional rules following context economics (under 1000 lines). Enforces positive constraints and no hardcoded secrets.

Audits an existing Squeeze Loop (SL) for soundness — checking whether a target loop is truly compliant (pairwise-disjoint authority pairs, physically barriered contexts, gate-defined "done", a genuine executable lower bound, and demonstrated catching of coherent-and-wrong) or is quietly collapsing into a rubber stamp. It applies the squeeze's own discipline to the loop under audit: it maps the actual (upper, lower) authority pairs and hunts for an actor certifying its own work; probes whether each context barrier is physical or merely honorary; confirms an executable oracle disjoint from the actor it judges; checks Gate A / Gate B / Gate C are present and load-bearing; seeds coherent-and-wrong artifacts to calibrate the monitors (flag rate not zero, not saturated); audits the loop's accumulated learned skills VIA the sl-monitoring-sl pattern; checks each known collapse mode is blocked by a stabilizer; and routes whatever an internal audit cannot self-certify to a disjoint base (external / cross-provider / hum

The Squeeze Loop instance for Use Case B — an autonomous customer-refund bot that commits a terminal action (REIMBURSE | DENY | ESCALATE) and must resist multi-turn social engineering, on terrain B (authored authority). No external spec exists; the refund policy POL_REFUND_042 is authored upstream from an incident archive by an author who never sees the bot, and author independence is the whole soundness argument. Use when working on src/B — the refund policy, the headless REST app where only POST /action commits a verdict, the customer-history DB, the adjudicated-case archive, the adversarial scenario matrix, or the coherent-and-wrong "handles nominal distress but caves to legal coercion / duplicate-refund manipulation". Trigger phrasings: "use case B", "instance B", "refund bot squeeze", "authored policy / no external spec", "social-engineering resistance", "POST /action commits, chat never commits", "duplicate-refund / legal-coercion adversarial".

The Squeeze Loop instance for Use Case C — an HTTP API where the document plane (OpenAPI contract) and the runtime plane (live server) are forced into exact lockstep, on terrain C (split planes). The dominant failure is blending — a clean schema masking broken runtime behaviour (id leaks, tracebacks, missing auth), or a clean runtime escaping stale documentation. The exerciser RUNS the live server over HTTP but is physically denied the server source and the published schema (the load-bearing "run, don't read" channel). Use when working on src/C — the API governance policy, the canonical OpenAPI contract, the schema linter, the live server, the conformance test matrix, the legacy route-signature regression oracle, or the no-blend cross-check. Trigger phrasings: "use case C", "instance C", "split planes", "document vs runtime plane", "no-blend", "run don't read", "OpenAPI conformance squeeze", "id leak / missing auth on an untested route".

The Squeeze Loop instance for Use Case D — formally verified Rocq (Coq) proofs of textbook arithmetic (e.g. commutativity of + on nat), on terrain A with a deductive lower bound (the Rocq kernel). The dominant failure is the prover discharging (Qed.) an adjacent weaker claim under the intended theorem name (e.g. right-identity n+0=n instead of n+m=m+n), or smuggling an axiom. The kernel (coqc) plus the axiom auditor (rocqchk --print-assumptions) is the immutable lower bound none of the actors can alter, and the exerciser authors false-theorem mutations the kernel must reject. Use when working on src/D — the textbook manifest, the formal theorem statement, the tactical proof, the false-theorem mutation matrix, the pinned Rocq stdlib, the prior-proofs regression registry, or the axiom audit. Trigger phrasings: "use case D", "instance D", "Rocq/Coq proof squeeze", "adjacent weaker theorem", "smuggled axiom / Admitted", "mutation must fail to compile", "Closed under the global context".

Interview a human who wants to build a Squeeze Loop (SL) for their problem, then draft a concrete, structured plan. Elicits the deliverable, the upper bound (soft normative authority — spec/standard/policy/contracts), the lower bound (executable oracle — prover/checker/tests/runtime/reference impl), the actors and their disjoint (U,L) pairs, the context barriers, the gates (A editorial / B machine / C coverage-no-blend), the coherent-and-wrong failure to guard, and the stabilizers/collapse modes to pre-empt — then turns the answers into a roles+bounds+barriers+gates+loop-steps plan. Use when the user says any of: "draft a plan to generate a squeeze loop", "draft an SL validation plan", "build an SL strategy for X", "design a squeeze loop for my problem", "help me set up a squeeze loop", "SL validation plan for C code with Frama-C", "an SL that monitors another SL", "nested squeeze loop / monitor of a monitor". Action-oriented: figure out what is known, ASK the missing interview questions, then OUTPUT a plan i

Specifies how one squeeze loop monitors another squeeze loop — squeezing the monitored loop's soft outputs (especially its accumulated skills / learned heuristics) against that loop's own upper and lower bounds, from an independent evidence base; it classifies a skill by kind (ignore-signal vs defer-to-oracle), runs the matching consistency check, and repairs by carving over-generalized skills with bound-deferring exceptions or pruning spurious ones. Use when a loop accumulates or consolidates skills that may over-reach; when you need a meta-loop or monitor that audits a base loop's learned rules for contradictions with its spec; when a learned heuristic seems to conflict with the governing policy; or when reasoning about the "disjointness principle applied to skills." Trigger phrasings include "a loop monitoring a loop", "monitor the squeeze loop", "check a skill against the upper bound", "the skill contradicts the spec", "carve out an exception", "prune a spurious skill", "who audits the learned skill", "sk

Polishes an existing SKILL.md file so it triggers reliably, scans well, and preserves every technical claim verbatim from the original; when a deep polish is warranted, it also splits cleanly into a SKILL.md plus reference files. Use whenever the user says "polish this skill", "clean up my skill", "make this skill better", "this SKILL.md is too long", uploads a `SKILL.md` file for polish, or asks for help reorganizing skill content under a `references/` folder. Also use when the user wants their skill checked for the common authoring failure modes: undertriggering descriptions, mis-numbered headings, mis-indented bullets, forward references, dead file paths, mixed cautionary-vs-canonical examples, run-on prose bullets, or a single `SKILL.md` past ~500 lines that should be broken up.

A general-purpose academic-paper-writing companion that encodes hard-won lessons (many from reviewer feedback) for writing a clear, honest, and defensible paper. Covers saying each idea once, resolving forward references, connective tissue, avoiding overclaim, citing responsibly, tightening the abstract, keeping front matter in sync with the body, cross-section consistency, bounding speculative material, quantifying honestly, figures, length discipline, and independent editorial review. Use whenever the user says "help me write a paper", "review my paper draft for clarity", "is my abstract overclaiming", "academic writing help", "polish my manuscript", "did I make a forward reference", "say it once", "check my paper for consistency", "read the full paper for consistency", "make sure each term is defined / introduced before use", "run a summary-vs-body faithfulness sweep", "make this qualifier/term consistent everywhere", "is this claim defensible", "how should I cite this", "did I leave stale future-work lang

Validates documentation builds successfully. Use when checking Sphinx/RTD build integrity or diagnosing build failures. Reports errors, warnings, and build configuration issues.

Analyzes documentation against Diataxis framework (Tutorial, How-to, Reference, Explanation). Use when reviewing documentation structure or classifying content type. Identifies misalignments between declared category and actual content.

Performs comprehensive documentation review including build validation, Diataxis analysis, structure audit, accuracy verification, and style compliance. Use when reviewing documentation changes or auditing documentation quality.

Validates documentation structural integrity including heading hierarchy, metadata, file naming, navigation, and cross-references. Use when checking documentation organization or validating toctree structure.

Enforces project documentation style guide compliance for tone, voice, terminology, punctuation, and formatting. Use when checking documentation style or validating MyST/reST syntax. Cites specific style guide violations.

Verifies documentation accuracy by cross-referencing claims, CLI commands, API signatures, and configuration against source code. Use when validating documentation correctness or checking code-docs consistency. Flags unsupported or outdated claims.

Validates documentation builds successfully. Use when checking Sphinx/RTD build integrity or diagnosing build failures. Reports errors, warnings, and build configuration issues.

Analyzes documentation against Diataxis framework (Tutorial, How-to, Reference, Explanation). Use when reviewing documentation structure or classifying content type. Identifies misalignments between declared category and actual content.

Performs comprehensive documentation review including build validation, Diataxis analysis, structure audit, accuracy verification, and style compliance. Use when reviewing documentation changes or auditing documentation quality.

Validates documentation structural integrity including heading hierarchy, metadata, file naming, navigation, and cross-references. Use when checking documentation organization or validating toctree structure.

Enforces project documentation style guide compliance for tone, voice, terminology, punctuation, and formatting. Use when checking documentation style or validating MyST/reST syntax. Cites specific style guide violations.

Verifies documentation accuracy by cross-referencing claims, CLI commands, API signatures, and configuration against source code. Use when validating documentation correctness or checking code-docs consistency. Flags unsupported or outdated claims.

Guidance on writing fast, robust, modern Svelte code. Load this skill whenever in a Svelte project and asked to write/edit or analyze a Svelte component or module. Covers reactivity, event handling, styling, integration with libraries and more.

Use when the user asks for documentation. Use when a new feature has been built or significantly changed and its design/decisions should be recorded in the repo's docs/. Captures the approach (and optional rationale) into per-topic markdown files (testing, api-endpoints, routes, data-loading, components, state-management, business-logic, forms-actions, auth, error-handling, build-deployment). Do NOT use for bugfixes, style tweaks, or other small tasks.

Use whenever you need to write a unit, integration or component test.

Use when reviewing code changes. Checks Svelte 5 runes usage, SvelteKit data-loading/endpoints, server-only and env/secret boundaries, SSR state leakage, storefront pitfalls (money, cart/price/stock trust boundaries, payments, SEO, a11y, caching), tests, and the repo's verification gates. Use ONLY for reviewing/critiquing existing code, not for writing new features.

Shared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable or AI-navigable, or when another skill needs the deep-module vocabulary.

Use when the user wants a plan or breakdown for building a feature (or significantly reshaping one) before any code is written. Turns a feature request into a written implementation plan of self-contained, independently testable vertical slices. Do NOT use for bugfixes, refactors with no behavior change, or trivial one-step tasks.

Build, install, and runtime-verify an inference snap including engine selection and prompt/API checks.

Run the full inference-snap workflow as a sequential chain of subagents — structure → github workflows → static checks → build & prompt check → create PR — passing each stage's report as input to the next.

Create GitHub Actions workflow files for inference snap repositories based on canonical/gemma4-snap patterns.

Push the current branch to a remote repo and open a pull request with the "trigger-tests" label applied.

Perform static quality checks for an inference snap (snapcraft.yaml consistency, component completeness, model signature verification).

Create and adapt the inference snap structure from reference examples (packaging, engines, hooks, scripts, components).

Check backend code coverage and flag packages below 80%

Scaffold a new Architecture Decision Record

Scaffold a new rule (static, live, or catalog) with tests and registration

Regenerate docs from code (rules, API, README)

Split working tree changes into logical git commits and push

Build and validate diagram-generator outputs. Use when changing renderers, shared primitives, deliverable SVGs, draw.io exports, compare pages, or any diagram slug that needs rebuild, sanitization, and focused output checks.

Redraw rough sketches or inconsistent diagrams into on-brand SVG and draw.io outputs. Use when adding a new diagram slug, translating a rough source into generator code, picking local icons, wiring compare pages, or producing editable outputs.

Sync broader design-language specs into the diagram system. Use when importing typography, spacing, or grid rules from the upstream design language into tokens.ts, shared renderer constants, draw.io style sync, or layout helpers.

Assign correct frame levels in YAML when nesting > 0. Use when creating or modifying a frame YAML that contains containers (items with children). Ensures siblings share the same visual class.

Safely modify manually edited draw.io files. Use when preparing a review copy, checkpointing an original draw.io file, promoting reviewed changes back, or documenting a revert path for protected manual edits.

Cross-agent CLI skill with command-per-file architecture. Primary command: /cli-review.

Copilot adapter for cross-agent CLI skill commands.

Pi Coding Agent adapter for command-per-file CLI workflows.

GitHub Copilot entrypoint for the cross-agent CLI skill.

Pi entrypoint for cross-agent CLI command workflows.

Add or improve debian/tests/ for as-installed Debian package testing per DEP-8. Detects package shape (library, daemon, CLI tool), proposes minimal Restrictions, runs tests with the lightest virt backend available. Asks the maintainer before enabling isolation-container or needs-root.

Create a fresh debian/ directory for an unpackaged upstream source tree. Use when source.has_debian_dir is false. Output is builds-once, lintian-respectable, UNRELEASED packaging ready for maintainer review. Debian-first, Ubuntu overlay.

Resolve lintian -EvIL +pedantic output on a Debian source package by classifying each tag and producing the right fix — packaging change, DEP-3 quilt patch, or justified override with a comment. Bails to the maintainer after 3 attempts on the same tag. Never blanket-suppresses.

Modernise an existing debian/ directory to current house style — compat bump, Standards-Version, R³, dh-sequence migration, wrap-and-sort, watch v5, DEP-5 normalisation, M-A audit, Salsa-CI. Default dry-run. The most dangerous worker; treat the maintainer's prior choices with respect.

Orchestrate Debian packaging tasks — bootstrap, refresh, lintian, autopkgtest — via the debaid worker skills. Use when a maintainer wants end-to-end packaging help on a Debian/Ubuntu source package, or a subset of phases selected with --only / --skip. Debian-first, Ubuntu overlay.