Skills.
Useful instructions. Inspected in context.

Why we selected itDocuments dict/CSV/SQL fixture tradeoffs and the special SQL-fixture requirement for ephemeral dependencies.

Weigh upMocked inputs do not make dbt tests offline. SQL models only; not a validator of production data, Python models or final incremental-table state. Never run --empty against data that must be retained.

Why we selected itExplains the operational differences among a plain API call, a tool runner, managed agents and the separate Agent SDK.

Weigh upThis is Anthropic-specific and its instructions can strongly influence model, SDK and architecture choices.

Why we selected itStarts with the audience, intended impact and missing context, then lets the author curate ideas before the agent drafts each section.

Weigh upReader-model agreement is a spot check, not factual verification or a human usability study; the author still needs to verify facts and links.

Why we selected itRequires a compact design plan and a critique of generic choices before implementation.

Weigh upThis is an opinionated design process, not a component library, usability study or automated accessibility audit.

Why we selected itForm instructions require field discovery before filling, which avoids treating every PDF as the same format.

Weigh upThe bounding-box helper prints failures without setting a failing exit code; callers must inspect its messages.

Why we selected itExplains presentation-specific failure modes in chart axes, colors and shared slide assets.

Weigh upLibreOffice previews can differ from PowerPoint font rendering; the source calls for visual review.

Why we selected itSeparates whether a skill activates from whether its instructions improve the resulting work.

Weigh upFull baseline and comparison workflows depend on subagents and Claude CLI; reduced Claude.ai paths omit those evaluations.

Why we selected itDistinguishes formula expressions from cached calculated values, a common source of misleading workbook output.

Weigh upRecalculation uses LibreOffice and the guide excludes several newer Excel functions that this environment cannot evaluate.

Why we selected itUses rendered-page reconnaissance before choosing selectors for dynamic applications.

Weigh upThe server helper checks only whether a TCP port accepts a connection, not whether the expected application is healthy.

Why we selected itDocuments the different create, edit and read paths instead of treating Word files as plain text.

Weigh upRestricted Anthropic terms apply; this is a source-available reference, not an open-source document package.

Why we selected itExplains atomic idempotency claims, payload-hash checks and explicit handling of an unknown downstream outcome.

Weigh upExamples need project-specific transactions, authentication and failure recovery. Trusted internal types do not make stored user-controlled data intrinsically trustworthy.

Why we selected itRequires the observed baseline, root-cause evidence, changed artifacts and relevant checks to accompany a completion status.

Weigh upThe validator checks supplied fields and status consistency; it cannot prove that a command actually ran or that a claimed observation is correct.

Why we selected itPreserves supporting, contradicting, qualifying and missing evidence as separate relationships instead of flattening a contested choice into confident prose.

Weigh upThe bundled validator checks structure and declared excerpts; it does not establish that a source is true or that the excerpt supports the claim.

Why we selected itTreats installed SDK versions and current docs as the basis for implementation.

Weigh upThis is specific to Cloudflare’s Agents SDK and runtime, not a general multi-provider agent framework.

Why we selected itDefines where Durable Objects fit and where stateless Workers or independent requests fit better.

Weigh upA single coordination object can become a bottleneck; object boundaries must fit the workload.

Why we selected itShips six framework references including SvelteKit plus scripts for validation, widget creation, auth probing, and persistence, with a tests/validation.md checklist.

Weigh upNeeds a Cloudflare account with a Turnstile widget secret; validation runs against live configuration.

Why we selected itStarts by discovering available measurement tools and records measurements it could not collect.

Weigh upA lab trace does not establish real-user Core Web Vitals or prove a resource is unused in every interaction.

Why we selected itUses installed types and compatibility settings instead of assuming the newest package defines the current runtime.

Weigh upWorkers-specific guidance is not interchangeable with a Node server checklist.

Why we selected itDistinguishes local simulation from remote bindings so development commands are not assumed to be harmless.

Weigh upThe skill authorizes no cloud action by itself; commands can deploy or mutate real resources.

Why we selected itTreats an empty or poorly extracted database as missing evidence rather than a clean security result.

Weigh upThe skill licence does not grant CodeQL product rights. Public repositories are eligible under CodeQL terms; private use may require GitHub Code Security. Exit 137 alone does not establish an Apple Silicon mismatch.

