| name | tendril-review |
| description | Comprehensive post-change review of all modified files. Checks for code smells, cleanup opportunities, unnecessary legacy support, missing tests, broken tests, and obsolete tests. Use after a big change to leave the codebase in better health. |
tendril-review
Perform a thorough review of all changes in the current working tree (or a specified branch/PR). The goal is to leave every touched file in better code health than before.
Invocation
/tendril-review
No arguments required — operates on the current git diff against the base branch.
What This Skill Does
- Identifies ALL changed files (staged, unstaged, and committed on branch)
- Reviews each file for code smells, cleanup opportunities, and quality issues
- Flags unnecessary legacy/backwards-compatibility code (asks before removing)
- Checks test coverage — missing tests, broken tests, obsolete tests
- Runs the test suite and reports failures
- Produces actionable recommendations
Execution Steps
Phase 1 — Scope the Changes
- Run
git diff --name-only against the base branch to get all changed files
- Run
git status to capture any uncommitted changes
- Categorize files: source code, tests, config, promptware, other
- Flag any files that seem unrelated to the main change — ask the user if there's confusion about why they changed
Phase 2 — Code Quality Review
For each changed source file:
- Read the full file content
- Check for:
- Dead code or unused imports
- Code duplication
- Overly complex methods (consider cyclomatic complexity)
- Poor naming or unclear intent
- Missing error handling at system boundaries
- Inconsistent patterns vs. the rest of the codebase
- Unnecessary abstractions or over-engineering
- Legacy/backwards-compatibility code that may no longer be needed
Important: For any legacy support or backwards-compatibility code identified for removal — ASK the user before removing. Do not auto-delete.
Phase 3 — Test Review
- Identify tests related to changed code
- Run the full test suite:
dotnet test (or appropriate command)
- Report:
- Failing tests — investigate root cause
- Missing tests — suggest what should be covered
- Obsolete tests — tests that exercise removed/changed behavior and are no longer relevant
- For obsolete tests — ASK the user before suggesting removal
Phase 4 — Summary Report
Produce a structured report:
## Review Summary
### Changes Reviewed
- List of all files reviewed, grouped by category
### Issues Found
- [ ] Issue 1 — severity, file, description
- [ ] Issue 2 — ...
### Cleanup Opportunities
- [ ] Opportunity 1 — what and why
### Legacy Code Questions
- [ ] "This code appears to exist for backwards compat with X — still needed?"
### Test Status
- Passing: N
- Failing: N (with details)
- Missing coverage: list
- Potentially obsolete: list
### Recommendations
Prioritized list of actions to take
Principles
- Leave it better than you found it — every touched file should improve in code health
- Ask, don't assume — when in doubt about whether something is still needed, ask
- Unrelated changes are normal — the user may have made parallel manual edits; clarify rather than flag as errors
- Be thorough — this is a big change review, not a quick scan
