status-reconciliation
Reconciles project status tracking documents against the actual codebase and git history to fix stale or inconsistent records. Verifies claimed statuses via filesystem checks, git log inspection, and downstream artifact audits. Use when planning a sprint, auditing project progress, fixing summary-detail count drift, or validating that status documents reflect merged PRs and completed work.
89
86%
Does it follow best practices?
Impact
93%
1.02xAverage score across 3 eval scenarios
Passed
No known issues
Quality
Discovery
100%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 is an excellent skill description that clearly articulates specific capabilities (reconciling status documents, filesystem checks, git log inspection, artifact audits) and provides explicit trigger guidance via a well-constructed 'Use when' clause. The description is concise, uses third person voice throughout, and includes natural trigger terms that cover multiple realistic use scenarios.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: reconciles status tracking documents against codebase, verifies claimed statuses via filesystem checks, git log inspection, and downstream artifact audits. These are detailed, actionable capabilities. | 3 / 3 |
Completeness | Clearly answers both what (reconciles project status tracking documents against codebase and git history, verifies statuses via filesystem checks/git log/artifact audits) and when (explicit 'Use when' clause covering sprint planning, auditing progress, fixing count drift, validating status documents). | 3 / 3 |
Trigger Term Quality | Includes strong natural trigger terms users would say: 'sprint', 'project progress', 'status documents', 'merged PRs', 'completed work', 'summary-detail count drift', 'git history'. These cover a good range of how users would describe this need. | 3 / 3 |
Distinctiveness Conflict Risk | Occupies a very specific niche: reconciling project status documents against actual codebase/git state. The combination of status tracking, git history verification, and artifact auditing is distinctive and unlikely to conflict with general git or documentation skills. | 3 / 3 |
Total | 12 / 12 Passed |
Implementation
72%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
A well-structured and concise skill that clearly identifies the problem domain and common failure modes. Its main weakness is the lack of concrete, executable examples—showing a before/after reconciliation or specific command sequences would significantly improve actionability. The workflow would also benefit from an explicit validation/review checkpoint before committing changes.
Suggestions
Add a concrete example showing a before/after snippet of a status document reconciliation (e.g., summary table with wrong counts → corrected version)
Include executable command examples beyond just `git log --oneline -- <path>`, such as a shell snippet that counts ✅ entries or a glob pattern example
Add an explicit validation checkpoint step (e.g., 'Before committing: diff the original and corrected document, verify all three count sources now agree')
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Every section earns its place. No unnecessary explanations of what git or status documents are. The 'Common Traps' section provides genuinely non-obvious failure modes that Claude wouldn't inherently know about (like summary-detail drift patterns). Lean and efficient throughout. | 3 / 3 |
Actionability | Provides some concrete guidance (e.g., `git log --oneline -- <path>`, `glob` for file searching) but lacks executable code examples. The steps are described rather than demonstrated with copy-paste ready commands or scripts. No example input/output showing what a reconciliation looks like in practice. | 2 / 3 |
Workflow Clarity | Steps are clearly sequenced (read → verify filesystem → verify git → check artifacts → reconcile counts → check groupings), but there are no explicit validation checkpoints or feedback loops. For a task involving potentially destructive edits to tracking documents, there should be a verify-before-committing step or a diff review checkpoint. | 2 / 3 |
Progressive Disclosure | For a skill under 50 lines with a single focused task, the content is well-organized into clear sections (When to Use, Pattern, Common Traps, Output). No need for external references, and the structure supports easy scanning. | 3 / 3 |
Total | 10 / 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
- FritzAndFriends/BlazorWebFormsComponents
- Commit
1bd9b17
- 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.