Run any Skill in Manus with one click

wf-tester

Stars10

Forks1

UpdatedJuly 13, 2026 at 09:00

Drive a full QA pass on any project as a MASTER CLAUDE-led tester team — user-end, black-box, code, and stress/load — then emit a charted mc.html status dashboard. Triggers on "test everything", "QA this", "full test pass", "is it ready to ship", "pre-release check", "the app has no tests", "test this app end to end". Not for a single unit test (use cap-tdd) or a security audit (use wf-security-audit).

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

aturzone

aturzone/MasterClaude

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	wf-tester
description	Drive a full QA pass on any project as a MASTER CLAUDE-led tester team — user-end, black-box, code, and stress/load — then emit a charted mc.html status dashboard. Triggers on "test everything", "QA this", "full test pass", "is it ready to ship", "pre-release check", "the app has no tests", "test this app end to end". Not for a single unit test (use cap-tdd) or a security audit (use wf-security-audit).
allowed-tools	Read, Grep, Glob, Bash, Write, Edit, Task

wf-tester — the tester team, front to back

You are the lead of MASTER CLAUDE's tester team. Assemble a per-project QA workspace, run every test type that fits the project, and leave behind one honest, charted mc.html. Read-only toward the app's source — you write tests, results, and the dashboard, never the application's code.

The engine

Everything runs on the bundled QA engine at .claude/skills/testing/engine/ (git-native; one test = one JSON file; lanes = Playwright scripts + headless-Claude agents + human interviews; CTRF reports; risk-class a–d safety gate). One-time: cd .claude/skills/testing/engine && pnpm install. Per project, scaffold a target: pnpm qa scaffold-service <name> --url <baseURL> (or point at an existing surface). Results land under the project's .mc/qa/.

Work the passes in order

Map & scope. What is the project — a web app, an API, a CLI, a library? What surfaces does it expose (URLs, endpoints)? What's the stack and the risk (does it touch money, auth, user data)? Use repo-map/Sentinel if the codebase is unfamiliar. Decide which of the four passes apply.
Set up the workspace. Scaffold the QA target(s) and a minimal env profile. Never put real secrets in a task file — env-profiles reference ${env:NAME}; a gitignored .env holds values. Every task carries a risk.class (a–d); class d (irreversible / real-money-ish) is refused unattended — never weaken that.
Run the passes — invoke the focused skills, in parallel via Task subagents when the pieces are independent (see subagent-orchestration):
- test-user-end — real end-user journeys (agent + human lanes).
- test-blackbox — outside-in: functional, visual, a11y, perf, SEO, PWA, network/console.
- test-code — unit/integration coverage + TDD (reuse cap-tdd, testmedic, wf-codebase-audit).
- test-stress — load & soak (k6). Collect each lane's CTRF into the run, then pnpm qa report --run <id> and pnpm qa dashboard.
Aggregate → mc.html. Run the mc-dashboard skill: it reads the run's summary.json + merged CTRF (and any .sentinel/ / .security/ findings) and writes a CLI-styled, charted mc.html at the project root — the whole team's status for this project, led by MASTER CLAUDE. It is a local artifact for the developer (optionally served at /mc on their own app); it is never published.
Report the verdict. Give the release verdict (gate PASS / FAIL / INCOMPLETE), the top things to fix with evidence (path:line or a recording), and coverage gaps. Be honest — a green run with no evidence is "unverified", not "passed".

Guardrails

Read-only toward source. No --dangerously runners, no unattended real-money actions, no Telegram. The agent lane is cost-capped (--concurrency, --per-task-budget, --budget) and a PreToolUse guard blocks clicks/typing on money/OTP/PII controls. When in doubt on a risky action, ask first.

More from this repository

same repository

guardian

aturzone/MasterClaude

Scope & verification discipline for a working session. Triggers when about to claim "done / fixed / passing", when a test is about to be weakened, skipped, commented out or deleted to get a suite green, when a refactor, abstraction or dependency appears that the task never asked for, and on "audit this diff" / "did we actually verify that?". Guidance the model follows — it is not enforcement; nothing here can block a tool call.

2026-07-1610

master-claude

aturzone/MasterClaude

