deslop
Diff-scoped AI-slop cleanup pass: strip comment slop, defensive-check slop, type-laundering, and style drift from the current branch diff before autoreview.
openclaw-qa-testing
Run, watch, debug, extend, or explain OpenClaw qa-lab and qa-channel scenarios, artifacts, and live lanes.
graincrawl
Granola archive: search, sync freshness, notes, transcripts, panels, SQL counts, and Graincrawl repo work.
openclaw-update
Route routine updates of an existing local or remote OpenClaw Gateway to its installation owner, with automatic session recovery. Defer to deployment-specific skills when available.
spike
Run throwaway prototypes to validate feasibility, compare approaches, and report a verdict.
taskflow
Run approval-gated workflows with durable TaskFlow state; distinguish workflow execution from linking real detached tasks.
openclaw-debugging
Debug OpenClaw model, provider, tool-surface, code-mode, streaming, and live/Crabbox behavior by choosing the right logs, probes, and proof path before changing code, including fetching stored sessions, transcripts, and attachments as evidence.
openclaw-secret-scanning-maintainer
Triage, redact, clean up, and resolve OpenClaw GitHub Secret Scanning alerts in issues or PRs.
openclaw-testing
Choose proportional OpenClaw tests and checks, diagnose failures, and route environment-sensitive or release proof to its owner.
openclaw-repair-sweep
Run scoped OpenClaw issue/PR repair campaigns: coordinate workers, prove root causes, and land or close verified work under the requested authority.
discord-user-post
Post an approved message as the logged-in Discord user through the Discord desktop app. Use for release announcements or other direct user-authored Discord posts; not for OpenClaw channel sends, bots, webhooks, relays, agent sessions, or archive search.
discrawl
Discord archive: search, sync freshness, DMs, summaries, TUI, repo/release work.
openclaw-release-validation
Guide human release testing on an isolated OCM copy or approved in-place gateway, collect feedback, or refresh the release campaign.
openclaw-ci-limits
Manage OpenClaw GitHub Actions and Blacksmith CI capacity, runner-registration budgets, fanout caps, main-push single-flight, shard sizing, hosted-runner offload, queue health, and safe ramp-down/ramp-up changes. Use when tuning `.github/workflows/*`, `docs/ci.md`, CI runner labels, matrix `max-parallel`, ClawSweeper/Blacksmith burst protection, CodeQL runner placement, or investigating slow/queued OpenClaw CI.
gitcrawl
GitHub archive: issue/PR search, sync freshness, duplicate clusters, current GitHub handoff, and Gitcrawl repo work.
openclaw-docker-e2e-authoring
Author OpenClaw Docker E2E and live provider Docker lanes.
openclaw-changelog-update
Regenerate OpenClaw release changelog sections from git history before beta, stable, or extended-stable releases.
taskflow-inbox-triage
Preview synthetic inbox routing with a real TaskFlow approval pause, and identify the adapters needed for live triage.
openclaw-refactor-docs
Refactor an existing OpenClaw docs page with source-audited preservation, restructuring, and verification.
notcrawl
Notion archive: search, sync freshness, pages/databases, Markdown exports, SQL counts, and Notcrawl repo work.
writing-skills
Use when creating new skills, editing existing skills, or verifying skills work before deployment
using-superpowers
Use when starting any conversation - establishes how to find and use skills, requiring skill invocation before ANY response including clarifying questions
verification-before-completion
Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always
using-git-worktrees
Use when starting feature work that needs isolation from current workspace or before executing implementation plans - ensures an isolated workspace exists via native tools or git worktree fallback
writing-plans
Use when you have a spec or requirements for a multi-step task, before touching code
subagent-driven-development
Use when executing implementation plans with independent tasks in the current session
systematic-debugging
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes
test-driven-development
Use when implementing any feature or bugfix, before writing implementation code
dispatching-parallel-agents
Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies
executing-plans
Use when you have a written implementation plan to execute in a separate session with review checkpoints
receiving-code-review
Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
finishing-a-development-branch
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work
brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
requesting-code-review
Use when completing tasks, implementing major features, or before merging to verify work meets requirements
flow
Use when you need to run Flow type checking, or when seeing Flow type errors in React code.
fix
Use when you have lint errors, formatting issues, or before committing code to ensure it passes CI.
verify
Use when you want to validate changes before committing, or when you need to check all React contribution requirements.
extract-errors
Use when adding new error messages to React, or seeing "unknown error code" warnings.
feature-flags
Use when feature flag tests fail, flags need updating, understanding @gate pragmas, debugging channel-specific test failures, or adding new flags to React.
test
Use when you need to run tests for React core. Supports source, www, stable, and experimental channels.
flags
Use when you need to check feature flag states, compare channels, or debug why a feature behaves differently across release channels.
plan-update
Use when you need to update a plan document with deep research across all compiler passes. Launches parallel subagents to analyze how a topic affects every compiler phase, then consolidates findings into the plan doc.
rust-port-status
Show the status of all Rust port plan documents and recent related commits. Use when you need to understand what's been done vs what remains.
compiler-orchestrator
Orchestrate the Rust compiler port end-to-end. Discovers the current frontier, fixes failing passes, ports new passes, reviews, and commits in a loop.
compiler-port
Port a compiler pass from TypeScript to Rust. Gathers context, plans the port, implements in a subagent with test-fix loop, then reviews.
compiler-review
Review Rust port code for port fidelity, convention compliance, and error handling. Compares against the original TypeScript source.
compiler-verify
Use when you need to run all compiler checks (tests, lint, format) before committing. Detects whether TS or Rust code changed and runs the appropriate checks.
compiler-commit
Use when you want to verify compiler changes and commit with the correct convention. Runs tests, lint, and format, then commits with the [compiler] or [rust-compiler] prefix.
golang-testing
>
strategic-compact
Suggests manual context compaction at logical intervals to preserve context through task phases rather than arbitrary auto-compaction.
Page 9 of 1735 · 86739 results
