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 +105 -0
- package/bin/cli.js +130 -0
- package/package.json +28 -0
- package/skills/_memory-protocol.md +146 -0
- package/skills/create-skill/SKILL.md +242 -0
- package/skills/onboard/SKILL.md +417 -0
- package/templates/context.md +24 -0
- package/templates/decision.md +24 -0
- package/templates/index.md +15 -0
- package/templates/lessons.md +16 -0
- package/templates/patterns.md +16 -0
- package/templates/plan.md +27 -0
- package/templates/status.md +17 -0
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:**
|