itzikiusa
@itzikiusa
Public Skills
missing-evals-skill
by itzikiusa
Use this skill when converting legacy CSV exports from the Northstar billing system into normalized JSON invoices.
bad-no-examples
by itzikiusa
Audits SQL query optimization skills for trigger clarity, workflow structure, references, evals, and safe script usage. Use when reviewing a SQL-optimization Agent Skill package.
good-focused
by itzikiusa
Reviews D2 diagram skill drafts for syntax workflow, diagram examples, references, and eval coverage. Use when asked to audit a D2-specific Agent Skill; do not use for generic code review.
bad-script-risk
by itzikiusa
Checks deployment helper skills for script safety, examples, references, evals, and conflict risks. Use when reviewing a deployment Agent Skill that bundles shell or Python scripts.
excellent-skill
by itzikiusa
Use this skill when reviewing small API migration pull requests for the Acme Payments service, especially changes touching idempotency keys, retry behavior, webhook signatures, or migration SQL.
bad-conflicts
by itzikiusa
Reviews release notes skill drafts for clarity, examples, references, and evals. Use when asked to audit release-note skills before publishing.
bad-bloated
by itzikiusa
Helps with everything and all tasks across coding, writing, research, diagrams, deployment, finance, product work, emails, analysis, and anything else.
interactive-script-skill
by itzikiusa
Use this skill when cleaning generated build artifacts from a repository and producing a deletion report.
bloated-conflicting-skill
by itzikiusa
Helps with everything related to documents, coding, research, travel, and productivity.
D2 Diagram Master
by itzikiusa
Use whenever asked to work on a diagram — create, update, improve, review, validate, or render one — including architecture / C4 maps, sequence & API flows, ERDs / SQL schemas, data flows & ETL pipelines, infrastructure / Kubernetes / deployment topology, dependency & module graphs, state machines, incident/debug timelines, and repo-derived diagrams. Produces durable D2 (.d2) sources plus rendered SVG in docs/diagrams/, with quality linting (d2_doctor) and layout/style rules. For Otto Canvas scenes (a per-scene canvas.d2/canvas.mermaid/canvas.json edited over HTTP), use the otto-canvas skill instead.
Otto Canvas (Mermaid + Excalidraw + D2 modes) + Discovery Chat over HTTP
by itzikiusa
Use when drawing/generating a diagram for the Otto Canvas, creating or editing canvas scenes, or driving Discovery Chat on a Product story, from an agent session over HTTP. Covers the FILE-BACKED canvas model with THREE modes — Mermaid (edit a per-scene canvas.mermaid; any diagram type), Excalidraw (edit a per-scene canvas.json; fully editable shapes), and D2 (edit a per-scene canvas.d2; modern declarative diagrams — architecture, sequence, SQL tables) — top-notch pretty-Mermaid styling, the D2 shape/class syntax, the Excalidraw simplified element format, the OTTO_API_TOKEN auth model, the Canvas + Discovery-Chat endpoints, and the canvas.mjs helper.
Pull request
by itzikiusa
Use BEFORE opening or drafting ANY pull request — when asked to "open a PR", "create a pull request", "draft a PR", or to write a PR title/description. Covers summarizing the whole branch, the Jira key as title prefix (never in the body), GitHub vs Bitbucket creation, and the rule that a PR carries NO AI attribution.
Commit message
by itzikiusa
Use BEFORE writing or finalizing ANY git commit message — when staging changes, running git commit, or asked to "commit", "write a commit message", or "draft a commit". Covers Conventional Commits, the repo's emoji/scope convention, the Jira key, splitting mixed changes, and the rule that a commit carries NO AI attribution.
Security review
by itzikiusa
A focused, single-lens security review of a change. The one specialist a user runs alone when they care about exploitability — not a general sweep. Core method is taint tracing - follow untrusted input from its source, across the trust boundary, to a dangerous sink - and prove the path is reachable before calling it a finding. Covers injection (SQL/NoSQL/command/LDAP), XSS, SSRF, path traversal, insecure deserialization, authn/authz gaps (missing permission checks, IDOR), secret handling, sensitive-data exposure in logs/errors/URLs, crypto misuse, and unsafe defaults. Every finding cites file:line, a severity (a real exploit path is a blocker), the concrete attack, and a fix.
Test Review
by itzikiusa
A focused, single-lens review of test quality and coverage for a change — does the test actually exercise the new behavior AND its failure modes, or does it merely pass? Hunts happy-path-only coverage, weak assertions, tests that pass even when the code is wrong, over-mocking that tests the mock, missing negative/edge/error cases, flakiness, and tests coupled to implementation detail. Every finding asks "would this test fail if I broke the code?", cites file:line, a severity, why it matters, and the concrete missing case or stronger assertion.
Devex Review
by itzikiusa
A focused single-lens code review of developer experience and API ergonomics only — the quality of the interface a change exposes to other developers and callers. Judges "is this pleasant and safe to USE?": API/function/CLI shape (easy to use right, hard to use wrong), naming clarity, error messages that say what to do next, sensible defaults, discoverability, docs/examples for new public surface, and migration/onboarding friction. Every finding cites the surface (file:line), a severity, the friction or footgun it creates for the next developer, and a concrete improvement. It deliberately does NOT check correctness (that's grill) or internal structure (that's architecture-review).
Architecture Review
by itzikiusa
A focused, single-lens review of a change's design and structure — not its defects. Judges separation of concerns and SOLID, coupling and cohesion, module/layer boundaries and dependency direction, whether the right abstraction is present (and the wrong/early one is absent), files and functions that have grown too large or do too much, leaky abstractions, intent-hiding names, duplication that wants to be a shared unit, and whether the change fits how this codebase is already built. Every finding cites file/module:line, a severity, the future cost it imposes, and a concrete refactor direction. Constructive and pragmatic — flags structure that will cost future change, never taste.
Grill
by itzikiusa
A relentless, exhaustive, adversarial code review that hunts the smallest defects. Sweeps the change in multiple passes — correctness, edge cases, error handling, concurrency, resources, security, performance, contracts, types, tests, docs, and convention-consistency — then a final "what did I miss?" pass. Every finding cites file:line, a severity down to nits, why it matters, and a concrete fix. Evidence before assertion: trace and reproduce, never hand-wave.
Correctness Review
by itzikiusa
A focused single-lens code review that hunts correctness bugs only — logic errors, off-by-one, inverted conditions, broken invariants, wrong state transitions, null/None/nil mishandling, and the unhandled branch the author never ran. For each suspected bug it hand-traces (and reproduces where it can) before asserting, then reports it with file:line, severity, why-it-matters, and a concrete fix. Run it alone for a sharp pass, or compose it with security/performance/etc. — it deliberately does not duplicate grill's exhaustive all-lens sweep.
Performance review
by itzikiusa
A single-lens performance & scalability reviewer. Reasons about cost at scale — what a change does at 1 row vs 1M, 1 user vs 10k — and hunts the patterns that quietly turn linear into quadratic or one query into a thousand: N+1 and queries-in-loops, missing indexes / full scans, accidental O(n²), needless allocations/copies/serialization, re-fetching data already in hand, blocking I/O on a hot path, unbounded memory growth, chatty network calls, missing pagination/batching, and cache misuse. Every finding cites file:line, a severity, the cost model (when it bites), and a concrete fix. Distinguishes a real hot-path problem from a cold-path micro-optimization — and does not flag premature optimization.