// Use when adding, updating, splitting, or reviewing local orchestrator skills for reusable procedures, including controlled self-improvement of the orchestrator.
| name | create-skill |
| description | Use when adding, updating, splitting, or reviewing local orchestrator skills for reusable procedures, including controlled self-improvement of the orchestrator. |
Use a skill when a procedure is reusable, conditional, and too detailed for always-loaded AGENTS.md.
Do not add a skill for one-off status, a current project decision, a private user workflow, or a rule that belongs in comms.md, projects.md, memory, or a project-local agent file.
Create ./.agents/skills/<name>/SKILL.md with required frontmatter:
---
name: <name>
description: Use when ...
---
# <Title>
The description is the trigger surface. Make it concrete enough that an agent can load the skill only when relevant.
Ship general mechanics: delegation, review cycles, durable jobs, handover, worktree isolation, cleanup.
Keep local-only: project-specific routing, named personal channels, account assumptions, private credentials, customer-specific policy, or personal release authority.
If a skill starts mixing both, split it: product-general guidance in the shipped skill, user-specific preferences in local memory or local-only skills.
Parallel divergent ideation via mesh fan-out. Spawns N frame-shifted peers, scores results, deepens top survivors. Use on open-ended design choices, fuzzy bugs, naming, API surfaces, or explicit /adhd invocation. Skip for syntax, lookups, or closed prompts ("quick", "standard", "canonical").
Use when orchestrating complex or multi-lane work, decomposing tasks across peers, choosing status/board surfaces, running mesh roundups, or keeping high-level progress visible.
Use when creating, updating, or explaining a standing Repowire agent folder, worker folder, durable-job executor context, or reusable agent-specific AGENTS.md guidance.
Use when transferring orchestrator responsibility, summarizing current state for a new peer, recovering after a closed session, or preparing takeover notes.
Use when coordinating PR review, CI triage, second-peer critique, requested-changes loops, merge readiness, or deciding whether implementation needs independent verification.
Use when splitting work across peers, creating or selecting feature worktrees, preventing overlapping edits, or deciding whether to reroute implementation out of the main worktree.