Why we selected itPairs each threshold with a concrete check and separates written policy from scripted enforcement.

Weigh upSuggested coverage/performance values are defaults, not measured guarantees. Example scanner commands need exit-code/severity wiring; a green invocation alone is not necessarily a blocking security gate.

Why we selected itUses existing project context, glossary and architecture decisions before synthesizing requirements.

Weigh upThis is synthesis after discussion, not a discovery interview or a check that every stakeholder requirement is present.

Why we selected itRuns detection before editing: runtime, LLM framework, app framework, existing instrumentation, and the manifest to persist into are all identified in Phase 1.

Weigh upEdits source and dependency manifests, so every change needs review and a test run before it ships.

Why we selected itStructures the analysis as explicit phases from input resolution through open and axial coding to recommendations, instead of offering generic debugging advice.

Weigh upRequires the Datadog LLMO MCP toolset with API credentials and existing LLM Observability data; without traces there is nothing to analyze.

Why we selected itUses dbt’s resolved manifest rather than guessing YAML layout, and clearly limits column coverage to columns declared in that manifest.

Weigh upThe audit measures nonempty descriptions, not their correctness or every physical warehouse column; imported model nodes can also appear in a manifest.

Why we selected itRequires a red-capable reproduction before edits, so an apparent improvement has a concrete behavior to compare against.

Weigh upThe included human-in-the-loop shell script is an editable single-line-input template, not a ready-made test runner or secret-redaction tool.

Why we selected itThe quadrant gate (tutorial, how-to, reference, explanation) plus a mandatory outline-approval step stops documentation from being written before its purpose and scope are agreed.

Weigh upFramework-first and deliberately procedural; overkill for one-paragraph answers and small edits.

Why we selected itRequires independence and explicit file or subsystem scope before work is parallelized.

Weigh upShared mutable state, sequential dependencies and overlapping file edits defeat the independence assumption.

Why we selected itSeparates authentication from object ownership and follows inherited classes, middleware and managers before reporting.

Weigh upThis is source reasoning, not a executed multi-user access test or security certificate. Upstream notes OWASP-derived reference material under CC BY-SA; retain those notices.

Why we selected itAdopt-before-you-build rule: extend an existing styling library in its own idiom and never introduce a second token system beside it, so adoption cannot become drift.

Weigh upWhat looks native (palettes, HIG rules, controls) is delegated to the sibling expo-native-ui skill; this skill governs where values live, not which values to pick.

Why we selected itVersion-aware guidance throughout: headerLargeTitleEnabled for SDK 56+ versus the deprecated headerLargeTitle, and expo-router/react-navigation instead of direct react-navigation imports.

Weigh upSeveral flagship patterns are iOS-gated (header search bar iOS only, Apple Zoom iOS 18+, liquid-glass sheet styling iOS 26+); Android equivalents need separate verification.

Why we selected itThe migration spine keeps the app shippable at every step: assess into a durable worklist, scaffold, DOM-component shell as the day-one milestone, then one nativized screen per pass in value order.

Weigh upThe verification recipe is opinionated about tooling: it asks the user to install agent-browser and argent simulators rather than falling back to manual screenshots.

Why we selected itRestates the exact root-cause claim before selecting standard or deeper verification.

Weigh upThis is finding verification, not discovery or security certification. Preserve an inconclusive outcome when evidence is missing rather than forcing a confident binary verdict.

Why we selected itVersion analysis prefers the code diff as primary signal with commit messages secondary, and states the reconciliation rule outright: on conflict the diff wins, with worked examples.

Weigh upSingle-package GitHub repositories are assumed; monorepos and non-SemVer tag schemes fall outside the versioning logic.

Why we selected itStarts with tokens and theme definitions, then inspects representative components to separate intended conventions from scattered overrides.

Weigh upSource extraction does not verify rendered appearance, accessibility or the effects of runtime themes. Descriptions of intent remain interpretation.

Why we selected itConnects component signatures and event listeners to complete examples covering forms, streaming and chat interfaces.

Weigh upThe static signatures are a source snapshot, not a version compatibility guarantee; check current Gradio documentation and your installed package.

Why we selected itStarts with subset/split discovery before pagination, search or filtering.

Weigh upAlthough the opening describes read-only exploration, later sections create repositories and upload files or raw agent traces.

