quality-strict

mgreenly's avatarfrom mgreenly

Quality (Strict) skill for the ikigai project

⭐1stars🔀0forks📁View on GitHub🕐Updated Jan 4, 2026
[Testing and QA]

When & Why to Use This Skill

This Claude skill enforces a rigorous, zero-tolerance quality assurance workflow designed for high-stakes software engineering. It automates mandatory pre-commit checks, including 100% code coverage requirements (lines, functions, and branches), code formatting, and comprehensive linting. By integrating dynamic analysis tools like ASan, UBSan, and TSan, it ensures memory safety and thread stability, making it an essential tool for developers aiming for maximum code reliability and technical excellence.

Use Cases

  • Strict Pre-commit Validation: Ensuring that no code is committed unless it passes all tests, meets style guidelines, and satisfies complexity checks.
  • Mission-Critical Coverage Tracking: Achieving and maintaining 100% test coverage across all code paths to eliminate hidden bugs and unverified failure modes.
  • Automated Bug Detection: Using dynamic sanitizers and Valgrind during the development cycle to identify memory leaks, undefined behavior, and race conditions.
  • Standardized Build & Test Orchestration: Managing complex build environments and parallel test execution to optimize local development workflows while maintaining strict quality gates.
namequality-strict
descriptionQuality (Strict) skill for the ikigai project

Quality (Strict)

Description

Strict testing, coverage, and quality requirements for coverage phase. 100% is mandatory.

Pre-Commit Requirements

BEFORE creating ANY commit (mandatory, no exceptions):

  1. make fmt - Format code
  2. make check - ALL tests pass (100%)
  3. make lint - ALL complexity/file size checks pass
  4. make check-coverage - ALL metrics (lines, functions, branches) at 100.0%
  5. make check-dynamic - ALL sanitizer checks pass (ASan, UBSan, TSan)

If ANY check fails: fix ALL issues, re-run ALL checks, repeat until everything passes.

Never commit with ANY known issue - even "pre-existing" or "in another file".

Test Execution

By Default: Tests run in parallel, with 24 parallel tests on this machine.

  • MAKE_JOBS=24 - up to 24 concurrent tests
  • PARALLEL=1 - all 4 check-dynamic subtargets in parallel

When you need clear debug output (serialize execution):

PARALLEL=0 MAKE_JOBS=1 make check
PARALLEL=0 MAKE_JOBS=1 make check-valgrind

Best practice: Test individual files during development, run full suite before commits.

Example:

make build/tests/unit/array/basic_test && ./build/tests/unit/array/basic_test

Build Modes

make BUILD={debug|release|sanitize|tsan|coverage}
  • debug - Development builds with symbols
  • release - Optimized production builds
  • sanitize - Address and undefined behavior sanitizers
  • tsan - Thread sanitizer
  • coverage - Code coverage analysis

Quality Gates

  • Use make check to verify tests while working on code changes
  • Use make lint && make check-coverage before commits - 100% coverage is MANDATORY
  • CRITICAL: Never run multiple make commands simultaneously. Different targets use incompatible compiler flags and will corrupt the build.

Coverage Phase Mindset

  • Every uncovered line is a bug waiting to happen
  • Every untested branch is a failure mode you haven't verified
  • LCOV exclusions are a last resort, not a shortcut
  • Zero tolerance for coverage gaps