# ai-coding-assistant-task-delegation-sop

AI Coding Assistant Task Delegation SOP

Overview
AI Coding Assistant Task Delegation SOP is the operating skill for turning vague coding requests into bounded, testable work packets an AI assistant can execute safely. Solopreneurs usually fail not because models are weak, but because task boundaries are fuzzy. This SOP gives you a repeatable delegation loop that protects speed and production quality at the same time.

When to Use This Skill
Use this when AI-generated code keeps drifting from requirements, when you get large noisy diffs, when fixes break adjacent features, when review cycles feel chaotic, or when you want to ship weekly without hiring a full engineering team.

What This Skill Does
This skill converts one feature request into controlled execution units with clear file scope, acceptance checks, and rollback readiness. It helps you:
- reduce rework from ambiguous prompts
- keep changes small enough to review quickly
- enforce testing and verification before merge
- preserve context between coding sessions

How to Use
Step 1: Convert request into one shipping objective.
Write the objective as one observable user outcome, not a technical activity. Good: "User can submit onboarding form and receive confirmation email." Weak: "Refactor form code." This keeps the assistant aligned to business behavior.

Step 2: Define hard scope boundaries.
List exact files or modules the assistant may edit. Add an explicit out-of-scope list for sensitive areas (billing, auth, analytics) unless the task requires them. Ambiguous scope is the top source of low-quality AI diffs.

Step 3: Split by risk class.
Use simple risk classes before prompting:
- R0: copy, style, low-impact UI
- R1: component logic and validation
- R2: data flow, orchestration, state updates
- R3: auth, payment, security-critical behavior
Never combine R3 with broad refactors in one step. Run tiny batches at high risk.

Step 4: Write a delegation prompt contract.
Every task prompt should include:
- Business intent: why this change exists
- Scope: exact file paths allowed
- Non-goals: what must not change
- Constraints: coding standards and API contracts to preserve
- Acceptance checks: required lint, type, unit, and integration commands
- Output format: summary, changed files, and test output

Step 5: Force implementation in one increment.
Do not ask for "complete feature end-to-end" unless trivial. Ask for one increment, review result, then assign next increment. Fast feedback loops outperform one-shot generation for production reliability.

Step 6: Validate before merge.
Require this minimum evidence from the assistant:
- commands run
- pass/fail outputs
- manual test notes on critical user path
- known limitations
If evidence is missing, treat output as draft and request a corrective pass.

Step 7: Capture reusable SOP assets.
After merge, save:
- winning prompt template
- failure patterns observed
- extra acceptance checks that caught bugs
Over 4-6 cycles this becomes your private shipping system and reduces prompt variance.

Task Packet Template (Copy/Paste)

```text
Task: [single increment]
Business Outcome: [observable user result]
Files In Scope:
- src/... 
- api/... 
Files Out Of Scope:
- billing/... 
- auth/... 
Constraints:
- Keep API signatures unchanged unless requested
- No unrelated refactors
- Add/update tests for changed behavior
Acceptance Checks:
- npm run lint
- npm run typecheck
- npm run test -- [target]
Return:
- Summary of code changes
- File-by-file rationale
- Exact test output
- Any unresolved risks
```

Risk and Batch Matrix

| Risk class | Typical examples | Recommended batch size | Required validation |
|---|---|---|---|
| R0 | Copy, layout, non-critical UI polish | Multiple files | Manual visual check |
| R1 | Form logic, component behavior, local state | Small file set | Lint + type + targeted tests |
| R2 | Workflow automation, async coordination, data mutation | Very small increments | Full tests + integration path check |
| R3 | Auth, payments, access control, sensitive operations | Tiny isolated patch | Manual review + staged rollout |

Common Failure Modes and Fixes

| Failure mode | Root cause | Immediate fix |
|---|---|---|
| Giant unrelated diff | Scope not constrained | Re-issue prompt with strict file allowlist |
| Tests missing | Acceptance checks optional | Make test output mandatory return field |
| Correct code, wrong behavior | Outcome phrased as technical task | Rewrite objective as user-visible result |
| Repeated regressions | No post-merge learning loop | Save failure patterns and add new checks |

Output
The output should include:
- final objective and scope used
- diff summary by file
- acceptance command results
- manual verification notes
- next-step backlog item (if remaining work exists)

What Good Looks Like
A healthy delegation workflow has:
- 1 objective per task packet
- clear in-scope and out-of-scope file boundaries
- small reviewable diffs
- explicit validation evidence attached to each merge
- prompt and QA improvements captured for reuse

Common Mistakes
Do not use one giant prompt for mixed-risk changes.
Do not allow edits outside declared scope without approval.
Do not merge output that lacks verification evidence.
Do not skip manual critical-path checks after test pass.
Do not keep repeating failed prompt patterns without updating the SOP.

Authority and Citations Table

| Claim this page makes | Citation type | Source |
|---|---|---|
| Smaller, iterative changes reduce review and merge risk versus large batches. | Engineering best practice | Google Testing Blog: Small Changes — https://testing.googleblog.com/2017/04/where-do-our-faults-come-from.html |
| Code review quality improves when change sets are bounded and understandable. | Research summary | SmartBear / Cisco study summary — https://smartbear.com/learn/code-review/best-practices-for-peer-code-review/ |
| Prompt clarity and explicit constraints improve LLM coding reliability. | Vendor documentation | OpenAI prompting guidance — https://platform.openai.com/docs/guides/prompt-engineering |
| Automated checks (lint/test/type) are required guardrails in modern software delivery. | Platform documentation | GitHub Docs: About continuous integration — https://docs.github.com/en/actions/automating-builds-and-tests/about-continuous-integration |