Why we selected itTreats dataset shape, credentials and model persistence as prerequisites rather than leaving them until a job fails.

Weigh upThe skill directs immediate job submission for training requests; make the target, hardware and spending scope explicit before invocation.

Why we selected itSeparates local GPU inference from a locally launched client that calls remote Inference Providers.

Weigh upThe provider-backed helper still sends inference requests over the network; local script execution does not mean local inference.

Why we selected itSeparates paper text from metadata such as authors and linked code, models and datasets, helping a research task collect the right evidence.

Weigh upHub indexing and HTML availability vary; confirm that the fetched text is the actual paper before summarizing methods or results.

Why we selected itSeparates logging, alerting and retrieval into focused references, including a route from an alert to metrics around the relevant training step.

Weigh upThe private flag only affects newly created Spaces; inspect an existing Space’s visibility before uploading metrics. Webhooks and remote synchronization send data outside the machine.

Why we selected itRoutes the request to separate Progress/Plans/Problems, newsletter, FAQ and general-communication guides.

Weigh upTemplates reflect one organization’s style; adapt audience, length and date range to your team.

Why we selected itDistinguishes inspection of arrival-rate load scenarios from a small local execution and checks functional assertions as well as exit status.

Weigh upA threshold breach accepted during script validation is not an SLO pass. Recheck version-specific APIs and VU-state behavior against current k6 docs; generated scripts have not been executed in this review.

Why we selected itSeparates syntax-only edits from changes to thresholds, targets, assertions and load shape that need an explicit review.

Weigh upA parse check cannot establish SLO or target correctness. Even short smoke requests require authorized targets; companion cloud workflows and service operations were not exercised.

Why we selected itInspects manifests, CI and established documentation before drafting instructions.

Weigh upIts preferred line limit and closest-file simplification are editorial conventions, not permission to discard governing policy or override higher-priority instructions.

Why we selected itDefines a deep module by what callers can accomplish through a small interface, rather than by its line count.

Weigh upThe adapter and interface rules are design heuristics, not universal requirements; local substitutes do not prove production integration behavior.

Why we selected itDistinguishes canonical domain terms from implementation notes and uses conflicting examples to expose overloaded language.

Weigh upThe root and bounded-context instructions do not fully agree on glossary and ADR placement; agree the target paths and numbering convention first.

Why we selected itOnly asks decisions whose prerequisites are settled, so answers do not depend on unanswered questions from the same round.

Weigh upThe interview has no built-in round cap and can be too demanding for a small task; choose its scope deliberately.

Why we selected itRequires the total bill and service breakdown alongside optimization suggestions.

Weigh upRequires Azure billing/monitoring permissions and supporting CLI or MCP tools.

Why we selected itSeparates App Service, Functions, AKS, compute and messaging investigations.

Weigh upThe AKS helper selects Azure resources by arguments but uses the existing kubectl context; confirm both point to the same cluster.

Why we selected itAsks for version, platform and task context in documentation searches.

Weigh upThis is a retrieval workflow, not an implementation validator; official documentation still needs to match the installed version and target environment.

Why we selected itRequires code-reading before architectural claims and traces actual calls and data flow rather than trusting directory names.

Weigh upIts git command identifies the current branch, although the prose calls it the default branch; choose the actual revision and host-specific link format yourself.

Why we selected itSeparates new-project setup from requested migration and documents when legacy Python requirements are outside its preferred path.

Weigh upTool substitutions and coverage thresholds are recommendations, not equivalence proofs. Preserve old lockfiles and environments until the actual project passes its checks.

Why we selected itIntegrates with OpenAI, Anthropic, google-genai, Vercel AI SDK, and Mastra by changing only the base URL, with separate recommended and lower-level paths.

Weigh upGateway availability and the served catalog are plan-gated; the skill's own Availability section says to check gating first.

Why we selected itKeeps request correlation separate from the entry point that actually initiated a shared job.

Weigh upSample thresholds and the prescribed alerting policy are starting points, not universal SLOs. Validate untrusted request IDs and measure overhead, sampling and privacy in the real system.

Why we selected itStarts with a single agent and adds tools, delegation or sandboxing only when the application needs them.

Weigh upA companion credential gate can pause work before implementation even when a key already exists.

Why we selected itDistinguishes exhausted quota from ordinary rate limiting even when the HTTP status is the same.

