jacob-balslev
- 375 skills
- 0 followers
- last month last updated
- ▌ 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.
- ▌ 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.
- ▌ 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).
- ▌ Middleware Patterns · jacob-balslevUse when designing or reviewing Next.js middleware: the single middleware.ts request preprocessor, Edge Runtime constraints, matcher config, NextRequest/NextResponse APIs, redirects, rewrites, pass-through responses, direct responses, auth gates, locale routing, A/B rewrites, security-header delivery, geo routing, bot blocking, and request ID injection. Use for fast cross-cutting request concerns that apply across many routes. Do NOT use for per-route API handlers, Server Actions, HTTP semantics, full security policy design, streaming logic, or webhook signature handling. Do NOT use for implement a /api/posts POST endpoint (use route-handler-design). Do NOT use for implement a delete-comment mutation triggered from a form button (use server-actions-design). Do NOT use for explain what an HTTP 308 means vs 307 (use http-semantics). Do NOT use for design the full CSP policy and the rest of the security-header strategy (use security-fundamentals).
- ▌ Testing Strategy · jacob-balslevUse when planning tests for a bug fix, feature, or refactor — deciding what deserves a test, at which level, with what evidence. Covers test-scope decisions, test-level selection (unit / integration / contract / e2e), effort-to-risk matching, regression targeting, evidence quality, and failure-case coverage. Do NOT use for chasing a known failure (that is `debugging`), for pure doc writing (that is `documentation`), or for conceptual architecture discussion with no verification target (no dedicated skill — treat as strategy, not testing). Do NOT use for my existing test is failing — why? Do NOT use for write a testing-patterns guide for the contributor docs. Do NOT use for clean up this duplicated test setup across three files.
- ▌ Visual Hierarchy · jacob-balslevUse when establishing visual hierarchy — type scale ratios, spacing rhythm, contrast as ordering signal, weight and size as importance, and the layered relationship between primary, secondary, and tertiary information. Do NOT use for content writing, information architecture, or specific color palette construction. Do NOT use for Write the H1 copy that should appear at the top of the landing page. Do NOT use for Choose between sans-serif and serif typefaces for the brand. Do NOT use for Pick the brand's primary color.
- ▌ Agent Engineering · jacob-balslevUse when designing or evaluating a production AI agent system, choosing a multi-agent coordination pattern (orchestrator/worker, fan-out, consensus, sequential chain, evaluator/optimizer), diagnosing coordination failures (claim races, silent stalls, context contamination, runaway loops), or auditing whether an agent loop is truly production-ready. Covers the four pillars (architecture and lifecycle, task decomposition, coordination patterns, production reliability), the six reliability requirements (observability, cost budgets, idempotency, failure recovery, safety caps, claim locks), the delegation decision framework with overhead crossover, and the most common anti-patterns. Do NOT use for prompt wording (use `prompt-craft`), per-call tool efficiency (use `tool-call-strategy`), context-stack design within a single agent (use `context-engineering`), or runtime debugging of a deployed system (use `debugging`). Do NOT use for improve this prompt's wording to get better outputs.
- ▌ Indexing Strategy · jacob-balslevUse when designing or auditing the maintained index set for a database workload: choosing index structures, matching access patterns, setting composite order, balancing read speed against write/storage cost, and deciding when to add, keep, or drop indexes. Do NOT use for tuning one slow query (use query-optimization), applying production DDL (use database-migration), isolation choices, schema design, or sharding. Do NOT use for choose a database schema (use entity-relationship-modeling). Do NOT use for decide how to partition data across nodes (use sharding-strategy).
- ▌ Ontology Modeling · jacob-balslevUse when formalizing domain meaning with classes, properties, constraints, RDF/OWL-style semantics, SHACL-like validation shapes, or reasoning-ready axioms. Do NOT use for simple category trees (use `taxonomy-design`), pre-implementation business entity sketches (use `conceptual-modeling`), database schemas (use `entity-relationship-modeling`), or broad representation choice (use `knowledge-modeling`). Do NOT use for make a simple browse category tree for skills. Do NOT use for identify the business entities and relationships before implementation. Do NOT use for design the SQL tables, keys, and indexes. Do NOT use for choose whether this knowledge belongs in rules, frames, a graph, or a hybrid.
- ▌ Real Time Updates · jacob-balslevUse when designing browser-facing freshness for live dashboards, notifications, progress views, feeds, and data that can change after initial render. Covers freshness contracts, transport choice among adaptive polling, Server-Sent Events, and bidirectional sockets, webhook-to-UI propagation, client cache invalidation, stale-data indicators, reconnect and catch-up behavior, centralized subscription ownership, and non-disruptive update UX. Do NOT use for low-level stream/backpressure protocol design (use `streaming-architecture`), async event envelope/topic contracts (use `event-contract-design`), recurring schedule design (use `cron-scheduling`), durable worker execution semantics (use `background-jobs`), generic UI action feedback (use `interaction-feedback`), or serialization/trust boundaries (use `client-server-boundary`). Do NOT use for design the backpressure protocol for an HTTP stream. Do NOT use for choose the cron expression for a daily refresh.
- ▌ Scenario Planning · jacob-balslevScenario planning: a strategic-foresight method for making decisions under deep uncertainty by constructing and stress-testing several plausible future worlds. Do NOT use for Scan political, economic, social, technological, environmental, and legal forces for market entry. Do NOT use for We have three options with probabilities and payoffs. Compute expected value and recommend one. Do NOT use for Update our confidence in this forecast after new evidence arrived. Do NOT use for Balance our innovation portfolio across core, adjacent, and transformational bets. Do NOT use for Turn strengths, weaknesses, opportunities, and threats into SO, WO, ST, and WT options. Do NOT use for Answer the five Playing to Win choices for this business. Do NOT use for constructing and using alternative futures from critical uncertainties (use pestel). Do NOT use for deep-uncertainty exploration (use expected-value). Do NOT use for multiple plausible future worlds and strategic robustness (use bayesian-reasoning).
- ▌ Sharding Strategy · jacob-balslevUse when reasoning about horizontal partitioning of data across nodes for storage capacity and write throughput beyond a single node: the three foundational partitioning schemes (range, hash, directory/lookup), the shard-key choice that determines whether the system scales or hotspots, the resharding problem and how consistent hashing addresses it, cross-shard queries and the joins-and-transactions trade-off, the relationship to replication (sharding partitions data; replication copies each shard), and the failure modes (hot shard, skewed distribution, cross-shard transactions, range-end overload). Do NOT use for replicating the same data across nodes (use replication-patterns), the CAP/PACELC frame (use cap-theorem-tradeoffs), single-node performance tuning (use query-optimization), or indexing within a shard (use indexing-strategy).
- ▌ Suspense Patterns · jacob-balslevUse when designing or reviewing React Suspense usage: where to place Suspense boundaries to control loading granularity, the difference between Suspense for data fetching and Suspense for code splitting, how Suspense interacts with Server Components for streaming HTML, how error boundaries pair with Suspense (and why they must be distinct components), the relationship between Suspense and React's transition APIs (useTransition, startTransition), and the design rules that prevent waterfall fetches, layout shift, and SEO regressions. Covers React 18+ and 19's `use` hook for unwrapping Promises in Client Components. Do NOT use for general React rendering strategy choice (use rendering-models), for the underlying hook primitives (use hooks-patterns), for streaming protocols beyond Suspense (use streaming-architecture), or for Server Component design (use server-components-design).
- ▌ Typography System · jacob-balslevUse when designing a typography system — typeface selection and pairing, modular type scale, vertical rhythm, line-height and measure rules, and web font delivery (subsetting, font-display, variable fonts). Do NOT use for body copy writing, single-headline font pairing, or non-text design tokens. Do NOT use for Write the headline copy for the landing page. Do NOT use for Pick the brand's primary color. Do NOT use for Decide where the headline component lives in the folder structure.
- ▌ Usability Testing · jacob-balslevUse when observing representative real users attempting realistic tasks on a prototype or live product to surface usability issues: moderated or unmoderated, remote or in-person, concurrent or retrospective think-aloud, task scenarios, participant screening, tree/first-click testing for IA findability questions, pilot runs, severity rating, sample sizing by claim type, and ethical recording/consent. Do NOT use for automated test suites, code coverage, CI pipelines, unit/integration testing, load testing, or replacing participants with AI/synthetic users; those are engineering verification or synthetic-analysis concerns, not human-behavior observation. Do NOT use for Add unit tests for the order-total calculation function. Do NOT use for Set up the CI pipeline for the new repo. Do NOT use for Run a load test against the checkout API. Do NOT use for Run a card sort to design the navigation hierarchy and labels for this site. Do NOT use for Cluster the findings from ten completed user sessions into themes.
- ▌ Writing Humanizer · jacob-balslevUse when writing or editing human-readable prose such as docs, PRs, issues, release notes, errors, UI copy, commits, tooltips, or support replies, especially when text sounds robotic, padded, monotonous, or overly formal. Covers AI-tell removal, active voice, hedging reduction, readability diagnosis, sentence rhythm, vocabulary variety, tone mapping, paragraph rhythm, bullets-vs-prose choice, and the 5-step humanization workflow. Do NOT use for documentation routing/type selection, code-identifier naming, or in-product UI-text pattern catalogs. Do NOT use for decide kebab-case vs camelCase for this new database column. Do NOT use for draft the marketing headline for the pricing page with strong persuasion. Do NOT use for restructure this doc into a tutorial format with progressive disclosure. Do NOT use for rewrite this UI button label so it names the actual action instead of saying Submit. Do NOT use for rename this React component across all call-sites in the repo. Do NOT use for audit this WCAG 2.
- ▌ Balanced Scorecard · jacob-balslevUse when building, reviewing, or applying a Balanced Scorecard for strategy execution and performance management: destination statement, strategy map, perspectives, strategic objectives, strategic readiness, measures/KPIs, targets, initiatives, owners, review cadence, cascading, and learning from performance gaps. Covers financial/stewardship, customer/stakeholder, internal process, and learning/growth or organizational-capacity perspectives, with sustainability/ESG embedded or added as a fifth perspective when strategic, and adaptation for business, nonprofit, public-sector, product, and transformation contexts. Do NOT use for upstream strategy formulation alone (use playing-to-win), quarterly goal-setting alone (use okrs), technical service thresholds (use performance-budgets), portfolio allocation (use bcg-matrix), generic internal/external factor inventory (use swot-tows), probability-weighted option valuation (use expected-value), or activity-level value/cost decomposition (use value-chain-analysis).
- ▌ Bayesian Reasoning · jacob-balslevUse when updating beliefs, forecasts, diagnoses, or decision assumptions under uncertainty using Bayesian reasoning: priors/base rates, likelihood, evidence strength, posterior direction, and residual uncertainty. Covers base-rate discipline, likelihood-vs-posterior separation, independent evidence updates, natural-frequency examples, confidence calibration, and when to stop at qualitative probability instead of fake precision. Do NOT use for expected monetary value calculations, strategy-cascade choices (use playing-to-win), industry-structure analysis (use porters-five-forces), or generic task prioritization (use prioritization). Do NOT use for calculate the expected value of these three options. Do NOT use for turn this growth plan into a strategy cascade. Do NOT use for analyze supplier power and substitutes in this industry. Do NOT use for rank these roadmap items by impact and effort. Do NOT use for build a statistical model from a dataset.
- ▌ Connection Pooling · jacob-balslevUse when reasoning about how an application manages its database connections: why every connection has a server-side cost, the difference between application-level pools (HikariCP, pgx pool, node-postgres Pool) and proxy-level pools (PgBouncer, Pgpool, ProxySQL), the three PgBouncer modes (session, transaction, statement) and their feature compatibility, the canonical pool-sizing math (Little's Law applied to database concurrency; Wooldridge's analyses), the failure modes (connection exhaustion, hot-loop reconnects, prepared-statement breakage under transaction pooling, idle-in-transaction leaks), and the diagnostic procedure when a workload is contending on connections instead of query work. Do NOT use for query-level performance (use query-optimization), for index design (use indexing-strategy), for read/write replica routing (use replication-patterns), or for cross-shard query coordination (use sharding-strategy). Do NOT use for choose the transaction isolation level for concurrent account transfers.
- ▌ Context Management · jacob-balslevUse when deciding what to load into an active agent session, recovering from context drift, preparing compaction or restart, distilling raw inputs into a working summary, or writing a handoff another agent can resume quickly. Covers intake triage, the active-context contract, the six-step context-management loop, working-set shaping, evidence capsules and observation masking, just-in-time handle-before-payload loading, prompt-caching alignment, context-rot defenses, drift signals and reset, the runtime-primitives boundary, compaction-ready handoffs, and selective rebuild after context loss. Do NOT use for token math (use `context-window`), prompt wording (use `prompt-craft`), persistent memory curation, or multi-graph context architecture (use `context-graph`). Do NOT use for calculate the per-zone token budget for the 200K context window. Do NOT use for improve this prompt template for the grader. Do NOT use for curate the persistent memory index file.
- ▌ Database Migration · jacob-balslevUse when planning or applying a raw-SQL database migration to a live PostgreSQL database — adding columns, renaming columns or tables, changing types, creating indexes, adding foreign keys, or running data backfills. Covers zero-downtime patterns (expand / contract, batched backfill, NOT VALID foreign keys, CONCURRENTLY indexes), the direct/unpooled connection requirement for migration tooling, branched-database workflows, and rollback strategy. Do NOT use for ORM-managed migrations driven by Prisma/Drizzle/TypeORM CLI scaffolding, for chasing a migration that has already failed in production (use debugging), for multi-release schema lifecycle planning outside one migration (use schema-evolution), or for designing the row-level-security model itself (use owasp-security). Do NOT use for design the row-level-security model for our new tenant table. Do NOT use for the migration crashed in production — find the root cause. Do NOT use for plan the full multi-release schema evolution for this domain.
- ▌ Intent Recognition · jacob-balslevUse BEFORE any tool call that could modify state, touch sensitive targets, rewrite history, install dependencies, publish packages, or expose credentials/environment data. Classifies intent into Passive/Read, Reconnaissance, Modification, or Destructive/Irreversible using operation type plus target sensitivity, then runs Identify / Confirm / Verify before action. Do NOT use for deciding what code to write, executing already-classified work, reactive post-execution guardrails, or defining upstream governance policy. Do NOT use for design the deterministic safety hook that blocks destructive commands. Do NOT use for decide whether to use a switch or a chain of ifs. Do NOT use for actually execute the migration after we've classified the risk. Do NOT use for scan this repo for OWASP top 10 vulnerabilities. Do NOT use for review this AI-generated PR for correctness. Do NOT use for the loop is stalling — what's the steering signal.
- ▌ Tool Call Flow · jacob-balslevUse when reasoning about the protocol-level cycle by which a language model uses external tools: declaration, request, execution, continuation, model-visible transcript or provider-resumed state, ID pairing, tool-result formatting, vendor encodings (Anthropic Messages, OpenAI Responses and Chat Completions, MCP, Gemini generateContent and Interactions), client tools vs hosted/server tools, strict schemas and grammar-constrained custom tools, streaming arguments, tool search/deferred loading, programmatic tool calling, computer-use/browser-control screenshot-action loops, parallel vs sequential calls, error handling, and the separation between model intent and runtime execution. Do NOT use for deciding when or how many tools to call (use tool-call-strategy), multi-agent architecture (use agent-engineering), prompt wording (use prompt-craft), or eval design for tool-use behavior (use eval-driven-development).
- ▌ Background Jobs · jacob-balslevUse when moving slow or failure-prone work out of a request path, designing job queues, retries, checkpoints, progress reporting, cancellation, or worker concurrency. Covers inline-vs-background decisions, queue contracts, state machines, idempotency, retry/backoff, progress signals, worker leases, and user-visible completion reporting. Do NOT use for time-based schedule design (use `cron-scheduling`), live browser transport choice (use `real-time-updates`), or async message schema ownership (use `event-contract-design`). Do NOT use for choose the cron expression for a daily run. Do NOT use for design an SSE or WebSocket browser update channel. Do NOT use for define an event envelope and topic naming standard. Do NOT use for debug why this already-running worker crashed. Do NOT use for model the database schema for the business entity being processed.
- ▌ Content Monitor · jacob-balslevUse when building or operating multi-source intelligence pipelines across video, GitHub, Reddit, curated lists, search, and RSS feeds. Covers source adapters, discovery/transcription/summarization/evaluation phases, deduplication, schedules, model-stage choice, and actionable brief generation. Do NOT use for SEO keyword research (use `keywords`) or competitive product analysis (use `user-research`).
- ▌ Cron Scheduling · jacob-balslevUse when designing time-based scheduled work in web applications: Vercel Cron routes, Inngest cron-triggered functions, recurring-job idempotency, overlap prevention, retry/failure handling, UTC/timezone decisions, and monitoring for missed or failed schedules. Covers cron expressions, scheduler selection, authorization of cron endpoints, dispatch-to-worker patterns, execution-window idempotency, concurrency locks, and heartbeat/alert design. Do NOT use for general background job queue architecture (use background-jobs), event-driven orchestration without a time trigger, browser freshness transports, or one-off task debugging unrelated to recurring schedules. Do NOT use for move a slow export out of an API handler but it is user-triggered, not scheduled. Do NOT use for design a generic queue contract with retries and progress. Do NOT use for choose Server-Sent Events versus WebSockets for live progress. Do NOT use for define an event payload schema for an async integration.
- ▌ Design Thinking · jacob-balslevUse when orchestrating a full human-centered design process across discovery, definition, ideation, prototyping, and testing — when uncertain which stage of the arc a team is in, when deciding whether to loop back, or when routing to the right stage-specific sibling skill. Do NOT use for single-stage execution (go directly to problem-framing, user-research, research-synthesis, journey-mapping, ideation, prototyping, or usability-testing) or for engineering domain discovery (use event-storming). Do NOT use for Run a single crazy-8s round on this specific how-might-we. Do NOT use for Write the React component for the dashboard widget. Do NOT use for Model the bounded contexts for the order-fulfillment domain. Do NOT use for single-stage divergent/convergent concept generation (use ideation).
- ▌ E2e Test Design · jacob-balslevUse when designing end-to-end tests that exercise a user-visible path through the whole system, including the UI layer: the user-journey unit-of-test that distinguishes e2e from integration testing, the five-primitive structure (user journey, environment, test data, observable assertion, recovery), why e2e tests are expensive and how to keep them few-and-load-bearing, the wait/synchronization discipline that makes them not-flaky, the page-object and trace-test patterns, the role of e2e tests in the test pyramid/trophy (the top tier — fewest in count but highest in coverage of user-observable behavior), and the modern e2e tool landscape (Playwright, Cypress, Selenium). Do NOT use for testing internal seams of the system (use integration-test-design), single-unit isolated tests (use testing-strategy + test-doubles-design), consumer-driven contract verification (use contract-testing), or visual regression of specific components (use snapshot-testing).
- ▌ Journey Mapping · jacob-balslevUse when mapping a user's experience across multiple touchpoints and time, surfacing emotional peaks and troughs, identifying opportunity moments in a cross-channel flow, or aligning a team on the end-to-end experience including back-stage support processes. Do NOT use for decomposing a single screen into UI steps (use task-analysis) or for drawing back-end service architecture diagrams — journey maps describe human experience, not system topology. Do NOT use for Break down the steps a user takes inside the upload modal. Do NOT use for Draw the microservice call graph for the checkout API. Do NOT use for Diagram the database schema for the order entity.
- ▌ Problem Framing · jacob-balslevUse when a team is converging on solutions before agreeing on the problem, when a brief reads as a feature request, when symptoms and root needs are tangled, or when assumptions need surfacing before design work proceeds. Do NOT use for code-level bug triage, runtime failure diagnosis, or root-cause analysis of system errors — those are engineering investigation tasks, not design problem framing. Do NOT use for Find the bug causing the 500 error in the checkout endpoint. Do NOT use for Why is the test suite flaky on CI? Do NOT use for Classify whether this agent request is high-risk before executing.
- ▌ Semantic Center · jacob-balslevUse when you need to explain how parts of a system, feature, concept, page, workflow, or problem connect; identify the single most important part of something; untangle dense dependencies into a core plus typed relations; or answer 'what is the load-bearing part?' without drifting into implementation or task prioritization. Provides a five-step workflow — classify the unit of analysis, find the single primary part using removal/governance/purpose/weight/decision tests, map secondary parts via typed relations (dependency, input/output, parent/child, owner/owned, cause/effect, constraint/enabler, and others), produce a structured output, and reduce the whole to one final sentence — that forces explanation through one-primary reduction rather than flat lists or chronology. Do NOT use for implementation work (use the relevant domain skill), choosing what to do next (use a prioritization skill), or formal architectural-ownership design (use a domain-modeling skill).
- ▌ Taxonomy Design · jacob-balslevUse when designing a controlled classification system: category trees, facets, browse taxonomies, SKOS broader/narrower relationships, tagging rules, and duplicate-category cleanup. Do NOT use for formal ontology axioms with reasoning constraints (use `ontology-modeling`), broad knowledge-representation choice (use `knowledge-modeling`), or one-off edge typing (use `semantic-relations`). Do NOT use for define OWL class restrictions and property domains for this knowledge base. Do NOT use for decide whether this knowledge should be represented as a graph, frame, rules, or hybrid. Do NOT use for type this single relation as meronymy, causality, synonymy, or thematic role. Do NOT use for write user-facing labels for this navigation item.
- ▌ Version Control · jacob-balslevUse when designing or maintaining the shape of a repository's git history — choosing a branching model, deciding rebase vs merge, sizing commits, linking commits to tracker tickets, tagging releases, running parallel work across worktrees, and resolving the merge conflicts that arise from any of the above. Covers trunk-based development, short-lived feature branches, atomic commit discipline, linear-history conventions (rebase + squash), release tagging with annotated tags and SemVer, hotfix flows from tags, and worktree lifecycle for parallel agents or contributors. Do NOT use for the words inside the commit message (Conventional Commits format, identifier naming — use `naming-conventions`), for chasing a release-pipeline failure (use `debugging`), or for reviewing a PR's content (use `code-review`). Do NOT use for draft a Conventional Commits message for this change. Do NOT use for the release pipeline failed at the tag-creation step — find out why. Do NOT use for review this PR before we merge it.
- ▌ Contract Testing · jacob-balslevContract testing: interface verification between consumers and providers via shared contract artifacts and independent two-phase verification. Do NOT use for Test internal seams of a system (use integration-test-design). Do NOT use for Validate an HTTP response against an OpenAPI schema (use API-spec tooling). Do NOT use for Test a complete user journey through the UI (use e2e-test-design).