Skills DirectorySkills Directory
SkillsLearnSecurityCategoriesDocsBlogPro
Sign InSubmit Skill
Skills Directory

Security-tested agent skills for Claude, coding agents, and AI workflows.

Directory

  • Browse Skills
  • All Skills A–Z
  • Claude Skills
  • Claude Code Skills
  • Agent Skills
  • Categories
  • Authors
  • Submit a Skill

Learn

  • Learn Hub
  • Install Claude Skills
  • Write SKILL.md
  • Skills vs MCP
  • Directories Compared

Security

  • Security
  • Methodology
  • Secure Claude Skills
  • Security Badges
  • Chrome Extension
  • Skill Manager

Company

  • About
  • Community
  • Blog
  • API Docs
  • Advertise

2026 Skills Directory. All rights reserved.

ProTermsPrivacyRefunds
Back to skills

Ln 633 Test Value Auditor

ASecurity

Calculates Usefulness Score = Impact (1-5) × Probability (1-5) for each test. Returns KEEP/REVIEW/REMOVE decisions based on thresholds (≥15 KEEP, 10-14 REVIEW, <10 REMOVE).

3 stars
0 votes
0 copies
0 views
Added 9/7/2026
testinggobashtestingsecurity

Security Analysis

A100/100

Scanned 9/7/2026

$npx -y skills add levalencia/agent-god-mode --skill ln-633-test-value-auditor --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Ln 633 Test Value Auditor?

Add the live security badge to your README — it updates automatically with every re-scan.

Security grade badge for Ln 633 Test Value Auditor
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/levalencia-ln-633-test-value-auditor/badge)](https://www.skillsdirectory.com/skills/levalencia-ln-633-test-value-auditor)

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

Download with Pro
Files
SKILL.md
---
name: ln-633-test-value-auditor
description: Calculates Usefulness Score = Impact (1-5) × Probability (1-5) for each test. Returns KEEP/REVIEW/REMOVE decisions based on thresholds (≥15 KEEP, 10-14 REVIEW, <10 REMOVE).
allowed-tools: Read, Grep, Glob, Bash
license: MIT
---

> **Paths:** File paths (`shared/`, `references/`, `../ln-*`) are relative to skills repo root. If not found at CWD, locate this SKILL.md directory and go up one level for repo root.

# Risk-Based Value Auditor (L3 Worker)

Specialized worker calculating Usefulness Score for each test.

## Purpose & Scope

- **Worker in ln-630 coordinator pipeline**
- Audit **Risk-Based Value** (Category 3: Critical Priority)
- Calculate Usefulness Score = Impact × Probability
- Make KEEP/REVIEW/REMOVE decisions
- Calculate compliance score (X/10)

## Inputs (from Coordinator)

**MANDATORY READ:** Load `shared/references/audit_worker_core_contract.md`.

Receives `contextStore` with: `tech_stack`, `testFilesMetadata`, `codebase_root`, `output_dir`.

## Workflow

**MANDATORY READ:** Load `shared/references/two_layer_detection.md` for detection methodology.

1) **Parse Context:** Extract tech stack, Impact/Probability matrices, test file list, output_dir from contextStore
2) **Calculate Scores (Layer 1):** For each test: calculate Usefulness Score = Impact x Probability
2b) **Context Analysis (Layer 2 — MANDATORY):** Before finalizing REMOVE decisions, ask:
   - Is this a regression guard for a known past bug? → **KEEP** regardless of Score
   - Does this test cover a critical business rule (payment, auth) even if Score<10? → **REVIEW**, not REMOVE
   - Is this the only test covering an edge case in a critical flow? → **KEEP**
3) **Classify Decisions:** KEEP (>=15), REVIEW (10-14), REMOVE (<10)
4) **Collect Findings:** Record each REVIEW/REMOVE decision with severity, location (file:line), effort estimate (S/M/L), recommendation
5) **Calculate Score:** Count violations by severity, calculate compliance score (X/10)
6) **Write Report:** Build full markdown report in memory per `shared/templates/audit_worker_report_template.md`, write to `{output_dir}/633-test-value.md` in single Write call
7) **Return Summary:** Return minimal summary to coordinator (see Output Format)

## Usefulness Score Calculation

### Formula

```
Usefulness Score = Business Impact (1-5) × Failure Probability (1-5)
```

### Impact Scoring (1-5)

| Score | Impact | Examples |
|-------|--------|----------|
| **5** | **Critical** | Money loss, security breach, data corruption |
| **4** | **High** | Core flow breaks (checkout, login, registration) |
| **3** | **Medium** | Feature partially broken, degraded UX |
| **2** | **Low** | Minor UX issue, cosmetic bug |
| **1** | **Trivial** | Cosmetic issue, no user impact |

### Probability Scoring (1-5)

| Score | Probability | Indicators |
|-------|-------------|------------|
| **5** | **Very High** | Complex algorithm, new technology, many dependencies |
| **4** | **High** | Multiple dependencies, concurrency, edge cases |
| **3** | **Medium** | Standard CRUD, framework defaults, established patterns |
| **2** | **Low** | Simple logic, well-established library, trivial operation |
| **1** | **Very Low** | Trivial assignment, framework-generated, impossible to break |

### Decision Thresholds

