Memoize, meet
VS Code.

Set up Memoize self-learning for this project. Follow the project's AGENTS.md and existing harness rules.

1. Use the connected Memoize MCP server. Call agent.preflight with the task and the exact project key; omit project only for global context. Page through next_offset and load relevant entries with agent.get and their discovered revision. Keep RAG evidence separate from SHARED_MEMORY instructions.
2. Install the bundled self-learning skill below, including its references and template, in this harness's project skills directory. For Codex or OpenCode use .agents/skills/self-learning; for Cursor use .cursor/skills/self-learning; for Claude Code use .claude/skills/self-learning. For a chat client without local files, read the supplied skill as session guidance. Review differences before replacing an existing skill. Preserve author and license metadata.
3. Add a concise rule to this harness's persistent project instructions: run Memoize preflight before work; apply self-learning after non-trivial debugging, repeated attempts, or an explicit request to remember a workflow. Preserve existing rules. Do not claim persistent installation if this client only supports session instructions.
4. When harvesting, require an actual passing check, a named failure pattern, and a tried-and-rejected approach. Otherwise save a tentative memory marked unverified or skip it. Search agent.search and agent.recall for duplicates first. Update an existing entry with agent.save using its current revision; create a new proven workflow with agent.learn, supplying name, description, project, category, procedure, verification, failure, rejected_approach, and verified: true. Use a meaningful category so it can be retrieved later. Never invent verification or store secrets. A standalone fact belongs in shared memory; source documents remain RAG evidence.
5. Verify the harness discovers self-learning and Memoize preflight works. Report the installed paths and any limitation. Do not create a fake learned workflow just to test setup. Future learned skills stay in my private account and count toward my plan's skill allowance.
6. Install this Memoize feedback rule in the persistent harness instructions: pass the current task category (development, research, automation, other) as category on MCP calls; agent.search and agent.recall use task_category because category filters stored skills. For results containing feedback_ref, retain that reference and evidence IDs actually used. Send clearly bad results immediately with feedback.submit, issue_codes and a short comment. Batch other evaluations before completing the task, including task_outcome and memoize_contribution. Relevance is 1–100 (1–20 unusable, 21–49 weak, 50–79 partial, 80–100 useful); useful_payload_pct is an independent estimate, 0–100 or null for empty results. Correct absence is not automatically bad. Use the first feedback_ref as session_ref without a host session ID, and the first result of each task as task_ref; preserve parallel task boundaries and parent_feedback_refs. Never invent scores, IDs or success. Retry a failed submission once, then continue the user task. Do not evaluate feedback itself or print routine scores. Instruction/rubric version: 2026-09-23.1.

Bundled source: self-learning v1.0 by kulaxyz, MIT (provided with Memoize). The three files below are the original skill and its supporting files; the setup steps above adapt storage to Memoize.

--- BEGIN self-learning/SKILL.md ---
---
name: self-learning
description: >
  Capture a hard-won "golden path" from the current session as a reusable Agent
  Skill, so future sessions start already knowing it. Use it (1) right after
  non-trivial debugging, after working out a multi-step operational workflow, or
  after rediscovering project facts you didn't know up front — e.g. how to reach
  the dev/prod database, where credentials and env vars live, how to deploy, run
  migrations, or verify a change live; and (2) whenever the user says "remember
  this", "save this as a skill", "make a skill for this", "don't make me
  re-explain this next time", or otherwise wants a workflow preserved across
  sessions. Proactively recognize the moment even when unprompted: if a task took
  several attempts before it worked, used non-obvious tooling, or is likely to
  recur, harvest it without asking first. Delegates to a subagent when your tool
  supports one, or works inline, to extract the proven procedure into a new
  project-local or global skill.
license: MIT
metadata:
  author: kulaxyz
  version: "1.0"
---

# Self-learning: harvest golden paths into skills

This skill turns something you just figured out the hard way into a reusable
Agent Skill, so the next session — yours or a teammate's — starts already
knowing the proven route instead of rediscovering it from scratch.

