AGENT SKILL

naive-memory

This skill should be used at the end of a session (or when explicitly asked) to persist generalizable, repository-specific knowledge to .genai/memory.md. It acts as a note-to-self scratchpad for LLMs, capturing lessons learned so future sessions start with useful context. At the start of any session, check if .genai/memory.md exists in the repository root — it may contain valuable context from previous sessions.

License 许可
MIT
最近更新
2026-11-10
Stars
★ 0
Forks
0

01 前言 Front Matter

name
naive-memory
description
This skill should be used at the end of a session (or when explicitly asked) to persist generalizable, repository-specific knowledge to .genai/memory.md. It acts as a note-to-self scratchpad for LLMs, capturing lessons learned so future sessions start with useful context. At the start of any session, check if .genai/memory.md exists in the repository root — it may contain valuable context from previous sessions.

03 SKILL.md 正文

Naive Memory

Overview

Persist useful, repository-specific knowledge discovered during a session into a shared memory file at .genai/memory.md in the repository root. This file serves as a durable scratchpad that any LLM agent can read at the start of future sessions to avoid rediscovering the same information.

When to Invoke

  • At the end of a working session, before closing out
  • When explicitly asked to "remember" or "save notes"
  • After resolving a non-obvious problem where the solution would help future sessions

Workflow

1. Reflect

Ask yourself:

Is there any generalizable knowledge specific to this repository that I wish I'd known prior to this conversation that would have made work more efficient?

Only proceed if the answer is yes.

2. Read existing memory

Read .genai/memory.md from the repository root. If the file does not exist, create it with a # Notes to self heading.

3. Evaluate before writing

Add a new entry under # Notes to self IF AND ONLY IF all of the following are true:

  1. The knowledge is not already documented in the file
  2. The knowledge is generally useful for future work on this repository
  3. The knowledge is unlikely to change soon (avoid transient details)
  4. The knowledge is specific to this repository (not general programming knowledge)

4. Write the entry

Each entry must include:

  • Timestamp: ISO 8601 date (YYYY-MM-DD)
  • Model name: The model that authored the entry (e.g., claude-opus-4-6)
  • Content: Concise, accurate, actionable knowledge

Format:

## <Topic>

_Added: YYYY-MM-DD by <model-name>_

<knowledge>

5. Maintain the file

  • Keep the file concise — remove or update entries that are outdated or proven wrong
  • Deduplicate — if new knowledge supersedes an existing entry, replace rather than append
  • Organize semantically by topic, not chronologically

Anti-patterns

  • Do NOT document session narratives ("Today I fixed bug X")
  • Do NOT include secrets, credentials, or API keys
  • Do NOT add general programming knowledge ("Python uses indentation")
  • Do NOT add information that is already obvious from the codebase structure
  • Do NOT add entries on every session — only when genuinely useful knowledge was discovered

04 同仓库更多 Skills

tzeusy-org
tzeusy-org/ai-bootstrap

user-run

Use when a step needs privileges this session lacks (docker, sudo, another user's checkout or secrets, host access) and the owner must run it as tze. Writes a reviewable /home/orca/.tmp/<slug>/run.sh that impersonates tze (USER_TO_IMPERSONATE overrides), tees timestamped logs plus latest.log and collects artifacts there; Claude presents it with a risk and time brief, then continues from the logs. Triggers: "I'll run it for you", "permission denied on docker.sock", "needs sudo", "sudo: a password is required", "run as tze", "/user-run".

★ 0
tzeusy-org
tzeusy-org/ai-bootstrap

requesting-code-review

Use when completing tasks, implementing major features, or before merging to verify work meets requirements

开发工程师代码审查
★ 0
tzeusy-org
tzeusy-org/ai-bootstrap

receiving-code-review

Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation

开发工程师代码审查
★ 0
tzeusy-org
tzeusy-org/ai-bootstrap

finishing-a-development-branch

Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup

★ 0
tzeusy-org
tzeusy-org/ai-bootstrap

executing-plans

Use when you have a written implementation plan to execute in a separate session with review checkpoints

★ 0
tzeusy-org
tzeusy-org/ai-bootstrap

dispatching-parallel-agents

Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies

★ 0