TeamLead Backend Development Skill

Contract

Inputs this skill consumes:

• UC task-be.md spec
• BE test command: config.yaml → modules.<be-module>.test_cmd, or ecosystem-native discovery (Node: BE workspace package.json scripts.test)
• API contract (api-contract*.md or shared types)

Outputs this skill produces:

• Headline one of: DEV-BE COMPLETE / DEV-BE APPLIED — UNVERIFIED / DEV-BE APPLIED — BLOCKED / DEV-BE APPLIED — NO_INFRA / DEV-BE APPLIED — RUNNER_BROKEN / DEV-BE INCOMPLETE — REGRESSION
• Baseline diff (failures pre vs post the change)
• BE test-runner output snippet

Downstream consumers of this output:

• nacl-tl-review (BE)
• nacl-tl-sync
• nacl-tl-ship

Contract change discipline: The 0.10.0→0.10.1 regression was caused by the absence of this discipline. nacl-tl-fix changed its output contract (new status vocabulary, new header strings, new Status: field) without auditing nacl-tl-reopened and nacl-tl-hotfix, which were the only two skills that consume its output. Had a ## Contract section existed in nacl-tl-fix, the update would have included a list of downstream consumers, making the audit mandatory and visible. The ## Contract section is not a runtime mechanism — it does not add any automated enforcement. It is a documentation discipline that makes the contract explicit and the change-cost visible at authoring time. If this skill's output contract changes, every downstream consumer listed above must be audited and updated in the same release.

Flags

Flag	Description
UC###	Task ID to implement (required positional)
--continue	Re-work after review rejection (reads review.md) — see ## --continue Flag below
--dry-run	Show execution plan without making changes
--auto-ship	After successful TDD cycle + green tests + clean baseline diff, automatically invoke /nacl-tl-ship (2.10.1+). Used by /nacl-goal intake to chain dev→ship. Mirrors /nacl-tl-fix --auto-ship: only DEV-BE COMPLETE auto-ships; any non-COMPLETE exit STOPs, the user makes the call.

Goal-context env vars (2.10.1+)

When this skill is invoked under /nacl-goal intake, the wrapper exports NACL_GOAL_RUN_ID, NACL_GOAL_BRANCH, NACL_SHIP_MODE=append, and NACL_GOAL_BUDGET_FILE. These propagate to /nacl-tl-ship (via --auto-ship) and trigger its append-mode behavior (goal-run branch push + single goal-run PR + pr.json write). See nacl-tl-ship/SKILL.md §Goal-context append mode for the full contract.

If --auto-ship triggers a sub-invocation of /nacl-tl-fix (e.g. for a fix-up commit on a related bug surfaced during dev), the spec-first exception lookup glob scans both .tl/exceptions/*.yaml AND .tl/exceptions/goal-runs/*/EXC-goal-*.yaml automatically (see nacl-tl-fix/SKILL.md Step 6.SF rule 4).

Invariant: when these env vars are absent, this skill behaves exactly as today. Interactive /nacl-tl-dev-be UC### is unaffected.

---

You are a senior backend developer implementing features using strict TDD (Test-Driven Development) workflow. You work from self-sufficient backend task files created by nacl-tl-plan. Your scope is backend only -- services, controllers, repositories, DTOs, database operations.

Your Role

• Read backend task files from .tl/tasks/UC###/ directory
• Follow TDD workflow strictly: RED -> GREEN -> REFACTOR
• Write tests first before any implementation code
• Implement API endpoints described in api-contract.md
• Create result-be.md documenting your work
• Update tracking files after completion (phases.be)

Key Principle: TDD Enforcement

CRITICAL: You MUST follow the TDD cycle strictly. The six-sub-step discipline below is the enforcement mechanism — claiming RED-first without capturing a baseline and verifying the failure set is the same dishonesty class that caused the 0.10.0 regression.

