bm629

@bm629 source repo

78 skills
0 followers
9 hours ago last updated

▌
Biome · bm629 bundle
Use when setting up or running linting and formatting in a JavaScript or TypeScript project with Biome — the single fast Rust tool that lints, formats, and organizes imports, replacing the ESLint + Prettier pair (the JS analog of Ruff). Covers installing Biome v2, the biome.json config (formatter, linter rule groups, the assist/import-organize actions, VCS integration, overrides, monorepo extends), the CLI (biome check --write, biome ci for CI), migrating from ESLint/Prettier, the v1->v2 deltas (e.g. --apply became --write), and authoring custom lint rules as GritQL plugins. Use when adding a lint/format gate, writing or fixing a biome.json, or porting an ESLint/Prettier setup. Not the Turborepo task wiring (compose with that skill).

0
installs
▌
Tsdoc · bm629 bundle
Use when writing or reviewing TSDoc doc-comments on a TypeScript codebase — the standardized /** ... */ comment grammar (Microsoft's @microsoft/tsdoc) that TypeDoc, API Extractor, and editors parse. Covers what to document (the exported surface: functions, classes, types, React components and props, hooks) and what to skip (private/internal, generated code, trivial cases, prose restating a type); the tag taxonomy categorized into block tags (@param, @returns, @remarks, @example, @defaultValue, @typeParam, @see, @throws, @deprecated), inline tags ({@link}, {@inheritDoc}, {@label}), and modifier tags (@public, @internal, @beta, @alpha, @readonly, @override); the summary-then-@remarks structure; and the key TSDoc-vs-JSDoc rule — do NOT repeat types in comments (the TS types already have them), document intent/behavior. Enforcement is convention-only by default; eslint-plugin-tsdoc is an optional CI pointer. Not TypeDoc-site or Storybook setup (pointers only).

0
installs
▌
Alembic · bm629 bundle
Use when running Alembic database migrations on top of a SQLAlchemy 2.x data layer that targets more than one dialect — SQLite, PostgreSQL, and MySQL — from a single migration history. Covers wiring env.py / alembic.ini to your models' Base.metadata (sourcing the DB URL from the environment, sync-first with a short async run_async_migrations note), the full revision -> autogenerate -> review -> upgrade/downgrade workflow, branching (history / current / heads / merge for multiple heads), and the load-bearing multi-dialect gotcha: SQLite cannot ALTER most schema, so write migrations in BATCH (move-and-copy) style — the same batch_alter_table code emits plain ALTER on PG/MySQL. Also owns the create_all-vs-Alembic decision and the baseline-stamp path off a create_all'd DB. Multi-dialect, portable, sync-first. Not SQLAlchemy model/engine authoring (see sqlalchemy), not job-queue/lease patterns (see sql-job-queue).

0
installs
▌
Sqlalchemy · bm629 bundle
Use when standing up a relational data layer with SQLAlchemy 2.x (2.0/2.1) ORM that must run on more than one dialect — SQLite, PostgreSQL, and MySQL — from a single codebase. Covers the typed 2.x ORM (DeclarativeBase / Mapped[...] / mapped_column), engine + connection-string + pooling, short-lived sessions and transaction scope, the sync-first / async (AsyncSession / await) split with a per-dialect driver matrix, and the cross-dialect gotchas that bite when one schema runs on all three engines: row locking (with_for_update / SKIP LOCKED), JSON columns, upsert (ON CONFLICT vs ON DUPLICATE KEY UPDATE), autoincrement / identity, and transaction isolation. Multi-dialect, portable, ORM-first. Not migrations (see alembic), not job-queue/lease patterns (see sql-job-queue), not a full API reference.

0
installs
▌
Netlify Ops · bm629 bundle
Use when driving Netlify web-hosting directly — creating a site, deploying a build (draft or production), setting + verifying a custom domain, reading deploy status, and listing/inspecting sites/deploys/DNS. CLI-first on the `netlify` CLI (which reads NETLIFY_AUTH_TOKEN and runs headlessly — never `netlify login`) with a REST fallback on Netlify's official OpenAPI at https://api.netlify.com/api/v1 (Authorization: Bearer <token>). Resolves any of the ~174 REST operations from a bundled spec via an endpoint index + a $ref-resolver, with the digest-deploy protocol, rate limits, and site_id conventions handled explicitly. Consumes caller-injected credentials (a token resolved by variable name) — it does not provision or resolve them; the token value is read only by the CLI/curl subprocess, never printed. For Netlify static/JAMstack + serverless hosting, not full-stack container apps.

0
installs
▌
Pydantic V2 · bm629 bundle
Use when defining, validating, serializing, or configuring data with Pydantic v2 in Python — BaseModel, Field constraints, field/model validators, model_dump serialization, pydantic-settings, TypeAdapter, enums, Literal, and discriminated unions — or when fixing code that still uses v1-era idioms (class Config, .dict()/.json(), @validator). Produces correct, idiomatic, current Pydantic v2 code. Keywords: pydantic, BaseModel, ConfigDict, model_validate, validator, settings.

0
installs
▌
Skill Forge · bm629 bundle
Use when you hit a knowledge gap — a topic, library, framework, tool, or domain you need to research, learn, or look up before continuing work. Researches the topic (finding existing published skills as source material, then web research with a verification pass) and synthesizes a focused, portable skills/<slug>/SKILL.md — creating a new skill or improving a related forge-made one. Broad topics that span several skills are handled by recommending and forging multiple skills in parallel. An optional task_context sharpens the research emphasis. Returns the finished SKILL.md inline for immediate same-turn use; the skill is self-contained on disk for future sessions.

0
installs
▌
Motion React · bm629 bundle
Use when adding animation to a React app with the Motion library (the framer-motion successor: npm package `motion`, import `motion/react`) — enter/exit animations, variants and stagger, AnimatePresence, layout and shared-element transitions, animated number tickers, gesture states — or when deciding whether a job needs Motion at all versus plain CSS/Tailwind transitions or AutoAnimate. Covers reduced-motion accessibility (MotionConfig, useReducedMotion, WCAG 2.3.3/2.2.2) as a first-class requirement, performance discipline (transform/opacity only), motion restraint for data-dense product UI, Radix/shadcn and router integration, and keeping tests stable (MotionGlobalConfig.skipAnimations). Keywords: motion, framer-motion, animation, AnimatePresence, layout animation, micro-interactions, reduced motion, page transitions, stagger, spring.

0
installs
▌
Authoring Prd · bm629 bundle
Use when authoring a PRD (product requirements document) for a software or product project — turning a product idea into a comprehensive, plannable requirements doc. Guides the producer through the METHOD, not the outline: grounding the problem in evidence (jobs-to-be-done), defining measurable success metrics with guardrails, drawing a defensible MVP boundary, specifying functional + a non-functional taxonomy with numeric targets, writing testable acceptance criteria, keeping the problem→goal→metric→feature→AC chain traceable, naming dependencies, and surfacing risks + open questions — to a bar an engineer can plan milestones from. Also amends an existing PRD as a versioned, changelogged delta. Composes with a separate PRD template tool (the section structure) and a deep-research capability. Not for reviewing a finished PRD and not for authoring other document types.

0
installs
▌
Design Review · bm629 bundle
Use when about to approve a design document — a spec, plan, design doc, RFC, or ADR — and you want an adversarial pre-approval review that surfaces gaps before sign-off. Hunts recurring gap categories (bootstrap & ownership, naming honesty, scale, hidden assumptions, consistency-with-shipped-code, idempotency/failure, security, necessity, completeness) plus, for a plan, a plan lens (task granularity, dependency-DAG, coverage-vs-spec, exit-criteria testability). Verifies claims against the codebase (file:line, never fabricating); returns findings + a ready-for-approval / has-blockers verdict. Review-only: never edits and never approves — the human decides, the author fixes. Gates generic design docs, RFCs, standalone ADRs, specs, and plans — NOT the doc-library technical-design, architecture-doc + its linked ADRs, data-model, or api-spec artifacts (each routes to its dedicated reviewing-* twin). Keywords: design review, spec/plan/RFC/ADR review, gap analysis.

0
installs
▌
Reviewing Prd · bm629 bundle
Use when reviewing or judging a finished PRD (product requirements document) to decide whether the downstream build can be planned from it — an acceptance gate, not authoring. Judges the PRD against a 12-condition plannability bar: the problem is evidenced (not asserted), users are concrete, success metrics are measurable (with guardrails where gameable), the MVP boundary is defensible, features + acceptance criteria are concrete, non-functional requirements carry numeric targets, the problem→goal→metric→feature→AC chain is traceable (no orphans), dependencies are named, no evidence is fabricated, and open questions are surfaced. Also reviews an AMEND as a delta-scoped review. Emits exactly `VERDICT: approve|revise` plus actionable findings. Approves a PRD that meets the bar (no false-revise on a thin one) and revises only on a real, named gap. Not for authoring or fixing a PRD, not for engineering design docs (specs, ADRs, RFCs), and not for other document types.

0
installs
▌
SQL Job Queue · bm629 bundle
Use when building a DB-backed job queue / task scheduler on SQLAlchemy 2.x whose readiness is dependency-driven, whose jobs are long-running and stateful, and whose only durable substrate is the relational DB — single box, embeddable, no broker, multi-dialect (SQLite / PostgreSQL / MySQL). Covers the generic jobs/job_deps model, the ready-set query, the per-dialect atomic lease (FOR UPDATE SKIP LOCKED on PostgreSQL + MySQL 8 vs BEGIN IMMEDIATE on SQLite, with dialect detection), crash-resume via heartbeat + lease expiry + stale-lease reclaim, the hung-but-alive per-dispatch timeout, weighted fair-share over group_key, the scan→rank→lease→dispatch→persist→reclaim tick loop, polling vs LISTEN/NOTIFY wake, and the at-least-once idempotency contract. Keywords: job queue, task scheduler, ready-set, SKIP LOCKED, lease, crash-resume, multi-dialect, SQLAlchemy, background jobs. Sync-first. Not the SQLAlchemy data layer or locking primitive (sqlalchemy), not migrations (alembic).

0
installs
▌
Github CLI Ops · bm629 bundle
Use when performing a GitHub operation programmatically — creating an issue or pull request, managing repos, releases, labels, Actions runs, Projects, secrets, or any github.com task — preferring the `gh` CLI and falling back to `gh api` (REST) or `gh api graphql` only where no command exists. Every call is authenticated per-invocation with `GH_TOKEN`; it never runs `gh auth switch` and never prints the token. Uses `gh`'s high-level commands (which also encrypt secrets client-side) for coverage and ergonomics; for the REST long tail it builds a `gh api` call from a bundled OpenAPI spec via an endpoint index + a `$ref`-resolver. github.com Cloud; consumes caller-injected credentials (host + a token resolved by variable name) — it does not provision or resolve them.

0
installs
▌
Authoring Hi Fi · bm629 bundle
Use when authoring or amending a high-fidelity UI design AS CODE — each key screen realized as runnable code (standalone HTML+Tailwind by default, React+shadcn when the build stack is React), derived from upstream wireframes + design-system, rendered headlessly and screenshotted, used as a build SEED. Guides the METHOD, not the outline: deriving one screen per wireframe-named screen/state, consuming design-system tokens through a token-to-code map (never inventing a token or raw hex/px), realizing the visual language + objective polish + named aesthetic heuristics to real pixels, rendering real content + every state, running a bounded generate-render-screenshot-vision-review-refine loop, judging numeric WCAG 2.2 AA on the render, and amending as a scoped versioned delta. Composes with a template tool + agent-browser + shadcn + research. Requires a vision-capable runtime. Not for reviewing hi-fi, the screen structure (wireframes), the token system (design-system), or final code.

0
installs
▌
REST API Design · bm629 bundle
Use when designing a REST/HTTP API surface and its contract — choosing resources and URLs, picking HTTP methods and status codes, defining the error model (RFC 9457 problem+json), shaping the success/pagination envelope, versioning, auth, and rate limiting, then expressing the design as an OpenAPI 3.1 contract. This is the design discipline that sits ABOVE a web framework: it produces the decisions and the contract, not the handler code. Keywords: REST API design, HTTP API, resource modeling, status codes, problem details, RFC 9457, pagination, API versioning, rate limiting, OpenAPI 3.1 contract.

0
installs
▌
Reviewing Hi Fi · bm629 bundle
Use when reviewing/judging a finished (or amended) high-fidelity UI design produced AS CODE — an acceptance gate: is the rendered hi-fi a sound build seed? The reviewer RE-RENDERS the code itself (headless browser) and vision-reviews the fresh screenshots — never trusting handed-in images. Judges a single-sourced bar: full coverage vs the wireframes; hi-fidelity + seed-not-over-built; visual execution + objective polish + named aesthetic heuristics (subjective taste never a gap); token-backed/no-DS-drift; real content (no lorem); rendered states; responsive reflow; NUMERIC WCAG 2.2 AA on the render (axe-core + vision, no rule disabled); gaps surfaced; an amend as a scoped versioned delta. Emits `VERDICT: approve|revise` + actionable findings; approves a seed meeting the bar (no false-revise on a thin screen), revises only on a named, rendered gap. Requires a vision-capable runtime. Not for authoring hi-fi, the structure (wireframes), the token system (design-system), or final code.

0
installs
▌
Tanstack Router · bm629 bundle
Use when setting up or using TanStack Router (@tanstack/react-router) in a Vite + React + TypeScript SPA — defining a route tree, end-to-end type-safe navigation, search-param validation, route loaders, code-splitting, preloading, authenticated routes, and the loader-to-TanStack-Query handshake. Produces a working file-based (or code-based) router: createRouter + RouterProvider + the Register augmentation, typed Link / useNavigate / useParams / useSearch, validateSearch, loaders with loaderDeps and deferred data, and a memory-history test harness for routed components. Covers file naming conventions, redirect guards, route masking, scroll restoration, head/meta, and notFound handling. Keywords: TanStack Router, type-safe routing, react router alternative, createFileRoute, search params, route loader, RouterProvider.

0
installs
▌
Jenkins REST Ops · bm629 bundle
Use when driving a Jenkins server's REST (Remote Access) API directly with curl (no SDK) — triggering a build, polling the queue item to a build, reading build status + console log, listing/inspecting jobs, job CRUD (createItem/copy/delete/enable/disable via config.xml), and build management (stop/delete). Jenkins is path-addressed REST authenticated with HTTP Basic username:API_TOKEN. A build trigger is ASYNC — it returns a queue item, not a build, so you poll queue/item/<id>/api/json to the executable. API-token auth is exempt from the CSRF crumb (Jenkins 2.96/2.107+); a crumb is only a 403 fallback. No official Jenkins OpenAPI exists, so the CORE path table is grounded on the official Remote Access docs (the bundled swaggy-jenkins spec is an unofficial cross-check). Consumes caller-injected credentials (base_url + username + a token resolved by variable name) — it does not provision or resolve them; the token value is read only by curl, never printed.

0
installs
▌
UI Illustrations · bm629 bundle
Use when adding illustrations or imagery to a web app UI — empty states, onboarding, error pages (404/500), success moments — or when deciding whether imagery helps or clutters a screen. Covers sourcing from the established free libraries (unDraw, Storyset, LottieFiles) with license compliance, recoloring SVGs to your design tokens so they follow light/dark themes, integrating SVG into React/Vite correctly (inline vs img, layout-shift and bundle discipline), animated imagery (Lottie) with reduced-motion accessibility, and empty-state craft (anatomy, variants, consistency). Keywords: illustration, empty state, imagery, SVG, unDraw, Storyset, Lottie, dark mode illustration, onboarding art, error page illustration, alt text, decorative image.

0
installs
▌
Openapi TS Client · bm629 bundle
Use when generating or regenerating a typed TypeScript client from an OpenAPI 3.1 contract — for example a FastAPI /openapi.json — with @hey-api/openapi-ts. Produces typed models, a typed SDK (one function per operation), TanStack Query hooks, and Zod schemas straight from the spec, so the frontend stays in lock-step with the API instead of a hand-written client. Covers the openapi-ts.config.ts config, the fetch/axios/next clients, the tanstack-query and zod plugins, the regenerate-and-drift-check workflow, and the FastAPI operationId naming fix. Use when wiring an OpenAPI or FastAPI backend to a TS/React frontend, replacing a hand-maintained API client, or adding generated query hooks. Not a TanStack Query usage tutorial (compose with that skill) and not backend/OpenAPI-spec authoring.

0
installs
▌
Atlassian REST Ops · bm629 bundle
Use when calling the Atlassian Cloud REST API directly — Confluence Cloud v2 (pages, spaces, search) or Jira Cloud v3 (issues, JQL search, comments) — to perform operations programmatically, including writes such as creating a Confluence page. Calls REST with curl (no SDK, no pip), authenticating with a Cloud email + API token. Constructs any of the 800+ endpoints from a bundled OpenAPI spec via an endpoint index + a $ref-resolver, with per-API patterns (base URL, pagination, errors, rate limits) and the ADF / storage rich-text formats handled explicitly. Consumes caller-injected credentials (base_url, email, and a token resolved by variable name) — it does not provision or resolve them; the token value is read only by curl, never printed.

0
installs
▌
Authoring API Spec · bm629 bundle
Use when authoring an API specification — the engineering wire contract of an API surface: operations/endpoints, request + response schemas (fields, types, required/optional, constraints), auth, a complete error model, pagination/rate-limits, versioning, and worked examples. Guides the producer through the METHOD, not the outline: rendering the contract in the project's style (OpenAPI for REST, SDL for GraphQL, proto for RPC), typing every field, enumerating the ERROR CASES (not just the happy path), tracing each operation to a feature-spec behavior, and referencing the data-model rather than redefining it — to a bar where a client can call every operation and a server can implement it from the contract alone. Composes with a separate api-spec template tool and a deep-research capability. Assumes the upstream feature-spec (+ architecture-doc + data-model where present) — never a blank page. Not the persistence data-model, the consumer-facing API reference, the implementation, or reviewing a finished api-spec.

0
installs
▌
Polyglot Git Hooks · bm629 bundle
Use when setting up Git hooks for a polyglot or monorepo project with Lefthook — wiring fast format/lint checks on staged files at pre-commit and slower type-check/test gates at pre-push, across mixed-language subtrees (e.g. TypeScript and Python) from a single lefthook.yml, in parallel. Covers install + activation, the lefthook.yml schema (commands/jobs, glob, root, run with {staged_files}/{push_files}, stage_fixed, skip/only, parallel), a genuinely polyglot worked example, the hooks-vs-CI division of labor, and the --no-verify bypass. Teaches the hook wiring; references the per-tool skills (biome, ruff, ty, typescript-typecheck) and turborepo rather than re-teaching them. Keywords: git hooks, pre-commit, pre-push, lefthook, staged files, monorepo hooks, polyglot lint format.

0
installs
▌
Reviewing API Spec · bm629 bundle
Use when reviewing/judging a finished api-spec — the engineering wire contract (operations, request/response schemas, auth, error model, pagination, versioning, examples) — to decide if a client can call every operation and a server can implement it from the contract alone. An acceptance gate, not authoring. Judges a single-sourced 11-condition contract-completeness bar: style + base + versioning + deprecation policy; every operation listed + traced; every operation fully typed both sides + status codes (happy-path-only fails); auth + per-operation authorization; a complete error model (one shape + every failure case + retryability); shared types referencing the data-model; pagination + a tie-breaker; examples matching the schemas; one-directional vs the api-reference; consistent with the shipped API; delta-scoped amend. Style-agnostic (REST/GraphQL/gRPC, no OpenAPI reflex). Emits exactly `VERDICT: approve|revise`. Not authoring, the data-model, the api-reference, or generic design docs (design-review).

0
installs
▌
Token Optimization · bm629 bundle
Use when you need to reduce token usage, lower API cost, fit work within a context window, or speed up an expensive/slow agent loop. Triggers on phrases like "optimize tokens", "reduce token usage", "save on cost", "fit in context", "context too long", "running out of tokens", "prompt caching", "compact the context", "agent is too expensive", "shrink the prompt", "cheaper model", "tokens-per-task". Provides a layered tactic catalog — measurement (heuristic counting and budget allocation), prompt-side levers (caching, system-prompt diet, tool-definition pruning), context management (compression, observation masking, file-system offload), agent-loop patterns (parallel tool calls, batch operations, model routing by complexity), and output-side controls (depth tiers, stop sequences, structured output). Project-agnostic and provider-agnostic; works across Claude Code, Codex CLI, Cursor, Gemini CLI, and Copilot.

0
installs
▌
Authoring Test Plan · bm629 bundle
Use when authoring or amending a test plan / QA verification plan — what to test, at what level, to what done-criteria, and the cases to run. Guides the METHOD, not the outline: deriving every case from a feature-spec behavior/AC or api-spec operation/error (never inventing one); the functional levels the project warrants; RISK-WEIGHTED catalog sizing (BVA/equivalence/decision-table/state-transition/pairwise, not the cross-product); a non-functional taxonomy (perf/security/accessibility WCAG 2.2 AA/compat/i18n) each with a numeric target where warranted; metric-threshold-on-a-named-dataset cases for ML/probabilistic behavior; and amending as a versioned delta with impact+risk regression selection — to a bar where a tester executes it with no questions, every behavior traced. Composes with a template tool + deep-research; consumes handed-in upstreams (feature-spec/api-spec/PRD/NFRs), never a blank page. Specs the cases, not the scripts; not the runbook, not the behavior contract, not reviewing one.

0
installs
▌
Ml Prior Art Survey · bm629 bundle
Use when surveying the published ML artifact corpus before deciding whether to call an API, fine-tune, or train from scratch — minting the ML task vocabulary map, or executing ONE search angle across model registries, dataset and training corpora, published evaluation tables, preprint listings, hosted-inference catalogues and pricing, training-cost figures, safety and responsible-AI evaluations, serving-performance measurements, and on-device runtime formats. Then deep-reading ONE admitted artifact into an extract record, and building the option register through seven lenses whose spine is an adoption ladder — the first admissible rung, with every rung above it explained by naming the artifact that failed. Records every query as run, so an option that does not exist is distinguishable from a search that never ran. Keywords: ML prior art, model selection, build vs buy, HuggingFace, benchmark, leaderboard, dataset survey, fine-tuning cost, inference pricing, model card.

0
installs
▌
Reviewing Test Plan · bm629 bundle
Use when reviewing/judging a test plan / QA verification plan — deciding whether a tester can execute it and every behavior is covered. A gate, not authoring. Judges it against a single-sourced 10-condition bar: every handed-in upstream behavior (feature-spec/api-spec ops+errors, else PRD) has >=1 TRACEABLE case; functional levels fit; entry/exit testable (coverage floor + open-defect threshold); environments + test data specified; each case has preconditions + steps + observable result (a metric-threshold-on-a-dataset for ML) + traces-to; the catalog is RISK-WEIGHTED (coverage gap, padded/thin, OR combinatorial blow-up = a finding); each warranted non-functional type (perf/security/WCAG 2.2 AA/compat/i18n) carries a target; an amend is reviewed delta-scoped; nothing fabricated. Emits exactly `VERDICT: approve|revise` + actionable findings; approves a proportionally-sized plan, revises only on a named gap. Not for authoring it, the release runbook, design-review, or the test scripts.

0
installs
▌
Authoring Data Model · bm629 bundle
Use when authoring a data model document — the persistence/domain model of stored data: typed entities, relationships + cardinality, keys/constraints, indexes, normalization, the storage choice, and lifecycle. Guides the producer through the METHOD, not the outline: deriving entities from the feature-spec's nouns + access patterns, detecting the paradigm and modeling in it (relational, document/NoSQL access-pattern-first, graph, wide-column, key-value), making integrity rules explicit (keys, constraints, cardinality + referential rule), justifying each index by an access pattern, and amending an approved model as a versioned, migration- planned delta — so an engineer can build + query the schema. Composes with a data-model template tool + a deep-research capability. Assumes the upstream feature-spec (+ architecture-doc) — never a blank page. Not the API wire contract (the api-spec references these entities downstream, one-directional), not the implementation/DDL, and not reviewing a finished data model.

0
installs
▌
Authoring User Flows · bm629 bundle
Use when authoring a user-flows document — the map of the paths a user takes through a product to accomplish each goal: entry points + the navigation/IA frame, the happy path, decision branches, error/recovery + edge states (incl. loading + success), interaction resilience (undo/resume/system-status), flow-level accessibility, and the screens/states traversed, each flow traced to a goal/persona job. Guides the METHOD, not the outline: deriving flows from upstream goals + prior-art patterns (never inventing them), enumerating every branch + error path so no path dead-ends, judging flow quality with objective heuristics, rendering each flow as a synced diagram + numbered narrative, and amending an existing doc as a scoped versioned delta. Composes with a separate user-flows template tool and a research capability. Assumes an approved PRD as upstream input — never a blank page. Not for reviewing a finished user-flows doc, not for screen layout/wireframes, and not for authoring the PRD itself.

0
installs
▌
Authoring User Guide · bm629 bundle
Use when authoring an end-user product guide — the consumer-facing help a typically non-technical person reads to accomplish goals with a product: a getting-started tutorial, task how-to guides, conceptual explanation, an end-user feature/settings/CLI reference (NOT the HTTP API), troubleshooting/FAQ, and a glossary. Guides the METHOD, not the outline: one how-to per user goal from the handed-in upstreams (never invented), the four Diataxis modes kept distinct, every step accurate and named by its exact UI label, plain language for a non-technical reader (no unexplained jargon), an accessible and findable guide, and amending a published guide as a versioned staleness sweep — to a 12-condition usability + accuracy bar. Composes with a user-guide template tool + a research capability. Assumes the handed-in upstreams (feature-spec + user-flows + wireframes) — never a blank page. Not the developer-tool adoption guide (developer-guide), the endpoint catalog (api-reference), or reviewing a finished guide.

0
installs
▌
Authoring Wireframes · bm629 bundle
Use when authoring or amending a wireframes document — the low-to-mid-fidelity STRUCTURAL design of each key screen (layout regions on a grid + shared app-shell, content hierarchy, components, affordances, content/microcopy intent, the per-screen empty/loading/populated/error/success states, screen-composition accessibility), as a textual/annotated wireframe (ASCII sketch + annotations), NOT a pixel mockup. Guides the METHOD, not the outline: deriving the screen list from the upstream user-flows (one wireframe per flow-named screen/state), composing each screen to an objective layout-quality bar, grounding it in established UI patterns, referencing a design-system's real components, owning screen-composition a11y (design-system owns the per-component contract), and amending as a scoped versioned delta — to a bar an engineer can build the screen structure from. Composes with a template tool + research. Not for reviewing a wireframes doc, hi-fi visual design, the navigation graph (user-flows), or other types.

0
installs
▌
Cloudflare Pages Ops · bm629 bundle
Use when driving Cloudflare Pages web-hosting directly — creating a Pages project, deploying a build, adding a custom domain, reading deployment status, and listing/inspecting projects/deployments/domains. CLI-first on the Wrangler CLI (which reads CLOUDFLARE_API_TOKEN + CLOUDFLARE_ACCOUNT_ID and runs headlessly — never `wrangler login`) with a REST fallback on Cloudflare's official API at https://api.cloudflare.com/client/v4 (auth Authorization: Bearer <scoped token>; every path account-scoped under /accounts/{account_id}/pages/...). Resolves the Pages REST operations from a bundled OpenAPI slice via an endpoint index + a $ref-resolver, with the response envelope, deploy stage machine, and multipart-deploy + Direct-Upload-vs-Git caveats handled explicitly. Consumes caller-injected credentials (account_id from context + a token by variable name) — it does not provision them; the token is read only by the Wrangler/curl subprocess, never printed. Static/JAMstack + serverless, not full-stack container apps.

0
installs
▌
Reviewing Data Model · bm629 bundle
Use when reviewing/judging a finished data-model document (the persistence/ domain model — entities, keys, relationships, indexes, normalization, lifecycle) to decide if an engineer can build the schema + query it correctly — an acceptance gate, not authoring. Judges it against a single-sourced 9-condition integrity + queryability bar: entities typed + keyed (stored shape, not the api-spec DTO); relationships carry cardinality + a referential rule (on-delete / embed-vs-reference); every index traces to an access pattern; normalization + paradigm choice + tradeoffs; lifecycle + migration; diagram ⇄ tables in sync; privacy/scale; one-directional vs the api-spec + consistent with the shipped schema; amend delta-scoped. Paradigm-aware (relational/document/graph/wide-column/key-value — never a relational reflex). Emits exactly `VERDICT: approve|revise` — approves a model meeting the bar, revises on a named gap. Not for authoring, the api-spec/feature-spec, or generic design docs (use design-review).

0
installs
▌
Reviewing User Flows · bm629 bundle
Use when reviewing/judging a finished user-flows document to decide whether a downstream wireframing pass can enumerate every screen and whether each path is complete, walkable, resilient, accessible, and sound — an acceptance gate, not authoring. A user-flows doc is the navigation/interaction graph: entries + IA frame, happy path, branches, error/recovery + edge states, resilience, flow-level accessibility, screens traversed. Judges it against a single-sourced bar: goals map to flows (no orphans), entries+exits defined, branches resolve, no dead ends, states (incl. loading+success) covered, irreversible actions guarded, every path keyboard/ AT-completable, the flow objectively sound, notations synced, screens enumerable; plus a delta-scoped review when amending. Emits exactly `VERDICT: approve|revise` with actionable findings. Approves a doc meeting the bar (no false-revise on a thin one), revises only on a named gap. Not for authoring, not for wireframes, not for the PRD.

0
installs
▌
Reviewing User Guide · bm629 bundle
Use when reviewing/judging an end-user product guide — the consumer-facing help a typically non-technical person reads to accomplish product goals (tutorial, how-tos, explanation, a product feature/settings reference, troubleshooting, glossary) — deciding whether a real user can accomplish every supported goal from the guide alone. A gate, not authoring. Judges a single-sourced 12-condition usability + accuracy bar: one how-to per goal; the four Diataxis modes correctly typed (not conflated); a complete product reference (NOT the HTTP API); accurate steps named by their exact UI label; symptom-keyed troubleshooting; plain language a non-technical reader can follow; accessibility + findability; surfaced assumptions, no fabrication; a delta-scoped amend. Emits exactly `VERDICT: approve|revise` plus actionable findings; approves a guide meeting the bar (no false-revise), revises only on a named gap. Not authoring it, the developer adoption guide, the endpoint catalog, or engineering design docs (design-review).

0
installs
▌
Reviewing Wireframes · bm629 bundle
Use when reviewing/judging a finished (or amended) wireframes document — an acceptance gate: can the downstream hi-fi + UI engineering build the screen structure from it. Judges a TEXTUAL markdown wireframe against a single-sourced buildability + coverage + composition bar: every flow-named screen/state covered with quality states; layout unambiguous on a grid + shared app-shell meeting an objective layout-quality bar; real + consistent components; affordances + data-display annotated; microcopy intent (no data-model leak in labels); screen-composition a11y (landmarks/focus-order/target-size) — pixel contrast/focus-appearance are the design-system's, not judged here; responsive; gaps surfaced; structural not hi-fi; an amend reviewed as a scoped versioned delta. Emits `VERDICT: approve|revise` + actionable findings; approves a doc meeting the bar (no false-revise on a thin screen), revises only on a named gap. Not for authoring, the navigation graph (user-flows), the visual tokens (design-system), or hi-fi.

0
installs
▌
Typescript Typecheck · bm629 bundle
Use when setting up or running TypeScript type-checking as a standalone quality gate — writing or tightening a strict tsconfig.json, adding a `tsc --noEmit` (or `tsc -b --noEmit`) check that runs separately from the build, wiring that check into CI, or configuring TypeScript project references for a multi-package (pnpm/Turborepo) monorepo. Covers why a dedicated type-check gate is mandatory (bundlers and transpilers strip types without checking them), the strict compiler-option set worth enabling beyond `strict: true`, the Vite split-config layout, and cross-package type resolution via composite project references. TypeScript 5.x.

0
installs
▌
Code Prior Art Survey · bm629 bundle
Use when running a systematic open-source prior art survey for a software idea — deriving a keyword map (typed search vocabulary) or executing one search angle of repository discovery across code hosts, package registries, curated catalogs, code search, alternative directories, and community channels. Produces schema-validated artifacts: a keyword-map file or a per-angle search-output file with reproducible coverage records and candidate repositories — or deep-reading one candidate into an EXTRACTION (a 10-section analysis + a machine-readable verdict/score/license/deps block). Keywords: prior art, open source search, repository discovery, keyword map, code extraction, competitor alternatives. Covers the survey's SEARCH wave (keyword-map derivation + angle execution), the EXTRACT wave, and the SYNTHESIS wave (aggregating extractions into a report + a borrow-index).

0
installs
▌
Authoring Feature Spec · bm629 bundle
Use when authoring a feature specification (functional spec) — elaborating the features a PRD names into implementable, testable detail. Guides the METHOD, not the outline: tracing each feature to a PRD goal; specifying observable behavior (use-case flows, EARS); enumerating I/O, a state-transition table, and decision tables for combinatorial rules; covering edge cases + errors with their handling; writing testable Given/When/Then (or metric-threshold, for probabilistic/ML) acceptance criteria; applying a per-feature non-functional-requirement taxonomy keyed to the feature archetype (UI/API/data-ML/batch/integration/CLI); and amending an approved spec as a versioned, ripple-analyzed delta — to a bar an engineer can build and a tester can verify each feature from. Composes with a feature-spec template tool + a deep-research capability. Assumes the approved PRD as upstream input — never a blank page. Not for authoring the PRD, reviewing a finished feature spec, or engineering design docs (ADR/RFC).

0
installs
▌
Reviewing Document Set · bm629 bundle
Use when judging a SET of finished project documents as one corpus, to decide whether they are mutually coherent and ready to plan from — the corpus-level analog of a single-document design review. Assumes each document passed its own gate; judges only how they relate, against an eight-dimension bar: cross-document consistency (incl. one name per entity); completeness/traceability from the upstream-most doc (no dropped/orphaned items or TBDs); contradictions; dependency integrity; divergent duplication; ready-to-plan sufficiency (Definition-of-Ready + a referenced-but-absent doc); amend/delta-scoped re-review when a doc changed (ripple to its dependents); and version-skew (a doc citing a stale version of another). Emits exactly one terminal `VERDICT: approve|revise` for the whole set, each finding prefixed with the affected document id(s). Approves a coherent corpus (no false-revise); revises only on a real, named cross-document gap. Not for one document's internal quality, nor authoring or fixing them.

0
installs
▌
Reviewing Feature Spec · bm629 bundle
Use when reviewing/judging a finished feature specification to decide if engineering can plan and build from it — an acceptance gate, not authoring. Below the PRD. Judges it against a single-sourced 10-condition implementability + testability bar: each feature traces to a PRD need (no orphans/gaps); behavior unambiguous + observable; I/O + states complete (a state-transition table where stateful); each edge case names its handling; acceptance criteria testable (Given/When/Then, or a metric-threshold for a probabilistic/ML feature); singular + consistent; load-bearing non-functional requirements carry numeric targets; an amend reviewed delta-scoped; open questions surfaced. EARS, decision tables, and archetype overlays are authoring aids judged by outcome, never demanded. Emits exactly `VERDICT: approve|revise` plus findings — approves a spec meeting the bar (no false-revise on a thin one), revises only on a real, named gap. Not for authoring, the upstream PRD, design docs (ADR/RFC), or other types.

0
installs
▌
Scale Prior Art Survey · bm629 bundle
Use when surveying how comparable systems actually behaved under load before a design commits to a scaling approach — minting the scale vocabulary map, executing ONE search angle across engineering narratives, systems literature, the operational canon, tail-latency and consistency evidence, incidents, capacity envelopes, benchmarks, inference serving and multi-tenancy, then extracting one source's episodes and synthesising the scale envelope index. Records every measurement with the configuration it was taken under and the band it was measured at, refuses a claim with no stated date because what ages is the hardware generation underneath it, and produces schema-validated artifacts whose coverage grid records every query as run — so a system nobody has published about is distinguishable from a search that never ran. Keywords: scale prior art, load testing evidence, tail latency, post-mortem, capacity limits, benchmark, consistency model, multi-tenancy, scale envelope.

0
installs
▌
Authoring API Reference · bm629 bundle
Use when authoring (or amending) a published, consumer-facing API reference — the docs an integrating client developer reads to call an API. Guides the producer through the METHOD, not the outline: deriving every endpoint, field, and error from the upstream api-spec contract (never fabricating one), grounding onboarding + examples in established public-API-docs practice, authoring prose-first yet adapting to OpenAPI-generated catalogs, documenting auth flows, errors, rate-limits, pagination + deprecation, and keeping the reference consistent with the contract — so a developer can authenticate and integrate every operation from the reference alone. Amends an existing reference as an upstream-driven re-sync when the contract changes, with a doc version + amend log. Composes with an api-reference template tool + deep-research. Assumes the upstream api-spec — never a blank page. Not the engineering wire contract (api-spec), not the end-user guide, not reviewing one.

0
installs
▌
Authoring Design System · bm629 bundle
Use when authoring a design-system document — the reusable visual + interaction language a product's UI draws on: principles, design tokens (color, typography, spacing, elevation, motion, iconography) in the W3C DTCG format, a component catalog, patterns, layout + internationalization conventions, WCAG 2.2 AA accessibility, voice, and lifecycle/governance. Guides the METHOD, not the outline: grounding tokens/components in established practice, naming tokens by intent in a primitive/semantic/component tiering, theming via alias-swap (light/dark + multi-brand), sizing the catalog to the archetype, specifying each component with anatomy + states + variants + usage + accessibility, and amending an existing system as a scoped, versioned delta. Composes with a design-system template tool + deep-research. Targets a textual markdown artifact, not rendered swatches. Not for reviewing a design system, not per-screen layout (wireframing), not a coded component library.

0
installs
▌
React Component Testing · bm629 bundle
RTL + MSW + vitest-axe component-test layer for a Vite + React + TypeScript SPA under Vitest. Use when writing or setting up component tests that render a real component tree, drive it as a user does (React Testing Library + user-event), mock the NETWORK boundary (Mock Service Worker v2 — not the module), and assert the rendered output is accessible (vitest-axe toHaveNoViolations). Covers the jsdom test environment (explicitly not happy-dom, which breaks axe), accessible-query priority, the always-await user-event v14 rule, async findBy/waitFor, the MSW setupServer lifecycle, intercepting a generated @hey-api/openapi-ts client at the fetch layer, a per-test TanStack Query QueryClientProvider with retry:false, and form + request-body + a11y assertions. The middle of the test pyramid: above Vitest unit tests, below Playwright e2e.

0
installs
▌
Reviewing API Reference · bm629 bundle
Use when reviewing/judging a published, consumer-facing API reference an integrating developer calls an API from — deciding if they can integrate from it. A gate, not authoring. Judges against a single-sourced 11-condition usability + contract-consistency bar: getting-started + auth reach a first call; every api-spec operation (incl. events/webhooks) is documented with purpose + typed params + a worked example + errors; errors first-class; rate-limits + pagination documented where applicable; versioning + deprecation/sunset stated; the reference is CONSISTENT WITH THE HANDED-IN api-spec (no drift, no fabricated endpoint — the load-bearing check); samples runnable; an amendment re-syncs to the changed contract. Emits exactly `VERDICT: approve|revise` plus actionable findings; approves a proportionally-sized reference, revises on a named gap. Not authoring it, not the end-user user-guide, not the developer-adoption guide, not the engineering api-spec (reviewing-api-spec).

0
installs
▌
Reviewing Design System · bm629 bundle
Use when reviewing or judging a finished design-system document — a product's reusable visual + interaction language — deciding whether an engineer can build a consistent, accessible UI from it. Reviews an AMEND delta-scoped. A gate, not authoring. Judges against a single-sourced usability/consistency/accessibility bar: tokens DTCG-typed and referenced by intent, not raw values; components fully specced in one API vocabulary; the catalog covers the screens' components plus an archetype-sized standard set; accessibility numeric (WCAG 2.2 contrast, focus appearance, target size, keyboard); i18n addressed or scoped out; governance present above its threshold; nothing fabricated. Emits exactly `VERDICT: approve|revise` plus actionable findings, and does not false-revise a proportionally-sized system. Not for authoring it, not per-screen layout, not navigation paths, not engineering design docs.

0
installs
▌
Visual Prior Art Survey · bm629 bundle
Use when surveying the DOCUMENTED visual and interaction conventions of a product's domain BEFORE any wireframe, design system or hi-fi screen is produced — deriving a UI-pattern vocabulary map, executing ONE search angle across design-system documentation, the ARIA Authoring Practices Guide, WCAG success criteria, platform human-interface guidelines and the deceptive-pattern corpus, deep-reading ONE convention source into a record, or synthesising the convention register and report the downstream design skill consumes. Mines documentation, never screenshots. Produces schema-validated artifacts whose coverage grid records every query as run, so a domain with no documented convention is distinguishable from a search that never ran. Carries a design system's DTCG tokens verbatim, never blended. Keywords: visual prior art, design system research, UI patterns, interaction conventions, accessibility criteria, design tokens, dark patterns.

0
installs
▌
Content Template Gateway · bm629
Use when anyone (user or agent) is about to author any structured content — RFC, ADR, runbook, spec, plan, PRD, README, retrospective, blog post, PR description, issue body, ticket, multi-paragraph commit message, announcement, or any other shape — regardless of destination (local file, GitHub, Jira, Linear, Slack, email, Confluence, Notion, Google Drive, etc.). This skill is the gate every content-authoring action passes through. It (1) identifies content-type + variant from intent via research, (2) checks docs/templates/<content-type>/<variant>/ for an existing template, (3) if it exists, returns it plus a hard-refusal directive that you MUST follow, (4) if missing, forges a new one via research, then returns it under the same directive, (5) on "advise:" intent, helps place content that doesn't fit (maps to sections or proposes new variant). Modes: use-or-create (default), force-regenerate, force-new-variant. Self-contained: prefers a research-capable skill if available, else built-in WebSearch + WebFetch.

0
installs
▌
Authoring Developer Guide · bm629 bundle
Use when authoring or amending developer-tool documentation — the adoption + integration narrative for an SDK, library, CLI, framework, or API platform: the guide a developer reads to install, integrate, and operate the tool. Guides the METHOD, not the outline: developer GOALS not endpoints; a signposted start-here + a fast verifiable first success; concepts before recipes; goal-named runnable recipes; an end-to-end tutorial; grounded best-practices; a troubleshooting path; archetype-aware emphasis (API/SDK/CLI/framework); POINTERS into — never a copy of — the api-reference; and amending a guide as a versioned delta that sweeps the tool's changes for stale samples. Full Diataxis correctly typed, every sample runnable + accurate to the tool, nothing fabricated. Composes with a template tool + deep-research. Consumes the handed-in feature-spec + api-reference + PRD — never a blank page. Not the api-reference catalog, the end-user user-guide, engineering docs, or reviewing one.

0
installs
▌
Authoring Release Runbook · bm629 bundle
Use when authoring or amending a release/deployment runbook: the go-to-production procedure for shipping a system to production safely. Guides the METHOD, not the outline: grounding it in SRE/operational practice, deriving deploy steps from the architecture-doc + technical-design rollout and verification from the test-plan exit criteria, writing idempotent copy-paste-safe steps each with an expected result, defaulting the deploy strategy to blue-green, sequencing a stateful change as a backward-compatible expand-contract migration (roll-forward if irreversible), giving every forward change a documented revert with measurable triggers, naming the comms window for a user-impacting deploy, and amending the living runbook as a versioned re-validated delta — to a bar where an unfamiliar engineer can deploy, confirm, and roll back from it alone, no secret inlined and nothing fabricated. Composes with a template tool + deep-research. Not the CI/CD pipeline config (cicd-plan), not a post-mortem, not reviewing one.

0
installs
▌
Reviewing Developer Guide · bm629 bundle
Use when reviewing or judging a finished or amended developer guide — the adoption + integration narrative for a developer-tool product (SDK/library/CLI/framework/API platform). Decides whether a developer can install, integrate, and operate the tool from the guide alone. A gate, not authoring. Judges it against a single-sourced 14-condition adoptability + accuracy bar: a signposted start-here + a verifiable first success; concepts before recipes; how-tos cover the handed-in scenarios; samples runnable + accurate to the CURRENT tool (no fabricated/stale endpoints); LINKS INTO the api-reference, never duplicates it; Diataxis modes typed; a troubleshooting path; an amend reviewed delta-scoped. Emits exactly `VERDICT: approve|revise` + actionable findings; approves a guide meeting the bar (no false-revise on a thin one), revises only on a named gap. Not for authoring it, the end-user user-guide, the endpoint catalog (api-reference review), or engineering design docs (design-review).

0
installs
▌
Reviewing Release Runbook · bm629 bundle
Use when reviewing/judging a release runbook (the go-to-production procedure for shipping a system to production) — deciding whether an unfamiliar engineer can execute, verify, and roll back from it alone. A gate, not authoring. Judges a single-sourced 11-condition executability + safety bar: every step copy-paste-safe + idempotent with an expected result; a go/no-go gate; a complete rollback (a revert per forward change, measurable triggers, roll-forward if irreversible); post-deploy verification reusing the test-plan criteria; escalation + monitoring; NO secret inlined (an embedded token/key is a finding); stateful-change safety (proportional); a comms window for a user-impacting deploy (proportional); commands spot-checked against the upstreams; nothing fabricated; a delta-scoped amend. Emits `VERDICT: approve|revise` + actionable findings; approves a runbook meeting the bar (no false-revise), revises on a named gap. Not authoring it, not the QA test-plan, not engineering design docs (design-review).

0
installs
▌
Security Prior Art Survey · bm629 bundle
Use when surveying documented security prior art for a product BEFORE it is built — deriving a threat-vocabulary map (translating a product's surfaces into the terms security corpora index), executing one search angle across weakness and attack-pattern taxonomies (CWE, CAPEC, ATT&CK), vulnerability registries (CVE/NVD, OSV, GitHub Advisory), exploitation-evidence catalogs (KEV, EPSS, Exploit-DB), vendor advisories (CSAF/VEX), incident corpora (VERIS) and control standards (OWASP ASVS, Top 10, MASVS) — or deep-reading ONE source item into an extraction whose evidence tier carries its receipts. Produces schema-validated artifacts with status-typed coverage records and mandatory zero-hit cells. Keywords: security prior art, threat research, vulnerability survey, attack patterns, CVE, CWE, CAPEC, OWASP, KEV, EPSS, advisories, supply chain. Covers the SEARCH, EXTRACT and SYNTHESIS waves.

0
installs
▌
Authoring Architecture Doc · bm629 bundle
Use when authoring a software/system architecture document — the whole-system structure: context and scope, the major components/services and their responsibilities, the interaction topology and integration boundaries, the significant technology choices and their rationale, and how the system realizes its non-functional/quality targets. Guides the producer through the METHOD, not the outline: scoping the boundary first, naming a responsibility per component, justifying each significant tech choice, giving every NFR target a realization, and recording each key decision as a STANDALONE, LINKED ADR file (the doc carries only a decisions index). Composes with a separate architecture-doc template tool AND an ADR template tool (section structure), plus a deep-research capability. Assumes the approved PRD + product direction as input — never a blank page. Not for reviewing a finished architecture doc, not for one feature's implementation design (a technical-design doc), and not for the API contract or data schema.

0
installs
▌
Authoring Technical Design · bm629 bundle
Use when authoring (or amending) a technical-design document (a TDD / engineering design doc / design RFC) for one feature or component — the detailed implementation design for building it within an existing system. Guides the METHOD, not the outline: grounding the design in established practice and the project's real constraints, tracing every decision bidirectionally to a requirement, comparing at least one real (non-strawman) alternative with a stated decision criterion, referencing the architecture-doc / API spec / data-model rather than duplicating them, naming the failure modes, the observability signals, the testing, and the rollout — and amending an approved design as a versioned, ripple-analyzed delta — to a bar where an engineer can implement without re-deriving the design. Assumes the approved PRD + feature-spec as upstream input, never a blank page. Not for system-wide architecture, not for the API contract or data schema, and not for reviewing a finished TDD.

0
installs
▌
External Content Sanitizer · bm629 bundle
Use when about to consume content from any external/untrusted source — files from externally-cloned repos, WebSearch results, WebFetch responses, or fetched files. Identifies and neutralizes prompt-injection attempts via hybrid regex + LLM detection. Returns sanitized content plus a structured report. Maintains a persistent flagged-sources document at docs/security/flagged-sources.md that turns repeat-offender sources into automatic caution-bumps. Severity-keyed action: low and medium are removed (replaced with [REMOVED: marker]), high aborts the whole sanitization. Flagged content is never echoed back to the caller. One layer of defense in depth — combine with synthesis guard rails and user review. Hand-authored, security-critical.

0
installs
▌
Project Document Discovery · bm629 bundle
Use when deciding which documents a software or product project needs to produce — classifies across 10 dimensions, identifies product capability areas (4-signal algorithm), and produces a proportional, capability-scoped manifest with all five sections populated (documents, roles, skills, tools, capabilities). Re-tailors when the project changes (amend). Covers the full SDLC universe (seven lifecycle bands + four domain overlays). Returns a three-key JSON payload; caller writes two files from it (capability-map.yaml + manifest.yaml) — never assumes scope_root. Discovery only: decides which documents and what it takes to produce them, not how to author them. Keywords: document discovery, documentation plan, SDLC documents, document manifest, capability map, proportional docs, manifest completeness.

0
installs
▌
Reviewing Architecture Doc · bm629 bundle
Use when reviewing/judging a finished whole-system architecture document (+ its linked ADR files) to decide if an engineer can grasp the system and place a feature's TDD within it — an acceptance gate, not authoring. Judges a single-sourced 10-condition bar: boundary + external deps + concerns; components single-responsibility at whole-system altitude (not api-spec/data-model or feature-TDD detail); diagrams ⇄ narrative agree; every significant decision a standalone LINKED, immutable ADR (one per file, index in sync, supersede not edit); decisions traced + justified; NFR targets realized + tradeoffs named; cross-cutting (resilience/security/privacy/observability) addressed; ASRs covered; nothing fabricated, claims consistent with the code; amend delta-scoped. C4/arc42/ATAM/4+1 are aids judged by outcome. Emits exactly `VERDICT: approve|revise` (no false-revise on a thin doc). Not for authoring, the PRD, api-spec/data-model, a feature's TDD, or generic design docs/RFCs/standalone-ADRs (use design-review).

0
installs
▌
Reviewing Technical Design · bm629 bundle
Use when reviewing/judging a finished technical-design document (a TDD / engineering design doc / design RFC) for one feature, deciding whether an engineer can implement it without re-deriving the design. An acceptance gate, not authoring. Judges a single-sourced 11-condition implementability bar: every decision traces bidirectionally to a requirement; scoped to one feature; approach and decomposition implementable, diagram synced to narration; interfaces an api-spec or data-model owns are referenced, not duplicated; one real alternative with a decision criterion; failure modes carry handling; observability signals named; testing covers failures and contract conformance; rollout and rollback with measurable triggers; nothing fabricated; an amend reviewed delta-scoped. Emits exactly `VERDICT: approve|revise` plus findings, and does not false-revise a thin-but-complete TDD. Not for authoring, the upstream PRD or feature-spec, the api-spec or data-model, or generic design docs and RFCs.

0
installs
▌
Regulatory Prior Art Survey · bm629 bundle
Use when surveying the regulatory obligations that bind a product before deciding its architecture — minting the regulatory scope map, or executing ONE search angle across primary-law registers, regulator guidance and enforcement decisions, control catalogs and numbered standards, AI-governance instruments, accessibility law, platform and intermediary obligations, cross-border-transfer instruments, and financial and payments rules. Then deep-reading ONE instrument into its obligations, and building the regulatory register — applicable instruments, merged architecture mandates, and the conflicts it escalates rather than resolves. Mines the ISSUING BODY'S OWN published text, never a restatement, and produces schema-validated artifacts whose 2-D coverage grid records every query as run — so an obligation that does not exist is distinguishable from a search that never ran. Keywords: regulatory prior art, compliance obligations, GDPR, HIPAA, AI Act, DSA, PSD2, accessibility law, data residency, control catalog.

0
installs
▌
Python Monorepo Architecture · bm629 bundle
Use when architecting or splitting a Python repository into a multi-package uv-workspace monorepo — a shared internal library plus one or more app or CLI members that depend on it — and you need the cross-package boundaries right: which code becomes a shared lib vs an app member, the acyclic depend-inward dependency direction (apps depend on the core lib, never on each other), the import-isolation discipline uv cannot enforce, each member's public API at the package boundary, cross-member test layout, and safely extracting shared code out of an existing package. Covers uv workspace wiring (members, tool.uv.sources, single lockfile, --package) and composes with the uv and python-project-structure skills. Keywords: monorepo, uv workspace, multi-package, shared library, package boundaries, dependency direction, circular import, import-linter.

0
installs
▌
Reviewing Document Discovery · bm629 bundle
Use when judging a produced document PLAN — a manifest of which documents a project will produce, each with producer/tools/skills/depends_on — to decide if it is sound enough to produce from. An acceptance gate, not authoring. Judges a fourteen-condition bar single-sourced with project-document-discovery's Self-check (v6.0.0): proportional; load-bearing present; production reqs + depends_on per doc; acyclic graph; no orphan (leaf deliverables like LICENSE/README exempt); no padding; open-ended preserved; change-scoped amend delta; skills carry purpose/requirements; capability_map + product_capabilities keys valid; manifest nested with fan-out entries matching flags; all five manifest meta-sections populated (capabilities/roles/skills/tools not empty, no build-level capabilities); capability scalar on every document entry (not array). Emits exactly one terminal VERDICT: approve|revise. Review-only — not a document's internal quality, not the coherence of finished documents (reviewing-document-set).

0
installs
▌
Integrations Prior Art Survey · bm629 bundle
Use when surveying the third-party integration surface a product will need before deciding its architecture — minting the integration vocabulary map, or executing ONE search angle across connector catalogs, machine-readable API descriptors, first-party integration directories, package-registry SDK adoption, event and webhook delivery conventions, regulated-integration constraints, unified-API abstractions, and MCP channels — then deep-reading ONE admitted service into an extract record, and synthesising the corpus into the integration register through eight lenses whose denominators are recorded rather than assumed. Keys every candidate on the vendor's own host, quotes the first-party descriptor rather than a catalog's restatement, and records every query as run — so a service that no catalog carries is distinguishable from a search that never ran. Keywords: integrations prior art, connector catalog, OpenAPI descriptor, webhook conventions, SDK adoption, unified API, MCP registry, third-party integration.

0
installs
▌
Reviewing Ml Prior Art Survey · bm629 bundle
Use when reviewing an artifact produced by ml-prior-art-survey — an ML task vocabulary map, one angle's search output, one artifact's extract record, or the option register and its report — and deciding whether it can be built on. Judges against numbered conditions covering canonical terms the corpus actually uses, per-angle applicability verdicts in both directions, verbatim query recording, the recorded zero, cause evidence on every unreached source, the evaluation frame behind any leaderboard result, authority as a ranking rather than a cut, and the absence-as-finding rule. Also judges whether each adoption-ladder descent's reason is true of the record it names, and whether any figure was recomputed on its way into the register. Emits exactly one VERDICT approve or revise, with findings naming their condition, and does not revise a thin-but-honest result. Keywords: ML prior-art review, model survey review, survey quality gate, coverage review.

0
installs
▌
User Research Prior Art Survey · bm629 bundle
Use when surveying the PUBLISHED user-research evidence for a product's design questions BEFORE an interface is designed — deriving a research vocabulary map, executing ONE search angle across scholarly indexes, preprint servers, practitioner-research corpora and standards-body findings, deep-reading ONE source into the findings it contains, or synthesising the evidence register and report. One source yields N finding-records, because how many findings a paper holds is only knowable after the read. Certainty uses GRADE's four-level vocabulary assigned BY RULE and re-derived by the validator; transferability stays a separate field, because excellent evidence from another population is strong evidence and weak guidance at once. Keywords: user research prior art, HCI literature, usability evidence, published findings, evidence synthesis.

0
installs
▌
Reviewing Code Prior Art Survey · bm629 bundle
Use when judging a produced open-source prior-art SEARCH, EXTRACT, or SYNTHESIS artifact — a keyword map (typed search vocabulary), a per-angle search output (coverage cells + candidate repositories), a per-repo extraction, or a synthesis report + borrow-index — to decide whether it is sound enough to feed the survey's downstream stages. An acceptance gate, not authoring: a twenty-two-condition bar single-sourced with the producer, covering the keyword map and search (1–11), proportionality (12), extraction due-diligence (13–18) and synthesis (19–22), delegating the deterministic schema checks to the producer's validator. Emits exactly one verdict — a terminal VERDICT: approve|revise line, or the caller's named equivalent — with condition-named findings. Review-only; no false-revise — a thin-but-honest result meets the bar. Keywords: prior art review, keyword map review, search coverage review, extraction review, synthesis review.

0
installs
▌
Reviewing Scale Prior Art Survey · bm629 bundle
Use when reviewing a scale prior-art artifact — a scale vocabulary map, one angle's search output, one source's episodes, or the scale envelope index — that has already passed its deterministic gate. Judges what the gate structurally cannot: whether the declared band is a faithful transcription of the handed scope, whether a locator resolves to what the row claims, whether a measured number is the source's own number rather than a conversion, whether `configuration_stated` is true only where the configuration really is stated, whether `primary_dimension` names the dimension the episode actually measured, and whether an absence is phrased with its receipt. Returns numbered findings and exactly one `VERDICT: approve|revise`. Keywords: scale prior art review, transferability, configuration disclosure, evidence class, load band, blind review.

0
installs
▌
Reviewing Visual Prior Art Survey · bm629 bundle
Use when judging a finished visual prior-art artifact before it is accepted — a UI-pattern vocabulary map, a per-angle search output, an extract record, or the convention register and report. An acceptance gate, not authoring. Judges a single-sourced bar: a recorded zero is distinguishable from an unreachable source and from one refused on its terms; queries are reproducible as run; every cited corpus actually contains the convention claimed; authority and prescriptivity are recorded and not confused; a register row says what its record says; a vacated angle is not reported as a negative result; tokens are carried verbatim. Approves a thin-but-honest result for a narrow UI and revises only on a named, unrecorded gap. Emits exactly VERDICT: approve|revise plus actionable findings. Keywords: design system review, UI convention review, accessibility criteria review.

0
installs
▌
Market Competitive Prior Art Survey · bm629 bundle
Use when surveying the competitive and market landscape for a product BEFORE it is built — deriving a market vocabulary map (category, capability, job-to-be-done, audience and seed- product terms with typed expansions and exclusion terms), executing ONE search angle across alternatives directories, review corpora, app stores, package registries, corporate and funding records, product graveyards and practitioner discussion, deep-reading ONE competing product into a dated record, or synthesising the competitor register and report that downstream document authoring consumes. Produces schema-validated artifacts whose coverage grid records every query as run, so a market with no competitor is distinguishable from a search that never ran. Dates every commercial fact and keeps a dead product as evidence. Keywords: market research, competitor analysis, competitive landscape, competitive intelligence, market prior art, alternatives, substitutes.

0
installs
▌
Platform Ecosystem Prior Art Survey · bm629 bundle
Use when surveying how EXISTING platform ecosystems are architected before building a plugin system, app marketplace, extension surface or developer platform — minting the platform-and- mechanism vocabulary map, or executing ONE search angle across a platform's own developer documentation, its marketplace policy and commercial terms, its declarative contracts (manifest fields, contribution points, permission scopes), its migration history, its isolation model, its regulatory delegation, and its complementors' own account of building on it. Then reading ONE mechanism from ONE platform into an extract record, and cutting the corpus across nine lenses into a decision index a build phase reads instead of re-deriving the survey. Records every query as run, so a platform with no published term is distinguishable from a search that never ran. Keywords: platform architecture, plugin API, extension model, marketplace policy, developer platform, ecosystem prior art, manifest, contribution points, revenue share.

0
installs
▌
Reviewing Security Prior Art Survey · bm629 bundle
Use when judging a finished security prior-art artifact — a threat-vocabulary map, a per-angle search output, an extract record, or the threat register — to decide whether the research craft is honest, complete against its own contracts, and proportionate. An acceptance gate, not authoring: it runs the producer's validator once, then judges what a validator cannot see — whether a coverage claim is provable, whether a source failure was typed or written as a zero, whether a bail was a confident relevance bail rather than a hedge, whether an evidence tier follows from evidence the record's own body agrees with, and whether a register names threats from a real vocabulary rather than coining them. Emits VERDICT: approve|revise with condition-named findings. Keywords: security prior art review, threat research review, coverage honesty, survey acceptance gate. Judges all three survey waves.

0
installs
▌
Reviewing Regulatory Prior Art Survey · bm629 bundle
Use when reviewing an artifact produced by regulatory-prior-art-survey — a regulatory scope map, one angle's search output, one instrument's extract record, or the regulatory register and its report — and deciding whether it can be built on. Judges numbered conditions covering canonical terms the corpus uses, the sector receipt, per-angle verdicts in both directions, verbatim query recording, the recorded zero, cause evidence with observable status, the date separations, authority as a rank and binding force as an orthogonal fact, and the claim-versus-quote boundary that fabricated citations cross. Also judges whether a paywalled clause was paraphrased, whether a merge crossed a non-comparable dimension, and whether a conflict was escalated rather than resolved. Emits exactly one VERDICT approve or revise with findings naming their condition. It does not revise a thin-but-honest result. Keywords: regulatory review, compliance survey review, citation check, survey quality gate.

0
installs
▌
Reviewing Integrations Prior Art Survey · bm629 bundle
Use when reviewing an integrations prior-art artifact — an integration vocabulary map, one angle's search output, one service's extract record, or the integration register and its report — before it is accepted. Judges what a deterministic gate cannot: whether a locator host really is the vendor's own, whether an evidence quote supports the claim drawn from it, whether an authority band is defensible for the page it points at, whether a record was deep-read first-party or restated from a catalog, whether each complexity component is the one the facts support, whether a lens denominator counts what was REACHED, and whether an admission or an absence was recorded truthfully. Emits exactly one verdict, approve or revise, with every finding tied to a numbered condition. Keywords: integrations prior art review, connector catalog review, descriptor evidence, vendor scope, coverage grid, integration register, prior-art reviewer.

0
installs
▌
Reviewing User Research Prior Art Survey · bm629 bundle
Use when judging a finished user-research prior-art artifact before it is accepted — a research vocabulary map, a per-angle search output, an extract container, or the evidence register and report. An acceptance gate, not authoring. Judges a single-sourced bar: a recorded zero is distinguishable from an unreachable source; a claim stays within what its method could measure; recorded facts match the source; transferability carries a weighable reason and is never folded into certainty; numbers are the source's own; findings in one container are genuinely distinct; population and platform describe the study rather than the project; convergence is across INDEPENDENT sources; certainty is never averaged; absence is phrased as a search result. Approves a thin-but-honest result and revises only on a named, unrecorded gap. Emits exactly VERDICT: approve|revise plus actionable findings.

0
installs
▌
Reviewing Market Competitive Prior Art Survey · bm629 bundle
Use when judging a finished market and competitive prior-art artifact before it is accepted — a market vocabulary map, a per-angle search output, an extract record, or the competitor register and report. An acceptance gate, not authoring. Judges a single-sourced bar: a recorded zero is distinguishable from an unreachable source and from one excluded on its terms; queries are reproducible as run; ratings carry their denominators; vendor claims are attributed rather than asserted; a tier is argued from capability overlap rather than fame; point-in-time facts are dated; a dead product is recorded as dead with its date; a register row says what its record says; white space is phrased as a search result. Approves a thin- but-honest result for a thin market and revises only on a named, unrecorded gap. Emits exactly VERDICT: approve|revise plus actionable findings. Keywords: competitive analysis review, market research review, competitor set critique.

0
installs
▌
Reviewing Platform Ecosystem Prior Art Survey · bm629 bundle
Use when reviewing an artifact produced by platform-ecosystem-prior-art-survey — a vocabulary map, one angle's search output, one mechanism's extract record, or the decision index and its report — and deciding whether it can be built on. Judges numbered conditions covering slug provenance, applicability verdicts, verbatim query recording, the zero-hit cell, cause evidence on every unreached source, enumeration framing, and the anecdote-aggregation trap — plus whether a reversibility call is right, whether an authority band means the platform PRESCRIBES it, and whether a divergence was presented rather than resolved by dropping a source. Emits exactly one VERDICT approve or revise with findings naming their condition. It does not revise a thin-but- honest result: on this corpus most marketplaces publish no ranking function, and recording that is the expected outcome. Keywords: prior-art review, platform ecosystem review, survey quality gate, coverage review.

0
installs

78 published skills