fai-refactor-plan — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited fai-refactor-plan (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Plan safe, incremental refactoring with risk assessment and regression guards.
# Refactoring Plan — [Area/Module]
## Goal
[What quality improvement are we targeting?]
## Scope
| Item | Current State | Target State | Risk | Priority |
|------|--------------|-------------|------|----------|
| OrderService | 450 lines, CC=15 | <100 lines, CC<5 | Medium | P1 |
| PaymentHandler | No tests | 80% coverage | High | P1 |
| UserController | Mixed concerns | Clean separation | Low | P2 |
## Execution Order
1. Add tests to PaymentHandler (safety net first)
2. Extract methods from OrderService
3. Separate concerns in UserController
## Constraints
- No behavior changes — only structural improvement
- Each PR < 200 lines changed
- All existing tests must pass after each step
- Run integration tests before merge
## Timeline
| Sprint | Items | Validation |
|--------|-------|-----------|
| S1 | Add test coverage for payment | Coverage >= 80% |
| S2 | Extract OrderService methods | CC < 5 per method |
| S3 | Separate UserController | No mixed concerns || Risk Level | Definition | Mitigation |
|---|---|---|
| High | Changes core business logic paths | Add tests FIRST, then refactor |
| Medium | Changes shared utilities | Review blast radius, test consumers |
| Low | Cosmetic or naming changes | Standard PR review |
1. Add tests for current behavior (safety net)
2. Refactor one function/class at a time
3. Run all tests after each change
4. Commit each step separately (easy revert)
5. Repeat until target state reached| Issue | Cause | Fix |
|---|---|---|
| Regression after refactor | No test safety net | Always add tests BEFORE refactoring |
| Scope creep | "While I'm here..." | Stick to plan, log new items separately |
| PR too large | Refactoring in one commit | One extraction per commit |
| Stakeholder pushback | No clear value | Show complexity metrics before/after |
| Practice | Rationale |
|---|---|
| Tests before refactoring | Safety net for behavior preservation |
| One refactoring per commit | Easy to revert specific changes |
| No feature changes mixed in | Separate refactor from feature PRs |
| Measure complexity before/after | Prove improvement objectively |
| Small PRs (< 200 lines changed) | Easier to review thoroughly |
| CI must pass after each step | Catch breakage immediately |
fai-refactor-complexity — Reduce cyclomatic complexityfai-refactor-plan — Multi-sprint refactoring plansfai-code-smell-detector — Automated smell detectionfai-review-and-refactor — Combined review + fix workflow~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.