Quest — Dispatch Task to Party

Context: The skill-context hook injects NPC state when this skill is invoked. Use the Project dir value as $PROJECT_DIR in bash commands below. The active party name is available directly from hook context.

Send a task to an adventuring party. Each party member approaches the task from their alignment+class perspective, then the results are synthesized.

Quests can operate in three ways:

• •Analysis (default): Party members give perspectives on a task. Nothing persistent is created.
• •Work a bead (--bead <id>): Party members claim and execute tasks from an existing epic's ready front.
• •Create work (--create): After analysis, persist the recommendations as a beads epic with tasks.

Arguments

$ARGUMENTS

Parse Arguments

• •task (required): Everything that isn't a flag. This is the quest description.
• •--mode council|expedition: Execution mode. Default: council.
  • •council: Single agent inhabits each member's perspective sequentially.
  • •expedition: Each member runs as a parallel subagent via the Task tool.
• •--party name: Target party. If omitted, uses the active party.
• •--bead id: An existing epic or task bead ID. Party members work its ready front instead of giving analysis.
• •--create: After analysis, create a beads epic with child tasks from the synthesis recommendations.

--bead and --create are mutually exclusive. If both are provided, error: "Use --bead to work existing beads or --create to generate new ones, not both."

Member Display Convention

Throughout this skill, identify members by their character bead title (name). If the character has a role label, prefix with the role.

Step 1: Load the Party

Resolve which party to use. If --party specified, resolve via resolve-party.sh. Otherwise use active party from hook context and resolve.

PARTY_ID=$("$PROJECT_DIR"/hooks/scripts/resolve-party.sh "<party-name>")

Get party details and members:

bd show "$PARTY_ID" --json
bd children "$PARTY_ID" --json

For each child bead, extract:

• •name: bead title
• •alignment: from alignment:* label
• •class: from class:* label (may be absent)
• •role: from role:* label (may be absent)
• •persona: bead description

If the party has no children, error: "Party <name> has no members. Use /recruit to add members first."

Step 2: Safety Check

Before executing, check for Evil-aligned members (alignment label contains "evil").

For each Evil member:

• •Announce: "<name> has an Evil alignment (<alignment>). Evil members will operate under safety constraints."

If any Chaotic Evil member:

• •Require explicit confirmation. Ask the user to type "unleash the gremlin" before proceeding.

If any other Evil member (Lawful Evil or Neutral Evil):

• •Announce and ask: "Proceed with Evil-aligned members? [Y / Remove]"

Class-specific Evil constraints:

• •Evil + Rogue: "This member is restricted to analysis only — no code production."
• •Evil + Cleric: "This member's infrastructure changes require explicit approval."

Step 3: Announce the Quest

Display the quest briefing:

## Quest Briefing

**Party:** <party-name> (<N> members)
**Mode:** <council|expedition>
**Task:** <task description>

If --bead is set, also show:

**Working bead:** <bead-id> — <bead title>

And run bd swarm status <bead-id> to show the current ready front.

### Roster
| # | Name | Alignment | Class | Role |
|---|------|-----------|-------|------|
| 1 | <name> | <alignment> | <class or "—"> | <role or "—"> |
| ... | ... | ... | ... | ... |

If any members have a persona, list them:

**Personas:**
- **<name>**: <persona text>

Step 4: Execute

If --bead is provided: Work the Ready Front

This replaces the normal analysis flow. The party works real beads tasks.

1. •

   Load the bead's work:

   bash

   bd show <bead-id> --json
   bd children <bead-id> --json
   bd swarm status <bead-id>
   

2. •

   Identify ready tasks — tasks that are open/unblocked and unclaimed (no assignee or status=open).

3. •

   Match tasks to party members by class affinity:

   • •Look at each task's type and content. Match to the party member whose class has the highest affinity for that kind of work.
   • •If multiple members suit a task, prefer the one without active work.
   • •If no clear match, assign to the member with the broadest affinities (typically Fighter).
4. •

   For each matched member-task pair, execute using the chosen mode:

   Council mode: For each member sequentially:

   • •Read their alignment + class SKILL.md files
   • •Adopt their character fully (see "Council Mode" section below for details)
   • •Claim: bd update <task-id> --status=in_progress -a "<member-name>"
   • •Work the task from their perspective — actually produce the deliverable (code, analysis, design, tests, etc.)
   • •Close: bd close <task-id>
   • •Show updated swarm status: bd swarm status <bead-id>

   Expedition mode: For each member in parallel, launch a Task subagent whose prompt includes:

   • •The character profile (alignment, class, persona)
   • •Instructions to read their SKILL.md files
   • •The specific task to work (bead ID, title, description)
   • •Instructions to claim (bd update <id> --claim), work, and close (bd close <id>)
5. •

   After all ready tasks are worked, show final swarm status.

6. •

   If more waves are now unblocked, announce: "Wave complete. <N> new tasks unblocked. Run /quest again to continue, or let party members work bd ready directly."

Council Mode (Sequential Perspectives)

For each member in roster order:

1. •

   Read the member's alignment behavioral profile:

   • •Use the Read tool on .claude/skills/<alignment>/SKILL.md