Weigh upIt relies on companion documentation and credential skills; it does not provision or rotate keys itself.

Why we selected itBinds reusable models to repository/version identity and avoids mixing scan-specific context into a shared cache.

Weigh upThis is one phase in the Codex Security plugin, not a standalone full security scan.

Why we selected itRecords query links, input versions, filters and cohort definitions next to the analysis.

Weigh upWarehouse and operational-log placeholders depend on the host’s configured connectors; exports or supplied data are fallback paths.

Why we selected itDistinguishes static instruction-size estimates from observed usage collected by real agent runs.

Weigh upStatic scores and budget bands are tool heuristics, not proof of task quality or safety.

Why we selected itRequires exploit reachability markers and benign controls so an import failure cannot masquerade as reproduction.

Weigh upThe runner’s worktree/environment isolation is not an OS sandbox. This review did not audit or execute every helper, and passing supplied checks still requires coverage review.

Why we selected itCompatibility is evaluated on four independent dimensions (binary wire, named formats, generated source API, behavior and operations) instead of a single wire-compatibility verdict.

Weigh upVerdicts are only as good as the declared compatibility envelope; the skill itself requires lowering confidence when encodings, consumers or deployment order are unknown.

Why we selected itResolves credentials as complete sets and distinguishes absent credentials from a misconfigured source.

Weigh upThe examplecloud code is illustrative. Credential and endpoint precedence must match the real provider; do not treat endpoint or insecure-setting mismatches as automatically harmless.

Why we selected itUses muxing to avoid a whole-provider rewrite and treats existing schema and block syntax as compatibility contracts.

Weigh upSimple schemas still need measured compatibility. The included server example must be adapted to the real provider; no state migration or acceptance tests ran here.

Why we selected itKeeps new-project scaffolding separate from adding a composition to an existing project.

Weigh upThis is a router into a larger reference package, so copying the definition alone loses the working guidance.

Why we selected itGives the reviewer concrete requirements, implementation context and a bounded Git comparison.

Weigh upA base-to-head comparison excludes uncommitted changes; include those separately when they are in scope.

Why we selected itFix passes are ordered by blast radius: safe autofixes with diff review and formatting first, unsafe fixes only if findings remain, then minimal manual edits.

Weigh upUnsafe autofixes can change behavior; the workflow's value depends on actually performing its mandated diff reviews rather than waving them through.

Why we selected itSeparates finding scope from broader read-only context and validates worker artifacts before accepting completion.

Weigh upInstalling only this SKILL.md directory does not install the parent plugin scripts, prompts and named agents. Host-specific tool/cache assumptions and security findings need independent verification.

Why we selected itExplains run structure and severity inheritance instead of treating every absent result.level as the same severity.

Weigh upThe helper is not a complete SARIF validator: invocation-level ruleConfigurationOverrides and extension rule components are not resolved.

Why we selected itRequires vulnerable and safe examples before rule implementation, then runs Semgrep validation and rule tests.

Weigh upA passing fixture suite establishes behavior on those examples; it does not prove complete detection or an acceptable false-positive rate on other repositories.

Why we selected itChecks runtime serialization against types and schema, including the difference between an absent field and a nullable one.

Weigh upThe file paths, ownership checks and validation commands are specific to Sentry; this is not a drop-in guide for every Django API.

Why we selected itRequires a branch check before committing and a feature branch by default, making the target of a local commit explicit.

Weigh upThe skill can create a feature branch and a git commit; it is not a read-only message formatter. It does not instruct a push.

Why we selected itStates its evidence rule up front and repeats it as a validation checklist: research the codebase to confirm each issue and report only what can be proven.

Weigh upDjango-only; its ORM rules do not transfer to other frameworks or raw SQL tuning.

Why we selected itRequires the complete diff to be read before findings and follows changed behavior into surrounding implementations and tests.

Weigh upThe initial command compares committed branch history and omits uncommitted edits; inspect those separately if they are in scope.

Why we selected itRequires a captured contract and external-context inventory before wording changes, which keeps optimization causal instead of stylistic.

Weigh upPorted prompts still need verification on the target model; family notes are guidance, not equivalence proofs.

Why we selected itDistinguishes malicious instructions from security examples discussing the same syntax.

