Rebelytics One Skill To Rule Them All One Skill To Rule Them All

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.

2. 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?
2. Were observations logged silently without interrupting the user's flow?
3. Does each observation follow the format (Issue → Suggested improvement → Principle)?
4. Is each observation tagged with the correct type (open-source or internal)?
5. For any observations about existing skills, does the suggested improvement reference the specific section or rule?
6. 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 derivatives matters to the author.

Whatever licence is chosen, include the licence statement in the skill preamble (after the author attribution block) and include a LICENSE or LICENSE.txt file in the skill directory containing the full licence text. The choice belongs to the skill's author; the requirement is that there be a licence.

Author Attribution Template

Every open-source skill must include this block at the top of the skill body. Replace the placeholders with the actual author's details.

**Created by [Author Name] / [website or contact link]**

[1-2 sentence description of what the skill does and its provenance.]

**Licence:** This skill is released under [LICENCE NAME]. [One-sentence
summary of the licence — e.g., "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 (or
equivalent public feedback channel). This keeps feedback public and
discoverable. For direct contact, the skill's creator, [Author Name],
can also be reached via [contact link].

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 the public feedback channel. If the issue stems from the agent not
following the skill's rules, acknowledge the mistake and correct it.

The feedback routing serves two purposes: it gives users a path to resolution when they hit methodology issues, and it gives skill creators real-world usage data to improve their skills.

Observation Protocol

When to Observe

Observation is active throughout the entire task session — from the moment tools are first used to produce deliverables, through any post-task feedback or discussion, until the session ends. This includes:

1. Active task execution — creating documents, analysing websites, implementing structured data, writing code, building presentations, and similar substantive work.

2. Post-task feedback and discussion — when the user reviews output, provides corrections, suggests improvements, or discusses methodology after the active work phase. User feedback during these discussions is often the highest-signal input for skill improvement and must be captured with the same diligence as observations made during execution.

3. Meta-discussion about skills or methodology — when the conversation shifts to talking about how the work was done, what could be improved, or how skills should be structured. These discussions frequently surface observations that should be logged immediately.

4. Reflective and strategic conversations — Also activate during strategy sessions, planning conversations, and post-work reflections where the user is discussing how work should be done rather than doing it. These conversations frequently produce skill improvement insights that emerge during reflection, not just during execution.

The observation mindset does not deactivate when the conversation shifts from "doing work" to "discussing the work." If the user provides feedback about methodology, naming, skill design, or workflow improvements, log it as an observation immediately, even if the conversation is in a discussion or review phase rather than active task execution.

Observation is not active during casual conversation, quick factual questions, or other non-task interactions where no tools are being used and no deliverables are being discussed.

What to Watch For

Signals for a NEW skill:

• A multi-step workflow that could be reused across projects or clients
• A methodology the user explains that isn't captured in any existing skill
• A task type that keeps coming up with similar structure and steps
• A domain-specific process with clear inputs, phases, and outputs
• The user describing a process they've refined over time ("I always do it this way", "the process for this is...")
• the agent and the user naturally developing a structured approach to a problem that could be formalised

Signals for IMPROVING an existing skill:

Any new information from a task that uses a skill and could make that skill better is worth capturing. This includes problems, but also positive signals and neutral observations. Examples:

• the agent doesn't follow a skill's rules despite them being documented — this means the skill needs stronger enforcement, not just better rules
• The user corrects the agent's output in a way that reveals a missing rule or an edge case the skill doesn't cover
• A skill's recommended workflow turns out to be less efficient than what emerged naturally during the task
• A technique or approach works particularly well and deserves to be promoted from incidental to explicitly recommended in the skill
• A workflow step turns out to be more important than the skill suggests, or less important than the emphasis it receives
• A new use case that the skill handles but doesn't explicitly document
• The user provides feedback that generalises beyond the current instance
• A skill assumption turns out to be wrong in practice
• New tools or capabilities make part of a skill's workflow obsolete or improvable
• The user's corrections form a pattern across multiple instances
• A general principle emerges that could apply to other skills too (see Principle Propagation below)
• The user suggests a naming, framing, or structural change to a skill — even conversationally — that could improve its effectiveness

Signals for SIMPLIFYING an existing skill:

Healthy skill maintenance requires both growth and pruning. Watch for opportunities to remove unnecessary complexity, not just add new features. Signals that a skill is ready to be simplified:

