Nacl Tl Dev Be

TeamLead Backend Development Skill

Contract

Inputs this skill consumes:

• UC task-be.md spec
• BE test command: config.yaml → modules..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 — NOINFRA / DEV-BE APPLIED — RUNNERBROKEN / 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..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.

1. If neither yields a command → record NO_INFRA and halt:

DEV-BE APPLIED — NO_INFRA
No test command found via config.yaml modules..test_cmd or ecosystem-native discovery.
Test verification is not possible.
Recommend: set modules..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=
  test_spec=.tl/tasks//test-spec.md
  acceptance=.tl/tasks//acceptance.md
  api_contract=.tl/tasks//api-contract.md
  target_files=[]
  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: :
     Severity: 
     Description: 
     Suggestion: 
   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 "" --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-

…

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [ITSalt](https://github.com/ITSalt)
- **Source:** [ITSalt/NaCl](https://github.com/ITSalt/NaCl)
- **License:** MIT

Install and usage instructions live in the source repository linked above.