Weigh upA clean pattern scan cannot certify a skill safe, and repository hosting on GitHub or PyPI does not establish trust. Scanner scripts and detection effectiveness were not runtime-tested here.

Why we selected itAsks for user agreement on the proposed breakdown before creating the tickets.

Weigh upTicket publication is not transactional: partial failures or repeated runs can leave duplicates and incomplete dependency links.

Why we selected itSeparates declarative schemas from imperative migrations and pairs each path with committing guidance instead of treating all schema edits alike.

Weigh upTriggers on any Supabase task, so it can load for work the narrower Postgres skill would handle better; pick the skill per task.

Why we selected itPairs incorrect and corrected SQL with query-plan examples instead of offering only generic database advice.

Weigh upIllustrative speedups and blanket indexing rules are not measurements of your workload; inspect actual plans and write costs.

Why we selected itTreats reviewer suggestions as hypotheses to verify, with explicit checks for existing behavior, platform constraints and unused functionality.

Weigh upIts conversational tone rules are a style preference, and its pause-on-ambiguity rule may be too restrictive for independent review items.

Why we selected itAsks for evidence at component boundaries and backward tracing of bad values before proposing a patch.

Weigh upThe bundled polluter helper assumes npm tests, hides their output and swallows their failing exit statuses.

Why we selected itRequires verifying why a test fails before changing implementation, then running the project suite after the fix.

Weigh upThe workflow is deliberately prescriptive: it tells an agent to discard implementation written before tests and seek permission for exceptions.

Why we selected itMaps common claims to appropriate evidence, including compiler/build status, original bug reproduction and requirements checks.

Weigh upThis is a behavioral checklist, not an automatic enforcement mechanism or runtime test harness.

Why we selected itMakes each task name concrete files, expected behavior and meaningful failing/passing checks rather than leaving implementation placeholders.

Weigh upDetailed code in a plan can become stale as the repository changes; planned checks are not evidence that tests have run.

Why we selected itKeeps ecosystem and resolved package versions attached to evidence and distinguishes unknown results from clean checks.

Weigh upDocumented project inputs include npm package-lock/shrinkwrap, Python uv.lock and supported Go module files; other lock formats need a separate extraction step.

Why we selected itExplains when to derive state instead of synchronizing it with effects, and when reactive wrappers or subscriptions are needed.

Weigh upThe references span several Svelte releases and include experimental async behavior. Check the installed compiler version and required flags before applying an example.

Why we selected itSeparates read-time not-found removal from deletion, and compares planned attributes with state before update calls.

Weigh upThe fictional examplecloud snippets are patterns, not a standalone compiled provider. Install the accompanying references and companion test guidance; no cloud CRUD was exercised.

Why we selected itKeeps component and deployment languages separate and documents ephemeral credentials and provider bindings.

Weigh upExamples are not tested deployments. A rule forbidding deletions alone does not make every remaining update safe; review resource changes, billing and approval policy.

Why we selected itShows separation of providers, variables, resources and outputs, with sensitivity and version-control guidance.

Weigh upThe resource snippets omit project-specific required values and are not deployment-ready. Suggested versions and latest-provider guidance do not authorize an upgrade.

Why we selected itFollows callees and unsuccessful paths instead of trusting names such as validate or authorize.

Weigh upThe skill is a router into a plugin workflow and named function analyzer; a copied standalone SKILL.md is insufficient.

Why we selected itUses git history to ask why a removed check existed and whether a previous fix is being undone.

Weigh upThe methodology includes checking out the baseline and head; use a suitable worktree so the review does not disrupt uncommitted work.

Why we selected itFeature tiers rank by practical usability today (use now, deploy without a standard bump, plan for, watch) instead of reciting the standard in version order.

Weigh upC++26 positions (reflection availability, contracts caution, execution immaturity) are roadmap judgments; verify against the installed toolchain before restructuring around them.

Why we selected itSeparates test-gap analysis from bug hunting, so an uncaught mutation is not automatically presented as a vulnerability.

Weigh upThis selection focuses on existing-report analysis. Setup and optimization need separate review: examples hardcode src/, retain a pre-optimization acceptance check and mix counting formats. Do not copy their campaign estimates or purge steps unchanged.

Why we selected itExplains how tests can pass while restating implementation or filtering away nearly every input.

Weigh upProperty selection still needs a valid specification; an incorrect invariant can generate misleading failures.

