phase-gated-commits — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited phase-gated-commits (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.
Break large features and refactoring into discrete phases. Each phase follows a strict implement -> review -> test -> commit cycle. The result is a clean, bisectable git history where every commit represents a working state.
Break the work into 2-5 phases. Each phase should:
| Phase Size | Guideline |
|---|---|
| Too small | Renaming a single variable is not a phase |
| Right size | Add the data model + migration + basic tests |
| Too large | Implement entire feature end-to-end in one phase |
Aim for phases that touch 2-8 files each. If a phase touches more than 10 files, consider splitting it further.
Phase N:
1. IMPLEMENT -- Write the code for this phase only
2. REVIEW -- Self-review the diff, check for issues
3. TEST -- Run tests, verify nothing is broken
4. COMMIT -- Create a single commit for this phase
5. PAUSE -- Wait for user confirmation before Phase N+1Write only the code that belongs to this phase. Do not reach ahead into the next phase. If you realize the current phase needs to be larger, stop and re-scope before continuing.
Review your own diff before committing:
If review finds issues, fix them within the same phase. Do not defer fixes to a later phase.
Run the project test suite. At minimum:
Create one commit per phase with a descriptive message.
Commit message format:
feat(phase N/M): <description of what this phase accomplishes>
<Optional body explaining WHY this phase exists as a separate unit>Examples:
feat(phase 1/3): add user preference data model and migration
Separate from the API layer so the schema can be reviewed independently.
feat(phase 2/3): implement preference API endpoints with validation
Builds on the data model from phase 1. Includes input validation
with zod schemas and error handling for all edge cases.
feat(phase 3/3): add preference UI components and integration tests
Connects the API to the frontend. Integration tests cover the
full create/read/update flow.After committing, pause and confirm with the user before starting the next phase. This gives the user a chance to:
When using this skill alongside plan-documentation:
<task>-phase-N-complete.md) are written after the commit~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.