project-qa
Skill0 starsChanged 41 days agoApache-2.0View on GitHub
Run scoped project-native checks and actual end-to-end acceptance journeys, then report failures and evidence for fixes.
In this repository14 other files it gives its agents.
- AGENTS.mdAGENTS.md
- business-operationsSkill
- capability-managerSkill
- decision-routingSkill
- global-orchestratorSkill
- integration-builderSkill
- plugin-safety-reviewSkill
- project-designSkill
- project-discoverySkill
- project-documentationSkill
- project-evidence-reviewSkill
- project-knowledgeSkill
- project-releaseSkill
- project-securitySkill
The file
We split this skill into the rules it gives an agent
1 rule. About 0 are common, 0 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈0
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 8
Read requirements, acceptance criteria, actual code and project tooling.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Project Qa
Read requirements, acceptance criteria, actual code and project tooling. Define and run relevant build/lint/type/unit/integration and E2E checks in the authorized environment. E2E is a real consumer journey through the affected boundaries: browser/device, API-to-persistence, CLI or library consumption as appropriate. Include meaningful negative/auth/error paths. Distinguish mocks from live dependencies; skipped required E2E blocks pre-push acceptance. Preserve unrelated work. Test fixtures/generated evidence may be written only to agreed locations; do not change production source to hide failures. Avoid broad costly checks, installers and production/third-party mutations without applicable authority. Report exact commands, environment, current revision/source fingerprint, actual passed/failed/skipped/unverified outcomes and sanitized artifact links under docs/quality/. Never fabricate a pass from another agent's claim. Send reproductions to the owning worker, rerun affected checks after fixes and inspect integrated behavior. Optional record validators do not prove tests ran. If execution is unavailable, report missing capability and keep required verification blocked.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.