ln-637-test-structure-auditor
Audits test maintainability and structure: layout drift, orphan tests, fragmented duplicates, test-to-source mapping, and domain grouping. Use when auditing test suite organization.
What this skill does
> **Paths:** File paths (`references/`, `../ln-*`) are relative to this skill directory.
# Maintainability/Structure Auditor (L3 Worker)
**Type:** L3 Worker
Specialized worker auditing test file organization, orphan tests, fragmented duplicates, and layout drift for maintainability as the test suite grows.
## Purpose & Scope
- Audit **Test Maintainability/Structure** (Category 8: Medium Priority)
- Detect layout pattern (flat / mirrored / co-located / hybrid)
- Flag flat directories exceeding growth thresholds with domain grouping recommendations
- Verify test-to-source mapping consistency, orphaned tests, and fragmented duplicates
- Emit `MOVE`, `MERGE`, or `DELETE_ORPHAN`
- Calculate compliance score (X/10)
## Inputs
**MANDATORY READ:** Load `references/audit_worker_core_contract.md`.
Receives `contextStore` with: `tech_stack`, `testFilesMetadata` (ALL types -- both automated and manual), `codebase_root`, `output_dir`, `domain_mode`, `all_domains`.
**Note:** Unlike other workers that receive type-filtered metadata, this worker receives ALL test files because directory structure analysis requires the full picture of where both automated and manual tests are placed.
## Workflow
Detection policy: use two-layer detection (candidate scan, then context verification); load `references/two_layer_detection.md` only when the verification method is ambiguous.
1) **Parse Context:** Extract test file list, output_dir, codebase_root, domain info from contextStore
2) **Map Source Structure:** Glob source directories (`src/`, `app/`, `lib/`) to build source domain/module tree
3) **Map Test Structure:** Group test files by parent directory, count files per directory, classify locations
4) **Scan Checks (Layer 1):** Run 6 audit checks (see Audit Rules) using Glob/Grep patterns
5) **Context Analysis (Layer 2 -- MANDATORY):** For each candidate finding, apply Layer 2 filters (see each check)
6) **Collect Findings:** Record violations with severity, location, effort, action, recommendation
7) **Calculate Score:** Count violations by severity, calculate compliance score (X/10)
8) **Write Report:** Build full markdown report in memory per `references/templates/audit_worker_report_template.md`, write to `{output_dir}/ln-637--global.md` in single Write call
9) **Return Summary:** Return minimal summary to coordinator (see Output Format)
## Audit Rules
### 1. Layout Pattern Detection
**What:** Detect which test organization pattern the project uses and check for unintentional mixing
**Detection:**
- Classify each test file location:
- **Co-located:** test file in same directory as source file (e.g., `src/users/users.test.ts`)
- **Mirrored:** test file in parallel hierarchy (e.g., `tests/users/users.test.ts` mirrors `src/users/`)
- **Centralized-flat:** all tests in single directory (e.g., `tests/` or `__tests__/`)
- **Manual:** files in `tests/manual/` (informational, not flagged)
- Calculate distribution percentages across patterns
- If >70% files follow one pattern -> that is the dominant pattern
- If no pattern reaches 70% -> hybrid
**Layer 2:**
- Hybrid is acceptable if different test TYPES use different patterns (e.g., unit tests co-located + integration tests in `tests/automated/integration/`). Check if deviation correlates with test type
- Projects with <5 test files -> skip (too small to establish pattern)
**Severity:** **MEDIUM** if hybrid without clear type-based rule (>30% of same-type tests deviate from dominant pattern)
**Recommendation:** Standardize test placement -- choose one pattern per test type and document in testing guidelines
**Action:** `MOVE`
**Effort:** L
### 2. Test-to-Source Mapping
**What:** Detect orphaned test files (source file deleted but test remains) and mismatched paths
**Detection:**
- For each test file, extract the implied source module:
- `users.test.ts` -> `users.ts` or `users/index.ts`
- `test_payments.py` -> `payments.py`
- Check if the implied source file exists in the expected location
- If source file not found -> orphaned test candidate
**Layer 2:**
- Skip integration/e2e tests (test multiple modules, no 1:1 source mapping)
- Skip tests in centralized-flat layout (no path-based mapping expected)
- Skip test files that import from multiple source modules (integration tests by nature)
- Skip utility/helper test files (`test_utils.ts`, `test_helpers.py`)
**Severity:** **MEDIUM** for orphaned tests (dead code), **LOW** for path mismatches
**Recommendation:** Delete orphaned tests or update to match current source structure
**Action:** `DELETE_ORPHAN` when the source behavior no longer exists; otherwise `MOVE`
**Effort:** S
### 3. Flat Directory Growth
**What:** Detect test directories with excessive file count that would benefit from subdirectory grouping
**Detection:**
- Count test files per directory (excluding `node_modules`, `dist`, `build`)
- Thresholds:
- 15-20 files in one flat directory -> LOW (approaching limit)
- \>20 files in one flat directory -> MEDIUM (restructure recommended)
- For MEDIUM findings, suggest domain-based grouping by analyzing file name prefixes:
- Group by common prefix (e.g., `test_auth_*.py` -> `auth/` subdirectory)
- Cross-reference with source domain structure if available
**Layer 2:**
- Skip if directory already has subdirectories (partially organized)
- Skip if files use clear naming prefixes that provide sufficient organization without subdirectories
- Skip `tests/manual/` (manual test structure has separate conventions)
**Severity:** **MEDIUM** (>20 files), **LOW** (15-20 files)
**Recommendation:** Group tests into subdirectories by domain/feature. Suggest specific grouping based on file name analysis:
```
# Before (flat):
tests/test_auth_login.py, tests/test_auth_tokens.py, tests/test_users_crud.py, ...
# After (grouped):
tests/auth/test_login.py, tests/auth/test_tokens.py, tests/users/test_crud.py, ...
```
**Effort:** M
**Action:** `MOVE`
### 4. Domain Grouping Alignment
**What:** Check whether test directory grouping mirrors source domain structure
**Detection:**
- Compare source domain directories (from `all_domains` or scanned `src/`) with test directory names
- For each source domain, check if a corresponding test group exists:
- Mirrored layout: `tests/{domain}/` directory exists
- Co-located: test files exist in `src/{domain}/`
- Flag source domains with zero corresponding test groups
**Layer 2:**
- Skip if project has no clear domain structure (`domain_mode="global"` or <2 source domains)
- Skip references/common/utils domains (cross-cutting, may not need dedicated test group)
- Skip if project uses centralized-flat layout (no grouping expected)
**Severity:** **MEDIUM** for domains with >5 source files but no test group, **LOW** otherwise
**Recommendation:** Create test directory/group for domain to maintain structural alignment
**Effort:** M
**Action:** `MOVE`
### 5. Co-location Consistency
**What:** Detect which co-location pattern the project uses and flag inconsistencies
**Detection:**
- Count test files placed next to source files vs. in dedicated test directories
- Calculate ratio: co-located / (co-located + centralized)
- If ratio 0.0-0.2 -> centralized pattern
- If ratio 0.8-1.0 -> co-located pattern
- If ratio 0.2-0.8 -> mixed (potential inconsistency)
- For mixed: identify which modules deviate from the dominant pattern
**Layer 2:**
- Mixed is acceptable if different test types use different placement:
- Unit tests co-located + integration/e2e tests centralized -> valid hybrid
- Check test file naming/location correlation with type
- Projects with <5 test files -> skip
**Severity:** **MEDIUM** if >20% of same-type tests deviate from dominant placement pattern
**Recommendation:** Consolidate test placement -- move deviating tests to follow the project's dominant pattern
**Effort:** M-L
**Action:** `MOVE`
### 6. Fragmented Duplicates
**What:** Detect duplicate or near-duplicate tests scattered acrRelated in Code Review
gstack
IncludedFast headless browser for QA testing and site dogfooding. Navigate pages, interact with elements, verify state, diff before/after, take annotated screenshots, test responsive layouts, forms, uploads, dialogs, and capture bug evidence. Use when asked to open or test a site, verify a deployment, dogfood a user flow, or file a bug with screenshots. (gstack)
startup-due-diligence
IncludedLegal due diligence review for seed-stage and Series A startups (US, Delaware C-Corp focus). Supports both investor and founder perspectives. Capabilities include: (1) Interactive document review and issue spotting; (2) Document request list generation; (3) Cap table and SAFE/convertible note analysis; (4) Red flag identification with severity ratings; (5) Diligence report generation. TRIGGERS: due diligence, DD, startup investment, cap table review, Series A, seed round, investor diligence, legal review startup, SAFE analysis, convertible note, 409A, founder vesting.
interview-master
IncludedThis skill should be used when the user asks to "generate interview questions", "prepare for interview", "optimize resume", "conduct mock interview", "analyze git commits for resume", "generate resume from code", "review my resume", or mentions interview preparation, career assistance, or extracting project experience from git history. Provides comprehensive interview and career development guidance for both job seekers and interviewers.
fix-issue
IncludedFixes GitHub issues using parallel analysis agents for root cause investigation, code exploration, and regression detection. Reads issue context from gh CLI, searches codebase and memory for related patterns, generates a fix with tests, and links the resolution back to the issue via PR. Includes prevention analysis to avoid recurrence. Use when debugging errors, resolving regressions, fixing bugs, or triaging issues.
sf-apex
IncludedGenerates and reviews Salesforce Apex code with 150-point scoring. TRIGGER when: user writes, reviews, or fixes Apex classes, triggers, test classes, batch/queueable/schedulable jobs, or touches .cls/.trigger files. DO NOT TRIGGER when: LWC JavaScript (use sf-lwc), Flow XML (use sf-flow), SOQL-only queries (use sf-soql), or non-Salesforce code.
swift-development
IncludedComprehensive Swift development for building, testing, and deploying iOS/macOS applications. Use when Claude needs to: (1) Build Swift packages or Xcode projects from command line, (2) Run tests with XCTest or Swift Testing framework, (3) Manage iOS simulators with simctl, (4) Handle code signing, provisioning profiles, and app distribution, (5) Format or lint Swift code with SwiftFormat/SwiftLint, (6) Work with Swift Package Manager (SPM), (7) Implement Swift 6 concurrency patterns (async/await, actors, Sendable), (8) Create SwiftUI views with MVVM architecture, (9) Set up Core Data or SwiftData persistence, or any other Swift/iOS/macOS development tasks.