Content
75%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.
Highly actionable content: the task-file template is complete, concrete, and copy-paste ready, and the status-derivation and DoD-tuple rules give real contract teeth. Weaknesses are trimmable backstory and soft framing text that dilute token efficiency, and a write-a-task flow that is implied by section order rather than explicitly sequenced.
Suggestions
Move the 2026-08-27 migration backstory (trigger-pos scoring history, AGENTS.md provenance) out of the body or into a clearly labeled history/deprecated note — it is organizational context, not instructions for writing tasks.
Replace the generic "What is GODS?" framing bullets ("Makes the task transparent and understandable...", "Does not replace flexible processes...") with one or two sentences of when-to-use guidance, keeping only what Claude cannot infer.
Add a short ordered "How to write a task" sequence (resolve the `tasks` role from project instructions → copy the template → fill sections → verify every DoD item has the FR-ID/test/evidence tuple) so the workflow is explicit rather than assembled from scattered sections.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The template and field rules are dense and earn their tokens, but the body pads with fluffy framing ("Makes the task transparent and understandable for executors and clients") and an inline provenance digression ("Moved here from the project instruction template on 2026-08-27 ... scored 0/3 with 13, 16 and 27 tool calls") — time-sensitive history outside any deprecated/old-patterns section, which the guidelines penalize. Fits the mostly-efficient anchor: not 2 because the core template guidance is tight, not 4 because the backstory paragraph and generic bullets are clearly trimmable. | 3 / 5 |
Actionability | The fenced markdown template is copy-paste ready with concrete conventions — "<YYYY>/<MM>/<slug>.md, kebab-case slug, max 40 chars", "Test: `path/to/test>::<test_name>`", "Evidence: `<command that passes iff the item is done>`" — and four worked examples cover incident, operational, development, and product-request cases. Matches the fully-executable anchor; not 4 because there is no material gap in the common-case guidance. | 5 / 5 |
Workflow Clarity | Writing a task is a single, unambiguous purpose with a guardrail ("Never edit `status` by hand — commit workflows derive it from the `## Definition of Done` checkbox count"), but the actual flow — resolve the `tasks` role, apply the template, fill sections, verify DoD tuples — is scattered across blocks with no ordered steps or final checklist; the missing-validation cap does not apply since the skill involves no destructive or batch operations. Fits the clear-with-minor-gaps anchor: not 3 because sequence and constraints are unambiguous once assembled, not 5 because no explicit step sequence or completion check exists. | 4 / 5 |
Progressive Disclosure | The ~140-line body is well sectioned (framework, template, frontmatter rules, examples) with no nested references, but it exceeds the under-50-line simple-skill case and inlines content — the four examples and the migration backstory — that could live in a separate reference file. Fits the good-structure-minor-gaps anchor; not 5 because the guideline reserves 5-without-references for skills under 50 lines. | 4 / 5 |
Total | 16 / 20 Passed |