Skip to content
Back to skills

Implement Slice

ASecurity

This skill should be used when the user asks to "implement a feature", "add a feature", "build a feature", "create a new feature", or mentions "vertical slice", "TDD implementation", "red green", or "implement with tests". Guides strict RED/GREEN/REFACTOR implementation through vertical slices.

  • 11 stars
  • 0 votes
  • 0 copies
  • 0 views
  • Added October 3, 2026
ai-agentsgotestingrefactoringapidatabasebackend

Works with

  • cli
  • api
  • mcp

Security analysis

A100/100

Scanned October 3, 2026

npx -y skills add standardbeagle/mcp-tui --skill implement-slice --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Implement Slice?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Implement Slice
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/standardbeagle-implement-slice/badge)](https://www.skillsdirectory.com/skills/standardbeagle-implement-slice)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: implement-slice
description: This skill should be used when the user asks to "implement a feature", "add a feature", "build a feature", "create a new feature", or mentions "vertical slice", "TDD implementation", "red green", or "implement with tests". Guides strict RED/GREEN/REFACTOR implementation through vertical slices.
---
<!-- Generated by dev-standards plugin. Customize as needed. -->

# Implement Vertical Slice (TDD)

Implement a feature as a complete vertical slice using strict RED/GREEN/REFACTOR discipline. Each slice delivers working functionality through all layers — not a horizontal layer across features.

## Pre-Flight Checks

Before writing any code:

1. Confirm the feature scope and acceptance criteria with the user
2. Read `.claude/rules/architecture.md` for active patterns and constraints
3. Read `.claude/rules/tdd.md` for TDD discipline rules
4. Identify which layers this slice touches (validation, logic, data, API, UI)
5. Verify the feature is small enough for one vertical slice (if not, split first)

## Step 1 -- Write the Smoke Test (RED)

Write one end-to-end smoke test for the core user journey at HIGHEST fidelity.

### Smoke Test Rules

- Full e2e — real UI (if applicable), real backend, real database
- NO mocks, stubs, or simulations
- Test the complete user journey from entry to exit
- Run it — it MUST FAIL (RED) because the feature doesn't exist yet

```
# Example: "User can create a post"
test("user creates a post and sees it in the list"):
  navigate to /posts/new
  fill in title and body
  click submit
  assert redirected to /posts
  assert new post appears in list
```

Run with: `go test (CLI subprocess + live MCP servers: npx server-everything, test-servers/*.js)`

Commit: `RED: Smoke test for [feature]`

## Step 2 -- Identify the Thinnest Slice

Break the feature into the smallest possible behavior increments. Each increment is ONE RED/GREEN/REFACTOR cycle.

### Slice Planning

List the behaviors in implementation order (dependencies first):

```
Example for "User can create a post":
  1. Post validation rejects empty title (pure logic)
  2. Post can be persisted to database (data layer)
  3. API endpoint accepts POST /posts (API layer)
  4. UI form submits to API (presentation layer)
  5. Success redirects to post list (navigation)
```

Each behavior becomes one TDD cycle. Order matters — build from the inside out, but always as a vertical slice (not all validation first, then all data, then all API).

## Step 3 -- RED/GREEN/REFACTOR Each Behavior

For EACH behavior in the slice:

### 3a. RED — Write ONE Failing Test

Write the simplest test that describes the next behavior. Run it. Confirm RED.

- Unit test for pure logic (validation, transformation, calculation)
- Integration test for data layer (real database, no mocks)
- API test for endpoint (HTTP request/response)
- Test at the RIGHT level — don't use e2e for logic testing

Commit: `RED: Test for [behavior]`

### 3b. GREEN — Minimum Implementation

Write the MINIMUM code to make this ONE test pass. Nothing more.

- No error handling unless a RED test demands it
- No abstractions unless a RED test demands them
- No "while I'm here" additions
- If you feel the urge to write more, write a RED test for it first

Commit: `GREEN: [behavior] implemented`

### 3c. REFACTOR — Clean Up Under GREEN

All tests are GREEN. Now clean up:

- Extract duplicated code
- Rename for clarity
- Simplify structure
- Run tests after EVERY change — any RED means undo immediately

Commit: `REFACTOR: [what changed]`

### Repeat

Move to the next behavior. Continue until all behaviors are GREEN.

## Step 4 -- Verify the Smoke Test (GREEN)

The smoke test from Step 1 should now pass. If not:

1. Identify what's missing (the smoke test tells you)
2. Write a RED test for the missing behavior
3. Implement GREEN
4. Repeat until the smoke test is GREEN

Commit: `GREEN: Smoke test passes — [feature] complete`

## Step 5 -- Edge Cases and Error Paths

Add tests for edge cases and error paths. Each follows the RED/GREEN cycle:

### Edge Cases to Cover

- Empty/null/whitespace inputs
- Boundary values (0, -1, max, min)
- Duplicate operations (submit twice)
- Concurrent access (two users at once)
- Large inputs (10K characters, 10K items)

### Error Paths to Cover

- Validation failures (each field, each rule)
- Authorization failures (wrong role, expired session)
- External service failures (if applicable)
- Database constraint violations

Each edge case: RED test -> GREEN implementation -> commit.

## Step 6 -- Verify Test Distribution

Count your tests and verify distribution:

```
Target:
  Happy path: 50-60%
  Edge cases: 25-30%
  Adversarial: 10-15%
```

If distribution is off, add tests for the underrepresented tier.

## Step 7 -- Final Verification

Before considering the slice complete:

- [ ] Smoke test passes at full e2e fidelity
- [ ] Every test was seen RED before GREEN
- [ ] All tests pass (unit + integration + e2e)
- [ ] Test distribution is on target
- [ ] No TODO/FIXME markers in new code
- [ ] No debug statements
- [ ] Code follows existing codebase patterns
- [ ] No scope creep beyond acceptance criteria
- [ ] No abstractions with single implementations
- [ ] Linting passes with zero errors

## Anti-Patterns to Reject

- Writing all tests first, then all implementation (batch TDD is not TDD)
- Building all database models, then all APIs, then all UI (horizontal layers)
- Skipping RED verification ("I know the test will fail")
- Writing more than minimum GREEN ("while I'm here...")
- Refactoring while RED ("I'll fix it after this test passes")
- Mocking internal code instead of testing through it

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…