Run any Skill in Manus with one click

Get Started

source-command-qa-scaffold-tests

Stars2

Forks0

UpdatedJune 13, 2026 at 03:29

QA — materialize tests for the given files, routing each slice to the right specialist.

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

reiTavares

reiTavares/ContextDevKit

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	source-command-qa-scaffold-tests
description	QA — materialize tests for the given files, routing each slice to the right specialist.

source-command-qa-scaffold-tests

Use this skill when the user asks to run the migrated source command scaffold-tests.

Command Template

🧪 Scaffold tests

Materialize tests for: $ARGUMENTS

Act as qa-orchestrator and route work to the specialists (fan out in parallel for independent slices via the Agent tool when available):

qa-unit → pure functions/modules in scope (fast, mocked deps).
qa-integration → anything crossing a boundary (HTTP/DB/queue/fs).
qa-fuzzer → parsers, validators, schemas, auth, and qa.criticalPaths.
qa-e2e → critical user journeys, plus visual / screenshot checks where the UI's look is the contract (scaffold with /visual-test).

Before dispatch, run:

node contextkit/tools/scripts/scaffold-tests.mjs plan "$ARGUMENTS" --json

Use that stack-aware matrix to decide which specialists should receive which slices. If the project has no test harness yet, run a dry-run first:

node contextkit/tools/scripts/scaffold-tests.mjs scaffold "$ARGUMENTS"

Only create starter harness files with explicit write intent:

node contextkit/tools/scripts/scaffold-tests.mjs scaffold "$ARGUMENTS" --write

Dispatches inherit each specialist's frontmatter model: tier (ADR-0052 — qa-unit/qa-integration run on the fast tier; their output is guarded by rule 4 below). If a specialist's output fails the suite twice, re-dispatch exactly once, one tier up, and report the escalation.

Rules:

Match the project's existing test runner and file conventions. Never add a second framework.
Use the deterministic scaffold script only for runner harnesses; domain tests still come from the specialists after they read the code.
Place test files where the project keeps them; mirror existing naming.
Cover happy / edge / failure for each slice (use a prior /test-plan if one exists).
After writing, run the suite and report pass/fail.

If sub-agents aren't available in this environment, write the tests yourself but keep the unit / integration / fuzz separation explicit.

More from this repository

same repository

source-command-domain

reiTavares/ContextDevKit

Domain Engineering diagnostic — shows what the classifier decides for an objective (CMIS/DAS/profile/skills/mode). Observation-only; never mutates or blocks.

2026-07-172

source-command-pipeline-work

reiTavares/ContextDevKit

Business-driven methodology entry point — classify (intake), create/advance an Operation or Business work context, and drive the intake → operation → nested-workflow flow. Host-neutral; dry-run by default.

2026-06-272

source-command-pipeline-workflow-assist

reiTavares/ContextDevKit

Workflow Navigator — shows the current phase, deliverables, and next commands for an ADR-0057 workflow. Read-only; never mutates state.

2026-06-272

source-command-pipeline-dev-start

reiTavares/ContextDevKit

Start a focused session on one objective — locks scope, blocks opportunistic refactors.

2026-06-272

source-command-pipeline-pipetest

reiTavares/ContextDevKit

Deterministic QA gate (ADR-0055) — run the project suite; green + complete acceptance criteria ⇒ qa-approve testing cards into conclusion; red ⇒ report (and qa-reject only attributable failures).

2026-06-272

source-command-pipeline-ship

reiTavares/ContextDevKit

L6 — autonomous feature pipeline. Drives the full squad: design → implement → review → test → log. Checkpoints can be manual or automatic.

2026-06-272

🧪 Scaffold tests

Materialize tests for: $ARGUMENTS

Act as qa-orchestrator and route work to the specialists (fan out in parallel for independent slices via the Agent tool when available):

qa-unit → pure functions/modules in scope (fast, mocked deps).

qa-integration → anything crossing a boundary (HTTP/DB/queue/fs).

qa-fuzzer → parsers, validators, schemas, auth, and qa.criticalPaths.

qa-e2e → critical user journeys, plus visual / screenshot checks where the UI's look is the contract (scaffold with /visual-test).

Before dispatch, run:

node contextkit/tools/scripts/scaffold-tests.mjs plan "$ARGUMENTS" --json

Use that stack-aware matrix to decide which specialists should receive which slices. If the project has no test harness yet, run a dry-run first:

node contextkit/tools/scripts/scaffold-tests.mjs scaffold "$ARGUMENTS"

Only create starter harness files with explicit write intent:

node contextkit/tools/scripts/scaffold-tests.mjs scaffold "$ARGUMENTS" --write

Rules:

Match the project's existing test runner and file conventions. Never add a second framework.

Use the deterministic scaffold script only for runner harnesses; domain tests still come from the specialists after they read the code.

Place test files where the project keeps them; mirror existing naming.

Cover happy / edge / failure for each slice (use a prior /test-plan if one exists).

After writing, run the suite and report pass/fail.

If sub-agents aren't available in this environment, write the tests yourself but keep the unit / integration / fuzz separation explicit.