Recall Is Part of Correctness
A skill that exists but never enters a future session has not completed AutoHarness's job. This chapter examines the gap between where a learned rule is stored and how it becomes visible to Claude Code, then separates three signals that are easy to confuse: a skill being loaded, being inspected, and being changed. The practical result is a way to judge whether AutoHarness is measuring future usefulness or merely counting files.
Storage scope is not recall scope
AutoHarness keeps two broad layers of skills. A project layer is associated with the work being done in a repository or working directory; a global layer is available across projects and therefore has a larger potential blast radius. The distinction is not just a different folder name. It is a statement about how widely a lesson is allowed to influence future work.
Imagine the testing convention from the earlier chapters. The rule that every parameterized test should identify its behaviors belongs naturally near the repository that established it. A rule about a broadly reusable testing technique might have a wider home. If the narrow convention were placed globally, it could be offered in unrelated repositories where it is wrong or distracting. AutoHarness therefore resolves layer ownership explicitly and rejects ambiguous same-name skills rather than guessing which scope should change.
The project layer also has to remain stable when a developer works through linked Git worktrees. The repository implementation remaps that special case to the main worktree so that one project's state does not fragment merely because the operator changed working directories. Ordinary non-git directories and nested project situations are treated more conservatively. This illustrates a general point: recall depends on identity. If the system cannot tell which project owns a lesson, it cannot safely decide where that lesson belongs.
Layer ownership is paired with an author boundary. AutoHarness's sidecar marks the skills it created, and the recall index, lifecycle manager, and promoter use that marker to identify their membership. Native skills, user-authored skills, and externally installed skills remain outside the plugin's management pool. This arrangement lets AutoHarness add an explicit surface for its own library without claiming ownership over the host's entire knowledge base.
The session-start index makes the library visible
Claude Code already has a native way to recall skills from names and descriptions. AutoHarness leaves that path intact, but it does not want the success of its own library to depend entirely on whether the host happens to offer one of those skills at the right moment. At session start, it builds a compact index of live, agent-created skills and injects that index as additional context.
The index is a scan surface, not a copy of every skill body. It groups entries by category, labels their layer, and puts a shortened description beside each name. The description is flattened so that line breaks cannot manufacture a misleading index structure, and long descriptions are visibly truncated. An empty library produces no injection.