@jeffober/thatch 0.1.26 → 0.1.27

package/src/setup.ts

@@ -22,7 +22,7 @@ interface SetupPaths {
 
 /**
  * Resolve the Claude config directory. `CLAUDE_CONFIG_DIR` overrides the
- * default `~/.claude` location — used by people running multiple accounts
+ * default `~/.claude` location - used by people running multiple accounts
  * side by side (per Claude Code env-vars docs). Settings, CLAUDE.md, and
  * skills are all stored under this path in global scope. Project-local
  * installs only use it for skills (which are always user-scoped); the
@@ -41,7 +41,7 @@ function resolvePaths(global: boolean, projectDir: string, homeDir: string): Set
       mcpConfigPath: null,
       // Per Claude Code settings docs, user-scope CLAUDE.md lives at
       // `~/.claude/CLAUDE.md` (or `$CLAUDE_CONFIG_DIR/CLAUDE.md` when the
-      // env var is set) — NOT `~/CLAUDE.md`. Honoring CLAUDE_CONFIG_DIR
+      // env var is set) - NOT `~/CLAUDE.md`. Honoring CLAUDE_CONFIG_DIR
       // here also fixes a pre-existing bug where we wrote to `~/CLAUDE.md`.
       claudeMdPath: join(configDir, "CLAUDE.md"),
       settingsPath: join(configDir, "settings.json"),
@@ -55,14 +55,14 @@ function resolvePaths(global: boolean, projectDir: string, homeDir: string): Set
     claudeMdPath: join(projectDir, "CLAUDE.md"),
     settingsPath: join(projectDir, ".claude", "settings.json"),
     // Skills are always user-scoped, so they always live under the config
-    // dir — even when settings and CLAUDE.md are project-local.
+    // dir - even when settings and CLAUDE.md are project-local.
     skillsDir,
     global: false,
   };
 }
 
 // ---------------------------------------------------------------------------
-// .mcp.json — MCP server registration
+// .mcp.json - MCP server registration
 // ---------------------------------------------------------------------------
 
 function writeMcpConfig(path: string, thatchBin: string): void {
@@ -71,7 +71,7 @@ function writeMcpConfig(path: string, thatchBin: string): void {
     try {
       config = JSON.parse(readFileSync(path, "utf8"));
     } catch {
-      // Corrupt or empty — start fresh.
+      // Corrupt or empty - start fresh.
     }
   }
   if (!config.mcpServers) config.mcpServers = {};
@@ -87,11 +87,11 @@ function writeMcpConfig(path: string, thatchBin: string): void {
 }
 
 // ---------------------------------------------------------------------------
-// CLAUDE.md — append thatch instructions (idempotent)
+// CLAUDE.md - append thatch instructions (idempotent)
 // ---------------------------------------------------------------------------
 
 const THATCH_MARKER = "# Persistence\n\nThatch provides persistent memory across Claude Code sessions.";
-const THATCH_END_MARKER = '"Forget X" — `memory_recall` to find it, then `memory_forget`.';
+const THATCH_END_MARKER = '"Forget X" - `memory_recall` to find it, then `memory_forget`.';
 const CURSOR_MARKER = "# Persistence\n\nThatch provides persistent memory across Cursor sessions.";
 const CURSOR_END_MARKER = THATCH_END_MARKER;
 
@@ -119,7 +119,7 @@ function appendBlock(
           return;
         }
       }
-      // Marker found but block boundaries didn't parse — leave it alone.
+      // Marker found but block boundaries didn't parse - leave it alone.
       return;
     }
     // Append to existing file.
@@ -140,7 +140,7 @@ function appendCursorInstructions(path: string): void {
 }
 
 // ---------------------------------------------------------------------------
-// settings.json — hook installation
+// settings.json - hook installation
 // ---------------------------------------------------------------------------
 
 interface HookEntry {
@@ -163,14 +163,14 @@ function writeHooks(path: string, thatchBin: string): void {
     try {
       settings = JSON.parse(readFileSync(path, "utf8"));
     } catch {
-      // Corrupt — start fresh.
+      // Corrupt - start fresh.
     }
   }
   if (!settings.hooks) settings.hooks = {};
 
   const sessionStartCmd = `${thatchBin} reminder`;
   // PostToolBatch silently buffers tool interactions to the file-backed queue
-  // (see src/extract-queue.ts). No stdout — the next model call must not block
+  // (see src/extract-queue.ts). No stdout - the next model call must not block
   // on a payload that should be invisible to the agent until UserPromptSubmit.
   const bufferCmd = `${thatchBin} buffer-batch`;
   // UserPromptSubmit peeks the queue. With buffered interactions, it prints
@@ -209,7 +209,7 @@ function replaceThatchHooks(
 }
 
 // ---------------------------------------------------------------------------
-// Skills — install to $CLAUDE_CONFIG_DIR/skills/ (or ~/.claude/skills/ by default)
+// Skills - install to $CLAUDE_CONFIG_DIR/skills/ (or ~/.claude/skills/ by default)
 // ---------------------------------------------------------------------------
 
 function installClaudeSkills(skillsDir: string): SkillFile[] {
@@ -233,7 +233,7 @@ export interface SetupResult {
 /**
  * Installs thatch into Claude Code. Writes MCP config, appends instructions to
  * CLAUDE.md, installs SessionStart + PostToolBatch + UserPromptSubmit hooks,
- * and installs skill files. All operations are idempotent — re-running setup
+ * and installs skill files. All operations are idempotent - re-running setup
  * updates content that has drifted without clobbering unrelated configuration.
  *
  * Honors `CLAUDE_CONFIG_DIR` for all user-scoped paths (settings, CLAUDE.md,
@@ -276,7 +276,7 @@ export function setupClaudeCode(
 }
 
 // ---------------------------------------------------------------------------
-// Cursor setup — .cursor/mcp.json, AGENTS.md, .cursor/hooks.json, skills
+// Cursor setup - .cursor/mcp.json, AGENTS.md, .cursor/hooks.json, skills
 // ---------------------------------------------------------------------------
 
 /**
@@ -303,7 +303,7 @@ function resolveCursorPaths(global: boolean, projectDir: string, homeDir: string
 
   if (global) {
     return {
-      // Cursor's global MCP config is a simple file — no equivalent of
+      // Cursor's global MCP config is a simple file - no equivalent of
       // `claude mcp add --scope user`. Writing ~/.cursor/mcp.json is enough.
       mcpConfigPath: join(configDir, "mcp.json"),
       agentsMdPath: join(configDir, "AGENTS.md"),
@@ -340,7 +340,7 @@ function writeCursorHooks(path: string, thatchBin: string): void {
     try {
       config = JSON.parse(readFileSync(path, "utf8"));
     } catch {
-      // Corrupt — start fresh.
+      // Corrupt - start fresh.
     }
   }
   if (!config.version) config.version = 1;
@@ -351,7 +351,7 @@ function writeCursorHooks(path: string, thatchBin: string): void {
   // Code style) and Cursor would not parse it.
   const sessionStartCmd = `${thatchBin} reminder --json`;
   // postToolUse fires per-tool (Cursor has no PostToolBatch equivalent).
-  // Silent — no stdout — so the agent loop is not delayed.
+  // Silent - no stdout - so the agent loop is not delayed.
   const bufferCmd = `${thatchBin} buffer-tool`;
   // beforeSubmitPrompt is Cursor's UserPromptSubmit equivalent. Drains the
   // queue and prints the extraction nudge as JSON additional_context.
@@ -422,7 +422,7 @@ export function setupCursor(
 }
 
 // ---------------------------------------------------------------------------
-// Setup detection — check whether setup was completed for the current host
+// Setup detection - check whether setup was completed for the current host
 // ---------------------------------------------------------------------------
 
 export type HostKind = "claude" | "cursor";
@@ -449,7 +449,7 @@ function checkInstructionsFile(path: string, startMarker: string, endMarker: str
  * CLAUDE_PROJECT_DIR for Claude Code) and checks whether `thatch setup` was
  * run for that host. Checks local instructions (in the project dir) first,
  * then global (in the config dir). Returns null if the host cannot be
- * determined (neither env var is set — e.g. manual `thatch mcp` invocation).
+ * determined (neither env var is set - e.g. manual `thatch mcp` invocation).
  */
 export function checkSetup(projectDir: string, homeDir?: string): SetupStatus | null {
   const home = homeDir ?? process.env.HOME ?? "/tmp";

package/src/sideband.ts

@@ -66,7 +66,7 @@ export class SidebandServer {
     try {
       unlinkSync(this.#path);
     } catch {
-      // No stale socket — expected on first run.
+      // No stale socket - expected on first run.
     }
 
     this.#server = createServer((socket) => {
@@ -103,7 +103,7 @@ export class SidebandServer {
       this.#handleRequest(line, socket);
     });
     socket.on("error", () => {
-      // Client disconnected abruptly — nothing to do.
+      // Client disconnected abruptly - nothing to do.
     });
   }
 
@@ -155,7 +155,7 @@ export class SidebandServer {
 
 /**
  * Connect to the sideband server and request semantic matches for a prompt.
- * Returns null on any failure (server not running, stale socket, timeout) —
+ * Returns null on any failure (server not running, stale socket, timeout) -
  * callers must treat null as "skip the recall nudge" and fall back gracefully.
  */
 export function sidebandMatch(

package/src/skills.ts

@@ -1,5 +1,6 @@
-import { mkdirSync, readFileSync, writeFileSync } from "node:fs";
+import { mkdirSync, readdirSync, readFileSync, rmSync, unlinkSync, writeFileSync } from "node:fs";
 import { join } from "node:path";
+import pkg from "../package.json";
 
 export interface SkillFile {
   name: string;
@@ -42,14 +43,16 @@ function loadSharedSkills(): SkillDef[] {
     "thatch-review-highlights",
     "thatch-review-synthesizer",
     "thatch-review-context",
-    "thatch-workflow-research",
+    "thatch-code-archaeology",
     "thatch-review-followup",
     "thatch-change-walkthrough",
     "thatch-code-walkthrough",
     "thatch-session-reflection",
-    "pr-description",
-    "ticket-description",
-    "split-overlarge-pr",
+    "thatch-coding-workflow",
+    "thatch-pr-description",
+    "thatch-ticket-description",
+    "thatch-split-overlarge-pr",
+    "thatch-review-response",
   ];
   return names.map((name) => ({ name, content: loadSkillFile(name) }));
 }
@@ -63,11 +66,106 @@ function loadOpencodeOnlySkills(): SkillDef[] {
 export const SHARED_SKILLS: SkillDef[] = loadSharedSkills();
 export const OPENCODE_ONLY_SKILLS: SkillDef[] = loadOpencodeOnlySkills();
 
+// ---------------------------------------------------------------------------
+// Stale skill cleanup - runs before install on every skillsDir
+// ---------------------------------------------------------------------------
+
+// Skills renamed from non-prefixed to thatch-prefixed in v0.1.27. The old
+// names are cleaned up during install for a limited version window because
+// non-prefixed names could be adopted by third parties after we abandon them.
+// After RENAME_MIGRATION_MAX_VERSION, the cleanup stops and leftover stale
+// files are the user's responsibility.
+const RENAMED_SKILLS = new Set([
+  "pr-description",
+  "ticket-description",
+  "split-overlarge-pr",
+]);
+
+// Last version that ships the non-prefixed-to-prefixed migration cleanup.
+// Users who upgrade to this version or earlier get automatic cleanup of the
+// old skill directories. Users who skip past this version must manually
+// delete the stale directories.
+const RENAME_MIGRATION_MAX_VERSION = "0.1.35";
+
+function compareVersions(a: string, b: string): number {
+  const [aMaj, aMin, aPatch] = a.split(".").map(Number);
+  const [bMaj, bMin, bPatch] = b.split(".").map(Number);
+  if (aMaj !== bMaj) return aMaj - bMaj;
+  if (aMin !== bMin) return aMin - bMin;
+  return aPatch - bPatch;
+}
+
+/**
+ * Remove stale skill directories before installing the current set.
+ *
+ * Two cleanup rules:
+ *
+ * 1. Always: delete any `thatch-*` skill directory that is not in the current
+ *    install set. The `thatch-` prefix is our namespace - no third party should
+ *    use it, so unconditional removal is safe. This catches skills we've
+ *    renamed or removed in any release.
+ *
+ * 2. Version-gated: delete directories matching old non-prefixed skill names
+ *    (pr-description, ticket-description, split-overlarge-pr) through
+ *    RENAME_MIGRATION_MAX_VERSION. These names lack the thatch- prefix and
+ *    could be adopted by third parties after we abandon them, so the cleanup
+ *    is time-boxed. Users who upgrade past the window must manually clean up.
+ */
+function cleanupStaleSkills(skillsDir: string, currentNames: string[]): void {
+  const currentSet = new Set(currentNames);
+  let entries;
+  try {
+    entries = readdirSync(skillsDir, { withFileTypes: true });
+  } catch {
+    return; // dir doesn't exist or isn't readable - nothing to clean
+  }
+
+  const withinMigrationWindow =
+    compareVersions(pkg.version, RENAME_MIGRATION_MAX_VERSION) <= 0;
+
+  for (const entry of entries) {
+    // isDirectory() returns false for symlinks (even symlinked dirs), so
+    // check isSymbolicLink() too - a symlinked skill dir is just as stale
+    // as a regular one.
+    if (!entry.isDirectory() && !entry.isSymbolicLink()) continue;
+    const name = entry.name;
+    const fullPath = join(skillsDir, name);
+
+    // Remove a stale entry. For symlinks, unlink the symlink itself - never
+    // follow the link, which could delete the target (e.g. a shared skill
+    // directory the user still wants). For regular dirs, recursive rm.
+    const remove = () => {
+      try {
+        if (entry.isSymbolicLink()) {
+          unlinkSync(fullPath);
+        } else {
+          rmSync(fullPath, { recursive: true, force: true });
+        }
+      } catch {
+        // best-effort - don't block install on cleanup failure
+      }
+    };
+
+    // Rule 1: stale thatch-* dirs (our namespace, always safe to remove).
+    if (name.startsWith("thatch-") && !currentSet.has(name)) {
+      remove();
+      continue;
+    }
+
+    // Rule 2: renamed non-prefixed dirs (version-gated, third-party risk).
+    if (RENAMED_SKILLS.has(name) && withinMigrationWindow) {
+      remove();
+    }
+  }
+}
+
 export function installSkills(
   skillsDir: string,
   skills: SkillDef[] = SHARED_SKILLS,
 ): SkillFile[] {
   mkdirSync(skillsDir, { recursive: true });
+  cleanupStaleSkills(skillsDir, skills.map((s) => s.name));
+
   const written: SkillFile[] = [];
 
   for (const skill of skills) {
@@ -78,7 +176,7 @@ export function installSkills(
     try {
       current = readFileSync(file, "utf8");
     } catch {
-      // missing file — first install
+      // missing file - first install
     }
 
     if (current !== skill.content) {

package/src/tool-defs.ts

@@ -14,7 +14,7 @@ const PREDICTION_DEDUP_COSINE = 0.85;
 const PREDICTION_QUERY_THRESHOLD = 0.45;
 
 /**
- * Shared context passed to every tool's execute function. Framework-agnostic —
+ * Shared context passed to every tool's execute function. Framework-agnostic -
  * neither opencode nor MCP specific. The plugin wires real defaults; tests and
  * the MCP server inject whatever they need.
  */
@@ -25,7 +25,7 @@ export interface CoreContext {
 }
 
 /**
- * A tool definition — the single source of truth shared by the opencode plugin
+ * A tool definition - the single source of truth shared by the opencode plugin
  * wrapper (tools.ts) and the MCP server (mcp.ts). The `args` field is a ZodRawShape
  * (a plain object of Zod types), which opencode's `tool()` accepts directly and
  * the MCP server wraps in `z.object()` for validation and `z.toJSONSchema()` for
@@ -39,7 +39,7 @@ export interface ToolDef {
 }
 
 // ---------------------------------------------------------------------------
-// Formatting helpers — shared by all tools that render entries
+// Formatting helpers - shared by all tools that render entries
 // ---------------------------------------------------------------------------
 
 function formatEntry(
@@ -68,7 +68,7 @@ function formatRecallResult(entry: any): string {
 /**
  * Groups candidate pairs into connected components over the similarity graph,
  * so a topic fragmented across N entries reads as one cluster instead of
- * O(N²) pairs. Verdicts stay pairwise (markChecked) — this is presentation only.
+ * O(N²) pairs. Verdicts stay pairwise (markChecked) - this is presentation only.
  */
 function renderClusters(candidates: DedupCandidate[]): string {
   const parent = new Map<string, string>();
@@ -114,7 +114,7 @@ const rememberDef: ToolDef = {
     "reference material for a future instance of yourself with zero context.",
   args: {
     label: z.string().describe(
-      "Short descriptive title. Used for deduplication — same label in the same store is the same entry.",
+      "Short descriptive title. Used for deduplication - same label in the same store is the same entry.",
     ),
     content: z.string().describe(
       "The information to remember. Self-contained, understandable without session context.",
@@ -133,7 +133,7 @@ const rememberDef: ToolDef = {
     ),
     archived: z.boolean().optional().describe(
       "Mark this memory as a stable, long-term record that should not trigger hygiene nudges. " +
-      "When updating an already-archived memory, this param is REQUIRED — " +
+      "When updating an already-archived memory, this param is REQUIRED - " +
       "pass archived: true to keep it archived, or archived: false to unarchive.",
     ),
   },
@@ -189,7 +189,7 @@ const recallDef: ToolDef = {
       "Maximum number of results. Default 10.",
     ),
     includeArchived: z.boolean().optional().describe(
-      "Include archived memories in results. Default false — archived memories are excluded.",
+      "Include archived memories in results. Default false - archived memories are excluded.",
     ),
   },
   async execute(args, ctx) {
@@ -299,7 +299,7 @@ const findDuplicatesDef: ToolDef = {
   description:
     "Find memories with unusually similar content that may be candidates " +
     "for consolidation. Uses cosine similarity on embeddings. Related pairs " +
-    "are grouped into clusters — a cluster of three or more usually means " +
+    "are grouped into clusters - a cluster of three or more usually means " +
     "one topic fragmented across entries that should be consolidated into " +
     "a single memory. Pairs already reviewed via dedup_mark_checked " +
     "are skipped.",
@@ -357,13 +357,13 @@ const markCheckedDef: ToolDef = {
  * Called in a PARENT session after dispatching the fact-extractor, it accepts
  * the buffer: entries move to a holding area and the nudge quiets, but they
  * are not dropped until the extractor completes. Called in a CHILD extractor
- * at the end of its run, it completes the parent's accepted entries —
+ * at the end of its run, it completes the parent's accepted entries -
  * including no-save runs that write no memory. If the child errors or is
  * deleted before either signal, the host requeues the entries so the facts
  * are not lost.
  *
  * The actual state changes happen in the host's post-tool hook
- * (tool.execute.after for opencode, PostToolBatch/appendBatch for MCP) —
+ * (tool.execute.after for opencode, PostToolBatch/appendBatch for MCP) -
  * this tool's execute function is a no-op confirmation. The tool exists so
  * the model has a recognizable tool name to key on. In the MCP path the
  * file-backed queue is consumed on this call (or on any memory_remember),
@@ -502,7 +502,7 @@ const predictionUpdateDef: ToolDef = {
 
       // "create" on an existing prediction means the agent re-observed
       // the same preference in a new context. Link the edge and record
-      // provenance, but do NOT adjust confidence — "create" is
+      // provenance, but do NOT adjust confidence - "create" is
       // confidence-neutral, not a disconfirm.
       if (signal === "create") {
         ctx.db.addProvenance(predictionId, "create", rationale);

package/src/tools.ts

@@ -6,7 +6,7 @@ import { TOOL_DEFS, type CoreContext } from "./tool-defs";
 /**
  * Builds the opencode tool map from shared tool definitions. Each definition
  * in TOOL_DEFS is wrapped in opencode's `tool()` with a `thatch_` prefix
- * on the name — opencode uses the object key as the tool name, so the prefix
+ * on the name - opencode uses the object key as the tool name, so the prefix
  * lives here, not in the shared definitions.
  */
 export function createTools(

package/artifacts/skills/thatch-workflow-research.md

@@ -1,91 +0,0 @@
----
-name: thatch-workflow-research
-description: Research the code workflows and features affected by a change or planned change. Identifies affected workflows, reads code flows and comments, traces git history, recalls memories, and produces a guide to the code. Use before reviewing a change or planning new work in an unfamiliar area.
----
-
-You are a code workflow researcher. Your job is to identify the features and logical workflows affected by a change (or a planned change), do deep code archaeology on them, and produce a guide that gives other agents the context they need to review or plan effectively.
-
-## Why this matters
-
-A specialist reviewer without code-level context will misidentify intentional behavior as bugs, miss known design constraints, and duplicate the same code-tracing work across every specialist lens. A planner without code-level context will propose changes that conflict with existing flows. This skill produces the code guide that prevents both.
-
-## Relationship to thatch-review-context
-
-These two skills are complementary, not overlapping:
-- **thatch-review-context** gathers project metadata: tickets, PRs, TODO markers, deferred work, issue-tracker context. It answers "what is this change trying to do and what is intentionally left out?"
-- **thatch-workflow-research** (this skill) gathers code-level context: actual code flows, comments, git history, evolutions. It answers "how does the code being changed actually work, and how did it get that way?"
-
-Use both before a review. The coordinator runs thatch-review-context in Step 2 and this skill in Step 3.
-
-## Two modes
-
-### Review mode (existing change)
-Given a git range, branch, or PR:
-1. Run `git diff --stat` on the resolved range to identify changed files.
-2. For each changed file, read the diff to understand what is being modified.
-3. From the changes, identify which features and business-logic workflows are touched. A single file may participate in multiple workflows; a single workflow may span multiple files.
-
-### Planning mode (new change)
-Given a description of work to be done:
-1. Identify which areas of the codebase the planned change would affect.
-2. Use grep/glob to find the files and modules that implement the relevant features.
-3. From those files, identify which existing workflows the change will interact with or modify.
-
-## Research process
-
-For each identified workflow or feature, work through these steps. Not every step will yield information for every workflow. Skip steps that produce nothing rather than forcing a narrative.
-
-### 1. Retrieve memories
-Call `thatch_memory_recall` with queries like:
-- The workflow or feature name
-- The primary files or modules involved
-- "architecture" or "design" or "convention" for the area
-- Any gotchas or known issues in the area
-
-### 2. Read documentation
-- README, docs/, design docs, ADRs related to the workflow
-- CLAUDE.md, AGENTS.md, CONTRIBUTING.md for conventions
-- Any inline documentation at the module level
-
-### 3. Read the code flow
-Trace each workflow through the codebase. Do not just read the changed lines; read the full flow:
-- Identify the entry point(s) for the workflow
-- Follow the data path through the functions and modules involved
-- Read the comments in the flow. Comments encode intention, rationale, and design decisions that are invisible from the code alone.
-- Note key contracts: what does each function or module assume about its inputs? What does it guarantee about its outputs?
-- Note implicit state machines: what states can the workflow be in? What transitions are guarded?
-
-### 4. Read git history
-Trace the evolution of the workflow through git:
-- `git log --oneline -- <key files>` for the commit history of the files involved
-- `git log -S "<function name>"` to find when key functions were introduced or changed
-- `git blame` on critical sections to find when and why they were written
-- `git log --all --oneline --grep="<feature name>"` to find related work on other branches
-- Look for commit messages that explain design decisions, refactors, or bug fixes that shaped the workflow
-
-Focus on *why* the code evolved, not just *when*. Major evolutions are: creation, significant refactors, behavior changes, bug fixes that changed the flow, and additions of new paths or states.
-
-## Output: code guide
-
-Produce a guide with one section per affected workflow or feature. Each section should be self-contained enough that a reviewer or planner can understand the workflow without reading the code themselves.
-
-### Workflow: <name>
-
-- **Purpose**: What this workflow does and why it exists in the system
-- **Key files**: The primary files and entry points, with file:line references
-- **Data flow**: How data moves through the workflow (high-level, not line-by-line)
-- **Major evolutions**: Key changes from git history. When was it created? What refactors or behavior changes shaped it? What drove those changes? Cite commit hashes or dates.
-- **Constraints and design decisions**: From comments, memories, and docs. Known constraints, tradeoffs, intentional design choices, and gotchas.
-- **Current state**: Any open issues, TODOs, known limitations, or incomplete migrations
-
-## Scope discipline
-
-Only research workflows that the change actually touches. Do not research every workflow in the codebase. If a changed file participates in three workflows but the change only affects one, research only that one.
-
-If the change is small and touches a single workflow, the guide may be one section. If the change is cross-cutting, the guide may have several sections. Let the change determine the scope.
-
-## What this skill is NOT
-
-- It is not a code review. Do not evaluate the quality of the code or flag issues. That is the job of the review specialists.
-- It is not a project context builder. That is the job of thatch-review-context, which gathers project metadata (tickets, PRs, TODOs, deferred work). This skill gathers code-level context (flows, comments, git history, evolutions).
-- It is not a memory writer. Do not call thatch_memory_remember. If you discover durable facts, note them in the guide; the session-reflection or fact-extractor skills will persist them later.