Claude Skills by felipemelendez

Use when starting creative work — a new feature, added functionality, a system design, or a behavior change — before any code is written. Not for one-line fixes, mechanical chores, or when an approved spec already exists.

Use when 3+ tasks are independent — no shared files, no order dependency — and can run concurrently. Fan-out only; per-task review happens after all return.

Use when running plan tasks sequentially with per-task two-stage review — the default for tasks with dependencies, sensitive code, or shared files another task changed.

Use when you have a written plan and need to drive it task-by-task to completion. Top-level orchestrator that routes each task to sequential or parallel dispatch and tracks state.

Use when implementation is complete and tests pass. Decides between merge, PR, keep, or discard — without destructive actions unless the user confirms.

Use when context is filling on a long task and you should leave a short note so work resumes cleanly after the conversation is compacted.

Use when the user says "remember", "save this", "I told you before", or "forget that". Classifies notes into Claude Code's native CLAUDE.md and research-gate state.

Use when responding to code review feedback — from a human, from another agent, or from the two-stage review flow. Resists performative agreement and blind implementation.

Use when a diff is complete and about to be merged, opened as a PR, or called done. Runs the two-stage review plus an optional security pass. Not for mid-task or incomplete diffs.

Use when about to invoke brainstorming or writing-plans, before a spec or plan is committed. Decides whether to verify API surfaces against current docs first.

Use when a bug, test failure, exception, regression, or unexpected behavior appears, before proposing or applying a fix — it forces root-cause investigation first. Not for the expected red phase of TDD: a failing test you just wrote is progress, not a bug. Runs before test-driven-development when both match.

Use when implementing a feature or bugfix where tests are practical, before writing implementation code. Enforces red-green-refactor with a verified red phase. Not for docs-only or config-only changes with no testable behavior, and not before systematic-debugging when the trigger was a failure rather than new work.

Use when work needs isolation from the current branch — long-running feature, risky refactor, parallel attempt. Creates and tracks a worktree without touching unrelated state.

Use when starting any session in an LLM Orchestrator project. Establishes the Concise Agent Protocol response shapes and mandates skill invocation before any response or action.

Use when deciding whether an already-chosen fan-out (multi-dimension review, parallel implementation, multi-source research) runs on the Workflow tool or inline. Do not use to decide whether to parallelize at all — that is dispatching-parallel-agents.

Use when about to claim work is done, fixed, passing, or ready to merge — it forces a real run of the verifying command first. Not for reporting a failure honestly, which needs no gate. Runs last, after any review skill.

Use when a spec is approved and implementation has not started. Produces a dated, checklist-shaped plan file that another agent (or you) can execute task-by-task. Not for work already covered by an existing plan, and not before brainstorming has produced the spec.

Use when adding a new skill or editing an existing one. Not for commands (commands/*.md) or agent definitions.

Use when <trigger>. Not for <adjacent non-trigger>.