mema-kit 1.0.4 → 1.0.6
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 +8 -8
- package/bin/cli.js +3 -3
- package/docs/guide.md +164 -47
- package/package.json +1 -1
- package/skills/{create-skill → mema.create-skill}/SKILL.md +2 -2
- package/skills/mema.implement/SKILL.md +184 -0
- package/skills/{onboard → mema.onboard}/SKILL.md +151 -11
- package/skills/mema.plan/SKILL.md +206 -0
- package/skills/{recall → mema.recall}/SKILL.md +5 -5
package/README.md
CHANGED
|
@@ -14,21 +14,21 @@ npx mema-kit
|
|
|
14
14
|
|
|
15
15
|
# 2. Open Claude Code and bootstrap memory
|
|
16
16
|
claude
|
|
17
|
-
> /onboard
|
|
17
|
+
> /mema.onboard
|
|
18
18
|
|
|
19
19
|
# 3. Next session: load memory into context
|
|
20
|
-
> /recall
|
|
20
|
+
> /mema.recall
|
|
21
21
|
```
|
|
22
22
|
|
|
23
|
-
`/onboard` scans your project, creates the `.mema/` memory structure, populates initial architecture and requirements docs, and configures CLAUDE.md and `.gitignore`. `/recall` loads that memory into any future session.
|
|
23
|
+
`/mema.onboard` scans your project, creates the `.mema/` memory structure, populates initial architecture and requirements docs, and configures CLAUDE.md and `.gitignore`. `/mema.recall` loads that memory into any future session.
|
|
24
24
|
|
|
25
25
|
## Built-in Skills
|
|
26
26
|
|
|
27
27
|
| Command | Purpose |
|
|
28
28
|
|---------|---------|
|
|
29
|
-
| `/onboard` | Bootstrap memory for a project — scans codebase, creates `.mema/`, populates initial knowledge |
|
|
30
|
-
| `/recall` | Load project memory into the current session — instant context on cold start |
|
|
31
|
-
| `/create-skill` | Generate a new memory-aware skill with the correct lifecycle phases |
|
|
29
|
+
| `/mema.onboard` | Bootstrap memory for a project — scans codebase, creates `.mema/`, populates initial knowledge |
|
|
30
|
+
| `/mema.recall` | Load project memory into the current session — instant context on cold start |
|
|
31
|
+
| `/mema.create-skill` | Generate a new memory-aware skill with the correct lifecycle phases |
|
|
32
32
|
|
|
33
33
|
## How Memory Works
|
|
34
34
|
|
|
@@ -64,10 +64,10 @@ The protocol is defined in `_memory-protocol.md` and shared across all skills (n
|
|
|
64
64
|
|
|
65
65
|
## Building Your Own Skills
|
|
66
66
|
|
|
67
|
-
Use `/create-skill` to generate memory-aware skills:
|
|
67
|
+
Use `/mema.create-skill` to generate memory-aware skills:
|
|
68
68
|
|
|
69
69
|
```
|
|
70
|
-
> /create-skill
|
|
70
|
+
> /mema.create-skill
|
|
71
71
|
|
|
72
72
|
Skill name: review
|
|
73
73
|
Purpose: Review code changes for quality and consistency
|
package/bin/cli.js
CHANGED
|
@@ -47,10 +47,10 @@ function runInstall() {
|
|
|
47
47
|
|
|
48
48
|
console.log('✓ mema-kit skills installed to .claude/skills/');
|
|
49
49
|
console.log('');
|
|
50
|
-
console.log('Next step: Open your project in Claude Code and run /onboard');
|
|
50
|
+
console.log('Next step: Open your project in Claude Code and run /mema.onboard');
|
|
51
51
|
console.log('');
|
|
52
52
|
console.log(' claude');
|
|
53
|
-
console.log(' > /onboard');
|
|
53
|
+
console.log(' > /mema.onboard');
|
|
54
54
|
console.log('');
|
|
55
55
|
}
|
|
56
56
|
|
|
@@ -123,7 +123,7 @@ Usage:
|
|
|
123
123
|
npx mema-kit --update Update skills to the latest version
|
|
124
124
|
npx mema-kit --help Show this help message
|
|
125
125
|
|
|
126
|
-
After installing, open your project in Claude Code and run /onboard.
|
|
126
|
+
After installing, open your project in Claude Code and run /mema.onboard.
|
|
127
127
|
|
|
128
128
|
Learn more: https://github.com/simonv15/mema-kit
|
|
129
129
|
`.trim());
|
package/docs/guide.md
CHANGED
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
|
|
3
3
|
**A memory protocol kit for Claude Code skills.**
|
|
4
4
|
|
|
5
|
-
|
|
5
|
+
Five built-in skills. Persistent memory across sessions. A protocol for building your own.
|
|
6
6
|
|
|
7
7
|
---
|
|
8
8
|
|
|
@@ -29,26 +29,26 @@ Think of it like a developer's notebook — it doesn't give you a bigger brain,
|
|
|
29
29
|
```bash
|
|
30
30
|
npx mema-kit # install skills to .claude/skills/
|
|
31
31
|
claude
|
|
32
|
-
> /onboard # scan project, create .mema/, populate initial memory
|
|
33
|
-
> /recall # next new session: load memory into context
|
|
32
|
+
> /mema.onboard # scan project, create .mema/, populate initial memory
|
|
33
|
+
> /mema.recall # next new session: load memory into context
|
|
34
34
|
```
|
|
35
35
|
|
|
36
|
-
`/onboard` reads your package.json, README, directory structure, and representative source files, then writes real content to `architecture.md` and `requirements.md`. Idempotent — safe to re-run.
|
|
36
|
+
`/mema.onboard` reads your package.json, README, directory structure, and representative source files, then writes real content to `architecture.md` and `requirements.md`. Idempotent — safe to re-run.
|
|
37
37
|
|
|
38
|
-
`/recall` loads your project memory into the current session — use it at the start of every new conversation to restore context instantly.
|
|
38
|
+
`/mema.recall` loads your project memory into the current session — use it at the start of every new conversation to restore context instantly.
|
|
39
39
|
|
|
40
40
|
---
|
|
41
41
|
|
|
42
|
-
## Recalling Memory: /recall
|
|
42
|
+
## Recalling Memory: /mema.recall
|
|
43
43
|
|
|
44
|
-
Every new Claude Code session starts with a blank context. `/recall` fixes the cold-start problem by reading `.mema/` and printing a formatted summary into the conversation.
|
|
44
|
+
Every new Claude Code session starts with a blank context. `/mema.recall` fixes the cold-start problem by reading `.mema/` and printing a formatted summary into the conversation.
|
|
45
45
|
|
|
46
46
|
### Modes
|
|
47
47
|
|
|
48
48
|
| Mode | Command | What you get |
|
|
49
49
|
|------|---------|--------------|
|
|
50
|
-
| **Minimal** (default) | `/recall` or `/recall minimal` | Purpose, stack, architecture, current status, memory map |
|
|
51
|
-
| **Full** | `/recall full` | Everything in Minimal + recent decisions, lessons, patterns, active context & plans |
|
|
50
|
+
| **Minimal** (default) | `/mema.recall` or `/mema.recall minimal` | Purpose, stack, architecture, current status, memory map |
|
|
51
|
+
| **Full** | `/mema.recall full` | Everything in Minimal + recent decisions, lessons, patterns, active context & plans |
|
|
52
52
|
|
|
53
53
|
### When to use which
|
|
54
54
|
|
|
@@ -60,84 +60,200 @@ Every new Claude Code session starts with a blank context. `/recall` fixes the c
|
|
|
60
60
|
| Quick check on what decisions exist | Full |
|
|
61
61
|
| Daily development work | Minimal |
|
|
62
62
|
|
|
63
|
-
`/recall` is **read-only** — it never modifies memory files. Safe to run at any time.
|
|
63
|
+
`/mema.recall` is **read-only** — it never modifies memory files. Safe to run at any time.
|
|
64
64
|
|
|
65
65
|
---
|
|
66
66
|
|
|
67
|
-
##
|
|
67
|
+
## Planning Work: /mema.plan
|
|
68
68
|
|
|
69
|
-
mema-
|
|
69
|
+
`/mema.plan` takes a high-level goal, explores your codebase, and produces a structured implementation plan with step-by-step specs. Plans are saved to `.mema/task-memory/` so `/mema.implement` can execute them.
|
|
70
70
|
|
|
71
|
-
###
|
|
71
|
+
### Usage
|
|
72
72
|
|
|
73
73
|
```
|
|
74
|
-
> /
|
|
75
|
-
|
|
76
|
-
|
|
77
|
-
Complexity: standard
|
|
74
|
+
> /mema.plan add user authentication
|
|
75
|
+
> /mema.plan refactor the database layer
|
|
76
|
+
> /mema.plan add search functionality to the API
|
|
78
77
|
```
|
|
79
78
|
|
|
80
|
-
|
|
79
|
+
### What it does
|
|
81
80
|
|
|
82
|
-
**
|
|
81
|
+
1. **Loads memory** — architecture, requirements, decisions, lessons, patterns
|
|
82
|
+
2. **Explores the codebase** — reads relevant source files, understands current patterns
|
|
83
|
+
3. **Asks clarifying questions** (1-2 max) if the goal is ambiguous
|
|
84
|
+
4. **Produces a plan** — general approach + detailed steps with file paths and specifics
|
|
85
|
+
5. **Saves to task-memory** — creates `context.md`, `plan.md`, and `status.md` in `task-memory/[task-name]/`
|
|
86
|
+
|
|
87
|
+
### Example output
|
|
83
88
|
|
|
84
89
|
```
|
|
85
|
-
|
|
90
|
+
## Plan: User Authentication
|
|
91
|
+
|
|
92
|
+
### Approach
|
|
93
|
+
Add JWT-based authentication using the existing Fastify plugin system.
|
|
94
|
+
Follows the controller → service → repository pattern already in the codebase.
|
|
95
|
+
|
|
96
|
+
### Steps (5 total)
|
|
97
|
+
1. Create auth database schema and migration
|
|
98
|
+
2. Implement auth service (register, login, token refresh)
|
|
99
|
+
3. Create auth route handlers
|
|
100
|
+
4. Add authentication middleware (Fastify plugin)
|
|
101
|
+
5. Add auth integration tests
|
|
102
|
+
|
|
103
|
+
### Out of Scope
|
|
104
|
+
- OAuth/social login
|
|
105
|
+
- Role-based access control
|
|
106
|
+
- Password reset flow
|
|
107
|
+
|
|
108
|
+
---
|
|
109
|
+
Plan saved to task-memory/user-authentication/
|
|
110
|
+
To start implementing: /mema.implement user-authentication
|
|
86
111
|
```
|
|
87
112
|
|
|
88
|
-
|
|
113
|
+
### Revising plans
|
|
114
|
+
|
|
115
|
+
If you run `/mema.plan` for a task that already has a plan, it will offer to revise the existing plan rather than starting from scratch. This makes `/mema.plan` idempotent — safe to re-run.
|
|
116
|
+
|
|
117
|
+
---
|
|
118
|
+
|
|
119
|
+
## Implementing Plans: /mema.implement
|
|
120
|
+
|
|
121
|
+
`/mema.implement` picks up steps from an existing plan, implements them one at a time, verifies the result, and tracks progress. It's designed to give you control — one step at a time by default.
|
|
122
|
+
|
|
123
|
+
### Usage
|
|
89
124
|
|
|
90
125
|
```
|
|
91
|
-
.
|
|
92
|
-
|
|
126
|
+
> /mema.implement user-authentication # implement next incomplete step
|
|
127
|
+
> /mema.implement user-authentication step 3 # implement a specific step
|
|
128
|
+
> /mema.implement user-authentication all # implement all remaining steps
|
|
129
|
+
> /mema.implement # list active tasks, then pick one
|
|
93
130
|
```
|
|
94
131
|
|
|
95
|
-
|
|
132
|
+
### What it does
|
|
96
133
|
|
|
97
|
-
|
|
134
|
+
1. **Loads the plan** — reads `plan.md`, `status.md`, and `context.md` from the task
|
|
135
|
+
2. **Picks the next step** — first incomplete step, or the one you specified
|
|
136
|
+
3. **Implements the step** — creates/modifies files following the plan's spec
|
|
137
|
+
4. **Verifies** — runs tests, checks for errors, validates against the plan
|
|
138
|
+
5. **Updates progress** — marks the step complete in `status.md`
|
|
139
|
+
6. **Reports** — shows what was done, what's next, overall progress
|
|
140
|
+
|
|
141
|
+
### Progress tracking
|
|
142
|
+
|
|
143
|
+
After each step, you'll see a progress summary:
|
|
98
144
|
|
|
99
145
|
```
|
|
100
|
-
|
|
101
|
-
|
|
102
|
-
|
|
103
|
-
|
|
146
|
+
## Progress: User Authentication
|
|
147
|
+
|
|
148
|
+
Step 2/5 complete: Implement auth service
|
|
149
|
+
|
|
150
|
+
Verified: All tests passing (4 new tests)
|
|
151
|
+
|
|
152
|
+
### Overall Progress
|
|
153
|
+
[====------] 2/5 steps
|
|
154
|
+
Next: Step 3 — Create auth route handlers
|
|
155
|
+
|
|
156
|
+
To continue: /mema.implement user-authentication
|
|
104
157
|
```
|
|
105
158
|
|
|
106
|
-
|
|
159
|
+
### Task completion
|
|
160
|
+
|
|
161
|
+
When all steps are done, `/mema.implement` offers to archive the task:
|
|
162
|
+
|
|
163
|
+
- Marks `status.md` as complete
|
|
164
|
+
- Moves `task-memory/[task-name]/` to `archive/[task-name]/`
|
|
165
|
+
- Removes the task from active tasks in `index.md`
|
|
166
|
+
- Records any lessons learned and patterns discovered
|
|
167
|
+
|
|
168
|
+
### Learning from implementation
|
|
169
|
+
|
|
170
|
+
After each step, `/mema.implement` reflects on the work:
|
|
171
|
+
- Unexpected issues become **lessons** in `agent-memory/lessons.md`
|
|
172
|
+
- Effective approaches become **patterns** in `agent-memory/patterns.md`
|
|
173
|
+
- Decisions made during implementation are saved to `project-memory/decisions/`
|
|
174
|
+
|
|
175
|
+
This means your memory grows smarter with every implementation cycle.
|
|
176
|
+
|
|
177
|
+
---
|
|
178
|
+
|
|
179
|
+
## The plan → implement Workflow
|
|
107
180
|
|
|
181
|
+
`/mema.plan` and `/mema.implement` form a complete spec-driven development workflow:
|
|
182
|
+
|
|
183
|
+
```
|
|
184
|
+
/mema.plan /mema.implement
|
|
185
|
+
│ │
|
|
186
|
+
├─ reads: ├─ reads:
|
|
187
|
+
│ architecture │ plan.md (from /mema.plan)
|
|
188
|
+
│ requirements │ status.md
|
|
189
|
+
│ decisions │ context.md
|
|
190
|
+
│ lessons & patterns │ architecture, decisions
|
|
191
|
+
│ │ lessons & patterns
|
|
192
|
+
├─ writes: │
|
|
193
|
+
│ task-memory/[task]/context.md ├─ writes:
|
|
194
|
+
│ task-memory/[task]/mema.plan.md │ status.md (mark steps done)
|
|
195
|
+
│ task-memory/[task]/status.md │ decisions/ (if any)
|
|
196
|
+
│ │ lessons.md (if any)
|
|
197
|
+
│ │ patterns.md (if any)
|
|
198
|
+
│ │ archive/ (on completion)
|
|
199
|
+
▼ ▼
|
|
200
|
+
both flow through .mema/index.md
|
|
108
201
|
```
|
|
109
|
-
|
|
202
|
+
|
|
203
|
+
### Full workflow example
|
|
204
|
+
|
|
205
|
+
```bash
|
|
206
|
+
# Session 1: Explore and plan
|
|
207
|
+
> /mema.recall # load project context
|
|
208
|
+
> /mema.plan add user authentication # explore codebase, produce plan
|
|
209
|
+
|
|
210
|
+
# Session 2: Implement (pick up where you left off)
|
|
211
|
+
> /mema.recall # load context + active tasks
|
|
212
|
+
> /mema.implement user-authentication # implement step 1
|
|
213
|
+
> /mema.implement user-authentication # implement step 2
|
|
214
|
+
|
|
215
|
+
# Session 3: Finish up
|
|
216
|
+
> /mema.recall
|
|
217
|
+
> /mema.implement user-authentication all # implement remaining steps
|
|
218
|
+
# → task archived, lessons saved
|
|
110
219
|
```
|
|
111
220
|
|
|
112
|
-
|
|
221
|
+
---
|
|
222
|
+
|
|
223
|
+
## Extending with Custom Skills
|
|
113
224
|
|
|
114
|
-
|
|
225
|
+
mema-kit ships with five built-in skills (`/mema.onboard`, `/mema.recall`, `/mema.plan`, `/mema.implement`, `/mema.create-skill`). You can create your own skills to extend the workflow.
|
|
226
|
+
|
|
227
|
+
### Example: Create `/explore`
|
|
115
228
|
|
|
116
229
|
```
|
|
117
|
-
> /create-skill
|
|
118
|
-
Name:
|
|
119
|
-
Purpose:
|
|
120
|
-
Complexity:
|
|
230
|
+
> /mema.create-skill
|
|
231
|
+
Name: explore
|
|
232
|
+
Purpose: Research technical decisions and save findings
|
|
233
|
+
Complexity: standard
|
|
121
234
|
```
|
|
122
235
|
|
|
123
|
-
|
|
236
|
+
Creates `.claude/skills/explore/SKILL.md` — a 4-phase skill that loads existing architecture and decisions, helps you research options, then saves new decisions and context to `.mema/`.
|
|
124
237
|
|
|
125
238
|
**Using it:**
|
|
126
239
|
|
|
127
240
|
```
|
|
128
|
-
> /
|
|
241
|
+
> /explore what auth strategy should we use?
|
|
129
242
|
```
|
|
130
243
|
|
|
131
|
-
The agent loads
|
|
244
|
+
The agent loads your stack from memory, researches JWT vs sessions vs OAuth, and saves the decision:
|
|
245
|
+
|
|
246
|
+
```
|
|
247
|
+
.mema/project-memory/decisions/2026-02-24-auth-strategy.md
|
|
248
|
+
→ "JWT with refresh tokens. Why: stateless, fits our REST API, team has experience."
|
|
249
|
+
```
|
|
132
250
|
|
|
133
|
-
|
|
134
|
-
- Archives `task-memory/user-auth/` to `archive/user-auth/`
|
|
135
|
-
- Updates `index.md`
|
|
251
|
+
Next session, any skill that loads memory will know this decision exists — including `/mema.plan`, which can incorporate it into implementation plans.
|
|
136
252
|
|
|
137
|
-
### How
|
|
253
|
+
### How custom skills connect with built-ins
|
|
138
254
|
|
|
139
255
|
```
|
|
140
|
-
/explore /plan /implement
|
|
256
|
+
/explore /mema.plan /mema.implement
|
|
141
257
|
│ │ │
|
|
142
258
|
├─ reads: ├─ reads: ├─ reads:
|
|
143
259
|
│ architecture │ architecture │ plan
|
|
@@ -154,7 +270,7 @@ The agent loads the plan, architecture, and past lessons. It implements each ste
|
|
|
154
270
|
|
|
155
271
|
Each skill reads what previous skills wrote. The index ties it all together.
|
|
156
272
|
|
|
157
|
-
> **Tip:** Start every new session with `/recall` to load project context before using other skills. It takes seconds and saves minutes of re-exploration.
|
|
273
|
+
> **Tip:** Start every new session with `/mema.recall` to load project context before using other skills. It takes seconds and saves minutes of re-exploration.
|
|
158
274
|
|
|
159
275
|
---
|
|
160
276
|
|
|
@@ -206,4 +322,5 @@ The index is a **rebuildable cache** — if it gets out of sync, the next skill
|
|
|
206
322
|
- **Memory is just markdown.** Open any file to see what the agent knows. Edit directly if something's wrong.
|
|
207
323
|
- **`.mema/` is gitignored by default.** To share decisions with your team, uncomment `!.mema/project-memory/` in `.gitignore`.
|
|
208
324
|
- **Curate, don't hoard.** The value of memory is its signal-to-noise ratio. Prune aggressively.
|
|
209
|
-
- **Any skill can use the protocol.** Use `/create-skill` or manually follow the 4-phase lifecycle.
|
|
325
|
+
- **Any skill can use the protocol.** Use `/mema.create-skill` or manually follow the 4-phase lifecycle.
|
|
326
|
+
- **One step at a time.** `/mema.implement` defaults to one step per invocation. This gives you a chance to review each change before continuing.
|
package/package.json
CHANGED
|
@@ -2,7 +2,7 @@
|
|
|
2
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
3
|
---
|
|
4
4
|
|
|
5
|
-
# /create-skill — Generate Memory-Aware Skills
|
|
5
|
+
# /mema.create-skill — Generate Memory-Aware Skills
|
|
6
6
|
|
|
7
7
|
You are creating a new Claude Code skill that integrates with mema-kit's memory protocol. Follow these steps carefully.
|
|
8
8
|
|
|
@@ -48,7 +48,7 @@ You are executing the /[skill-name] skill. Follow these steps carefully.
|
|
|
48
48
|
## Phase 1: AUTO-LOAD
|
|
49
49
|
|
|
50
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
|
|
51
|
+
2. If `index.md` is missing or empty, inform the user to run `/mema.onboard` first
|
|
52
52
|
3. Based on the user's request, identify and read relevant memory files
|
|
53
53
|
4. Read only what's needed — don't load everything
|
|
54
54
|
|
|
@@ -0,0 +1,184 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Execute implementation plan steps one at a time. Picks up the next step from an existing plan, implements it, verifies the result, and tracks progress. Run /mema.plan first to create a plan.
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
# /mema.implement — Plan Step Execution
|
|
6
|
+
|
|
7
|
+
You are executing the /mema.implement skill. Follow these steps carefully.
|
|
8
|
+
|
|
9
|
+
This skill picks up a step from an existing plan (created by `/mema.plan`), implements it, verifies the result, and updates progress tracking. By default, it implements **one step at a time** to give the user control over the process.
|
|
10
|
+
|
|
11
|
+
## Phase 1: AUTO-LOAD
|
|
12
|
+
|
|
13
|
+
1. Read `.mema/index.md` to understand current project state
|
|
14
|
+
2. If `index.md` is missing or `.mema/` does not exist:
|
|
15
|
+
- Tell the user: "No memory found. Run `/mema.onboard` first to set up mema-kit for this project."
|
|
16
|
+
- **Stop here** — do not continue to further steps.
|
|
17
|
+
3. If `index.md` is empty, run the **Rebuild Procedure** from `_memory-protocol.md`
|
|
18
|
+
4. Scan `## Active Tasks` in `index.md` to find tasks with plans
|
|
19
|
+
5. Load relevant memory files:
|
|
20
|
+
- `project-memory/architecture.md` — for technical context during implementation
|
|
21
|
+
- `project-memory/decisions/` — past decisions that affect implementation
|
|
22
|
+
- `agent-memory/lessons.md` — mistakes to avoid
|
|
23
|
+
- `agent-memory/patterns.md` — reusable approaches
|
|
24
|
+
|
|
25
|
+
## Phase 2: WORK
|
|
26
|
+
|
|
27
|
+
### 2a: Select Task
|
|
28
|
+
|
|
29
|
+
Parse the user's input to determine which task to implement:
|
|
30
|
+
|
|
31
|
+
- **Task specified:** `/mema.implement user-auth` → look for `task-memory/user-auth/`
|
|
32
|
+
- **Task + step specified:** `/mema.implement user-auth step 3` → load that specific step
|
|
33
|
+
- **No task specified:** `/mema.implement` → list active tasks from index.md and ask which one
|
|
34
|
+
- **"all" modifier:** `/mema.implement user-auth all` → implement all remaining steps sequentially (see 2e)
|
|
35
|
+
|
|
36
|
+
If the specified task directory doesn't exist:
|
|
37
|
+
- Tell the user: "No plan found for '[task-name]'. Run `/mema.plan [goal]` first to create an implementation plan."
|
|
38
|
+
- **Stop here.**
|
|
39
|
+
|
|
40
|
+
### 2b: Load Task Context
|
|
41
|
+
|
|
42
|
+
Read the task's files from `task-memory/[task-name]/`:
|
|
43
|
+
|
|
44
|
+
1. **`plan.md`** — the full implementation plan with all steps
|
|
45
|
+
2. **`status.md`** — current progress (which steps are done)
|
|
46
|
+
3. **`context.md`** — exploration findings relevant to this task
|
|
47
|
+
|
|
48
|
+
If `plan.md` is missing, tell the user: "Task directory exists but has no plan. Run `/mema.plan [goal]` to create one."
|
|
49
|
+
|
|
50
|
+
### 2c: Select Step
|
|
51
|
+
|
|
52
|
+
Determine which step to implement:
|
|
53
|
+
|
|
54
|
+
- **If user specified a step** (e.g., `step 3`): validate it exists in the plan and isn't already complete. If already complete, inform the user and ask if they want to re-implement it.
|
|
55
|
+
- **If no step specified:** find the first incomplete step in `status.md` (first unchecked `- [ ]` item). If all steps are complete, see section 2f (Task Completion).
|
|
56
|
+
|
|
57
|
+
Tell the user which step you're implementing:
|
|
58
|
+
|
|
59
|
+
```
|
|
60
|
+
## Implementing Step [N]/[total]: [Step title]
|
|
61
|
+
|
|
62
|
+
[Brief description of what this step does]
|
|
63
|
+
```
|
|
64
|
+
|
|
65
|
+
### 2d: Implement the Step
|
|
66
|
+
|
|
67
|
+
Follow the plan's specification for this step:
|
|
68
|
+
|
|
69
|
+
1. **Read the step details** from `plan.md` — files to create/modify, specific implementation details, dependencies
|
|
70
|
+
2. **Check dependencies** — verify that all prerequisite steps are marked complete in `status.md`. If a dependency is incomplete, warn the user: "Step [N] depends on Step [M] which isn't complete yet. Proceed anyway?" If the user says no, stop.
|
|
71
|
+
3. **Implement the changes** — create/modify files as specified in the plan. Follow the project's existing coding patterns (from architecture.md and patterns.md). Apply lessons learned (from lessons.md) to avoid known pitfalls.
|
|
72
|
+
4. **Verify the changes:**
|
|
73
|
+
- If the project has tests and the step involves testable code: run relevant tests
|
|
74
|
+
- Check for obvious errors (syntax, imports, type errors)
|
|
75
|
+
- Validate the implementation matches the plan's specification
|
|
76
|
+
- If verification fails: do NOT mark the step as complete. Inform the user with details about what went wrong and suggest fixes.
|
|
77
|
+
|
|
78
|
+
### 2e: Implement All Remaining (if requested)
|
|
79
|
+
|
|
80
|
+
If the user requested "all" (e.g., `/mema.implement user-auth all`):
|
|
81
|
+
|
|
82
|
+
1. Implement steps sequentially, starting from the first incomplete step
|
|
83
|
+
2. After each step, verify before moving to the next
|
|
84
|
+
3. If any step fails verification, stop and report. Do not continue to subsequent steps.
|
|
85
|
+
4. After each successful step, show a brief progress update:
|
|
86
|
+
```
|
|
87
|
+
Step [N]/[total] complete: [description]
|
|
88
|
+
```
|
|
89
|
+
5. After all steps are done, proceed to 2f (Task Completion)
|
|
90
|
+
|
|
91
|
+
### 2f: Update Progress
|
|
92
|
+
|
|
93
|
+
After implementing a step (whether it succeeded or failed):
|
|
94
|
+
|
|
95
|
+
1. **Update `status.md`:**
|
|
96
|
+
- Mark the completed step: `- [x] Step N: [description]`
|
|
97
|
+
- Add any notes about deviations from the plan under `## Notes`
|
|
98
|
+
- Update the `**Updated:**` date
|
|
99
|
+
|
|
100
|
+
2. **Print a progress summary:**
|
|
101
|
+
|
|
102
|
+
```
|
|
103
|
+
## Progress: [Task Name]
|
|
104
|
+
|
|
105
|
+
Step [N]/[total] complete: [what was done]
|
|
106
|
+
|
|
107
|
+
[if verification passed:]
|
|
108
|
+
Verified: [how — tests passed, no errors, etc.]
|
|
109
|
+
|
|
110
|
+
[if verification failed:]
|
|
111
|
+
Issue: [what went wrong]
|
|
112
|
+
Suggested fix: [how to resolve]
|
|
113
|
+
|
|
114
|
+
### Overall Progress
|
|
115
|
+
[====------] [completed]/[total] steps
|
|
116
|
+
Next: Step [N+1] — [description]
|
|
117
|
+
|
|
118
|
+
To continue: /mema.implement [task-name]
|
|
119
|
+
```
|
|
120
|
+
|
|
121
|
+
### 2g: Task Completion
|
|
122
|
+
|
|
123
|
+
If all steps are now complete:
|
|
124
|
+
|
|
125
|
+
1. Print a completion summary:
|
|
126
|
+
|
|
127
|
+
```
|
|
128
|
+
## Task Complete: [Task Name]
|
|
129
|
+
|
|
130
|
+
All [N] steps implemented successfully.
|
|
131
|
+
|
|
132
|
+
### What was built
|
|
133
|
+
- [Summary of changes made across all steps]
|
|
134
|
+
|
|
135
|
+
### Files changed
|
|
136
|
+
- [List of files created or modified]
|
|
137
|
+
|
|
138
|
+
Would you like to archive this task? (This moves it from active tasks to archive/)
|
|
139
|
+
```
|
|
140
|
+
|
|
141
|
+
2. If the user confirms archiving (or doesn't object), proceed to archive in Phase 3.
|
|
142
|
+
3. If the user wants to keep it active (e.g., for further iteration), leave it in `task-memory/`.
|
|
143
|
+
|
|
144
|
+
### 2h: Learn
|
|
145
|
+
|
|
146
|
+
After completing work (whether one step or all steps), reflect:
|
|
147
|
+
|
|
148
|
+
- Did anything unexpected happen during implementation? → Record as a lesson
|
|
149
|
+
- Did you use a pattern that worked well? → Record as a pattern
|
|
150
|
+
- Did any previous lesson prove wrong or need updating? → Update or delete it
|
|
151
|
+
- Did the plan need adjustment? → Note this for future planning improvements
|
|
152
|
+
|
|
153
|
+
## Phase 3: AUTO-SAVE & CURATE
|
|
154
|
+
|
|
155
|
+
Follow the curation rules in `_memory-protocol.md`. For each piece of knowledge produced:
|
|
156
|
+
|
|
157
|
+
- **Decisions made** during implementation → ADD to `project-memory/decisions/YYYY-MM-DD-short-name.md`
|
|
158
|
+
- **Architecture changes** (if implementation changed the architecture) → UPDATE `project-memory/architecture.md`
|
|
159
|
+
- **Lessons learned** → ADD/UPDATE `agent-memory/lessons.md`
|
|
160
|
+
- **Patterns discovered** → ADD/UPDATE `agent-memory/patterns.md`
|
|
161
|
+
- **Task progress** → UPDATE `task-memory/[task-name]/status.md`
|
|
162
|
+
|
|
163
|
+
Apply ADD/UPDATE/DELETE/NOOP to each memory file. Most files will be NOOP.
|
|
164
|
+
|
|
165
|
+
### Task Archiving (on completion)
|
|
166
|
+
|
|
167
|
+
If the task is fully complete and the user has confirmed archiving:
|
|
168
|
+
|
|
169
|
+
1. Update `task-memory/[task-name]/status.md`:
|
|
170
|
+
- Set `**Status:** complete`
|
|
171
|
+
- Fill in the `**Completed:**` field with today's date
|
|
172
|
+
2. Move the entire `task-memory/[task-name]/` directory to `archive/[task-name]/`
|
|
173
|
+
3. Remove the task from `## Active Tasks` in `index.md`
|
|
174
|
+
|
|
175
|
+
## Phase 4: AUTO-INDEX
|
|
176
|
+
|
|
177
|
+
Update `.mema/index.md`:
|
|
178
|
+
1. Re-read the current index
|
|
179
|
+
2. If a step was completed: update the task's summary in `## Active Tasks` (e.g., "3/7 steps complete")
|
|
180
|
+
3. If the task was archived: move entry from `## Active Tasks` to remove it, and optionally note it under a completed tasks record
|
|
181
|
+
4. Add entries for any new files (decisions, lessons, patterns)
|
|
182
|
+
5. Update summaries for modified files
|
|
183
|
+
6. Remove entries for deleted files
|
|
184
|
+
7. Update the `**Updated:**` date
|
|
@@ -2,7 +2,7 @@
|
|
|
2
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
3
|
---
|
|
4
4
|
|
|
5
|
-
# /onboard — Project Memory Bootstrap
|
|
5
|
+
# /mema.onboard — Project Memory Bootstrap
|
|
6
6
|
|
|
7
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
8
|
|
|
@@ -341,13 +341,15 @@ Build the index from the files you just created:
|
|
|
341
341
|
|
|
342
342
|
## Step 6: Update CLAUDE.md
|
|
343
343
|
|
|
344
|
-
|
|
345
|
-
|
|
346
|
-
|
|
347
|
-
|
|
348
|
-
|
|
344
|
+
Read the current `CLAUDE.md` (if it exists) and follow the appropriate path:
|
|
345
|
+
|
|
346
|
+
### Path A: CLAUDE.md already exists
|
|
347
|
+
|
|
348
|
+
1. Search for `## Memory System` in the file content
|
|
349
|
+
2. If found → **skip this step entirely** (already configured). Record outcome as **skipped**.
|
|
350
|
+
3. If not found → append the Memory System section (see below) at the end of the file. Record outcome as **appended**.
|
|
349
351
|
|
|
350
|
-
|
|
352
|
+
Memory System section to append:
|
|
351
353
|
|
|
352
354
|
```
|
|
353
355
|
## Memory System
|
|
@@ -359,6 +361,134 @@ Memory lives in `.mema/`. At the start of each task, read `.mema/index.md` to lo
|
|
|
359
361
|
Memory is managed automatically by skills — do not manually modify `.mema/` files unless correcting an error.
|
|
360
362
|
```
|
|
361
363
|
|
|
364
|
+
### Path B: CLAUDE.md does NOT exist — Generate comprehensive file
|
|
365
|
+
|
|
366
|
+
Follow sub-steps 6a through 6f to build a rich CLAUDE.md from scratch. Use the scan data collected in Step 4 for all content. Record outcome as **generated**.
|
|
367
|
+
|
|
368
|
+
#### 6a: Ask user "About Me"
|
|
369
|
+
|
|
370
|
+
Ask the user a single question using the AskUserQuestion tool:
|
|
371
|
+
|
|
372
|
+
> "Before I generate your CLAUDE.md, I'd like to personalize it. How would you describe yourself? (e.g., experience level, preferences for code style, anything you want Claude to know)"
|
|
373
|
+
|
|
374
|
+
Provide 3 options:
|
|
375
|
+
- **Junior developer** — "I'm learning. Explain decisions, be thorough in comments, correct my terminology gently."
|
|
376
|
+
- **Senior developer** — "I'm experienced. Keep explanations brief, focus on trade-offs and edge cases."
|
|
377
|
+
- **Skip** — "Skip personalization, use a sensible default."
|
|
378
|
+
|
|
379
|
+
If the user selects "Skip" or doesn't respond, use this default:
|
|
380
|
+
|
|
381
|
+
```
|
|
382
|
+
When I ask you to implement something, briefly explain key decisions. Prefer clear, well-commented code.
|
|
383
|
+
```
|
|
384
|
+
|
|
385
|
+
#### 6b: Write the `# About Me` section
|
|
386
|
+
|
|
387
|
+
Use the user's response from 6a to write a natural-language paragraph (3-5 lines). This section uses **H1** (`# About Me`), matching mema-kit's own CLAUDE.md convention.
|
|
388
|
+
|
|
389
|
+
#### 6c: Write the `## Project Overview` section
|
|
390
|
+
|
|
391
|
+
Using Step 4 scan data, generate three sub-sections:
|
|
392
|
+
|
|
393
|
+
**Opening paragraph:** Project name (from `package.json` name field, `README.md` title, or directory name as fallback) and a 1-2 sentence description of what the project does.
|
|
394
|
+
|
|
395
|
+
**`### Repository Structure`:** A directory tree (top-level + 1 level deep) with inline comments explaining each directory's purpose. Use the `tree` format:
|
|
396
|
+
|
|
397
|
+
```
|
|
398
|
+
project-name/
|
|
399
|
+
├── src/ # Source code
|
|
400
|
+
├── tests/ # Test suite
|
|
401
|
+
└── package.json # Dependencies and scripts
|
|
402
|
+
```
|
|
403
|
+
|
|
404
|
+
**`### Architecture`:** Architecture pattern (e.g., REST API, CLI tool, library), key entry points, and data flow. Keep to 2-4 sentences. If the project is too simple or unclear for an architecture description, write: "Architecture details will be added as the project grows."
|
|
405
|
+
|
|
406
|
+
#### 6d: Write the `## Coding Standards` section
|
|
407
|
+
|
|
408
|
+
Using Step 4c source file analysis, generate a bullet list covering:
|
|
409
|
+
|
|
410
|
+
- **Naming:** Conventions observed (camelCase, snake_case, kebab-case for files, etc.)
|
|
411
|
+
- **Style:** Formatting patterns (semicolons, quotes, indentation)
|
|
412
|
+
- **Patterns:** Recurring code patterns (e.g., "error-first callbacks", "async/await throughout")
|
|
413
|
+
- **Tooling:** Linting/formatting tools detected (ESLint, Prettier, Black, rustfmt, etc. — check `devDependencies`, config files like `.eslintrc`, `.prettierrc`, `pyproject.toml [tool.black]`)
|
|
414
|
+
|
|
415
|
+
If insufficient data for any bullet, use a placeholder like: "No linting configuration detected — consider adding one."
|
|
416
|
+
|
|
417
|
+
#### 6e: Write the `## Technical Workflows` section
|
|
418
|
+
|
|
419
|
+
Using Step 4a package manager files (`package.json` scripts, `Makefile` targets, `pyproject.toml [tool.poetry.scripts]`, `Cargo.toml`, etc.), generate a list of common commands:
|
|
420
|
+
|
|
421
|
+
```
|
|
422
|
+
- `npm run dev` — Start development server
|
|
423
|
+
- `npm test` — Run test suite
|
|
424
|
+
- `npm run build` — Build for production
|
|
425
|
+
```
|
|
426
|
+
|
|
427
|
+
Include dev, test, build, and lint commands at minimum (if they exist). If no commands are detected, write: "No build/test commands detected. Add scripts to `package.json` (or equivalent) as the project matures."
|
|
428
|
+
|
|
429
|
+
#### 6f: Write the `## Skill Commands` and `## Memory System` sections
|
|
430
|
+
|
|
431
|
+
**Skill Commands:** Scan the `.claude/skills/` directory. For each subdirectory containing a `SKILL.md`, read the YAML frontmatter `description` field. Generate an entry:
|
|
432
|
+
|
|
433
|
+
```
|
|
434
|
+
- `/skill-name` — [description from frontmatter]
|
|
435
|
+
```
|
|
436
|
+
|
|
437
|
+
If no skills are found (shouldn't happen since we just installed them, but as a fallback):
|
|
438
|
+
|
|
439
|
+
```
|
|
440
|
+
- `/mema.onboard` — Bootstrap the mema-kit memory system
|
|
441
|
+
- `/mema.recall` — Recall project memory into current session
|
|
442
|
+
- `/mema.create-skill` — Generate a new memory-aware skill
|
|
443
|
+
```
|
|
444
|
+
|
|
445
|
+
**Memory System:** Append the standard Memory System section (same text as Path A).
|
|
446
|
+
|
|
447
|
+
#### Assemble the final CLAUDE.md
|
|
448
|
+
|
|
449
|
+
Combine all sections into a single file in this order and write it:
|
|
450
|
+
|
|
451
|
+
```
|
|
452
|
+
# CLAUDE.md
|
|
453
|
+
|
|
454
|
+
This file provides guidance to Claude Code when working with code in this repository.
|
|
455
|
+
|
|
456
|
+
# About Me
|
|
457
|
+
[Content from 6b]
|
|
458
|
+
|
|
459
|
+
## Project Overview
|
|
460
|
+
|
|
461
|
+
[Content from 6c — opening paragraph]
|
|
462
|
+
|
|
463
|
+
### Repository Structure
|
|
464
|
+
|
|
465
|
+
[Content from 6c — tree]
|
|
466
|
+
|
|
467
|
+
### Architecture
|
|
468
|
+
|
|
469
|
+
[Content from 6c — architecture description]
|
|
470
|
+
|
|
471
|
+
## Coding Standards
|
|
472
|
+
|
|
473
|
+
[Content from 6d]
|
|
474
|
+
|
|
475
|
+
## Technical Workflows
|
|
476
|
+
|
|
477
|
+
[Content from 6e]
|
|
478
|
+
|
|
479
|
+
## Skill Commands
|
|
480
|
+
|
|
481
|
+
[Content from 6f — skill list]
|
|
482
|
+
|
|
483
|
+
## Memory System
|
|
484
|
+
|
|
485
|
+
This project uses mema-kit for persistent memory across sessions.
|
|
486
|
+
|
|
487
|
+
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`.
|
|
488
|
+
|
|
489
|
+
Memory is managed automatically by skills — do not manually modify `.mema/` files unless correcting an error.
|
|
490
|
+
```
|
|
491
|
+
|
|
362
492
|
## Step 7: Update .gitignore
|
|
363
493
|
|
|
364
494
|
1. Read the current `.gitignore` (if it exists)
|
|
@@ -378,14 +508,22 @@ Append this block:
|
|
|
378
508
|
|
|
379
509
|
## Step 8: Confirm to the User
|
|
380
510
|
|
|
381
|
-
Print a summary of what was done, including what you discovered about the project
|
|
511
|
+
Print a summary of what was done, including what you discovered about the project. Use the CLAUDE.md outcome recorded in Step 6 to select the appropriate message.
|
|
512
|
+
|
|
513
|
+
For the CLAUDE.md line, use the matching outcome:
|
|
514
|
+
|
|
515
|
+
- **generated** → `[check] CLAUDE.md generated with project overview, coding standards, workflows, and memory system`
|
|
516
|
+
- **appended** → `[check] CLAUDE.md updated — memory system section appended`
|
|
517
|
+
- **skipped** → `[check] CLAUDE.md — memory system section already present`
|
|
518
|
+
|
|
519
|
+
### Fresh setup (first run):
|
|
382
520
|
|
|
383
521
|
```
|
|
384
522
|
mema-kit initialized! Here's what was set up:
|
|
385
523
|
|
|
386
524
|
[check] .mema/ directory structure (memory system)
|
|
387
525
|
[check] Memory templates in .mema/_templates/
|
|
388
|
-
[check] CLAUDE.md
|
|
526
|
+
[check] [CLAUDE.md outcome message from above]
|
|
389
527
|
[check] .gitignore updated to exclude .mema/
|
|
390
528
|
|
|
391
529
|
Project scan results:
|
|
@@ -403,14 +541,16 @@ Memory populated:
|
|
|
403
541
|
Next: Start working on your project. Memory will be loaded and saved automatically by any mema-kit skill.
|
|
404
542
|
```
|
|
405
543
|
|
|
406
|
-
|
|
544
|
+
### Re-run (some items already existed):
|
|
545
|
+
|
|
546
|
+
Adjust the summary to show what was verified vs. created:
|
|
407
547
|
|
|
408
548
|
```
|
|
409
549
|
mema-kit verified! Everything looks good:
|
|
410
550
|
|
|
411
551
|
[check] .mema/ directory structure — already exists, verified
|
|
412
552
|
[check] Memory templates — already exist, skipped
|
|
413
|
-
[check] CLAUDE.md
|
|
553
|
+
[check] [CLAUDE.md outcome message from above]
|
|
414
554
|
[check] .gitignore — .mema/ already excluded
|
|
415
555
|
|
|
416
556
|
Your setup is intact. No changes were needed.
|
|
@@ -0,0 +1,206 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Break a high-level goal into a structured implementation plan. Explores the codebase, produces step-by-step specs, and saves them to task-memory/ for use by /mema.implement.
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
# /mema.plan — Implementation Planning
|
|
6
|
+
|
|
7
|
+
You are executing the /mema.plan skill. Follow these steps carefully.
|
|
8
|
+
|
|
9
|
+
This skill takes a user's goal (e.g., `/mema.plan add user authentication`), explores the codebase, and produces a detailed implementation plan saved to `.mema/task-memory/[task-name]/`.
|
|
10
|
+
|
|
11
|
+
## Phase 1: AUTO-LOAD
|
|
12
|
+
|
|
13
|
+
1. Read `.mema/index.md` to understand current project state
|
|
14
|
+
2. If `index.md` is missing or `.mema/` does not exist:
|
|
15
|
+
- Tell the user: "No memory found. Run `/mema.onboard` first to set up mema-kit for this project."
|
|
16
|
+
- **Stop here** — do not continue to further steps.
|
|
17
|
+
3. If `index.md` is empty, run the **Rebuild Procedure** from `_memory-protocol.md`
|
|
18
|
+
4. Load relevant memory files:
|
|
19
|
+
- `project-memory/architecture.md` — to understand the current stack and structure
|
|
20
|
+
- `project-memory/requirements.md` — to check how the goal fits project requirements
|
|
21
|
+
- `project-memory/decisions/` — recent decisions that might affect the plan
|
|
22
|
+
- `agent-memory/lessons.md` — mistakes to avoid in the plan
|
|
23
|
+
- `agent-memory/patterns.md` — reusable approaches to incorporate
|
|
24
|
+
|
|
25
|
+
Read only what's needed — don't load everything.
|
|
26
|
+
|
|
27
|
+
## Phase 2: WORK
|
|
28
|
+
|
|
29
|
+
### 2a: Parse the Goal
|
|
30
|
+
|
|
31
|
+
Extract the task goal from the user's input. The goal is everything after `/mema.plan`.
|
|
32
|
+
|
|
33
|
+
- Example: `/mema.plan add user authentication` → goal is "add user authentication"
|
|
34
|
+
- Example: `/mema.plan refactor the database layer` → goal is "refactor the database layer"
|
|
35
|
+
|
|
36
|
+
If no goal is provided, ask the user: "What would you like to plan? Describe your goal in a sentence or two."
|
|
37
|
+
|
|
38
|
+
**Derive the task name** from the goal in kebab-case:
|
|
39
|
+
- "add user authentication" → `user-authentication`
|
|
40
|
+
- "refactor the database layer" → `database-layer-refactor`
|
|
41
|
+
- Keep it short (2-4 words max). Drop filler words like "add", "create", "the".
|
|
42
|
+
|
|
43
|
+
### 2b: Check for Existing Task
|
|
44
|
+
|
|
45
|
+
Check if `task-memory/[task-name]/` already exists:
|
|
46
|
+
|
|
47
|
+
- **If it exists:** Read the existing `plan.md`, `context.md`, and `status.md`. Tell the user: "Found an existing plan for [task-name]. Would you like to revise it, or start fresh?" If revising, load the existing plan as a starting point. If starting fresh, overwrite the existing files.
|
|
48
|
+
- **If it doesn't exist:** Continue to the next step.
|
|
49
|
+
|
|
50
|
+
### 2c: Explore the Codebase
|
|
51
|
+
|
|
52
|
+
Before writing the plan, explore the codebase to understand what exists and what needs to change. This is the intelligence step — don't skip it.
|
|
53
|
+
|
|
54
|
+
1. **Identify relevant files** — Based on the goal and loaded architecture, determine which source files, configs, and tests are relevant
|
|
55
|
+
2. **Read representative files** — Read 3-5 key files to understand current patterns, conventions, and structure
|
|
56
|
+
3. **Map dependencies** — Note what existing code the new work depends on or affects
|
|
57
|
+
4. **Identify constraints** — Note any technical constraints, compatibility requirements, or limitations discovered
|
|
58
|
+
|
|
59
|
+
### 2d: Clarify if Needed
|
|
60
|
+
|
|
61
|
+
If the goal is ambiguous, ask **1-2 clarifying questions** (no more). Use the AskUserQuestion tool.
|
|
62
|
+
|
|
63
|
+
Good clarifying questions:
|
|
64
|
+
- "Should X support Y, or is Z sufficient for now?"
|
|
65
|
+
- "Do you want this to follow the existing pattern in [file], or take a different approach?"
|
|
66
|
+
|
|
67
|
+
Skip this step if the goal is clear from context + exploration.
|
|
68
|
+
|
|
69
|
+
### 2e: Write the Plan
|
|
70
|
+
|
|
71
|
+
Using your exploration findings and loaded memory, produce the plan in three parts:
|
|
72
|
+
|
|
73
|
+
**General Plan** — High-level approach in 1-2 paragraphs:
|
|
74
|
+
- What are we building/changing?
|
|
75
|
+
- How does it fit with the existing architecture?
|
|
76
|
+
- What key architectural decisions does this plan make?
|
|
77
|
+
|
|
78
|
+
**Detailed Steps** — Step-by-step implementation specs. Each step must include:
|
|
79
|
+
- **Action:** What to do (create file, modify function, add test, etc.)
|
|
80
|
+
- **Files:** Specific file paths to create or modify
|
|
81
|
+
- **Details:** Enough detail that `/mema.implement` can execute the step without ambiguity
|
|
82
|
+
- **Dependencies:** Which prior steps must be complete first (if any)
|
|
83
|
+
|
|
84
|
+
Rules for steps:
|
|
85
|
+
- Each step should be small enough to implement in a single `/mema.implement` invocation
|
|
86
|
+
- Order steps logically (foundations first, then features, then tests, then cleanup)
|
|
87
|
+
- Be specific about file paths — use the actual paths discovered during exploration
|
|
88
|
+
- Include test steps where appropriate (not just at the end)
|
|
89
|
+
|
|
90
|
+
**Out of Scope** — Explicitly list what this plan does NOT cover. This prevents scope creep during implementation.
|
|
91
|
+
|
|
92
|
+
### 2f: Write Task Files
|
|
93
|
+
|
|
94
|
+
Create `task-memory/[task-name]/` with three files:
|
|
95
|
+
|
|
96
|
+
**`context.md`** — Exploration findings relevant to this task:
|
|
97
|
+
```
|
|
98
|
+
# [Task Name] — Exploration Context
|
|
99
|
+
|
|
100
|
+
**Status:** active | **Updated:** [today's date]
|
|
101
|
+
|
|
102
|
+
## Summary
|
|
103
|
+
[2-3 sentences: what was explored and the key takeaway]
|
|
104
|
+
|
|
105
|
+
## Key Findings
|
|
106
|
+
- [Important facts, constraints, or insights discovered during exploration]
|
|
107
|
+
|
|
108
|
+
## Open Questions
|
|
109
|
+
- [Anything unresolved that might affect implementation]
|
|
110
|
+
|
|
111
|
+
## Relates To
|
|
112
|
+
- [Links to related memory files]
|
|
113
|
+
```
|
|
114
|
+
|
|
115
|
+
**`plan.md`** — The full implementation plan:
|
|
116
|
+
```
|
|
117
|
+
# [Task Name] — Implementation Plan
|
|
118
|
+
|
|
119
|
+
**Status:** active | **Updated:** [today's date]
|
|
120
|
+
|
|
121
|
+
## General Plan
|
|
122
|
+
[High-level approach from 2e]
|
|
123
|
+
|
|
124
|
+
## Detailed Plan
|
|
125
|
+
|
|
126
|
+
### Step 1: [Action]
|
|
127
|
+
- **Files:** `path/to/file`
|
|
128
|
+
- **Details:** [Specific implementation details]
|
|
129
|
+
- **Dependencies:** None
|
|
130
|
+
|
|
131
|
+
### Step 2: [Action]
|
|
132
|
+
- **Files:** `path/to/file`
|
|
133
|
+
- **Details:** [Specific implementation details]
|
|
134
|
+
- **Dependencies:** Step 1
|
|
135
|
+
|
|
136
|
+
[... more steps ...]
|
|
137
|
+
|
|
138
|
+
## Out of Scope
|
|
139
|
+
- [What this plan does NOT cover]
|
|
140
|
+
```
|
|
141
|
+
|
|
142
|
+
**`status.md`** — Progress checklist mirroring the plan:
|
|
143
|
+
```
|
|
144
|
+
# [Task Name] — Status
|
|
145
|
+
|
|
146
|
+
**Status:** active | **Updated:** [today's date]
|
|
147
|
+
|
|
148
|
+
## Progress
|
|
149
|
+
|
|
150
|
+
- [ ] Step 1: [description]
|
|
151
|
+
- [ ] Step 2: [description]
|
|
152
|
+
- [ ] Step 3: [description]
|
|
153
|
+
|
|
154
|
+
## Notes
|
|
155
|
+
<!-- Any blockers, deviations from plan, or important observations. -->
|
|
156
|
+
|
|
157
|
+
## Completed
|
|
158
|
+
**Completed:**
|
|
159
|
+
```
|
|
160
|
+
|
|
161
|
+
### 2g: Present the Plan
|
|
162
|
+
|
|
163
|
+
Print a summary to the user:
|
|
164
|
+
|
|
165
|
+
```
|
|
166
|
+
## Plan: [Task Name]
|
|
167
|
+
|
|
168
|
+
### Approach
|
|
169
|
+
[1-2 sentence summary of general plan]
|
|
170
|
+
|
|
171
|
+
### Steps ([N] total)
|
|
172
|
+
1. [Step 1 summary]
|
|
173
|
+
2. [Step 2 summary]
|
|
174
|
+
3. [Step 3 summary]
|
|
175
|
+
...
|
|
176
|
+
|
|
177
|
+
### Out of Scope
|
|
178
|
+
- [Item 1]
|
|
179
|
+
- [Item 2]
|
|
180
|
+
|
|
181
|
+
---
|
|
182
|
+
Plan saved to task-memory/[task-name]/
|
|
183
|
+
To start implementing: /mema.implement [task-name]
|
|
184
|
+
```
|
|
185
|
+
|
|
186
|
+
## Phase 3: AUTO-SAVE & CURATE
|
|
187
|
+
|
|
188
|
+
Follow the curation rules in `_memory-protocol.md`. For each piece of knowledge produced:
|
|
189
|
+
|
|
190
|
+
- **Decisions made** about approach → ADD to `project-memory/decisions/YYYY-MM-DD-short-name.md` (only if the plan includes a significant architectural or technical decision worth preserving beyond this task)
|
|
191
|
+
- **Architecture insights** discovered during exploration → UPDATE `project-memory/architecture.md` (only if you found something missing or incorrect)
|
|
192
|
+
- **Lessons learned** during planning → ADD/UPDATE `agent-memory/lessons.md`
|
|
193
|
+
- **Patterns discovered** during exploration → ADD/UPDATE `agent-memory/patterns.md`
|
|
194
|
+
|
|
195
|
+
Apply ADD/UPDATE/DELETE/NOOP to each memory file. Most files will be NOOP.
|
|
196
|
+
|
|
197
|
+
**Do NOT save the plan itself as a decision.** The plan lives in task-memory. Only save standalone decisions that have value beyond this specific task.
|
|
198
|
+
|
|
199
|
+
## Phase 4: AUTO-INDEX
|
|
200
|
+
|
|
201
|
+
Update `.mema/index.md`:
|
|
202
|
+
1. Re-read the current index
|
|
203
|
+
2. Add an entry under `## Active Tasks`: `- \`task-memory/[task-name]/\` — [one-line summary] (plan ready)`
|
|
204
|
+
3. Update summaries for any modified files (decisions, lessons, patterns)
|
|
205
|
+
4. Remove entries for any deleted files
|
|
206
|
+
5. Update the `**Updated:**` date
|
|
@@ -2,9 +2,9 @@
|
|
|
2
2
|
description: Recall project memory into the current session. Loads .mema/ knowledge (architecture, decisions, lessons, patterns) and prints a formatted summary. Use at the start of a session to restore context.
|
|
3
3
|
---
|
|
4
4
|
|
|
5
|
-
# /recall — Session Memory Recall
|
|
5
|
+
# /mema.recall — Session Memory Recall
|
|
6
6
|
|
|
7
|
-
You are executing the /recall skill. This is a **read-only** skill — it loads memory and prints a summary into the conversation. It never writes to any files.
|
|
7
|
+
You are executing the /mema.recall skill. This is a **read-only** skill — it loads memory and prints a summary into the conversation. It never writes to any files.
|
|
8
8
|
|
|
9
9
|
Follow these steps carefully.
|
|
10
10
|
|
|
@@ -23,7 +23,7 @@ If the user provides an unrecognized argument (not `minimal`, `full`, or empty):
|
|
|
23
23
|
|
|
24
24
|
1. Read `.mema/index.md`
|
|
25
25
|
2. If `index.md` is missing or `.mema/` does not exist:
|
|
26
|
-
- Tell the user: "No memory found. Run `/onboard` first to set up mema-kit for this project."
|
|
26
|
+
- Tell the user: "No memory found. Run `/mema.onboard` first to set up mema-kit for this project."
|
|
27
27
|
- **Stop here** — do not continue to further steps.
|
|
28
28
|
3. Parse the index to identify available memory files and their summaries.
|
|
29
29
|
|
|
@@ -85,7 +85,7 @@ Use the format below based on the current mode.
|
|
|
85
85
|
- Agent Lessons: [N] lessons, [N] patterns
|
|
86
86
|
|
|
87
87
|
---
|
|
88
|
-
*Showing minimal recall. Use `/recall full` for decisions, lessons, and patterns.*
|
|
88
|
+
*Showing minimal recall. Use `/mema.recall full` for decisions, lessons, and patterns.*
|
|
89
89
|
```
|
|
90
90
|
|
|
91
91
|
---
|
|
@@ -132,4 +132,4 @@ Use the format below based on the current mode.
|
|
|
132
132
|
|
|
133
133
|
---
|
|
134
134
|
|
|
135
|
-
**Important:** This skill is purely informational. If you notice memory files are missing or out of date, suggest the user run `/onboard` or the relevant skill — do not attempt to fix memory yourself.
|
|
135
|
+
**Important:** This skill is purely informational. If you notice memory files are missing or out of date, suggest the user run `/mema.onboard` or the relevant skill — do not attempt to fix memory yourself.
|