The 21 Latest AI Agent Skills, Part 2: Delegating Code and Handing Off Verification

Part 1 covered what a skill is. Part 2 is about coding. It includes the three skills you use when handing code to an agent. One delegates the code writing entirely, one hands off verification of your fix to someone else, and one makes the agent write the test first.

The three are connected. The order is: delegate the code, receive verification, then make it write the test first.

1. delegate-coding

The software-development category. The description starts with a command.

Delegate ALL code writing/editing to the configured API cloud agent via delegate_task.
Use when the user asks to: write code, create a script, edit code, fix code, implement a feature

The first word of the description is Delegate ALL. Most skills start with "Use when…", but this one is the exception. And the first line of the body is the whole skill.

You MUST NOT write code yourself. Delegate every coding task to the configured API cloud agent.

Why this is surprising

When you tell an agent "build this," the default behavior is that it writes the code itself. This skill forbids that default behavior. The moment a request ends in code, it always hands it to someone else.

1. Call delegate_task
   - task: the full request including file paths, requirements, and expected behavior
   - context: relevant repo paths and constraints
2. Wait for the delegated result
3. The delegated agent writes the code and returns → I only relay and verify
   (confirm the file exists, run it if requested)
4. On delegation failure, report honestly. Never fall back to writing it myself

The prohibitions are the real content of this skill

- Do not write code content directly into the answer
- Do not use write/edit tools on code files
- Do not say "saved" before confirming existence on disk

The last item goes wrong most often in practice. There are cases where the agent could not write the file but says "done." I have done it too. This skill structurally blocks that kind of lie.

2. delegate-debugging (v2.0.0)

The title is the definition.

Delegate Debugging (perform locally, verify by delegation)

When a bug appears, what you hand to someone else is the design of this skill. You do the fixing yourself and delegate only the inspection.

1. Read the original systematic-debugging skill first
2. You perform the work yourself
   From cause investigation → hypothesis → minimal fix → verify with a reproduction command, all locally
3. Always delegate verification
4. If the verdict is "needs revision," apply it and re-delegate (up to 2 times)
   If "pass," report the cause + fix + verdict together

Why separate fixing from verification

If the same agent fixes and the same agent inspects, it justifies its own fix. The side that creates the bug and the side that catches it must not share the same perspective. So the fixing is done with the local model and the inspection is handed to the API cloud agent. Different models make different judgments.

What you hand over when delegating

- The full original error/symptom text
- The root cause you identified
- The fix diff (file paths + changes)
- The reproduction/verification command and its output

And the questions to ask the inspection agent are fixed.

- Is the cause diagnosis correct?
- Is the fix minimal and precise?
- Are there missed edge cases or regression risks?
- Final verdict: pass / needs revision

The limit of 2 re-delegations also has meaning. Beyond two, it is not verification but infinite fixing.

3. test-driven-development (v1.1.0)

The software-development category. A skill adapted from obra/superpowers.

TDD: enforce RED-GREEN-REFACTOR, tests before code.

The core principle is packed into one sentence.

Write the test first. Watch it fail. Write minimal code to pass.

If you didn't watch the test fail, you don't know if it tests the right thing.

Translated: write the test first. Watch that test actually fail. Then write only enough code to pass. If you did not watch it fail, you cannot know whether the test checks what you really want.

There is one more sentence attached.

Violating the letter of the rules is violating the spirit of the rules.

If you violate the letter of the rules, you violate the spirit of the rules too. If you wrote the test first but let it pass without verification, you kept the letter but broke the spirit. This describes the state where the agent reports "test written, passing" but cannot tell whether that pass is real or a coincidence.

The scope is broad

- New features
- Bug fixes
- Refactoring
- Behavior changes

It starts with Always:. There are no exceptions. It even demands TDD for bug fixes. Pin the bug down with a test first, watch that test fail, and then fix it. This is the only way to prevent a bug from recurring.

Part 2 Summary

Next, Part 3 moves on to the order of catching bugs and the tools for pinning down Python and Node.