← all publishers

gridaco

@gridaco source repo

19 published skills

  1. Spock Lang · gridaco bundle
    Create, 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.
    0
    installs
  2. Uhura Lang · gridaco bundle
    Create, 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.
    0
    installs
  3. Links · gridaco
    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/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.
    0
    installs
  4. Io Svg · gridaco
    Guides 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.
    0
    installs
  5. Naming · gridaco bundle
    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.
    0
    installs
  6. Vision · gridaco bundle
    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".
    0
    installs
  7. Docs Wg · gridaco
    Doctrine 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.
    0
    installs
  8. Etiology · gridaco
    Bug-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.
    0
    installs
  9. Fixtures · gridaco
    Guides 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.
    0
    installs
  10. Io Grida · gridaco
    Guides 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.)
    0
    installs
  11. Pedantic · gridaco
    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-engi
    0
    installs
  12. Research · gridaco
    Research 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/.
    0
    installs
  13. Sdk Seam · gridaco
    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.
    0
    installs
  14. Sdk Design · gridaco
    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, `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.
    0
    installs
  15. Render Perf · gridaco
    Guides 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.
    0
    installs
  16. Oss Standards · gridaco
    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/nothing` or when finalizing work for review.
    0
    installs
  17. Render Reftest · gridaco bundle
    Design, 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.
    0
    installs
  18. Dev Render Htmlcss Feature · gridaco
    Manual-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.
    0
    installs
  19. Dev Render Htmlcss Svg Feature · gridaco
    Manual-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).
    0
    installs