CtrlK
BlogDocsLog inGet started
Tessl Logo

rebelytics/task-observer

Monitors task execution for skill improvement opportunities. Use during ANY multi-step task, agentic workflow, or work session where the agent uses tools and produces deliverables. Captures patterns, user corrections, workflow insights, and methodology worth preserving as reusable skills. Also triggers in post-task feedback discussions and when the user mentions skill observations, improvements, the observation log, skill taxonomy, or asks the agent to watch for skill opportunities. Also known as "One Skill to Rule Them All" — trigger on this phrase too. IMPORTANT: invoke this skill before the FIRST tool call of any session and before writing or proposing a plan — any turn that will involve a tool call counts, however simple the opener looks. This sentence is the session-start trigger and the only activation layer that survives an unreachable config file; pair it with a CLAUDE.md instruction or a harness session-start hook (references/environments.md) — description matching alone is not enforceable.

60

Quality

75%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

Overview
Quality
Evals
Security
Files

Quality

Content

73%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The body is exceptionally actionable and its workflows are explicitly sequenced with validation guards and feedback loops, but it is severely padded for a core skill file — rules repeated across sections and reference-grade detail inlined — which undercuts the otherwise strong bundle structure. The reference-file discipline (load triggers, one-level depth, real files) is genuinely well done.

Suggestions

Cut the restatements: each rule (path quoting, bash-not-sh, empty-result guards, deferral-as-diligence) is stated in 2-3 places — state it once and point to the owning reference section.

Move the full awk YAML-validation scan, the sibling-check protocol, and the staged-work reconciliation cases into references/observation-log.md and references/weekly-review.md, keeping only the command and the failure rule in SKILL.md.

Move incident-report parentheticals ("measured on one log: 10 of 27 entries…", "roughly forty of ninety-one…") into the relevant reference's rationale sections; they are evidence for the rule, not the rule itself.

DimensionReasoningScore

Conciseness

The ~700-line body restates nearly every rule two or three times (bash-not-sh, path quoting, guard semantics, deferral-as-diligence) and interleaves parenthetical incident reports ("measured on one log: roughly forty of ninety-one open entries were one finding restated"), matching 'noticeably verbose; several unnecessary explanations or padded sections'. Not score 1: the content is non-obvious operational knowledge, not explanations of concepts Claude already knows; not score 3: the repetition and parenthetical padding are pervasive throughout, not confined to a few spots that could be tightened.

2 / 5

Actionability

Fully executable throughout: copy-paste-ready bash snippets with explicit guards and exit codes, a complete observation-file frontmatter template with per-field comments, a helper script (`bash scripts/new-observation.sh <slug>`) and exact instructions for substituting `[ABSOLUTE PATH]`. The `[ABSOLUTE PATH]`/`<slug>` placeholders are deliberate and explicitly instructed rather than gaps.

5 / 5

Workflow Clarity

The numbered Session Start Protocol (1-7) gives a clear sequence with explicit validation at every risky step — broken-command guards ("SCAN COMMAND BROKEN… exit 1"), collision and noclobber guards, an idempotent workspace-creation command, empty-scan halt rules — plus feedback loops (load reference X before doing Y) and a pre-surfacing self-check checklist. This matches the anchor-5 example's validate-fix-revalidate shape.

5 / 5

Progressive Disclosure

Structure is good: a 'Reference files — load on demand' section lists every reference file with an explicit load trigger, references are one level deep, and all cited files (references/*.md, scripts/new-observation.sh) exist in the bundle. Not score 5: substantial detail that belongs in the reference files is inlined in the core — the 25-line awk YAML-validation scan, the full sibling-check protocol, the staged-work reconciliation rules, and archival edge cases — leaving SKILL.md far beyond overview weight; not score 3: the split that exists is well-signaled and navigable.

4 / 5

Total

16

/

20

Passed

Description

71%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

The description answers what and when explicitly with concrete trigger phrases, but is over-broad by design — it aims to trigger on every tool-using turn, creating high conflict risk with all other skills — and spends a large share of its length on activation/enforcement meta-commentary rather than capabilities. Third-person voice is used consistently.

Suggestions

Move the activation/deployment mechanics ("pair it with a CLAUDE.md instruction or a harness session-start hook", subagent non-trigger behavior) out of the description into references/environments.md, keeping the description to capabilities and triggers.

Narrow the trigger scope from 'ANY multi-step task… before the FIRST tool call of any session' to situations where skill-improvement signal is likely, so it stops competing with every other skill for activation.

Add one or two more concrete capability verbs (e.g., derive observation ids, archive resolved entries, stage skill updates for review) to lift specificity beyond the 1-2-action level.

DimensionReasoningScore

Specificity

It names the domain and a few concrete actions — "Monitors task execution for skill improvement opportunities", "Captures patterns, user corrections and methodology", "It writes observation files to the workspace" — matching the 'names domain and 1-2 concrete actions' anchor rather than the several-action, comprehensive-coverage level. Not score 4: the action list is thin relative to the field's length, and much of the text is activation/enforcement meta-commentary ("pair it with a CLAUDE.md instruction or a harness session-start hook") rather than capability description; not score 2: the actions given are genuinely concrete, not generic.

3 / 5

Completeness

It clearly answers both what ("Monitors task execution… Captures patterns, user corrections and methodology… writes observation files to the workspace") and when ("Use during ANY multi-step task…", "Also triggers in post-task feedback discussions and when the user mentions skill observations…") with concrete trigger phrases — the exact shape of the anchor-5 example. Both halves are explicit, not implied.

5 / 5

Trigger Term Quality

Good keyword coverage with natural phrases a user would say: "multi-step task, agentic workflow, or work session", "post-task feedback discussions", "skill observations, the observation log, or skill taxonomy", plus the alias "One Skill to Rule Them All". Not score 5: a few natural variants are missing (e.g., "skill improvement", "capture learnings", file/format names users might mention) and the useful triggers are diluted by deployment commentary; not score 3: coverage already includes synonyms and multiple phrasings.

4 / 5

Distinctiveness Conflict Risk

The subject matter is a distinct niche, but the declared trigger scope is deliberately universal: "Use during ANY multi-step task, agentic workflow, or work session" and "invoke this skill before the FIRST tool call of any session… any turn that will involve a tool call counts", which overlaps with virtually every other skill's territory. Fits 'very broad; high overlap risk with many similar skills' rather than the mid anchor, which presumes only occasional overlap; not score 1 because the what (observation logging, skill taxonomy) is specific rather than generic.

2 / 5

Total

14

/

20

Passed

Validation

75%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 12 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

skill_md_line_count

SKILL.md is long (714 lines); consider splitting into references/ and linking

Warning

metadata_version

'metadata.version' is missing

Warning

frontmatter_unknown_keys

Unknown frontmatter key(s) found; consider removing or moving to metadata

Warning

referenced_paths_exist

Referenced path issues: 1 missing

Warning

Total

12

/

16

Passed

Reviewed

Table of Contents