runkids

Manages and syncs AI CLI skills and agents across 50+ tools from a single source. Use this skill whenever the user mentions "skillshare", runs skillshare commands, manages skills or agents (install, update, uninstall, sync, commit, audit, analyze, check, diff, search), or troubleshoots skill/agent configuration (orphaned symlinks, broken targets, sync issues). Covers both global (~/.config/skillshare/) and project (.skillshare/) modes. Also use when: adding new AI tool targets (Claude, Cursor, Windsurf, etc.), setting target include/exclude filters or copy vs symlink mode, using backup/restore or trash recovery, piping skillshare output to scripts (--json), setting up CI/CD audit pipelines, building/sharing skill hubs (hub index, hub add), or working with agents (single .md files synced to agent-capable targets like Claude, Cursor, Augment, OpenCode) via positional `agents` filter or `--kind agent`, plus `.agentignore` and `enable`/`disable` for per-agent toggles.

Generate CHANGELOG.md entry from recent commits in conventional format. Also syncs the website changelog page. Use this skill whenever the user asks to: generate a changelog, document what changed between tags, or create a new CHANGELOG entry. If you see requests like "write the changelog for v0.17", "what changed since last release", this is the skill to use. Do NOT manually edit CHANGELOG.md without this skill — it ensures proper formatting, user-perspective writing, and website changelog sync. For full release workflows (tests, changelog, release notes, version bump, announcements), use /release instead.

End-to-end release workflow for skillshare. Runs tests, generates changelog (via /changelog), writes RELEASE_NOTES, updates version numbers, commits, and drafts announcements. Use when the user says "release", "prepare release", "cut a release", "release v0.19", or any request to publish a new version. For changelog-only tasks, use /changelog instead.

Run isolated E2E tests in devcontainer from ai_docs/tests runbooks. Use this skill whenever the user asks to: run an E2E test, execute a test runbook, validate a feature end-to-end, create a new runbook, or test CLI behavior in isolation. If you need to run a multi-step CLI validation sequence (init → install → sync → verify), this is the skill — it handles ssenv isolation, flag verification, and structured reporting. Prefer this over ad-hoc docker exec sequences for any test that follows a runbook or needs reproducible isolation.

Cross-validate CLI flags, docs, tests, and targets for consistency across the codebase. Use this skill whenever the user asks to: audit the codebase, check for consistency issues, find undocumented flags, verify test coverage, validate targets.yaml, check handler split conventions, or verify oplog instrumentation. This is a read-only audit — it reports issues but never modifies files. Use after large refactors, before releases, or whenever you suspect docs/code/tests have drifted out of sync.

Run CLI commands, tests, and debugging inside the skillshare devcontainer. Use this skill whenever you need to: execute skillshare CLI commands for verification, run Go tests (unit or integration), reproduce bugs, test new features, start the web UI, or perform any operation that requires a Linux environment. All CLI execution MUST happen inside the devcontainer — never run skillshare commands on the host. If you are about to use Bash to run `ss`, `skillshare`, `go test`, or `make test`, stop and use this skill first to ensure correct container execution.

Implement a feature from a spec file or description using TDD workflow. Use this skill whenever the user asks to: add a new CLI command, implement a feature from a spec, build new functionality, add a flag, create a new internal package, or write Go code for skillshare. This skill enforces test-first development, proper handler split conventions, oplog instrumentation, and dual-mode (global/project) patterns. If the request involves writing Go code and tests, use this skill — even if the user doesn't explicitly say "implement".

Skillshare frontend design system for the React dashboard (ui/) and Docusaurus website (website/). Use this skill whenever you: build or modify a dashboard page or component in ui/src/, style or layout website pages or custom CSS in website/, create new React components for the dashboard, add pages to the dashboard, fix visual bugs in either frontend, or need to know which design tokens, components, or patterns to use. This skill covers color tokens, typography, component API, page structure, accessibility, keyboard shortcuts, animations, and anti-patterns for both frontends. Even if the user just says "fix the styling" or "add a card", use this skill to ensure consistency.

