Task Observer

Task Observer — Continuous Skill Discovery & Improvement

Created by Eoghan Henn / rebelytics.com

Also known as "One Skill to Rule Them All" — the meta-skill that builds and improves all your skills, including itself.

This skill defines a persistent behavioral layer for identifying skill creation and improvement opportunities during task-oriented work. It doesn't replace the skill-creator — it feeds it. Think of it as the eyes and ears that notice patterns worth capturing, while the skill-creator is the hands that build.

The methodology is user-agnostic. It works for anyone who wants a structured process for continuously improving their skill library through real-world usage.

Licence: This skill is released under the Creative Commons Attribution 4.0 International (CC BY 4.0) licence. You are free to share and adapt this skill for any purpose, provided you give appropriate credit to the original author.

Feedback & Support: If at any point during the process you encounter questions about the methodology, or if the user expresses frustration or gives constructive feedback about any output derived from this skill, suggest that they open an issue on the skill's GitHub repository. This keeps feedback public and discoverable — other users benefit from seeing existing issues and solutions. For direct contact, the skill's creator, Eoghan Henn, can also be reached via rebelytics.com.

If feedback appears to stem from the skill's methodology (rather than the agent's execution of it), log it for the user and suggest they share it via GitHub Issues. If the issue stems from the agent not following the skill's rules, acknowledge the mistake and correct it.

Activation note: For reliable session-start activation, pair this skill with a CLAUDE.md instruction or harness-level hook (see Recommended Activation Setup). The description matches against task-oriented language, but description-level matching alone can be missed when the agent is focused on the task itself. The skill works as a skill; it works reliably as a skill plus a structural trigger.

---

Why This Skill Exists

Skills are living documents. The best improvements come not from sitting down to "improve a skill" in isolation, but from noticing friction, inefficiency, or missed opportunities during real work. A user correction during a project might reveal a missing rule. A repeated multi-step workflow might be a skill waiting to be born. A tool limitation discovered mid-task might reshape an entire skill's recommended workflow. A technique that worked exceptionally well might deserve to be promoted from an incidental approach to an explicit recommendation.

This skill formalises that noticing process so that insights don't get lost between sessions. Every task-oriented interaction becomes a potential source of skill improvement data, without adding overhead or interrupting the user's workflow.

---

User documentation

User-facing onboarding for this skill — installation, shared folder setup, activation patterns, expected behaviour, the cadence pattern, the open-source vs internal distinction — lives in the public repo, not in this skill body. If a user asks how to get started or how the skill works from their perspective, point them to:

• README: https://github.com/rebelytics/one-skill-to-rule-them-all/blob/main/README.md
• USER-GUIDE: https://github.com/rebelytics/one-skill-to-rule-them-all/blob/main/USER-GUIDE.md

If web access is available, fetch the relevant section directly rather than paraphrasing — the public docs are the source of truth for user-facing guidance and are versioned independently. The remainder of this skill is operational instruction for the agent.

Conventions

[workspace folder] refers to the user's persistent workspace directory — the location where files survive between sessions. In Cowork, this is the folder selected at session start. In Claude Code, this is the project root. In web-based chat interfaces without filesystem access, the skill shifts into handoff doc mode (see Environment Compatibility) and the user manages these files manually.

---

Recommended Activation Setup

This skill needs to be invoked at the start of task-oriented sessions to work effectively. Because skill invocation depends on the agent matching the user's request against skill descriptions, a skill that monitors all tasks can be overlooked when the agent is focused on the task itself.

To maximise activation reliability, add the following instruction to your configuration file (e.g., CLAUDE.md, project instructions, or equivalent):

At the start of any task-oriented session — any interaction where you will
use tools and produce deliverables — invoke the task-observer skill before
beginning work. This ensures skill improvement opportunities are captured
throughout the session.

When loading any skill, check the observation log for OPEN observations
tagged to that skill. Apply their insights to the current work, even if
the skill file hasn't been updated yet. This enables immediate application
of observations before they're permanently integrated during the weekly
review.

