一键在 Manus 中运行任何 Skill

开始使用

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 仓库查看创作者相关仓库

下载

在 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.