brainqub3

Create and execute scenario YAML files for architecture what-if predictions.

Prepare and run evaluator-gated SAS and MAS experiments with explicit batch control and mandatory elasticity calibration for scenario scaling.

Reset local experiment state to a fresh slate by clearing runs, prediction outputs, scaling snapshots, and database index files under data/.

Create or repair Brainqub3 task packages that must pass evaluator tests before runs, including both fabricated instances and user-provided data workflows.

Build or repair task evaluators and evaluator tests with deterministic-first strategy.

Generate markdown reports with observed metrics, predicted metrics, and architecture recommendations.

Use to open a safe, reviewable pull request from a feature branch into main once a slice is built with red-green-refactor and green. Phase 4 of the TDD harness. It assembles everything a reviewer needs — the feature and slice description, evidence of the tests that ran (unit summaries plus Playwright screenshots and recordings for web slices, or terminal transcripts for CLI and API slices), a reviewer checklist, and a link to the plan — then pushes the branch and opens the PR with gh. Trigger on 'raise a PR', 'open a pull request', 'ship this slice', or 'create the PR with evidence'. Deliberately cautious — confirms before pushing, never force-pushes, only targets main.

Use to implement one slice test-first with disciplined double-loop TDD — an outer failing end-to-end or integration test wrapping inner unit-test red, green, refactor cycles, worked outside-in until the acceptance test is green. Phase 2 and the heart of the TDD harness. Trigger on 'red green refactor', 'TDD this', 'write a failing test then make it pass', 'implement slice NN', or working through a plan in plans/. Enforces the discipline literally — never write production code without a failing test, watch every test fail first, minimum code to green, refactor only on green.

Use once a slice is built and green locally and its unit plus acceptance tests (end-to-end Playwright for web, or integration tests for CLI and API slices) should run automatically in Continuous Integration. Phase 3 of the TDD harness — it detects the stack and the project directory and writes a correct GitHub Actions workflow (for web slices installing Playwright browsers and uploading the report, screenshots, and videos as artifacts; for non-web slices running the integration test; handling subdirectory apps via working-directory), validates it, and commits it. Trigger on 'add a GitHub Actions workflow', 'set up CI', 'run the tests on every PR', 'wire up continuous integration', or 'make these a required check'. Run after red-green-refactor and before safe-pr.

Use whenever the user wants a feature, product, bugfix, or change taken from idea to a reviewable pull request the disciplined test-driven way. This is the red-green-refactor TDD harness orchestrator — it drives the full pipeline (slice into thin vertical increments, write execution plans, develop with unit plus end-to-end tests via red-green-refactor, promote tests to GitHub Actions CI, and open a safe evidence-rich PR) and coordinates the tdd-plan, red-green-refactor, tdd-ci, and safe-pr skills. Triggers on 'build X with TDD', 'red green refactor this', 'do this enterprise-grade or from idea to PR', or 'use the tdd or rgr harness'.

Use at the START of any new feature, product, bugfix, or change, before writing code, to decompose it into thin vertical slices (each the smallest end-to-end testable behaviour that delivers value) and write a markdown execution plan per slice into the plans/ folder. Phase 1 of the TDD harness. Trigger on 'slice this up', 'what is the smallest first step', 'plan this test-first', 'write a TDD plan', or any request to build something where the slices should be identified first. Each plan becomes the contract the red-green-refactor skill then executes.

Use to safely clean up stale LOCAL feature branches left behind by the TDD harness once their slices have shipped — both merged branches and abandoned (closed-PR) branches. Phase 5 maintenance and the cleanup companion to safe-pr. It reports first, confirms before deleting, never force-deletes unmerged work, never touches the remote, and never deletes main, the current branch, or any branch with an open PR. Trigger on 'clean up merged branches', 'delete stale feature branches', 'tidy up branches', 'prune local branches', or after a PR merges. Records every deleted branch's SHA so anything is recoverable.

Use this skill whenever Claude needs to identify business-related spending inside personal financial statements, build candidate transaction rows, or decide whether transactions are likely business, personal, or need review based on a local trading profile.

Use this skill whenever Claude needs to create a feature branch, commit a batch of repo changes, push it, and open a GitHub PR while preventing financial statements, transaction exports, verification artifacts, or local trading profile files from being staged.

Use this skill whenever candidate transaction rows must be verified against original bank or card statements before export, especially for messy PDF, CSV, XLS, or XLSX statements where deterministic checks and careful fuzzy matching are both needed.

Recursive Language Model (RLM) loop for processing a context that is too large to read into the conversation directly. Loads the context as a variable in a persistent Python REPL and answers the query by writing code that probes, chunks, and programmatically sub-queries a cheap LLM (`llm_query`) over slices of it, then aggregates. Use this WHENEVER the user points you at a big context file/log/transcript/codebase/scraped corpus (anything from ~50K chars up to millions) and asks a question that needs most of the content -- counting, aggregating, classifying every item, multi-hop lookup, or summarising the whole thing -- ESPECIALLY when the answer "depends on almost every line" and a single retrieval/grep won't do. Trigger it even if the user doesn't say "RLM": phrases like "this file is huge", "go through the whole log", "how many X across all of these", "label every row", or "it won't fit in context" are all signals to use this skill. Prefer it over dumping the file into chat.