• A skill section or rule that has never been relevant across multiple sessions where the skill was active
• A rule added from a single observation that hasn't been validated by recurrence — one-off cases should not accumulate as permanent rules
• An elaborate workflow that users consistently shortcut or skip
• Sections that the agent loads but never acts on (dead weight in context window)
• Rules that contradict each other or create unnecessary complexity
• Complexity added "just in case" that has never triggered
• A documented rule that the agent consistently fails to follow — the rule isn't reaching the moment of decision. The fix is rarely to write it more loudly; usually it's either to remove the rule, or to convert it from narrative guidance into structural enforcement (a checklist, a verification step, or a tool call that can't be skipped).

Treat the list above as a review checklist when looking at any of your own skills — a "yes" on any signal is a candidate for simplification or removal, not just a flag for future consideration.

During weekly reviews, ask "what can we remove?" as deliberately as you ask "what should we add?" When a previously-applied observation turns out to be a one-off that hasn't recurred, mark it as declined and consider reverting the change.

Signals to NOT log:

• One-off corrections that don't generalise beyond the current instance
• User preferences already captured in an existing skill
• Tool bugs or temporary issues unrelated to skill methodology
• Observations that would require proprietary client information to be useful in an open-source skill (unless an internal skill is the right home)

How to Log

Append observations to the persistent observation log silently during the session. The user should not be interrupted by the logging process.

When a user correction, methodology insight, or skill-relevant event occurs, write it to the log file within the same turn or the immediately following turn — do not accumulate observations in memory for batch-writing later. The act of writing is the enforcement mechanism; mental notes are not observations. Tie observation flushing to existing workflow checkpoints — e.g., when marking a TodoWrite item as completed, check whether any unlogged observations have accumulated and write them before proceeding.

Mandatory observation checkpoint after every 3rd TodoWrite completion: After marking the 3rd, 6th, 9th (etc.) TodoWrite item as completed in a session, pause and explicitly ask: "Have any unlogged observations accumulated?" This is a hard checkpoint, not a suggestion — the skill has demonstrated that softer "check when completing items" guidance gets lost during cognitively demanding analytical work. The count doesn't need to be precise; the rule is: roughly every third completion, stop and flush. If nothing has accumulated, the pause costs seconds. If observations have accumulated, this prevents the common failure mode where the skill is loaded but no observations are written until the user explicitly asks.

Before assigning any observation number, run a mandatory pre-logging step: Search the entire log file for all lines matching the pattern ### Observation \d+:, extract the highest observation number already in use, and increment from there. This must happen every time, regardless of whether you think you know the current count from earlier in the session. Never rely on session memory or summaries for the next number. Always read the actual log file. A one-liner like the following suffices:

# GNU grep (Linux, Cowork):
grep -oP '### Observation \K\d+' log.md | sort -n | tail -1

# macOS / POSIX-compatible alternative:
grep -o '### Observation [0-9]*' log.md | grep -o '[0-9]*' | sort -n | tail -1

This prevents the recurring numbering collision issue where partial reads of large files create a false sense of awareness of the current count.

Write-time verification assertion (mandatory): The pre-logging step above catches honest mistakes, but is vulnerable to parallel-session scenarios where multiple task-oriented sessions on the same day each compute "next number" against a snapshot and then collide on write. To catch this class of collision, after determining the proposed next number and immediately before appending, re-read the log and assert the number does not already exist:

PROPOSED=$(( $(grep -oP '### Observation \K\d+' log.md | sort -n | tail -1) + 1 ))
grep -qE "^### Observation ${PROPOSED}:" log.md && {
  echo "COLLISION on #${PROPOSED} — another writer has claimed this number"; exit 1; }
# If assertion passes, proceed with the append using #${PROPOSED}.

If the assertion fires, increment past all existing numbers (not just by 1) and re-check. Treat an assertion failure as a meta-observation worth logging — it indicates either a parallel-session collision or a stale read elsewhere in the workflow.

Post-write verification (mandatory — closes the TOCTOU race): The pre-write assertion catches stale-read collisions but cannot close the time-of-check-to-time-of-use race between the assertion and the append. In shell, grep -q && cat >> ... is two separate operations: the grep passes at T0, the append lands at T1. Any other session that appends between T0 and T1 can claim the same number — this race has been observed in production, producing duplicate observation pairs in the active log.

After the append, re-read the log and count occurrences of the just-written observation number. If the count is greater than 1, a parallel session has collided — renumber the current session's entry to max+1 in place via sed. Concrete shell:

WRITTEN=$(grep -cE "^### Observation ${PROPOSED}:" log.md)
if [ "$WRITTEN" -gt 1 ]; then
  # Find my line (the last occurrence, since I just appended) and renumber
  MY_LINE=$(grep -nE "^### Observation ${PROPOSED}:" log.md \
    | tail -1 | cut -d: -f1)
  NEW_NUM=$(( $(grep -oP '^### Observation \K\d+' log.md \
    | sort -n | tail -1) + 1 ))
  sed -i "${MY_LINE}s/^### Observation ${PROPOSED}:/### Observation ${NEW_NUM}:/" log.md
fi

This turns the pre-write assertion into a pre-and-post pair. Pre-write catches stale-read collisions cheaply; post-write catches race collisions by renumbering instead of failing. Either way, the log ends up with no duplicates. Alternative approaches — lockfile, atomic append, transactional write — are heavier and require more infrastructure; the post-write-verify-and-renumber pattern works with plain shell and self-heals.

Why both checks are required: Stale-read collisions and race-condition collisions are different classes of error. The pre-write assertion closes the first; the post-write verification closes the second. Stacking more pre-write layers does not close race cases — only a post-write check can. When the shared state is a log file written by parallel agents, the reliable pattern is check-then-act-then-verify.

Session-start staleness check: At the start of any task-oriented session, note the modification time of log.md. If it was modified in the last few hours (i.e., a parallel or recent session has been writing to it), be extra cautious about the numbering pre-check — do not trust any mental model of "current number" and always re-read the log immediately before appending each observation, not just once at session start.

Format and insertion rules: Always use the ### Observation NNN: format. Always append new observations to the END of the log file. Never insert observations mid-file. Never use alternative ID formats (e.g., OBS-YYYY-MMDD-NN). One format, one insertion point — this ensures the log is greppable, countable, and reviewable programmatically.

Each observation follows this format:

### Observation [N]: [Short descriptive title]

**Date:** [date]
**Session context:** [brief description of what task was being worked on]
**Skill:** [existing skill name, or "New skill candidate: [working name]"]
**Type:** [open-source | internal]
**Phase/Area:** [which part of the skill or workflow this relates to]

**Issue:** [What happened or what was observed. Be specific — include what
The agent did, what the user corrected, or what pattern emerged. Include enough
detail that someone reading this weeks later can understand the context
without having seen the original conversation.]

**Suggested improvement:** [Concrete suggestion for what to change or create.
For existing skills, reference the specific section or rule. For new skills,
describe the scope and key components.]

**Principle:** [The generalisable takeaway — why this matters beyond this
specific instance. This is the most important part. It turns a single
observation into a reusable insight.]

This format was refined through iterative real-world use. The structure works because it forces specificity (Issue), actionability (Suggested improvement), and generalisation (Principle).

Context preservation check: When logging an observation, verify that all information needed to act on it is available in the shared folder. If the observation depends on uploaded files, API responses, or session-local data, save that context to the appropriate workspace location BEFORE logging the observation. Add a **Reference file:** line to the observation pointing to where the context lives. Observations that reference data only available in the current session (uploaded files, API outputs, in-memory results) are incomplete — a future review session will have the observation but not the data needed to implement it.

Handoff Doc Analysis

When a handoff doc arrives for observation logging, extract observations systematically from both explicit and implicit sources:

1. Log all explicitly stated observations first. These are easy to surface and should be logged without filtering.

2. Then systematically analyse the full document. Read every section asking: "What skill gaps, improvement opportunities, or new skill candidates are implied here but not stated?" Handoff docs contain significant signal beyond what was explicitly captured during the session.

3. Pay special attention to:

   • Action items (each one may imply a missing skill or workflow)
   • Open questions (unresolved ambiguity often signals a decision framework gap)
   • The "work completed" narrative (patterns across work items may reveal meta-skills)
   • Session notes (reflective insights about process, not just content)

4. Log the additional observations with clear attribution. Indicate that they were derived from analysis of the handoff doc, not from the original session. This preserves the distinction between stated and derived insights.

Archival on Write

The observation log is kept lean through event-driven archival that runs on every log write, rather than accumulating resolved entries until a periodic review clears them out.

Defining "from a previous update": The phrase "from a previous update" means entries whose status was already resolved in a previous SESSION or prior log write, not entries marked ACTIONED or DECLINED in the current session. Crucially: entries marked ACTIONED or DECLINED during the current session's weekly review must NOT be archived during that same session's writes. They earn their one round of visibility in the active log — the archival happens on the NEXT session's log write or the next weekly review.

Archival Timing During Weekly Reviews: The weekly review performs archival in two phases:

1. Step 1 (at review start): Archive entries from previous sessions. Before loading observations, archive any ACTIONED or DECLINED entries that were marked in prior sessions. This clears old resolved items.

2. Step 6 (after marking ACTIONED): Do NOT archive immediately. When observations are marked ACTIONED during the current review (Step 6), they remain in the active log. Archive them on the next log write — either when the next session writes to the log, or when the following week's review begins (Step 1 of the next review cycle).

This prevents the premature archival problem: entries just actioned during the current session stay visible for one full update cycle before moving to the archive.

Archive File Structure: Move resolved entries to an archive file at:

[workspace folder]/skill-observations/archive/log-[date].md

where [date] is today's date in YYYY-MM-DD format.

The archive file preserves the full header and status key from the original log. After archiving, the active log.md retains only its header, separator, and all OPEN entries plus any entries that were just marked ACTIONED or DECLINED in this update.

Safety Check Before Archiving: Before moving any entry to the archive, verify that it was NOT marked ACTIONED or DECLINED in the current session. If it was, keep it in the active log. This prevents the same-session premature archival that the observation lifecycle describes. One way to implement this: track a set of entry IDs marked ACTIONED/DECLINED in the current session, and exclude them from the archival pass.

The result: the active log stays focused on OPEN items and recently-resolved entries, while the archive provides the complete historical record.

Confidentiality Safeguards

The open-source/internal boundary is a confidentiality boundary. Client names, project details, domain names, and proprietary information must never appear in open-source skills. Because a single leak can erode trust, this is enforced through multiple layers — any one of which should catch what the others miss.

Layer 1: Observation-Level Stripping

When logging an observation tagged as type: open-source, the Issue and Suggested Improvement fields should already use generic language. The private observation log can reference specifics for context, but the Principle field — which feeds into skill creation — should be fully generalised. Think of it as: the log is a private notebook, but the Principle is a publishable insight.

Layer 2: Pre-Creation Review

Before drafting or regenerating any open-source skill, scan all source material (observations, conversation notes, existing skill content) for identifying information: client names, project URLs, domain names, internal terminology, site structures described so specifically they're identifiable. Replace anything found with generic equivalents before writing begins.

Layer 3: Post-Draft Sweep

After writing or regenerating an open-source skill, re-read it with a specific focus on information leakage. This is a separate pass from the general pre-flight checklist. Look for:

• Proper nouns that aren't the skill author's name
• Domain names, URLs, or project identifiers
• Industry-specific details that narrow down the client
• Internal terminology that only makes sense in one organisation's context
• Examples so specific they're traceable to a real project

If anything is found, replace it with generic equivalents or remove it.

Layer 4: Structural Principle

The taxonomy section states this explicitly, but it bears repeating: the open-source/internal distinction is not just about usefulness — it's about confidentiality. When in doubt about whether a detail is too specific, remove it. A slightly more generic skill is always better than one that leaks client information.

Layer 5: Cross-Product Re-Identifiability Sweep

Layers 1–4 focus on single-example scrubbing. They do not catch the case where two or three sanitised examples in the same skill — each fine on its own — combine to narrow the identifiable client set. A reader who knows the author's client portfolio (which is often public on a consultant's website) can triangulate even when each individual example is properly placeholdered. The failure mode is invisible to the author because they mentally compartmentalise each example; it's visible to any reader with adjacent context.

