jacob-balslev
- 206 skills
- 0 followers
- 9 hours ago last updated
- ▌ Graph Audit · jacob-balslev bundleUse when checking that SKILL.md files and audit-state.json sidecars conform to the live Skill Metadata Protocol schemas, that manifest entries match the joined source model, that relation targets point at real sibling skills, or that Skill Graph routing/audit claims are backed by the current deterministic gates. Covers schema conformance, sidecar consistency, manifest sync, protocol/schema parity, drift baselines, routing-eval honesty, relation metadata and target-existence ownership gaps, application-eval shape, eval-artifact coherence, corpus conformance-ledger signals, inline corpus-count hygiene, Markdown-link integrity, grounding presence, and name-directory parity. Do NOT use for general code review, runtime agent debugging, prose rewriting, body-section refactoring, new-skill scaffolding, or maintaining the health-tooling implementation itself.
- ▌ SEO Strategy · jacob-balslev bundleSEO implementation strategy for building pages that rank -- covering content strategy, programmatic SEO at scale, marketplace-specific SEO, and AI search optimization.
- ▌ Secrets Management · jacob-balslev bundleManaging the full lifecycle of sensitive credentials — API keys, database passwords, tokens, certificates, signing keys, and encryption keys — so they are never exposed in code, logs, images, or version history. Covers the secret lifecycle (generation, storage, distribution, use, rotation, revocation, audit), the cardinal rule of never hardcoding secrets, externalizing values out of source into a secrets manager or vault, encryption at rest and in transit, least-privilege scoping per consumer, short-lived dynamically-issued credentials over long-lived static ones, automated rotation and emergency revocation, workload identity (OIDC/SPIFFE) to eliminate standing credentials, environment-variable and .env pitfalls, secret scanning and leak detection in commits and CI, blast-radius containment when a secret leaks, and audit logging of secret access. Tool-agnostic across HashiCorp Vault, cloud secret managers, and KMS-backed stores.
- ▌ Caching Strategies · jacob-balslev bundleDeciding what to cache, where, and how to keep it coherent — trading freshness for speed and load reduction across the cache layers (client, CDN/edge, application in-memory, distributed cache, database). Covers the two hard problems (cache invalidation and choosing the layer), the write/read patterns (cache-aside/lazy, read-through, write-through, write-behind, refresh-ahead), expiry and TTL design, eviction policies (LRU/LFU/FIFO/TTL), staleness budgets and tolerated inconsistency, cache coherence and invalidation strategies (TTL expiry, explicit invalidation, key/tag versioning, write-through), the thundering-herd / cache-stampede problem and its mitigations (request coalescing, locks, jitter, stale-while-revalidate), HTTP caching semantics (Cache-Control, ETag, conditional requests, stale-while-revalidate/stale-if-error), CDN and edge caching, multi-layer cache hierarchies, cache key design and cardinality, negative caching, and measuring hit ratio and the cost of a miss. Stack-agnostic across Redis/Memcac
- ▌ Skill Evolution · jacob-balslev bundleUse when running or auditing Skill Graph's corpus-level `evolve` operation: the continuous skill-improvement loop that analyzes a skill library, triages a priority queue, executes bounded improve/scaffold/eval-generation actions, verifies the result, records checkpoints, and repeats. Covers `skill-graph evolve`, `lib/audit/skill-evolution-loop.js`, the Karpathy keep-or-revert spine, the priority signals based on Audit Status, standalone workspace flags, and the boundary between corpus walking and single-skill audit/improve/evaluate operations. Do NOT use for initial skill scaffolding alone (use skill-scaffold), single-skill schema/eval checks (use graph-audit or the audit operation), or generic evaluation rubric design (use evaluation / eval-driven-development).
- ▌ CI CD Pipelines · jacob-balslev bundleDesigning continuous integration and continuous delivery pipelines that turn every commit into a verified, releasable artifact and move it safely toward production. Covers the CI/CD distinction (integration vs delivery vs deployment), the pipeline as a staged graph of fast-to-slow gates, trunk-based integration and short-lived branches, build-once/promote-the-same-artifact discipline, hermetic and reproducible builds, dependency and layer caching for fast feedback, the test pyramid mapped onto pipeline stages, required status checks and branch protection, quality and security gates (lint, type-check, SAST, dependency/SCA scanning, license checks) as blocking vs advisory, artifact and container registries with immutable versioning and provenance, environment promotion (build → test → stage → prod), deployment strategies the pipeline triggers (blue-green, canary, rolling, feature-flag-gated), pipeline secrets and least-privilege CI credentials (OIDC over long-lived tokens), DORA delivery metrics (deployment fre
- ▌ Experimentation · jacob-balslev bundleDesigning, running, and interpreting controlled experiments to decide whether a change is genuinely better — online A/B tests, randomized controlled trials, and offline hypothesis tests. Covers hypothesis framing, randomization and unit-of-assignment, sample-size and statistical-power calculation, metric design (primary, guardrail, invariant, and the overall evaluation criterion), variance reduction (CUPED/CUPAC) for sensitivity, significance testing and confidence intervals, sequential and anytime-valid testing for the peeking problem, multiple-comparison correction, the trust checklist led by sample-ratio-mismatch, interference-aware designs (cluster and switchback), long-term holdouts and reverse experiments, bandit/adaptive-allocation boundaries, experiment ethics and blast-radius limits, quasi-experimental fallbacks when randomization is infeasible, and the validity threats that quietly invalidate results (novelty and primacy effects, interference/SUTVA violations, Simpson's paradox, and survivorship).
- ▌ Canonical Repo Structure · jacob-balslev bundleUse when organizing or cleaning a project/repository so every script, command, prompt, doc, generated artifact, compatibility shim, and legacy path has one canonical home under version control. Covers owner selection, repo-boundary verification, generated-vs-authored separation, duplicate implementation cleanup, compatibility-shim registration, delete-to-git-history discipline, timestamped changelog explanations, and path-limited commits in the owning repo. Do NOT use for ordinary branching/rebase/tag strategy alone (use `version-control`), behavior-preserving code restructuring alone (use `refactor`), documentation-sync routing alone (use `doc-updater`), or controlled category taxonomy design alone (use `taxonomy-design`).
- ▌ Skill Router · jacob-balslev bundleUse when routing an agent request across multiple skills, building or auditing a routing table, detecting routing coverage gaps, or answering questions like 'which skill handles this?', 'who routes X?', or 'why did skill A activate instead of B?'. Covers trigger-label matching, file-path matching, keyword matching, description-based semantic matching, project-fit filtering, relation-aware co-loading and exclusion, eval/staleness annotations, and coverage-gap detection. Do NOT use when the target skill is already known (load it directly), when authoring a new skill (use `skill-scaffold` instead), or when evaluating a SINGLE skill's quality (use `graph-audit`).
- ▌ Payment Provider Router · jacob-balslev bundleUse when dispatching a verified payment event (Stripe webhook or future provider) to the correct downstream handler based on event type. Routes `checkout.session.completed` to subscription provisioning, `invoice.payment_failed` to dunning logic, and `customer.subscription.deleted` to cancellation. Do NOT use for signature verification of the incoming event (use stripe-webhook-signature-verification first) or for the actual subscription database writes (use the per-handler skill or postgres-rls-pattern).
- ▌ Migrate Posts To V2 Frontmatter · jacob-balslev bundleUse when migrating every existing post in `content/posts/**/*.md` to the v2 frontmatter schema — adding the new required `summary` field, normalizing `tags` to the controlled vocabulary, converting bare-date `date` strings to ISO 8601 with timezone, and re-validating every post against the v2 schema before the next build runs. Activate this skill whenever the task references migration `0007-frontmatter-v2`, the v2 frontmatter rollout, or asks how to safely change a required-field set across a populated content tree without breaking the build. Do NOT use for unrelated migrations (use a generic content-migration skill or write a fresh one) or for general schema-design questions (use a schema-design skill).
- ▌ Nextjs Server Action Validation · jacob-balslev bundleUse when writing a Next.js Server Action that accepts user-submitted form data, mutation parameters, or any client-originated input. Every Server Action is a public HTTP endpoint regardless of how it is called — validate with Zod and check authentication as the first two operations before touching the database. Do NOT use for GET route handlers or Server Components that fetch data (those have no user-supplied input); do NOT use for Stripe webhook handlers (use stripe-webhook-signature-verification instead).
- ▌ Image Optimization Pipeline Config · jacob-balslev bundleUse when authoring or reviewing the build-time image pipeline config — defining responsive srcset breakpoints, picking output formats (AVIF / WebP / JPEG fallback), tuning compression quality per format, and ensuring the pipeline never produces a lossy artifact for source PNGs with transparency. Activate this skill whenever the task touches `lib/images/pipeline.config.ts`, `scripts/build-images.ts`, or any code path that resizes or recompresses content images. Do NOT use for runtime image rendering choices (use a frontend skill) or for chasing a specific build failure (use debugging).
- ▌ Migrate Orders To Canonical Schema · jacob-balslev bundleUse when running migration 0004 that normalizes the orders table from a Stripe-specific shape (stripe_session_id, stripe_customer_id as top-level columns) to a canonical provider-agnostic shape (provider, provider_order_id, provider_customer_id). Covers the four-phase safe migration procedure — add nullable columns, backfill from existing data, validate, drop legacy columns — and the RLS policy update that must accompany the column rename. Do NOT use for unrelated schema migrations (write a fresh skill anchored to that migration's number), for designing a new canonical schema from scratch, or for the ongoing orgQuery access pattern (use postgres-rls-pattern).
- ▌ Markdown Post Frontmatter Validation · jacob-balslev bundleUse when authoring or reviewing the frontmatter of a markdown post — checking required fields (title, date, slug, tags), validating against the content schema in `lib/content/schema.ts`, catching ambiguous date formats or tags not in the controlled vocabulary, and ensuring the slug matches the file path. Activate this skill whenever the task touches files under `content/posts/**/*.md`, the `parsePostFrontmatter()` helper, or any code path that reads YAML frontmatter from a content file. Do NOT use for general YAML schema design (use a generic schema-design skill) or for chasing a specific build-time validation failure (use debugging).
- ▌ Stripe Webhook Signature Verification · jacob-balslev bundleUse when validating incoming Stripe webhook requests in a Node.js or Next.js backend before processing any payment event. Verifies the `stripe-signature` header against `STRIPE_WEBHOOK_SECRET` using Stripe's HMAC-SHA256 scheme, and rejects replays older than 300 seconds. Do NOT use for general HTTP signature validation (use a generic crypto-signature skill), for processing the webhook payload after signature is confirmed (use payment-provider-router), or for Stripe API calls that are not webhook-driven.
- ▌ Comprehension Present Missing Understanding · jacob-balslev bundleNegative fixture for the gate-conformance suite: the audit-state sidecar declares `comprehension_state: present` but the SKILL.md omits the five flat Understanding fields. Activate only inside test-gate-conformance.js to prove the cross-file lint gate (comprehension_state -> Understanding fields) FAILS. Do NOT use as a production skill.
- ▌ Design Module Composition · jacob-balslevUse when designing reusable component modules — composition patterns, compound components, slot/children APIs, render props, headless component contracts, and the choice between configuration and composition. Do NOT use for application-level architecture, single-use feature components, or visual styling decisions. Do NOT use for Choose the border radius value for cards. Do NOT use for Decide where the OrderDetailPage component lives in the folder structure. Do NOT use for Pick the brand font for headings.
- ▌ First Principles Thinking · jacob-balslevUse when a problem is trapped inside inherited assumptions, copied convention, analogy, or local optimization and needs to be rebuilt from irreducible premises. Covers decomposition to primitives, assumption stripping, primitive tests, reconstruction from constraints, derivation chains, and reality checks. Do NOT use for root-cause analysis of an observed failure (use debugging or problem-locating-solving), formal argument grounding (use epistemic-grounding), domain entity modeling (use conceptual-modeling), or recurring issue clustering (use pattern-recognition). Do NOT use for This incident happened yesterday. Find the root cause. Do NOT use for Update the probability after new evidence arrives. Do NOT use for Score these options by expected monetary value. Do NOT use for Imagine this plan failed and list why.
- ▌ Visual Design Foundations · jacob-balslevUse when designing or auditing visual craft at foundation level: color palette, typography, spacing, elevation, rhythm, density, optical alignment, visual hierarchy direction, brand fit, contrast intent, and motion feel — making a surface more legible, polished, scannable, and tone-appropriate without changing its task structure. Do NOT use for sign-system meaning (use `semiotics`), token/component architecture (use `design-system-architecture`), responsive structure (use `layout-composition`), accessibility compliance (use `a11y`), or the DEEP contract of one dimension — formal color systems (use `color-system-design`), full type systems (use `typography-system`), deep hierarchy modeling (use `visual-hierarchy`), theming/token delivery (use `theme-system-design`), or interaction-state feedback (use `interaction-feedback`). Do NOT use for what does this icon or badge color communicate to users? Do NOT use for define semantic tokens and component variants.
- ▌ Data Modeling Fundamentals · jacob-balslevUse when reasoning about the theory beneath data modeling: Codd's relational model and algebra, normal forms from 1NF through 5NF/BCNF, functional dependencies and closure, Chen ER modeling, principled denormalization, relational-vs-document tradeoffs, and immutable-data alternatives such as event sourcing or append-only tables. Do NOT use for practical persistence design (use entity-relationship-modeling), applying schema changes (use schema-evolution), index choices (use indexing-strategy), or conceptual modeling above the data model (use conceptual-modeling).
- ▌ Design System Architecture · jacob-balslevUse when designing or auditing a design system's architecture: token taxonomy, semantic tokens, component APIs, theming, accessibility contracts, documentation, governance, and migration strategy. Do NOT use for information hierarchy and navigation (use `information-architecture`), page-specific layout (use `layout-composition`), visual craft direction (use `visual-design-foundations`), sentence-level UI copy (use `microcopy`), or accessibility-only audits (use `a11y`). Do NOT use for organize pages, nav, sitemap, and wayfinding. Do NOT use for rewrite the empty-state text and tooltip labels. Do NOT use for add aria-labels and keyboard behavior to this component. Do NOT use for draft an architecture note explaining why we chose Postgres over DynamoDB.
- ▌ System Interface Contracts · jacob-balslevUse when defining or reviewing contracts between systems, modules, services, agents, jobs, events, APIs, or teams: ownership, inputs, outputs, invariants, compatibility, errors, idempotency, and versioning. Do NOT use for REST resource design alone (use `api-design`), async event contract detail (use `event-contract-design`), database schemas (use `entity-relationship-modeling`), or post-failure debugging (use `debugging`). Do NOT use for design the REST endpoints, status codes, and pagination. Do NOT use for create database tables and constraints. Do NOT use for investigate why this existing integration is failing in production. Do NOT use for write an ADR after the interface decision has already been accepted.
- ▌ Vercel Composition Patterns · jacob-balslevUse when refactoring React components with boolean-prop proliferation, designing flexible component APIs, building reusable component libraries, or reviewing component architecture — compound components, explicit variant components, children-over-render-props, the context provider state/actions/meta interface, boolean state-explosion auditing, and the React 19 API migration (ref-as-prop, use() over useContext()). Do NOT use for render performance optimization (memoization, suspense, profiling), visual styling, or Next.js routing/server-component framework patterns. Do NOT use for Memoize this component tree to stop re-renders. Do NOT use for Style this card with the brand spacing and color tokens. Do NOT use for Set up the App Router route and a server component for this page.
- ▌ Entity Relationship Modeling · jacob-balslevUse when designing database tables, reviewing schema changes, planning migrations, or translating conceptual models into physical database structures. Covers ER notation, entity/attribute/key design, normalization and denormalization, junction tables, inheritance mapping, temporal modeling, ER-to-SQL translation, indexing, and constraints. Do NOT use for conceptual domain analysis (use `conceptual-modeling`), formal ontology (use `ontology`), or cross-system API contracts (use `system-interface-contracts`).
- ▌ Architecture Decision Records · jacob-balslevUse when writing, reviewing, or updating Architecture Decision Records: context, decision, options rejected, consequences, status, supersession, and follow-up verification. Do NOT use for general documentation prose (use `documentation`), code review findings (use `code-review`), or choosing between frameworks before a decision exists (use `framework-fit-analysis`). Do NOT use for write a general README section explaining how this module works. Do NOT use for choose which framework we should use for this project. Do NOT use for review this PR for bugs and regressions. Do NOT use for design the interface contract between these two services.
- ▌ Missing Scope · jacob-balslevNegative fixture for the gate-conformance suite: identical to the minimal valid fixture except the required `scope` field is omitted. Activate only inside test-gate-conformance.js to prove the structural lint gate FAILS when a required protocol field is absent. Do NOT use as a production skill.
- ▌ Invalid Sidecar · jacob-balslev bundleNegative fixture for the gate-conformance suite: the SKILL.md frontmatter is fully valid, but the sibling audit-state.json sidecar is missing the required `owner` field. Activate only inside test-gate-conformance.js to prove the structural lint gate validates the sidecar against schemas/skill-audit-state.schema.json. Do NOT use as a production skill.
- ▌ Invalid Subject · jacob-balslevNegative fixture for the gate-conformance suite: valid v8 frontmatter except `subject` is set to a value outside the closed twelve-shelf enum. Activate only inside test-gate-conformance.js to prove the structural lint gate FAILS on an out-of-enum subject. Do NOT use as a production skill.
- ▌ Truth Source Broken · jacob-balslevNegative fixture for the gate-conformance suite: valid v8 frontmatter with a complete grounding block, except one declared truth source path points at a file that does not exist. Activate only inside test-gate-conformance.js to prove the truth/drift gate reports BROKEN. Do NOT use as a production skill.
- ▌ Dangling Verify With · jacob-balslevNegative fixture for the gate-conformance suite: valid v8 frontmatter except `relations.verify_with` points at a skill that does not exist. Activate only inside test-gate-conformance.js to prove the structural lint gate FAILS on a dangling relation target. Do NOT use as a production skill.
- ▌ Link Rot Detection · jacob-balslev bundleUse when authoring or reviewing a periodic-scan job that walks every external link in a markdown content set and flags 404s, redirects to unrelated content, and connection failures. Activate this skill whenever the task says 'check our links' or mentions a link-rot scan, broken-link audit, or link-health report. Do NOT use for live runtime link checking inside the rendered page (use a frontend a11y / UX skill) or for chasing a specific broken-link incident from a user report (use debugging).
- ▌ Postgres Rls Pattern · jacob-balslev bundleUse when writing or reviewing Postgres queries in a multi-tenant SaaS where every table row must be scoped to a single organization. Enforces the FORCE ROW LEVEL SECURITY + USING + WITH CHECK triple on every tenant-bound table, and wraps application queries in an `orgQuery(orgId)` helper that sets `app.current_org_id` before each statement. Do NOT use for cross-org system queries such as billing cron jobs or admin panels (those bypass RLS intentionally via the service role); use a service-role query wrapper instead.
- ▌ Missing Audit Status Verdicts · jacob-balslev bundleWarning fixture for the gate-conformance suite: the sidecar is schema-valid but omits the four durable Audit Status verdict fields. Activate only inside test-gate-conformance.js to prove lint warns without failing. Do NOT use as a production skill.
- ▌ Content Source Router · jacob-balslev bundleUse when dispatching a content-fetch task across the multiple sources the site reads from — local markdown under `content/`, MDX with React components under `content/mdx/`, and a headless-CMS sync under `lib/cms/`. Activate this skill whenever the task says 'render this content' or 'where does this post come from' without naming a specific source, or when adding a new source to the routing surface. Do NOT use for the actual rendering of one source (use the per-source skill — `markdown-post-frontmatter-validation`, an MDX rendering skill, or a CMS-sync skill) or for chasing a specific routing bug (use debugging).
- ▌ Task Path Optimization · jacob-balslevThis skill provides decision frameworks for choosing the optimal execution path before starting work: plan-vs-act gates, agent architecture selection (chaining, routing, parallelization, orchestrator-worker, evaluator-optimizer), scope management heuristics, critical-path analysis across task networks, and context budget awareness. Use when deciding how to approach a task (plan first vs act immediately), decomposing complex work into parallelizable subtasks, choosing between subagent patterns, or when a task has failed twice and needs a fresh approach. Do NOT use for executing the chosen plan (use task-execution), debugging failures (use troubleshooting or diagnosis), or tool-level efficiency (use tool-call-strategy). Do NOT use for reduce the number of tool calls in this read-heavy step. Do NOT use for troubleshoot why the deployment keeps timing out. Do NOT use for execute the implementation plan we already agreed on.
- ▌ Test Coverage Strategy · jacob-balslevUse when reasoning about code coverage as a strategic measurement rather than a quality target: structural reach versus behavioral verification (covered vs tested), the coverage-criterion hierarchy (function, line, branch, decision, condition, MC/DC, path) and matching the criterion to where a module's failure modes hide, Marick's floor-vs-ceiling distinction, Goodhart's Law applied to coverage and Goodhart-resistant policy (diagnostic use, diff/patch floors, risk-weighting, behavioral panels), denominator hygiene and cross-tool counter semantics, safety-critical MC/DC (DO-178C Level A required; ISO 26262 ASIL-D highly recommended) as requirements-based evidence, and interpreting coverage from AI-generated tests. Do NOT use for choosing test levels (use testing-strategy), mutation testing as a behavioral signal (use mutation-testing), test-double construction (use test-doubles-design), LLM eval iteration (use eval-driven-development), or specific coverage-tooling configuration (tool docs).
- ▌ Comprehension Full · jacob-balslev bundleUse as the v8-conformant fixture exercising the full Understanding surface — the five flat top-level fields (mental_model, purpose, concept_boundary, analogy, misconception) in SKILL.md frontmatter, paired with comprehension_state: present in the audit-state.json sidecar. Activate this skill when verifying that the cross-file lint accepts the flat Understanding fields when the sidecar declares comprehension_state: present. Do NOT use as a production skill (use a real capability skill from the canonical library).
- ▌ Minimal Capability · jacob-balslev bundleUse as the smallest v8-compat capability fixture for skill-graph package tests. Activate this skill when verifying that lint, manifest generation, and routing accept the bare-minimum required frontmatter. Do NOT use as a production skill (use a real capability skill from the canonical library).
- ▌ Dependency Architecture · jacob-balslevUse when designing or auditing dependency structure: package boundaries, runtime vs build dependencies, adapter layers, duplicate-purpose libraries, supply-chain risk, upgrade policy, lock-in, and dependency graph health. Do NOT use for choosing a major framework (use `framework-fit-analysis`), vulnerability-only review (use `owasp-security`), or routine refactoring without dependency boundary changes (use `refactor`). Do NOT use for choose between Next.js, Remix, and Astro for a new app. Do NOT use for scan dependencies only for known vulnerabilities. Do NOT use for refactor this module without changing dependency boundaries. Do NOT use for write an ADR after the dependency decision is accepted.
- ▌ Integration Test Design · jacob-balslevUse when designing tests that verify the interaction between two or more units of a system — modules, services, layers, processes: the scope-and-boundary primitives that distinguish integration from unit and e2e tests, the test-pyramid (Cohn 2009) and test-trophy (Dodds) frameworks for how much integration testing belongs in the suite, the real-vs-faked-collaborator decision per dependency, the test-data lifecycle (per-test setup, transaction rollback, container reset), the difference between sociable-unit tests, integration tests, and contract tests, and the failure modes (over-broad scope that mimics e2e, over-narrow scope that mimics unit, shared mutable state that produces flakes). Do NOT use for testing one unit in isolation (use testing-strategy + test-doubles-design), full user-journey testing (use e2e-test-design), consumer-driven contract verification (use contract-testing), or test-suite quality measurement (use mutation-testing).
- ▌ Performance Engineering · jacob-balslevUse when measuring, diagnosing, budgeting, or improving performance: latency, throughput, Core Web Vitals, database queries, caching, bundle size, concurrency, resource use, and regression prevention. Do NOT use for telemetry schema design alone (use `observability-modeling`), error capture setup (use `error-tracking`), or premature micro-optimization without a measured bottleneck. Do NOT use for design logs, spans, metrics, and correlation IDs before implementation. Do NOT use for set up Sentry and error redaction. Do NOT use for make random micro-optimizations without measurements. Do NOT use for write general unit tests for this feature.
- ▌ Problem Approach Router · jacob-balslevUse when facing a new problem and unsure which problem-solving methodology or foundational skill to apply first. Routes between first-principles-thinking, pattern-recognition, mental-models, constraint-awareness, and task-analysis by classifying the problem type. Activate before choosing any other foundational skill. Do NOT use to execute the selected approach (use the specific routed skill directly), for implementation work (use the relevant engineering skill), or when the correct approach is already known. Do NOT use for actually apply first-principles thinking to this specific problem. Do NOT use for analyze why this pattern keeps recurring in the codebase. Do NOT use for break down the constraints on this engineering decision. Do NOT use for map the mental model for this domain concept. Do NOT use for implement the algorithm we already decided on. Do NOT use for choose a testing strategy for this feature.
- ▌ Spec Driven Development · jacob-balslevUse when starting a non-trivial feature, refactor, or agent implementation that needs a written spec, plan, task breakdown, and verification path before code changes. Covers Spec Kit-style SDD phases, requirements-vs-plan separation, task traceability, review gates, and spec-compliance verification. Do NOT use for one-line edits, README-only fixes, post-implementation code review (use `code-review`), or test-level decisions (use `testing-strategy`).
- ▌ Test Driven Development · jacob-balslevUse when reasoning about Test-Driven Development as a design discipline rather than a workflow: the red-green-refactor cycle as a feedback loop, the difference between London-school (outside-in, interaction-heavy, mock-driven) and Detroit-school (inside-out, state-heavy, classicist) TDD, the role of TDD as a design tool (how tests pressure code into more decomposable shapes), the connection between TDD and emergent design, the boundary between TDD and prior-test-suites, why TDD's failure mode is not 'no tests' but 'tests that mirror implementation', and the empirical record of TDD's effects on defect density, design quality, and development velocity. Do NOT use for the strategy of what to test at which level (use testing-strategy), the construction of test doubles (use test-doubles-design), the discipline of LLM eval iteration (use eval-driven-development), or general-software process workflow (use the obra/superpowers test-driven-development workflow skill — this skill is the concept-shape complement).
- ▌ Autonomous Loop Patterns · jacob-balslevUse when designing, reviewing, or debugging an autonomous AI agent loop: repeated agent execution, completion signals, checkpoints, supervisor respawn, stall detection, safety caps, and human handoff rules. Covers the core loop patterns from simple bounded runs through sentinel-based continuation, checkpoint-resume, and external supervisor loops. Do NOT use for choosing a specific agent product command (use agent-engineering or the product's docs), writing ordinary task instructions (use prompt-craft), or optimizing individual tool calls (use tool-call-strategy).
- ▌ Dark Mode Implementation · jacob-balslevUse when implementing dark mode — prefers-color-scheme detection, theme persistence, flash-of-unstyled-theme prevention, color token mirroring, image and asset variants, and meta theme-color updates. Do NOT use for designing the dark palette itself, designing the token architecture, or generic theme-switching across more than two themes. Do NOT use for Pick the dark mode color palette values. Do NOT use for Design the three-tier token architecture. Do NOT use for Build a multi-brand theme system with five themes.
- ▌ Information Architecture · jacob-balslevUse when structuring information for findability: navigation, page hierarchy, docs architecture, sitemap shape, labeling systems, wayfinding, and content grouping. Do NOT use for formal category-governance work (use `taxonomy-design`), responsive page composition (use `layout-composition`), component/token architecture (use `design-system-architecture`), or sentence-level UI text (use `microcopy`). Do NOT use for make the category taxonomy and assignment rules for this skill library. Do NOT use for define design tokens, component APIs, and theming rules. Do NOT use for rewrite this tooltip and empty-state copy. Do NOT use for audit keyboard accessibility and ARIA semantics. Do NOT use for structure inside a page or screen (use layout-composition). Do NOT use for sentence-level UI text (use microcopy).
- ▌ Problem Locating Solving · jacob-balslevUse when locating a bug in an unfamiliar codebase, tracing a failure from symptom to source, or choosing between candidate fixes after the symptom is observed but before a patch lands. Covers the locate-to-solve workflow: problem-statement contract, search-space reduction, boundary-based fault localization, good-vs-bad path comparison, binary search through a call chain, minimal repro, root-cause isolation, fix option comparison, blast-radius review, and post-fix verification. Do NOT use for broad task planning once the bug is localized, test-pyramid design, or performance forensics. Do NOT use for plan the next 6 weeks of work for the team. Do NOT use for review this PR for code quality. Do NOT use for this endpoint is slow under load — find the bottleneck. Do NOT use for scan this repo for OWASP top 10 vulnerabilities. Do NOT use for run scientific-method debugging on this stack trace. Do NOT use for I see the symptom but cannot find the root cause of this nil panic.
- ▌ Prompt Injection Defense · jacob-balslevUse when reasoning about systems that pass untrusted content to a language model: the data-vs-instruction collapse that makes this attack class a structural property of LLMs rather than a fixable bug, the direct/indirect/exfiltration/action-trigger taxonomy, the role of every untrusted surface (RAG retrievals, tool results, attachments, web content, document parsing, user-provided text), why content filters and improved system prompts do not solve it, and the defense-in-depth measures that do (capability constraint, content origin tracking, separate planning and execution stages, human-in-the-loop gates, principle-of-least-authority for tools). Do NOT use for model refusal policy or jailbreak evals (use `guardrails` or `eval-driven-development`), for general application security (use `owasp-security` or `security-fundamentals`), for runtime input validation patterns (use `type-safety` + `api-design`), or for the protocol cycle of tool calls (use `tool-call-flow`).
- ▌ Server Components Design · jacob-balslevUse when designing or reviewing React Server Components: what an RSC can do (async, data fetching, server-only imports) versus what it cannot (state, effects, event handlers, browser APIs), where to draw the server/client boundary in the tree, how to keep private data from leaking across that boundary, and how RSC composes with Suspense to stream content without a separate API layer. Covers Next.js App Router as the canonical implementation, but the discipline is framework-agnostic. Do NOT use for the 'use client' directive mechanics (use client-server-boundary), hook discipline on Client Components (use hooks-patterns), rendering strategy choice (use rendering-models), the server-action mutation surface (use server-actions-design), or the wider Suspense discipline (use suspense-patterns). Do NOT use for add a click handler to an existing component (use hooks-patterns and client-server-boundary). Do NOT use for design the public API for a third-party integration (use api-design).
- ▌ AI Native Development · jacob-balslevUse when reasoning about agent autonomy levels, designing auto-improve loops, evaluating AI-generated code quality, or measuring agent productivity in an LLM-assisted codebase. Covers Karpathy's three eras of software (1.0 explicit / 2.0 learned / 3.0 natural-language), the vibe-coding-vs-agentic-engineering distinction, the 0–5 autonomy slider with task-type recommendations, the one-asset / one-metric / one-time-box AutoResearch loop, Software 3.0 productivity metrics, and the documented quality regressions of ungated AI-generated code (the 'vibe hangover'). Do NOT use for choosing a specific autonomy-loop topology (use `agent-engineering`), for the per-prompt authoring discipline (use `prompt-craft`), or for reviewing the AI-generated code that comes out of a Software 3.0 workflow (use `code-review`). Do NOT use for improve this specific prompt for the grader. Do NOT use for review this AI-generated PR for correctness. Do NOT use for design the checkpoint state machine for our loop.
- ▌ Cap Theorem Tradeoffs · jacob-balslevUse when reasoning about the consistency-availability-partition-tolerance trade-off for distributed data systems: Brewer's CAP conjecture (2000), Gilbert & Lynch's 2002 formal proof, why P is not optional in any real distributed system, the CP-vs-AP dichotomy that follows, PACELC as the extension that names the latency-vs-consistency trade-off that exists even without partition, the relationship between CAP's C and ACID's C (different concepts with the same letter), and the choice procedure of naming what the system must guarantee under partition. Do NOT use for single-node transactional guarantees (use transaction-isolation), choosing an isolation level (use transaction-isolation), the design of replication topologies (use replication-patterns), or sharding decisions (use sharding-strategy).
- ▌ Cognitive Load Theory · jacob-balslev bundleSweller's Cognitive Load Theory (CLT) for agents reviewing skill bodies, prompts, docs, dashboards, and agent outputs for avoidable cognitive burden. Working memory holds ~4 chunks; CLT splits load into intrinsic (irreducible difficulty), extraneous (avoidable load from poor presentation — ELIMINATE), and germane (the schema-building work applied to intrinsic load — PROTECT). Use when writing a SKILL.md body, designing prompts (am I asking the model to hold too much at once?), building dashboards (per-screen cognitive budget), authoring docs (is intrinsic load segmented?), or checking whether modern features (long context, structured outputs, prompt caching, subagents) actually reduce load or just move it. Do NOT use for retrieval/session working-set design (use context-management), token budget and compaction timing (use context-window), prompt engineering tactics (use prompt-craft), or token-efficient representation (use compression).
- ▌ Event Contract Design · jacob-balslevUse when designing or reviewing asynchronous event contracts: producer/consumer ownership, event envelope, schema, topic/channel naming, ordering, idempotency, versioning, compatibility, replay, dead-letter behavior, and AsyncAPI/CloudEvents-style documentation. Do NOT use for domain-event discovery (use `event-storming`), broad interface contracts (use `system-interface-contracts`), inbound provider webhook mechanics (use `webhook-integration`), or HTTP endpoint design (use `api-design`). Do NOT use for discover the domain events, commands, and policies in this business process. Do NOT use for define every boundary contract between services, jobs, and APIs. Do NOT use for verify inbound provider webhook signatures and retry behavior. Do NOT use for design REST endpoints, status codes, and pagination.
- ▌ Frontend Architecture · jacob-balslevUse when organizing a frontend codebase — module boundaries, component layering, state ownership, data-flow direction, and the separation between feature code and shared primitives. Do NOT use for visual design decisions, specific framework migration tactics, or backend API contract design. Do NOT use for Pick the brand color palette for a marketing site. Do NOT use for Design the REST endpoint shape for the orders resource. Do NOT use for Decide whether to use CSS-in-JS or Tailwind.
- ▌ Second Order Thinking · jacob-balslevUse when a decision, intervention, policy, product change, metric target, or system fix needs analysis beyond the immediate effect: ask what happens next, how actors respond, what incentives change, and what delayed or compounding consequences follow. Covers consequence chains, time horizons, stakeholder reactions, feedback loops, second- and third-order effects, and guardrail design. Do NOT use for reversing a goal to find failure paths (use inversion), decomposing assumptions to primitives (use first-principles-thinking), recurring issue clustering (use pattern-recognition), or system leverage-level diagnosis (use meadows-leverage-points when available). Do NOT use for Invert this plan and list how to make it fail. Do NOT use for Break this strategy into irreducible premises. Do NOT use for The same issue appears in many files; cluster the pattern. Do NOT use for Find the highest leverage point in this system.
- ▌ Security Fundamentals · jacob-balslevUse when reasoning about baseline application-security properties: threat modeling, trust boundaries, Saltzer and Schroeder design principles, input validation, authentication vs authorization, secrets handling, secure-by-default choices, least privilege, defense in depth, and OWASP vulnerability classes as recurring failure modes. Covers cross-cutting decisions about what is trusted, where validation belongs, where authn/authz checks live, and how to bound blast radius. Do NOT use for LLM-specific prompt injection or agent-tool authority (use prompt-injection-defense), OWASP-category deep code review (use owasp-security), vendor webhook mechanics (use webhook-integration), cryptographic primitive implementation or key-management mechanics (use vendor/KMS/library docs), compliance/legal artifacts, or the social/organizational side of security. Do NOT use for configure a specific SAST or dependency scanner (use the scanner docs, then owasp-security for review).
- ▌ Server Actions Design · jacob-balslevUse when designing or reviewing React Server Functions / Next.js Server Actions for mutations: the 'use server' directive, function-to-POST endpoint semantics, form integration through action/formAction, React useActionState and useFormStatus, progressive enhancement, server-side validation, authentication, authorization, rate limiting, cache revalidation, redirect/refresh/updateTag behavior, bound arguments, and the security boundary that makes actions public HTTP endpoints despite function-like syntax. Covers Next.js App Router as the canonical implementation. Do NOT use for read-path data fetching with React Server Components (use server-components-design), broader serialization/directive mechanics (use client-server-boundary), externally consumed API contracts (use api-design), or form visual/interaction UX (use form-ux-architecture). Do NOT use for choose between SSR and SSG (use rendering-models). Do NOT use for debug React hook dependency arrays in a client form (use hooks-patterns).
- ▌ Transaction Isolation · jacob-balslevUse when reasoning about the I in ACID: the isolation level a database provides between concurrent transactions; the four SQL-standard levels plus practical snapshot/read-versioning modes; the anomalies each level can admit or prevent; the Berenson/Adya critique of label-based isolation; locking, MVCC, row-versioning, SSI, key-range/gap/predicate locks, RCSI, and distributed-SQL serializable/external-consistency defaults; and how to choose isolation per workload by naming the anomalies, invariants, retry contract, and engine-specific behavior. Do NOT use for the broader ACID frame (outside this active skill corpus), distributed-replica consistency or CAP/PACELC choices (use cap-theorem-tradeoffs and replication-patterns), query performance tuning (use query-optimization), durable index design (use indexing-strategy), or schema design (use entity-relationship-modeling). Do NOT use for explain the four ACID properties (outside this active skill corpus).
- ▌ Client Server Boundary · jacob-balslevUse when reasoning about the line where execution context changes between server runtime and client runtime: what values can cross via the active serializer, what cannot, how `'use client'`, `'use server'`, guard imports, and server-only file conventions mark module/function transitions, how React Server Components differ from server-rendered HTML, why Server Functions / Server Actions are reachable network endpoints, why client input is adversarial, and how server-only modules, secrets, raw records, or closures leak into client bundles and payloads. Do NOT use for choosing when and where UI is produced (use rendering-models), full Server Component read-path placement (use server-components-design), full Server Action mutation/form/cache design (use server-actions-design), public Route Handler endpoint design (use route-handler-design), HTTP wire semantics (use http-semantics), frontend codebase organization (use frontend-architecture), or API JSON contract design (use api-design).
- ▌ Component Architecture · jacob-balslevThe architectural discipline of structuring a UI component library — layering, API surface design, headless/styled split, and state contracts — so component APIs survive reuse across products, themes, and teams. Do NOT use for design the typography system: type scale, font pairing, text sizes, and reading rhythm. Do NOT use for define the form validation, error messaging, submit behavior, and field grouping for checkout. Do NOT use for decide where component state lives across the app and which components own the app state. Do NOT use for how a single product's modules compose internally (use design-module-composition). Do NOT use for palette, token, contrast, and semantic color decisions (use color-system-design). Do NOT use for type scale, font pairing, rhythm, and text hierarchy (use typography-system). Do NOT use for form validation, submission, grouping, and error experience (use form-ux-architecture). Do NOT use for the visual language itself (use visual-design-foundations).
- ▌ Framework Fit Analysis · jacob-balslevUse when choosing, replacing, or justifying a framework, library, SDK, runtime, database, UI kit, agent tool, or platform by fit: constraints, quality attributes, team skill, evidence, ecosystem maturity, maintenance health, migration cost, operability, performance, security, supply-chain posture, AI/codegen readiness, lock-in, reversibility, and exit cost. Do NOT use for routine dependency hygiene (use `dependency-architecture`), documenting an accepted decision (use `architecture-decision-records`), or framework-specific implementation work. Do NOT use for audit installed packages for duplication and supply-chain risk. Do NOT use for write the ADR after we chose the framework. Do NOT use for implement this feature in the framework we already selected. Do NOT use for profile a slow page and optimize bottlenecks. Do NOT use for design the full production lifecycle of a multi-agent system after the platform is chosen.
- ▌ Observability Modeling · jacob-balslevUse when designing telemetry semantics before or during implementation: logs, metrics, traces, events, spans, attributes, correlation IDs, SLOs, alert signals, and diagnostic questions. Do NOT use for domain/business event contracts (use `event-contract-design`), configuring an error tracker alone (use `error-tracking`), performance optimization (use `performance-engineering`), or debugging a current incident (use `debugging`). Do NOT use for set up Sentry error tracking for this app. Do NOT use for profile and optimize a slow endpoint. Do NOT use for debug the current production incident. Do NOT use for write application tests for this feature.
- ▌ Principled Negotiation · jacob-balslevUse when preparing, structuring, or pressure-testing a negotiation with principled negotiation / BATNA: separate people from the problem, focus on interests rather than positions, invent options for mutual gain, use objective criteria, define BATNA / reservation value / ZOPA, and decide whether to accept, improve, or walk away. Do NOT use for generic persuasion copy (use microcopy or writing-humanizer), unilateral conflict diagnosis without a deal table, competitive strategy analysis (use playing-to-win, porters-five-forces, or seven-powers), or broad decision scoring without counterparties (use expected-value or prioritization). Do NOT use for Write persuasive landing-page copy for this offer. Do NOT use for Analyze rivalry, supplier power, buyer power, entrants, and substitutes. Do NOT use for Choose our winning aspiration, where to play, and how to win. Do NOT use for Rank these initiatives by expected value and downside risk. Do NOT use for Give legal advice on whether this contract clause is enforceable.
- ▌ Property Based Testing · jacob-balslevUse when reasoning about tests that specify universal properties of code rather than specific input-output pairs: the forall(input) → property quantification, the generator/shrinker primitives that produce inputs and minimize failing cases, the four-rules-of-simple-design analog (commutativity, associativity, idempotence, round-trip, oracle, invariant), the difference between example-based tests (one input, one assertion) and property-based tests (many generated inputs, one universal claim), why property tests find bugs example tests don't, the shrinking discipline that produces minimal failing cases, and the trade-off between generator complexity and bug-finding capacity. Do NOT use for specifying one concrete behavior with one input (use example-based tests under testing-strategy), for fuzz-testing focused on crashes (use fuzz-testing), for mutation testing as a test-suite quality signal (use mutation-testing), or for model-based testing of state machines (use state-machine-modeling).
- ▌ State Machine Modeling · jacob-balslevUse when modeling lifecycle states, transitions, guards, events, side effects, invalid states, retries, statecharts, and state invariants for workflows or domain objects. Do NOT use for broad event discovery (use `event-storming`), database schema design (use `entity-relationship-modeling`), frontend state-location decisions (use `state-management`), or observability instrumentation after the lifecycle already exists (use `observability-modeling`). Do NOT use for discover the domain events and policies for the whole business process. Do NOT use for create database tables and constraints for this lifecycle. Do NOT use for decide whether this React form state should live in the URL, context, or a global store. Do NOT use for instrument metrics and traces for an existing workflow. Do NOT use for debug why this job got stuck yesterday.
- ▌ Streaming Architecture · jacob-balslevUse when reasoning about systems that emit a sequence of values over time and consume them incrementally: the producer/stream/consumer/backpressure/termination primitives, the difference between streaming and request-response, the difference between streaming and pub-sub messaging, how WHATWG Streams, Server-Sent Events, HTTP chunked transfer, WebSockets, gRPC streaming, and React Server Component streaming compose, push vs pull backpressure, and the failure modes (slow consumer, abandoned consumer, partial-result correctness). Do NOT use for the message-history protocol between a model and a tool runtime (use tool-call-flow), browser freshness or live dashboard UX transport choice (use real-time-updates), single-response API design (use api-design), durable worker execution and retry semantics (use background-jobs), or event payload/domain-event contracts (use event-contract-design). Do NOT use for design the JSON shape and status codes for a single request-response API payload.
- ▌ Pattern Recognition · jacob-balslevUse when auditing for recurring issues, clustering errors, detecting drift from conventions, or when an agent keeps fixing symptoms instead of root causes. Covers the Observe -> Cluster -> Name -> Codify -> Detect -> Prevent loop, grep-based audits, normalize-then-hash error clustering, board-health patterns, design-token and heading drift, domain-encoding patterns, eval-as-pattern-tests, 5 Whys, pattern lifecycle states, and drift traps. Do NOT use for one-off bug localization without recurrence, or for designing the classification system itself; this skill detects violations of conventions that already exist. Do NOT use for review this code for semantic correctness. Do NOT use for find where the user-auth helper is defined. Do NOT use for design a MECE classification taxonomy for our error catalogue. Do NOT use for investigate why this single failing test is breaking. Do NOT use for trigger an alert when CPU exceeds 80% for 5 minutes. Do NOT use for rewrite this function to be cleaner.
- ▌ Performance Budgets · jacob-balslevUse when declaring, measuring, or enforcing performance thresholds as a quality contract rather than as an aspirational target. Covers the three budget axes (time, size, count), the four governing properties of a real budget (metric, threshold, percentile, consequence), the Core Web Vitals set (LCP, INP, CLS), the RAIL model, Lighthouse budgets.json, lab vs field measurement, and the discipline of treating budget breach as a build or deploy failure rather than a tracked metric. Do NOT use for the activity of profiling and optimizing a specific slow path (use performance-engineering), the choice of rendering model that bounds achievable budgets (use rendering-models), or the design of observability and telemetry signals (use observability-modeling).
- ▌ Performance Testing · jacob-balslevUse when measuring a system's non-functional properties — latency, throughput, error rate, resource utilization, saturation — by running it under controlled load and verifying against explicit SLO thresholds. Covers the five primitives (load profile, workload, latency metric, throughput metric, SLO target), load-shape taxonomy (smoke, load, stress, spike, soak, breakpoint), latency-percentile vocabulary (p50, p95, p99, p99.9), why average latency and coordinated omission mislead, tool selection (k6, JMeter, Locust, Gatling, Vegeta), and offline controlled measurement versus production observability. Do NOT use for optimization itself (use `performance-engineering`), threshold contracts (use `performance-budgets`), production runtime measurement (use `observability-modeling` or `error-tracking`), single-function microbenchmarks, fault injection, or test-suite quality measurement (use `mutation-testing`). Do NOT use for decide which modules need more unit tests and what test coverage target to enforce.
- ▌ Porters Five Forces · jacob-balslevUse when analyzing an industry's competitive structure and profit pool using Porter's Five Forces: rivalry among existing competitors, threat of new entrants, bargaining power of suppliers, bargaining power of buyers, and threat of substitutes. Covers industry-boundary definition, force-by-force diagnostics, structural drivers, dynamic trends, profitability implications, strategic positioning options, and the distinction between industry attractiveness and firm-specific advantage. Do NOT use for creating an integrated strategy cascade (use playing-to-win), classifying durable moat sources (use Seven Powers when available), backlog scoring (use prioritization), or generic market sizing. Do NOT use for turn this vague product strategy into where-to-play and how-to-win choices. Do NOT use for rank these roadmap items by expected impact. Do NOT use for estimate the TAM for this market. Do NOT use for classify this company's durable moat source. Do NOT use for write OKRs for the chosen strategy.
- ▌ Test Doubles Design · jacob-balslevUse when designing or reviewing test doubles — the stand-in objects that replace real collaborators in a test: the five-kind taxonomy (dummy, stub, spy, fake, mock) from Meszaros's xUnit Test Patterns, the difference between state verification (Detroit-school, classicist) and interaction verification (London-school, mockist) and how it determines which doubles fit, the cost of doubles (fragility, false confidence, divergence from real behavior), the role of fakes as the under-used middle ground, the verify_with relationship to test-driven-development, and the heuristics for when to use a real collaborator instead of any double. Do NOT use for choosing test levels or what to test (use testing-strategy), the design discipline of writing tests first (use test-driven-development), specific mocking-library API choice (library docs), or general production stubs and feature flags (use feature-gating or domain-specific skills). Do NOT use for set up a production feature flag (use feature-gating).
- ▌ Theme System Design · jacob-balslevUse when designing a theme system — design tokens, semantic token layering, CSS custom property strategy, runtime theme switching, and theme contract guarantees. Do NOT use for one-off color choices, brand-only palette work, or framework-specific styling-library configuration. Do NOT use for Choose the exact hex value for the brand's primary blue. Do NOT use for Configure Tailwind's content array and purge settings. Do NOT use for Implement the dark mode toggle interaction.
- ▌ Webhook Integration · jacob-balslevUse when implementing or reviewing an inbound webhook handler for any third-party provider - verifying signatures, deduplicating retries, choosing the right HTTP status code for retry vs no-retry, persisting raw payloads before canonical mapping, and quarantining unverifiable events. Covers signature schemes, idempotency patterns, provider retry contracts, raw-then-canonical pipelines, quarantine, secret rotation, and PII-capture timing. Do NOT use for outbound webhook publishing (use `event-contract-design`), general background-job orchestration, or chasing a webhook handler that has already failed in production (use `debugging`). Do NOT use for design our outbound webhook product (we want to deliver events to customers). Do NOT use for the production webhook is failing — find the root cause. Do NOT use for explain our webhook patterns in the contributor docs. Do NOT use for review this AI-generated webhook handler for correctness. Do NOT use for refactor the webhook handler helpers for clarity.
- ▌ Constraint Awareness · jacob-balslevUse when prioritizing work in an AI-assisted codebase, designing agent autonomy levels, deciding what to automate vs keep manual, or evaluating whether a process/tool adds value. Covers Theory of Constraints for AI-era engineering: cheap code production, human review/validation/decision bottlenecks, Five Focusing Steps, constraint-aware process design, attention audits, and constraint-shift modeling. Do NOT use for task-effort estimation, backlog scoring with RICE/WSJF/ICE, or routing a task to a specific model. Do NOT use for what's the ICE / RICE score for this initiative against five others. Do NOT use for estimate the effort tier for this ticket. Do NOT use for route this debugging task to the cheapest model that can solve it. Do NOT use for review this AI-generated PR for correctness. Do NOT use for design the production reliability layer for our agent system.
- ▌ Form UX Architecture · jacob-balslevUse when designing or auditing form structure and validation UX: field grouping, required vs optional inputs, validation timing, client/server validation split, submission lifecycle, recovery, multi-step forms, and high-risk data entry. Do NOT use for labels and announcements alone (use `a11y`), validation-message wording (use `microcopy`), API schema design (use `api-design`), or stored data modeling (use `entity-relationship-modeling`). Do NOT use for add labels so assistive tech can read each field. Do NOT use for rewrite the inline validation messages. Do NOT use for define the request and response schema for the form submit endpoint. Do NOT use for model the database columns that store these inputs. Do NOT use for validation-message wording (use microcopy).
- ▌ Interaction Feedback · jacob-balslevUse when designing UI feedback around user actions and system state: loading, skeletons, optimistic updates, progress, success, errors, empty states, retries, disabled/pending states, autosave, undo, and perceived latency. Do NOT use for the words inside feedback (use `microcopy`), accessibility announcement mechanics (use `a11y`), business lifecycle modeling (use `state-machine-modeling`), or performance optimization (use `performance-engineering`). Do NOT use for rewrite the toast and validation text. Do NOT use for make sure the status update is announced to screen readers. Do NOT use for model the order lifecycle and legal transitions. Do NOT use for profile the endpoint that makes this action slow. Do NOT use for the words inside feedback states (use microcopy).
- ▌ Interaction Patterns · jacob-balslevUse when choosing or auditing UI interaction patterns and controls: tabs vs pages, dropdown vs combobox, stepper vs wizard, modal vs inline edit, disclosure, command menus, selection, filtering, and gesture alternatives. Do NOT use for accessibility compliance (use `a11y`), task decomposition (use `task-analysis`), feedback-state staging (use `interaction-feedback`), or reusable component API design (use `design-system-architecture`). Do NOT use for audit this combobox for ARIA roles and keyboard support. Do NOT use for define the user's top task before choosing controls. Do NOT use for add skeleton loading and optimistic feedback to this action. Do NOT use for define the component props, variants, slots, and token contract. Do NOT use for feedback states after an action (use interaction-feedback). Do NOT use for component props, variants, slots, and token contracts (use design-module-composition).
- ▌ Mobile Responsive UX · jacob-balslevUse when designing mobile-specific UX for dashboards and operational web apps: touch-friendly targets, thumb-zone optimization, swipe gestures, condensed data display, bottom navigation, bottom sheets, mobile inputs, and pull-to-refresh. Load when adapting a desktop dashboard to phone use, implementing touch interactions, or checking whether a mobile layout serves quick-glance tasks rather than compressed desktop analysis. Do NOT use for general responsive layout structure across all breakpoints (layout-composition), accessibility compliance breadth such as ARIA, keyboard, and screen reader audits (a11y), or component/token architecture (design-system-architecture). Do NOT use for audit ARIA labels and keyboard focus order. Do NOT use for choose global page breakpoints and responsive grid tracks. Do NOT use for design reusable design tokens for mobile components. Do NOT use for create the product information architecture.
- ▌ Opencode Free Models · jacob-balslevUse when deciding WHICH free or cheap agent model to route a piece of work to (e.g. MiniMax M3 Free, NVIDIA Nemotron, GLM, GPT-5 Nano, or another OpenCode Zen free-tier model), what each is good at, where its quality ceiling sits, and when to escalate the same work to a frontier model instead. Covers cost-routing: matching deterministic/mechanical/high-volume work to the cheapest model that clears its bar, and the hard rule that quality-creating and quality-judging work never goes to a free/cheap model. Do NOT use for choosing or operating the OpenCode runtime itself (use `opencode`), for authoring the agent loop (use `autonomous-loop-patterns`), or for GitHub Copilot premium-request budgeting (use `github-copilot`). Do NOT use for how do I invoke opencode from a script? Do NOT use for how do I write the retry loop for my agent? Do NOT use for how many Copilot premium requests will this cost?
- ▌ Replication Patterns · jacob-balslevUse when designing how a database keeps multiple copies of its data in agreement across nodes for availability, read scaling, and disaster recovery: the three foundational topologies (single-leader / primary-replica, multi-leader / multi-primary, leaderless / quorum), synchronous vs asynchronous replication and the replication-lag trade-off, log shipping vs statement replication vs trigger-based replication, the read-after-write consistency problem and its mitigations (sticky session, read-from-leader, monotonic reads), the failover model and split-brain risk, and the relationship to the CAP/PACELC choices the topology realizes. Do NOT use for horizontal partitioning across nodes (use sharding-strategy), the CAP theoretical frame itself (use cap-theorem-tradeoffs), single-node transactional guarantees (use transaction-isolation), or query tuning (use query-optimization).
- ▌ Route Handler Design · jacob-balslevUse when designing or reviewing Next.js App Router Route Handlers: route.ts file placement, HTTP method exports, Web Request/Response APIs, body parsing, GET caching and opt-outs, dynamic segments, search params, CORS, Edge vs Node runtime choice, streaming responses, status and header discipline, error responses, and webhook endpoint shape. Use when the caller is mobile, third-party, webhook, server-to-server, cross-origin, or otherwise not your own typed UI. Do NOT use for internal UI mutations, broad API design, abstract HTTP semantics, request preprocessing, or full webhook reliability design. Do NOT use for design an internal create-comment form mutation triggered only from this app's UI (use server-actions-design). Do NOT use for read application data inside a Server Component during render (call the data source directly, not a self-fetch to your own Route Handler). Do NOT use for define the REST contract and resource model for a v2 public API (use api-design).
- ▌ Skill Infrastructure · jacob-balslevUse when designing or auditing deterministic health tooling for a skill library: schema/source validation, manifest/protocol parity, relation integrity, routing health, drift/export checks, supply-chain scanning, and eval-verdict evidence honesty. Covers checker ownership, the library-as-database model, release gates, and maintenance workflows after batch skill changes. Do NOT use for authoring one SKILL.md (use `skill-scaffold`), repo conformance audits (use `graph-audit`), generic lint rules (use `lint-overlay`), or reviewing checker code (use `code-review`). Do NOT use for scaffold a new SKILL.md for our team''s deploy procedure. Do NOT use for audit this Skill Graph repo for schema conformance and dangling relation targets. Do NOT use for the manifest sample drifted from the generator — find the mismatch. Do NOT use for improve this prompt''s wording to get better outputs. Do NOT use for review this AI-generated PR for correctness. Do NOT use for review this PR that changes scripts/skill-lint.js.
- ▌ Value Chain Analysis · jacob-balslevUse when decomposing how an organization, business unit, product, service, platform, or operating model creates value and cost through Porter's Value Chain and adjacent activity-system lenses. Covers primary and support activities, value configurations, virtual information activities, value-system dependencies, activity-level cost and differentiation drivers, linkages, fit, margin, mapping activities, comparing activity configuration to rivals or alternatives, and diagnosing cost or differentiation opportunities. Do NOT use for industry profit-pressure diagnosis (use porters-five-forces), resource/capability advantage testing (use vrio), durable moat classification (use seven-powers), full strategy-cascade design (use playing-to-win), market-boundary reconstruction (use blue-ocean-strategy), portfolio allocation (use bcg-matrix), product-market growth paths (use ansoff-matrix), macro scanning (use pestel), or quantified option valuation (use expected-value).
- ▌ Knowledge Modeling · jacob-balslevKnowledge modeling: choosing and maintaining the representation paradigm (graphs, frames, rules, hybrids) for domain knowledge based on primary query patterns. Do NOT use for Design the database tables and foreign keys for this schema. Do NOT use for I just need a clean IS-A category hierarchy with no rules or graph behavior. Do NOT use for I need formal OWL axioms with class restrictions and reasoning semantics. Do NOT use for I want the exact edge labels between concepts. Do NOT use for Abstract the domain into entities and relationships in human-readable terms before any database talk. Do NOT use for paradigm choice and informal/hybrid representation (use ontology-modeling). Do NOT use for graph structure and representation choice (use semantic-relations). Do NOT use for multi-paradigm and graph modeling (use taxonomy-design).
- ▌ Layout Composition · jacob-balslevUse when deciding responsive page or screen structure: section order, scan pattern, grid/flex composition, breakpoints, viewport hierarchy, responsive media, and density. Do NOT use for user-goal decomposition (use `task-analysis`), navigation taxonomy (use `information-architecture`), visual polish (use `visual-design-foundations`), or component/token contracts (use `design-system-architecture`). Do NOT use for what is the user's top task for this route? Do NOT use for design the global navigation and sitemap. Do NOT use for pick the color palette, type scale, and visual mood. Do NOT use for define component variants and semantic tokens. Do NOT use for navigation and page grouping (use information-architecture). Do NOT use for visual craft choices (use visual-design-foundations).
- ▌ Naming Conventions · jacob-balslevUse when naming a new file, function, variable, type, route, database column, environment variable, or any other code or system artifact. Covers identifier morphology (verb-noun choice, plural vs singular, prefix/suffix conventions), kebab-case vs camelCase vs snake_case vs PascalCase per artifact kind, abbreviation rules, name-vs-path semantics, the rename-coordination workflow, and detection of names that lie. Do NOT use for content writing (use `documentation`), for restructuring already-named code (use `refactor`), or for human-language copy in product UI (separate skill, not in this library). Do NOT use for refactor this 200-line function into smaller pieces. Do NOT use for write a doc explaining our naming conventions. Do NOT use for review this PR's naming choices. Do NOT use for the variable named `userIsActive` is logging the wrong value. Do NOT use for scaffold a new skill that teaches naming conventions.
- ▌ No Cutting Corners · jacob-balslevEnforce five non-negotiable quality pillars as a pre-output gate: complete reporting (show ALL items, never filter unilaterally), verification (no claim of works/done/exists without a tool-call receipt in the same turn), thoroughness (every acceptance criterion verified with evidence; docs ship with the change), enrichment ('improve' adds capability, never trims), and anti-shortcut (exhaust deterministic lookup before guessing; findings demand action, not filing). Use when reviewing enumerated output for completeness, when an agent claims something works without evidence, when marking a task done, or when asked to 'improve' anything.
- ▌ Query Optimization · jacob-balslevDiagnosing and tuning a specific slow relational-database query from plan evidence: workload impact, exact query context, EXPLAIN / actual execution plans, row-estimate accuracy, access path choice, join order, sort/hash spills, JIT/planning overhead, parameter-sensitive plans, plan regressions, statistics, and rewrite-vs-index-vs-operational response selection. Start from the actual plan and runtime evidence, not from the reflex to add an index; modern engine features such as Query Store, PSP/OPPO, SQL Plan Management, pg_stat_statements, auto_explain, MySQL histograms, Oracle DBMS_XPLAN, and PostgreSQL planner improvements are evidence sources and response tools, not replacements for diagnosis. Do NOT use for designing the durable index portfolio (use indexing-strategy), schema design (use entity-relationship-modeling), distributed partitioning (use sharding-strategy), isolation-level correctness (use transaction-isolation), or whole-system load testing (use performance-testing).
- ▌ Research Synthesis · jacob-balslevUse when turning raw qualitative research output (interview transcripts, field notes, diary entries, observation logs) into themes, patterns, insight statements, and design-ready artifacts via affinity mapping, empathy maps, and jobs-to-be-done framing. Do NOT use for collecting new research, quantitative analysis, statistical inference, or summarizing a single document — synthesis specifically operates on a corpus of qualitative evidence. Do NOT use for Run more interviews with five additional participants. Do NOT use for Calculate the response rate of the survey. Do NOT use for Summarize this single PDF document. Do NOT use for transforming a corpus of collected qualitative evidence into themes and insights (use user-research).
- ▌ Semantic Relations · jacob-balslevUse when typing edges in a knowledge graph or concept map, resolving synonym/antonym/polysemy/homonym confusion, testing whether a connection is IS-A, PART-OF, causal, thematic, or vague, explaining adjacent concepts, or auditing whether hierarchy and skill-boundary decisions use the wrong relation type. Covers taxonomic, associative, and thematic relations plus symmetry, asymmetry, transitivity, reflexivity, and irreflexivity. Do NOT use for formal ontology axioms with reasoning constraints, database foreign-key or junction-table design, or operational data correspondence across systems. Do NOT use for I need formal OWL axioms, class restrictions, and reasoning semantics on a knowledge base. Do NOT use for I need the physical database foreign keys and junction-table design for these relationships. Do NOT use for I need to connect external IDs from one platform to canonical IDs in our system operationally.
- ▌ Tool Call Strategy · jacob-balslevUse when an agent is making too many tool calls, when context is filling from verbose tool outputs, when the same operation could be a script instead of N individual calls, or when designing a tool-use protocol for a new agent or harness. Covers the three costs of every call (token, latency, context pollution), the script-vs-call decision gate, tool-selection decision trees (file-search vs content-search vs targeted-read vs full-read), call batching and parallelization, redundancy avoidance, the poka-yoke principle, subagent delegation for context protection, and cost-benchmark heuristics by task type. Do NOT use for prompt wording (use `prompt-craft`), broader context stack design across the five layers (use `context-engineering`), runtime tool failures or production debugging (use `debugging`), or behaviour-preserving refactor mechanics (use `refactor`). Do NOT use for improve this prompt's wording to get better outputs. Do NOT use for design what skills get loaded for which prompts.
- ▌ With Grounding · jacob-balslev bundleUse as the minimal v8-conformant project-grounded fixture for skill-graph package tests. Activate this skill when verifying that lint enforces the rule 'non-empty project[] requires grounding' (subject_matter, grounding_mode, truth_sources, failure_modes, evidence_priority). Do NOT use as a production skill (use a real grounded skill from the canonical library).
- ▌ With Relations · jacob-balslev bundleUse as the v8-conformant fixture exercising typed relation predicates (related, suppresses, verify_with, depends_on) using the live schema item shapes. Activate this skill when verifying that lint resolves cross-fixture relation targets without a sibling skills clone. Do NOT use as a production skill (use a real capability skill from the canonical library).
- ▌ Blue Ocean Strategy · jacob-balslevUse when creating, auditing, or pressure-testing a Blue Ocean Strategy: value innovation, strategy canvas, Four Actions Framework, ERRC grid, six paths, buyer utility, noncustomers, and commercial viability. Covers reconstructing market boundaries, breaking the value-cost trade-off, shifting from competitor benchmarking to alternative/noncustomer insight, and turning the result into a new value curve. Do NOT use for industry-structure diagnosis alone (use porters-five-forces), durable moat classification (use seven-powers), or integrated five-choice strategy cascades (use playing-to-win). Do NOT use for analyze supplier power, buyer power, entrants, substitutes, and rivalry in this industry. Do NOT use for classify which durable moat this company has using Seven Powers. Do NOT use for turn this company strategy into aspiration, where to play, how to win, capabilities, and systems. Do NOT use for rank these roadmap initiatives by impact and effort.
- ▌ Color System Design · jacob-balslevUse when designing a color system — palette construction, semantic color tokens, WCAG contrast pairings, perceptual scale generation in OKLCH/LCH/HCT, wide-gamut fallbacks, and light/dark/high-contrast parity. Do NOT use for single brand-color picks, runtime theme-switching mechanics, token delivery architecture, or non-color design tokens. Do NOT use for Pick the brand's primary color from scratch with no system constraints. Do NOT use for Implement prefers-color-scheme detection, localStorage persistence, and anti-flash script. Do NOT use for Design the full DTCG token build pipeline for all token categories. Do NOT use for Choose spacing values for the layout grid. Do NOT use for the palette, the scale construction, the semantic color roles, and the contrast pairings against every surface (use dark-mode-implementation).
- ▌ Conceptual Modeling · jacob-balslevUse when translating messy business requirements, stakeholder language, or early product ideas into an implementation-neutral domain model before database schemas, API endpoints, or DDD aggregates are named. Covers entities, attributes, named relationships, cardinality, identity criteria, specialization/generalization, aggregation/composition, reification, abstraction-level control, stakeholder validation, and modeling anti-patterns. Do NOT use for database ER diagrams with keys and normalization, formal ontology axioms with OWL/RDFS, or DDD tactical design; use those dedicated skills instead. Do NOT use for give me the physical table design with PKs, FKs, and normalization forms. Do NOT use for turn this model into SQL migrations and index definitions. Do NOT use for I need OWL class axioms and reasoning constraints for these concepts. Do NOT use for build the DDD aggregate boundaries and anti-corruption layer. Do NOT use for what hypernymy or meronymy labels apply between these two terms.
- ▌ Context Engineering · jacob-balslevUse when designing what information reaches an LLM agent before it reasons — system prompt, persistent memory, always-loaded rules, injected skills, and the user prompt — or when diagnosing why an agent produced a wrong answer despite a clear instruction. Covers the four context failure modes (missing, stale, wrong, overwhelming), the five-layer context stack, four context quality metrics (injection precision and recall, utilization, freshness), the Frequent Intentional Compaction (FIC) protocol, subagent delegation for context-heavy work, and the failure-mode decision tree. Do NOT use for prompt wording (use `prompt-craft`), authoring a new SKILL.md (use `skill-scaffold`), or deciding which skill the router activates for a given query (use `skill-router`). Do NOT use for improve this prompt's wording to get better outputs. Do NOT use for scaffold a new SKILL.md for our team's deploy procedure. Do NOT use for the router picked the wrong skill for this query — debug it.
- ▌ Epistemic Grounding · jacob-balslevUse when authoring any artifact that makes claims — skill content, documentation, audit findings, architecture proposals, code review comments, research summaries, or agent output. Covers the discipline of grounding every claim to a verifiable source, distinguishing verified-by-evidence from inferred-from-context, Chain-of-Verification-style claim checking, RFC 2119/RFC 8174 modality, Toulmin argument structure, citation faithfulness, native citation-tool limits, and honest handling of inference, absence, conflict, and currentness. Do NOT use for execution-level evidence protocols or output-completeness enforcement (use methodology), naming precision (use semantics), or grader/rubric design (use evaluation or eval-driven-development). Do NOT use for decide which lint rule to add for a specific kind of drift (use skill-infrastructure). Do NOT use for evaluate a finished SKILL.md against the comprehension grader (use evaluation).