ship-issue
One-command issue-to-merge pipeline orchestrator. Drives a GitHub issue through nine stages (preflight, plan, implement, review, ci, cloud_review, deploy, e2e, logs) with two human gates, persisting all run state to files so a crashed or interrupted run resumes losslessly. Triggers on "/ship-issue" with an issue number or URL. User-invoked only.
skill-visualizer
Generate interactive HTML visualizations of the skills collection, codebase structure, or dependency graphs. Uses D3.js for interactive visualization with collapsible nodes, color-coded categories, and hover details. Triggers on "visualize skills", "generate skill map", "codebase visualization", or "show skill dependencies".
strategic-compact
Suggest context compaction at optimal logical boundaries — between phases, after a research burst, after a debugging session ends — rather than waiting for the automatic compaction threshold to hit mid-task. Use when the user asks whether to compact, mentions context is getting long, wants to checkpoint before a big task, or when you notice the session is approaching a natural transition where compacting would preserve the next phase's context. Complements (doesn't replace) Claude Code's built-in auto-compaction. Triggers on "/strategic-compact", "should I compact", "when should I clear context", "getting long", or proactively at phase boundaries and session transitions.
team-brainstorm
Adversarial brainstorming using agent teams for multi-perspective analysis. Use when users want thorough idea exploration with real debate between independent perspectives. Triggers on "team brainstorm", "adversarial brainstorm", "brainstorm with team", "debate this idea", or when the user explicitly requests team-based analysis. Higher token cost but significantly deeper analysis than single-agent brainstorm.
team-create-plan
Team-based implementation planning with adversarial design review. Spawns an Architect, Risk Analyst, and Researcher who explore competing designs and challenge each other before producing a plan. Use when planning complex features, high-stakes changes, or when multiple valid approaches exist. Triggers on "team create plan", "team plan", "deep plan", or when the user explicitly wants team-based planning.
team-implement-plan-full
Execute implementation plans with a full team — one implementer per phase running in parallel where the dependency graph allows, plus a shared cross-phase Reviewer. Phases execute in waves based on dependencies. Use for large plans with 4+ phases and independent work streams. Highest token cost but fastest execution for parallelizable work. Triggers on "full team implement", "parallel implement", or when the user explicitly wants maximum parallelism.
team-implement-plan
Execute implementation plans with a small review team (Implementer + Reviewer + optional Integrator). The Implementer writes code directly while the Reviewer provides adversarial quality checks per phase. Use for moderate-to-complex plans where real-time adversarial review catches issues that automated checks miss. Triggers on "team implement", "team implement plan", or when the user explicitly wants team-based implementation.
tt-brainstorm
Tasktracker-native Socratic brainstorming. Refines a raw idea into a frozen brainstorm document tree stored in tasktracker (NOT in docs/brainstorms/*.md), with every chosen/deferred/rejected option recorded as a decision and an optional one-way promotion into a task tree. Use whenever a user wants to brainstorm, explore, refine, or "think through" an idea AND the work is (or will be) tracked in tasktracker. Triggers on "tt brainstorm", "brainstorm with tasktracker", "brainstorm in tasktracker", "explore this idea (tasktracker)", "/tt-brainstorm", or any brainstorm-style request inside a session that already has a tasktracker active task or project. Prefer this over the plain /brainstorm skill whenever a tasktracker MCP is available — the artifacts integrate with /tt-create-plan and /tt-implement-plan, so picking the file-based variant in a tasktracker project just creates orphan markdown.
tt-create-plan
Tasktracker-native implementation planning. Turns a frozen brainstorm (or a clear requirement) into a phased plan persisted as tasktracker phase tasks — NOT as a docs/plans/*.md file. Creates requirements with formal acceptance criteria, registers architecture components, generates phases via createPhaseFromTemplate (backend-feature / ui-fix / refactor / schema-migration / bug-investigation / docs-only / data-housekeeping), links every task back to its requirement, and uses getProjectReadiness as the completion gate. Use whenever the user wants to plan, design, or scope an implementation AND the work is (or will be) tracked in tasktracker. Triggers on "tt create plan", "tt plan", "plan this in tasktracker", "create a plan (tasktracker)", "/tt-create-plan", or any plan-creation request inside a session that already has a tasktracker active task or project. Prefer this over the plain /create-plan skill whenever a tasktracker MCP is available — the resulting phase tasks integrate with /tt-implement-plan and /implement-phase, so picking the file-based variant in a tasktracker project just creates orphan markdown.
tt-implement-phase
Tasktracker-native per-phase executor. Runs a SINGLE phase whose scope and sub-tasks live as tasktracker phase + sub-task rows (NOT in a docs/plans/*.md file). Honours active-task discipline (setActiveTask on phase AND on each sub-task as worked), respects the locked phase body (HTTP 422 on description edit — design notes go to sub-tasks), updates sub-task status via tasktracker_updateTaskStatus as work progresses, logs defects/learnings/frictions through tasktracker insights, and delegates code work to subagents when a subagent-dispatch tool is available — otherwise does the work in-context itself (graceful degradation), never stalling. Used by /tt-implement-plan as the per-phase unit of work; can also be invoked directly with a phase task id. Triggers when /tt-implement-plan delegates a phase, or manually with "/tt-implement-phase <phase-task-id>", "tt implement phase", "execute phase (tasktracker)", "/tt-implement-phase". Prefer this over the plain /implement-phase skill whenever a tasktracker MCP is available — /implement-phase will happily edit a phase task description (HTTP 422), miss sub-task status updates, and bury defects in chat narrative instead of insights.
tt-implement-plan
Tasktracker-native plan orchestrator. Drives execution of a plan whose phases are stored as tasktracker phase tasks (NOT a docs/plans/*.md file). Honours active-task discipline (setActiveTask before every artifact-producing call, pauseActiveTask before user waits, clearActiveTask on phase done), respects the locked phase body (design notes go to sub-tasks, never to the phase description), logs defects/learnings/frictions through tasktracker insights as they surface, and delegates the actual implementation to /implement-phase. Use whenever the user wants to "implement the plan", "run the plan", or "work through the phases" AND the plan was created with /tt-create-plan (or otherwise lives in tasktracker). Triggers on "tt implement plan", "tt implement", "implement plan (tasktracker)", "/tt-implement-plan", "execute the tasktracker plan", or any plan-execution request inside a session that already has a tasktracker active task or project. Prefer this over the plain /implement-plan skill whenever a tasktracker MCP is available — it correctly handles the locked phase body, requirement linking, insight logging, and lifecycle gating that the file-based variant ignores.
tt-workflow-audit
Tasktracker-native project-wide parallel audit using the Claude Code Workflow tool (dynamic workflows). Partitions a repo / backlog / architecture and fans out read-only agents (one per partition) that return schema-checked findings, aggregates them into a deduplicated, ranked risk register, and OPTIONALLY writes fixes back as tasks under a Bug Fix phase — with all tasktracker writes done by the PARENT, never the parallel agents (single global active-task pointer). Journaled and resumable, so a rate-limit or crash mid-audit resumes without re-running completed partitions. Use for large, embarrassingly-parallel, read/analyze-heavy jobs where each unit is self-contained and the output aggregates — audit every file/component for risk, find all architecture drift (scanArchitectureDrift) or duplicate tasks (detectDuplicates/auditDuplicates), per-file tech-debt sweep, test-coverage or security-surface scan across a whole project. Triggers on "/tt-workflow-audit", "audit the whole repo", "parallel audit", "scan every file/component", "find all drift/duplicates", "tech-debt sweep (tasktracker)", or any whole-project analyze-at-scale request inside a session with a tasktracker project. Prefer this over /codebase-audit or /code-quality-audit when the project is tracked in tasktracker AND you want the findings written back as tasks; prefer it over team-* modes when the units don't need to negotiate live (they just report).
tt-workflow-build
Tasktracker-native trigger for a PARALLEL build via the Claude Code Workflow tool. Thin by design — it does two things, then drives to done: (1) ensure a tasktracker project exists (use the existing one, or create one), then (2) start a dynamic `Workflow` that builds it, tracking the work in tasktracker and using the build + verify skills. It does NOT analyze parallelism up front, ask the user to choose a mode, hand back, or fall back to a sequential skill — get a project, start the workflow, drive autonomously to done (pausing only at real human gates like deploy). Use when the user wants a build driven by the parallel Workflow engine — typically after /tt-brainstorm + /tt-create-plan, or standalone. Triggers on "/tt-workflow-build", "build this with a workflow", "parallel build (tasktracker)", "fan out the build". Prefer /tt-implement-plan or /tt-workflow-run only when the WHOLE job is irreducibly sequential; prefer /tt-workflow-audit for read-only analysis.
tt-workflow-run
Tasktracker-native autonomous build-loop orchestrator. Drives a first-class `workflow_run` end-to-end — create the run (Gate 1 lifecycle completeness + Gate 2 zero-defects-in), then loop while `getNextReadyTask(projectId)` returns a slice — `setActiveTask` → record a pre-slice `scanArchitectureDrift` baseline → delegate the slice to `/tt-implement-phase` (which does the code work, registers the architecture delta in-slice, and auto-logs defects/learnings/frictions) → re-scan drift (Gate 3 architecture-followed) + re-read `getDefectStats` (Gate 2 delta) → read `getTimeSummary` for measured time + classify the slice's layer → `workflow_recordIteration` (appends an immutable by-layer measured-only projection version) → `pauseActiveTask` before any human gate — until the backlog drains, then `workflow_completeRun`. Loose coupling (brainstorm Fork B): the run is pure tasktracker data driven by a thin skill over EXISTING MCP tools + `/tt-implement-phase`; there is NO backend-callable Workflow API and `/loop` is only an optional outer cadence. The skill logs the RUN'S OWN insights too — a "no data" friction when heartbeating was off for a slice (principle #11), a learning on notable patterns, a defect for any new error above baseline. Use whenever the user wants to "run the workflow", "start an autonomous build loop", "drive the backlog to done", "dogfood the run", or "/tt-workflow-run" AND the work is tracked in tasktracker with a passable lifecycle. Triggers on "tt workflow run", "/tt-workflow-run", "start a workflow run", "run the build loop", "autonomous loop (tasktracker)", "drive the next-ready backlog". Prefer this over /tt-implement-plan when you want measured-time projection + per-slice drift/defect gates + a versioned remaining-effort series on top of phase execution; /tt-implement-plan just runs phases in order with no run entity, no projection, no per-slice gate ledger.
user-story
Generate hierarchical user stories (epics, features, tasks) with formal Given/When/Then acceptance criteria. Works from brainstorm output or standalone. Produces structured requirements that feed directly into create-plan. Triggers on "create user stories", "write stories", "define requirements", "user story", or when presenting features that need requirements decomposition.
verification-loop
Comprehensive 6-check verification framework for validating implementation quality across build, types, lint, tests, security, and diff review. This skill ensures code meets all quality gates before phase completion. Triggers on "verify implementation", "run verification", "/verification-loop", or automatically as part of implement-phase Step 2.
workflow-guide
Recommend which workflow mode fits the task at hand — solo (implement-plan), small team (team-implement-plan with Implementer + Reviewer), full team (team-implement-plan-full with parallel per-phase implementers + shared Reviewer), or a dynamic workflow (the Workflow tool — deterministic parallel fan-out across tens-to-hundreds of background agents for large read/analyze/audit/research jobs, e.g. /tt-workflow-audit). Factors in task complexity, risk, parallelism, work shape (analyze vs implement), and token budget. Use when the user asks which workflow to pick, is unsure whether to go solo or team-based, mentions "which mode should I use", asks "solo or team for this", "should I use a workflow", "parallel audit", or is about to kick off execution without having chosen a mode. Triggers on "/workflow-guide", "which workflow mode", "solo or team", "pick a workflow", "dynamic workflow or team".
kurrentdb
Provides KurrentDB (EventStoreDB) client code for event sourcing and CQRS. Generates correct package names, connection strings, and API patterns for Python, Node.js, .NET, F#, Go, Java, Rust. Triggers on "kurrentdb", "eventstore", "event sourcing", "append events", "read stream", "subscription", "aggregate", "CQRS".
cc-track-tools
Provides paths to cc-track utility scripts for validation, task completion, and git operations. Use when a cc-track command needs to run a script.
repo-clipboard
Snapshot the current directory into pseudo-XML for LLM context. Use when you need to share a repo (or a sub-tree) with Codex/LLMs, especially for code review/debugging, generating an agent-friendly “repo snapshot”, or piping context into tools like `llm` (see skill $llm-cli). Supports `.gitignore`-aware file discovery, common ignore patterns, extension filtering, regex include/exclude, optional file-list printing, line-range snippets, and writes `/tmp/repo_clipboard.{stdout,stderr}` for reuse.
dead-code-audit
Use when auditing Julie for dead code, test-only code paths, stale helpers, graph gaps, or cleanup candidates before deleting, privatizing, or simplifying code.
editing
>-
explore-area
Orient on a new codebase area using get_context for token-budgeted exploration. Use when the user asks "what does this module do", "explain this part", or wants to understand an unfamiliar area before making changes.
impact-analysis
Analyze what would break if a symbol changes: finds callers, groups by risk level, assesses impact. Use when the user asks about blast radius, who uses a symbol, or is planning a refactor.
search-debug
Diagnose why a Julie search returns unexpected results during Julie development. Analyze scoring factors, tokenization, and index health when dogfooding search quality.
web-research
Fetch web pages and index them locally for token-efficient research. Use when you need to read documentation, articles, or any web content. Fetches via browser39, saves as markdown, indexes via Julie's filewatcher, then uses Julie tools for selective reading. Requires browser39 (binary release from GitHub).
claude-five-prompting-guide
Guidelines for prompting and building context for Claude 5 generation models (Sonnet 5, Opus 5, Fable 5), based on Anthropic's official guidance from July 2026. Use this skill whenever the user asks how to prompt Claude 5 models, wants to write or review a system prompt, CLAUDE.md, skill, or agent harness targeting these models, mentions "unhobbling", "unknowns", "blind spot pass", "context engineering", or asks why an agentic task came back wrong despite detailed instructions. Also use it when auditing existing prompts or rules for over-constraint, or when migrating prompts written for Claude 4-era models. When invoked with file path arguments, audit those files against the guide (prefer delegating the audit to a read-only sub-agent and returning only findings).
claudify
Esta skill debe usarse cuando el usuario pide "documenta el modulo", "claudify", "generate module docs", "actualiza el CLAUDE.md de este modulo", "onboarding del modulo", "necesito un CLAUDE.md para X", o quiere crear/actualizar un CLAUDE.md a nivel de modulo. Corre como fork en background — no roba contexto a la sesion principal y devuelve solo un resumen de una linea. Genera documentacion token-efficient con referencias LSP-optimizadas (`file::Symbol`) enfocada en informacion no-obvia que ahorra al agente tener que inferirla del codigo.
end-session
Skill de invocacion manual exclusiva, ejecutada por el usuario via /end-session; el modelo nunca debe autoinvocarla. Cierra formalmente una sesion de trabajo: commitea los cambios de logica de negocio y genera un documento de contexto autocontenido para reconstruccion futura de la sesion.
remember
Esta skill debe usarse cuando el usuario pide "recuerda que", "guarda
rulify
Esta skill debe usarse cuando el usuario pide "aligerar el CLAUDE.md", "dividir el CLAUDE.md", "extraer reglas a .claude/rules", "rulify", "claudemd splitter", "convertir secciones del CLAUDE.md en rules bajo demanda", o menciona que su CLAUDE.md crecio demasiado, supera las 200 lineas, o quiere migrar a carga contextual con globs. Divide un CLAUDE.md monolitico en archivos `.claude/rules/*.md` cargados bajo demanda via frontmatter `paths`, fusionando con reglas existentes y dejando el CLAUDE.md base con solo informacion que aplica a todo el proyecto.
stabilize
>
document-endpoints
Esta skill debe usarse cuando el usuario pide "documenta los endpoints", "documenta la API", "documentar las rutas", "document the endpoints", "document the API", "necesito la doc de los endpoints para el frontend", o cuando menciona documentar endpoints HTTP para consumo desde el frontend. Tambien activar cuando el usuario menciona pasar endpoints al frontend, compartir contratos HTTP, o preparar documentacion de rutas REST. No usar para WebSockets ni socket.io (usar document-sockets en su lugar).
document-sockets
Esta skill debe usarse cuando el usuario pide "documenta los sockets", "documenta los eventos", "documentar websockets", "document the sockets", "document socket events", "necesito la doc de los sockets para el frontend", o cuando menciona documentar eventos de socket.io para consumo desde el frontend. Tambien activar cuando el usuario menciona pasar eventos al frontend, compartir contratos de sockets, o preparar documentacion de eventos en tiempo real. No usar para endpoints HTTP REST (usar document-endpoints en su lugar).
domain-restructure
Use this skill when the user asks to "restructure by domain", "group by feature", "apply screaming architecture", "reorganize the architecture", "move everything into modules per domain", "domain-driven folder structure", "my project is organized by layers and I want it by features", or mentions that their code is layer-first (controllers/, services/, models/ at the top) and wants the structure to scream the business. Also use it with the ultracode trigger for architectural restructuring. It runs a PURE STRUCTURAL refactor (zero functional change): it discovers domains via strategic DDD, classifies them core/supporting/generic, moves files into modules/<domain>/<layer>, and rewrites imports — all inside a dedicated worktree, closing with a single green commit. It is NOT for tactical modeling (entities, aggregates, events) — it only reorganizes where files live.
claude-code-agent-creator
Crea archivos markdown de sub-agentes de Claude Code (con YAML frontmatter y system prompt) listos para colocar en ~/.claude/agents/, .claude/agents/ o agents/ de un plugin. Usa esta skill proactivamente cuando el usuario diga "crea un agente", "create an agent", "necesito un sub-agente que...", "scaffold an agent", "haz un auditor", "make a code reviewer agent", "agente que revise", "agente que audite", "agente que investigue", o cuando describa funcionalidad especializada que conviene aislar en un sub-agente (ej. "necesito algo que revise PRs", "quiero un agente que analice seguridad"). Cubre seleccion de tools con principio de menor privilegio, tuning de description para auto-invocacion, eleccion de arquetipo (auditor / researcher / implementer / orchestrator), calibracion de modelo + effort segun la carga de razonamiento de la tarea (mas mecanico = modelo mas ligero y menos effort) e incluye un sistema de scoring de confianza 0-100 con umbral >=80 para agentes tipo auditor.
lib-advisor
>-
plan-constraints
>-
workflow-creator
Designs, writes, or audits dynamic workflows for Claude Code — the JavaScript orchestration scripts the Workflow tool runs to fan many subagents across one large job (triggered by 'ultracode' or by asking to "use a workflow"). Use this skill proactively whenever the user says "create a workflow", "write a dynamic workflow", "orchestrate subagents", "fan out agents", "parallelize this with agents", "codebase-wide audit", "massive bug hunt", "ultracode workflow", "port this from X to Y", "migrate the whole repo", or describes work a single pass can't hold (repo-wide audits, large migrations, language ports, verified multi-source research). Also use it to audit or review an existing workflow script — "audit this workflow", "review my orchestration script", "is this workflow correct", "improve this workflow" — checking data-flow shape, per-role thinking load, and runtime safety. For authoring a single isolated sub-agent that reports back once, this is not the skill. Reach for this even when the user only hints at coordinating many agents or scaling a job beyond one context window.
branching
>
commit
>
conflict-resolver
>
squash-suggester
>
split-component
Esta skill debe usarse cuando el usuario pide "dividir componente", "separar componente", "split component", "extraer componentes", "componente muy grande", "refactorizar componente grande", "break down component", "este archivo tiene muchas responsabilidades", o menciona que un archivo React tiene demasiado codigo, demasiado estado, o demasiada logica mezclada con UI. Analiza un componente React y lo divide en piezas mas manejables siguiendo el patron smart/dumb components.
refactor
>
smell-scan
>
close-design
>
create-specification
Create a new, closed and self-contained specification file optimized for Generative AI consumption and cold execution via the /goal command. Scaffolds the managed Design Gaps section that the close-design loop consumes. Use when the user wants to write a new spec, draft a specification, capture requirements, or plan a substantial change as a cold-executable spec.
implement-spec
>
update-specification
Update an existing specification file optimized for Generative AI consumption, based on new requirements or code changes. Also the living-document maintainer for the spec-kit closure loop: folds accepted Design Gaps into the spec body and removes resolved entries from the managed section. Use when the spec drifted from the code, requirements changed, the implementation diverged, or the user says to sync, revise, or update the spec.
Page 1324 of 1666 · 83268 results