gridaco
- 19 skills
- 0 followers
- 10 hours ago last updated
- ▌ Spock Lang · gridaco bundleCreate, inspect, validate, run, debug, and modify Spock v0 backend and framework projects using the published npm distribution. Use when turning product requirements into a Spock program; scaffolding or adopting a framework project; changing tables, records, functions, seed data, actor-aware operations, storage, or refusals; generating contracts, TypeScript, or GraphQL; or verifying Spock-backed Uhura behavior.
- ▌ Uhura Lang · gridaco bundleCreate, inspect, validate, run, debug, and modify strict Uhura 0.4 machine-first programs and Web UI applications inside Spock framework projects. Use when translating requirements into machines, explicit UI projections, deterministic evidence, host bindings, or provider-backed behavior; repairing Uhura diagnostics; or verifying Editor, Play, and authority behavior with the npm-distributed Spock CLI.
- ▌ Links · gridacoWrite 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/wg specs, crate READMEs and docstrings, the npm-published wasm package README, or skills. This is the engine-repo variant of the grida links doctrine.
- ▌ Io Svg · gridacoGuides work on SVG import into the Grida Canvas Rust engine (grida crate). Covers crates/grida/src/import/svg/, the grida_dev svg-to-grida CLI, cross-boundary FBS codec tests (Rust encode → TS decode), SVG fixture authoring, and known SVG import limitations (text model, filters, transforms). Use when adding SVG feature support, fixing import bugs, authoring SVG test fixtures, debugging cross-boundary codec failures, or investigating what SVG elements map to which Grida node types.
- ▌ Naming · gridaco bundleHow 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.
- ▌ Vision · gridaco bundleQuery 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".
- ▌ Docs Wg · gridacoDoctrine for drafting and keeping working-group docs under `docs/wg/**` — RFC/RFD specs and findings/research/glossary. A WG doc is a language-agnostic, code-agnostic study of a domain: it argues *why* and defines *what*, never *how in our code*. Use when writing or editing anything under `docs/wg/`, an RFC/RFD, a spec, a design note, a glossary, or research findings — including "write up the design", "document the spec", or "capture what we learned". Not for plans/TODOs (untracked `*.plan.md`), user docs, or SDK API refs — use `docs` to route those.
- ▌ Etiology · gridacoBug-fix discipline — every defect has an etiology, the chain of cause that produced the observable fault; trace it before patching. Errors only grow: a bandaid leaks unless genuinely localized and leak-free. Walk the diagnostic ladder (presentation → proximate cause → API contract → isolated or systemic) before writing the fix. Use when authoring or reviewing any bug fix, regression patch, "quick fix" PR, or when deciding whether to ship, defer, or refactor.
- ▌ Fixtures · gridacoGuides authoring, organizing, and referencing test fixtures across the engine repo. Use when creating new fixtures, writing tests that depend on fixtures, or deciding what should be checked into git.
- ▌ Io Grida · gridacoGuides work on the Grida file format (.grida): the FlatBuffers schema and the Rust decoder that loads it into the canvas runtime. Use when working with .grida files, the FlatBuffers schema, codegen, or debugging format issues. (The TS reader/writer packages live in the grida product repo.)
- ▌ Pedantic · gridacoRole 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-engi
- ▌ Research · gridacoResearch upstream and peer projects to inform Grida's design and implementation. Use when investigating how Chromium, Skia, Servo, Taffy, or peer canvas editors solve a problem before writing code. Covers source-code exploration and research document authoring under docs/wg/research/.
- ▌ Sdk Seam · gridacoDiscipline 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.
- ▌ Sdk Design · gridacoDoctrine 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, `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.
- ▌ Render Perf · gridacoGuides performance optimization work on the Grida Canvas Rust rendering engine (grida crate). Use when asked to benchmark, profile, optimize, or analyze rendering performance — panning, zooming, compositing, caching, culling, or frame budgeting.
- ▌ Oss Standards · gridacoPre-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/nothing` or when finalizing work for review.
- ▌ Render Reftest · gridaco bundleDesign, review, and debug visual rendering tests: reftests (independent oracle), golden/snapshot regression tests, probe tests (pixel assertions without vision), SVG reftest suites, and Figma refig suites. Use when adding pixel diffs, choosing an oracle strategy, or comparing renderer output against a ground truth.
- ▌ Dev Render Htmlcss Feature · gridacoManual-invocation only. Five-phase feature loop (audit → ground → fixture → implement → verify) for driving a single CSS feature to Chromium parity in the grida htmlcss renderer.
- ▌ Dev Render Htmlcss Svg Feature · gridacoManual-invocation only. Five-phase feature loop (audit → ground → fixture → implement → verify) for driving a single SVG feature to Chromium parity in the grida `htmlcss::svg` renderer. Sibling to `dev-render-htmlcss-feature` (HTML/CSS path); same loop shape, different corpus (resvg-test-suite + Chrome bake) and different scoring (multi-oracle: consensus / disputed / UB).