Content
50%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
The skill provides a reasonable workflow for reconciling FPF state with git changes, with good structure and a useful output template. However, it falls short on actionability — the core analysis steps (evidence staleness checking, decision relevance tracing) are described abstractly rather than with concrete, executable logic. The conceptual preamble and lack of error handling/validation checkpoints also weaken the overall quality.
Suggestions
Replace abstract instructions like 'Read all evidence files' and 'Cross-reference with changed files' with concrete code or pseudocode showing how to parse evidence YAML files, extract carrier_ref fields, and compare against the git diff output.
Add error handling for common failure cases: missing .fpf/ directory, missing .baseline file (partially addressed but not robustly), malformed evidence files, and git command failures.
Remove or condense the conceptual preamble paragraph about 'Observe phase' and 'Epistemic Debt' — either link to the spec or omit, as it doesn't help Claude execute the task.
Add links or references to the related commands mentioned (/fpf:decay, /fpf:propose-hypotheses) so Claude can navigate to them when needed.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content includes some unnecessary framing (e.g., explaining what the command does conceptually, referencing FPF phases like 'Observe phase of the FPF Canonical Evolution Loop (B.4)' and 'Epistemic Debt (B.3.4)' which are jargon Claude would need context for anyway). The report example is quite lengthy but serves as a useful template. Could be tightened by removing the conceptual preamble. | 2 / 3 |
Actionability | Steps are described procedurally but mix concrete commands (git diff) with vague instructions ('Read all evidence files', 'Cross-reference with changed files', 'Trace back to source evidence'). The git commands are executable, but the core analysis steps (2-4) are described abstractly without showing how to parse evidence files, check carrier_ref fields, or perform cross-referencing programmatically. | 2 / 3 |
Workflow Clarity | The six steps are clearly sequenced and the overall flow is logical. However, there are no validation checkpoints or error handling — what if .fpf/ doesn't exist? What if git commands fail? What if evidence files are malformed? The user interaction point in Step 2 ('Ask user if they want to update') is good but there's no feedback loop for error recovery. | 2 / 3 |
Progressive Disclosure | The content is well-structured with clear sections, but it's a monolithic document with no references to supporting files despite mentioning related commands ('/fpf:decay', '/fpf:propose-hypotheses') and FPF concepts (B.4, B.3.4) that could be linked. No bundle files are provided, so there's no external structure to leverage, but the references to other commands and spec sections are unlinked. | 2 / 3 |
Total | 8 / 12 Passed |