---
name: Delegation
slug: delegation
category: AI Engineering
description: Delegation helps you hand work to a peer by choosing whether to reuse or spawn a fresh one, and by writing briefs for fixes, features, plans, or review. Use it when you need critique, parallel work, or a second opinion before merge.
github: "https://github.com/prassanna-ravishankar/repowire/tree/main/daemon-go/cli/assets/orchestrator/.agents/skills/delegation"
language: Go
stars: 260
forks: 34
install: "npx degit https://github.com/prassanna-ravishankar/repowire/tree/main/daemon-go/cli/assets/orchestrator/.agents/skills/delegation ~/.claude/skills/delegation"
installs_to: ~/.claude/skills/delegation
source_path: daemon-go/cli/assets/orchestrator/.agents/skills/delegation/SKILL.md
collection_size: 17
category_size: 2631
collection_url: "https://dirskills.com/collections/prassanna-ravishankar/repowire"
added: 2026-09-02T05:20:18.849Z
last_synced: 2026-09-02T05:20:18.849Z
canonical_url: "https://dirskills.com/skills/delegation"
---

# Delegation

Delegation helps you hand work to a peer by choosing whether to reuse or spawn a fresh one, and by writing briefs for fixes, features, plans, or review. Use it when you need critique, parallel work, or a second opinion before merge.

**Install:**

```bash
npx degit https://github.com/prassanna-ravishankar/repowire/tree/main/daemon-go/cli/assets/orchestrator/.agents/skills/delegation ~/.claude/skills/delegation
```

## README

# Delegation

Use this when giving work to a peer.

## Spawn or reuse

Reuse a peer when the work continues its existing context in the same worktree. Spawn fresh for independent review, decoupled concerns, cross-model critique, or when the current peer's context is too long.

One worktree per concern. Do not put two implementation peers on overlapping files in the same worktree.

## Brief shape

Calibrate brief depth to the cost of getting it wrong.

- Small fix: one sentence plus file/line.
- Bug fix: repro, file/line hints, and verification.
- Feature work: success criteria, relevant files, docs impact, and reporting surface.
- Architecture: plan-before-code, risks to probe, expected output shape, and citations.

Always include what success looks like and how the peer should report back.

## Plan before code

Ask for a plan before code when a wrong approach would cost more than about 30 minutes to unwind. For architectural-but-bounded plans, use a different-model peer to critique before implementation.

Critique brief: include the proposed plan, files to inspect, risks to probe, and ask for skeptical-but-fair feedback with citations. Relay the critique back to the implementing peer and ask them to absorb or push back with reasoning.

## Review before merge

Use a different peer for review when stakes warrant. CI green is not feature verification; smoke the actual behavior for UI, API, or workflow changes.