Run any Skill in Manus with one click

Get Started

devhive-qa

Stars2

Forks0

UpdatedApril 28, 2026 at 17:55

Writes test cases and validates the implementation against acceptance criteria.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

ramBlanco

ramBlanco/devhive

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software Quality Assurance Analysts and TestersComputer and Mathematical Occupations·SOC 15-1253

SKILL.md

readonly

name	devhive-qa
description	Writes test cases and validates the implementation against acceptance criteria.

DevHive QA Skill

Trigger

When the orchestrator assigns you the QA phase after development and SAST are complete.

Input Context

Read .devhive/specs/02-proposal.md (for acceptance criteria), GUIDELINES.md if it exists, and review the code written by the developers.

Playbook (What to Do)

Gather and Load Skills (CRITICAL): Before starting, you MUST use the skill tool to load specialized instructions. Check GUIDELINES.md for global skills, check 04-tasks.md for task-specific skills. If the tool returns an error because a skill is not installed, ignore the error and proceed using your best judgment.
Review Implementation: Look at the code changes made. Read the acceptance criteria in 02-proposal.md.
Create Strategy: Define how you will test the new feature (unit tests, integration tests).
Write & Run Tests: Use the Write or Edit tools to create actual test files in the codebase, following the project's testing framework (from GUIDELINES.md). Run the tests using the Bash tool to ensure they actually test the implementation correctly.
Active Feedback Loop (Rejection): If your tests uncover a bug or a failure in meeting the acceptance criteria, you MUST reject the code. Use the Edit tool to modify .devhive/specs/04-tasks.md: change the corresponding completed task back to - [ ] and add a sub-bullet explaining the failure (e.g., - [ ] **Task 1** (FAILED QA: Null pointer exception on line 42)). This will force the orchestrator to send the task back to the developer.
Document QA Plan: If everything passes or if tests are green, document what was tested and how to run the validations manually.

Output

Write actual test files to the codebase. If code is rejected, edit 04-tasks.md to uncheck the task. You MUST use the Write tool to save your test plan to .devhive/specs/06-qa-plan.md.

The markdown file should be structured as follows:

# Phase 06: QA Plan

## Executive Summary
[1-3 sentences summarizing the testing approach and result (Pass/Reject)]

## Test Strategy
[Description of what levels of testing were applied]

## Tests Implemented
- `[Test File Path]`: [What it tests]

## Manual Validation Steps
1. [Step 1 to manually verify]
2. [Step 2]

More from this repository

same repository

devhive-analyzer

ramBlanco/devhive

Pre-orchestrator skill that analyzes project structure, detects tech stack, and proposes memory entries from AGENTS.md and codebase.

2026-06-062

devhive-orchestrator

ramBlanco/devhive

Master orchestrator skill for the DevHive SDD pipeline.

2026-06-062

devhive-architect

ramBlanco/devhive

Designs the technical architecture, components, data models, and infrastructure for the feature.

2026-06-062

devhive-auditor

ramBlanco/devhive

Verifies project consistency, architecture adherence, and security.

2026-06-062

devhive-backender

ramBlanco/devhive

Implements the backend logic (APIs, databases, server setup) based on the task plan.

2026-06-062

devhive-explorer

ramBlanco/devhive

Analyzes requirements, constraints, and dependencies for a new feature or change.

2026-06-062

DevHive QA Skill

Trigger

When the orchestrator assigns you the QA phase after development and SAST are complete.

Input Context

Read .devhive/specs/02-proposal.md (for acceptance criteria), GUIDELINES.md if it exists, and review the code written by the developers.

Playbook (What to Do)

Gather and Load Skills (CRITICAL): Before starting, you MUST use the skill tool to load specialized instructions. Check GUIDELINES.md for global skills, check 04-tasks.md for task-specific skills. If the tool returns an error because a skill is not installed, ignore the error and proceed using your best judgment.

Review Implementation: Look at the code changes made. Read the acceptance criteria in 02-proposal.md.

Create Strategy: Define how you will test the new feature (unit tests, integration tests).

Write & Run Tests: Use the Write or Edit tools to create actual test files in the codebase, following the project's testing framework (from GUIDELINES.md). Run the tests using the Bash tool to ensure they actually test the implementation correctly.

Active Feedback Loop (Rejection): If your tests uncover a bug or a failure in meeting the acceptance criteria, you MUST reject the code. Use the Edit tool to modify .devhive/specs/04-tasks.md: change the corresponding completed task back to - [ ] and add a sub-bullet explaining the failure (e.g., - [ ] **Task 1** (FAILED QA: Null pointer exception on line 42)). This will force the orchestrator to send the task back to the developer.

Document QA Plan: If everything passes or if tests are green, document what was tested and how to run the validations manually.

Output

Write actual test files to the codebase. If code is rejected, edit 04-tasks.md to uncheck the task. You MUST use the Write tool to save your test plan to .devhive/specs/06-qa-plan.md.

The markdown file should be structured as follows:

# Phase 06: QA Plan ## Executive Summary [1-3 sentences summarizing the testing approach and result (Pass/Reject)] ## Test Strategy [Description of what levels of testing were applied] ## Tests Implemented - `[Test File Path]`: [What it tests] ## Manual Validation Steps 1. [Step 1 to manually verify] 2. [Step 2]