By GoCodeAlone
Autonomous development workflow skills for coding agents: design, review, planning, execution, monitoring, and retrospectives
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores requirements and design before implementation.
Execute plan in batches with review checkpoints
Create detailed implementation plan with bite-sized tasks
An **interface boundary** is any point where two independent components exchange data or control. The canonical boundary classes are:
Use this agent when a major project step has been completed and needs to be reviewed against the original plan and coding standards. Examples: <example>Context: The user is creating a code-review agent that should be called after a logical chunk of code is written. user: "I've finished implementing the user authentication system as outlined in step 3 of our plan" assistant: "Great work! Now let me use the code-reviewer agent to review the implementation against our plan and coding standards" <commentary>Since a major project step has been completed, use the code-reviewer agent to validate the work against the plan and identify any issues.</commentary></example> <example>Context: User has completed a significant feature implementation. user: "The API endpoints for the task management system are now complete - that covers step 2 from our architecture document" assistant: "Excellent! Let me have the code-reviewer agent examine this implementation to ensure it aligns with our plan and follows best practices" <commentary>A numbered step from the planning document has been completed, so the code-reviewer agent should review the work.</commentary></example>
Skills refer to model tiers by **role** rather than by brand name so they read
Shared rules that every team agent (implementer, spec-reviewer, code-reviewer)
Use after a design or implementation plan is drafted, before downstream skills accept it - adversarially attacks the ideas in the artifact (not just structural coverage) to surface unstated assumptions, repo-precedent conflicts, YAGNI violations, missing failure modes, security gaps, and simpler alternatives the author didn't consider
Use after writing-plans to verify the implementation plan covers all design requirements without drift or scope creep
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
Use when producing design docs, adversarial review reports, implementation plans, progress logs, or phase handoffs where token efficiency matters and precision must be preserved
Use when creating a demo, example, quickstart, showcase, sample, or any artifact meant to prove an implementation works — before writing it. Triggers when about to "show it working", build a proof-of-concept, or generate sample output, especially under time pressure or when the real code is awkward to run. Catches fake demos that reimplement the logic, hard-code the output, or rewrite it in another language instead of executing the real artifact.
Executes bash commands
Hook triggers when Bash tool is used
Modifies files
Hook triggers on file write and edit operations
Own this plugin?
Verify ownership to unlock analytics, metadata editing, and a verified badge. GitHub access is read-only (username + org membership).
Sign in to claimOwn this plugin?
Verify ownership to unlock analytics, metadata editing, and a verified badge. GitHub access is read-only (username + org membership).
Sign in to claimBased on adoption, maintenance, documentation, and repository signals. Not a security audit or endorsement.
Uses power tools
Uses Bash, Write, or Edit tools
Uses power tools
Uses Bash, Write, or Edit tools
No model invocation
Executes directly as bash, bypassing the AI model
No model invocation
Executes directly as bash, bypassing the AI model
Autonomous Dev Kit is a complete software development workflow for your coding agents, built on top of a set of composable "skills" and some initial instructions that make sure your agent uses them.
It starts from the moment you fire up your coding agent. As soon as it sees that you're building something, it doesn't just jump into trying to write code. Instead, it steps back and asks you what you're really trying to do.
Once it's teased a spec out of the conversation, it shows it to you in chunks short enough to actually read and digest.
After you've signed off on the design, your agent puts together an implementation plan that's clear enough for an enthusiastic junior engineer with poor taste, no judgement, no project context, and an aversion to testing to follow. It emphasizes true red/green TDD, YAGNI (You Aren't Gonna Need It), and DRY.
Next up, once you say "go", it launches a subagent-driven-development process, having agents work through each engineering task, inspecting and reviewing their work, and continuing forward. In capable hosts, agents can work autonomously for long stretches without deviating from the plan you put together.
There's a bunch more to it, but that's the core of the system. And because the skills trigger automatically, you don't need to do anything special. Your coding agent just has Autonomous Dev Kit.
Autonomous Dev Kit originated as a fork of Jesse Vincent's Superpowers repo.
Note: Installation differs by platform. Claude Code or Cursor have built-in plugin marketplaces. Codex can use the open skills CLI (npx skills add) or manual setup. OpenCode, Hermes Agent, and Zed currently use manual setup.
Zed's June 2026 Skills docs require each skill to be a direct child of ~/.agents/skills/ (global) or <worktree>/.agents/skills/ (project-local). Use ADK's Zed installer rather than the namespace symlink used by some other hosts.
macOS/Linux:
# Clone the autodev repository
git clone https://github.com/GoCodeAlone/autonomous-dev-kit.git ~/.agents/autodev
# Link each ADK skill into Zed's flat skills root
~/.agents/autodev/scripts/install-zed.sh
WSL2 with Windows-native Zed: run the same Bash installer from WSL. It detects WSL and, when /mnt/c/Users/<linux-user> exists, copies the skills into the Windows profile path Zed scans: /mnt/c/Users/<linux-user>/.agents/skills (C:\Users\<user>\.agents\skills). If your Windows username differs from your WSL username, pass it explicitly:
~/.agents/autodev/scripts/install-zed.sh --skills-root /mnt/c/Users/<WindowsUser>/.agents/skills --copy --force
Windows (PowerShell):
git clone https://github.com/GoCodeAlone/autonomous-dev-kit.git "$env:USERPROFILE\.agents\autodev"
& "$env:USERPROFILE\.agents\autodev\scripts\install-zed.ps1"
Add this once to Zed personal instructions (~/.config/zed/AGENTS.md, or %APPDATA%\Zed\AGENTS.md on Windows):
# Autonomous Dev Kit host declaration
Host: zed-agent
When reading ADK skills, follow host-neutral instructions and `<host: zed-agent>` blocks. Ignore host blocks for claude-code, codex, opencode, cursor, and hermes-agent unless explicitly running that External Agent instead of Zed Agent.
For project-local install instead of global install, run from a trusted project worktree:
git clone https://github.com/GoCodeAlone/autonomous-dev-kit.git .autodev-kit
.autodev-kit/scripts/install-zed.sh --scope project --project-root .
Windows PowerShell:
git clone https://github.com/GoCodeAlone/autonomous-dev-kit.git .autodev-kit
& ".\.autodev-kit\scripts\install-zed.ps1" -Scope Project -ProjectRoot .
Project-local Zed skills are written under <worktree>/.agents/skills/ and load only after Zed trusts the worktree.
Then open Zed's AI > Skills page or start a new Zed Agent thread and ask help me plan this feature. Skills live-reload; start a fresh thread if the catalog was already cached.
If Zed says no global skills are installed after the installer reports success:
In Zed, open AI > Skills, choose the User tab, and click Create Skill.
Note the directory Zed says it will write the skill to. That is the global skills root Zed is actually scanning.
Rerun the installer with that exact path:
~/.agents/autodev/scripts/install-zed.sh --skills-root /exact/path/from/zed --copy --force
& "$env:USERPROFILE\.agents\autodev\scripts\install-zed.ps1" -SkillsRoot "C:\exact\path\from\zed" -Copy -Force
This usually means the installer ran under a different home directory than Zed uses, such as MSYS/Git Bash, a remote shell, or another sandboxed environment. For WSL2 with Windows-native Zed, use the WSL-aware Bash installer or the explicit /mnt/c/Users/<WindowsUser>/.agents/skills command above.
npx claudepluginhub gocodealone/autonomous-dev-kit --plugin autodevCore skills library for Claude Code: TDD, debugging, collaboration patterns, and proven techniques
Superpowers Plus core skills library for Claude Code: planning, execution routing, TDD, debugging, and collaboration workflows
Harness-native ECC plugin for engineering teams - 67 agents, 278 skills, 94 legacy command shims, reusable hooks, rules, MCP conventions, and operator workflows for Claude Code plus adjacent agent harnesses
Consult multiple AI coding agents (Gemini, OpenAI, Grok, Perplexity, plus codex, antigravity, and grok CLIs when installed) to get diverse perspectives on coding problems
Access thousands of AI prompts and skills directly in your AI coding assistant. Search prompts, discover skills, save your own, and improve prompts with AI.
Matt Pocock's agent skills for real engineering — grilling, spec/ticket flows, TDD, code review, domain modelling and more. Plug-and-play, not vibe coding.