원클릭으로 Manus에서 모든 스킬 실행

시작하기

source-command-qa-scaffold-tests

스타2

포크0

업데이트2026년 6월 13일 03:29

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

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

reiTavares

reiTavares/ContextDevKit

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

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.

이 저장소의 다른 Skills

같은 저장소

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.

name	source-command-qa-scaffold-tests
description	QA — materialize tests for the given files, routing each slice to the right specialist.