一键在 Manus 中运行任何 Skill

wf-tester

星标10

分支1

更新时间2026年7月23日 11:29

Drive a full QA pass on any project as a SKULL-led tester team — user-end, black-box, code, and stress/load — then emit a charted skull.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).

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

在 Manus 中运行

来源

aturzone

aturzone/Skull

打开 GitHub 仓库查看创作者相关仓库

下载

在 Manus 中运行

wf-tester — the tester team, front to back

You are the lead of SKULL's tester team. Assemble a per-project QA workspace, run every test type that fits the project, and leave behind one honest, charted skull.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 .skull/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 → skull.html. Run the skull-dashboard skill: it reads the run's summary.json + merged CTRF (and any .sentinel/ / .security/ findings) and writes a CLI-styled, charted skull.html at the project root — the whole team's status for this project, led by SKULL. 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. 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.

同仓库更多 Skills

同仓库

fe-refactor

aturzone/Skull

Restructure frontend code so it's testable, predictable, and correctly layered — without changing behavior. Pull pure logic out of framework glue, fix reactivity anti-patterns (derived state synced by a watcher/effect, logic in the view, effects with no cleanup, unstable list keys), name and place extractions right (util vs helper vs colocated), and keep the base ← common ← feature dependency one-way. Triggers on "refactor this component", "logic in the template/JSX", "this is hard to test", "watch/useEffect misused", "component does too much", "where does this helper go". Vue & React.

2026-07-2310

fe-token-audit

aturzone/Skull

Find and fix hardcoded design values that bypass the design system — raw hex/rgb/hsl colors, arbitrary Tailwind classes like `bg-[#1f2432]`, inline-style colors, and magic spacing/radius/shadow — and route each through a token. Triggers on "remove hardcoded colors", "use our design tokens", "enforce the design system", "why isn't dark mode working here", or a linter flagging arbitrary values. Complements `fe-design-system` (which defines the tokens); this enforces their use.

2026-07-2310

test-frontend

aturzone/Skull

Test frontend UI code the way it should be tested — risk-scored per file (P0–P3), behavior-not-implementation, boundary-only mocking, and the minimum valuable set. Covers components, composables/hooks, stores, forms, and SSR/hydration safety using the project's own runner (Vitest/Jest + Testing Library / Vue Test Utils, Playwright for E2E). Triggers on "test this component/page", "frontend/Vue/React/Nuxt tests", "component/composable/store tests", "why is this test flaky", "should this be an E2E?". Not for non-UI logic (use test-code) or outside-in black-box QA (use test-blackbox).

2026-07-2310

codescribe

aturzone/Skull

Capture the *why* after a change — the non-obvious knowledge a future developer or agent can't recover by reading the code: hidden constraints, business rules, rejected alternatives, edge-case guards, invisible API contracts, and what silently breaks if the code changes. Triggers on "document this", "write docs for what we built", "capture why this exists", "document the constraints/decisions", "preserve this for future devs" — after a feature, refactor, or bug fix. NOT for README, API docs, code comments, or CHANGELOG — only the knowledge the code can't tell you.

2026-07-2310

skull

aturzone/Skull

The SKULL leader/conductor. Triggers on "skull", "set up skull", "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-2310

doc-office

aturzone/Skull

Generate and edit Microsoft Office files — Word, Excel, PowerPoint — when the deliverable is a document, not code. Triggers on "make a Word doc", "generate an Excel report", "build a spreadsheet with formulas or charts", "create a deck or slides", "fill a docx template". Reaches for python-docx and docxtpl (templated documents), openpyxl and XlsxWriter (spreadsheets with real formulas, styling, charts), and python-pptx (slides from data). Prefers templating over hand-building; keeps numbers as live formulas, not strings.

2026-07-2210

name	wf-tester
description	Drive a full QA pass on any project as a SKULL-led tester team — user-end, black-box, code, and stress/load — then emit a charted skull.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 → skull.html. Run the skull-dashboard skill: it reads the run's summary.json + merged CTRF (and any .sentinel/ / .security/ findings) and writes a CLI-styled, charted skull.html at the project root — the whole team's status for this project, led by SKULL. 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".