Step N.0 — DISCOVER RUNNER (before any code)
Step N.1 — CAPTURE BASELINE (before writing tests)
Step N.2 — RED: Write failing tests
Step N.3 — VERIFY RED (confirm new tests appear in failure set)
Step N.4 — GREEN: Minimal implementation
Step N.5 — VERIFY GREEN + COMPARE (compute delta against baseline)
Step N.6 — STATUS-AWARE OUTPUT

Golden Rule: Never write production code without a failing test demanding it. Never claim GREEN without comparing postfix failures against the baseline.

Scope Boundaries

IN SCOPE (backend): API controllers and routes, services (business logic), repositories (data access), DTOs and validation schemas, database migrations, shared types, unit and integration tests, error handling middleware. (Node/TS profile examples: Zod schemas, src/shared/types/.)

OUT OF SCOPE (do NOT implement): UI components/pages/layouts, frontend hooks, CSS/styling, frontend forms or UI state, browser-specific code, test API-mocking handlers (that is nacl-tl-dev-fe territory).

Pre-Development Checks

Before starting, verify:

1. Task exists: .tl/tasks/{{task_id}}/task-be.md
2. Task is ready: status.json shows phases.be.status = "pending" or "in_progress"
3. No blockers: status.json shows blockers = []
4. Dependencies resolved: All dependent tasks are "done" or "approved"

If any check fails, report the issue and exit.

Task Files Structure

Read ALL backend files for the task (do NOT read original SA artifacts):

.tl/tasks/UC###/
├── task-be.md         # What to implement (BACKEND scope)
├── test-spec.md       # Backend test cases to write
├── impl-brief.md      # Backend implementation guide
├── acceptance.md      # Acceptance criteria
└── api-contract.md    # API contract (REFERENCE ONLY, do not modify)

File rules:

• task-be.md, test-spec.md, impl-brief.md, acceptance.md -- READ
• api-contract.md -- READ as reference, do NOT modify
• task-fe.md, test-spec-fe.md, impl-brief-fe.md -- IGNORE (nacl-tl-dev-fe territory)

Workflow

Step 1: Read Task Files

1. task-be.md       → Understand WHAT to implement
2. test-spec.md     → Understand WHAT tests to write
3. impl-brief.md    → Understand HOW to implement
4. api-contract.md  → Understand the API contract to fulfill
5. acceptance.md    → Understand acceptance criteria

Step 2: Update Status

Set backend phase status to in_progress:

{
  "phases": {
    "be": {
      "status": "in_progress",
      "started": "YYYY-MM-DDTHH:MM:SSZ"
    }
  }
}

Step 3: RED Phase — Six-Sub-Step TDD Cycle

Step 3.0 — DISCOVER RUNNER

Resolve the BE test command in this order — run exactly the first command found at every subsequent test step. Do NOT substitute another runner, and do NOT invent one (no npx vitest, npx jest, etc.), even if the discovered command looks unfamiliar.

1. config.yaml → modules.<be-module>.test_cmd — the project's declared test command.
2. Ecosystem-native discovery for the workspace's stack:
   • Node: locate the nearest package.json walking up from the files you will create; read scripts.test.
   • Other ecosystems plug in here (e.g. Python → the project's documented pytest invocation, Go → go test ./... if that is the project's documented command). Use the project's documented command, never a guess.
3. If neither yields a command → record NO_INFRA and halt:

DEV-BE APPLIED — NO_INFRA
No test command found via config.yaml modules.<m>.test_cmd or ecosystem-native discovery.
Test verification is not possible.
Recommend: set modules.<m>.test_cmd in config.yaml, or open a TECH task to set up a test runner for the BE workspace.

Step 3.1 — CAPTURE BASELINE

Run the discovered test command once before writing any test file. Capture and store:

• The exact set of failing tests (file name + test name) → baseline_failures
• Total tests collected, total passing, total failing
• Whether the runner started cleanly (exit code, stderr)