| Score Range | Decision | Action |
|-------------|----------|--------|
| **≥15** | **KEEP** | Test is valuable, maintain it |
| **10-14** | **REVIEW** | Consider if E2E already covers this |
| **<10** | **REMOVE** | Delete test, not worth maintenance cost. **Exception:** regression guards for known bugs → KEEP. Tests covering critical business rules (payment, auth) → REVIEW |

## Scoring Examples

### Example 1: Payment Processing Test

```
Test: "processPayment calculates discount correctly"
Impact: 5 (Critical — money calculation)
Probability: 4 (High — complex algorithm, multiple payment gateways)
Usefulness Score = 5 × 4 = 20
Decision: KEEP
```

### Example 2: Email Validation Test

```
Test: "validateEmail returns true for valid email"
Impact: 2 (Low — minor UX issue if broken)
Probability: 2 (Low — simple regex, well-tested library)
Usefulness Score = 2 × 2 = 4
Decision: REMOVE (likely already covered by E2E registration test)
```

### Example 3: Login Flow Test

```
Test: "login with valid credentials returns JWT"
Impact: 4 (High — core flow)
Probability: 3 (Medium — standard auth flow)
Usefulness Score = 4 × 3 = 12
Decision: REVIEW (if E2E covers, remove; else keep)
```

## Audit Rules

### 1. Calculate Score for Each Test

**Process:**
- Read test file, extract test name/description
- Analyze code under test (CUT)
- Determine Impact (1-5)
- Determine Probability (1-5)
- Calculate Usefulness Score

### 2. Classify Decisions

**KEEP (≥15):**
- High-value tests (money, security, data integrity)
- Core flows (checkout, login)
- Complex algorithms

**REVIEW (10-14):**
- Medium-value tests
- Question: "Is this already covered by E2E?"
- If yes → REMOVE; if no → KEEP

**REMOVE (<10):**
- Low-value tests (cosmetic, trivial)
- Framework/library tests
- Duplicates of E2E tests

### 3. Identify Patterns

**Common low-value tests (<10):**
- Testing framework behavior
- Testing trivial getters/setters
- Testing constant values
- Testing type annotations

## Scoring Algorithm

**MANDATORY READ:** Load `shared/references/audit_worker_core_contract.md` and `shared/references/audit_scoring.md`.

**Severity mapping by Usefulness Score:**
- Score <5 → CRITICAL (test wastes significant maintenance effort)
- Score 5-9 → HIGH (test likely wasteful)
- Score 10-14 → MEDIUM (review needed)
- Score ≥15 → no issue (KEEP)

## Output Format

**MANDATORY READ:** Load `shared/references/audit_worker_core_contract.md` and `shared/templates/audit_worker_report_template.md`.

Write report to `{output_dir}/633-test-value.md` with `category: "Risk-Based Value"` and checks: usefulness_score, remove_candidates, review_candidates.

Return summary to coordinator:
```
Report written: docs/project/.audit/ln-630/{YYYY-MM-DD}/633-test-value.md
Score: X.X/10 | Issues: N (C:N H:N M:N L:N)
```

**Note:** Tests with Usefulness Score >=15 (KEEP) are NOT included in findings -- only issues are reported.

## Critical Rules

**MANDATORY READ:** Load `shared/references/audit_worker_core_contract.md`.

- **Do not auto-fix:** Report only
- **Effort realism:** S = <1h, M = 1-4h, L = >4h
- **Score objectivity:** Base Impact and Probability on code analysis, not assumptions
- **KEEP tests not reported:** Only REVIEW and REMOVE decisions appear in findings
- **Cross-reference E2E:** REVIEW decisions depend on whether E2E already covers the scenario

## Definition of Done

**MANDATORY READ:** Load `shared/references/audit_worker_core_contract.md`.

- contextStore parsed successfully (including output_dir)
- Usefulness Score calculated for each test (Impact x Probability)
- Decisions classified: KEEP (>=15), REVIEW (10-14), REMOVE (<10)
- Findings collected with severity, location, effort, recommendation
- Score calculated using penalty algorithm
- Report written to `{output_dir}/633-test-value.md` (atomic single Write call)
- Summary returned to coordinator

## Reference Files

- **Audit output schema:** `shared/references/audit_output_schema.md`

---
**Version:** 3.0.0
**Last Updated:** 2025-12-23

Attribution

levalencialevalencia
View sourceSee grades on GitHubMore from levalencia →
SSkills DirectorySkills Directory

Ship a skill? Prove it's safe.

Free 120-pattern security scan, letter grade, and an embeddable README badge.

Submit a skill

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 (0)

No comments yet. Be the first to comment!

SSkills DirectorySkills Directory

Ship a skill? Prove it's safe.

Free 120-pattern security scan, letter grade, and an embeddable README badge.

Submit a skill

Related Skills

Screen Reader Testing

Practical guide to testing web applications with screen readers for comprehensive accessibility validation.

401991 votes

Tdd Workflow

在编写新功能、修复错误或重构代码时使用此技能。强制执行测试驱动开发,包含单元测试、集成测试和端到端测试,覆盖率超过80%。

2456590 votes

Eval Harness

克劳德代码会话的正式评估框架,实施评估驱动开发(EDD)原则

2456590 votes

Python Testing

使用pytest、TDD方法、夹具、模拟、参数化和覆盖率要求的Python测试策略。

2456590 votes

Django Tdd

Django测试策略,包括pytest-django、TDD方法论、factory_boy、模拟、覆盖率以及测试Django REST Framework API。

2456590 votes
View all in testing →