
Claude Skills by kdlbs
github.com/kdlbsDebug an ACP agent CLI by spawning it, speaking raw JSON-RPC, and capturing every frame to a JSONL file. Use when the user asks to probe an agent's capabilities, compare agents, test a prompt against an agent, inspect raw ACP wire frames, or investigate why an agent fails to initialize.
Add a new third-party integration (Jira/Linear-style) — per-workspace credentials, 90s auth-health poller, settings page, link/import buttons. Use when scaffolding a new external service integration.
Delete local branches whose remote has been deleted ([gone]), including their worktrees. Use for branch cleanup after merging PRs.
Review changed code for quality, security, and architecture compliance. Use after implementing features or before opening PRs.
Stage and commit changes using Conventional Commits. Use when there are dirty/staged files to commit, the user says "commit", or before pushing a PR.
Write and run web E2E tests (Playwright) using TDD — locations, patterns, commands, and debugging.
Fix bugs and issues — reproduce, find root cause, minimal fix with regression test. Use when something is broken.
Ensures UI feature work ships with desktop and mobile parity, responsive behavior, and mobile Playwright E2E coverage. Use when implementing, planning, reviewing, or testing any new feature, page, component, workflow, form, dialog, sidebar, navigation, dashboard, or visual UI change; if work touches frontend or user-facing UI, this skill must run even when user mentions only desktop or says "new feature".
Create an implementation plan (plan.md) from a feature spec. Explores the codebase, designs the approach, and produces a structured plan with backend, frontend, tests, and E2E sections. Use after writing a spec and before implementing.
Automate browser interactions, test web pages and work with Playwright tests.
Wait for CI checks and automated reviews (CodeRabbit, Greptile, Claude, cubic) on a PR, fix failures and address comments, then push.
Commit, push, and create a PR. Default is ready-for-review with auto-fixup. Use --draft to skip review/fixup.
Commit and push to the current branch. Use --fixup to also wait for CI/CodeRabbit and fix issues.
Verify a feature works after implementation. Actively try to break it — edge cases, error paths, integration wiring, and real usage flows.
Keep docs/decisions/ ADRs and docs/specs/ specs in sync with the work happening in the conversation. AUTO-INVOKE proactively the moment the user asks for any change that will alter architecture or observable product behavior — new feature, cross-cutting refactor, dependency swap, data-model or public-API change, new pattern, or a bug fix that changes documented behavior or reveals a spec gap. Also invoke on explicit triggers: "record this", "create an ADR", "document this decision", "update t...
Kandev release & versioning conventions — single SemVer across npm, Homebrew, GitHub release. Use when cutting a release, debugging release artifacts, or answering questions about version channels.
Simplify recently changed code — inline one-off abstractions, remove speculative code, reduce nesting, replace cleverness with clarity. Run after implementing a feature.
Write a feature spec — the "what & why" of a kandev product feature, before coding. Use ONLY for a product-feature surface (user-visible capability the app supports). Do NOT use for bug fixes, incident postmortems, refactors that preserve behavior, or infra-only work — those get ADRs (if a new convention emerged) and/or regression tests, not specs. Use when the user says "let's spec X" or starts a new product feature.
Implement changes using Test-Driven Development (Red-Green-Refactor). Use for bug fixes, new features, or any code change that should have test coverage.
Run format, typecheck, test, and lint across the monorepo. Use after implementing changes.
List pending approvals and decide them (approve or reject)
How to create a human-actionable decision task when you are blocked
How to interact with the kandev orchestrator via the CLI
Schedule recurring work via cron and webhook triggers
Read and write persistent memory entries via agentctl
Curate the right project context before coding or debugging. Use when starting a new session, switching areas of the codebase, output quality is drifting, a task spans backend/frontend/docs, or external instructions need to be reconciled with Kandev conventions.
Create, modify, debug, test, package, or publish a Kandev runtime plugin in its dedicated repository. Use only when the requested work targets a Kandev plugin implementation or its release and marketplace lifecycle, including fixing a bug in an existing plugin. Do not use for agent skills, MCP servers, general integrations, or Kandev host, SDK, loader, and registry changes that do not also change a plugin.
Diagnose Kandev bugs, running-instance issues, UI/browser failures, and runtime behavior. Use when the user reports unexpected behavior, asks to investigate, asks to add logs/instrumentation, or when a fix needs root-cause evidence before implementing. Triage first, gather evidence safely, then hand off to /fix for code changes.
Keep public Kandev docs current when code or behavior changes affect CLI commands, config keys, install/deploy flows, workflows, executors, APIs, screenshots, or user-facing terminology. Use this before finishing any change with public documentation impact, and when reviewing whether a change needs docs.
Improve Kandev's AI harness from session learnings or explicit requests. Use when the user asks to record learnings, update or create skills, agents, subagents, commands, AGENTS.md/CLAUDE.md guidance, or adapt harness files across Claude, Codex, Cursor, or OpenCode.
Clarify what the user wants before requirements, system design, plans, or code. Use when an ask is underspecified, when the user asks for an interview or stress test, or when important product or architecture assumptions are missing.
Enforce Kandev's single-session, user-controlled model workflow for feature, fix, debug, review, verification, and delivery work.
Generate a single-file HTML walkthrough for a pull request. Use when the user wants a visual, scrollable page that explains a PR's problem, approach, architecture, key code changes, data flow, and trade-offs for reviewers. Trigger on "walkthrough for this PR", "explain this PR visually", "generate a PR walkthrough", or a PR URL with a request to explain it. Not for code review: do not load this skill to critique a PR, post review findings, or approve or request changes. Use a code-review skil...
Seed coherent, disposable Kandev demo scenarios for screenshots, product films, landing-page media, and reproducible UI captures. Use when media needs believable tasks, workflows, agents, executors, integrations, plans, sessions, diffs, reviews, or native-mobile states; invoke before product-video-capture and never use a developer's main instance or data.
Record, camera-process, encode, stage, and validate polished Kandev product films, landing-page loops, screenshots, and alternate framing from isolated demo data. Use when the user asks for product videos, GIF-like feature demos, cursor-follow camera motion, desktop/mobile captures, recaptures, landing media, or different framing; always invoke product-demo-seeding first.
Add, roll out, promote, graduate, or remove Kandev runtime feature flags and release toggles across the backend and frontend. Use whenever a task mentions a feature flag, release toggle, staged rollout, kill switch, or graduating a flag.
Single-session Kandev feature workflow: clarify intent, create durable requirements, system designs, plans, and work orders, then hand off before implementation and verification.
Discover and choose the right Kandev agent skill for a task. Use when starting a session, when the user asks which skill applies, when work spans multiple phases, or when existing skill references need to be mapped to this repo's actual skills.
Synchronize Office workspace configuration with the .kandev folder when exporting reviewable config, importing committed config, seeding a workspace, or reviewing a config diff.
List and create Office projects, then place new tasks in the correct project when organizing workspace work by repository.
Operate Office tasks when you need to list workspace tasks, read a conversation, or post an agent-authored comment.
Manage the Office roster when delegating work, hiring agents, changing budgets or concurrency, retiring agents, or checking spend before approvals.