grida

Write any link or URL so it resolves where it is rendered, not where it lives in the repo. Use when authoring or editing a link — in docs, source docstrings, READMEs (incl. npm-published), or product UI: docs cross-refs, "see SECURITY.md", universal `/_/` routes, GitHub URLs.

How to think about names in the Grida repo — not conventions, but what a name commits you to, reveals about the system, and costs to change. The central discipline is that a strict, honest name refuses to grow, and that refusal drives the repo's shape (flat modules, small agnostic packages, suffix siblings). Use when planning a new package, crate, module, directory, route group, or test corpus — the name comes first.

Set up, download, verify, and seed the optional Grida Library developer corpus into local Supabase. Use when Library browse/search, Desktop reference picking, or agent Library tools need realistic local assets and Gemini embeddings; also use when changing the gridaco/grida consumer for gridaco/library developer-corpus releases.

Pre-PR discipline for a public-by-default repo. What a reviewer enforces beyond CI: secrets and internal data in diffs or screenshots, docs that name their reader, and the cleaning pass where incomplete or confusing artifacts get dropped. Use before opening any PR against `gridaco/grida` or when finalizing work for review.

Role profile — a reviewer who is fact-seeking, bedrock-seeking, honest, and rejecting. Demands that arguments rest on small facts that cannot be wrong (not on stacked assumptions dressed up as foundation), and that deliberately-unclear concepts be quarantined — never leaked into solid layers, never mixed with each other. Catches the failure mode where designs ship after partial grounding: most of the spec researched, the design feels finished, and the unresearched remainder holds the deal-breaker. Invoke with `/pedantic <target>` (e.g. `/pedantic review this design doc`, `/pedantic review the SDK design`, `/pedantic review this PR`). Probes cover logical structure (definitions, assumptions, boundaries, contradictions, unfalsifiability, vague quantifiers, counterexamples), epistemic honesty (researchable vs. discoverable-only-by-doing), bedrock integrity (assumed-bedrock, leaked uncertainty, mixed unclarity), and design pathology (YAGNI, wrong-layer abstraction, unclear responsibility, fragmentation, over-engineering). Use when you want a hard critique of a plan, design doc, technical doc, code change, or PR description — not a copy edit, not a vibe check.

Doctrine for designing and evolving any **SDK** Grida ships — TypeScript, Rust, or otherwise. "SDK" here means a surface that crosses a foreign-or-foreign-treated boundary: published packages, separately-versioned consumers, FFI bindings, public-by-design modules. An SDK's job is to refuse; a strict, honest surface rejects the wrong contents and keeps the package testable in isolation. Default is "core, not customizable"; customization is the exception, defended by a deciding table. Use when authoring or evolving any such surface — `@grida/*` published packages, engine crates (gridaco/nothing `crates/*`) published or FFI-exported, intent/message vocabularies, any contract a second author will compile against. Internal-only helper packages are welcome to follow, not forced. Companion skill for two-sided contract work: $sdk-seam. Critique partners: $pedantic, $etiology. Related: $naming.

Discipline for the seam between two SDKs (or two sides of one contract) that the same hand writes. The failure mode: "we own both sides" produces dirty contracts no foreign reviewer would accept. The exercise: pretend the other side is FFI, IPC, or a network protocol you cannot rewrite. Spawn an adversarial subagent profiled as the producer's maintainer; negotiate the change as a feature request, not a PR. Companion to $sdk-design. Language-agnostic — applies to a TS package + its consumer, a Rust crate + its WASM binding, two services sharing a wire format, or any other boundary the same author writes both ends of.

How to handle `GRIDA-SEC-<id>` security boundaries in the Grida repo. Triggers when you encounter a `GRIDA-SEC` tag in source/docs, when modifying files under any tagged path, or when adding a new prevented- vulnerability record. Each `GRIDA-SEC-<id>` identifies a structural trust boundary documented in `/SECURITY.md`. This skill explains the contract, mandates a security review before committing changes to any tagged file, and shows how to register a new id. Use whenever "GRIDA-SEC" appears in context.

SEO best practices for the Grida project across Next.js pages, blog posts, and documentation. Covers Next.js metadata API, Open Graph / Twitter cards, sitemaps, image search optimization, structured data (JSON-LD), Docusaurus frontmatter, and content writing for search. Use when creating or editing public-facing pages under editor/app/(www), writing blog posts, authoring docs, or reviewing SEO-related metadata. Trigger phrases: "SEO", "metadata", "sitemap", "open graph", "og image", "meta tags", "search ranking", "structured data", "JSON-LD".

Build a Grida slides deck — a `.canvas` bundle in slides mode whose pages are SVG documents (16:9, one SVG per slide). Use when creating a presentation, pitch deck, slideshow, or talk.

Author and edit `.svg` files in a Grida editor session — live-canvas binding, SVG output style, and parse-error recovery. Use when creating or modifying an SVG document.

Query images with a local Ollama vision model without loading the image into the main agent context. Use when you need to describe a screenshot, check whether rendered content is present, detect overlapping elements, or ask any visual question about a PNG/JPEG/WebP file. Requires Ollama running locally with the Gemma 4 multimodal model (`gemma4` on Ollama). Script: .agents/skills/vision/scripts/ask.py. Trigger phrases: "describe image", "what does this screenshot show", "does the canvas contain content", "check screenshot visually", "look at this image", "any overlapping elements", "vision query".