Skip to content
Back to skills

Project Config And Tests

ASecurity

Overlay for config contracts, defaults, path helpers, and deterministic test coverage. Use alongside the repo's principle skill when the main task is config behavior or test coverage.

  • 4 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added May 28, 2026
ai-agentsperformance

Security analysis

A100/100

Scanned May 28, 2026

npx -y skills add n-n-code/n-n-code-skills --skill project-config-and-tests --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Project Config And Tests?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Project Config And Tests
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/n-n-code-project-config-and-tests/badge)](https://www.skillsdirectory.com/skills/n-n-code-project-config-and-tests)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: project-config-and-tests
description: Overlay for config contracts, defaults, path helpers, and deterministic test coverage. Use alongside the repo's principle skill when the main task is config behavior or test coverage.
---

# Project Config And Tests

This is a composable overlay, not a standalone workflow.
Use alongside the repo's principle skill (e.g. **coding-guidance-cpp**) when the
main task is config behavior or test coverage.

## When to use

The task involves config parsing, defaults, path resolution, normalization, or
adding deterministic test coverage around these seams.

## Not for

General feature work (use **project-core-dev**), vendored dependency changes
(use **project-vendor-boundary**), or release/packaging work (use
**project-release-maintainer**).

## Rules

- keep config parsing non-fatal where that preserves recovery/help paths
- keep defaults, example config, and docs aligned
- prefer deterministic tests around parsing, normalization, and helper seams
  using the repo's test framework
- keep WHAT/HOW/WHY commentary current in repo-owned tests
- add benchmarks for performance-sensitive helpers using the repo's benchmark
  framework when available
- use the repo's coverage tooling to verify test coverage for new code when it
  exists; otherwise state the manual or structural evidence used

## Examples

- config default changed but docs/examples still show the old value
- path helper normalization needs deterministic tests across relative,
  absolute, missing, and platform-specific paths

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…