dasha-ws/ai-dev-framework/test-feature

test-feature

Purpose

/test-feature is the independent verification gate between implementation and code review. It verifies one already implemented work item of a target project: the implemented behaviour against the approved intent, and the relevant regression surface. The verification is done by the independent reviewers that apply, which this skill orchestrates: qa-reviewer, product-reviewer and, for user-facing work, ux-reviewer. It returns one final result, PASS, FAIL or BLOCKED — NO VERDICT (step 9).

It is not a builder. It does not write or fix production code, tests, fixtures or snapshots, change requirements, architecture, the Tech Spec or the UI, or update documentation, and it is not a code review, a security or infrastructure audit or a deployment readiness review. The build report is context, never evidence: "tests passed" from the builder is a claim, and green developer checks never become a PASS on their own. A defect goes back to where it was made:

/test-feature → FAIL → /build-feature → /test-feature again.

After a PASS the next step is /review-code. What follows is governed by "Next skills".

Reviewers. They stay separate, never merged into one universal reviewer. qa-reviewer asks whether it was built correctly, product-reviewer whether the right thing was built (the approved product or feature intent), ux-reviewer whether the user-facing experience matches the approved UX expectations. Each takes its detailed professional criteria from its own agent definition. This skill owns applicability, workflow, gate invariants, safety, aggregation and routing.

Source of truth. The expected behaviour comes from the approved sources of step 3. Code and existing tests are the implementation under test, not the expected behaviour just because they exist.

A PASS is version-specific. It proves that the implementation, as it was actually tested, meets the approved expectations it was tested against. An old PASS is no longer sufficient, and a new /test-feature is needed, after a substantive change to:

• the production implementation, including migrations;
• the required automated tests and their required fixtures and snapshots (required by the current tests or the project conventions);
• verification-relevant implementation or test configuration;
• an applicable source of truth, where the change materially affects the approved expectations or the verification scope of this work item: the Product Spec or Feature Spec requirements, the current Tech Spec, the relevant agreed architecture contracts and boundaries, the approved UX/UI direction.

Normal transient test outputs (coverage files, reports, caches, screenshots and videos created only as runtime artifacts), unrelated files and source changes not relevant to this work item or its verification scope do not invalidate a PASS. A PASS is never carried over to new expectations, even if the implementation did not change: "the requirement became weaker, so the old PASS still counts" is not valid without new verification. When a relevant source changed, step 3 applies. Nothing is recorded: no hashes, approval registry, QA status file or PASS metadata. A later stage may treat a PASS as reliably established only if the current conversation or workflow contains it for this very implementation and the sources it was tested against, with no relevant substantive change since, or the user explicitly confirms the same. Otherwise it does not count, and the safe move is a new run.

One work item per run. The work item under test and the regression surface are kept apart (step 2).

When to use

• After /build-feature for substantial work: reviewed requirements → architecture as applicable → reviewed Tech Spec → /build-feature → /test-feature.
• For a real microchange that the user explicitly wants verified, in proportion.
• After a FAIL was fixed by /build-feature, after a BLOCKED cause was resolved, or after a reliably known change that voids an earlier PASS (see "Purpose"). A changed source completes its own upstream gates first.

When not to use

• The current directory is the ai-dev-framework repository itself. That repo is the source of the framework, not a target. If the root contains the framework's own skills/ folder, stop and ask which project the user actually means.
• The framework structure created by /init-project is missing (step 1).
• Nothing of the work item is implemented. That is /build-feature. A partly implemented item is tested as it stands (step 2).
• The work is substantial and has no requirements or no Tech Spec (step 3), or a "microchange" turns out to be substantial (step 2).
• The request covers several work items.
• The user wants bugs fixed, tests written, snapshots updated or a feature added (/build-feature), code reviewed (/review-code), documentation updated (/update-docs), deployment readiness checked (/deploy-check), or a security or infrastructure audit.

Inputs

• Target project root. Default: the current working directory. Confirm it if there is any doubt.
• The work item. Substantial work: .claude/work/<work-item-name>/tech-spec.md. Microchange: the user's request.
• The applicable approved requirements. The Feature Spec of the work item, or the Product Spec for an initial product implementation.
• The framework structure created by `/init-project`. Substantial work: root CLAUDE.md, .claude/skills/project-context/SKILL.md, in .claude/skills/project-context/context/ the files product.md, architecture.md, development.md and infrastructure.md, plus .claude/product/product-spec.md and .claude/work/. Microchange: root CLAUDE.md and the router.
• The implementation, its automated tests and its test and application configuration.
• The reviewers qa-reviewer, product-reviewer and ux-reviewer, as provided by the current installation. Agents are built after the skills, so a reviewer may not be installed yet (step 4).
• A safe verification environment.
• The `/build-feature` report, if any. Context only.
• The user, for the few questions only they can settle (step 2).