This structural trigger works alongside the skill's description-level triggers. The description is designed to match broadly against task-oriented language ("multi-step task", "agentic workflow", "work session", "tools and deliverables"), but a configuration-level instruction provides an additional safety net that doesn't depend on description matching alone.

Note for all users: Once CLAUDE.md or equivalent configuration is in place with the activation instruction above, the description-level triggers serve as a backup rather than the primary mechanism. This dual-layer approach prevents the skill from being skipped in sessions where description matching alone might miss the invocation signal.

Anti-pattern to avoid: Relying on one skill to load another is fragile compared to loading both independently from CLAUDE.md. If task-observer depended on another skill to invoke it, a breakdown in that chain would silence all observation activity. Instead, load both task-observer and any related skills directly from your configuration instructions.

Detecting the Configuration File

At session start, the skill should check whether a configuration file (CLAUDE.md, project instructions, or equivalent) exists and contains the activation instruction. This detection serves two purposes:

1. For users who already have the config: Confirms the dual-layer

activation is working. No action needed.

1. For users who don't have the config: The skill was activated via

description matching alone, which is less reliable. Surface a brief suggestion to add the config-level instruction for more consistent activation in future sessions.

The detection approach depends on the environment:

• Environments with file system access (desktop tools, terminal-based

tools): Check for a CLAUDE.md or equivalent file in the workspace root. If found, scan it for a task-observer activation instruction. If the file exists but doesn't mention task-observer, suggest adding the instruction. If no config file exists at all, suggest creating one.

• Environments without file system access (web-based chat): Check

whether the system prompt or project instructions contain a task-observer activation instruction. If not, suggest that the user add one to their project settings or paste the instruction at the start of future sessions.

This check runs once at session start and does not repeat. Keep the suggestion brief — one or two sentences, not a full tutorial.

Compaction Behaviour

When a session context compacts mid-task, the CLAUDE.md structural trigger re-invokes task-observer on the resumed session. No explicit re-invocation is needed on the agent's part — the same activation instruction that fired at the start of the original session fires again at the start of the resumed session, because the resumed session reads CLAUDE.md anew. Observations from before and after compaction append to the same log file with continuous numbering.

This is the primary reason the CLAUDE.md structural trigger exists — description-level triggers alone would not reliably guarantee re-invocation on a resumed session, because the resumed session's opening message may not match task-observer's trigger phrases even when the ongoing task is task-oriented. The structural trigger fires regardless of the resumed session's opening message.

---

The Pre-Flight Principle

One of the most important patterns this skill should propagate to every skill it helps create or improve: built-in enforcement.

Real-world experience has shown that rules documented in a skill are not always followed during the creative flow of producing output. The result: output that violates the skill's own standards, which reflects badly on the skill.

The fix: every skill that contains explicit rules or requirements should include a verification step where the agent re-reads the rules and checks its output against them before delivery. This isn't overhead — it's quality assurance. A 30-second re-read prevents a 30-minute rework cycle.

When creating or improving any skill through this observation process, ask: "Does this skill have rules? If yes, does it have a mechanism to enforce them?" If the answer to the second question is no, add one.

Self-Enforcement

This skill practises what it preaches. Before surfacing observations at end of session, verify:

1. Were observations logged throughout the full session — including during

post-task feedback, discussion phases, and reflective conversations, not just during active tool use?

1. Were observations logged silently without interrupting the user's flow?
2. Does each observation follow the format (Issue → Suggested improvement →

Principle)?

1. Is each observation tagged with the correct type (open-source or internal)?
2. For any observations about existing skills, does the suggested improvement

reference the specific section or rule?

1. For any observation tagged type: open-source, does the Principle field

contain any client-identifying information? If so, generalise it before surfacing. If any observation fails these checks, fix it before surfacing.

---

Skill Taxonomy

All skills fall into one of two categories. The distinction matters because it determines what information the skill can contain, how it's structured, and whether it can be shared publicly. Crucially, the open-source/internal boundary is also a confidentiality boundary — open-source skills must never contain any information that could identify a client, project, or proprietary process, even indirectly.