Use when: writing E2E, integration, or smoke tests; verifying CLI tools, APIs, or deployments; creating executable documentation; running existing runbook or proof files; or after implementing a feature to verify it works. Activate when the project has *_runbook.md/*_proof.md files, a mdproof.json config, or the user mentions mdproof/runbook/proof. Executable runbook runner — turns Markdown into real tests with bash execution, 6 assertion types (substring, regex, exit_code, jq, negation, snapshot), and source-aware failure reporting that points to the exact Markdown file and line.

Write and run E2E test runbooks that exercise the mdproof CLI itself. Use this skill whenever you need to: verify a new feature works end-to-end, validate a bug fix via a reproducible markdown runbook, test CLI flags (--dry-run, --fail-fast, --steps, --report json, --output), regression-test assertion types (substring, regex, exit_code, jq, snapshot), or confirm that parser/executor changes didn't break real-world runbook files. This skill produces .md files in runbooks/ that mdproof can run against itself — the tool testing itself. If you're about to write or run an E2E test for mdproof, use this skill first.

Run CLI commands, tests, and debugging inside the mdproof devcontainer. Use this skill whenever you need to: execute mdproof CLI commands, run Go tests (unit or integration), reproduce bugs, test new features, run E2E runbooks, or perform any operation that requires a Linux container environment. mdproof refuses to execute outside Docker by design — the devcontainer is the correct place to run and test it. If you are about to use Bash to run `mdproof`, `go test`, or `make test`, stop and use this skill first to ensure correct container execution.

Update all documentation (skills/, docs/, README.md, CHANGELOG.md) to match recent code changes, cross-validating every flag and config field against Go source. Use this skill whenever the user asks to: update docs, sync docs with code, document a new flag or config option, fix stale docs, or refresh documentation after implementing a feature. This skill covers: docs/ (user-facing guides: cli-reference.md, writing-runbooks.md, advanced.md), skills/SKILL.md (AI agent skill), skills/references/ (assertions, advanced features), README.md (project overview), and CHANGELOG.md. If you just implemented a feature and need to update documentation, this is the skill to use. Never manually edit docs without cross-validating against Go source first.

Implement a feature from a spec file or description using TDD workflow. Use this skill whenever the user asks to: add a new CLI flag, implement a feature, build new functionality, create a new internal package, add an assertion type, extend the parser, or write Go code for mdproof. This skill enforces test-first development and proper package structure. If the request involves writing Go code and tests, use this skill — even if the user doesn't explicitly say "implement".

Generate CHANGELOG.md entry from recent commits in conventional format. Use this skill whenever the user asks to: write release notes, generate a changelog, prepare a version release, document what changed between tags, or create a new CHANGELOG entry. Do NOT manually edit CHANGELOG.md without this skill — it ensures proper formatting and user-perspective writing.

Discover new feature opportunities from creative brainstorming, user feedback, ecosystem trends, and cross-project research. Writes results to .feature-radar/opportunities/. MUST use this skill when the user wants to GENERATE new ideas — not evaluate existing ones. Trigger on any request to brainstorm, explore, discover, or find new feature ideas, even casual ones like "I wonder what else we could do" or "give me ideas". Use when the user: - Asks "what else could we build?", "give me feature ideas", "what are we missing?" - Wants to brainstorm, explore new directions, or refresh the opportunity backlog - Says "scan ecosystem", "scan opportunities", "find new features" - Asks to review GitHub issues, community feedback, or adjacent tools for inspiration - Mentions "explore", "discover", or "new directions" in a feature context - Has a vague idea: "I have an idea", "what if we...", "I was thinking about..." Do NOT use for evaluating/prioritizing existing features — that's feature-radar's job.

Archive a completed, rejected, or covered feature into .feature-radar/archive/ with mandatory learning extraction. MUST use this skill whenever a feature reaches a terminal state — done, rejected, covered, deferred, or N/A. Even casual mentions like "we shipped X" or "X is done" should trigger this. The skill extracts learnings, derives new opportunities, and updates refs. Use when the user: - Says "we shipped X", "X is done", "X is complete", "we just finished X" - Rejects a feature: "we decided not to build X", "reject this", "doesn't fit" - Defers: "defer X", "postpone this", "revisit later", "not now" - Closes an opportunity: "close this opportunity", "mark as done", "archive this" - Mentions any feature reaching Done/Covered/Rejected/Deferred status Do NOT use for discovering new features — that's feature-radar-scan's job.

Extract reusable patterns, architectural decisions, and pitfalls from completed work into .feature-radar/specs/. Captures the "why" behind choices so future sessions build on past experience. MUST use this skill when the user reflects on what worked/didn't, wants to document a decision, or mentions remembering a pattern for future use. Use when the user: - Says "remember this approach", "document this decision", "save this pattern" - Reflects: "that worked well", "lessons learned", "what did we learn" - Wants to capture: "don't forget this", "this was a good pattern" - Hit a dead end: "this didn't work because...", "avoid this approach" - Made a technical decision worth recording for posterity - Says "extract learnings" or "capture what we learned" Do NOT use for recording external observations — that's feature-radar-ref's job. Do NOT use for archiving completed features — that's feature-radar-archive's job.

Record external observations, ecosystem trends, and creative inspiration into .feature-radar/references/. MUST use this skill when the user mentions something interesting from outside their project — other tools, articles, approaches, or trends. Even casual mentions like "I saw a cool thing in X" should trigger this skill. Use when the user: - Says "I saw this cool thing in X's API", "check out how X handles this" - Shares a URL, article, talk, or research finding with relevant insights - Notes an ecosystem trend: new tools, standards, community patterns - Mentions a related project shipping a notable feature - Wants to bookmark external inspiration: "interesting approach", "save this" - Says "add reference", "log observation", "track this project" Do NOT use for internal learnings/patterns — that's feature-radar-learn's job. Do NOT use for prioritizing features — that's feature-radar's job.

Full-cycle feature discovery, evaluation, and prioritization. Builds a persistent knowledge base at .feature-radar/ and runs a 6-phase workflow to recommend what to build next. Modes: full (all phases), quick (scan only), evaluate (prioritize), #N (deep-dive one). MUST use this skill whenever the user asks about feature priorities, roadmaps, what to build, or wants to evaluate/compare feature ideas — even if they don't say "feature radar" explicitly. Use when the user: - Asks "what should we build next?", "what's most impactful?", or similar - Wants to prioritize, rank, or compare features or backlog items - Needs roadmap planning, project direction, or strategic feature decisions - Says "help me prioritize", "review our backlog", "what are we missing" - Mentions .feature-radar/ directory or feature tracking - Wants periodic reassessment of deferred or open opportunities

Validate SKILL.md frontmatter and .feature-radar/ files against format rules. Runs validate.sh, reports errors/warnings, and auto-fixes issues. MUST use this skill after editing any SKILL.md or .feature-radar/ file — catches format bugs like the 1024-char description limit before they break skill registration. Use when: - User says "validate", "check format", "lint skills", "run validation" - You just edited a SKILL.md (description, name, or body) — run proactively - You created or modified files in .feature-radar/ — run proactively - Before committing changes that touch skills/ or .feature-radar/ - User asks "are my skills valid?", "verify skills", "check skill format" IMPORTANT: Use this proactively after ANY edit to skills/ or .feature-radar/ files, even if the user doesn't ask for it. Format validation prevents silent breakage.

Generate CHANGELOG.md entry from recent commits in conventional format. Use this skill whenever the user asks to: write release notes, generate a changelog, prepare a version release, document what changed between tags, or create a new CHANGELOG entry. Do NOT manually edit CHANGELOG.md without this skill — it ensures proper formatting, user-perspective writing, and version consistency with Cargo.toml.

Run isolated E2E tests from ai_docs/tests runbooks against the veto release binary. Use this skill whenever the user asks to: run an E2E test, execute a test runbook, validate a feature end-to-end, create a new runbook, or test CLI behavior in the sandbox. If you need to run a multi-step CLI validation sequence (init → check → gate → verify), this is the skill. Prefer this over ad-hoc command sequences for any test that follows a runbook or needs reproducible results.

Cross-validate CLI flags, rules, tests, and integrations for consistency across the veto codebase. Use this skill whenever the user asks to: audit the codebase, check for consistency issues, find undocumented flags, verify test coverage, validate rule definitions, or check integration completeness. This is a read-only audit — it reports issues but never modifies files. Use after large refactors, before releases, or whenever you suspect code has drifted.

Run CLI commands, tests, and debugging inside the veto devcontainer. Use this skill whenever you need to: execute veto CLI commands for verification, run cargo test, reproduce bugs, test rule matching, or perform any operation that requires an isolated Linux environment. If you are about to use Bash to run `veto`, `cargo test`, or `make test`, stop and use this skill first to ensure correct container execution in headless environments (no Touch ID, no keychain).

Implement a feature or fix using TDD workflow in the veto Rust codebase. Use this skill whenever the user asks to: add a new rule category, implement a CLI subcommand, add an auth method, modify the risk engine, add a new integration (setup command), or write Rust code for veto. This skill enforces test-first development and follows veto's module conventions. If the request involves writing Rust code and tests, use this skill.

Manages and syncs AI CLI skills and agents across 50+ tools from a single source. Use this skill whenever the user mentions "skillshare", runs skillshare commands, manages skills or agents (install, update, uninstall, sync, audit, analyze, check, diff, search), or troubleshoots skill/agent configuration (orphaned symlinks, broken targets, sync issues). Covers both global (~/.config/skillshare/) and project (.skillshare/) modes. Also use when: adding new AI tool targets (Claude, Cursor, Windsurf, etc.), setting target include/exclude filters or copy vs symlink mode, using backup/restore or trash recovery, piping skillshare output to scripts (--json), setting up CI/CD audit pipelines, building/sharing skill hubs (hub index, hub add), or working with agents (single .md files synced to agent-capable targets like Claude, Cursor, Augment, OpenCode) via positional `agents` filter or `--kind agent`, plus `.agentignore` and `enable`/`disable` for per-agent toggles.

Integrate lifecycle hooks across AI coding tools (Claude Code, Gemini CLI, Cursor, OpenCode) and any CLI. Use when: (1) installing/removing hooks, (2) creating OpenCode plugins, (3) setting up auto-formatting, testing, notifications, security policies, (4) wrapping CLI tools without hooks API. Triggers on: "add hook", "install hook", "hook integration", "PreToolUse", "PostToolUse", "PermissionRequest", "PostToolUseFailure", "SubagentStart", "SubagentStop", "TeammateIdle", "TaskCompleted", "ConfigChange", "WorktreeCreate", "WorktreeRemove", "PreCompact", "beforeShellExecution", "auto-format", "notify on complete", "wrap CLI", "intercept command", "HTTP hook", "prompt hook", "agent hook", "async hook".