Agent team dev
Multi-agent harness configurations: agent teams, safety hooks, skills and context engineering patterns
npx -y skills add mike-diff/ai-coding-configs --skill agent-team-devAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Run the Agent Team dev workflow in pi for this repo. Use when implementing a validated feature or spec-backed phase with preflight, exploration, clarification, implementation, reflection, review, QA and wrapup.
SKILL.md
4.3 KB, as published. Nobody here has run it
Agent Team Dev
Use this skill to run the Agent Team /dev workflow from pi while maintaining repo parity.
Source of truth
The product workflow source of truth is:
.claude/skills/dev/SKILL.md.claude/skills/dev/references/workflow.md.cursor/skills/dev/SKILL.md.cursor/skills/dev/references/workflow.md
Read those files when details matter. This pi skill is a maintainer/operator wrapper, not a fourth independent workflow implementation.
Modes
Spec-backed mode
Use when the request includes @.context/specs/....
- Read the spec before implementation.
- Verify Requirement Validation and Architecture Validation status.
- Treat the spec as the contract.
- Do not expand scope without asking.
- Implement the requested phase or task graph slice.
Single-phase vs sweep: a named phase (/dev "Implement Phase 1" @<spec>) builds that one phase. A spec path with no single phase (/dev @<spec>, /dev "all phases" @<spec>) is sweep mode: explore + clarify once, then work the spec's phases in dependency order, one at a time, committing at every phase boundary, fully autonomously. pi has no TaskCreate/shared-task-list tool and no sub-agents, so track progress with an explicit ordered phase checklist kept in your working notes (or in the spec file): read the spec, implement the current phase, verify, commit, then move to the next; native compaction handles context across the sweep. Halt the sweep on a blocked phase or high-risk escalation; do not cascade into dependent phases. (The source-of-truth workflow.md describes the same loop using Claude Code's TaskCreate task graph, which is Claude-only — translate it to the sequential checklist above on pi.)
Ad hoc mode
Use for small validated changes without a spec.
- Explore the codebase first.
- Ask clarifying questions if acceptance criteria or boundaries are unclear.
- Keep scope minimal.
Process
- Preflight
- Check
git status --short. - Note pre-existing dirty files.
- Restore or ignore
.claude/.logs/hooks.logunless explicitly requested.
- Check
- Explore
- Read relevant files before editing.
- Search for existing utilities and patterns.
- Clarify
- Ask before implementation if scope, behavior, data, auth, migrations, billing, deployment, or public API contracts are unclear.
- Implement
- Use test-first workflow for non-trivial code.
- Make minimal focused changes.
- Keep generated specs in
.context/specs/uncommitted.
- Reflect
- Check spec coverage, assumptions, scope and weak spots.
- Review and QA
- Use a single focused review pass for low-risk work.
- For security, data, migrations, dependencies, public contracts, cross-layer work, or user-requested thorough review, do a deeper multi-pass review — pi is single-agent, so this is sequential review lenses in one session, not spawned reviewer teammates (the
.claude/.cursorsource describes a spawned review council). - Run relevant validation commands.
- Commit or PR-ready
- Commit only if requested or appropriate for the task.
- Otherwise report PR-ready state.
- Wrapup
- Capture what shipped, verification, lessons, assumptions, follow-ups and ship handoff.
High-risk assumptions
Stop and ask before changing behavior involving:
- Product scope
- Auth or authorization
- User data or privacy
- Migrations or destructive operations
- Billing or payments
- External side effects
- Public API contracts
- Deployment
Repo validation
After workflow config changes, run:
./tests/workflow-contract.sh
bash -n tests/workflow-contract.sh tests/smoke.sh scripts/sync-plugin.sh .claude/hooks/*.sh .cursor/hooks/*.sh plugins/agent-team/hooks/*.sh
git diff --check
When plugin behavior changes, run:
COMMAND_TIMEOUT_SECONDS=60 ./tests/smoke.sh
Completion response
DEV complete
Terminal state: [committed / pr-ready / blocked / failed]
Spec: [.context/specs/... or none]
Validation: [commands + status]
Review: [default / council]
Wrapup: [lessons and follow-ups captured]