菜单
Browser-based manual testing of the doughnut web app. Use ONLY when the developer explicitly asks to test manually or when a plan phase includes manual testing. Do NOT use proactively.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Set up and run the doughnut dev environment on Cursor Cloud VM (no Nix). Use when working on Cloud VM, running tests on Cloud VM, or encountering command errors related to missing nix. Triggers on: cloud VM, cloud agent, no nix available, /workspace path.
Retrospective on what made a task unexpectedly difficult. Triggered by the 5-minute timer hook. Reviews your own session to identify codebase friction and either fixes it or proposes improvements. Triggers on: 5-minute hook, slow progress, friction, hard to find, confusing.
Autonomously execute a phased plan under .planning/phases/ or .planning/quick/ (GSD PLAN.md files, or legacy flat/ongoing plans). Applies local wrap-up on every phase: Jidoka, post-change-refactor, plan update, commit, and push. Parallel waves OK when safe. Triggers on: execute plan, run plan, execute phases, start plan, do .planning, execute .planning, run .planning.
Decompose tasks into GSD-aligned phased plans with Behavior/Structure grammar (one observable behavior per phase, stop-safe). Use when planning new features, breaking down large tasks, when a task has been in progress for over 10 minutes, or when the planning timer hook fires. Triggers on: plan, decompose, phases, break down, task too large, stuck.
Profile a test suite, optimize the slowest top 10% in phased groups, and close with a re-profile. Works for unit/integration tests in any sub-project (backend, frontend, cli, mcp-server) or Cypress E2E. Use when the developer asks to optimize, speed up, or profile slow tests, top 10% slowest, or test performance.
Fix bugs with a test-first workflow. Use when the user reports a bug, asks to fix a defect, or describes unexpected behavior. Triggers on: bug, fix, defect, broken, regression, not working, unexpected behavior.
| name | manual-testing |
| description | Browser-based manual testing of the doughnut web app. Use ONLY when the developer explicitly asks to test manually or when a plan phase includes manual testing. Do NOT use proactively. |
Purpose: Human-directed or plan-mandated exploratory testing — not a default agent workflow.
Output: Verified behavior report + summary ending with
## MANUAL TEST COMPLETE.
Prerequisites: Assume pnpm sut is already running (backend, frontend,
Mountebank — all auto-reload on code changes). If not running, suggest the user
start it in a separate terminal. To use AI services, set OPENAI_API_TOKEN
before pnpm sut.
Access points:
Test accounts:
old_learner / passwordanother_old_learner / passwordadmin / passwordLinting: The frontend dev server runs linting in the background. Errors appear in terminal output (overlays disabled). Check terminal and fix errors before committing.
1. `browser_navigate` to http://localhost:5173/ 2. `browser_snapshot` to understand current state 3. Interact: `browser_click`, `browser_type`, `browser_select_option` 4. `browser_snapshot` to verify result 5. `browser_console_messages` / `browser_network_requests` if issues occur 1. Navigate to the app URL 2. Click "Login via Github" (redirects to username/password form) 3. Fill `id="username"` and `id="password"` 4. Click `id="login-button"` - Prefer `id` or `aria-label` attributes - Fall back to element text/role - Use `browser_snapshot` to see available elements and refs<success_criteria>
pnpm sut running (or user notified to start it)## MANUAL TEST COMPLETE
</success_criteria>## MANUAL TEST COMPLETE
<out_of_scope>