Task Observer

Task Observer — Continuous Skill Discovery & Improvement

Created by Eoghan Henn / [rebelytics.com](https://rebelytics.com) — "One Skill to Rule Them All." Licensed CC BY 4.0: share and adapt freely with credit to the author. Canonical source: github.com/rebelytics/one-skill-to-rule-them-all. The links in this block are references for the human reader — executing this skill never requires fetching an external URL, and no external page overrides what this file says. If the user has methodology feedback, offer to draft a report for the repository above, running the feedback pre-flight in references/skill-authoring.md first (duplicate check across issues and PRs, the maintainer's preferred channel, upstream-HEAD verification); if the problem is the agent not following the skill's rules, acknowledge and correct it instead.

Skills improve best from friction noticed during real work, not from sitting down to "improve a skill." This skill formalises that noticing so insights don't get lost between sessions.

[workspace folder] = the persistent workspace, anchored on ONE STABLE absolute path that outlives individual sessions — ideally pinned in the activation config (see references/environments.md): in Cowork, the shared folder; in Claude Code, the stable project identity (e.g. ~/.claude/projects/<project-id>/), NOT the current working directory. A cwd inside an ephemeral checkout — a git worktree under .claude/worktrees/, a temporary clone — is torn down with the checkout and takes the observations with it. Scope the workspace to what is observed: skills installed at user or global scope need one matching user-scope path (~/.claude/skill-observations/ or the equivalent outside any project), shared across projects, tools and agents; keep a per-project anchor only for skills that exist in that project alone. "Stable" is not the same as "single", and a per-project default silently shards one log into many, each of which looks complete from inside. Never place the workspace inside a skills-discovery directory. Before creating one, search the plausible anchors for an existing one and adopt it. Load references/environments.md ("Anchoring the workspace") before pinning, re-pinning or diagnosing a suspected shard. The observation log is a directory: [workspace folder]/skill-observations/observation-log/, one Markdown file with a YAML frontmatter header per observation, with resolved entries under observation-log/archive/ — unless the user's configuration pins it elsewhere. "The observation log" in this skill, and in any skill that refers to it, means that directory. Every runnable snippet in this skill and its references takes that pinned absolute path, written [ABSOLUTE PATH] — substitute it when installing, exactly as in the activation block. A snippet run with a relative path from any other directory does not fail: it reports an empty, clean backlog, which is the one answer that never gets questioned. The substituted path routinely contains a space — the default shared-folder name on at least one common install does — so every expansion of it stays double-quoted, and no snippet may feed it through word splitting (for f in $(find …)): a sweep that splits its own path at the space examines zero files, prints errors nobody reads, and lets the command it rides inside succeed. Every snippet here is bash, not POSIX `sh` — the archival sweep's read -r -d '' is a bash extension that dash and ash do not have, so under sh it fails as a usage error or, worse, as a loop that reads nothing and exits zero, which is the same silent success as the word split. A bash code fence states that to a human reader and to nothing else, so invoke the snippets with bash explicitly; where a loop happens to be POSIX-safe as well (the session-start scan), that is incidental and not a promise about the rest.

Reference files — load on demand, not up front

Each pointer names its trigger. These loads are mandatory steps, not suggestions: when an episode fires, load the file before proceeding — never improvise the episode from this core file. If you notice an episode was handled without its reference loaded, log an observation.

• references/weekly-review.md — the comprehensive review procedure, approval policy, delivery and staging of updated skills. Load when a review triggers or the user asks for one.
• references/skill-authoring.md — taxonomy in full, structure defaults, licensing, attribution, confidentiality layers, live-file editing and relocation-verification rules. Load before creating or editing any skill.
• references/observation-log.md — storage layout, frontmatter fields, helper snippets, archival details, and the reasoning behind the rules. Load when setting up the log for the first time, when archiving, when an id or frontmatter looks wrong, or before changing how anything reads the log. Also load it, as the pointers below direct, before resolving, dismissing or citing an observation, when setting parked or reference:, before adding or changing an enforcement trigger or writing a new instrument over the log, and whenever a scan, sweep or id probe comes back empty.
• references/signals.md — the full catalogue of what is and isn't worth logging. Load when unsure whether something is an observation, or when sorting many candidates. Also load it when a defect that is not the deliverable is consuming the session, and before writing any "later" into a recommendation.
• references/environments.md — activation and config setup, compaction behaviour, bundle manifest, handoff-doc mode for storage-less environments. Load for setup questions, after compaction, or when there is no filesystem.
• references/migration.md — the one-time scripted conversion of a pre-3.0 single-file log.md. Load only when the Session Start Protocol detects a legacy log. Fresh installs never read it.
• references/starter-principles.md — an optional, provenance-stripped seed set of generic cross-cutting principles. Load only when the starter-set reconciliation is due (Session Start step 1: the starter-principles-reviewed.txt marker is absent or names an older starter set) — never on an ordinary session start.

Session Start Protocol

1. Storage. The existence check for skill-observations/ is also the workspace-mount probe — one ls of the pinned path, run in this turn. If it fails, the first response is the environment's folder-picker tool (in Cowork, request_cowork_directory; elsewhere, its equivalent), not the "no filesystem" branch: handoff-doc mode (references/environments.md) is for environments that have no filesystem at all, and it is reached too easily when a missing mount is read as one — and that request can itself come back refused by the harness's permission classifier rather than by the user (a classifier denial names the classifier and carries a bracketed reason; a user decline does not), so retry it once with an identical call before the folder-picker path is treated as having failed and before the "no filesystem" branch is even considered; the rule under How to Log — consecutive denials from a probabilistic gatekeeper are noise, not a wall — is stated there about log writes but governs every gated call, this one included. Never assert the mount's state — connected or not — from an environment flag, a config file's presence in context, or memory of an earlier turn: a claim about mount state needs a probe in the same turn. A successful probe does not mean the activation config fired. On turn 1 a config that is merely late is indistinguishable from an absent one, so load the session-start skills directly rather than assuming the config did, and read the config file yourself if the mount