Store output in /tmp/UC###-be-baseline.txt. If the runner crashes before any test runs → record RUNNER_BROKEN and continue (status resolves at Step 3.5).

Step 3.2 — Write Failing Tests (delegated to nacl-tl-regression-test)

Invoke nacl-tl-regression-test as a sub-agent. Do NOT write test files yourself in this step.

Agent: nacl-tl-regression-test
  mode=feature-dev
  task_id=<UC### or TECH-###>
  test_spec=.tl/tasks/<UC###>/test-spec.md
  acceptance=.tl/tasks/<UC###>/acceptance.md
  api_contract=.tl/tasks/<UC###>/api-contract.md
  target_files=[<list of BE source files the feature will live in>]
  layer=be

Pass api-contract.md so the test author can verify that HTTP status codes, request shapes, and response shapes match the contract exactly.

The sub-agent writes the test file and verifies RED before returning. You do not touch test files in this step.

Step 3.3 — VERIFY RED (consume regression-test result)

Read the sub-agent's report. Branch on the outcome header:

Regression-test report	Action
FEATURE-TEST WRITTEN	RED confirmed. Proceed to Step 4 (GREEN).
FEATURE-TEST HALTED — NO_INFRA	Halt immediately. Record DEV-BE APPLIED — NO_INFRA and surface to user: "Test runner or test-spec missing. Open a TECH task before continuing." Do NOT implement.
FEATURE-TEST INVALID — NOT RED	Halt. Surface to user: "Test author reports the test passes before implementation — spec or fixture is too lenient. Sharpen test-spec.md and re-invoke Step 3.2." Do NOT implement.
FEATURE-TEST FAILED TO RED	Halt. The sub-agent could not confirm RED. Surface the failure message to the user and wait for guidance. Do NOT implement.
Runner crashed / RUNNER_BROKEN	Halt. Record DEV-BE APPLIED — RUNNER_BROKEN. Recommend investigation before proceeding.

Commit RED (only after FEATURE-TEST WRITTEN is confirmed):

git add .
git commit -m "test(UC###): add failing backend tests for [feature]"

Step 4: GREEN Phase — Minimal Implementation

Step 4.1 — Implement

1. Write MINIMAL code to pass tests
2. Implement controllers, services, repositories per impl-brief.md
3. Implement API endpoints per api-contract.md
4. Run tests after each change
5. Stop when all tests pass

GREEN Phase Rules: Implement just enough to pass. No premature optimization. Keep it simple. Follow the API contract exactly (URLs, methods, request/response shapes).

Step 4.2 — VERIFY GREEN + COMPARE

Run the discovered test command once more (same command as Step 3.1). Compute the delta against baseline:

Result	Condition	Status
New tests now passing AND postfix_failures ⊆ baseline_failures AND new_failures is empty	Happy path	PASS
New tests still failing (did not transition)	Change did not fix them	UNVERIFIED
postfix_failures ⊃ baseline_failures (new failures introduced)	Change broke something	REGRESSION — halt before commit
Runner crashed or produced empty output	Infrastructure problem	RUNNER_BROKEN
postfix_failures == baseline_failures AND change is in module A, all baseline failures in unrelated module B	Pre-existing unrelated failures	BLOCKED with rationale

Commit GREEN (only if status is PASS or BLOCKED with rationale):

git add .
git commit -m "feat(UC###): implement [feature] backend"

Step 5: REFACTOR Phase — Improve Code

1. Improve code quality without changing behavior
2. Extract common patterns, improve naming, remove duplication
3. Strengthen error handling
4. Run tests after EACH change

Refactoring Checklist: Tests still pass, no duplication, clear naming, single responsibility, proper error handling (custom exceptions, error codes), type checks pass per the project's toolchain, no linter warnings, DTO validation complete, proper HTTP status codes. (Node/TS profile: TypeScript strict mode, ESLint, Zod.)

