i2mint

Load context on acture's schema bridge — Zod → JSON Schema projection, MCP tool emission, AI SDK tool definitions, Standard Schema compatibility, and the JSON-Schema-representable subset rule. Use when working on toJsonSchema, the MCP adapter, the Vercel AI adapter, the Anthropic adapter, schema validation at registration, or compare-schemas. Triggers on "JSON Schema", "Zod schema", "z.toJSONSchema", "MCP tool", "AI tool definition", "schema bridge", "Standard Schema", "Valibot", "param schema validation". Do NOT use for general CommandRecord questions (load `acture-command-record-shape`) or for the tier/versioning system (load `acture-tier-system`).

Build an embedded AI assistant that OPERATES a command-dispatch app — not just a chatbot that answers, but an assistant that reads current app state and takes actions on the user's behalf. Composes acture's write-side (command→tool/MCP, via acture-ai / acture-mcp) with the missing read side (a ViewRegistry projected to MCP resources + a getState tool), a dispatch-boundary human-in-the-loop confirmation gate, and dispatch-chain capture (undo/replay). Bridges to the general ai-assistant-* skill family for the runtime, chat UI, and prompts (which stay the app's choice). Use when adding an "operate my app" assistant/copilot to a command-dispatch app, exposing app state to an LLM, wiring MCP resources, or gating destructive AI actions. Triggers on "AI assistant", "operate my app", "copilot", "agent that takes actions", "expose state to the AI", "MCP resources", "getState tool", "human in the loop", "confirmation gate", "CopilotKit", "assistant-ui", "AG-UI", "the assistant should see what's selected".

Build a keyboard-shortcut consumer surface in a target project — bind `keybinding` off every CommandRecord and dispatch through the registry on key match, AND (new) let end users remap shortcuts. Covers the tool-library choice (tinykeys / react-hotkeys-hook / custom), the agent-written vs `acture-hotkeys` package paths, first-registered-wins conflict resolution, fire-time when-clause evaluation, the input-aware default, and end-user customization (persisted user keymap over the record default, press-to-record capture, conflict detection, physical-vs-logical keys, WCAG 2.1.4). Use when adding keyboard shortcuts to a command-dispatch app, when adding user-remappable shortcuts, or when working ON the `acture-hotkeys` package. Triggers on "hotkeys", "keyboard shortcuts", "keybindings", "bind keys", "tinykeys", "Ctrl+K shortcut", "shortcut conflict", "modal-scoped shortcuts", "customize keybindings", "remap shortcut", "rebind keys", "user keymap", "keybinding editor", "keymap preset".

Build an MCP-server consumer surface in a target project — project the command registry as Model Context Protocol tools (`{name, description, inputSchema}`), tier-filtered, errors-as-data, AND (new) project app state as MCP resources (the read side — views → `resources/list`/`resources/read`/`resources/subscribe`). Covers the two-layer split (pure projection vs transport glue), the agent-written vs `acture-mcp-server` package paths, tier semantics, function-when-clause exclusion, the prompt-injection guardrails, and the read-side resources projection. Use when exposing a command-dispatch app to MCP clients, exposing app state as MCP resources, or when working ON the `acture-mcp-server` package. Triggers on "MCP", "MCP server", "Model Context Protocol", "tools/list", "tools/call", "MCP resources", "resources/list", "expose state to an assistant", "expose to Claude", "stdio server", "@modelcontextprotocol/sdk".

Load the conceptual model of acture's command-dispatch architecture. Use this skill at the start of ANY non-trivial task in the acture repository — it covers the three primitives (state model, command registry, schema bridge), the eight consumer surfaces, and acture's dev-tool-first positioning with its two flexibility dimensions. Triggers on phrases like "what is acture", "how does the architecture work", "the three primitives", "the consumer surfaces", or when starting a new phase. Do NOT use this for narrow API/typing questions — load `acture-command-record-shape` or another targeted skill instead.

The foundational pattern for building a command-dispatch CONSUMER in a target project — a command palette, keyboard shortcuts, AI tool calling, an MCP endpoint, e2e testing, macros, telemetry, undo. Load this whenever you are adding a consumer surface to a user's app, OR whenever you are working on a consumer-specific acture-* package (acture-palette-react, acture-hotkeys, acture-mcp-server, acture-ai-vercel, acture-e2e-playwright, …). It encodes acture's dev-tool-first positioning: the agent-written path is always viable, acture packages are an optional opt-in accelerator, and tool-library choices belong to the user. Triggers on "add a command palette", "add hotkeys", "wire up MCP", "expose commands to an AI", "set up e2e testing", "build a consumer", "which acture package should I use", "do I need to install acture".

Build an extension / plugin consumer surface in a target project — let code you did not author contribute new commands to the registry via a typed, inert manifest, invoked through `dispatch`. Covers the trust-tier fork (trusted in-process host/loader vs untrusted-author isolation), the contribution-manifest shape, the ~15-line hand-written host (there is NO package for the trusted path — it ships as a pattern), the deferred isolation-only `acture-sandbox` package and the single trigger that unlocks it, and the prompt-injection / supply-chain guardrails. Use when a host needs to load command-contributing code from a partner, customer plugin, or Labs bundle, or when working ON the deferred `acture-sandbox` package. Triggers on "extension", "plugin", "plugin system", "contribution points", "third-party commands", "extension API", "sandbox", "isolate untrusted code", "iframe sandbox", "QuickJS", "load external commands".

Concrete, file-by-file walk-through for standing up a command-dispatch layer in a NEW PHP project. Covers the state model (cuyz/valinor DTOs + backed enums), the `#[Command]` attribute, a ~120-line attribute-scanning CommandRegistry on top of symfony/messenger, JSON Schema generation via spiral/json-schema-generator, the first CLI surface (Symfony Console 7.3 invokable commands), and Pest architecture tests that enforce the contract. Use after `acture-php` once the project has chosen the greenfield path. Triggers on "new PHP project with commands", "set up command registry in PHP from scratch", "PHP greenfield acture", "Symfony Messenger registry from scratch", "Laravel command registry from scratch", "first PHP command".

Full health diagnosis and improvement dispatch for a wads-managed Python repo (uv-ci stub, i2mint conventions). One read-only audit across every dimension — legacy packaging, CI generation and status, PyPI/pyproject version sync, PyPI metadata, tests, docstrings, docs publishing, GitHub metadata drift, type annotations/py.typed, import time, changelog, agent skills — then a prioritized health report and dispatch to specialist skills one dimension at a time. Use for "diagnose this repo", "repo health check", "what's wrong with this repo", "audit this package", "doctor this repo", "how healthy is this project", "bring this repo up to standard", "what should I improve here". Also trigger when the user names a repo and wants a general improvement pass. Does NOT itself migrate, debug CI, write tests, or fix docstrings — it diagnoses, prioritizes, and routes to the owning specialist skills. Only GitHub metadata alignment is fixed inline.

Point-in-time CI health snapshot for a single wads-managed Python repo (one using the i2mint uv-ci stub or inline uv workflow). Checks five things and reports a checklist: is CI green, is ci.yml the current stub (and how it's pinned), are the secrets wired correctly across the two layers, is the version in sync between pyproject/PyPI/git tags, and is docs publishing (Pages, Discussions) healthy. Use when the user asks "is CI green", "check CI health", "why didn't it publish", "is this repo's CI up to date", "are my CI secrets set up right", "is PyPI in sync with pyproject", "give me a CI snapshot", or "health-check this repo's CI". Diagnosis only — fixes are delegated: format migration → wads-migrate, push-back/version-sync repair → wads-ci-fix, fleet/batch work → wads-ci-sweep, Pages repair → epythet-docs. Does NOT cover generic CI strategy or non-wads pipelines — use ci-advisor or ci-setup for those.

Use when migrating Python projects to modern wads setup (pyproject.toml + uv CI). Triggers on migration tasks, CI modernization, setup.cfg conversion, switching from pip to uv, or moving a repo from inline uv CI to the reusable-workflow stub.

The skills step of a wads repo-improvement pass: assess whether a repo warrants AI agent skills (baseline: a consumer + a dev skill) and dispatch the work. Layout, distribution, and spec compliance are DEFERRED to the canonical authority — the `skill-package-setup` skill in the `skill` package. Use when the user says "skillify this repo", "does this repo need skills", "set up skills for this project", "where should skills live", "restructure the skills layout", "align/validate my skills", "make skills gh-skill compatible", or "why doesn't Claude Code see this repo's skills". Also trigger as the skills step of a repo health pass (wads-repo-doctor). Does NOT author skill content (skill-build / skill-creator), write README docs (skill-docs), or fix content drift (skill-sync).

Diagnose and close test-coverage gaps in a wads-managed Python repo (pytest + doctests + uv CI). Measures coverage exactly as CI does (doctests included), adds branch coverage and per-test contexts, buckets every public function/class as untested / doctest-only / test-covered, then writes the missing tests. Use for "what's untested", "check test coverage", "coverage gaps", "which functions have no tests", "is this only covered by doctests", "improve coverage", "raise coverage", "write tests for the uncovered parts", "add tests for this module". Also trigger when CI coverage numbers look wrong or a doctest-heavy package looks untested. Does NOT analyze failing-test output (pipe pytest output to the wads-test-analyze CLI), measure docstring presence (wads-docs-coverage), or check CI workflow health (wads-ci-health).

Documentation coverage for a wads-managed Python repo: diagnose, align, complete. Measures docstring presence (every module, class, and function), executes the README's code blocks to prove they still run, cross-checks README names and install lines against the live API, and detects signature↔docstring drift; then proposes removals for obsolete docs and writes missing Google-style docstrings (with doctests) and README sections. Use when the user says "audit the docs", "docs coverage", "what's missing docstrings", "write the missing docstrings", "is the README up to date", "check the README examples", "the README mentions things that don't exist", or "docstring coverage report". Also trigger after a refactor or rename that may have stranded docs, or when CI lint flags D1xx missing-docstring errors. Does NOT fix RST/Sphinx rendering mistakes (use wads-docstring-render), does NOT cover docs publishing, GitHub Pages, or 404s (use epythet-docs), and does NOT measure test coverage (use wads-test-coverage).

Generate and maintain CHANGELOG.md for a wads-managed repo (one where CI auto-bumps the version and tags releases with bare version tags like 0.2.3) from git history. Diagnoses coverage (does a changelog exist, latest tag vs latest version covered, gap list), generates Keep-a-Changelog-style sections per version tag with CI noise filtered (bump commits, [skip ci] housekeeping, bare merges) and PR titles kept verbatim, and maintains the file idempotently: only inserts sections for missing versions, never rewrites hand-edits. Use for "generate a changelog", "create CHANGELOG.md", "update the changelog", "is the changelog up to date", "backfill the changelog", "what changed in 0.2.3", "release notes from git history", "changelog is behind the releases". Also trigger when wads-repo-doctor reports a missing/stale changelog. Does NOT add the [project.urls].Changelog link or polish PyPI metadata (wads-pypi-polish), and does NOT diagnose version-sync or CI problems (wads-ci-health).

Find and fix docstrings that mis-render under epythet (Sphinx + RST + napoleon): single backticks showing as italics, doctests glued into paragraphs, literal "Returns:" or ":param" text, red asterisks from bare *args, collapsed bullet lists, markdown fences, smartquote-corrupted code. Use for "fix my docstrings", "the API docs render wrong", "my doctest shows as plain text", "why is this italic in the docs", "red asterisks in the docs", "Returns: shows literally on the page", "audit docstring RST", "make docstrings Sphinx-clean", "the published module page looks mangled". Also trigger after writing new docstrings or before a docs release. Does NOT cover docs publishing, GitHub Pages, or 404s (use epythet-docs), and does NOT measure docstring presence/coverage or README drift (use wads-docs-coverage).

Developer skill for implementing a new vector-database backend in the vd package. Use when adding, refactoring, or reviewing a vd backend adapter (qdrant, pinecone, weaviate, lancedb, pgvector, faiss, etc.) — covers the AbstractClient/AbstractCollection raw-primitive contract, filter handling, capability protocols, the escape hatch, and the provider registry. Trigger on "add a backend to vd", "implement the X backend", "vd adapter".

Backend-selection and setup tooling for the vd package. Use this skill when the user is picking a vector database with vd, asks "which backend should I use", weighs persistence / cloud / cost / hybrid / scale trade-offs, hits a "backend not installed" error, or needs help installing and starting a vectorDB (pip packages, Docker, API keys, env vars).

Operational tooling for the vd package. Use this skill when the user is managing a vd collection beyond reads/writes — exporting or importing data (JSONL / JSON / directory), migrating between backends, computing collection statistics, finding duplicates / outliers, validating integrity, running health checks, benchmarking search or insert latency, or driving any of the above from the `vd` CLI.

Vector-search tooling for the vd package. Use this skill when the user wants to do semantic / vector search in Python with the vd package — connecting to a backend, creating a collection, adding documents, and running a query. Also trigger on mentions of "vector database", "embeddings + search", or any time the user imports `vd` for a new task and needs the basic happy-path setup.

Advanced-search tooling for the vd package. Use this skill when the user goes beyond a single basic .search() call with vd — metadata filters with MongoDB-style operators, multi-query searches, reciprocal rank fusion, finding documents similar to an existing one, deduplicating result sets, or searching by a pre-computed query vector.

Corpus-ingestion tooling for the vd package. Use this skill when the user has documents, files, articles, or long text they need to load into a vd collection — including cleaning text, splitting it into chunks, attaching metadata, and adding the result in batches. Trigger on requests like "load these docs into a vector DB", "chunk this text", "preprocess before embedding", or "bulk insert".

Routing data through a graph of type/representation conversions with i2.castgraph's TransformationGraph — register pairwise transformers, then convert any source representation to any reachable target via multi-hop shortest-path routing. Trigger on "convert between many data representations", "type conversion registry / service", "transformation graph", "filepath -> text -> record style pipeline", "find a conversion path between two kinds", "adapter / anti-corruption layer for external formats", "cast a thing whose form varies but role is stable".

Composing and combining a fixed collection of functions (or context managers) with i2.multi_object — Pipe (function composition), FuncFanout (apply many functions to the same input), ParallelFuncs (per-key dict-to-dict), FlexFuncFanout (shared argument pool), and ContextFanout (bundle context managers). Trigger on "compose functions into a pipeline", "apply several functions to the same arguments", "run a function per dict key", "chain transformations", "bundle multiple context managers as one", "function pipeline", "fan out / fan in".

Building, merging, and editing function signatures with i2's Sig — signature "+/-" arithmetic, changing parameter names/kinds/defaults/annotations, and giving a function a different signature (a la functools.wraps but signature-driven). Trigger on "merge two signatures", "combine the parameters of several functions", "give this function a new signature", "rename/reorder function parameters", "change a parameter's default", "make all params positional-or-keyword", "add an optional keyword argument to a function", "Sig() decorator", "ch_func_to_all_pk".

Introspecting function signatures and binding call arguments to parameter names with i2's Sig class — turning an arbitrary (*args, **kwargs) call into a named-argument dict (with defaults filled in), and back. Trigger on "bind args to parameter names", "get the full kwargs of a call", "apply defaults to a call", "what are this function's parameter names/kinds/defaults", "call a function forgivingly / ignoring extra kwargs", "normalize a call for caching/hashing", "inspect.signature is not enough", "Sig", "map_arguments".

Wrapping functions to transform their interface, inputs, and output with i2.wrapper — wrap, Ingress/Egress, ch_names, include_exclude, rm_params, arg_val_converter, partialx, and caller-based wrapping (Wrapx). Trigger on "wrap a function and change its signature", "transform arguments before calling", "rename/remove/reorder a function's parameters but keep it working", "convert/cast argument values", "make a CLI/HTTP-friendly version of a function", "currying with a clean signature", "apply a function over an iterable of inputs (iterize)", "ingress / egress", "decorator factory".

Use when developing or modifying the enlace package itself — adding features, fixing bugs, extending the ASGI composition, adding middleware, process supervision, or working on any module in the enlace/ source directory. Triggers on: editing enlace source files (base.py, discover.py, compose.py, serve.py, supervise.py, proxy.py, auth.py, stores.py), implementing spec phases 2-4, or when the user says "add X to enlace" or "implement Y in enlace".

Use when working with the enlace multi-app platform — creating apps, configuring platform.toml or app.toml, diagnosing discovery issues, understanding conventions, or serving/deploying apps. Triggers on: enlace CLI commands, apps/ directory structures, platform.toml/app.toml files, multi-app ASGI composition, process supervision, or when the user mentions enlace, app discovery, app mounting, or personal app platform.

Diagnose whether an app can be "enlaced" (mounted under the enlace multi-app platform). Identifies hardcoded URLs, CORS issues, SSR requirements, missing entry points, and other compatibility blockers. Produces a report with severity levels and actionable fix suggestions that preserve the app's ability to run standalone. Use when the user wants to bring an existing app into enlace, asks "can this app be enlaced?", "why won't my app work with enlace?", "diagnose this app", or when onboarding any new app. Also triggers on: "compatibility check", "what needs to change", "analyze this app for enlace", or when the user points at an app directory and asks about integration.

Use when developing or modifying the enlace package itself — adding features, fixing bugs, extending the ASGI composition, adding middleware, or working on any module in the enlace/ source directory. Triggers on: editing enlace source files (base.py, discover.py, compose.py, serve.py, auth.py, stores.py), implementing spec phases 2-4, or when the user says "add X to enlace" or "implement Y in enlace".

Use when working with the enlace multi-app platform — creating apps, configuring platform.toml or app.toml, diagnosing discovery issues, understanding conventions, or serving/deploying apps. Triggers on: enlace CLI commands, apps/ directory structures, platform.toml/app.toml files, multi-app ASGI composition, or when the user mentions enlace, app discovery, app mounting, or personal app platform.

Build a dol store: wrap any storage backend (files, S3, DB, dict, an API) behind a uniform dict-like (MutableMapping) interface, adding key and value transforms/serialization. Use when a user wants to give a backend a dict interface, add JSON/pickle/gzip (or custom) serialization to a store, transform or filter keys, compose codecs, cache a slow store, or asks 'how do I use dol to ...'. Covers wrap_kvs (the core), the ValueCodecs/KeyCodecs namespaces, Pipe composition, the ready-made file stores (Files/TextFiles/JsonFiles/PickleFiles), filt_iter, the test-with-dict-then-swap-backend workflow, and self-aware transforms via FirstArgIsMapping. For authoring interactive scaffolds see the /new-store, /add-codec, /explain-store commands; for modifying dol's internals see dol-dev-wrap-kvs.

Understand and safely modify dol's core wrapping machinery — wrap_kvs, store_decorator, Store.wrap, and how transforms are applied. Use when touching dol/trans.py or dol/base.py; when changing how key/value transforms (key_of_id, id_of_key, obj_of_data, data_of_obj, postget, preset) are called; when a transform passed to wrap_kvs behaves unexpectedly (called with/without the store as first arg); when working Issues #9/#12/#18/#6/#5; or when a wrap_kvs change could ripple through the ~32 ecosystem packages that use it. Covers the signature-conditioning rule (name AND arity), the FirstArgIsMapping marker, the delegation (has-a) architecture and its 'self is unwrapped' trap, the subclass-signature-freeze trap, and the mandatory dependents test-gate. For end-user store-building, see the consumer skills; for Windows path issues, see dol-dev-portability.

Keep dol working on Windows as well as Linux/macOS. Use when touching dol's path/key machinery (filesys.py, naming.py, paths.py, util.py), compiling regexes from templates/paths, mapping keys<->filesystem paths, or when a dol test/doctest passes on Linux/macOS but fails on the Windows CI job. Covers dol's specific landmines: safe_compile is path-only (never compile a regex with it), escape template LITERALS not the whole pattern, os.sep consistency in prefix/affix codecs, empty-prefix handling, POSIX-only os calls, and dol's native-separator key convention. For general cross-platform Python principles, see the global `cross-platform-python` skill.

Convert files, URLs, or raw content to PDF using pdfdol. Use this skill whenever the user wants to convert documents to PDF format -- including EPUB, MOBI, DOCX, ODT, HTML, Markdown, images, URLs, or any other file format to PDF. Also use when the user asks about what formats can be converted to PDF, wants to register custom format converters, or needs to check whether Calibre/ebook-convert is available. Triggers on: "convert to pdf", "make a pdf from", "epub to pdf", "save as pdf", "export to pdf", "pdf from url", "screenshot to pdf", "image to pdf", "docx to pdf".

Read, extract text from, and process PDF files using pdfdol. Use this skill whenever the user wants to extract text from PDFs, read PDF metadata (title, author), access a folder of PDFs as a dict-like store, concatenate or merge multiple PDFs, or do batch PDF operations. Triggers on: "extract text from pdf", "read pdf", "pdf to text", "get pdf title", "merge pdfs", "combine pdfs", "concatenate pdfs", "pdf metadata", "pdf folder", "pdf store", "batch pdf".

Use when developing, reviewing, or extending the azuredol package (Azure Blob Storage as dol Mapping interfaces). Triggers on edits under i/azuredol/, on imports of `azuredol`, when adding new blob-store wrappers, value codecs, or credential paths, when writing tests against Azurite, when reviewing PRs against azuredol, and when designing sibling packages like azuredatalakedol.