Why we selected itLooks at zero, empty, negative and mixed-up values rather than only intended happy-path usage.

Weigh upThis is a design-review method, not a general implementation bug scanner.

Why we selected itPairs a bounded workflow with an offline Python checker and explicitly synthetic example inputs.

Weigh upDeterministic local checks over supplied evidence; not a guarantee of source truth or production suitability.

Why we selected itPairs a bounded workflow with an offline Python checker and explicitly synthetic example inputs.

Weigh upChecks one caller-supplied candidate set, refusing unresolved, conflicting and self-targets. It does not verify target existence, candidate completeness, recency or recursively resolve aliases.

Why we selected itPairs a bounded workflow with an offline Python checker and explicitly synthetic example inputs.

Weigh upDeterministic local checks over supplied evidence; not a guarantee of source truth or production suitability.

Why we selected itPairs a bounded workflow with an offline Python checker and explicitly synthetic example inputs.

Weigh upDeterministic local check of a supplied ladder; it does not fetch vendor prices or model marginal block billing.

Why we selected itPairs a bounded workflow with an offline Python checker and explicitly synthetic example inputs.

Weigh upDeterministic local checks over one supplied pair and the listed requirements; not a guarantee of source truth.

Why we selected itPairs a bounded workflow with an offline Python checker and explicitly synthetic example inputs.

Weigh upDeterministic local checks over supplied evidence; not a guarantee of source truth or production suitability.

Why we selected itPairs a bounded workflow with an offline Python checker and explicitly synthetic example inputs.

Weigh upChecks one supplied ordered population and subsequence, including empty arrays. It does not check scores, numeric ranks, frontier membership or dominance labels.

Why we selected itPairs a bounded workflow with an offline Python checker and explicitly synthetic example inputs.

Weigh upCompares the two host strings you supply. It does not send a request, read a body, or strip www. A pass is not a rate card.

Why we selected itPairs a bounded workflow with an offline Python checker and explicitly synthetic example inputs.

Weigh upChecks recorded path strings in a narrow ASCII subset. It rejects whitespace, doubled leading slashes, URLs, queries, fragments and dot segments; it does not fetch, compare hosts, decode percent escapes, or verify page content.

Why we selected itPairs a bounded workflow with an offline Python checker and explicitly synthetic example inputs.

Weigh upThe header is ignored. rowUnit has to come from that row's own sentence, or be null. It does not read amounts or convert units. A pass is not a vendor quote.

Why we selected itPairs a bounded workflow with an offline Python checker and explicitly synthetic example inputs.

Weigh upLooks for qualifying wording in the excerpt you supply. Negation is not parsed. It does not read amounts or pick a country. A pass is not a vendor quote.

Why we selected itPairs a bounded workflow with an offline Python checker and explicitly synthetic example inputs.

Weigh upDeterministic consistency check of a filled licence note; it does not interpret licence text or fetch the licence.

Why we selected itPairs a bounded workflow with an offline Python checker and explicitly synthetic example inputs.

Weigh upDeterministic local checks over supplied evidence; not a guarantee of source truth or production suitability.

Why we selected itPairs a bounded workflow with an offline Python checker and explicitly synthetic example inputs.

Weigh upLooks for multiplier wording in the excerpt you supply. Negation is not parsed. It does not read amounts or apply a factor. A pass is not a vendor quote.

Why we selected itPairs a bounded workflow with an offline Python checker and explicitly synthetic example inputs.

Weigh upExact savings-based arithmetic only; repeating results remain rational pairs. Currency and period alignment, taxes, timing, discounting and source truth are not verified.

Why we selected itPairs a bounded workflow with an offline Python checker and explicitly synthetic example inputs.

Weigh upDeterministic local checks over a supplied plan table; not a guarantee that a vendor page still matches.

Why we selected itPairs a bounded workflow with an offline Python checker and explicitly synthetic example inputs.

Weigh upDeterministic local checks over supplied evidence; not a guarantee of source truth or production suitability.

Why we selected itPairs a bounded workflow with an offline Python checker and explicitly synthetic example inputs.

Weigh upDeterministic local checks over supplied evidence; not a guarantee of source truth or production suitability.

Why we selected itPairs a bounded workflow with an offline Python checker and explicitly synthetic example inputs.

