review-and-commit
by awegg
A modern, declarative, central-pull backup system with native SMB + SSH pull, deduplication, clean include/exclude rules, retention policies, scheduling, a modern web UI, file history + diff, and Docker deployment. This is a modern re-imagining of BackupPC, with a clean config model and a contemporary UI.
Run in ManusSKILL.md
name: review-and-commit description: Semi-automated workflow that runs comprehensive pre-commit review, requires a manual verification pass, auto-fixes safe issues, and commits with a proper message if review passes. Use when user asks to "review and commit", "auto commit", "review then commit", or wants automated review + commit workflow.
Review and Commit
Automated workflow that executes pre-commit review and handles the commit process intelligently based on review results.
Integration with Pre-Commit Review
This skill builds on the pre-commit-review skill:
- Pre-commit-review: Analysis and reporting only
- Review-and-commit: Analysis + auto-fix + commit
Both skills share the same quality standards and review criteria.
Workflow
1. Run Pre-Commit Review (MANDATORY - DO NOT SKIP)
This step MUST be executed first before any other actions. Do not proceed to staging/committing without completing this step.
Execute the comprehensive pre-commit-review skill to analyze all changes:
Invoke the pre-commit-review skill
This performs:
- Automated change analysis
- Test execution with coverage verification (>50% required)
- Specification alignment check
- Architecture review
- Security and maintainability assessment
Manual code/spec review is REQUIRED: After automated analysis, review changed non-generated files and verify against relevant specs (e.g., specs/001-backup-system/spec.md). For large changesets, prioritize high-risk and behavior-changing files first, then sample lower-risk files; always note any areas not manually inspected. Do not proceed to staging/commit without recording the manual review outcome.
CRITICAL: Block commit if review is not performed. Report findings before proceeding.
2. Process Review Results
Based on review findings, take appropriate action:
❌ If Issues/Errors Found
Automatically fix and retry:
- Analyze each issue and determine fix scope
- Apply safe fixes using standard tools (formatters: prettier/eslint/dotnet format; linters; targeted code edits for clear null/typing/test setup issues)
- Re-run pre-commit review
- Repeat until no issues remain or maximum 3 iterations reached
- Escalate to user for logic/architectural changes or after 3 failed attempts; do not keep auto-retrying
Common auto-fixes:
- Code formatting issues
- Missing dependencies
- Obvious bugs (null checks, type mismatches)
- Test failures with clear causes
- Security issues (exposed secrets, debug code)
⚠️ If Warnings/Suggestions Found
Ask user for guidance:
Present warnings and suggestions clearly, then ask:
- "Should I address these warnings before committing?"
- "Do you want me to implement any of these suggestions?"
Wait for user response before proceeding.
✅ If Review Passes (No Issues/Warnings/Suggestions)
Show pending changes and get confirmation before staging:
- Run
git status --porcelainto show all changes - Run
git diff --statto show change summary - Present the list of files to be committed
- Ask user: "Ready for me to stage these changes? (yes/no)"
- If yes, stage all changes:
git add -A - Ask: "Ready for me to commit the staged changes? (yes/no)"
- If yes:
- Generate proper commit message based on changes
- Commit with generated message
- Report commit hash and summary
3. Generate Commit Message
Create conventional commit message following this format:
<type>(<scope>): <subject>
<body>
<footer>
Type: feat, fix, docs, style, refactor, test, chore, perf
Scope: Component/module affected (optional)
Subject: Concise summary (max 72 chars)
Body: Detailed explanation of what and why (optional, use for significant changes)
Footer: Breaking changes, issue references (optional)
Message Generation Strategy
Analyze changed files and determine:
- Primary type based on change nature
- Scope from affected modules/components
- Concise subject summarizing the change
- Body if changes are complex or need explanation
- Footer for breaking changes or closed issues
Examples:
Simple change:
fix(restic): expand exception filter for repository initialization
Feature addition:
feat(dashboard): add dashboard summary endpoint
- Implement DashboardController with /api/dashboard/summary
- Add DTOs for dashboard data structure
- Integrate storage monitoring and job aggregation
- Calculate health status based on recent backup success
Multiple components:
refactor(tests): improve test infrastructure
- Register IResticClient interface in test factories
- Remove debug logging from ErrorHandlingMiddleware
- Add SchedulingFlowTests for Quartz integration
- Switch E2E factory to real service implementations
Auto-Fix Guidelines
Safe to auto-fix (use tools above, keep behavior unchanged):
- Formatting/linting errors
- Missing using statements/imports
- Obvious null-reference/typing issues
- Test setup problems with clear intent
- Debug code removal
- Exposed secrets/credentials
Decision cues:
- If linter/formatter flags it → auto-fix.
- If failing test has a clear fixture/setup fix → auto-fix and re-run.
- If change alters logic, API, or data contracts → pause and confirm with user.
Require user confirmation:
- Logic changes that affect behavior
- Breaking changes to public APIs
- Database schema modifications
- Performance optimizations with tradeoffs
- Architectural refactoring
Error Handling
STRICT WORKFLOW ENFORCEMENT:
- Review MUST be executed before staging/committing
- If review is not performed, the workflow is invalid and must restart
- Do not skip review steps regardless of perceived urgency
- Block commits until review is complete
Maximum retry attempts for auto-fixes: 3
After 3 failed fix attempts:
- Report all issues that couldn't be auto-fixed
- Provide analysis of why fixes failed
- Suggest manual intervention steps
- Do NOT commit
Usage Examples
Simple workflow:
User: "review and commit"
→ Runs review
→ Passes with no issues
→ Commits: "fix(ui): handle future dates in formatDate"
With auto-fix:
User: "review and commit"
→ Runs review
→ Finds debug logging in middleware
→ Removes debug code automatically
→ Re-runs review
→ Passes
→ Commits: "fix(middleware): remove debug logging"
With suggestions:
User: "review and commit"
→ Runs review
→ Finds suggestions for refactoring
→ Asks: "Should I implement these suggestions before committing?"
→ User: "no, commit as is"
→ Commits current changes
Integration with Pre-Commit Review
This skill leverages the pre-commit-review skill but adds automation:
- Pre-commit-review: Analysis and reporting only
- Review-and-commit: Analysis + auto-fix + commit
Both skills share the same quality standards and review criteria.
Score
Total Score
Based on repository quality metrics
SKILL.mdファイルが含まれている
ライセンスが設定されている
100文字以上の説明がある
GitHub Stars 100以上
3ヶ月以内に更新がある
10回以上フォークされている
オープンIssueが50未満
プログラミング言語が設定されている
1つ以上のタグが設定されている
Reviews
Reviews coming soon