Files to read

All reads are read-only. Never read or expose real .env files, passwords, tokens, credentials or secret keys. Use the existing safe test configuration. Do not load the whole repository without a reason.

• Substantial work: the root CLAUDE.md; the router; the current Tech Spec; the applicable reviewed requirements (the Product Spec directly for an initial product implementation, for feature work only where needed to understand the product intent); architecture.md only where it bears on observable boundaries and contracts; the relevant parts of development.md and infrastructure.md; ux-guide.md when the work is user-facing and the router marks it relevant; the relevant production code, automated tests, test configuration and application configuration that affects test behaviour.
• Microchange: the root CLAUDE.md, the router, the minimum relevant context, and the affected code, tests and configuration.

Execution steps

1. Confirm the target and the framework structure

Verify that the working directory is a target project, not the framework repo, and that the structure required for the mode exists (see "Inputs"). If it is missing: stop with `BLOCKED — NO VERDICT`, say what is missing and suggest /init-project. Do not create or rebuild it.

Follow the target's root CLAUDE.md and conventions. They may refine how the verification is done and cannot silently override a mandatory framework gate. If a project instruction directly conflicts with a mandatory framework rule and both cannot be satisfied, stop, report the conflict and ask for a decision.

2. Decide the mode and the work item

Spec-driven substantial work. The work item has a Tech Spec and approved requirements, and the implementation exists. It usually arrives straight after /build-feature. Do not ritually repeat /review-spec. Real microchange. Work where a separate Tech Spec would be decoration. The basis is the user's request, the affected implementation, the relevant existing behaviour and the applicable project instructions. No artificial specs, proportional verification, and not every reviewer forced on it (step 4).

Do not shrink substantial work into a microchange to save time. If the work turns out to be substantial (new product behaviour, a new contract, a schema change, a non-obvious technical decision), stop and route to the normal workflow: /new-feature-spec or /product-spec, /tech-spec, /review-spec, /build-feature, then back here.

Exactly one work item. If the Tech Spec or the request covers several, take the one the sources and the user point to, and ask if that is unclear. For substantial work, establish which requirements apply (the feature-spec.md in the same work folder, or the Product Spec for an initial product implementation). If the workflow cannot be determined, do not guess. Ask.

The implementation must exist. If nothing of the work item is in the code, there is nothing to verify: stop with `BLOCKED — NO VERDICT` and route to /build-feature. A partly implemented item is tested as it stands, and what is missing against the approved behaviour is a defect, not an excuse.

Keep two scopes apart: the work item under test (what the approved sources say it must do) and the regression surface (neighbouring behaviour, shared components, touched contracts and integrations it could realistically have broken, picked from the actual impact and not from habit).

Ask the user only what the sources cannot answer: unresolved product behaviour, permission for a real side effect, a missing safe environment or test account, a business or security policy, an inaccessible required system, an ambiguous source conflict, or a decision the framework cannot safely infer. No QA interview.

3. Establish the sources and the workflow state

Sources. The Product Spec and the reviewed Feature Spec define the intended behaviour and intent. The reviewed Tech Spec defines the design, including the technical contracts that are externally observable or required. architecture.md matters only for observable boundaries and contracts. ux-guide.md holds the approved UX and UI conventions, where it exists. Project context holds durable constraints and the project's own commands. For a real microchange, the user's request, the affected existing behaviour and the applicable project instructions stand in for formal specs.

For substantial work, the applicable approved requirements and the current Tech Spec must exist and hold real content. If one is missing, empty or a not-started stub, the expected behaviour is not established: stop with `BLOCKED — NO VERDICT` and route to the matching workflow (see "Next skills").

How workflow state is established. Whenever this skill depends on a previous gate or PASS state, it counts as reliably established only through the current conversation or workflow, an explicit user confirmation, or a FRESH row of the workflow ledger .claude/work/status.md (powershell.exe -NoProfile -ExecutionPolicy Bypass -File "%USERPROFILE%\.claude\ai-dev-framework\scripts\workflow-state.ps1" check, see templates/work/status.md: the script decides freshness, and a STALE or missing row is not established). Never infer it from file contents, git history, commits, timestamps, comments or file existence. If it cannot be established, it does not count. If the conversation already establishes it, or nothing reliably shows a relevant substantive change of a source or after a PASS, do not ask for a ritual confirmation. This gate does not re-prove earlier gates: if the workflow is plainly the normal one and no conflict is known, take the sources as approved. This skill only reads the ledger for this.