菜单
Run a live QA pass over the app — first map all user-facing functionality, then boot the full stack and manually exercise flows with Playwright, recording pass/fail evidence and filing a QA report. Use for release QA, post-merge smoke passes, or "QA the app / this area" requests.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Add a new data source / connection type (e.g. a SQL Server-like database) end to end — client with get_schemas/execute_query, config + credentials schemas, registry entry, icon, tests — plus the verification steps. Also covers adding or updating an MCP connector (a preset, not a new type). Use when adding or significantly extending a connector.
Add a new LLM model to the preset catalog, or a whole new LLM provider — with the mandatory pre-flight verification of model id, pricing, and context window against the provider's official docs. Use when asked to add/update LLM models, providers, or pricing.
Build a runnable reproduce→fix→verify loop for a bug or feature in a fresh sandbox, and record it as a feedback-loop doc. Use when investigating a reported bug, validating a root cause, or proving a fix works — before and after the change.
The locale/i18n architecture of bagofwords — catalogs, resolution order, RTL, backend contracts — and the procedures for adding strings, adding a locale, or translating UI. Use when adding/changing user-facing strings, working on RTL, emails, localized errors, or anything locale-related.
Capture mandatory before/after screenshots (and videos/GIFs for flows) for any change touching UI/UX, and attach them to the PR. Use whenever a change touches frontend/pages, components, layouts, or assets.
Update the product docs at docs.bagofwords.com (Mintlify) with text and fresh screenshots after a user-facing change ships. Use when a merged change alters user-visible behavior, adds a feature, or when asked to update/refresh documentation.
| name | qa |
| description | Run a live QA pass over the app — first map all user-facing functionality, then boot the full stack and manually exercise flows with Playwright, recording pass/fail evidence and filing a QA report. Use for release QA, post-merge smoke passes, or "QA the app / this area" requests. |
Two phases, always in this order. The map is what keeps the live pass honest: without it you test what's easy, not what exists.
Build (or refresh) docs/qa/functionality-map.md by enumerating from code, not
memory:
frontend/pages/** (file-based routing).backend/app/routes/*.py — group by domain.frontend/middleware/{auth,permissions,onboarding}.global.ts —
note which flows require auth, permissions, or onboarding state.frontend/tests/** and backend
e2e in backend/tests/e2e/** — mark what's already automated.Format — one row per user-facing flow:
| Area | Flow | Route(s) | API | Automated coverage | Last QA | Status |
|---|
Keep rows behavioral ("invite a member and they can sign in"), not structural ("members page renders"). If a functionality map already exists, diff it against the current routes/pages and update it rather than regenerating.
tools/agent/boot_stack.sh # backend :8000 + built frontend :3000
cd backend && uv run python ../tools/agent/seed_org.py --demo --invite member@example.com
http://localhost:3000, not by calling APIs directly. Use throwaway specs or
cd frontend && node ../tools/agent/capture.mjs <url> <shot.png> for
evidence. export PLAYWRIGHT_BROWSERS_PATH=/opt/pw-browsers in sandboxes./tmp/bow-agent/backend.log).docs/feedback-loops/qa-<date>-<scope>.md:
scope, environment, table of flows with verdicts + evidence, and a
findings section where each failure follows the sandbox-feedback-loop
format (symptom → repro → suspected root cause with file:line).Last QA / Status columns as you go — the
map is the durable artifact, the report is the snapshot.