3 layer of memory system

Always active in every session. Learns user preferences from corrections and stated preferences, distills axioms, applies them as defaults. Makes every other...

Security Scan

The skill's requirements and runtime instructions are coherent with a session-persistent preference memory: it reads/writes a dedicated memory/context-infra directory and promotes repeated signals to a small, reusable profile.

Purpose & Capability

Name/description (persistent, cross-session preference memory) align with the instructions: reading/writing memory/context-infra, recording corrections/preferences, clustering into axioms. No unrelated binaries, env vars, or external services are requested.

Instruction Scope

SKILL.md limits operations to files under memory/context-infra and to three signal types (correction, stated-preference, retraction). This is within scope. Note: the skill rewrites context-profile.md during reflection and appends observations.log; that can overwrite any user-edited profile and will persist defaults applied across future conversations. Also, recorded strings could include sensitive info if the user states preferences containing secrets — the skill does not filter content beyond the 15-word guidance.

Install Mechanism

Instruction-only skill with no install spec or code files — lowest install risk. Nothing is downloaded or executed on disk besides writing to the memory directory.

Credentials

No environment variables, credentials, or config paths are requested. The only filesystem access is to memory/context-infra, which is proportional to a preference-memory feature.

Persistence & Privilege

The skill is designed to persist and apply axioms across sessions (expected for a memory system). Registry flags show always:false (not force-included), and model invocation is allowed (normal). Note the description claims "Always active in every session" which conflicts with the registry always:false; confirm how the platform will invoke the skill if you want guaranteed per-session loading.

Assessment

This skill is coherent with its stated purpose: it will read and write two files in memory/context-infra (observations.log and context-profile.md), automatically distill recurring preferences into axioms, and apply them as soft defaults across future conversations. Before installing, consider: (1) backup any existing context-profile.md if you manually maintain a profile — the skill will rewrite it during reflection; (2) avoid stating secrets or highly sensitive preferences in free text, since the skill persists short lines from your input; (3) decide whether you want automatic, cross-session learning or prefer to review changes before they’re applied — ask the author for an opt-in/preview step if you want manual approval of promoted axioms; (4) confirm the platform’s invocation behavior (the skill claims “always active” but registry shows always:false). If those points are acceptable, the skill appears internally consistent and proportionate.

Smarty Skills-Infra

You maintain a lightweight memory of this user's preferences, judgments, and working style. Memory operations never interrupt the user's workflow.

At Session Start

Do this before addressing the user's request.

1. Read memory/context-infra/context-profile.md if it exists. Treat axioms as your own defaults — adapt when the situation differs. If missing, skip.

2. Check memory/context-infra/observations.log. If it has 15+ entries since the last ## Reflected marker, reflect before starting the user's task. Say exactly: "Consolidating patterns from recent work." Then follow When Reflecting below. Never interrupt a task to reflect.

On first session (no files exist), skip both steps and start observing.

During Every Task

Record ONLY when a trigger fires:

• Correction: the user changes, rewrites, or redirects your output
• Stated preference: the user explicitly says they prefer, want, or dislike something
• Retraction: the user asks to forget, stop applying, or undo a remembered preference

Most tasks produce zero observations.

Append one line to memory/context-infra/observations.log:

YYYY-MM-DD | domain | signal | "Preference in ≤15 words."

• domain: organic label (e.g. code-style, architecture, communication, tooling, testing, workflow)
• signal: correction | stated-preference | retraction

One observation per preference per session.

Bootstrap mode (first 2 sessions) — cast a wider net: also note what the user accepts without comment and consistent choices.

Do not record: routine completions, project-specific facts, or one-time decisions.

When Reflecting

Four steps:

1. Group: Read observations and profile. Cluster by domain, merging near-duplicates.
2. Promote: Promote when a pattern appears across 3+ distinct contexts (different days or projects), has no contradictions, and is a preference not a fact. Each axiom must be specific enough to change behavior, yet general enough to apply across projects. See references/profile-format.md for format.
3. Maintain: Increment strength for reinforced axioms. Mark contradictions as contested. Remove axioms targeted by a retraction immediately — no threshold needed. Merge related axioms. Move unconfirmed (30+ days) to Dormant. Cap at 25 — if at cap, merge related axioms or demote lowest-strength to Dormant before promoting.
4. Clean up: Rewrite the profile. Rewrite observations.log: keep only un-promoted entries, prepend ## Reflected YYYY-MM-DD.

Create missing files on first write. Never fail silently.

Example

Observations:

2026-01-15 | code-style | correction | "User shortened verbose function name."
2026-01-18 | code-style | correction | "User rejected descriptive name, asked for abbreviation."
2026-02-01 | code-style | stated-preference | "User uses 2-3 word function names in new project."

3 distinct contexts, 0 contradictions — promoted:

- I prefer short, concise names — abbreviate rather than spell out.
  strength: 3 | domain: code-style | last-confirmed: 2026-02-01

NOT promoted if all observations were same-session — same-session repeats count as one context.