code-quality-testing

Write runnable code and execute unit tests, integration tests, and linter passes.

3|Updated Jun 29, 2026
One-click install
npx skills add https://github.com/ruskicoder/system-prompts --skill code-quality-testing-ruskicoder
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: code-quality-testing
Source: https://github.com/ruskicoder/system-prompts/tree/main/prompt-orchestrator/.opencode/skills/code-quality-testing
Command: npx skills add https://github.com/ruskicoder/system-prompts --skill code-quality-testing-ruskicoder

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? It prevents shipping broken or untested code by enforcing a systematic workflow for writing runnable code, running test suites, fixing failures, and resolving linter errors before presenting results. ## Core Features & Use Cases - Runnable Code Checklist: Verifies imports, dependencies, type definitions, and API endpoints exist before code is presented. - Testing Practices: Guides unit test structure (one test file per module, mocking external dependencies), integration tests, and the rule of never committing with failing tests. - Debugging & Linting Workflow: Applies a root-cause debugging procedure and a linter-fix loop capped at 3 cycles per file. - Use Case: After implementing a new API endpoint, trigger this Skill to add unit tests for success and failure paths, run the test suite, fix any failures, and resolve linter errors before marking the task complete. ## Quick Start Ask the AI to run the tests for the module you just changed and fix any failing tests or linter errors it finds.

Frequently Asked Questions about code-quality-testing

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I run tests and fix failures before committing code?▼

Run the relevant test suite after making changes, then fix any failures before marking the task complete. The workflow forbids committing while tests fail and requires addressing root causes rather than symptoms.

How to structure unit tests for a codebase?▼

Create one test file per source module, covering core logic, edge cases, and both success and failure paths. Mock external dependencies so tests stay isolated and deterministic.

What should I check before presenting generated code?▼

Verify all imports are present, referenced variables are defined, dependencies are listed in the package manifest, there are no syntax errors, and type definitions match usage. The code must be immediately runnable.

How many times should I retry fixing linter errors?▼

The workflow caps linter-fix attempts at 3 cycles per file. If errors persist after 3 cycles, stop guessing and present the situation to the user with everything known so far.

Why does debugging fail when only fixing symptoms?▼

Fixing symptoms leaves the root cause intact, so bugs resurface. The recommended workflow observes the symptom, gathers data, forms a hypothesis, adds targeted logging to confirm, then applies a minimal verified fix.

When should tests be added before refactoring?▼

Add tests before refactoring whenever coverage is lacking. Refactoring must preserve existing behavior, use small focused commits, and never mix with feature work, so a test safety net is essential.