Reconcile the project's FPF state with recent repository changes
43
28%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./plugins/fpf/skills/actualize/SKILL.mdQuality
Discovery
7%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This description is very weak across all dimensions. It relies on an unexplained acronym ('FPF'), uses vague action language ('reconcile'), and completely lacks explicit trigger guidance. A user or Claude would struggle to know when to select this skill or what it concretely does.
Suggestions
Define 'FPF' explicitly and list the concrete actions performed (e.g., 'Updates file path fingerprints by scanning for added, removed, or renamed files in the repository').
Add a 'Use when...' clause with natural trigger terms users would say, such as 'Use when the user mentions syncing project state, updating file tracking after git pulls, or resolving stale file references.'
Include specific file types, commands, or scenarios that distinguish this skill from general repository management or version control skills.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description uses vague language — 'reconcile' and 'FPF state' are abstract and undefined. It does not list any concrete actions (e.g., update files, resolve conflicts, sync configurations). 'FPF' is an unexplained acronym that provides no clarity. | 1 / 3 |
Completeness | The description weakly addresses 'what' (reconcile FPF state) but provides no 'when' clause or explicit trigger guidance. There is no 'Use when...' or equivalent, and the 'what' itself is too vague to be useful. | 1 / 3 |
Trigger Term Quality | The term 'FPF state' is technical jargon that users would almost never naturally say. 'Reconcile' and 'repository changes' are somewhat relevant but too generic. There are no natural trigger keywords a user would use to invoke this skill. | 1 / 3 |
Distinctiveness Conflict Risk | The mention of 'FPF state' is a niche term that would reduce overlap with other skills, but because it's undefined, it's unclear what domain this targets. It could overlap with general git/repo sync or state management skills. | 2 / 3 |
Total | 5 / 12 Passed |
Implementation
50%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill provides a well-structured multi-step workflow for reconciling FPF state with git changes, with a useful concrete output template. However, it falls short on actionability—most steps describe what to do in natural language rather than providing executable code or specific commands. It also lacks validation/error-handling steps for a workflow that modifies state, and could be more concise by trimming conceptual framing.
Suggestions
Add executable code or pseudocode for Steps 2-4 (e.g., how to parse evidence files, extract carrier_ref, and cross-reference with the git diff output) rather than describing the logic in prose.
Add explicit error handling: what to do if .fpf/ directory doesn't exist, if no baseline file is found (beyond 'use initial commit'), or if evidence files are malformed.
Trim the introductory paragraph explaining what the command does conceptually—the step-by-step workflow already makes this clear.
Link or reference supporting bundle files for the FPF schema (evidence file format, DRR format, context.md structure) so Claude knows the exact structure to parse.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is moderately efficient but includes some unnecessary framing (e.g., explaining what the command does conceptually, referencing FPF canonical evolution loop sections). The report template example is lengthy but arguably useful as a concrete output specification. Some tightening is possible. | 2 / 3 |
Actionability | Steps are described clearly but much of the guidance is procedural description rather than executable code. The git commands in Step 1 are concrete, but Steps 2-4 are described in natural language ('Read all evidence files', 'Cross-reference with changed files') without concrete code or specific commands to accomplish these tasks. The baseline file format and report template are helpful concrete artifacts. | 2 / 3 |
Workflow Clarity | The six steps are clearly sequenced and logically ordered, and the report output provides a good checkpoint. However, there are no explicit validation or error-handling steps—e.g., what if .fpf/ doesn't exist, what if git commands fail, what if evidence files have malformed carrier_ref fields. For a workflow that modifies state (.baseline), missing validation caps this at 2. | 2 / 3 |
Progressive Disclosure | The content is reasonably well-structured with clear section headers and a logical flow. However, it's a fairly long monolithic document with no references to supporting files. The detailed report template and baseline file format could potentially be split out. References to other FPF commands (/fpf:decay, /fpf:propose-hypotheses) are mentioned but not linked to actual files. | 2 / 3 |
Total | 8 / 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.
dedca19
Table of Contents
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.