Teaching Freddy's Team

Freddy has a team of one human and several models — and every session, the models show up with amnesia. This chapter is about making knowledge stick: memory for facts, skills for procedures, snippets for prompts, blueprints for whole sessions.

The problem

On Tuesday you spent ten minutes explaining Freddy's one real gotcha: the notes_fts table is kept in sync by SQLite triggers, so writing to it directly corrupts the index. The agent understood perfectly, worked around it beautifully — and on Thursday, in a fresh session, it wrote an INSERT INTO notes_fts like the conversation never happened. It hadn't. Session knowledge evaporates when the session ends, and every new session starts as the new hire's first day.

The hard way

There are two bad fixes. The first is re-explaining forever — you become a human onboarding document, reciting the same three gotchas at the top of every session. The second is stuffing everything into AGENTS.md until it's four hundred lines of rules, facts, war stories, and half-remembered decisions. A junk drawer that long stops being read carefully — by the model, and honestly, by you. Rules files work because they're short.

The Elyra way: project memory

Enable codebaseMemory in /settings and Elyra persists project knowledge across sessions — facts it learned while working, carried forward without you lifting a finger. /memory shows and manages what's stored:

/memory

  Project memory (freddy):
  - notes_fts is kept in sync by triggers — never write to
    it directly
  - tag attach is create-or-attach in Note::attachTags()
  - composer test is the only sanctioned test runner
  - archived notes are excluded from search by design (SPEC)

That first entry is Tuesday's explanation, still alive on Thursday. Memory entries are facts — small, declarative, learned once. They ride into every session the way AGENTS.md does, but they accumulate from the work itself instead of from you writing documentation.

Skills with /learn

Facts aren't the only thing worth keeping. In Chapter 9 the swarm built Freddy's FTS5 search, and along the way a real procedure emerged: create the virtual table, add insert/update/delete triggers, backfill existing rows, verify with a rebuild. That's not a fact — it's a recipe. Extract it before the session ends:

/learn

  Extracting a skill from this session...
  Skill saved: fts5-sync-triggers
  Steps: create virtual table (external content), add
  insert/update/delete triggers, backfill, verify with
  integrity check. Pitfall recorded: never write to the
  FTS table directly.

/learn turns the session's hard-won procedure into a named skill. Next month, when Freddy's tags need their own searchable index, the skill is invocable by name — and because it's a file, it's shareable with anyone else building on the same stack. The distinction to hold on to: memory is facts, skills are procedures with steps.

Snippets and blueprints

Some knowledge is neither fact nor procedure — it's a prompt you keep retyping. Those live in .elyra/snippets/*.md as reusable instruction blocks, sent with /snippet [name]. Freddy's most-used one is the pre-merge ritual:

# .elyra/snippets/pre-merge.md
Before we merge: run composer test and make it green, run
/review --cross on the full diff, and run
design_system_check on every Svelte file we touched.

/snippet pre-merge

One keystroke instead of three sentences, and the ritual never loses a step because you were tired.

Blueprints go one level up: /blueprint [name] applies a whole session template. Freddy's "feature" blueprint pins SPEC.md and sets the standard prompt shape from Chapter 4 — scope, constraints, definition of done — so every feature session starts identically:

/blueprint feature

  Applied blueprint: feature
  - Pinned: SPEC.md
  - Prompt template: scope + constraints + definition of done

The first five minutes of a session used to be setup. Now they're work.

What goes where

Five containers, five jobs. When you're unsure where a piece of knowledge belongs, this table is the answer:

Container	Holds	Example
AGENTS.md	Rules, always loaded	"Svelte 5 runes only, never npm run dev"
Memory	Facts learned	"notes_fts is synced by triggers"
Skills	Procedures with steps	fts5-sync-triggers
Snippets	Reusable prompts	pre-merge checklist
Blueprints	Session setups	"feature": pin SPEC.md, standard prompt

What you learned

• AGENTS.md is for rules, and it only works while it stays short. Don't make it a junk drawer.
• Memory is for facts. Enable codebaseMemory, manage with /memory — Tuesday's explanation survives to Thursday.
• Skills are for procedures. /learn extracts them from the session that discovered them, named and shareable.
• Snippets are for prompts, blueprints are for sessions. /snippet pre-merge and /blueprint feature replace retyping with a keystroke.
• Knowledge you don't persist is knowledge you'll pay for again — in tokens, in minutes, or in a corrupted FTS index.