When to run it: After every individual example has been sanitised — as a final pass before the skill ships or before any major public release. This is the last check, not a substitute for earlier layers.

What to look for:

• Enumerated counts that match a known client count. "Four builds across three verticals" in a skill whose author has four public clients across three verticals is functionally a directory. Blur the count ("multiple builds") or the verticals ("across regulated, editorial, and commerce contexts").
• Specific numbers in a thin vertical. Visibility percentages, revenue ranges, or geography given in a vertical where only one or two candidates plausibly exist. A single real client can be narrowed from "vertical × percentage × geography × timing" even when no name appears. Replace specific numbers with illustrative ranges.
• Thinly-disguised placeholder names. "Northwind Coffee" in a specialty-retailer vertical where the only plausible specialty-retail client is a coffee roaster reads as the real brand with a thin rename. Use the Northwind / Contoso / Fabrikam placeholder family explicitly, and make sure the placeholder's vertical is different from any real client's vertical.

How to sweep:

1. List every worked example in the skill and the fields each one names (vertical, geography, numeric range, timing, count).
2. Ask: do any two examples share enough fields that a reader with access to the author's public client list could map the set to real clients?
3. Mitigate by blurring counts, widening verticals, dropping specific numbers to illustrative ranges, or consolidating similar examples into a single composite.

Why this is a separate layer: Re-identification risk is combinatorial. Each additional sanitised example adds a field that narrows the candidate space. Layers 1–4 check each example in isolation and pass.

…(truncated)