// Use when creating, updating, or explaining a standing Repowire agent folder, worker folder, durable-job executor context, or reusable agent-specific AGENTS.md guidance.
| name | create-agent |
| description | 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 an agent folder when a repeatable worker needs standing context: domain rules, tool expectations, privacy boundaries, output format, or durable-job instructions.
Agent folders are a convention, not a registry. Jobs and spawns still target --path --backend [--profile].
repowire agents create <name> --backend <runtime>
The command creates .repowire/agents/<name>/AGENTS.md. For Claude Code it also creates CLAUDE.md as a shim. Other supported runtimes load AGENTS.md directly.
Keep it specific to the worker:
Do not store secrets, personal tokens, absolute machine paths, or one user's private service assumptions in a shipped template.
Use the folder as the durable execution context:
repowire jobs create "Daily brief" \
--path "$(pwd)/.repowire/agents/daily-brief" \
--backend codex \
--cron "0 8 * * *" \
--prompt "Prepare the brief and update this job with the result."
If the worker is only a one-off prompt with no standing context, create a normal job instead of an agent folder.
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 adding, updating, splitting, or reviewing local orchestrator skills for reusable procedures, including controlled self-improvement of the orchestrator.
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.