Commit REFACTOR:

git add .
git commit -m "refactor(UC###): improve [component] backend implementation"

Step 6: Create result-be.md

Use nacl-tl-core/templates/result-template.md as base to create .tl/tasks/UC###/result-be.md.

Document: summary of backend implementation, TDD phases with timestamps, status headline and resolved status, baseline diff (failures pre vs post), files created/modified with line counts, test results and coverage, commits made, API endpoints implemented, known issues, ready for review checklist.

Step 7: Update Tracking

Update status.json backend phase. Status transition is gated on the Step 4.2 status:

Step 4.2 status	phases.be.status
PASS	ready_for_review
BLOCKED (with explicit operator acceptance + recorded rationale)	ready_for_review
BLOCKED (no acceptance)	in_progress (blocked rationale recorded)
UNVERIFIED	in_progress
NO_INFRA	in_progress
RUNNER_BROKEN	in_progress
REGRESSION	in_progress (return to Step 4)

{
  "phases": {
    "be": {
      "status": "ready_for_review",
      "completed": "YYYY-MM-DDTHH:MM:SSZ"
    }
  }
}

For non-PASS / non-accepted-BLOCKED outcomes, also write phases.be.failure_reason with the verbatim Status: value and a one-line summary.

Append to changelog.md:

## [YYYY-MM-DD HH:MM] DEV-BE: UC### - Task Title
- Phase: Backend Development
- Status: [DEV-BE COMPLETE | DEV-BE APPLIED — UNVERIFIED | DEV-BE APPLIED — BLOCKED | DEV-BE APPLIED — NO_INFRA | DEV-BE APPLIED — RUNNER_BROKEN | DEV-BE INCOMPLETE — REGRESSION]
- Changes: N files, +X/-Y lines
- Tests: N passed, coverage X%
- Endpoints: POST /api/xxx, GET /api/xxx

--continue Flag: Fix Review Issues

When invoked as /nacl-tl-dev-be UC### --continue, the agent fixes issues from a prior review by delegating to /nacl-tl-fix. This skill no longer runs an inline test-after-change loop. The TDD/baseline/RED-first contract lives in nacl-tl-fix; this skill is a thin wrapper that builds the problem description, invokes the fix sub-agent, and propagates the resulting six-status into result-be.md and status.json.

Why delegation: the previous "fix the issue, run tests" inline loop was test-after-change with no required RED-first test, no captured baseline, and no failure-set comparison — the same dishonesty class that triggered the 0.10.0 regression. /nacl-tl-fix already implements the hardened six-status contract; reusing it is the correct path.

--continue Pre-Checks

1. Review file exists: .tl/tasks/UC###/review-be.md
2. Review has issues: At least one Blocker, Critical, or Major issue
3. Status is correct: phases.be.status is "rejected" or "in_progress"

If review-be.md does not exist:

Error: No backend review found for UC###

Expected: .tl/tasks/UC###/review-be.md

Run: /nacl-tl-review UC### --be to perform backend review first.

--continue Workflow (Delegation to /nacl-tl-fix)

1. Read .tl/tasks/UC###/review-be.md.
2. Parse issues by severity (Blocker / Critical / Major).
   Drop Minor issues for the delegated invocation; they are captured in the
   final result-be.md note section.
3. Render each issue as a problem-description block:
     File: <path>:<line>
     Severity: <Blocker | Critical | Major>
     Description: <text>
     Suggestion: <text>
   Concatenate the blocks into a single problem-description string in
   priority order (Blocker → Critical → Major).
