Install
$ agentstack add skill-justinmchoi-ai-toolkit-setup-agent-team ✓ scanned · ✓ verified — works with Claude Code, Cursor, and more.
Security review
✓ PassedNo issues found. Passed automated security review. · v0.1.0 How review works →
- ✓ Prompt-injection patterns
- ✓ Secret / credential exfiltration
- ✓ Dangerous shell & filesystem operations
- ✓ Untrusted network calls
- ✓ Known-malicious package signatures
What it can access
- ✓ Network access No
- ✓ Filesystem access No
- ✓ Shell / process execution No
- ✓ Environment & secrets No
- ✓ Dynamic code execution No
From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.
About
Setup Agent Team
Overview
Use this skill to decide whether agent-team delegation is warranted and, when it is, produce a tool-neutral manual execution packet. Do not launch subagents, run runtime-specific workers, or edit the target repo as part of setup.
Trigger Gate
Use an agent team only when all are true:
- The work spans multiple domains, surfaces, or viewpoints.
- Meaningful parts can proceed in parallel.
- A single agent's context would become too large, tangled, or risk-prone.
Refuse or downgrade for:
- Small bugs
- Single-file edits
- Clear one-slice features
- Narrow docs/spec/glossary edits
- Tasks with no meaningful parallel ownership
- Requests that need broad write access before scope is known
- Private-vault, credential, production, or package-fetching work without
explicit approval
If refusing, output a short downgrade decision and recommend the appropriate single-agent workflow.
Workflow
- Inspect the user goal and available repo/project context.
- Record the project baseline: path, repo guide, worktree state, known user
changes, existing verification, and whether this continues an existing project or starts a new one.
- Apply the trigger gate. Refuse if the task does not meet it.
- Select only roles that own distinct questions, artifacts, or verification
responsibilities.
- Define context packets for each selected role.
- Define ownership boundaries, read/write scopes, and disallowed paths.
- Identify external systems and credential policy.
- Identify package-manager and dependency-execution policy.
- Define parallelizable tasks, parallelization safety, blocking dependencies,
handoff protocol, integration owner, verification plan, budgets, and stop conditions.
- Output the execution packet and wait for user approval before any worker
launch or implementation.
Role Catalog
Coordinator: Maintains goal, decomposition, dependencies, integration order, context allocation, conflict resolution, and final synthesis.
Product Analyst: Clarifies user behavior, scope, acceptance criteria, and product trade-offs.
Architecture Reviewer: Checks boundaries, data flow, risks, existing patterns, and long-term design pressure.
Frontend Engineer: Owns UI, UX, component boundaries, frontend tests, and browser verification.
Backend Engineer: Owns APIs, domain logic, data contracts, persistence, and server-side tests.
Test Engineer: Owns test strategy, coverage gaps, regression checks, and verification risk.
Documentation Maintainer: Owns README, context, ADRs, specs, issue notes, and handoff documentation.
Ad hoc workers may be added only when they receive a bounded task, context packet, output contract, and stop condition.
Required Packet Fields
Produce these fields:
- Goal
- Trigger reason
- Project baseline and worktree state
- Selected roles
- Roles refused and why
- Context packet per role
- Ownership boundaries
- Parallelizable tasks
- Parallelization safety
- Blocking dependencies
- External systems and credential policy
- Package execution policy
- Handoff protocol
- Integration owner
- Verification plan
- Team budget
- Per-worker budget
- Stop conditions
External Systems And Credentials
For each external system, state:
- Purpose
- Whether it is needed for implementation, verification, or both
- No-secret verification path
- Credentialed verification path
- Whether a disposable test environment is required
- Who provides credentials or access
- Required scopes or roles
- Whether production data or production credentials are forbidden
- Stop condition if credentials are unavailable
Prefer no-secret verification first. Use disposable test environments for risky or stateful integration checks. Do not infer, locate, print, or exfiltrate credentials.
Package Execution Policy
Treat package managers as an execution boundary.
Distinguish:
- Local scripts, such as
npm run checkornpm start - Dependency installs, such as
npm installornpm ci - Remote package execution, such as
npx,npm exec,pnpm dlx, or
equivalents
Default rules:
- Prefer existing local scripts.
- Do not use
npxas a security shortcut. - Do not add, update, install, or remotely execute packages without explicit
approval.
- Pin package names and versions before any approved install or remote
execution.
- Use an isolated runtime or
--ignore-scriptswhen install scripts are not
required.
Parallelization Safety
Before recommending parallel workers, state:
- Independent file or artifact sets
- Shared contracts, schemas, interfaces, routes, or docs
- Expected integration order
- Whether an integration checkpoint is required before more edits
- Conflict risk: low, medium, or high
If independent ownership cannot be stated clearly, downgrade to sequential work or a single-agent workflow.
Output Templates
Refusal
# Agent Team Decision
- decision: refuse / downgrade
- reason:
- recommended single-agent workflow:
- verification:
Execution Packet
# Agent Team Execution Packet
## Goal
## Project Baseline
## Trigger Reason
## Selected Roles
## Roles Not Selected
## Context Packet Per Role
## Ownership Boundaries
## Parallelizable Tasks
## Parallelization Safety
## Blocking Dependencies
## External Systems And Credential Policy
## Package Execution Policy
## Handoff Protocol
## Integration Owner
## Verification Plan
## Team Budget
## Per-Worker Budget
## Stop Conditions
Handoff Format
Require every future role or worker to report:
## Result
## Evidence
- Files inspected:
- Commands run:
- Findings:
- Changed files:
## Decisions Needed
## Risks
## Verification
- Passed:
- Failed:
- Not run:
## Knowledge And Documentation Updates
- Durable knowledge update required:
- Documentation update required:
## Next Handoff
- Recommended next owner:
- Context they need:
- Suggested task:
Stop Conditions
Stop setup when:
- The task should stay single-agent.
- Required context is missing.
- Credentials, private data, package-fetching, destructive actions, or external
network access are needed before approval.
- Ownership boundaries cannot be made explicit.
- Worker budgets would be speculative.
- The user has not approved moving from packet setup to execution.
Source & license
This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.
- Author: justinmchoi
- Source: justinmchoi/ai-toolkit
- License: MIT
Install and usage instructions live in the source repository linked above.
Reviews
No reviews yet — be the first.
Write a review
Versions
- v0.1.0 Imported from the upstream source.