Weigh upLooks for schema phrases in the excerpt you supply. Negation is not parsed. It does not read amounts. A plain pass is not a vendor quote.

Why we selected itPairs a bounded workflow with an offline Python checker and explicitly synthetic example inputs.

Weigh upDeterministic local checks over supplied rows and caller-assigned seller owners; not a guarantee of source truth or market coverage.

Why we selected itPairs a bounded workflow with an offline Python checker and explicitly synthetic example inputs.

Weigh upChecks explicit claimedScore and named-subject equality only. It does not verify benchmark provenance, source truth or shared measurement conditions.

Why we selected itPairs a bounded workflow with an offline Python checker and explicitly synthetic example inputs.

Weigh upChecks two splits in the excerpt you supply. It does not fetch a page, read amounts, or decide which sentence is the invoice. Batch, region, and input-versus-output are outside this check. A pass is not a vendor quote.

Why we selected itPairs a bounded workflow with an offline Python checker and explicitly synthetic example inputs.

Weigh upReads the excerpt only. A locator is ignored. It does not fetch a page or read amounts. A pass is not a vendor quote.

Why we selected itPairs a bounded workflow with an offline Python checker and explicitly synthetic example inputs.

Weigh upChecks the revision string you supply. It does not fetch a repository, resolve a tag, or prove the tree was read. A pass is not a source review.

Why we selected itPairs a bounded workflow with an offline Python checker and explicitly synthetic example inputs.

Weigh upChecks a conservative status policy only. A 200 result is status-eligible; every other valid status needs review and every quote claim is refused. No status establishes that a response body was received or read; bodyVerified is always false.

Why we selected itPairs a bounded workflow with an offline Python checker and explicitly synthetic example inputs.

Weigh upRequires the explicit observed withdrawnValue and named numeric dependents. It cannot verify withdrawal or discover omitted dependencies; zero remains residue and empty coverage requires review.

Why we selected itSeparates sequential pre-1.8 changes from detected behavior flags and preserves unresolved outside-repository job changes.

Weigh upIts stated target is 1.12, not a promise to reach whichever release is newest. Starting versions 1.3–1.7 have bundles; later versions have narrower flag handling. Parsing alone does not prove migration correctness.

Why we selected itStarts from a verified instance and broadens one abstraction at a time, with explicit false-positive review.

Weigh upPattern matches are candidates, not confirmed vulnerabilities; reachability, sanitization and impact still need review.

Why we selected itEnforces an observability-first pipeline: no source file is inspected until signals.json exists and a deterministic gate names a route, file, or setting, which blocks speculative rewrites.

Weigh upNeeds Vercel project access and usage metrics; without signals the workflow stops by design and produces nothing.

Why we selected itPairs rules with incorrect and corrected code, making recommendations easier to inspect.

Weigh upPublished impact labels and example speedups are not measurements of your application.

Why we selected itShows complete before-and-after component variants rather than only naming the compound-component pattern.

Weigh upContext and compound components can add indirection to a simple component; apply the pattern where variation warrants it.

Why we selected itIncludes worked mobile-specific examples rather than reusing browser performance guidance.

Weigh upThe list rule recommends virtualization even for short lists; that is a prescriptive default, not a measured requirement for every screen.

Why we selected itCovers concrete interaction details such as focus visibility, form labeling, asynchronous announcements and URL state.

Weigh upThe skill fetches a mutable external rules file at runtime; pinning the skill alone does not freeze the guidance.

Why we selected itThree localization approaches keyed to resource type (manifest, walkthrough, code strings) instead of one blanket rule applied to all strings.

Weigh upVS Code extensions only; not a general i18n-framework guide and silent on pluralization, ICU formats and RTL layout.

Why we selected itMeasured findings and code-only hypotheses are kept in separate columns, and the Performance section tracks the Lighthouse move to shared Performance Insights instead of requiring retired audit IDs.

Weigh upIts own reference list points at the sibling accessibility skill withheld in wave 1 over a px-versus-pt contrast-table error; follow this audit's ratio-only checks and current WCAG text instead of that table.

Why we selected itRequires build context and compiler output before attributing a missing wipe to optimization.

Weigh upRead-only target intent does not sandbox compilers or generated checks. Evidence labels and example reports are not independently verified zeroization proofs; AArch64 and unsupported Rust categories require manual review.