custom-rebase
Guide for rebasing feature branches onto main in the Fusion Framework monorepo, including handling pnpm-lock.yaml conflicts
73
58%
Does it follow best practices?
Impact
97%
1.42xAverage score across 3 eval scenarios
Advisory
Suggest reviewing before use
Optimize this skill with Tessl
npx tessl skill review --optimize ./.agents/skills/custom-rebase/SKILL.mdQuality
Discovery
54%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
The description identifies a clear, narrow niche (rebasing in a specific monorepo with pnpm lock file conflicts) and uses natural developer terminology. However, it lacks an explicit 'Use when...' clause and could be more specific about the concrete actions or steps it covers beyond the general concept of rebasing and conflict handling.
Suggestions
Add an explicit 'Use when...' clause, e.g., 'Use when the user needs to rebase a feature branch onto main, encounters pnpm-lock.yaml merge conflicts, or asks about git rebase workflows in the Fusion Framework monorepo.'
List more specific concrete actions covered, e.g., 'Walks through resolving pnpm-lock.yaml merge conflicts by regenerating the lockfile, handling rebase --continue, and verifying dependency integrity after rebase.'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (rebasing feature branches onto main) and mentions a specific action (handling pnpm-lock.yaml conflicts), but doesn't list multiple concrete steps or actions beyond the general 'rebasing' and 'handling conflicts'. | 2 / 3 |
Completeness | Describes what it does (guide for rebasing with lock file conflict handling) but has no explicit 'Use when...' clause or equivalent trigger guidance, which per the rubric should cap completeness at 2, and the 'what' is also somewhat thin, placing this at 1. | 1 / 3 |
Trigger Term Quality | Contains strong natural trigger terms users would actually say: 'rebasing', 'feature branches', 'main', 'monorepo', 'pnpm-lock.yaml', 'conflicts'. These are terms developers naturally use when encountering this specific workflow problem. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive due to the specific combination of 'Fusion Framework monorepo', 'rebasing onto main', and 'pnpm-lock.yaml conflicts'. This is unlikely to conflict with other skills given its narrow, project-specific scope. | 3 / 3 |
Total | 9 / 12 Passed |
Implementation
62%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill provides excellent actionability with concrete, executable commands for every step and a well-structured multi-step workflow with proper validation checkpoints. However, it is significantly over-verbose — repeating the same conflict resolution pattern in the workflow, checklist, and example sections, and including explanatory sections (like 'Why Regenerate pnpm-lock.yaml?') that explain concepts Claude already understands. The monolithic structure would benefit from splitting reference material into separate files.
Suggestions
Remove the 'Why Regenerate pnpm-lock.yaml?' section entirely — Claude understands dependency resolution and lockfile semantics.
Consolidate the repeated conflict resolution instructions: the workflow steps, checklist, and complete example all repeat the same pnpm-lock.yaml resolution pattern. Keep one authoritative version.
Move the troubleshooting section and reporting steps (9-10) into separate referenced files (e.g., TROUBLESHOOTING.md, REPORTING.md) to reduce the main skill's token footprint.
Remove explanatory phrases like 'This skill helps you...' and 'The lockfile contains exact dependency resolutions for the entire monorepo' — these add no actionable value for Claude.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is excessively verbose at ~250 lines. It explains why pnpm-lock.yaml needs regeneration (Claude knows this), includes a 'Why Regenerate pnpm-lock.yaml?' section explaining basic dependency resolution concepts, repeats the same conflict resolution steps multiple times (in workflow, checklist, example, and troubleshooting), and the reporting/summary steps (9-10) add significant bulk for what could be brief references. | 1 / 3 |
Actionability | The skill provides fully executable, copy-paste-ready bash commands throughout. Every step has concrete commands with specific flags and paths, and the complete example flow at the end ties everything together with real branch names and exact command sequences. | 3 / 3 |
Workflow Clarity | The 10-step workflow is clearly sequenced with explicit validation checkpoints (step 6 'git status' verification, step 8 sanity check vs remote with diff commands, dry-run push). It includes feedback loops for conflict resolution (fix → validate → continue), abort/skip escape hatches, and a comprehensive checklist. The 'Version Packages' commit handling includes clear decision criteria. | 3 / 3 |
Progressive Disclosure | The content is largely monolithic — everything is inline in one long file. The reporting sections (steps 9-10) reference scripts in `.agents/skills/custom-rebase/scripts/` but no bundle files are provided. The 'Why Regenerate pnpm-lock.yaml?' and troubleshooting sections could be split out. The 'Related Skills' reference at the end is a good touch but insufficient to offset the wall-of-text structure. | 2 / 3 |
Total | 9 / 12 Passed |
Validation
100%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
- Repository
- equinor/fusion-framework
- Commit
060e3af
- Reviewed
Table of Contents
Is this your skill?
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.