It is a *meta-skill*: it doesn't do the work, it captures **how** work got done.
It's tool-neutral — it works with any agent that reads the Agent Skills format
(e.g. Claude Code and Codex, which both load `SKILL.md` skills natively). Where a
step differs by tool, the generic version comes first and any tool-specific
detail is only an example.

## Recognize the moment

Watch for these signals during normal work. Any one of them is a cue to harvest:

- A task only worked **after several attempts**, wrong turns, or a correction
  from the user. The successful path is worth more than the failures around it.
- You discovered **project-specific facts the agent didn't know up front**:
  where creds/env vars live, which selector or backend talks to a service, a
  non-obvious command, a required sequence, a gotcha that defies the obvious
  assumption.
- It's an **operational workflow likely to recur**: reach the dev/prod DB,
  deploy, run migrations, seed data, verify a change live, run one specific
  test path, rotate a key, tail the right logs.
- The user **signals it explicitly**: "remember this", "save this as a skill",
  "don't make me re-explain this next time".

**Act on the cue immediately — don't ask for permission first**, whether the
user requested it or you noticed it yourself. Harvest the skill, then tell the
user what you captured and where (step 5). They can always edit or delete it.

### Skill, memory, or skip?

Not every lesson deserves a whole skill — triage first, so you don't bloat the
skills list with one-liners:

- **A multi-step, reusable procedure or workflow** (how to deploy, reach the DB,
  run the migration dance, verify live) → harvest it as a **skill** using the
  procedure below.
- **A single standalone fact or one-line correction** (an env var name, a path,
  one gotcha) → if your harness has a lightweight memory/notes facility (e.g. a
  `MEMORY.md` index), record it **there** instead; a whole skill is overkill for
  a one-liner. With no such facility, make a small skill.
- **A genuinely one-off thing** unlikely to recur → skip it.

When you do harvest, capture the **failures too**, not just the win: the
approaches you ruled out and *why* often save more time next session than the
golden path itself.

### Promotion rule: don't enshrine guesses

A skill is authoritative — the next session trusts it without re-deriving it —
so hold promotion to a high bar. Only write a skill when **all three** hold:

1. **A passing check.** The path was actually verified — a test passed, the
   command exited clean, the repro reproduced, the build went green. Record what
   the check was. "Seemed to work" is not a passing check.
2. **A named failure pattern.** You can name the failure this path avoids or
   diagnoses (e.g. "stale build cache → phantom type errors"), not a vague
   "sometimes it breaks".
3. **At least one ruled-out dead-end.** A concrete approach you tried and
   eliminated, with the reason.

If any is missing, it isn't a skill yet — leave a tentative note in memory
(marked unverified) or skip it. This keeps confident guesses out of the skill
set.

## Harvest procedure

- [ ] 1. **Apply the promotion rule** (above). Passing check + named failure
      pattern + one ruled-out dead-end — or it isn't a skill: note it in memory
      or skip. Don't proceed on a confident guess.
- [ ] 2. **Choose scope and name yourself** using the heuristics below — don't
      stop to ask. Default to project scope; pick a clear, specific `name`.
