Building a /next‑task agent skill
In my last post, I talked about using Claude Code skills to manage my product dev workflow end-to-end. The /next-task skill was the centerpiece — it pulls from an issue tracker, manages git branches, implements changes, and opens a PR. In this post, let's build a /next-task skill.
A skill is simply a Markdown file that describes a process. Once you drop it in a skills folder in your project you can invoke it as a slash command. The agent then reads the instructions and follows them.
Here's what I wanted my /next-task skill to do:
- Prioritize unfinished work first
- Select the next highest priority thing on the roadmap
- Write the code and create a PR
- Ask for feedback and iterate
- Merge and deploy when approved
Your /next-task skill can follow whatever process makes sense for you.
Prerequisites
Before creating your skill, install any tools your agent needs to follow your process. These might include MCP servers (services that let agents interact with websites and APIs that require authentication) and command line tools.
Since I use Linear and GitHub, I installed:
- Linear's MCP — gives your agent the ability to read, create, and modify issues in Linear.
- GitHub's command line tool (
gh) — for creating PRs, checking CI status, and more. (GitHub also has an official MCP server if you prefer that route.)
You might also need tools for deploying to dev servers or running other parts of your workflow. If you're not sure what to install, just ask your agent.
Start with a prompt
You don't need to write the skill by hand. Describe what you want and let your agent generate it. Here's an example prompt based on my process:
Create a `/next-task` skill for this project. When I run it, it should query Linear for the highest-priority "Todo" issue. Before picking a new task, check for blocked issues with new comments from me and PRs with unresolved review feedback — those take priority. Once it picks a task, update the issue to "In Progress", check out the right git branch, implement the changes, commit, push, and open a PR. After the PR is up, update the issue to "In Review" and show me a summary with a test checklist. If I request changes, iterate on the same branch. If I approve, squash-merge. Before writing the skill, consult the latest documentation for skils to ensure that it's in the right format.From this prompt, your agent can generate the full skill covering the workflow end-to-end.
Customize it for your needs
After your agent generates the skill, review the file and make sure it does what you want. I generally iterate on it a bit before trying it for the first time. You'll probably be surprised at how well your agent infers your process from a limited description.
To run the skill, quit your agent (or start a new chat if you're in Cursor). It will then be available as a slash command. Simply type:
/next-taskWhat a session looks like
Here's /next-task in action:
> /next-task
Checking for blocked tasks with new comments... none found.
Checking for PRs with unresolved comments... none found.
Querying Linear for Todo issues...
Found 3 issues. Selecting: APP-47 - Add user goal screen
to onboarding wizard
Switching to jlong/app-47-add-user-goal-screen-to-onboarding
[reads existing onboarding flow, implements new screen,
commits, pushes, opens PR]
✅ PR: https://github.com/acme/myapp/pull/47
Quick tests:
- Start the onboarding flow → verify the goal screen
appears after the welcome screen
- Select a goal and tap Continue → verify it advances
to the next step
- Tap Back → verify it returns to the previous screen
without losing your selection
- Skip the screen → verify onboarding still completes
Ready for review! Say "approved" to merge, or let me
know what changes you need.Two words to kick off, one word to ship. If I say "approved" it checks that CI is green before squash-merging. If I ask for changes, it iterates on the same branch and pushes again.
Iterate as you go
You can ask your agent to update your skills at any time. I regularly add things to my /next-task skill that raise the quality of my process. A few ideas:
- Run tests before pushing changes — have the skill run your test suite and only push if everything passes.
- Post a summary comment on the Linear issue — log what was implemented and link to the PR so your issue tracker stays in sync.
- Enforce commit message conventions — require Conventional Commits format, or whatever your team uses.
- Tag PRs by type — automatically add labels like
bugfix,feature, orchorebased on the issue metadata. - Deploy to a preview environment — after the PR is open, trigger a preview deploy and include the URL in the PR description.
But don't overthink it. Start with what works for you and add more later.