This skill should be used when the user asks to "resolve an issue", "work on issue #N", "fix #N", "implement #N", "close #N", "tackle #N", "pick up #N", "start working on #N", "what should I work on next", or references a specific GitHub issue number they want to work on. Can also accept a version number (e.g., "0.5.0") to select from that release's sub-issues, or auto-select the best issue when no argument is specified.
Use when a typemd code change needs end-to-end TUI verification — keybinding behaviour, layout rendering, config overrides, error recovery — and "open TTY failed" or "non-interactive sandbox" is about to be treated as a blocker. Trigger on symptoms like "can't test TUI without a terminal", "need to verify what the user sees", "press ctrl+X and check X appears", "help popup should show Y", "sidebar should look like Z after config change".
Import existing markdown collections into a structured typemd vault. Use when the user wants to onboard, import, or migrate content from external directories into their vault.
Import existing markdown collections into a typemd vault.
This skill should be used when the user asks to "create an issue", "open an issue", "file a bug", "request a feature", "add a task", or discusses a problem or idea that should be tracked as a GitHub issue.
Use when resolving a GitHub issue labeled `discussion` — facilitates decision-making on open questions, documents conclusions as an issue comment, creates follow-up issues if needed, and removes the discussion label. Triggered by resolve-issue when it detects a discussion-labeled issue, or directly when user asks to "resolve discussion
Cross-reference BDD tests, OpenSpec specs, and documentation to find contradictions and terminology inconsistencies, then optionally triage coverage gaps by verifying Go source code. Use when the user mentions "consistency check", "cross-reference", "do BDD and spec align", "are docs and tests contradicting", "is terminology consistent", "check specs", "spec and feature match", "triage coverage gaps", "verify implementation matches spec". Also useful before releases, after refactoring, or when suspecting a concept is described differently across sources.
Use when reviewing BDD feature files or OpenSpec specs for technical-only scenarios without user context, when cleaning up test layers, when deciding whether a behavior belongs in BDD or unit tests, or when the user mentions "check features", "BDD cleanup", "BDD audit", "feature audit", "test layer review".