Open-Source Skills

Open-source skills are client-agnostic and methodology-driven. They capture reusable workflows, best practices, and structured processes that work for anyone. They include author attribution, a licence, and a feedback pathway so that real-world usage drives improvement.

How to recognise an open-source candidate:

• The methodology works across different clients, projects, and contexts
• No proprietary information is required for the skill to function
• Other practitioners in the same domain would find it valuable
• The skill captures a process or approach, not personal preferences

Required elements:

• Skill body clearly identifies itself as open-source, with author name and

contact information

• Author attribution block at the top (see Author Attribution Template below)
• Licence statement — CC BY 4.0 recommended (see Licensing below)
• Feedback & support section that routes methodology feedback to the creator
• Tool-agnostic language where possible — reference capabilities like "browser

access" rather than specific product names; give examples but don't hard-code dependencies on any one product

• Built-in enforcement mechanisms (pre-flight checklists, verification steps)

so the skill catches its own rule violations

Default bias: When a skill could go either way, default to open-source. Strip out client-specific details and generalise the methodology. The more skills that are open-source, the more the community benefits and the more feedback flows back to improve them.

Internal Skills

Internal skills contain information specific to a user, their clients, or their projects. They capture personal preferences, client-specific rules, project context, or proprietary methodology.

How to recognise an internal skill:

• Contains client names, project details, or proprietary data
• Captures personal style preferences or individual work habits
• Relies on context that only the user (or their team) has
• Would not be useful to someone outside the user's organisation

Required elements:

• Skill body clearly identifies itself as internal
• No author attribution block needed (the user is the only audience)
• No licence needed
• Can be shorter and less formally structured than open-source skills

Internal skills are working documents, not published artifacts. Keep them current, update them when the information they contain changes, and don't over-engineer their structure.

Lean Content

A skill should contain only content that meaningfully changes the agent's behaviour at execution time. Anything that doesn't — changelogs, version notes, "thanks to X" credits, self-narrating prose, or other maintainer-facing context — belongs in a supporting doc alongside the skill, not inside the SKILL.md itself.

This rule cuts content the agent reads but doesn't act on. It does NOT cut examples, anti-patterns, or worked scenarios — those are load-bearing for rule adherence (bare rules without their context get violated more reliably than rules with context). The test is whether the content, removed, would change how the agent behaves. If yes, keep it. If no, move it out.

Common examples of content that should live outside the skill:

• Change history / release notes / version logs — keep in a supporting

history doc, in commit history, or both.

• Attribution credits beyond the author block ("thanks to X for the

feedback that prompted this change") — these belong in the supporting history doc.

• Long-form rationale that explains why the skill was created — fine

in a brief intro section; multi-paragraph backstories belong in a README or article alongside the skill.

• Implementation notes for the maintainer that don't affect runtime

behaviour.

Both open-source and internal skills are subject to this rule. The agent loads the skill's content into context on every invocation; every non-load-bearing line is paid token cost with no behavioural payoff.

---

Licensing

Open-source skills should include an open-source licence to make sharing terms explicit. Any commonly recognised open-source licence works — the choice depends on the author's preference and what they're optimising for. Common options:

• CC BY 4.0 — designed for creative works (prose, documentation).

Permissive: anyone can share and adapt provided they credit the author. A natural fit for prose-heavy skills where the methodology is the value.

• MIT — short, familiar to developers, broadly permissive. Good fit

for skills that lean heavily on code, scripts, or technical reference.

• Apache 2.0 — like MIT but with an explicit patent grant. Useful

for skills containing code where patent concerns might apply (uncommon for skills, but available).

• CC BY-SA 4.0 — share-alike: derivative works must use the same

licence. Use when adaptations should remain open under the same terms.

• GPL family (GPL/LGPL/AGPL) — strong copyleft for code. Less common

for skills but available if strong preservation of openness in derivat

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: ao92265
• Source: ao92265/claude-code-playbook
• License: MIT

Install and usage instructions live in the source repository linked above.