mema-kit 1.0.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md ADDED
@@ -0,0 +1,105 @@
1
+ # mema-kit
2
+
3
+ Memory protocol kit for Claude Code skills. Give any skill persistent, curated memory across sessions.
4
+
5
+ **What it does:** A `.mema/` directory in your project stores architecture decisions, requirements, lessons learned, and reusable patterns as curated markdown. Skills automatically load relevant context at the start of each session and save curated knowledge when done.
6
+
7
+ **Key differentiator:** The memory protocol (AUTO-LOAD → WORK → AUTO-SAVE & CURATE → AUTO-INDEX) is a reusable pattern. Any skill you build can plug into it — not just the two that ship with mema-kit.
8
+
9
+ ## Quick Start
10
+
11
+ ```bash
12
+ # 1. Install skills into your project
13
+ npx mema-kit
14
+
15
+ # 2. Open Claude Code and bootstrap memory
16
+ claude
17
+ > /onboard
18
+ ```
19
+
20
+ `/onboard` scans your project, creates the `.mema/` memory structure, populates initial architecture and requirements docs, and configures CLAUDE.md and `.gitignore`.
21
+
22
+ ## Built-in Skills
23
+
24
+ | Command | Purpose |
25
+ |---------|---------|
26
+ | `/onboard` | Bootstrap memory for a project — scans codebase, creates `.mema/`, populates initial knowledge |
27
+ | `/create-skill` | Generate a new memory-aware skill with the correct lifecycle phases |
28
+
29
+ ## How Memory Works
30
+
31
+ mema-kit uses a `.mema/` directory in your project to persist knowledge between sessions:
32
+
33
+ ```
34
+ .mema/
35
+ ├── index.md # Memory map — agent reads this first
36
+ ├── project-memory/ # Architecture, requirements, decisions
37
+ │ └── decisions/ # Individual decision records with reasoning
38
+ ├── task-memory/ # Per-task context, plans, active work
39
+ ├── agent-memory/ # Lessons learned, reusable patterns
40
+ └── archive/ # Completed task memories
41
+ ```
42
+
43
+ - **Auto-load**: Skills read `index.md` and load only the files relevant to the current task.
44
+ - **Auto-save**: After work, the agent curates findings into the right memory files.
45
+ - **Auto-prune**: Noise is removed; only actionable knowledge is kept.
46
+ - **Self-healing**: If `index.md` gets out of sync, the next skill rebuilds it from the directory structure.
47
+
48
+ Memory is just markdown. Open any file to see what the agent knows. Edit directly if something's wrong.
49
+
50
+ ## The Memory Protocol
51
+
52
+ Every memory-aware skill follows four phases:
53
+
54
+ 1. **AUTO-LOAD** — Read `index.md`, decide what's relevant, load only those files
55
+ 2. **WORK** — Execute the skill's core purpose with loaded context
56
+ 3. **AUTO-SAVE & CURATE** — For each piece of knowledge, decide: ADD / UPDATE / DELETE / NOOP
57
+ 4. **AUTO-INDEX** — Update `index.md` to reflect all changes
58
+
59
+ The protocol is defined in `_memory-protocol.md` and shared across all skills (never duplicated). See [docs/guide.md](docs/guide.md) for the full protocol reference.
60
+
61
+ ## Building Your Own Skills
62
+
63
+ Use `/create-skill` to generate memory-aware skills:
64
+
65
+ ```
66
+ > /create-skill
67
+
68
+ Skill name: review
69
+ Purpose: Review code changes for quality and consistency
70
+ Complexity: standard
71
+ ```
72
+
73
+ This creates `.claude/skills/review/SKILL.md` with the full 4-phase memory lifecycle wired in. Three complexity levels are available:
74
+
75
+ - **Simple** (3 phases) — Read-only skills like code review, linting
76
+ - **Standard** (4 phases) — Most skills that read and write memory
77
+ - **Advanced** (4 phases + task management) — Multi-step workflows with archiving
78
+
79
+ See [docs/guide.md](docs/guide.md) for a complete worked example.
80
+
81
+ ## Updating
82
+
83
+ ```bash
84
+ npx mema-kit --update
85
+ ```
86
+
87
+ Updates skill files only. Never touches `.mema/`, CLAUDE.md, or `.gitignore`.
88
+
89
+ ## Requirements
90
+
91
+ - Node.js >= 16.7.0
92
+ - [Claude Code](https://claude.ai/code)
93
+
94
+ ## Documentation
95
+
96
+ See [docs/guide.md](docs/guide.md) for the full usage guide with worked examples and protocol reference.
97
+
98
+ ## Links
99
+
100
+ - [npm package](https://www.npmjs.com/package/mema-kit)
101
+ - [GitHub repository](https://github.com/simonv15/mema-kit)
102
+
103
+ ## License
104
+
105
+ MIT
package/bin/cli.js ADDED
@@ -0,0 +1,130 @@
1
+ #!/usr/bin/env node
2
+
3
+ const fs = require('fs');
4
+ const path = require('path');
5
+
6
+ const VERSION = require('../package.json').version;
7
+ const VERSION_COMMENT = `<!-- mema-kit v${VERSION} -->`;
8
+
9
+ // Paths
10
+ const packageRoot = path.resolve(__dirname, '..');
11
+ const skillsSource = path.join(packageRoot, 'skills');
12
+ const targetDir = path.join(process.cwd(), '.claude', 'skills');
13
+
14
+ // Parse arguments
15
+ const args = process.argv.slice(2);
16
+ const isUpdate = args.includes('--update');
17
+ const isHelp = args.includes('--help') || args.includes('-h');
18
+
19
+ if (isHelp) {
20
+ printHelp();
21
+ process.exit(0);
22
+ }
23
+
24
+ if (isUpdate) {
25
+ runUpdate();
26
+ } else {
27
+ runInstall();
28
+ }
29
+
30
+ function runInstall() {
31
+ // Check if skills already exist
32
+ if (fs.existsSync(targetDir)) {
33
+ const hasSkills = fs.readdirSync(targetDir).some(f => f.endsWith('.md') || fs.statSync(path.join(targetDir, f)).isDirectory());
34
+ if (hasSkills) {
35
+ console.log('⚠ mema-kit skills already exist in .claude/skills/');
36
+ console.log(' Use --update to replace with the latest version.');
37
+ console.log(' Or delete .claude/skills/ and run again for a fresh install.');
38
+ process.exit(1);
39
+ }
40
+ }
41
+
42
+ // Create target directory
43
+ fs.mkdirSync(targetDir, { recursive: true });
44
+
45
+ // Copy all skills
46
+ copySkills();
47
+
48
+ console.log('✓ mema-kit skills installed to .claude/skills/');
49
+ console.log('');
50
+ console.log('Next step: Open your project in Claude Code and run /onboard');
51
+ console.log('');
52
+ console.log(' claude');
53
+ console.log(' > /onboard');
54
+ console.log('');
55
+ }
56
+
57
+ function runUpdate() {
58
+ if (!fs.existsSync(targetDir)) {
59
+ console.log('⚠ No .claude/skills/ directory found.');
60
+ console.log(' Run npx mema-kit (without --update) for a fresh install.');
61
+ process.exit(1);
62
+ }
63
+
64
+ // Check current version
65
+ const protocolPath = path.join(targetDir, '_memory-protocol.md');
66
+ if (fs.existsSync(protocolPath)) {
67
+ const content = fs.readFileSync(protocolPath, 'utf8');
68
+ const versionMatch = content.match(/<!-- mema-kit v([\d.]+) -->/);
69
+ if (versionMatch && versionMatch[1] === VERSION) {
70
+ console.log(`✓ mema-kit skills are already at v${VERSION}. No update needed.`);
71
+ process.exit(0);
72
+ }
73
+ if (versionMatch) {
74
+ console.log(`Updating mema-kit skills from v${versionMatch[1]} to v${VERSION}...`);
75
+ }
76
+ }
77
+
78
+ // Copy (overwrite) all skills
79
+ copySkills();
80
+
81
+ console.log(`✓ mema-kit skills updated to v${VERSION}`);
82
+ console.log('');
83
+ console.log(' .mema/ and CLAUDE.md were not modified.');
84
+ console.log('');
85
+ }
86
+
87
+ function copySkills() {
88
+ const entries = fs.readdirSync(skillsSource, { withFileTypes: true });
89
+
90
+ for (const entry of entries) {
91
+ const sourcePath = path.join(skillsSource, entry.name);
92
+ const targetPath = path.join(targetDir, entry.name);
93
+
94
+ if (entry.isDirectory()) {
95
+ // Skill directory (e.g., onboard/)
96
+ fs.mkdirSync(targetPath, { recursive: true });
97
+ const files = fs.readdirSync(sourcePath);
98
+ for (const file of files) {
99
+ const content = fs.readFileSync(path.join(sourcePath, file), 'utf8');
100
+ fs.writeFileSync(path.join(targetPath, file), addVersionComment(content));
101
+ }
102
+ } else if (entry.isFile() && entry.name.endsWith('.md')) {
103
+ // Standalone file (e.g., _memory-protocol.md)
104
+ const content = fs.readFileSync(sourcePath, 'utf8');
105
+ fs.writeFileSync(targetPath, addVersionComment(content));
106
+ }
107
+ }
108
+ }
109
+
110
+ function addVersionComment(content) {
111
+ // Remove any existing version comment
112
+ const cleaned = content.replace(/<!-- mema-kit v[\d.]+ -->\n?/, '');
113
+ // Add current version at the end
114
+ return cleaned.trimEnd() + '\n\n' + VERSION_COMMENT + '\n';
115
+ }
116
+
117
+ function printHelp() {
118
+ console.log(`
119
+ mema-kit v${VERSION} — Memory protocol kit for Claude Code skills
120
+
121
+ Usage:
122
+ npx mema-kit Install skills to .claude/skills/
123
+ npx mema-kit --update Update skills to the latest version
124
+ npx mema-kit --help Show this help message
125
+
126
+ After installing, open your project in Claude Code and run /onboard.
127
+
128
+ Learn more: https://github.com/simonv15/mema-kit
129
+ `.trim());
130
+ }
package/package.json ADDED
@@ -0,0 +1,28 @@
1
+ {
2
+ "name": "mema-kit",
3
+ "version": "1.0.0",
4
+ "description": "Reusable memory protocol kit for Claude Code skills",
5
+ "bin": {
6
+ "mema-kit": "bin/cli.js"
7
+ },
8
+ "files": [
9
+ "bin/",
10
+ "skills/",
11
+ "templates/"
12
+ ],
13
+ "keywords": [
14
+ "claude-code",
15
+ "ai-memory",
16
+ "claude-skills",
17
+ "memory-protocol",
18
+ "agent-memory"
19
+ ],
20
+ "license": "MIT",
21
+ "repository": {
22
+ "type": "git",
23
+ "url": "git+https://github.com/simonv15/mema-kit.git"
24
+ },
25
+ "engines": {
26
+ "node": ">=16.7.0"
27
+ }
28
+ }
@@ -0,0 +1,146 @@
1
+ # Memory Protocol
2
+
3
+ This document defines how you manage memory in `.mema/`. Every skill that reads or writes memory must follow these rules.
4
+
5
+ ## The Memory Lifecycle
6
+
7
+ Every skill execution follows four phases:
8
+
9
+ ### Phase 1: AUTO-LOAD
10
+ 1. Read `.mema/index.md` to understand current project state
11
+ 2. If `index.md` is missing or empty, run the **Rebuild Procedure** (see below)
12
+ 3. Based on the user's request, decide which memory files are relevant
13
+ 4. Read only the relevant files — do NOT load everything
14
+
15
+ **How to decide relevance:** Scan each index entry's one-line summary. If it relates to the user's current topic, technology, or task — load it. When in doubt, load it. When clearly unrelated, skip it.
16
+
17
+ ### Phase 2: WORK
18
+ Execute the skill's core purpose (research, planning, test generation, implementation) with the loaded context.
19
+
20
+ ### Phase 3: AUTO-SAVE & CURATE
21
+ For every piece of knowledge produced during this session, decide one of four actions:
22
+
23
+ **ADD** — Save new knowledge that doesn't exist yet
24
+ - A new decision with reasoning
25
+ - A new exploration finding worth preserving
26
+ - A new lesson learned from implementation
27
+ - A new pattern discovered for reuse
28
+
29
+ **UPDATE** — Modify existing knowledge that has changed
30
+ - A decision's reasoning was refined
31
+ - Architecture changed due to new requirements
32
+ - A plan step was adjusted during implementation
33
+ - A lesson gained a new example
34
+
35
+ **DELETE** — Remove knowledge that is wrong, superseded, or irrelevant
36
+ - Dead-end exploration (evaluated and rejected — no future value)
37
+ - Superseded decisions (old decision replaced by new one — keep the new one only)
38
+ - Redundant information (already captured in a more complete file)
39
+ - Temporary notes that served their purpose
40
+
41
+ **NOOP** — Leave unchanged (the memory is still accurate and relevant)
42
+ - Most memories should be NOOP on any given skill execution
43
+ - Only act (ADD/UPDATE/DELETE) when there's a clear reason
44
+
45
+ ### Phase 4: AUTO-INDEX
46
+ Update `.mema/index.md` to reflect all changes made in Phase 3. This is **mandatory** — never skip it.
47
+
48
+ ## What to Save vs. What to Prune
49
+
50
+ ### SAVE (curated knowledge worth preserving):
51
+ - Decisions with reasoning: "Chose Fastify over Express because: 2x faster benchmarks, built-in schema validation, better TypeScript support"
52
+ - Architecture and design patterns: "API follows controller → service → repository layers"
53
+ - Requirements and constraints: "Must support 100 concurrent users, PostgreSQL is required by client"
54
+ - Lessons from failures: "Drizzle ORM needs explicit type casting for PostgreSQL enums — spent 30 min debugging this"
55
+ - Reusable patterns: "Fastify route registration pattern: define schema, write handler, register in app.ts"
56
+
57
+ ### PRUNE (noise that wastes future context):
58
+ - Conversational back-and-forth that led to a conclusion (keep the conclusion, prune the discussion)
59
+ - Dead-end explorations with no useful outcome (evaluated MongoDB, doesn't fit — delete the comparison notes)
60
+ - Temporary debugging context (fixed the bug, no recurring lesson — delete)
61
+ - Verbose explanations when a concise summary exists (condense, don't hoard)
62
+ - Information already captured elsewhere (don't duplicate across files)
63
+
64
+ ## Per-File-Type Curation Rules
65
+
66
+ ### decision.md — Conservative curation
67
+ - **Rarely delete.** Decisions are historical record. Even reversed decisions teach future sessions why something didn't work.
68
+ - **UPDATE** when the decision is refined, expanded, or its status changes.
69
+ - **ADD** reasoning if the original entry lacks a "why."
70
+ - Only **DELETE** if the decision was recorded in error (wrong project, duplicate entry).
71
+
72
+ ### context.md — Aggressive curation
73
+ - **Prune dead-end explorations.** If you explored 5 options and chose 1, delete the notes on the 4 rejected options. The decision file captures what was chosen and why.
74
+ - **Consolidate findings.** If multiple explorations cover overlapping ground, merge them into one concise context file.
75
+ - **DELETE** when a decision supersedes the exploration entirely (the exploration's value is now captured in the decision).
76
+
77
+ ### plan.md — Replace curation
78
+ - **Keep the final version only.** Draft plans are noise once a final plan exists.
79
+ - **UPDATE** during implementation — mark steps as complete, note adjustments.
80
+ - **Do not create multiple plan versions.** Overwrite the plan when it changes.
81
+
82
+ ### lessons.md and patterns.md — Consolidation curation
83
+ - **Merge similar lessons.** "Drizzle needs type casting" and "Drizzle enum handling requires explicit cast" are the same lesson — keep one entry with both examples.
84
+ - **UPDATE** with new examples when the same pattern/lesson recurs.
85
+ - **DELETE** if a lesson is proven wrong by later experience.
86
+ - **Consolidate periodically.** If lessons.md exceeds ~30 entries, group related lessons under headers.
87
+
88
+ ## Metadata Format
89
+
90
+ Every memory file includes metadata in the body (not YAML frontmatter):
91
+
92
+ ```
93
+ **Status:** active | **Updated:** 2026-02-23
94
+ ```
95
+
96
+ Status values:
97
+ - `active` — Current and relevant
98
+ - `complete` — Finished but still useful for reference
99
+ - `archived` — Moved to archive/ (set by the completing skill on task completion)
100
+
101
+ Place metadata on the line immediately after the title heading.
102
+
103
+ ## index.md Format
104
+
105
+ The index is a structured pointer map with four sections:
106
+
107
+ ```
108
+ # Memory Index
109
+
110
+ **Updated:** 2026-02-23
111
+
112
+ ## Active Tasks
113
+ - `task-memory/api-setup/` — Setting up REST API with Fastify (plan ready, implementing)
114
+
115
+ ## Project Knowledge
116
+ - `project-memory/architecture.md` — Node.js + Fastify + PostgreSQL + Drizzle stack
117
+ - `project-memory/requirements.md` — Core requirements and constraints
118
+
119
+ ## Recent Decisions
120
+ - `project-memory/decisions/2026-02-23-tech-stack.md` — Chose Fastify + PostgreSQL + Drizzle
121
+ - `project-memory/decisions/2026-02-23-auth-jwt.md` — JWT with refresh tokens for auth
122
+
123
+ ## Agent Lessons
124
+ - `agent-memory/lessons.md` — 3 lessons recorded (Drizzle type casting, Fastify plugin order, test isolation)
125
+ - `agent-memory/patterns.md` — 2 patterns recorded (route registration, error handling middleware)
126
+ ```
127
+
128
+ Each entry is: `- \`file-path\` — one-line summary`
129
+
130
+ ### Updating the Index
131
+ After every curated save:
132
+ 1. Re-read the current index.md
133
+ 2. Add entries for new files
134
+ 3. Update summaries for modified files
135
+ 4. Remove entries for deleted files
136
+ 5. Update the `**Updated:**` date
137
+
138
+ ### Rebuild Procedure (fallback)
139
+ If `index.md` is missing, empty, or clearly stale (references files that don't exist):
140
+ 1. List all directories in `.mema/`: `project-memory/`, `task-memory/`, `agent-memory/`, `archive/`
141
+ 2. For each directory, list all `.md` files (excluding `_templates/`)
142
+ 3. Read the first 3 lines of each file to get title and metadata
143
+ 4. Generate index entries in the format above
144
+ 5. Write the rebuilt `index.md`
145
+
146
+ This procedure makes the index a **rebuildable cache** — it's convenient but never the only copy of truth. The actual files in `.mema/` are the source of truth.
@@ -0,0 +1,242 @@
1
+ ---
2
+ description: Generate a new memory-aware Claude Code skill. Creates a SKILL.md file with the correct memory lifecycle phases based on the skill's complexity.
3
+ ---
4
+
5
+ # /create-skill — Generate Memory-Aware Skills
6
+
7
+ You are creating a new Claude Code skill that integrates with mema-kit's memory protocol. Follow these steps carefully.
8
+
9
+ ## Step 1: Interview
10
+
11
+ Gather the following from the user. Keep it to **2-3 exchanges max** — don't over-interview.
12
+
13
+ ### Required:
14
+ 1. **Skill name** — kebab-case (e.g., `review`, `debug`, `migrate`). If the user gives a name with spaces or camelCase, convert it.
15
+ 2. **Purpose** — What does this skill do? One sentence is enough.
16
+
17
+ ### Optional (offer sensible defaults):
18
+ 3. **Memory needs** — Does this skill need to:
19
+ - **Read** memory (load context, architecture, lessons) — most skills
20
+ - **Write** memory (save decisions, findings, lessons) — skills that produce knowledge
21
+ - **Both** (default) — most useful skills both read and write
22
+ 4. **Complexity level**:
23
+ - **Simple** — Read-only or minimal memory. 3 phases: AUTO-LOAD, WORK, REPORT. Good for: code review, linting, quick lookups.
24
+ - **Standard** (default) — Full 4-phase lifecycle. Good for: most skills that produce and consume knowledge.
25
+ - **Advanced** — Full lifecycle + task management, archiving, and lesson learning. Good for: implementation skills, multi-step workflows.
26
+
27
+ If the user doesn't specify memory needs or complexity, default to **both** and **standard**.
28
+
29
+ ## Step 2: Generate SKILL.md
30
+
31
+ Based on the interview answers, generate a SKILL.md file. Use the appropriate template below based on complexity level.
32
+
33
+ **Critical rule:** Generated skills reference `_memory-protocol.md` for curation rules. NEVER duplicate the memory protocol content inside generated skills.
34
+
35
+ ---
36
+
37
+ ### Simple Template (3 phases)
38
+
39
+ ```markdown
40
+ ---
41
+ description: [User's purpose description]
42
+ ---
43
+
44
+ # /[skill-name] — [Title]
45
+
46
+ You are executing the /[skill-name] skill. Follow these steps carefully.
47
+
48
+ ## Phase 1: AUTO-LOAD
49
+
50
+ 1. Read `.mema/index.md` to understand current project state
51
+ 2. If `index.md` is missing or empty, inform the user to run `/onboard` first
52
+ 3. Based on the user's request, identify and read relevant memory files
53
+ 4. Read only what's needed — don't load everything
54
+
55
+ ## Phase 2: WORK
56
+
57
+ [Core skill logic goes here — describe what the skill does step by step]
58
+
59
+ 1. [First action]
60
+ 2. [Second action]
61
+ 3. [Third action]
62
+
63
+ Use the loaded memory context to inform your work. Reference architecture decisions, past lessons, and patterns where relevant.
64
+
65
+ ## Phase 3: REPORT
66
+
67
+ Summarize what was done and any findings. If you discovered anything worth preserving, tell the user:
68
+
69
+ "I noticed [finding]. Consider saving this as a lesson/decision/pattern using a memory-writing skill."
70
+
71
+ Do NOT modify memory files directly in a simple skill.
72
+ ```
73
+
74
+ ---
75
+
76
+ ### Standard Template (4 phases)
77
+
78
+ ```markdown
79
+ ---
80
+ description: [User's purpose description]
81
+ ---
82
+
83
+ # /[skill-name] — [Title]
84
+
85
+ You are executing the /[skill-name] skill. Follow these steps carefully.
86
+
87
+ ## Phase 1: AUTO-LOAD
88
+
89
+ 1. Read `.mema/index.md` to understand current project state
90
+ 2. If `index.md` is missing or empty, run the **Rebuild Procedure** from `_memory-protocol.md`
91
+ 3. Based on the user's request, identify and read relevant memory files
92
+ 4. Read only what's needed — don't load everything
93
+
94
+ **Relevant memory for this skill:**
95
+ - `project-memory/architecture.md` — for technical context
96
+ - `project-memory/decisions/` — for past decisions related to this work
97
+ - `agent-memory/lessons.md` — for mistakes to avoid
98
+ - `agent-memory/patterns.md` — for reusable approaches
99
+ - [Add or remove entries based on the skill's purpose]
100
+
101
+ ## Phase 2: WORK
102
+
103
+ [Core skill logic goes here — describe what the skill does step by step]
104
+
105
+ 1. [First action]
106
+ 2. [Second action]
107
+ 3. [Third action]
108
+
109
+ Use the loaded memory context to inform your work.
110
+
111
+ ## Phase 3: AUTO-SAVE & CURATE
112
+
113
+ Follow the curation rules in `_memory-protocol.md`. For each piece of knowledge produced:
114
+
115
+ - **Decisions made** → ADD to `project-memory/decisions/YYYY-MM-DD-short-name.md`
116
+ - **Architecture changes** → UPDATE `project-memory/architecture.md`
117
+ - **Lessons learned** → ADD/UPDATE `agent-memory/lessons.md`
118
+ - **Patterns discovered** → ADD/UPDATE `agent-memory/patterns.md`
119
+ - **Exploration findings** → ADD to appropriate `task-memory/` or `project-memory/` file
120
+
121
+ Apply ADD/UPDATE/DELETE/NOOP to each memory file. Most files will be NOOP.
122
+
123
+ ## Phase 4: AUTO-INDEX
124
+
125
+ Update `.mema/index.md`:
126
+ 1. Re-read the current index
127
+ 2. Add entries for new files
128
+ 3. Update summaries for modified files
129
+ 4. Remove entries for deleted files
130
+ 5. Update the `**Updated:**` date
131
+ ```
132
+
133
+ ---
134
+
135
+ ### Advanced Template (4 phases + task management)
136
+
137
+ ```markdown
138
+ ---
139
+ description: [User's purpose description]
140
+ ---
141
+
142
+ # /[skill-name] — [Title]
143
+
144
+ You are executing the /[skill-name] skill. Follow these steps carefully.
145
+
146
+ ## Phase 1: AUTO-LOAD
147
+
148
+ 1. Read `.mema/index.md` to understand current project state
149
+ 2. If `index.md` is missing or empty, run the **Rebuild Procedure** from `_memory-protocol.md`
150
+ 3. Based on the user's request, identify and read relevant memory files:
151
+ - Task-specific: `task-memory/[task-name]/` (context, plan, status)
152
+ - Project-wide: `project-memory/architecture.md`, relevant decisions
153
+ - Agent knowledge: `agent-memory/lessons.md`, `agent-memory/patterns.md`
154
+ 4. Read only what's needed — don't load everything
155
+
156
+ ## Phase 2: WORK
157
+
158
+ ### 2a: Task Setup
159
+ If no task directory exists for this work:
160
+ 1. Create `task-memory/[task-name]/`
161
+ 2. Write initial `context.md` with the task description and relevant findings
162
+
163
+ If a task directory exists, read the current status and continue where you left off.
164
+
165
+ ### 2b: Core Work
166
+
167
+ [Core skill logic goes here — describe what the skill does step by step]
168
+
169
+ 1. [First action]
170
+ 2. [Second action]
171
+ 3. [Third action]
172
+
173
+ Track progress by updating `task-memory/[task-name]/status.md` as you go.
174
+
175
+ ### 2c: Learn
176
+
177
+ After completing work, reflect:
178
+ - Did anything unexpected happen? → Record as a lesson
179
+ - Did you use a pattern that worked well? → Record as a pattern
180
+ - Did any previous lesson prove wrong? → Update or delete it
181
+
182
+ ## Phase 3: AUTO-SAVE & CURATE
183
+
184
+ Follow the curation rules in `_memory-protocol.md`. For each piece of knowledge produced:
185
+
186
+ - **Decisions made** → ADD to `project-memory/decisions/YYYY-MM-DD-short-name.md`
187
+ - **Architecture changes** → UPDATE `project-memory/architecture.md`
188
+ - **Lessons learned** → ADD/UPDATE `agent-memory/lessons.md`
189
+ - **Patterns discovered** → ADD/UPDATE `agent-memory/patterns.md`
190
+ - **Task progress** → UPDATE `task-memory/[task-name]/status.md`
191
+
192
+ Apply ADD/UPDATE/DELETE/NOOP to each memory file. Most files will be NOOP.
193
+
194
+ ### Task Completion
195
+ If the task is fully complete:
196
+ 1. Mark `task-memory/[task-name]/status.md` as `**Status:** complete`
197
+ 2. Move `task-memory/[task-name]/` to `archive/[task-name]/`
198
+ 3. Remove the task from "Active Tasks" in `index.md`
199
+
200
+ ## Phase 4: AUTO-INDEX
201
+
202
+ Update `.mema/index.md`:
203
+ 1. Re-read the current index
204
+ 2. Add entries for new files
205
+ 3. Update summaries for modified files
206
+ 4. Remove entries for deleted files
207
+ 5. Update the `**Updated:**` date
208
+ ```
209
+
210
+ ---
211
+
212
+ ## Step 3: Write the File
213
+
214
+ 1. Write the generated SKILL.md to `.claude/skills/[skill-name]/SKILL.md`
215
+ 2. Create the directory if it doesn't exist
216
+ 3. If the file already exists, warn the user and ask before overwriting
217
+
218
+ ## Step 4: Verify
219
+
220
+ Read back the file you just wrote and confirm:
221
+ - The `description` frontmatter is present and accurate
222
+ - The skill name is correct throughout
223
+ - Memory file paths use `.mema/` (not `.praxis/` or any other prefix)
224
+ - The skill references `_memory-protocol.md` for curation rules (standard and advanced only)
225
+ - No memory protocol content is duplicated inside the skill
226
+
227
+ ## Step 5: Confirm
228
+
229
+ Tell the user:
230
+
231
+ ```
232
+ Skill created: /[skill-name]
233
+
234
+ Location: .claude/skills/[skill-name]/SKILL.md
235
+ Type: [simple|standard|advanced]
236
+ Memory: [read-only|write-only|read+write]
237
+
238
+ To use it:
239
+ /[skill-name] [your request]
240
+
241
+ The skill follows the mema-kit memory protocol and will [read from / write to / read from and write to] .mema/ automatically.
242
+ ```
@@ -0,0 +1,417 @@
1
+ ---
2
+ description: Bootstrap the mema-kit memory system for this project. Creates .mema/ directory, scans the project, populates initial memory, and configures CLAUDE.md and .gitignore.
3
+ ---
4
+
5
+ # /onboard — Project Memory Bootstrap
6
+
7
+ You are setting up the mema-kit memory system for this project. Follow these steps carefully. This command is idempotent — safe to re-run. Never overwrite existing data.
8
+
9
+ ## Step 1: Check Current State
10
+
11
+ Before creating anything, assess what already exists:
12
+
13
+ 1. Check if `.mema/` directory exists
14
+ 2. Check if `CLAUDE.md` exists and whether it contains a `## Memory System` section
15
+ 3. Check if `.gitignore` exists and whether it contains `.mema` entries
16
+
17
+ Report what you found to the user: "Setting up mema-kit. Found existing .mema/ directory — will verify and repair." or "Fresh setup — creating everything from scratch."
18
+
19
+ ## Step 2: Create .mema/ Directory Structure
20
+
21
+ Create the following directories if they don't already exist:
22
+
23
+ ```
24
+ .mema/
25
+ ├── _templates/
26
+ ├── project-memory/
27
+ │ └── decisions/
28
+ ├── task-memory/
29
+ ├── agent-memory/
30
+ └── archive/
31
+ ```
32
+
33
+ For each directory: if it exists, skip it. If it doesn't, create it.
34
+
35
+ ## Step 3: Write Template Files
36
+
37
+ Write the following files to `.mema/_templates/`. If a template file already exists, **skip it** (the user may have customized it).
38
+
39
+ ### `.mema/_templates/decision.md`
40
+
41
+ ```
42
+ # [Decision Title]
43
+
44
+ **Status:** active | **Updated:** YYYY-MM-DD
45
+
46
+ ## Context
47
+ <!-- What situation or question prompted this decision? What problem are we solving? -->
48
+
49
+ ## Decision
50
+ <!-- What was decided? Be specific and concrete. -->
51
+
52
+ ## Options Considered
53
+
54
+ ### Option A: [Name]
55
+ <!-- Brief description. Why chosen/rejected. -->
56
+
57
+ ### Option B: [Name]
58
+ <!-- Brief description. Why chosen/rejected. -->
59
+
60
+ ## Reasoning
61
+ <!-- Why this option was selected. What factors mattered most? What trade-offs were accepted? -->
62
+
63
+ ## Consequences
64
+ <!-- What are the implications? What does this enable or constrain? Any known trade-offs or risks? -->
65
+ ```
66
+
67
+ ### `.mema/_templates/context.md`
68
+
69
+ ```
70
+ # [Topic] — Exploration Context
71
+
72
+ **Status:** active | **Updated:** YYYY-MM-DD
73
+
74
+ ## Summary
75
+ <!-- 2-3 sentence overview of what was explored and the key takeaway. -->
76
+
77
+ ## Key Findings
78
+ <!-- Bullet list of important facts, constraints, or insights discovered. Be specific and concise. -->
79
+
80
+ -
81
+ -
82
+ -
83
+
84
+ ## Open Questions
85
+ <!-- What remains unresolved? What needs further exploration or a decision? -->
86
+
87
+ -
88
+ -
89
+
90
+ ## Relates To
91
+ <!-- Links to related memory files (decisions, other context, plans). Use relative paths. -->
92
+
93
+ -
94
+ ```
95
+
96
+ ### `.mema/_templates/plan.md`
97
+
98
+ ```
99
+ # [Task Name] — Implementation Plan
100
+
101
+ **Status:** active | **Updated:** YYYY-MM-DD
102
+
103
+ ## General Plan
104
+ <!-- High-level approach: architecture decisions, component design, data flow. Keep it to 1-2 paragraphs or a short list. This should answer "what are we building and how does it fit together?" -->
105
+
106
+ ## Detailed Plan
107
+ <!-- Step-by-step implementation tasks. Each step should be specific enough to implement directly. -->
108
+
109
+ ### Step 1: [Action]
110
+ <!-- What to do, which files to create/modify, any dependencies on prior steps. -->
111
+ - Files: `path/to/file`
112
+ - Details:
113
+
114
+ ### Step 2: [Action]
115
+ - Files: `path/to/file`
116
+ - Details:
117
+
118
+ ### Step 3: [Action]
119
+ - Files: `path/to/file`
120
+ - Details:
121
+
122
+ ## Out of Scope
123
+ <!-- What this plan explicitly does NOT cover. Prevents scope creep during implementation. -->
124
+
125
+ -
126
+ ```
127
+
128
+ ### `.mema/_templates/lessons.md`
129
+
130
+ ```
131
+ # Agent Lessons
132
+
133
+ **Updated:** YYYY-MM-DD
134
+
135
+ ## Lessons
136
+
137
+ ### [Short Title]
138
+ <!-- One-sentence lesson. -->
139
+ - **Context:** <!-- When/how this was discovered. -->
140
+ - **Example:** <!-- Concrete code example or scenario if applicable. -->
141
+
142
+ ---
143
+
144
+ <!-- Add new lessons above this line. When entries exceed ~30, consolidate related lessons under grouped headers. -->
145
+ ```
146
+
147
+ ### `.mema/_templates/patterns.md`
148
+
149
+ ```
150
+ # Agent Patterns
151
+
152
+ **Updated:** YYYY-MM-DD
153
+
154
+ ## Patterns
155
+
156
+ ### [Pattern Name]
157
+ - **Structure:** <!-- How the pattern is organized. -->
158
+ - **Example:** <!-- Concrete usage example. -->
159
+
160
+ ---
161
+
162
+ <!-- Add new patterns above this line. -->
163
+ ```
164
+
165
+ ### `.mema/_templates/status.md`
166
+
167
+ ```
168
+ # [Task Name] — Status
169
+
170
+ **Status:** active | **Updated:** YYYY-MM-DD
171
+
172
+ ## Progress
173
+
174
+ - [ ] Step 1: [description]
175
+ - [ ] Step 2: [description]
176
+ - [ ] Step 3: [description]
177
+
178
+ ## Notes
179
+ <!-- Any blockers, deviations from plan, or important observations during implementation. -->
180
+
181
+ ## Completed
182
+ **Completed:**
183
+ ```
184
+
185
+ ## Step 4: Scan the Project
186
+
187
+ This is the intelligence step. Read and analyze the project to populate memory with real content instead of empty placeholders.
188
+
189
+ ### 4a: Detect Project Type and Stack
190
+
191
+ Read the following files (skip any that don't exist):
192
+
193
+ 1. `package.json` or `pyproject.toml` or `Cargo.toml` or `go.mod` or `pom.xml` or `Gemfile` — to identify language, framework, and dependencies
194
+ 2. `README.md` — to understand project purpose and setup
195
+ 3. `CLAUDE.md` — to understand existing conventions and instructions
196
+ 4. `tsconfig.json` or equivalent config files — to understand build setup
197
+
198
+ ### 4b: Scan Directory Structure
199
+
200
+ List the top-level directories and key subdirectories (1-2 levels deep) to understand the project layout. Note:
201
+ - Source code location (`src/`, `lib/`, `app/`, etc.)
202
+ - Test location (`tests/`, `__tests__/`, `test/`, etc.)
203
+ - Config files present
204
+ - Any existing documentation
205
+
206
+ ### 4c: Read Representative Source Files
207
+
208
+ Pick 2-3 source files that best represent the codebase patterns:
209
+ - The main entry point (e.g., `src/index.ts`, `main.py`, `main.go`)
210
+ - A representative module/component
211
+ - A test file (if tests exist)
212
+
213
+ Read these to understand coding patterns, style, and architecture.
214
+
215
+ ### 4d: Summarize Findings
216
+
217
+ Before writing memory, compile your findings:
218
+ - **Project name** and purpose
219
+ - **Language/framework/stack** with versions
220
+ - **Architecture pattern** (monolith, microservices, CLI tool, library, etc.)
221
+ - **Key directories** and what they contain
222
+ - **Testing setup** (framework, patterns)
223
+ - **Build/run commands**
224
+ - **Notable conventions** (naming, patterns, config)
225
+
226
+ ## Step 5: Populate Initial Memory
227
+
228
+ Using the scan findings, create memory files with **real content** (not empty placeholders).
229
+
230
+ ### `.mema/project-memory/architecture.md`
231
+
232
+ Write an architecture overview based on what you discovered. Include:
233
+ - Tech stack with versions
234
+ - Project structure (key directories and their purposes)
235
+ - Architecture pattern
236
+ - Key entry points
237
+ - Build and run commands
238
+
239
+ Example format:
240
+
241
+ ```
242
+ # Project Architecture
243
+
244
+ **Status:** active | **Updated:** [today's date]
245
+
246
+ ## Stack
247
+ - **Language:** TypeScript 5.x
248
+ - **Runtime:** Node.js 20+
249
+ - **Framework:** Fastify 4.x
250
+ - **Database:** PostgreSQL 16 via Drizzle ORM
251
+ - **Testing:** Vitest
252
+
253
+ ## Structure
254
+ - `src/` — Application source code
255
+ - `routes/` — API route handlers
256
+ - `services/` — Business logic
257
+ - `db/` — Database schema and migrations
258
+ - `tests/` — Test files mirroring src/ structure
259
+
260
+ ## Architecture
261
+ REST API following controller → service → repository layers.
262
+ Entry point: `src/app.ts`
263
+
264
+ ## Commands
265
+ - `npm run dev` — Start development server
266
+ - `npm test` — Run test suite
267
+ - `npm run build` — Build for production
268
+ ```
269
+
270
+ ### `.mema/project-memory/requirements.md`
271
+
272
+ Write a requirements summary based on README, package.json description, and observed functionality:
273
+
274
+ ```
275
+ # Project Requirements
276
+
277
+ **Status:** active | **Updated:** [today's date]
278
+
279
+ ## Purpose
280
+ [What this project does, based on README and code]
281
+
282
+ ## Key Requirements
283
+ - [Requirement discovered from code/docs]
284
+ - [Requirement discovered from code/docs]
285
+
286
+ ## Constraints
287
+ - [Any constraints discovered (Node version, dependencies, etc.)]
288
+ ```
289
+
290
+ ### `.mema/agent-memory/lessons.md`
291
+
292
+ Create a starter lessons file with any project-specific gotchas discovered during scanning:
293
+
294
+ ```
295
+ # Agent Lessons
296
+
297
+ **Updated:** [today's date]
298
+
299
+ ## Lessons
300
+
301
+ <!-- Lessons will be added here as the agent learns from development experience. -->
302
+ ```
303
+
304
+ If you discovered anything notable during scanning (e.g., unusual config, non-obvious setup steps), add it as the first lesson.
305
+
306
+ ### `.mema/agent-memory/patterns.md`
307
+
308
+ Create a starter patterns file. If you identified clear patterns from the source files you read, add them:
309
+
310
+ ```
311
+ # Agent Patterns
312
+
313
+ **Updated:** [today's date]
314
+
315
+ ## Patterns
316
+
317
+ <!-- Patterns will be added here as the agent discovers reusable approaches. -->
318
+ ```
319
+
320
+ ### `.mema/index.md`
321
+
322
+ Build the index from the files you just created:
323
+
324
+ ```
325
+ # Memory Index
326
+
327
+ **Updated:** [today's date]
328
+
329
+ ## Active Tasks
330
+
331
+ ## Project Knowledge
332
+ - `project-memory/architecture.md` — [one-line summary of stack/architecture]
333
+ - `project-memory/requirements.md` — [one-line summary of purpose]
334
+
335
+ ## Recent Decisions
336
+
337
+ ## Agent Lessons
338
+ - `agent-memory/lessons.md` — [N] lessons recorded
339
+ - `agent-memory/patterns.md` — [N] patterns recorded
340
+ ```
341
+
342
+ ## Step 6: Update CLAUDE.md
343
+
344
+ 1. Read the current `CLAUDE.md` (if it exists)
345
+ 2. Search for `## Memory System` in the file content
346
+ 3. If found → **skip this step** (already configured)
347
+ 4. If not found → append the following section at the end of the file
348
+ 5. If `CLAUDE.md` doesn't exist → create the file with this content
349
+
350
+ Append this section:
351
+
352
+ ```
353
+ ## Memory System
354
+
355
+ This project uses mema-kit for persistent memory across sessions.
356
+
357
+ Memory lives in `.mema/`. At the start of each task, read `.mema/index.md` to load relevant context. After completing work, curate and save knowledge following the memory protocol in `.claude/skills/_memory-protocol.md`.
358
+
359
+ Memory is managed automatically by skills — do not manually modify `.mema/` files unless correcting an error.
360
+ ```
361
+
362
+ ## Step 7: Update .gitignore
363
+
364
+ 1. Read the current `.gitignore` (if it exists)
365
+ 2. Search for `.mema` in the file content
366
+ 3. If found → **skip this step** (already configured)
367
+ 4. If not found → append the following block at the end of the file
368
+ 5. If `.gitignore` doesn't exist → create the file with this content
369
+
370
+ Append this block:
371
+
372
+ ```
373
+ # mema-kit memory (developer-local)
374
+ .mema/*
375
+ # Uncomment to share project decisions with your team:
376
+ # !.mema/project-memory/
377
+ ```
378
+
379
+ ## Step 8: Confirm to the User
380
+
381
+ Print a summary of what was done, including what you discovered about the project:
382
+
383
+ ```
384
+ mema-kit initialized! Here's what was set up:
385
+
386
+ [check] .mema/ directory structure (memory system)
387
+ [check] Memory templates in .mema/_templates/
388
+ [check] CLAUDE.md updated with memory system conventions
389
+ [check] .gitignore updated to exclude .mema/
390
+
391
+ Project scan results:
392
+ - [Language/framework discovered]
393
+ - [Architecture pattern discovered]
394
+ - [N] source directories mapped
395
+ - [Notable findings]
396
+
397
+ Memory populated:
398
+ - architecture.md — [summary]
399
+ - requirements.md — [summary]
400
+ - lessons.md — [N] initial lessons
401
+ - patterns.md — [N] initial patterns
402
+
403
+ Next: Start working on your project. Memory will be loaded and saved automatically by any mema-kit skill.
404
+ ```
405
+
406
+ If this was a re-run (some items already existed), adjust the summary to show what was verified vs. created:
407
+
408
+ ```
409
+ mema-kit verified! Everything looks good:
410
+
411
+ [check] .mema/ directory structure — already exists, verified
412
+ [check] Memory templates — already exist, skipped
413
+ [check] CLAUDE.md — memory section already present
414
+ [check] .gitignore — .mema/ already excluded
415
+
416
+ Your setup is intact. No changes were needed.
417
+ ```
@@ -0,0 +1,24 @@
1
+ # [Topic] — Exploration Context
2
+
3
+ **Status:** active | **Updated:** YYYY-MM-DD
4
+
5
+ ## Summary
6
+ <!-- 2-3 sentence overview of what was explored and the key takeaway. -->
7
+
8
+ ## Key Findings
9
+ <!-- Bullet list of important facts, constraints, or insights discovered. Be specific and concise. -->
10
+
11
+ -
12
+ -
13
+ -
14
+
15
+ ## Open Questions
16
+ <!-- What remains unresolved? What needs further exploration or a decision? -->
17
+
18
+ -
19
+ -
20
+
21
+ ## Relates To
22
+ <!-- Links to related memory files (decisions, other context, plans). Use relative paths. -->
23
+
24
+ -
@@ -0,0 +1,24 @@
1
+ # [Decision Title]
2
+
3
+ **Status:** active | **Updated:** YYYY-MM-DD
4
+
5
+ ## Context
6
+ <!-- What situation or question prompted this decision? What problem are we solving? -->
7
+
8
+ ## Decision
9
+ <!-- What was decided? Be specific and concrete. -->
10
+
11
+ ## Options Considered
12
+ <!-- What alternatives were evaluated? For each: name, brief description, and why it was chosen or rejected. -->
13
+
14
+ ### Option A: [Name]
15
+ <!-- Brief description. Why chosen/rejected. -->
16
+
17
+ ### Option B: [Name]
18
+ <!-- Brief description. Why chosen/rejected. -->
19
+
20
+ ## Reasoning
21
+ <!-- Why this option was selected. What factors mattered most? What trade-offs were accepted? -->
22
+
23
+ ## Consequences
24
+ <!-- What are the implications? What does this enable or constrain? Any known trade-offs or risks? -->
@@ -0,0 +1,15 @@
1
+ # Memory Index
2
+
3
+ **Updated:** YYYY-MM-DD
4
+
5
+ <!-- Format: - `file-path` — one-line summary -->
6
+
7
+ ## Active Tasks
8
+
9
+ ## Project Knowledge
10
+ - `project-memory/architecture.md` — Project architecture (not yet documented)
11
+ - `project-memory/requirements.md` — Project requirements (not yet documented)
12
+
13
+ ## Recent Decisions
14
+
15
+ ## Agent Lessons
@@ -0,0 +1,16 @@
1
+ # Agent Lessons
2
+
3
+ **Updated:** YYYY-MM-DD
4
+
5
+ <!-- Lessons learned during development. Each entry is a mistake, surprise, or hard-won insight that future sessions should know about. -->
6
+
7
+ ## Lessons
8
+
9
+ ### [Short Title]
10
+ <!-- One-sentence lesson. -->
11
+ - **Context:** <!-- When/how this was discovered. -->
12
+ - **Example:** <!-- Concrete code example or scenario if applicable. -->
13
+
14
+ ---
15
+
16
+ <!-- Add new lessons above this line. When entries exceed ~30, consolidate related lessons under grouped headers. -->
@@ -0,0 +1,16 @@
1
+ # Agent Patterns
2
+
3
+ **Updated:** YYYY-MM-DD
4
+
5
+ <!-- Reusable patterns and approaches that worked well. Load these to apply proven solutions. -->
6
+
7
+ ## Patterns
8
+
9
+ ### [Pattern Name]
10
+ <!-- What this pattern solves and when to use it. -->
11
+ - **Structure:** <!-- How the pattern is organized (e.g., file layout, function signatures). -->
12
+ - **Example:** <!-- Concrete usage example. -->
13
+
14
+ ---
15
+
16
+ <!-- Add new patterns above this line. -->
@@ -0,0 +1,27 @@
1
+ # [Task Name] — Implementation Plan
2
+
3
+ **Status:** active | **Updated:** YYYY-MM-DD
4
+
5
+ ## General Plan
6
+ <!-- High-level approach: architecture decisions, component design, data flow. Keep it to 1-2 paragraphs or a short list. This should answer "what are we building and how does it fit together?" -->
7
+
8
+ ## Detailed Plan
9
+ <!-- Step-by-step implementation tasks. Each step should be specific enough to implement directly. -->
10
+
11
+ ### Step 1: [Action]
12
+ <!-- What to do, which files to create/modify, any dependencies on prior steps. -->
13
+ - Files: `path/to/file.ts`
14
+ - Details:
15
+
16
+ ### Step 2: [Action]
17
+ - Files: `path/to/file.ts`
18
+ - Details:
19
+
20
+ ### Step 3: [Action]
21
+ - Files: `path/to/file.ts`
22
+ - Details:
23
+
24
+ ## Out of Scope
25
+ <!-- What this plan explicitly does NOT cover. Prevents scope creep during implementation. -->
26
+
27
+ -
@@ -0,0 +1,17 @@
1
+ # [Task Name] — Status
2
+
3
+ **Status:** active | **Updated:** YYYY-MM-DD
4
+
5
+ ## Progress
6
+ <!-- Check off steps as they complete. These should mirror the plan's detailed steps. -->
7
+
8
+ - [ ] Step 1: [description]
9
+ - [ ] Step 2: [description]
10
+ - [ ] Step 3: [description]
11
+
12
+ ## Notes
13
+ <!-- Any blockers, deviations from plan, or important observations during implementation. -->
14
+
15
+ ## Completed
16
+ <!-- Date when all steps finished. Leave empty until done. -->
17
+ **Completed:**