← ClaudeAtlas

testinglisted

Establish, document, and apply project-specific testing workflows. Use for testing strategy, workflow setup/revision, test authoring/alteration, or execution. Do not use for bug fixes, feature implementation, code review, audit, or release.
leninkhaidem/super-developer · ★ 0 · Testing & QA · score 60
Install: claude install-skill leninkhaidem/super-developer
# Testing Resolve the repository's testing authority, establish durable workflow docs when needed, then route downstream test authoring, alteration, or execution with authority-aware instructions. Do not default to standalone broad test edits or commands. ## Always - Canonical interface: root `AGENTS.md` should contain only a concise lazy pointer for testing work, and root-relative `docs/testing/workflow.md` is the reusable workflow entry point. Companion docs live under `docs/testing/` and are loaded only when the workflow points to them. - Authority precedence: system/developer/current user/current skill safety rules outrank project workflow docs; approved project workflow docs outrank optional skill-local references. - Keep this eager prompt meta-level. Put project methodology in `docs/testing/workflow.md` or linked companion docs; use skill references only as optional proposal/adaptation aids. - Choose a mode before acting: initialize/update workflow, author/alter tests, execute a bounded command, or delegate execution-oriented work. - Testing authority is required before test writes, harness/test commands, or delegation. Authority is canonical workflow, routine-safe fallback for one parent-run local command, or task-local Testing Authorization. - Canonical workflow remains the durable authority for broad/reusable delegation, recurring, browser/E2E, live service, shared-data, network, credentialed, dependency/config/CI/orchestration, multi-stage harness,