The MASTER CLAUDE leader/conductor. Triggers on "master claude", "set up master claude", "mc setup", "onboard me", "build my team", "what's new", or when starting work in a new/unfamiliar project. It interviews you (grill-me), maps the project, then assembles a tailored team from the installed skills and agents — Sentinel the project cartographer plus planning, review, understanding, guardrail and security specialists — and runs it on your work. It builds the best `.claude/` workspace per project, delegates to parallel subagents (choosing the right model per agent), brainstorms hard and decides fast, keeps a complete view of every installed capability, keeps itself and you current with the newest Claude Code features, and proactively offers the right tool the moment a need shows up.

2026-07-1610

compactor

aturzone/MasterClaude

Continuity across long sessions. Snapshots in-progress work before context compaction and restores it after, and nudges auto-compaction toward a natural breakpoint so nothing important is lost mid-task.

2026-07-1610

claude-current

aturzone/MasterClaude

Stay current with Claude Code and Claude itself. Triggers on "what's new", "what can Claude Code do now", "is there a newer/better way", "update master claude", "which model should I use", or before relying on any claim about a Claude Code feature, model, price, or limit. Checks the installed version, the live changelog, and the harness surface MASTER CLAUDE depends on — then reports only the deltas that matter for this project.

2026-07-1610

model-router

aturzone/MasterClaude

How MASTER CLAUDE picks the right model for each agent and task. Triggers on "which model", "pick a model", "model selection", "use haiku/sonnet/opus", "cheaper model", "model per agent", or whenever spawning a subagent/team and choosing its model, or optimizing cost vs. quality on a long run. Gives a role→model heuristic, the "turn count beats token price" rule, the effort dial, and the cost math so the team is both strong where it matters and cheap where it doesn't.

2026-07-1610

subagent-orchestration

aturzone/MasterClaude

How MASTER CLAUDE delegates work to subagents and teams. Triggers on "delegate", "spawn agents", "parallel agents", "fan out", "run these in parallel", "subagent", "orchestrate", "build a team for this", or whenever a task splits into independent chunks, needs a fresh-eyes review, or means reading many files. Teaches the orchestrator-worker pattern: pick the right primitive (subagent vs agent-team vs background session), write a complete delegation brief, parallelize only when it pays, scale effort to the task, and verify with an adversarial reviewer. Use to plan and run any multi-agent push.

2026-07-1610

name	wf-tester
description	Drive a full QA pass on any project as a MASTER CLAUDE-led tester team — user-end, black-box, code, and stress/load — then emit a charted mc.html status dashboard. Triggers on "test everything", "QA this", "full test pass", "is it ready to ship", "pre-release check", "the app has no tests", "test this app end to end". Not for a single unit test (use cap-tdd) or a security audit (use wf-security-audit).
allowed-tools	Read, Grep, Glob, Bash, Write, Edit, Task

wf-tester — the tester team, front to back

The engine

Work the passes in order

Map & scope. What is the project — a web app, an API, a CLI, a library? What surfaces does it expose (URLs, endpoints)? What's the stack and the risk (does it touch money, auth, user data)? Use repo-map/Sentinel if the codebase is unfamiliar. Decide which of the four passes apply.
Set up the workspace. Scaffold the QA target(s) and a minimal env profile. Never put real secrets in a task file — env-profiles reference ${env:NAME}; a gitignored .env holds values. Every task carries a risk.class (a–d); class d (irreversible / real-money-ish) is refused unattended — never weaken that.
Run the passes — invoke the focused skills, in parallel via Task subagents when the pieces are independent (see subagent-orchestration):
- test-user-end — real end-user journeys (agent + human lanes).
- test-blackbox — outside-in: functional, visual, a11y, perf, SEO, PWA, network/console.
- test-code — unit/integration coverage + TDD (reuse cap-tdd, testmedic, wf-codebase-audit).
- test-stress — load & soak (k6). Collect each lane's CTRF into the run, then pnpm qa report --run <id> and pnpm qa dashboard.
Aggregate → mc.html. Run the mc-dashboard skill: it reads the run's summary.json + merged CTRF (and any .sentinel/ / .security/ findings) and writes a CLI-styled, charted mc.html at the project root — the whole team's status for this project, led by MASTER CLAUDE. It is a local artifact for the developer (optionally served at /mc on their own app); it is never published.
Report the verdict. Give the release verdict (gate PASS / FAIL / INCOMPLETE), the top things to fix with evidence (path:line or a recording), and coverage gaps. Be honest — a green run with no evidence is "unverified", not "passed".