AI Software Development Skills: Teaching Your Agent How to Build
After configuration comes process: four structured skill sets that teach agentic AI how to run a software project, and how to choose the one that fits you.
Last time I argued that configuration is the other half of the prompt. Write a good SOUL.md or CLAUDE.md, fill it with verifiable rules instead of wishes, and your agent starts every session knowing who it is and where the boundaries are. That post ended with skills, the third layer, and this is that conversation.
Once your agent knows who it is, the question becomes how it works. Ask a well-configured agent to build something and it will, but the process is whatever the model improvises that day: plan in its head, write code, add tests if it remembers, close with a summary that says nothing. For small chores that is fine. For real software, the gap between an agent that produces working code and one that produces plausible code is the process it follows.
For anyone joining mid-series: a skill is a reusable procedure saved as files, loaded when the task matches. Think of standard operating procedures, written for software instead of a flight deck. A skill set is the whole binder plus the philosophy behind it. Over the last year four structured skill sets have earned real traction, and they disagree about how much process is right. That disagreement is exactly why they are worth comparing.
Superpowers: the whole lifecycle, enforced
Superpowers is the most complete of the four. Jesse Vincent calls it “a complete software development methodology for your coding agents, built on top of a set of composable skills.” Its agent checks for relevant skills before any task; workflows are mandatory, not suggestions.
The flow is a full development lifecycle. Brainstorming draws out what you actually want before anything gets built, producing a design document for anything substantial. A git worktree gives the project an isolated branch and clean test baseline. A written plan breaks the work into small tasks with exact file paths and verification steps. Implementation runs as subagent-driven development, a fresh subagent per task reviewed after each, or inline with one review of the branch at the end. Test-driven development is load-bearing throughout: red, green, refactor, and any code written before its test gets deleted. Code review sorts findings by severity, critical issues block progress, and a finishing skill walks you through merge, PR, or discard.
It also ships a native Hermes Agent plugin, which is how my own agent runs: when I ask it to build something, the first move is a brainstorming skill making me say what I want before a line of code exists.
Who it fits: developers who would rather fix the process than the symptoms. If you want the same disciplined routine on every project, and can let the ceremony run automatically, this is the most complete answer available. Its weakness is the same feature: if you don’t want to be interviewed about your requirements, the honesty can feel like friction.
Agent Skills: production-grade and familiar
Addy Osmani’s Agent Skills take the opposite route: no invented methodology, just the workflow a disciplined engineering team already runs. The README calls the pack “production-grade engineering skills for AI coding agents,” built from practices senior engineers apply across every phase of development.
The flow maps onto the lifecycle you already know: define, with a spec-driven skill writing a PRD before any code; plan; build; verify; review, with a five-axis code review and severity labels like critical, required, optional, and nit; ship, with CI/CD and rollout checklists. Nine slash commands wrap the phases, so /review and /ship do what they say. Specialized personas set the bar: a code-reviewer held to “would a staff engineer approve this?” and a test-engineer running the prove-it pattern. Security and accessibility quality gates are enforced rather than hoped for.
The point is predictability. Nothing here surprises a developer from a well-run team, because it is the same sequence you already know. The skills install into Claude Code, Cursor, Codex, and Copilot, so a team can standardize one process across tools. If you want your agent to behave like a careful colleague rather than an exotic new species, this is the pack to install.
Who it fits: teams that already have a house style and want the agent to follow it, and developers who want a process they can explain to their boss in one sentence.
Matt Pocock Skills: think first, then build
Matt Pocock’s skills start from an interesting premise: the plan is where software dies most often, so the process front-loads thinking. The site organizes twenty-seven skills by when you reach for them, and the main flow is an idea-to-ship spine: grill, specify, ticket, implement, review, retro.
The flow begins with the sharpest tools in the pack. /grill-with-docs interviews you about a plan and records the decisions; /grill-me aligns on an idea before you commit to it. The reference layer includes grilling itself, the interview other skills run to stress-test a plan. What survives the interview becomes a written spec, split into tickets, implemented test-first, and reviewed against the spec, with a retro that suggests improvements to the environment. Around the spine sit skills for shaping open questions, diagnosing bugs, triage, and handoffs.
If you install nothing else, start here. The grilling skills change how you arrive at a plan even when the rest of the flow does not fit. Being forced to answer pointed questions about what you are building before asking an agent to build it is the cheapest insurance policy in this space.
Who it fits: developers who make better decisions under questioning, and anyone who has ever approved a vague plan and regretted it. The flow asks for real time investment up front, and repays it by not building the wrong thing.
pstack: the code is the spec
Pstack is the anti-ceremony entry, and it comes from inside Cursor. The README is blunt: “the best spec is code,” and planning is something the author does not believe in. Where other sets front-load structure, pstack front-loads evidence.
The default flow runs through poteto-mode, which splits work by model strength. Investigations are read-only questions answered with evidence. Bug fixes start from a reproduction, trace the root cause, and fix it with runtime evidence that the defect is gone. Principles encoded as one-line skills keep the work honest: fix root causes, prove it works, test behavior rather than implementation, never block on the human. For teams drowning in a backlog, a companion automation triages bug reports from Slack, reproduces confirmed bugs with real UI evidence, and opens draft-only pull requests for review.
That makes it a natural fit for bug hunting and the most Cursor-native option here. It’s also the most explicit about making the process yours: one skill mines your session transcripts and drafts a personal mode from how you actually work, an idea worth stealing no matter which set you adopt.
Who it fits: developers who trust the code over the plan, work best with minimal ceremony, and would rather review a fix than approve a design document. If you want your agent to move fast and prove it, this is your pack.
Choosing, reading, and writing your own
Set the four side by side and you’re really choosing a philosophy: enforce the whole lifecycle, follow the familiar one, interview your way to a good plan, or skip straight to code and evidence. They all work, and they all fail when applied to someone they do not fit. Start with the one that feels like the developer you already are, not the one you think you should be.
All four are MIT licensed and all four are plain text. That’s worth saying twice: the product you are installing is a folder of markdown files. Simply downloading and reading them is one of the better ways to learn this craft: each file is a working procedure written by a senior engineer who has debugged the failure modes it prevents. Spending an afternoon reading systematic-debugging or the five-axis review checklist teaches more about structured engineering than most tutorial content.
None of these sets is sacred. Trim the skills you will never use, reorder the flow, merge philosophies, or write new skills from scratch. My own agent maintains a skill for publishing to this site, captured after the procedure worked once, and it rarely needs to be re-derived. That is the real endgame: not choosing a vendor, but building the binder that fits your projects, your team, and your taste.
Configuration says who the agent is. Skills say how it works. Pick a process on purpose, watch what the agent actually does, and adjust. The agent that follows a process you chose deliberately, rather than one the model improvised, is the one worth trusting with compounding work.