Recursive Language Model (RLM) loop for processing a context that is too large to read into the conversation directly. Loads the context as a variable in a persistent Python REPL and answers the query by writing code that probes, chunks, and programmatically sub-queries a leaf LLM (`llm_query`) over slices of it, then aggregates. Use this WHENEVER the user points you at a big context file/log/transcript/codebase/scraped corpus (anything from ~50K chars up to millions) and asks a question that needs most of the content -- counting, aggregating, classifying every item, multi-hop lookup, or summarising the whole thing -- ESPECIALLY when the answer "depends on almost every line" and a single retrieval/grep won't do. Trigger it even if the user doesn't say "RLM": phrases like "this file is huge", "go through the whole log", "how many X across all of these", "label every row", or "it won't fit in context" are all signals to use this skill. Prefer it over dumping the file into chat.

Recursive Language Model (RLM) loop for processing a context that is too large to read into the conversation directly. Loads the context as a variable in a persistent Python REPL and answers the query by writing code that probes, chunks, and programmatically sub-queries a cheap LLM (`llm_query`) over slices of it, then aggregates. Use this WHENEVER the user points you at a big context file/log/transcript/codebase/scraped corpus (anything from ~50K chars up to millions) and asks a question that needs most of the content -- counting, aggregating, classifying every item, multi-hop lookup, or summarising the whole thing -- ESPECIALLY when the answer "depends on almost every line" and a single retrieval/grep won't do. Trigger it even if the user doesn't say "RLM": phrases like "this file is huge", "go through the whole log", "how many X across all of these", "label every row", or "it won't fit in context" are all signals to use this skill. Prefer it over dumping the file into chat.

Sync leads from Zoho CRM into the local SQLite database. Fetches all leads, performs upserts with change detection, and maintains full audit history.

Safely write and link knowledge to the kb/** directory. Use when storing customer insights, patterns, or durable knowledge extracted from meetings, CRM, or research.

Extract all Conditions to Closing from a merger agreement using Playwright browser automation. Use when asked to identify closing conditions, conditions precedent, or obligations to close from merger agreements. Requires direct URL to contract document (no landing pages). Uses ONLY Playwright tools (no fetch/curl). Handles PDF and HTML documents, creates comprehensive audit trails with screenshots and CSV outputs. Includes granular R&W categorization and cross-referencing. (project)

Extract H1 2025 and H2 2024 financial data from any listed company's investor relations website using Playwright browser automation. Use when asked to get half-year financials, interim results, semi-annual reports, or compare H1/H2 periods for publicly traded companies. Handles cookie consent, navigation to IR sections, and derives H2 data from FY minus H1 when no standalone H2 report exists.

Recursive Language Model (RLM) loop for processing a context that is too large to read into the conversation directly. Loads the context as a variable in a persistent Python REPL and answers the query by writing code that probes, chunks, and programmatically sub-queries a cheap LLM (`llm_query`) over slices of it, then aggregates. Use this WHENEVER the user points you at a big context file/log/transcript/codebase/scraped corpus (anything from ~50K chars up to millions) and asks a question that needs most of the content -- counting, aggregating, classifying every item, multi-hop lookup, or summarising the whole thing -- ESPECIALLY when the answer "depends on almost every line" and a single retrieval/grep won't do. Trigger it even if the user doesn't say "RLM": phrases like "this file is huge", "go through the whole log", "how many X across all of these", "label every row", or "it won't fit in context" are all signals to use this skill. Prefer it over dumping the file into chat.

Use this skill whenever the user asks to understand, map, audit, reverse-engineer, document, or reason about the architecture of an existing codebase, especially a vibe-coded, prototype, legacy, inherited, or poorly documented repo. This skill guides an agent to discover the architecture as it actually exists, not as it was intended, by combining static inspection, dependency and entrypoint discovery, safe execution, evidence-backed flow tracing, upfront scoping questions, and a timestamped readable HTML as-built architecture report.

Read, search, summarize, quote, and extract tables from existing PDF files without loading the whole file into context. Use whenever the user wants to read, summarize, search, analyze, or ask questions about a PDF — especially long, large, scanned, or image/figure-heavy ones (reports, papers, contracts, manuals, financial statements, slide decks) — including requests like "read/summarize this PDF", "what does the chart/figure on page N show", or "extract the tables", and any work involving one or more .pdf files even when the user does not say "convert". It works by converting the PDF once into a token-efficient Markdown workspace with page-anchored image placeholders, then rendering only the page(s) needed to see a figure. This reads PDFs that already exist; it does not create, generate, fill, sign, or export PDFs. Prefer it over dumping a PDF into context.