Agent Teams
Assign conjure agent-team members to implementer, researcher, tester, reviewer, or architect roles with a clear capability matrix before parallel work starts.
Overview
agent-teams is a journey-wide agent skill that defines crew roles and tool capabilities for multi-agent delegation—usable whenever a solo builder needs to split work across specialized agent members before committing.
Install
npx skills add https://github.com/athola/claude-night-market --skill agent-teamsWhat is this skill?
- Defines 5 crew roles: implementer, researcher, tester, reviewer, and architect
- 5×5 capability matrix covering read, write, edit, tests, builds, git, tasks, and messaging per role
- Default role is implementer for backward-compatible members without an explicit role
- Maps each role to focus areas—code, investigation, validation, review, and system design
- Parent skill conjure:agent-teams; category delegation-framework for night-market conjure stack
- 5 crew roles in the role taxonomy
- 5×5 role capability matrix
Adoption & trust: 2 installs on skills.sh; 304 GitHub stars; 3/3 security scanners passed (skills.sh audits); trending (+200% hot-view momentum).
What problem does it solve?
You run multiple agents in parallel but everyone has the same tools, so research agents rewrite code and reviewers accidentally ship changes.
Who is it for?
Solo builders orchestrating conjure-style agent teams who want a shared vocabulary for who may write, test, review, or architect.
Skip if: Single-agent sessions with one general-purpose assistant or projects that forbid multi-agent delegation entirely.
When should I use this skill?
Before spinning up or rebalancing a multi-member agent crew when tasks need different tool access (implementation, research, test, review, or architecture).
What do I get? / Deliverables
Each crew member gets an explicit role, allowed capabilities, and assignment focus so implementers build, researchers stay read-only, testers validate, reviewers comment, and architects own design decisions.
- Role assignments per crew member
- Capability-aligned task routing plan aligned to the matrix
Recommended Skills
Journey fit
Useful at every journey phase - explore requirements and options before committing to a direction.
Where it fits
Assign a researcher to map existing APIs read-only while an implementer spikes the UI without overlapping writes.
Use an architect for interface decisions and implementers for feature branches with git enabled only on builder roles.
Route PR commentary through reviewer roles that lack write tools so audit feedback does not mutate the tree.
Keep testers on read plus test execution to run suites without editing production code paths.
Pair a researcher investigating logs with an implementer flagged for hotfix edits under clear separation.
How it compares
Skill package for role taxonomy and permissions—not an MCP server and not a substitute for task-specific implementation skills.
Common Questions / FAQ
Who is agent-teams for?
Indie builders and small teams using Claude Code conjure/agent-teams who need a standard role and capability model before delegating parallel agent work.
When should I use agent-teams?
Use it during Build when configuring crews, during Ship when splitting reviewer vs tester lanes, during Validate when a researcher explores while an implementer prototypes, and during Operate when investigation and fix roles must stay separated.
Is agent-teams safe to install?
It is documentation and delegation rules, not arbitrary shell access by itself; review the Security Audits panel on this Prism page and still enforce least privilege per role in your agent runtime.
SKILL.md
READMESKILL.md - Agent Teams
# Crew Roles ## Role Taxonomy Each team member has a `role` that determines their capabilities and the types of tasks they can be assigned. | Role | Tools | Focus | Use When | |------|-------|-------|----------| | `implementer` | All tools | Code implementation | Building features, fixing bugs | | `researcher` | Read-only | Investigation, analysis | Codebase exploration, design research | | `tester` | Read and test execution | Testing, validation | Writing tests, running test suites | | `reviewer` | Read-only and comment | Code review, quality | Reviewing PRs, auditing code quality | | `architect` | All tools | Planning, design | System design, architectural decisions | **Default role**: `implementer` (backward compatible: members without an explicit role are treated as implementers). ## Capability Matrix | Capability | implementer | researcher | tester | reviewer | architect | |-----------|:-----------:|:----------:|:------:|:--------:|:---------:| | Read files | Yes | Yes | Yes | Yes | Yes | | Write files | Yes | No | No | No | Yes | | Edit files | Yes | No | No | No | Yes | | Run tests | Yes | No | Yes | No | Yes | | Run builds | Yes | No | Yes | No | Yes | | Git operations | Yes | No | No | No | Yes | | Create tasks | Yes | No | No | Yes | Yes | | Send messages | Yes | Yes | Yes | Yes | Yes | | Plan mode | Optional | No | No | No | Required | ## Role-Risk Compatibility Not all roles can handle all risk tiers. The lead validates compatibility before assigning tasks: | Risk Tier | Allowed Roles | Additional Requirement | |-----------|--------------|----------------------| | **GREEN** | Any role | None | | **YELLOW** | implementer, tester, architect | None | | **RED** | implementer, architect | Lead oversight required | | **CRITICAL** | architect only | Human approval required | **Rationale:** - GREEN tasks are safe for anyone, including researchers and reviewers - YELLOW tasks need write access (implementer/architect) or test execution (tester) - RED tasks need experienced agents with full tool access and active lead monitoring - CRITICAL tasks need the most strategic role (architect) with human sign-off ## Role Assignment ### At Spawn Time Roles are assigned when spawning teammates: ```bash claude --agent-id "backend@my-team" \ --agent-name "backend" \ --agent-role "implementer" \ --team-name "my-team" \ ... ``` ### Dynamic Role Change Roles can be changed during execution via team config update: ```json { "agent_id": "backend@my-team", "role": "reviewer" } ``` Role changes take effect immediately. The lead should reassign any in-progress tasks that are incompatible with the new role. ## Role-Based Task Routing When the lead assigns tasks, it should consider role compatibility: ``` For each pending task: 1. Determine task risk tier (from metadata or classify) 2. Filter available agents by role-risk compatibility 3. Prefer agents whose role matches the task type: - Implementation tasks → implementer - Research/investigation → researcher - Test writing/validation → tester - Code review → reviewer - Architecture/planning → architect 4. Assign to best-fit available agent ``` --- name: health-monitoring description: Agent health tracking, stall detection, and automated recovery via heartbeat monitoring and claim expiry parent_skill: conjure:agent-teams category: delegation-framework estimated_tokens: 250 --- # Health Monitoring ## Member Health Fields Each team member's config gains a `health` object for tracking operational status: ```json { "agent_id": "backend@my-team", "name": "backend", "role": "implementer", "health": { "status": "healthy", "last_heartbeat": "2026-02-07T22:15:00Z", "last_task_update": "202