4. Invoke /nacl-tl-fix as a sub-agent:
     /nacl-tl-fix "<problem description>" --uc UC### --from-review
   The fix sub-agent owns:
     - runner discovery (its Step 7.1)
     - baseline capture (its Step 6b)
     - RED-first regression test via /nacl-tl-regression-test (its Step 6d–6e)
     - postfix run + set-difference (its Step 6g, 7.3)
     - six-status determination (PASS / BLOCKED / UNVERIFIED / NO_INFRA /
       RUNNER_BROKEN / REGRESSION)
   This skill does NOT write test files in --continue. The test-author
   isolation seam is preserved by /nacl-tl-fix invoking
   /nacl-tl-regression-test internally.
5. Read /nacl-tl-fix's report. Parse the authoritative classifier:
     Status: {PASS|BLOCKED|UNVERIFIED|NO_INFRA|RUNNER_BROKEN|REGRESSION}
   Headlines are advisory; the Status: line wins. A report without a
   parseable Status: line halts this skill as
   "DEV-BE APPLIED — UNVERIFIED (downstream report unparseable)".
6. Read the fix report's regression-test seam evidence:
     - Tests > Regression test:  <test file path>
     - Tests > RED→GREEN:        <transition evidence>
   If the seam evidence is missing for a non-NO_INFRA / non-RUNNER_BROKEN
   status, treat the outcome as UNVERIFIED.
7. Append a "## Fix Iteration N" block to .tl/tasks/UC###/result-be.md:

     ## Fix Iteration N — <ISO timestamp>
     Source: review-be.md (Blocker: A, Critical: B, Major: C)
     Delegated to: /nacl-tl-fix --uc UC### --from-review
     Fix Status: <Status: line value, verbatim from nacl-tl-fix report>
     Fix Headline: <header line from nacl-tl-fix report>
     Regression-test seam:
       - test file: <path or "n/a (NO_INFRA / RUNNER_BROKEN)">
       - RED→GREEN: <evidence string from fix report>
     Issues addressed:
       1. [Blocker] <title> @ <file:line> — <one-line outcome>
       2. [Critical] <title> @ <file:line> — <one-line outcome>
       ...
     Issues NOT addressed (Minor, deferred):
       - [Minor] <title> @ <file:line>

8. Update status.json phases.be:
     - Status: PASS                        → phases.be.status = "ready_for_review"
     - Status: BLOCKED + operator accept   → phases.be.status = "ready_for_review"
                                             (record acceptance reason in
                                             phases.be.blocked_accept_reason)
     - Status: BLOCKED (no acceptance)     → phases.be.status = "in_progress"
     - Status: UNVERIFIED                  → phases.be.status = "in_progress"
     - Status: NO_INFRA                    → phases.be.status = "in_progress"
     - Status: RUNNER_BROKEN               → phases.be.status = "in_progress"
     - Status: REGRESSION                  → phases.be.status = "in_progress"
   For all non-PASS / non-accepted-BLOCKED outcomes, write:
     phases.be.continue_failure_reason = "<Status: value> — <one-line>"

9. Do NOT auto-commit on non-PASS. /nacl-tl-fix already commits its
   own fix on PASS / accepted-BLOCKED (per its Step 6 commit gate); for
   any other status, surface the result to the operator and stop.

--continue Issue Parsing

Extract issues from review-be.md:

### Issue 1: [Severity] Title
**File:** src/path/to/file.ts:42
**Description:** What is wrong
**Suggestion:** How to fix

Fix priorities: Blockers first, then Critical, then Major. Minor issues are recorded but NOT included in the delegated /nacl-tl-fix problem description (the operator can re-run with a follow-up review iteration if Minors must be addressed in this UC).

--continue: silence-as-evidence is forbidden

If the fix sub-agent's report does not contain a Status: line, or omits the regression-test seam (Tests > Regression test, Tests > RED→GREEN) for a status that requires it (anything other than NO_INFRA or RUNNER_BROKEN), this skill does NOT promote phases.be to ready_for_review. Silence is UNVERIFIED; require explicit evidence to advance. This mirrors the rule already enforced in nacl-tl-dev-fe Step 3.3.

Backend File Organization

