Test Cases and Acceptance

Requirements

For Codex-class agents with repository and file access capabilities. The documentation does not grant permissions for browsers, testing tools, credentials, project data, or modifying external systems; other hosts may require adaptation.

Confirmed requirements and expected outcomes, with pending rules explicitly noted.
Selected mode and the permissions required for corresponding actions.
Real acceptance requires specifying the application, environment, roles, authorized data, and cleanup scope.

Quick start

After downloading, first check the package instructions, then extract the ZIP to a temporary directory.
When installing the collection, copy the six Skill folders and the shared folder at the same level to the project's .agents/skills/ or personal ~/.agents/skills/. Maintain the relative directory structure; do not install the outer collection directory as a single Skill.
When installing a separate ZIP, place the folder with the same name from it into the selected Skills directory and retain its internal shared resources. Back up any existing Skill with the same name before overwriting to avoid duplicate installation.
In Codex, use the precise $test-case invocation; restart the host if not recognized. Install corresponding companion Skills separately when tasks require process handoff.

Applicable Scenarios

Establish traceable test cases for normal, boundary, rejection, and recovery paths.
Verify existing behavior without modifying code, or support authorized development closed loops.

Steps for Use

Use $test-case, specifying a mode of design, tdd_handoff, validation, or closed_loop; the mode name itself does not grant authority.
Map requirements/acceptance criteria, roles, rules, and risks to test cases with precise expected results, deriving boundaries from agreed units and limits.
The design mode only delivers test cases, it does not perform acceptance that is associated with side effects; execution modes first fix the version, data, and environment, then run authorized checks.
Record the actual statuses of pass, fail, blocked, not run, or justified not applicable; preserve original failures; after obtaining approval for a fix, rerun relevant regression tests and report uncovered scope.

Field Names and Page Text

Requirements, frontend/backend fields, pages, interfaces, and exports should use common, accurate, and consistent business names. Clearly show the mapping between labels and existing identifiers, and do not break public contracts by changing display names. Pages should not add explanatory text that is not explicitly required by default, nor move explanations to placeholders, Tooltips, or collapsed sections; necessary labels, validation, statuses, error, and recovery feedback should be retained as usual. The separate ZIP contains the required shared references.

Deliverables

Test cases, coverage, and status in test-cases.md, and authorized executable tests where permitted.
Test case statuses matching the actual mode and evidence: Case Ready, Red Test Ready, Test Blocked, or Test Passed.

Limitations

Validation mode cannot add or modify test or product code; product fixes require corresponding authorization.
Real acceptance data must come from user-provided or specified sources; derived or synthetic substitute data requires explicit permission.
Mocked results, zero collection tests, uncommented skips, and numeric checks in helper scripts are not equivalent to full product acceptance passes.

Example Prompt, not an Actual Execution Case

Use $test-case in design mode to design test cases for a confirmed text field rule: length is 1–20 Unicode code points, exceeding limits is rejected. Illustrate test cases for lengths 0, 1, 2, 19, 20, 21; blank and normalization rules, if not explicit, should remain pending. Do not run tests or modify code; these numbers are example requirements, not default rules.

This guide explains a packaging workflow, does not represent verified cross-model reliability, and is not a real acceptance run report.

Inside the skill

SKILL.md

---
name: test-case
license: MIT
description: >-
  Derive all applicable test cases from confirmed requirements, business rules, role states, and actual call chains; validate them using authorized data in a real browser or target application and record the results.
  Distinguish test-case design, red-test handoff, validation only, and closed-loop repair; request missing real data first, and obtain explicit permission for substitute data.
---

# Test Cases and Acceptance Validation

Cover the requirements, rules, and actual failure mechanisms within the user-confirmed scope. Do not substitute test counts, line coverage, or an "all green" result for completeness. Record real data, real execution platforms, and real external dependencies separately; none can stand in for the others.

Hand off to `talking-us`, `write-design-doc`, `develop-closed-loop`, or `bug-fixing` as needed. Prefer the user-specified version; otherwise, use the currently enabled entry point. Carry forward the original scope, decisions/open questions, specified data/platforms, existing style, deliverables, and coverage requirements. Do not reinvestigate reliable evidence for the current version.

## 1. Choose the Mode and Confirm Authorization

Included files · 13

test-case/LICENSE
test-case/MANIFEST.json
test-case/README.md
test-case/SKILL.md
test-case/agents/openai.yaml
test-case/references/browser-backend-validation.md
test-case/shared/evals/boundary-dialogue/context-contrast.md
test-case/shared/evals/boundary-dialogue/partial-replies.md
…