Content
77%Weight 40%Scale 1-5Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
The content is well-structured, actionable, and assumes Claude's competence, with a clear validated workflow. Its main weakness is that the two referenced bundle files are missing, so the progressive-disclosure navigation points to nonexistent detail.
Suggestions
Create `references/type-compatibility.md` and `references/migration-patterns.md` (or remove the broken links), since the body delegates key detail to files that do not exist.
Trim minor teaching lines such as 'Use import type for types to enable proper tree-shaking' — assume Claude already knows this.
Inline at least one complete before/after migration example in the body so the skill remains actionable even if the reference is unavailable.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Dense and reference-rich, assuming Claude knows TypeScript/PostHog, with only minor over-explanation (e.g. 'Use import type for types to enable proper tree-shaking') that could be trimmed. | 4 / 5 |
Actionability | Provides executable commands (`pnpm --filter=@posthog/frontend typescript:check`, `hogli build:openapi`, `hogli test`), real import snippets, and a decision table, with minor gaps where full before/after examples are deferred to the reference. | 4 / 5 |
Workflow Clarity | A clear 6-step sequence closes with an explicit verification section (TypeScript check, grep for leftover manual types, run tests) providing the validation checkpoint a batch refactor needs. | 5 / 5 |
Progressive Disclosure | The body signals one-level-deep references to `references/type-compatibility.md` and `references/migration-patterns.md`, but the `references/` directory does not exist, so the navigation is broken and cannot be trusted as written. | 3 / 5 |
Total | 16 / 20 Passed |