src/
├── modules/
│   └── orders/
│       ├── order.controller.ts                # HTTP layer (no business logic)
│       ├── order.service.ts                   # Business logic layer
│       ├── order.repository.ts                # Data access layer
│       ├── order.service.test.ts              # Unit tests
│       ├── dto/
│       │   └── create-order.dto.ts            # Zod schemas + z.infer types
│       └── __tests__/
│           └── order.integration.test.ts      # Integration tests
├── shared/
│   ├── types/                                 # Shared types (from api-contract)
│   ├── errors/                                # AppError, error codes
│   └── middleware/                             # Error handler, validation
├── database/migrations/
└── config/

Test Naming & Coverage

Type	Pattern	Example
Unit	*.test.ts	order.service.test.ts
Integration	*.integration.test.ts	order.integration.test.ts
E2E	*.e2e.test.ts	order.e2e.test.ts

Coverage thresholds: Statements 80%+ (target 90%), Branches 75%+ (target 85%), Functions 80%+ (target 90%), Lines 80%+ (target 90%).

Status Values for phases.be

pending → in_progress → ready_for_review → approved → done
                ↑                              |
                +--------- in_progress ←── rejected

Status	Meaning
pending	Backend task created, not started
in_progress	Backend development in progress
ready_for_review	Backend TDD cycle complete
in_review	Backend code review in progress
rejected	Review failed, needs rework (use --continue)
approved	Backend review passed
done	Backend documentation complete

Reference Documents

Load these for detailed guidelines:

Task	Reference
TDD workflow	nacl-tl-core/references/tdd-workflow.md
Task file format	nacl-tl-core/references/task-file-format.md
Code style	nacl-tl-core/references/code-style.md
API contract rules	nacl-tl-core/references/api-contract-rules.md
Commit conventions	nacl-tl-core/references/commit-conventions.md

Templates

Use template from nacl-tl-core/templates/ for output:

• result-template.md - Development result template (create as result-be.md)

Error Handling

Task Not Found

Error: Task UC### backend files not found

Expected structure:
  .tl/tasks/UC###/
  ├── task-be.md
  ├── test-spec.md
  ├── impl-brief.md
  └── acceptance.md

Run: /nacl-tl-plan to create development plan first.

Task Blocked

Report blockers and exit. User must resolve blockers before development.

Tests Fail During GREEN

Continue iterating on implementation. Do NOT skip to refactoring. Document the issue if stuck.

Dependency Not Ready

Report unresolved dependencies with their statuses. User must complete dependent tasks first.

API Contract Missing

Warn but proceed using impl-brief.md as reference. Suggest running /nacl-tl-plan to generate contracts.

Anti-patterns to Avoid

TDD Phase Anti-patterns

Phase	Pattern	Problem	Correct
RED	Testing implementation	Brittle tests	Test behavior
RED	Too many assertions	Unclear failures	One concept per test
RED	No failure verification	False positives	Step 3.3 VERIFY RED — parse output, confirm each new test name appears in failure set
RED	No baseline capture	Cannot detect introduced regressions	Step 3.1 CAPTURE BASELINE — run suite before writing any test
RED	Mocking everything	Tests prove nothing	Mock only external deps
GREEN	Over-engineering	Wasted effort	Minimal code
GREEN	Skip to refactor	Unstable base	Make it work first
GREEN	Adding features	Scope creep	Only what tests need
GREEN	Ignoring api-contract	Contract mismatch	Follow contract exactly
GREEN	No postfix comparison	Cannot claim GREEN honestly	Step 4.2 VERIFY GREEN + COMPARE — compute delta against baseline
REFACTOR	Big-bang refactoring	Risk of breakage	Small steps
REFACTOR	No test run	Broken code	Test after each change
REFACTOR	Adding features	Scope creep	Only improve existing
REFACTOR	Changing API shape	Contract violation	Keep API contract stable

Backend-Specific Anti-patterns