// Capture a user-reported defect as a durable GitHub issue written in the project's own domain language. Explores the codebase in parallel for context but never leaks file paths or line numbers into the issue. Use when the user reports a bug conversationally, runs a QA pass, or says "file an issue", "log this as a bug", "capture this".
Render a self-contained HTML viewer for a pro-workflow wiki. Pages, sources, claims, seed queue, page-link graph and full-text search all in one file. No external dependencies, no JS framework, S3-uploadable. Use when the user wants to browse a wiki visually, share its current state with someone, audit research progress, or hand off a knowledge base. Inspired by Thariq Shihipar's "Unreasonable Effectiveness of HTML" — favors information density and shareability over markdown-only outputs.
Capture a correction or lesson as a persistent learning rule with category, mistake, and correction. Stores, categorises, and retrieves rules for future sessions. Use after mistakes or when the user says "remember this", "don't forget", "note this", or "learn from this".
Provider-agnostic multi-LLM deliberation. Three phases — independent responses, cross-model anonymized ranking, chairman synthesis. Provider config from env (OPENAI/ANTHROPIC/FIREWORKS/OPENROUTER/custom OpenAI-compatible base URL). Persists transcript to a wiki page when --wiki <slug> is passed. Use when the user wants multiple AI perspectives, consensus-building, or the "LLM Council" approach for high-stakes reviews, plan critique, or contested learning rules.
Compile a structured literature survey on any AI/ML topic. Agent curates a research bundle (taxonomy + sections + bibliography of real papers) from a public anchor resource, then a chosen LLM generates the survey artifact. Output target is a wiki page (markdown), not a one-off HTML — survey lands in `<wiki>/derived/surveys/<slug>.md` with full bibliography rows in `sources.md`. Provider-agnostic (Anthropic/OpenAI/OpenRouter/Fireworks/custom OpenAI-compat). Use when the user asks for a "survey", "literature review", "lit review", or "deep dive" on a technical topic.
Start, structure, and grow a persistent research wiki indexed in pro-workflow's SQLite knowledge base. Each wiki is a folder of markdown pages with provenance, plus a shadow FTS5 index so any session can recall it. Use when the user says "start a wiki", "add to wiki", "compile a page", "wiki on X", or wants a long-lived knowledge base on a topic, paper, product, person, project, or codebase.
Query pro-workflow wikis via SQLite FTS5 BM25 retrieval. Returns top-K passages with citations. Use when answering a question that any of the user's wikis already covers, when the user says "what does the wiki say about X", "ask wiki", "search wikis", or before drafting a new wiki page (to avoid duplication).
| name | bug-capture |
| description | Capture a user-reported defect as a durable GitHub issue written in the project's own domain language. Explores the codebase in parallel for context but never leaks file paths or line numbers into the issue. Use when the user reports a bug conversationally, runs a QA pass, or says "file an issue", "log this as a bug", "capture this". |
Turn a conversation into an issue that still reads correctly after a major refactor.
Let the user describe the problem in their own words. Ask at most two short clarifying questions, drawn from:
If the description already answers these, skip straight to filing. Over- interviewing is a tax the reporter pays for your uncertainty.
While the user is answering, start a background exploration of the relevant area. The goal is not to propose a fix. The goal is to absorb the project's own vocabulary — the nouns and verbs the codebase uses for this feature — so the issue reads like it was written by a maintainer.
If the repo has a glossary file (common names: GLOSSARY.md, UBIQUITOUS_LANGUAGE.md, docs/domain.md), read it first.
Run gh issue list --search "<key phrase>" --state all --limit 10. If a
live or recently closed issue matches, surface it to the user and ask
whether to add a comment instead of opening a new issue. Do not silently
skip filing.
Break down when the report contains two or more independent failure modes that a different contributor could fix in parallel. Keep as one when every symptom traces to a single wrong behavior.
For a breakdown, file in dependency order so each child issue can
reference a real parent number, and mark honest Blocked by links.
Avoid inventing dependencies to make the tree look tidier.
gh issue createFile without asking the user to review the draft. Send back the URLs.
## What happened
<observed behavior, in domain terms>
## What I expected
<expected behavior>
## Reproduction
1. <step>
2. <step>
3. <step>
## Context
<anything that narrows where the bug lives, in domain terms — e.g.
"only affects the import path, not the export path">
## Parent
#<parent-number>
## What is wrong
<one behavior, narrow slice>
## What I expected
<expected for this slice>
## Reproduction
1. <step>
## Blocked by
<#issue or "none — independent">
## Context
<notes that apply only to this slice>
applyPatch() throws".After each issue, print the URL and ask whether there is a next one. Do not batch multiple reports into one filing pass — each bug deserves its own scoped issue.