acceptance-tests

Name: acceptance-tests
Availability: InStock
Author: thegeronimo

Designescribes acceptance and integration test proposals from frozen specs or ExecPlans for downstream teams.

44|8|Updated Jul 14, 2025

Search Tags:#workflow #integration #qa #multi-agent #spec #acceptance-testing #test-proposal

Ready to run

npx skills add https://github.com/thegeronimo/hyperopen --skill acceptance-tests

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: acceptance-tests
Source: https://github.com/thegeronimo/hyperopen/tree/main/.agents/skills/acceptance-tests
Command: npx skills add https://github.com/thegeronimo/hyperopen --skill acceptance-tests

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Use when acting as acceptance_test_writer to propose happy-path acceptance and integration coverage from an approved spec or ExecPlan. Do not use to materialize tests directly or to edit production code.

Core Features & Use Cases

Proposal pass only: design acceptance and integration tests from the frozen spec.
Focus on user-visible happy-path and integration behavior, not boundary or adversarial coverage.
Guardrails:
- Write only manager artifacts under /hyperopen/tmp/multi-agent/<bd-id>/.
- Do not materialize tests directly.
- Never edit /hyperopen/src/**.

Quick Start

Draft a proposal outlining acceptance and integration tests from the current spec so that downstream teams can implement them accurately.

Frequently Asked Questions about acceptance-tests

High-intent search queries and answers about installing and using this skill.

FAQPage Schema

How do I draft acceptance tests from an approved spec for downstream teams?▼

Draft acceptance tests from an approved spec by outlining happy-path acceptance and integration coverage proposals. This creates structured acceptance criteria that guide downstream testing activities without materializing actual tests or editing production code.

What is the difference between proposing acceptance tests and writing actual test code?▼

Proposing acceptance tests involves designing coverage plans and acceptance criteria from a frozen spec, whereas writing actual test code means materializing executable tests. This proposal pass focuses on user-visible happy-path and integration behavior, leaving implementation to downstream teams.

Can I use this approach to generate tests for multi-agent ticket workflows?▼

Yes, you can generate test proposals for multi-agent ticket workflows where the writer produces structured acceptance criteria and coverage plans. Artifacts are written only to the designated manager directory under the multi-agent path, keeping production code untouched.

Does this proposal pass cover boundary and adversarial test cases?▼

No, this proposal pass does not cover boundary or adversarial test cases. It focuses exclusively on user-visible happy-path and integration behavior from the frozen spec or ExecPlan to guide downstream testing activities.

How do I start designing integration test coverage from an ExecPlan?▼

Start designing integration test coverage from an ExecPlan by reviewing the frozen spec and drafting a proposal that outlines happy-path integration behavior. This ensures downstream teams can implement tests accurately based on structured criteria.

Why should I not edit production code when creating acceptance test proposals?▼

You should not edit production code because the task is strictly a proposal pass that writes only manager artifacts to the designated multi-agent directory. This guardrail ensures separation between test design and production implementation.