name	write-test-specs
description	Guide for the tester agent when writing test specs in step 5. Auto-loaded when a step-5 task is in progress.
user-invocable	false

Writing test specs (Step 5)

You are writing test specifications before any implementation begins. Your specs define what "passing" means for this feature.

Before you start

Read the feature and definitions_of_done from your task context.
Each DoD criterion must have at least one test spec. Aim for 1–3 specs per criterion.
Check rejection_notes on your task if present — the previous submission was rejected.

Test spec structure

Each spec requires:

description: One sentence — what is being tested? (e.g. "Valid login returns a session token")
expected_result: Exact, measurable outcome (e.g. "HTTP 200 with {token: string} in body")

Optional but recommended:

rationale: Why this test matters — which DoD criterion does it cover?
strategy: How it will be tested — unit, integration, e2e, contract?
order_index: Execution order hint

Coverage rules

Every DoD criterion must map to at least one spec.
Test both the happy path and at least one error/edge case per criterion.
Do not write duplicate specs for the same behaviour.

Good spec examples

description: "POST /users with valid payload creates user and returns 201"
expected_result: "HTTP 201, body contains {id: integer, email: string}"
rationale: "Covers DoD: user creation endpoint returns correct response"
strategy: "integration"

description: "POST /users with missing email returns 400"
expected_result: "HTTP 400, body contains {error: 'email is required'}"
rationale: "Covers DoD: invalid input is rejected with a clear error"
strategy: "integration"

Bad spec examples

expected_result: "no errors" ← not measurable
description: "it works" ← not specific
expected_result: "200" ← missing body/content assertion

Calling submit_test_specs

submit_test_specs(
  task_id=<your task id>,
  specs=[
    {
      "description": "...",
      "expected_result": "...",
      "rationale": "...",
      "strategy": "integration",
      "order_index": 0
    },
    ...
  ]
)

Más de este repositorio

mismo repositorio

create-vscode-custom-agent

pedrogrande/open-taskflow

Create VS Code custom agents (.agent.md files) that define specialized AI personas with scoped tools, model preferences, handoffs, and hooks. Use when creating a new custom agent, configuring tool restrictions for a role, setting up agent handoffs for multi-step workflows, adding agent-scoped hooks, or deciding between agents vs prompt files vs skills.

2026-06-082

initiate-project

pedrogrande/open-taskflow

Guide for the Project Initiation Manager when conducting the brief conversation. Covers all three entry paths (fresh start, rough brief, form JSON), the one-question-at-a-time conversation rules, completeness-driven question ordering, and how to generate the markdown brief.

2026-06-082

my-tasks

pedrogrande/open-taskflow

Show pending tasks for a TaskFlow agent role. Lists what work is waiting and which project/feature each task belongs to. Use this to find out what an agent needs to do next.

2026-06-082

onboard

pedrogrande/open-taskflow

Add TaskFlow to an existing project. Scans the workspace, detects existing agents/skills/MCP servers, and guides the user through creating a brief that captures what's already built.

2026-06-082

start-project

pedrogrande/open-taskflow

Start a new TaskFlow project. Prompts for a project brief (file path or inline text), then hands off to the Project Initiation Manager to build and validate the brief before the Dev Manager configures the team. Use this to kick off a new development cycle.

2026-06-082

upgrade

pedrogrande/open-taskflow

Check for and apply pending TaskFlow schema migrations after pulling a new release.

2026-06-082

Writing test specs (Step 5)

You are writing test specifications before any implementation begins. Your specs define what "passing" means for this feature.

Before you start

Read the feature and definitions_of_done from your task context.

Each DoD criterion must have at least one test spec. Aim for 1–3 specs per criterion.

Check rejection_notes on your task if present — the previous submission was rejected.

Test spec structure

Each spec requires:

description: One sentence — what is being tested? (e.g. "Valid login returns a session token")

expected_result: Exact, measurable outcome (e.g. "HTTP 200 with {token: string} in body")

Optional but recommended:

rationale: Why this test matters — which DoD criterion does it cover?

strategy: How it will be tested — unit, integration, e2e, contract?

order_index: Execution order hint

Coverage rules

Every DoD criterion must map to at least one spec.

Test both the happy path and at least one error/edge case per criterion.

Do not write duplicate specs for the same behaviour.

Good spec examples

description: "POST /users with valid payload creates user and returns 201" expected_result: "HTTP 201, body contains {id: integer, email: string}" rationale: "Covers DoD: user creation endpoint returns correct response" strategy: "integration"

description: "POST /users with missing email returns 400" expected_result: "HTTP 400, body contains {error: 'email is required'}" rationale: "Covers DoD: invalid input is rejected with a clear error" strategy: "integration"

Bad spec examples

expected_result: "no errors" ← not measurable

description: "it works" ← not specific

expected_result: "200" ← missing body/content assertion

Calling submit_test_specs

submit_test_specs( task_id=<your task id>, specs=[ { "description": "...", "expected_result": "...", "rationale": "...", "strategy": "integration", "order_index": 0 }, ... ] )