79 skills · sorted by relevance
Drives implementation by writing a failing test first, then the smallest code that passes it. Use this before writing implementation code for any feature or bugfix, when a bug needs a regression test, when existing code is hard to change safely, or when someone asks whether a change is covered. Also use to decide what is worth testing and what is not.
The English summary is being prepared. Showing the original description.
Use when implementing any feature or bugfix, before writing implementation code
The English summary is being prepared. Showing the original description.
Use when implementing any feature or bugfix, before writing implementation code. Enforces RED-GREEN-REFACTOR cycle.
The English summary is being prepared. Showing the original description.
Observation capture and retrieval across sessions. Stores decisions, discoveries, and bugfix patterns. Searchable via tags and relevance scoring.
The English summary is being prepared. Showing the original description.
Use when implementing any feature or bugfix, before writing implementation code - write the test first, watch it fail, write minimal code to pass; ensures tests actually verify behavior by requiring failure first
The English summary is being prepared. Showing the original description.
Use when implementing any feature or bugfix, before writing implementation code
The English summary is being prepared. Showing the original description.
Bug fix workflow: root cause analysis → user review → regression test + fix via TDD
The English summary is being prepared. Showing the original description.
Use when implementing any feature or bugfix, before writing implementation code
The English summary is being prepared. Showing the original description.
Produce a weekly synthesis of authored commits with highlights by bugfix, tech debt, and net-new work
The English summary is being prepared. Showing the original description.
Maintenance of the contributor issue pipeline for JSONbored/awesome-claude (HeyClaude) — closing issues that are already done but not marked so, and keeping a small, high-value contributor-available backlog stocked with real website/content/feature/bugfix work. Runs every ~24h via a dedicated scheduled task. Invoke for "run the issue gardening", "audit open issues for stale/complete ones", "generate new contributor issues", or any recurring/scheduled run of this process. `reference.md` (next to this file) has the exhaustive label/milestone/ template detail — read it before doing real work, not just this file. This is the awesome-claude-specific instance; JSONbored/loopover and JSONbored/metagraphed each have their own separate copy with different conventions and a much larger backlog target — do not cross-apply either repo's specifics to this one without being asked.
The English summary is being prepared. Showing the original description.
Use when implementing any feature or bugfix, before writing implementation code
The English summary is being prepared. Showing the original description.
Use when publishing, open-sourcing, exporting, sanitizing, or moving code, agent skills, prompts, templates, fixtures, datasets, workshop assets, or other artifacts from a private repository, vendor/runtime environment, or mixed working directory into a public repository or registry. Builds a provenance inventory, license/security review, explicit allowlist, clean staging package, approval dry run, and fresh public clone/install smoke. Triggers on "open source this", "publish these skills", "make this repo public", "export and sanitize", "подготовь публичный релиз", "выложи скиллы", "опенсорсни", "санитизируй и опубликуй". NOT for ordinary upstream bugfix PRs, vulnerability disclosure, or creating a corp-* department.
The English summary is being prepared. Showing the original description.
Manage per-feature living documents that capture decisions, constraints, and reasoning across AI sessions during active development. Scoped to feature-level work — design, implementation, bugfix, refactor — not for codebase-wide assessments or product-wide specifications (those define their own document lifecycles). Handles creating new context documents, loading existing ones, and enriching them with new decisions. Use when starting a new feature, resuming work, making technical decisions, resolving questions, or when context needs to persist across sessions. Use this skill whenever the user mentions 'load context', 'update context', 'context doc', 'decisions', 'continue where we left off', 'what did we decide', or 'capture this decision'.
The English summary is being prepared. Showing the original description.
"/blueprint", "blueprint", "task graph", "contract derivation", "execution plan", "plan tasks from requirements", "contract-first planning" Turn requirements.md into an executable blueprint (plan.json + contracts.md). Five phases: Contracts → Tasks → Journeys → Verify Plan → Commit. Sits between /specify and /execute. Scope-adaptive (greenfield → bugfix). Uses hoyeon-cli (plan.json only; requirements.md is read as-is via Read tool).
The English summary is being prepared. Showing the original description.
Use when implementing any feature or bugfix, before writing implementation code
The English summary is being prepared. Showing the original description.
Test-driven development - write failing test first, then minimal code. Use before implementing any feature or bugfix.
The English summary is being prepared. Showing the original description.
Run a high-thoroughness end-to-end implementation loop using clean worker worktrees, per-slice planning, implementation, explicit review/fix iteration, orchestrator integration, and final commit/PR drafting. Use when the user explicitly wants a Ralph/Wiggum-style loop, autonomous multi-agent execution, a delegated feature/bugfix carried from confirmed scope through review-ready completion, or RFC-driven implementation that should be reviewed, bumped to In Progress, decomposed into phases, and executed through nested sub-loops. Supports Codex subagents by default and external CLI workers such as OpenCode when explicitly requested and available.
The English summary is being prepared. Showing the original description.
Draft commit titles and optional commit bodies using the workspace commit naming convention. Use when the user asks for a commit message, commit text, commit title, or wants commit wording in the format `chore|bugfix|feature - <issue_id(s)> <short description>`.
The English summary is being prepared. Showing the original description.
Use when the user reports a problem or names a piece of work and wants to start on it in a fresh worktree — "start a task", "new task", "file this and make a branch", "/start-task". Finds or files the GitHub issue, creates the feat/… or bugfix/… branch linked to it, and prints the paste-ready `ai fwt|bwt` (Docker) and `ai os fwt|bwt` (host) commands that open the worktree. Linear flow with hard stops; asks nothing.
The English summary is being prepared. Showing the original description.
Use when implementing any feature or bugfix, before writing implementation code
The English summary is being prepared. Showing the original description.
Use when implementing any feature or bugfix. Routes to the core Red-Green-Refactor loop, test quality guidance, rationalization handling, examples, or stuck-state recovery.
The English summary is being prepared. Showing the original description.
Add or update automated tests for a change using the repository’s verification rules in `AGENTS.md`. Use when implementing a feature, bugfix, refactor, or regression test; prefer stable integration/API/UI coverage and pull deeper test strategy from the bundled references.
The English summary is being prepared. Showing the original description.
Create change specification and implementation plan with dynamic phase generation. Supports feature, bugfix, refactor, and epic types.
The English summary is being prepared. Showing the original description.
Before any multi-step work with a stated goal — a feature, a bugfix spanning multiple files, a QA sweep, a doc draft + iterations, a multi-day investigation — create an ATO Mission instead of doing it via bare `ato dispatch` calls. A Mission persists the goal + the verifiable success criteria, lets the coordinator tick drive the work across days, captures every event in a structured audit trail (SQLite + markdown narrative), and integrates parallel agents' work via merge strategies. Complement to `ato-warroom` (the cross-family decision before you start) and `ato-review` (the post-code-diff review). Missions is where multi-step work LIVES; war-rooms are where decisions ABOUT it get made; reviews are where the resulting commits get vetted. Fires when: the work has more than one decision point, a verifiable end state, or runs across more than one session. Use it for any ATO development that doesn't fit in a single dispatch.
The English summary is being prepared. Showing the original description.