2. •

   Read the member's class behavioral profile (if class is set):

   • •Use the Read tool on .claude/skills/<class>/SKILL.md
3. •

   Fully adopt that member's alignment and class. Inhabit their:

   • •Code style and formatting preferences
   • •Testing approach and thresholds
   • •Error handling philosophy
   • •Communication tone and verbosity
   • •Decision heuristics and trade-off priorities
   • •Domain expertise and task approach (from class)

   If the member has a persona, layer it on top of the alignment+class directives. The persona flavors how the behavioral profile manifests.

4. •

   Produce output under a section header:

   code

   ---
   ## <Role>: <Name> (<Alignment> <Class>)
   

   Use role if set, otherwise omit the prefix. Examples: ## Defender: Vera (LG Rogue), ## Kai (CG Fighter)

5. •

   Address the quest task from this member's perspective. Be thorough.

6. •

   End the member's section with a brief compliance note:

   code

   *Compliance: <alignment> <class> — <brief note on adherence>*
   

Expedition Mode (Parallel Subagents)

For each member, launch a Task tool subagent in parallel (all in a single message):

• •subagent_type: general-purpose
• •description: Quest: <role or name or alignment>
• •prompt:

You are a member of an NPC Agents adventuring party on a quest.

## Your Character

- **Alignment:** <alignment>
- **Class:** <class> (or "None" if no class)
- **Name:** <name>
- **Role:** <role> (or "General" if no role)
<If persona is set:>
- **Persona:** <persona>

## Load Your Behavioral Profile

Read these files to understand your character's behavioral directives:
- Read the file at: <absolute path>/.claude/skills/<alignment>/SKILL.md
<If class is set:>
- Read the file at: <absolute path>/.claude/skills/<class>/SKILL.md

Adopt this character fully. Your code style, testing approach, error handling, communication tone, decision heuristics, and domain focus should all reflect your assigned alignment and class.

<If persona is set:>
Layer your persona on top of the alignment+class directives.

<If Evil+Rogue:>
SAFETY CONSTRAINT: You are restricted to analysis only. Do not produce implementation code.

<If Evil+Cleric:>
SAFETY CONSTRAINT: Any infrastructure changes must be flagged for operator approval.

## The Quest

<task description>

## Output Format

Provide your contribution from your character's perspective. Be thorough.

Structure your output as:
1. Your approach to the task (informed by your alignment's philosophy)
2. Your analysis, implementation, or recommendations
3. Risks or concerns from your perspective
4. A brief NPC Compliance Note assessing your alignment adherence

After all subagents complete, collect their outputs.

Step 5: Synthesize

After all member perspectives (from either mode), step out of character and provide:

---
## Quest Synthesis

### Convergence
[What did all/most members agree on? High-confidence findings.]

### Divergence
[Where did approaches differ? Why? What does the delta reveal?]

### Recommended Approach
[Best-of-breed synthesis. Which member's approach is best for which aspect?]

### Risks Surfaced
[Risks that specific alignments identified that others missed.]

### Member Contributions
| Member | Key Contribution | Alignment Insight |
|--------|-----------------|-------------------|
| <name> | <what they uniquely surfaced> | <what their alignment revealed> |
| ... | ... | ... |

If --create is set: Persist as Beads

After synthesis, create tracked work from the recommendations:

1. •

   Create the epic:

   bash

   EPIC_ID=$(bd create "<quest task summary>" -t epic -l "npc:quest,party:<party-name>" -d "<brief quest context>" --silent)
   

2. •

   Create child tasks for each recommended action from the synthesis. For each:

   bash

   TASK_ID=$(bd create "<action title>" -t task --parent "$EPIC_ID" -l "assigned:<best-member>" -d "<description from synthesis>" --silent)
   

   Match task type to bead type where appropriate: use -t bug for identified defects, -t feature for new functionality, -t task for general work, -t chore for maintenance.

3. •

   Wire dependencies based on the synthesis ordering. If task B should follow task A:

   bash

   bd dep add "$TASK_B_ID" "$TASK_A_ID"
   

4. •

   Show the result:

   bash

   bd graph "$EPIC_ID"
   bd swarm validate "$EPIC_ID"
   

5. •

   Announce: "Quest work created as <epic-id>: <title>. Party members can start with bd ready."

If --bead is set: Show Progress

After working the ready front, show final status instead of the normal synthesis:

---
## Quest Progress: <bead-title>

<output of bd swarm status <bead-id>>

### Work Completed This Quest
| Task | Member | Status |
|------|--------|--------|
| <task title> | <member who worked it> | completed / in_progress |

### Next Steps
[What's now unblocked? Who should pick it up? Any new work discovered?]

Notes

• •Council mode processes sequentially — later members can react to earlier output. Good for debates.
• •Expedition mode spawns parallel subagents — truly independent perspectives. Good for unbiased comparison.
• •Party size: 2-4 members is the sweet spot. 5-6 works but produces long output.
• •--bead mode is for working through existing tracked work. The party executes, not just analyzes.
• •--create mode turns analysis into tracked beads. Good when a quest surfaces work that should be persistent.
• •Default mode (no flags) is the original one-shot analysis. Still useful for quick perspectives without beads overhead.