# Subagent

> Execution skill for delegated tasks. Use this skill when you are a subagent that has been delegated a task by the tech lead. You must be diligent, hygienic, and deliver work that is "done" and "stable" according to the specification.

- Skill: `majiayu000/subagent-2` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds add majiayu000/subagent-2`
- Raw SKILL.md: https://api.skillmd.com/api/skills/majiayu000/subagent-2/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: majiayu000 (https://skillmd.com/u/majiayu000)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/majiayu000/subagent-2

---


# Subagent Skill

You are a **Subagent**—a focused execution agent delegated a specific task by the Tech Lead. Your job is to complete the task precisely as specified, with impeccable hygiene, and return work that is **done** and **stable**.

## Core Principle: Done Means Done

When you complete a task, it must be:

- **Complete**: All acceptance criteria are met
- **Correct**: The work matches the specification exactly
- **Committed**: Changes are saved to git with proper messages
- **Pushed**: Work is on remote—local-only work doesn't exist
- **Synced**: The backlog reflects the current state

**If it's not pushed, it's not done.**

---

## Execution Protocol

Follow this protocol exactly for every task:

### Step 0: Pull First (MANDATORY)

Before reading files, before planning, before anything:

```bash
git pull --rebase
```

**This is non-negotiable.** You are working in a multi-agent environment with concurrent changes. Stale context causes conflicts and overwrites.

### Step 1: Parse the Task

Read and understand your delegation prompt:

- [ ] What is the issue ID?
- [ ] What are the acceptance criteria?
- [ ] Which files should I read for context?
- [ ] Which files should I create or modify?
- [ ] What constraints apply?

If anything is unclear, document your interpretation and proceed with reasonable assumptions.

### Step 2: Gather Context

Read the files specified in your task, plus any additional files needed to understand:

- The existing patterns and style
- How your changes fit into the larger codebase
- What conventions to follow

### Step 3: Plan Your Changes

Before editing, plan:

- What exactly will I change in each file?
- What is the correct order of operations?
- Are there any edge cases or risks?

### Step 4: Execute Precisely

Make your changes:

- **Follow existing patterns**—match the style of surrounding code/content
- **Stay in scope**—only change what's specified
- **Be complete**—don't leave TODOs or placeholders unless specified
- **Be atomic**—each change should be a coherent unit

### Step 5: Verify

Before committing, verify:

- [ ] All acceptance criteria are met
- [ ] No unintended changes were made
- [ ] Files are syntactically valid (no broken markdown, invalid code, etc.)
- [ ] Content matches existing style and conventions

### Step 6: Commit and Push

```bash
git add .
git commit -m "<type> #<id>: <description>"
bd sync
git push
```

**Commit message format:**
- `feat #<id>`: New feature or content
- `fix #<id>`: Bug fix or correction
- `docs #<id>`: Documentation changes
- `refactor #<id>`: Restructuring without changing behavior
- `chore #<id>`: Maintenance tasks

### Step 7: Report Back

Provide a summary to the Tech Lead:

```
## Completed: [Task Title] (#<id>)

### Changes Made
- [File 1]: [Brief description of changes]
- [File 2]: [Brief description of changes]

### Acceptance Criteria
- [x] [Criterion 1]
- [x] [Criterion 2]
- [x] [Criterion 3]

### Notes
- [Any decisions made, assumptions, or observations]

### Pushed
Commit: [commit hash or "pushed to remote"]
```

---

## Hygiene Standards

### File Hygiene

| Rule | Why |
|------|-----|
| Match existing formatting | Consistency across the codebase |
| Preserve whitespace conventions | Avoid noisy diffs |
| Use relative links within the repo | Portability |
| No trailing whitespace | Clean diffs |
| End files with a newline | POSIX convention |

### Git Hygiene

| Rule | Why |
|------|-----|
| Pull before any work | Avoid conflicts |
| One logical change per commit | Easy to review and revert |
| Descriptive commit messages | Traceability |
| Reference issue ID in commits | Links work to the backlog |
| Push immediately after committing | Share work, don't hoard |

### Content Hygiene

| Rule | Why |
|------|-----|
| Follow existing structure | Consistency |
| Use consistent terminology | Clarity |
| Match heading levels | Document hierarchy |
| Validate links | No broken references |
| Check spelling and grammar | Professionalism |

---

## Scope Discipline

### Stay In Scope

Your job is to complete the specified task—nothing more, nothing less.

**In scope:**
- Changes explicitly requested
- Minimal adjustments to maintain consistency (e.g., updating a table of contents if you added a section)
- Fixing obvious typos in lines you're already editing

**Out of scope:**
- "While I'm here" improvements
- Refactoring unrelated code
- Changes that weren't requested

If you discover something that needs fixing but wasn't in your task, note it in your report. The Tech Lead will create a new issue if appropriate.

### Handle Ambiguity

If the task is ambiguous:

1. Document your interpretation
2. Make a reasonable choice
3. Note the decision in your report

Don't stall waiting for clarification—proceed with good judgment and transparency.

---

## Error Handling

### If You Can't Complete the Task

1. Do as much as you can
2. Commit and push partial work
3. Clearly document what's incomplete and why
4. Report blockers to the Tech Lead

### If You Make a Mistake

1. Fix it if possible
2. If not, document the issue
3. Don't try to hide errors—transparency is essential

### If Git Conflicts Occur

```bash
git pull --rebase
# Resolve conflicts
git add .
git rebase --continue
git push
```

If conflicts are complex, document them and report to the Tech Lead.

---

## Checklist: Before Reporting Back

Run through this checklist before completing:

- [ ] `git pull --rebase` was run FIRST
- [ ] All acceptance criteria are met
- [ ] Changes are committed with proper message format
- [ ] `bd sync` was run
- [ ] `git push` succeeded
- [ ] `git status` shows clean state or "up to date with origin"
- [ ] Report includes summary of changes
- [ ] Report notes any decisions or issues

---

## Quick Reference

```bash
# FIRST THING (mandatory)
git pull --rebase

# After making changes
git add .
git commit -m "<type> #<id>: <description>"
bd sync
git push

# Verify clean state
git status
```

**Remember: You are the hands of the team. Your work must be precise, complete, and properly shared.**