Skip to content
Development
Skill

/post-dev-test

Post-development test completion. Use when: checking test coverage after feature-dev, writing missing integration/e2e tests. Not for: unit test generation (use codex-test-gen), test review (use test-review). Output: test files + coverage report.

From plugin
sd0x-dev-flow
194102 skills16 agents5 hooks

Claude Code

$ npx -y skills add sd0xdev/sd0x-harness --skill post-dev-test --agent claude-code

SKILL.md

post-dev-test.SKILL.md
name: post-dev-test
description: "Post-development test completion. Use when: checking test coverage after feature-dev, writing missing integration/e2e tests. Not for: unit test generation (use codex-test-gen), test review (use test-review). Output: test files + coverage report."
allowed-tools: Read, Grep, Glob, Write, Bash

Post-Dev Test Skill

Trigger

  • Keywords: add tests, integration test, e2e test, test coverage, post dev test

When to Use

  • After completing feature development, before /precommit
  • Want to ensure new features have sufficient integration/e2e coverage
  • Unit tests exist, but higher-level tests are missing

Key Rule: Must Execute on Changes

**Even if test coverage looks complete, tests must be executed whenever there are code changes.**

| Scenario | Action | | ---------------------------- | ------------------------------------ | | Code changes exist | Must execute related integration/e2e | | Tests exist and are complete | Still execute to confirm no regression | | Tests missing or insufficient| Write then execute | | Pure doc/comment changes | Can skip |

**Reason**: Test coverage does not equal tests passing. Existing tests may fail due to code changes.

When NOT to Use

  • Only need unit tests (use `/codex-test-gen`)
  • Review existing tests (use `/codex-test-review`)
  • Still in development (complete `/feature-dev` flow first)

Workflow

┌─────────────────────────────────────────────────────────────────┐
│ Phase 1: Analyze Context                                        │
├─────────────────────────────────────────────────────────────────┤
│ 1. From conversation history: what feature was developed?       │
│ 2. Identify involved Service / Provider / Controller            │
│ 3. List core flows and API endpoints                            │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│ Phase 2: Check Existing Test Coverage                           │
├─────────────────────────────────────────────────────────────────┤
│ 1. Search test/integration/ for related tests                   │
│ 2. Search test/e2e/ for related tests                           │
│ 3. Assess coverage gaps                                         │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│ Phase 3: Determine Test Strategy                                │
├─────────────────────────────────────────────────────────────────┤
│ ┌──────────────┬────────────────────────────────────────────┐   │
│ │ Change Type  │ Test Requirement                           │   │
│ ├──────────────┼────────────────────────────────────────────┤   │
│ │ New API      │ Integration test (Controller + Service)    │   │
│ │ New Service  │ Integration test (Service layer)           │   │
│ │ Cross-svc    │ E2E test (complete flow)                   │   │
│ │ DB operation │ Integration test (actual DB)               │   │
│ │ External API │ Integration test (mock external)           │   │
│ └──────────────┴────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│ Phase 4: Write Tests                                            │
├─────────────────────────────────────────────────────────────────┤
│ 1. Reference existing test patterns                             │
│ 2. Use {FRAMEWORK_MOCK_LIB} createApp / createRequester        │
│ 3. Follow TEST_ENV environment variable conventions             │
│ 4. Write to corresponding directory                             │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│ Phase 5: Execute Verification                                   │
├─────────────────────────────────────────────────────────────────┤
│ 1. Execute newly added tests                                    │
│ 2. Confirm passing                                              │
│ 3. Report results                                               │
└─────────────────────────────────────────────────────────────────┘

Test File Conventions

| Type | Directory | Naming | Env Variable | | ----------- | ------------------- | -------------------------------------- | ---------------------- | | Integration | `test/integration/` | `*.integration.test.ts` or `*.test.ts` | `TEST_ENV=integration` | | E2E | `test/e2e/` | `*.e2e.test.ts` or `*.test.ts` | `TEST_ENV=e2e` |

Test Template

import { Application, Framework } from '{FRAMEWORK_WEB}';
import { close, createApp } from '{FRAMEWORK_MOCK_LIB}';
import { ITestRequester, createRequester } from '../../createRequester';
import { TestEnvironment, onlyIf } from '../../helper/test-env';

const describeIntegration = onlyIf([
  TestEnvironment.INTEGRATION,
  TestEnvironment.E2E,
]);

describeIntegration('Feature Integration Tests', () => {
  let app: Application;
  let request: ITestRequester;

  beforeAll(async () => {
    app = await createApp<Framework>();
    request = await createRequester(app);
  });

  afterAll(async () => {
    await close(app);
  });

  describe('Scenario: ...', () => {
    it('should ...', async () => {
      // Arrange
      // Act
      // Assert
    });
  });
});

Output

  • Test files (integration/e2e) in correct directories
  • Coverage delta report
  • Gate: ✅ Coverage sufficient / ⛔ Gaps remaining

Verification

  • [ ] Test files in correct directory
  • [ ] Using correct TEST_ENV condition
  • [ ] Test
Read more
@sd0xdev
Ships withsd0x-dev-flow

Language: English | 繁體中文 | 简体中文 | 日本語 | 한국어 | Español The harness layer for Claude Code. Let the model choose the path. Keep "done" verifiable. Claude has discretion inside a closed, test-pinned anchor set.

194102 skills16 agents
Get the whole plugin

Stars on GitHub

Momentum

stars in total
194
Star history of sd0xdev/sd0x-dev-flow on GitHub, a chart by star-history.com

Other skills on sd0x-dev-flow.

adr

adr

Write an Architecture Decision Record (ADR) for a feature — Context / Decision / Status / Consequences / Alternatives, filed as…

agentctl-setup

agentctl-setup

Install and set up the optional agentctl mod (task scope, refusal before execution, evidence that goes stale, model-free…

architecture

architecture

Architecture design and documentation. Produces 3-architecture.md with component diagrams, data flow, integration points, and…

ask

ask

Context-aware Q&A with auto context gathering. Use when: user has a quick question about codebase, git history, rules, docs, or…

best-practices

best-practices

Industry best practices conformance audit with mandatory adversarial debate. Produces audit artifact: verdict (OK/WARN/FAIL) +…

bug-fix

bug-fix

Bug fix workflow. Use when: fixing bugs, resolving issues, regression fixes. Not for: new features (use feature-dev),…

More skills from other plugins.

brainstorming
Auto-invoked

brainstorming

You MUST use this before any creative work - creating features, building components, adding functionality, modifying behavior, or…

@obra@obraInstall Skill
ask-matt

ask-matt

Ask which skill or flow fits your situation. A router over the skills in this repo.

skills10d309k
@mattpocock@mattpocockInstall Skill
accessibility
Auto-invoked

accessibility

Design, implement, and audit accessible UI to WCAG 2.2 Level AA across Web, iOS, and Android — semantic ARIA roles and labels,…

ecc12d293k
@affaan-m@affaan-mInstall Skill
compiler-commit

compiler-commit

Use when you want to verify compiler changes and commit with the correct convention. Runs tests, lint, and format, then commits…

react1d252k
@facebook@facebookInstall Skill

Questions about post-dev-test.

Which coding agents can use post-dev-test?
post-dev-test installs in Claude Code, Codex, Cursor, Gemini CLI, GitHub Copilot, OpenCode and Windsurf with the skills CLI, using each agent's flag shown on this page. Flowy's auto-invocation, which fires a skill when your prompt matches, runs in Claude Code only.