- [ ] 3. **Dedupe.** Look for an existing skill to UPDATE rather than duplicate.
      List your agent's skills directories — the project one and the user-level
      one (e.g. Claude Code `.claude/skills` + `~/.claude/skills`, Codex
      `.codex/skills` + `~/.codex/skills`, or your tool's equivalent). Also
      glance at any memory/notes index — a fact already there may just need a
      pointer.
- [ ] 4. **Distill the golden path from THIS conversation** before delegating —
      while it's fresh in your head: the exact working commands, file paths, env
      var names, the required order, and (just as important) the dead-ends to
      avoid. This is the raw material for the write.
- [ ] 5. **Delegate the write** to a subagent that inherits this conversation if
      your tool supports one, or do it inline otherwise — see below. The
      conversation is the only place the golden path lives, so whoever writes it
      must have that context.
- [ ] 6. When the write is done, **relay the new skill's path** to the user
      and, in one line, what it captured.

### Scope: project vs global

- **Project** (the repo's skills directory — e.g. `.claude/skills/`,
  `.codex/skills/`): the path is specific to THIS codebase — its env vars, its
  build/release steps, its schema, its quirks. Most harvested operational skills
  are project-scoped, and they ship to the team via git.
- **Global** (your user-level skills directory — e.g. `~/.claude/skills/`,
  `~/.codex/skills/`): the path generalizes across projects — a personal tool, a
  cross-repo habit, or a workflow tied to your machine rather than to one repo.

When unsure, prefer **project** — an over-shared global skill triggers in repos
where its commands don't apply.

## Delegate the write (subagent, or inline)

Whoever writes the skill needs THIS conversation's context — it's the only place
the golden path lives. Two equally valid ways to run it:

- **Inline** — do the steps yourself in the main loop. Always works.
- **Subagent** — if your tool can delegate to a subagent that **inherits this
  conversation**, use it to keep the harvesting work out of your main context.
  (Claude Code: a skill with `context: fork`. Codex and others spawn subagents
  their own way.) Don't hand it to a *fresh* agent with no context — it would
  start blank with nothing to extract.

Either way it over-reaches by default, so box it in tightly. Follow this brief
(fill in the bracketed parts) — hand it to the subagent, or work through it
yourself inline:

> You are harvesting a skill. Your ONLY job is to write a new Agent Skill
> capturing the golden path we just worked out in this conversation:
> **[one-line description of the workflow]**.
>
> Hard rules:
> - Write ONLY under `[skills dir]/[skill-name]/`. Do NOT modify project
>   source, run builds, install anything, or resume the original task.
> - First read `[this-skill-dir]/references/skill-authoring.md` and
>   `[this-skill-dir]/assets/SKILL.template.md`, then author `SKILL.md` to that
>   spec, plus any `references/` or `assets/` files the procedure warrants.
> - Capture the PROCEDURE — commands, paths, the required order, gotchas — not a
>   one-off answer. Generalize so it works next time.
> - Capture the FAILURES too: the approaches we ruled out and why, so the next
>   session skips the dead-ends. Put them in a "What didn't work" section.
> - Enforce the promotion rule: the skill must record the passing check that
>   verified this path, name the failure pattern it addresses, and list at least
>   one ruled-out dead-end. If any is missing (e.g. nothing was actually
>   verified), STOP and report it isn't promotable — leave a tentative memory
>   note instead of writing the skill.
> - NEVER write secret VALUES (passwords, tokens, connection strings, API keys).
>   Record only WHERE to find them: the env var name, the selector function, the
>   MCP tool, the secret manager. Reproducing a secret into a skill file leaks it.
> - Self-validate before finishing (see the checklist in skill-authoring.md).
> - Report back: the absolute path you wrote and a one-line summary. Then STOP —
>   do not pick the original task back up.

## Gotchas

- **Secrets never go in a skill file.** Skills get committed and open-sourced.
  Point to *where* the secret lives; never reproduce the value. This is the
  single most important rule in this skill.
- **`name` must equal the directory name**, and be lowercase `a-z`/`0-9`/hyphens
  only — no leading, trailing, or doubled hyphens. A mismatch means the skill
  won't load.
- **Whoever writes the skill over-reaches by default** (a subagent especially).
  That's why the brief above forbids touching project source or resuming the
  task — keep it boxed to the skills directory.
- **Don't duplicate.** If a near-identical skill (or memory) already exists,
  update it instead of spawning a second one that competes to trigger.
- **Capture procedures, not answers.** "Join orders to customers for EMEA" is
  useless next time; "how to find the right tables and build the query" is the
  skill. See `references/skill-authoring.md`.
- **Keep `SKILL.md` tight** (< 500 lines, < ~5000 tokens). Push detail into
  `references/` and tell the reader *when* to load each file.

For the full authoring spec, see
[references/skill-authoring.md](references/skill-authoring.md). The fill-in
template is [assets/SKILL.template.md](assets/SKILL.template.md).
--- END self-learning/SKILL.md ---

--- BEGIN self-learning/references/skill-authoring.md ---
# Skill authoring spec

Read this before writing a harvested skill. It is a condensed version of the
Agent Skills specification and best-practices, focused on what you need to
produce a good, well-triggering, safe skill. Source: https://agentskills.io

## Directory structure

```
<skill-name>/
├── SKILL.md          # required: YAML frontmatter + Markdown body
├── references/       # optional: docs the agent loads on demand
├── assets/           # optional: templates, schemas, static resources
└── scripts/          # optional: executable code the agent can run
```

`SKILL.md` MUST live at the skill root. Only the root `SKILL.md` is parsed as a
skill — files with frontmatter inside `references/`/`assets/` are inert (safe to
use as templates).

## Frontmatter

| Field           | Required | Rules |
|-----------------|----------|-------|
| `name`          | yes  | 1–64 chars, lowercase `a-z`/`0-9`/`-` only, no leading/trailing/`--`. **Must equal the directory name.** |
| `description`   | yes  | 1–1024 chars. Says **what it does AND when to use it**. Carries the entire triggering burden. |
| `license`       | no   | License name or a bundled file reference (e.g. `MIT`). |
| `compatibility` | no   | ≤500 chars. Only if there are real environment requirements (tools, network, runtime). Most skills omit it. |
| `metadata`      | no   | Arbitrary string→string map (e.g. `author`, `version`). |
| `allowed-tools` | no   | Space-separated pre-approved tools (experimental; support varies). Omit unless you have a reason. |

Minimal valid frontmatter:

```markdown
---
name: my-skill
description: What it does and when to use it.
---
```

## Writing the description (the most important field)

At startup the agent loads only `name` + `description` for every skill, and uses
the description to decide whether to load the body. Get this wrong and the skill
never fires (or fires when it shouldn't).

- **Imperative + "when".** "Use this skill when…", not "This skill does…".
- **What + when, both.** State the capability and the trigger situations.
- **Be pushy about triggers.** List the contexts it applies to, including when
  the user won't name the domain: "…even if they don't mention 'X'."
- **Match user intent, not internals.** Describe what the user is trying to do.
- **Concise.** A few sentences to a short paragraph. Hard limit 1024 chars.

```yaml
# weak
description: Process CSV files.

# strong
description: >
  Analyze CSV/TSV/Excel data — summary stats, derived columns, charts, cleaning.
  Use when the user has a tabular data file and wants to explore, transform, or
  visualize it, even if they don't explicitly say "CSV" or "analysis."
```

## Body content

No required format, but favor this shape:

1. One or two lines on what the skill is for.
2. **Procedure** — numbered/checklist steps, with a clear default at each choice.
3. A short worked example (input → command → output) when it helps.
4. **Gotchas** — see below; often the highest-value part.

Calibrate prescriptiveness to fragility:
- **Be exact** for fragile/destructive/order-dependent steps ("run exactly this
  command, don't add flags").
- **Give freedom + explain why** where several approaches are valid.
- **Provide a default, not a menu.** Name one tool/approach; mention an
  alternative briefly as an escape hatch.
- **Procedures over declarations.** Teach how to approach the class of problem,
  not the answer to one instance — that's what makes it reusable.

### Add what the agent lacks, omit what it knows

Spend tokens only on what the agent wouldn't get right on its own: project
conventions, the specific commands/paths/tools, and non-obvious edge cases.
Don't explain what a database or a deploy is. For each line ask: "Would the
agent get this wrong without it?" If no, cut it.

### Gotchas section (high value)

Concrete corrections to mistakes the agent *will* make otherwise — not generic
advice. Keep these in `SKILL.md` so they're read before the situation arises.

```markdown
## Gotchas
- The `users` table uses soft deletes — queries need `WHERE deleted_at IS NULL`.
- The `/health` endpoint returns 200 even when the DB is down; use `/ready`.
- Creds live in env var `FOO_TOKEN` (see `lib/clients/foo-real.ts`), never in code.
```

### Useful patterns (use the ones that fit)

- **Checklist** for multi-step workflows with dependencies.
- **Validation loop**: do the work → run a check → fix → repeat until it passes.
- **Plan-validate-execute** for batch/destructive ops.
- **Output template** when a specific format is required (agents pattern-match
  templates better than prose).

## Progressive disclosure

- Keep `SKILL.md` under **500 lines / ~5000 tokens**.
- Move long reference material to `references/`, templates to `assets/`,
  reusable code to `scripts/`.
- Reference them with **relative paths**, one level deep, and tell the agent
  *when* to load each: "Read `references/api-errors.md` if the API returns a
  non-200." A generic "see references/" defeats the purpose.

## Secrets safety (non-negotiable)

Harvested skills get committed and often open-sourced. **Never write a secret
value** — no passwords, tokens, connection strings, API keys, or private
endpoints. Record only **where to find it**: the env var name, the selector
function, the MCP tool, the secret manager / vault entry. If you catch yourself
pasting a value, replace it with its source.

## Self-validation checklist (run before finishing)

- [ ] **Promotion rule met**: the skill records a passing check that verified the
      path, names the failure pattern it addresses, and lists ≥1 ruled-out
      dead-end. If any is missing, this shouldn't be a skill — stop and report it.
- [ ] `SKILL.md` exists at the skill root.
- [ ] `name` matches the directory name and the regex (lowercase, hyphen rules).
- [ ] `description` is non-empty, ≤1024 chars, and states what + when.
- [ ] Body is a generalized **procedure**, not a one-off answer.
- [ ] No secret values anywhere in the skill — only pointers to them.
- [ ] `SKILL.md` is under ~500 lines; long material is in `references/`/`assets/`.
- [ ] Relative file references are correct and one level deep.

Optional, if `skills-ref` is installed:
`skills-ref validate <path-to-skill>` checks frontmatter and naming.
--- END self-learning/references/skill-authoring.md ---

--- BEGIN self-learning/assets/SKILL.template.md ---
---
name: REPLACE-with-skill-name-matching-this-directory
description: >
  REPLACE. One short paragraph (≤1024 chars). Say WHAT the skill does AND WHEN
  to use it. Use imperative phrasing ("Use this skill when…"), be pushy about
  trigger situations, and list contexts even when the user won't name the
  domain. Match user intent, not internals.
license: MIT
metadata:
  author: REPLACE
  version: "1.0"
---

# REPLACE — title of the golden path

One or two sentences: what this captures and the situation it's for.

<!-- Promotion rule: fill BOTH lines. If you can't, this shouldn't be a skill. -->
**Failure pattern:** REPLACE — the failure this path avoids or diagnoses.
**Verified by:** REPLACE — the passing check that confirmed it (test passed, clean
exit, green build, reproduced repro). Not "seemed to work".

## When to use this

- REPLACE: the concrete trigger(s) — the recurring task or situation this serves.

## Procedure

<!-- Teach the METHOD, not a one-off answer. Be exact for fragile/ordered steps;
     give freedom (and say why) where several approaches work. Default, not menu. -->

- [ ] 1. REPLACE — first step (exact command / path if fragile).
- [ ] 2. REPLACE — next step, with the required order if it matters.
- [ ] 3. REPLACE — how to verify it worked.

### Example

```
REPLACE — a short, real input → command → expected output, if it helps.
```

## Gotchas

<!-- The highest-value section. Concrete corrections to mistakes that WILL happen
     otherwise — not generic advice. Record where secrets live, never their value. -->

- REPLACE — a non-obvious fact that defies the reasonable assumption.
- REPLACE — where creds/config live (env var name, selector fn, MCP tool, vault),
  NEVER the secret value itself.

## What didn't work

<!-- Required by the promotion rule: list at least one approach you ruled out and
     WHY, so the next session skips the dead-end instead of re-discovering it. -->

- REPLACE — approach that looked right but failed, and the reason.

<!-- Optional: move long reference material to references/ and templates to
     assets/, and tell the reader WHEN to load each. Keep this file < 500 lines. -->
--- END self-learning/assets/SKILL.template.md ---