Hire an AI coding specialist

Everything it can hand back

Your task sets the actual outputs. The specialist picks the methods that cover them.

• A spec with the problem, user stories and the decisions made
• Small tickets in build order, each saying what blocks it
• The feature built on one branch and reviewed
• A list of new behaviours with no test, and the tests to add
• A pull request with a short summary and proof

How it does the job well

• Write a short spec with acceptance checks before code. Confirm it when the request is ambiguous.
• Read the surrounding code and tests first, then follow the project's existing patterns and libraries.
• Work in small, reviewable steps. Each step should build and pass its tests.
• Add or update tests for the behaviour you change, including one edge case.
• Measure performance claims before and after on the same machine and data.
• Read the existing code, its conventions and its tests before changing anything. Match the project's patterns.
• Make the smallest change that fully solves the request. Keep unrelated refactors out.

Mistakes it avoids

• Adding a new dependency when the project already has one that does the job.
• Leaving debug code, secrets or commented-out blocks in the change.
• Marking work done when tests were not run.
• Claiming code works without running it or its tests.
• Inventing APIs, package versions or settings instead of checking the installed ones.
• Changing behaviour outside the request, such as reformatting whole files or renaming public interfaces.

What a good result looks like

An example, not your task: You have a feature in your head and no written spec yet.

• Spec. The problem, the solution, user stories, the decisions made and how the feature will be tested.
• Tickets. Thin tickets in build order, each saying what blocks it and what it delivers.
• Build. The feature on one branch, what each ticket changed and the fixes from the review.
• Missing tests. Each new behaviour marked covered or not covered, plus proposed tests with the riskiest first.
• Pull request. A short summary, before and after proof from your tests, and how hard the change is to undo.
• HAND-BACK SUMMARY. Each step's file, any step not run and why, and every MISSING line in one list.

How the work is checked

• The diff contains only changes the task needs.
• Build, tests and linters pass, with commands and output shown.
• The pull request description states what changed, why, how it was tested and what is left.
• Each step passed its own checks, or the run stopped at the step that failed and says why.
• States which checks passed, failed or could not run, and names missing inputs.

These checks have not been run against a model yet. Your AI uses them to check its own work.

A second opinion

Before it hands back, your AI reviews the draft the way Linus Torvalds would. This is a way of reviewing the work. It does not mean they wrote or endorse it.

Capabilities

• Write the spec. Turns your idea into a spec with the problem, user stories, what to build and how it will be tested, then saves it as a file. It posts it to your tracker only if you say yes.
• Split the spec into tickets. Cuts the spec into thin slices that each work from end to end, with the tickets that must come first marked.
• Build the tickets. Builds each ticket test first on its own branch, merges them together and runs a review on the whole change.
• Find the missing tests. Lists each new behaviour in the change and marks it covered or not covered, then proposes tests for the gaps.
• Add the tests (your turn). You write or approve the proposed tests and run the suite, so the next step can show real proof.
• Write the pull request. Sums up the change in a small picture, shows before and after proof, and says how hard it is to undo.

How the role works

1. Checks your task, context and available tools.
2. Picks the methods needed and prepares a work plan.
3. Carries out supported tasks, with each method's limits and review gates.
4. Checks the real deliverables and corrects supported faults.
5. Hands back files, evidence and unresolved gaps.

Your specialist's working setup

Download the base specialist without a task form or account. README.md and SETUP.md explain how to use the folder. SOUL.md defines its scope. INTAKE.md asks missing questions inside your AI. PLAYBOOK.md, SKILLS.md, BEST_PRACTICES.md, CHECKS.md and HANDOFF.md guide the work and its checked deliverables.

Complete associated skills, supporting files and licences are included. Choose only the methods needed for the actual task. Keep context, working files and accepted feedback in your AI project.

Use this specialist through MCP or the API

Call prepare_specialist with role_id coding-specialist only. No task is required to load it. Your AI asks what job you need done, what you want back and which relevant context it can use.

For task-led hiring, call find_specialist, explain the suggested specialists and let the user accept or change the team.

Complete ZIP: Download base specialist. API: GET /api/v1/specialists/coding-specialist/pack. The host AI supplies its own model, tools and execution; a pack does not connect accounts or run a task.

Inputs and helpful context

The specialist starts from the task brief. Only active methods require their inputs.

For the primary method, when used

• A feature idea, in a few sentences, and who it is for
• Access to your project code
• Your issue tracker, if you use one (the spec and tickets go there only after you say yes)
• Your written coding standards (optional)

Tools and access

• Project files and a terminal
• A browser for interface checks
• Claude, ChatGPT or Gemini: A pasted brief and profile is enough for a plan and code sketches.
• Claude Code: It can read your repo, so components and state fit what you already have.
• Claude, ChatGPT or Gemini: A chat is enough for the proposal. A tool that reads your project files can check the plan against your real code.
• Claude, ChatGPT or Gemini with file upload: It can read a saved diff or several changed files together, and keep the link between them.

Functions and deliverables

• Feature specification and code builder: Share a feature idea, repo and constraints. Get a spec, ordered tasks, code changes, test-gap findings and a pull-request draft.
  • A spec with the problem, user stories and the decisions made
  • Small tickets in build order, each saying what blocks it
  • The feature built on one branch and reviewed
  • A list of new behaviours with no test, and the tests to add
  • A pull request with a short summary and proof
• Screenshot to interface builder: Turn a screenshot into a working screen. Give it your mockup and get matching UI built from your own parts, checked side by side.
  • Code for the screen using your own parts
  • A side-by-side check against the image
  • A list of differences fixed
  • Placeholders where assets are not yours to copy
  Source: sickn33.
