harden
This skill contains shell command directives (!`command`) that may execute system commands. Review carefully before installing.
Harden
Target: $ARGUMENTS (file, directory, or module — if blank, use unstaged changes)
Pre-loaded context
- Test runner: !
node -e "const p=require('./package.json'); console.log(p.scripts?.test || 'none')" - Unstaged changes: !
git diff --name-only
Workflow
1. Scope
Identify target files. If $ARGUMENTS is blank, use unstaged changed files.
- Read each target file
- Read its existing test file (co-located
*.test.tsor__tests__/) - If no test file exists, note it
2. Audit
For each file, list findings in three buckets:
| Bucket | What to look for |
|---|---|
| Split | Functions > 20 lines, multiple responsibilities, deeply nested logic (> 2 levels), God functions doing I/O + logic |
| Edge cases | Missing null/empty/boundary checks at system boundaries, unhandled error paths, implicit assumptions |
| Test gaps | Untested public functions, branches with no coverage, missing sad-path tests |
Present the audit as a checklist. Ask via AskUserQuestion (multiSelect): "Which items should I address?" — list each finding as an option, with "All items" as first option marked (Recommended).
3. Harden (TDD loop per item)
For each approved item, apply red-green-refactor:
RED: Write a failing test that exposes the gap
GREEN: Minimal code change to pass
REFACTOR: Extract/simplify if the fix introduced complexity
One item at a time. Run tests after each cycle. Never batch.
Splitting rules:
- Extract pure logic into named helpers — keep I/O at the edges
- New functions must be testable through public interface when possible
- Preserve the original function's signature (no breaking changes)
Test rules:
- Test behavior, not implementation
- Each test gets a descriptive name:
it('returns empty array when input is null') - Prefer real values over mocks; mock only external I/O
4. Verify
- Run full test suite
- Confirm no regressions
- Report summary: items addressed, tests added, functions extracted
Output format
## Hardening Report
### Audit
- [ ] Split: `processOrder` (45 lines, validation + persistence + notification)
- [ ] Edge: `parseConfig` — no handling for missing file
- [ ] Test: `formatOutput` — zero test coverage
### Changes
- Extracted `validateOrder()` from `processOrder()` (+1 fn, +3 tests)
- Added null-guard to `parseConfig` (+2 tests)
- Backfilled `formatOutput` tests (+4 tests)
### Result
Tests: 42 passed (was 35) | 0 failed
Rules
- Never change external behavior — hardening is internal improvement
- If splitting a function would require changing its public API, flag it and ask before proceeding
- Always run tests between items — stop if anything breaks
- Skip files with zero test infrastructure unless user explicitly asks to set it up
Error Handling
- If no test runner found → ask user which runner to use before proceeding
- If test suite fails before hardening → report failures and stop; don't harden broken code
- If a split introduces a regression → revert that split immediately, note it as blocked
- If target file has no exports (script/entrypoint) → audit only, skip test backfill unless user confirms
More from helderberto/skills
explain-code
Explains code with visual diagrams and analogies. Use when explaining how code works, teaching about a codebase, or when the user asks "how does this work?" Don't use for modifying code, fixing bugs, or generating new implementations.
45ship
Commit and push changes using atomic commits. Use when user asks to "ship", "commit and push", or requests committing and pushing changes. Don't use for creating pull requests or reviewing changes before committing.
45refactor-plan
Create structured refactoring plans. Use when user wants to plan a refactor, needs a refactoring strategy, or mentions breaking down large changes into small commits. Don't use for implementing code changes directly, small one-line fixes, or renaming a single variable.
44safe-repo
Check for sensitive data in repository. Use when user asks to "check for sensitive data", "/safe-repo", or wants to verify no company/credential data is in the repository. Don't use for general code review, adding .gitignore entries, or scanning non-git directories.
41perf-audit
Audit frontend bundle size and performance. Use when user asks to "audit performance", "/perf-audit", "analyze bundle", "check bundle size", or wants to find performance bottlenecks. Don't use for backend performance, database query optimization, or projects without a frontend build step.
29deps-audit
Check dependencies for vulnerabilities. Use when user asks to "audit dependencies", "/deps-audit", "check for vulnerabilities", or wants to check dependency health. Don't use for yarn, pnpm, or bun projects (npm only), or for reviewing code quality.
22