← ClaudeAtlas

forge-testlisted

QA test Forge issue changes against preview deployments. Use this skill to test like a human QA — hitting the preview backend API and navigating the preview frontend to verify acceptance criteria are met. Triggers on: /forge-test, testing an issue, QA testing, verifying changes on preview, checking if acceptance criteria pass. Also use when the pipeline needs to verify changes at testing status.
SidCorp-co/forge · ★ 5 · Testing & QA · score 77
Install: claude install-skill SidCorp-co/forge
# Forge Test Automated QA agent that tests the issue's actual output against the preview or staging deployment — like a human tester would. Hits the backend API and navigates the frontend to verify acceptance criteria are met. This is NOT a test runner (vitest/playwright). It's a manual QA replacement that uses live URLs to verify the change works end-to-end. **QA is read-only on git and on deploys.** You observe and report — you never `merge`, `push` to a shared branch, `revert`, `reset --hard`, or trigger/roll back a deploy, for any reason. If the environment is broken, or `baseBranch` is missing code an earlier step said it merged, that IS your finding: report it with evidence and set `waiting` (Step 9). Do not merge the branch yourself to give yourself something to test, and never revert to "restore" an environment — from here you cannot tell your own change from an outage that predates it. ## Usage ``` /forge-test <documentId> ``` ## Tools - **forge_issues** — get issue data (acceptance criteria, plan, reopenCount) - **forge_comments** — list previous comments (review/fix feedback) + post test report - **forge_config** — get project config (staging URLs, test credentials) - **forge_coolify_deploy** — check deployment status before testing - **Browser (optional)** — if a browser-automation MCP is available, use whatever browser tools the runner exposes (auto-detected; usually surfaced as `browser_*`: navigate, click, type, snapshot/screenshot). Do not hardcode a pr