• Frontend developer: Plan a React, Vue, Angular or Svelte front end. Get the component list, accessibility and speed plan, and tests to run before launch.
  • A component list with props, state and data flow
  • A mobile-first layout plan
  • An accessibility plan: labels, focus and keyboard use
  • A speed plan: code splitting, images and caching
  • Code sketches for the main components, marked as drafts you have not run
  • A list of tests and checks to run
  • Open questions
  Source: Michael Sitarzewski and Agency Agents contributors.
• Software architect: Choose how to structure your software, with at least two options, their trade-offs, a recommended design and a written decision record.
  • A short problem statement with your limits written back to you
  • A map of the main business areas and where the system splits
  • At least two options, each with what it gives and what it costs
  • A recommended design and the reasons for it
  • A decision record with context, decision and consequences
  • A growth path, so the system can change without a rewrite
  Source: Michael Sitarzewski and Agency Agents contributors.
• Code reviewer agent: Paste a code change and get a review of bugs, security, tests and clarity. Each point has the reason and a fix, ranked blocker, suggestion or nit.
  • A summary with the main concerns and what is good
  • Blockers, each with where it is, why it matters and a fix to try
  • Suggestions and nits, ranked
  • A list of missing tests for the paths that matter
  • Questions where the intent is unclear, and next steps
  Source: Michael Sitarzewski and Agency Agents contributors.
• Web accessibility checker: Check a web page or code for WCAG 2.2 accessibility problems. Get a ranked list with where each one is, and fixes if you ask.
  • A ranked list of WCAG 2.2 problems
  • The place in the page or code for each
  • Fixes applied and re-checked, if you asked
  • A note on what automated checks cannot cover
  Source: sickn33.
• Code performance investigator: Find the slow code path and measure it. Make a focused fix and write a pull request with before-and-after timings.
  • The slow moment written in one line, with the stages ranked by what they cost
  • A list of ideas the numbers rule out, so you skip them
  • The biggest bottleneck fixed in code, measured before and after
  • A pull request that shows the timings
• Feature requirements writer: Turn feature plans and code context into a spec that sets out what to build and test.
  • A spec with problem, solution and user stories
  • Implementation decisions
  • A testing plan with chosen test points
  • The spec posted to your tracker with a ready label
  Source: Matt Pocock.
• Plan-to-ticket writer: Share a plan and tracker. Get small, linked tickets to review before they are posted.
  • A numbered list of small tickets
  • Blockers listed for each ticket
  • A review round with you before posting
  • Tickets posted to your tracker in order
  Source: Matt Pocock.
• Software developer from specifications: Give it a spec and tickets. Get the work built in code, tested and reviewed.
  • One integration branch with the full spec built
  • Tests for each ticket
  • Tickets closed in your tracker
  • A code review of the result
  • A draft pull request (optional)
  Source: Matt Pocock.
• Code change test coverage reviewer: Find what a code change does that no test checks. Give it your diff and tests. Get each behaviour marked covered or not, plus test cases for gaps.
  • A list of new behaviours
  • A covered, not covered or unknown label for each
  • Evidence for each label
  • Proposed test cases for the gaps
  Source: Pro Skill Packs.
• Pull request writer: Turn your code changes into a pull request description with a picture, proof it works, and a merge risk note that reviewers can scan fast.
  • Pull request body in a set template
  • A diagram, tree or code sketch of the change
  • Before and after evidence section
  • Merge risk rating
  Source: Matt Pocock.
• AI project context organiser: Share your project and next task. Get a short rules file, a focused file list and a clear handoff for later sessions.
  • A ready rules file for your project
  • A list of which files to load for each task
  • Rules for when to reset or trim the session
  • A checklist for spotting drifting answers
  Source: Addy Osmani.
• Linus Torvalds: Review a code change using Linus Torvalds’s recorded approach. Ask what works, what breaks for existing users and who owns the fix.
  • Your problem worked on the way Linus Torvalds would: their questions, their method, their push-back
  • The answer or the work, in Linus Torvalds's voice, using their ideas by name
  • Anything that goes beyond their public record, marked
  • One suggested next step

Tasks you can use it for

• You have a feature in your head and no written spec yet.
• Past AI builds came back too big to review.
• You want tests and a pull request that a teammate can read in ten minutes.

Limits to check before starting

• You want a one-line change or a small fix: ask your AI for the change directly.
• You have no project code to build in: write the spec alone, or ask a developer to set up the project first.
• You only want to review code that already exists: ask your AI to review the pull request, or ask a teammate.

Best way to use this role

Give it one clear outcome, the actual files and a definition of done. Keep the work in one AI project so it can reuse checked context and earlier files.

• Download the handoff pack. It holds HANDOFF.md and the 5 skill files in the order they run: Spec writer, Ticket planner, Spec builder, Test gap finder and Pull request writer.
• Open your project in Claude Code, give it the folder and say "Follow HANDOFF.md".
• Describe the feature, then answer its questions about the tests and the ticket sizes.
• After the missing-test step, add the tests it proposes and run your suite before you go on.
• Read the pull request text and fix anything that does not match what you wanted.

Read it as data

Read the complete role setup as JSON. Connect your AI to the AI Blocks MCP library and read aiblocks://roles/coding-specialist for its role instructions and pinned sources.

This is a prepared AI role. No task has run. Your AI carries out authorized work using its available tools and reports the actual deliverables and checks.