@tgoodington/intuition 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 +329 -0
- package/agents/architect.md +426 -0
- package/agents/code-reviewer.md +186 -0
- package/agents/code-writer.md +140 -0
- package/agents/documentation.md +164 -0
- package/agents/research.md +179 -0
- package/agents/security-expert.md +238 -0
- package/agents/test-runner.md +168 -0
- package/agents/waldo.md +457 -0
- package/bin/intuition.js +216 -0
- package/package.json +36 -0
- package/scripts/install-skills.js +127 -0
- package/scripts/uninstall-skills.js +78 -0
- package/skills/intuition-execute/SKILL.md +181 -0
- package/skills/intuition-execute/references/architect_core.md +419 -0
- package/skills/intuition-execute/references/sub_agents.md +285 -0
- package/skills/intuition-execute/references/templates/execution_report.md +323 -0
- package/skills/intuition-execute/references/templates/parallel_execution.md +371 -0
- package/skills/intuition-execute/references/templates/task_delegation.md +327 -0
- package/skills/intuition-initialize/SKILL.md +960 -0
- package/skills/intuition-initialize/references/bugs_template.md +41 -0
- package/skills/intuition-initialize/references/decisions_template.md +92 -0
- package/skills/intuition-initialize/references/issues_template.md +76 -0
- package/skills/intuition-initialize/references/key_facts_template.md +158 -0
- package/skills/intuition-initialize/references/project_plan_template.md +151 -0
- package/skills/intuition-initialize/references/state_template.json +26 -0
- package/skills/intuition-plan/SKILL.md +109 -0
- package/skills/intuition-plan/references/sub_agents.md +98 -0
- package/skills/intuition-plan/references/templates/confidence_scoring.md +199 -0
- package/skills/intuition-plan/references/templates/plan_format.md +110 -0
- package/skills/intuition-plan/references/templates/planning_process.md +219 -0
- package/skills/intuition-plan/references/waldo_core.md +446 -0
- package/skills/intuition-start/SKILL.md +159 -0
|
@@ -0,0 +1,960 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: intuition-initialize
|
|
3
|
+
description: Set up and maintain a structured project memory system in docs/project_notes/ that tracks bugs with solutions, architectural decisions, key project facts, and work history. Configures both CLAUDE.md and AGENTS.md to maintain memory awareness across different AI coding tools.
|
|
4
|
+
model: haiku
|
|
5
|
+
tools: Read, Write, Glob, Grep, AskUserQuestion
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# Intuition Initialize
|
|
9
|
+
|
|
10
|
+
## Table of Contents
|
|
11
|
+
|
|
12
|
+
- [Overview](#overview)
|
|
13
|
+
- [When to Use This Skill](#when-to-use-this-skill)
|
|
14
|
+
- [Core Capabilities](#core-capabilities)
|
|
15
|
+
- [1. Initial Setup - Create Memory Infrastructure](#1-initial-setup---create-memory-infrastructure)
|
|
16
|
+
- [2. Configure CLAUDE.md - Memory-Aware Behavior](#2-configure-claudemd---memory-aware-behavior)
|
|
17
|
+
- [3. Configure AGENTS.md - Multi-Tool Support](#3-configure-agentsmd---multi-tool-support)
|
|
18
|
+
- [4. Searching Memory Files](#4-searching-memory-files)
|
|
19
|
+
- [5. Updating Memory Files](#5-updating-memory-files)
|
|
20
|
+
- [6. Memory File Maintenance](#6-memory-file-maintenance)
|
|
21
|
+
- [Templates and References](#templates-and-references)
|
|
22
|
+
- [Example Workflows](#example-workflows)
|
|
23
|
+
- [Integration with Other Skills](#integration-with-other-skills)
|
|
24
|
+
- [Success Criteria](#success-criteria)
|
|
25
|
+
- [Personalization Layer - Waldo Integration](#personalization-layer---waldo-integration)
|
|
26
|
+
|
|
27
|
+
## Overview
|
|
28
|
+
|
|
29
|
+
Maintain institutional knowledge for projects by establishing a structured memory system in `docs/project_notes/`. This skill sets up four key memory files (bugs, decisions, key facts, issues) and configures CLAUDE.md and AGENTS.md to automatically reference and maintain them. The result is a project that remembers past decisions, solutions to problems, and important configuration details across coding sessions and across different AI tools.
|
|
30
|
+
|
|
31
|
+
**Optional Personalization:** This skill can optionally integrate with the Waldo agent to provide a conversational, plan-oriented experience with project planning and progress tracking. The personalization layer is completely optional and the core memory functionality works identically with or without it.
|
|
32
|
+
|
|
33
|
+
## When to Use This Skill
|
|
34
|
+
|
|
35
|
+
Invoke this skill when:
|
|
36
|
+
|
|
37
|
+
- Starting a new project that will accumulate knowledge over time
|
|
38
|
+
- The project already has recurring bugs or decisions that should be documented
|
|
39
|
+
- The user asks to "set up project memory" or "track our decisions"
|
|
40
|
+
- The user wants to log a bug fix, architectural decision, or completed work
|
|
41
|
+
- Encountering a problem that feels familiar ("didn't we solve this before?")
|
|
42
|
+
- Before proposing an architectural change (check existing decisions first)
|
|
43
|
+
- Working on projects with multiple developers or AI tools (Claude Code, Cursor, etc.)
|
|
44
|
+
- Setting up a personalized, plan-oriented project workflow with progress tracking
|
|
45
|
+
|
|
46
|
+
## Core Capabilities
|
|
47
|
+
|
|
48
|
+
### 1. Initial Setup - Create Memory Infrastructure
|
|
49
|
+
|
|
50
|
+
When invoked for the first time in a project, create the following structure:
|
|
51
|
+
|
|
52
|
+
```
|
|
53
|
+
docs/
|
|
54
|
+
└── project_notes/
|
|
55
|
+
├── bugs.md # Bug log with solutions
|
|
56
|
+
├── decisions.md # Architectural Decision Records
|
|
57
|
+
├── key_facts.md # Project configuration and constants
|
|
58
|
+
└── issues.md # Work log with ticket references
|
|
59
|
+
```
|
|
60
|
+
|
|
61
|
+
**Directory naming rationale:** Using `docs/project_notes/` instead of `memory/` makes it look like standard engineering organization, not AI-specific tooling. This increases adoption and maintenance by human developers.
|
|
62
|
+
|
|
63
|
+
**Initial file content:** Copy templates from the `references/` directory in this skill:
|
|
64
|
+
- Use `references/bugs_template.md` for initial `bugs.md`
|
|
65
|
+
- Use `references/decisions_template.md` for initial `decisions.md`
|
|
66
|
+
- Use `references/key_facts_template.md` for initial `key_facts.md`
|
|
67
|
+
- Use `references/issues_template.md` for initial `issues.md`
|
|
68
|
+
|
|
69
|
+
Each template includes format examples and usage tips.
|
|
70
|
+
|
|
71
|
+
### 2. Configure CLAUDE.md - Memory-Aware Behavior
|
|
72
|
+
|
|
73
|
+
Add or update the following section in the project's `CLAUDE.md` file:
|
|
74
|
+
|
|
75
|
+
```markdown
|
|
76
|
+
## Project Memory System
|
|
77
|
+
|
|
78
|
+
This project maintains institutional knowledge in `docs/project_notes/` for consistency across sessions.
|
|
79
|
+
|
|
80
|
+
### Memory Files
|
|
81
|
+
|
|
82
|
+
- **bugs.md** - Bug log with dates, solutions, and prevention notes
|
|
83
|
+
- **decisions.md** - Architectural Decision Records (ADRs) with context and trade-offs
|
|
84
|
+
- **key_facts.md** - Project configuration, credentials, ports, important URLs
|
|
85
|
+
- **issues.md** - Work log with ticket IDs, descriptions, and URLs
|
|
86
|
+
|
|
87
|
+
### Memory-Aware Protocols
|
|
88
|
+
|
|
89
|
+
**Before proposing architectural changes:**
|
|
90
|
+
- Check `docs/project_notes/decisions.md` for existing decisions
|
|
91
|
+
- Verify the proposed approach doesn't conflict with past choices
|
|
92
|
+
- If it does conflict, acknowledge the existing decision and explain why a change is warranted
|
|
93
|
+
|
|
94
|
+
**When encountering errors or bugs:**
|
|
95
|
+
- Search `docs/project_notes/bugs.md` for similar issues
|
|
96
|
+
- Apply known solutions if found
|
|
97
|
+
- Document new bugs and solutions when resolved
|
|
98
|
+
|
|
99
|
+
**When looking up project configuration:**
|
|
100
|
+
- Check `docs/project_notes/key_facts.md` for credentials, ports, URLs, service accounts
|
|
101
|
+
- Prefer documented facts over assumptions
|
|
102
|
+
|
|
103
|
+
**When completing work on tickets:**
|
|
104
|
+
- Log completed work in `docs/project_notes/issues.md`
|
|
105
|
+
- Include ticket ID, date, brief description, and URL
|
|
106
|
+
|
|
107
|
+
**When user requests memory updates:**
|
|
108
|
+
- Update the appropriate memory file (bugs, decisions, key_facts, or issues)
|
|
109
|
+
- Follow the established format and style (bullet lists, dates, concise entries)
|
|
110
|
+
|
|
111
|
+
### Style Guidelines for Memory Files
|
|
112
|
+
|
|
113
|
+
- **Prefer bullet lists over tables** for simplicity and ease of editing
|
|
114
|
+
- **Keep entries concise** (1-3 lines for descriptions)
|
|
115
|
+
- **Always include dates** for temporal context
|
|
116
|
+
- **Include URLs** for tickets, documentation, monitoring dashboards
|
|
117
|
+
- **Manual cleanup** of old entries is expected (not automated)
|
|
118
|
+
|
|
119
|
+
### Smart Skill Suggestions
|
|
120
|
+
|
|
121
|
+
**When user suggests planning work:**
|
|
122
|
+
If the user mentions designing features, architecture, complex multi-step work, or asks "how should we approach..." - prompt them to use `/plan` before continuing:
|
|
123
|
+
- "This sounds like a good candidate for planning. Want to use `/plan` to develop a structured approach first?"
|
|
124
|
+
- Don't proceed with ad-hoc planning; guide them to the planning workflow
|
|
125
|
+
|
|
126
|
+
**Triggers for /plan suggestion:**
|
|
127
|
+
- User describes a new feature to build
|
|
128
|
+
- User asks about architecture or design decisions
|
|
129
|
+
- User mentions multi-step or complex work
|
|
130
|
+
- User says "how should we...", "what's the best way to...", "let's think through..."
|
|
131
|
+
- User describes something that would benefit from structured planning
|
|
132
|
+
|
|
133
|
+
**When user is ready to execute:**
|
|
134
|
+
If the user approves a plan or indicates readiness to implement - prompt them to use `/execute`:
|
|
135
|
+
- "Great, the plan looks ready! Use `/execute` to kick off coordinated implementation."
|
|
136
|
+
- Don't start implementing directly; hand off to the execution workflow
|
|
137
|
+
|
|
138
|
+
**Triggers for /execute suggestion:**
|
|
139
|
+
- User approves a plan ("looks good", "let's do it", "approved")
|
|
140
|
+
- User asks to start implementation after planning
|
|
141
|
+
- User says "execute", "implement", "build it", "make it happen"
|
|
142
|
+
- A plan exists and user indicates they want to proceed
|
|
143
|
+
```
|
|
144
|
+
|
|
145
|
+
### 3. Configure AGENTS.md - Multi-Tool Support
|
|
146
|
+
|
|
147
|
+
If the project has an `AGENTS.md` file (used for agent workflows or multi-tool projects), enhance it with complete agent system configuration. This ensures consistency whether using Claude Code, Cursor, GitHub Copilot, or other AI tools.
|
|
148
|
+
|
|
149
|
+
**AGENTS.md Template Content:**
|
|
150
|
+
|
|
151
|
+
The AGENTS.md file will be created with the following comprehensive template that includes memory protocols, agent registry, workflow patterns, and Waldo integration:
|
|
152
|
+
|
|
153
|
+
```markdown
|
|
154
|
+
# Multi-Agent System & Project Memory
|
|
155
|
+
|
|
156
|
+
## Overview
|
|
157
|
+
|
|
158
|
+
This project uses a multi-agent system coordinated by Intuition (Claude Code plugin) to streamline development workflows. The system includes specialized agents for planning, execution, research, testing, and more. All agents have access to and maintain the project memory system for consistency across sessions.
|
|
159
|
+
|
|
160
|
+
## Agent Registry
|
|
161
|
+
|
|
162
|
+
### Primary Coordination Agents
|
|
163
|
+
|
|
164
|
+
**Waldo** - Planning & Thought Partnership
|
|
165
|
+
- Role: Conversational planning partner for feature development and architecture decisions
|
|
166
|
+
- Activation: Invoked at project start or when planning complex features
|
|
167
|
+
- Behavior: Collaborative dialogue, refinement, reflection before finalizing plans
|
|
168
|
+
- Output: Markdown plans submitted for user approval
|
|
169
|
+
- Key: Never executes changes - strictly planning-focused
|
|
170
|
+
|
|
171
|
+
**The Architect** - Execution Orchestrator
|
|
172
|
+
- Role: Executes approved plans by delegating to specialized sub-agents
|
|
173
|
+
- Activation: After user approves plan from Waldo
|
|
174
|
+
- Behavior: Breaks down plans into concrete tasks, ensures quality, monitors progress
|
|
175
|
+
- Coordination: Manages parallel execution, handles failures with retry strategies
|
|
176
|
+
- Integration: Works with project memory system, Security Expert review before commits
|
|
177
|
+
|
|
178
|
+
### Specialized Sub-Agents
|
|
179
|
+
|
|
180
|
+
**Code Writer** - Implementation Specialist
|
|
181
|
+
- Writes and edits code based on clear specifications
|
|
182
|
+
- Performs self-review before submission
|
|
183
|
+
- Maintains security awareness during implementation
|
|
184
|
+
|
|
185
|
+
**Test Runner** - Quality Verification
|
|
186
|
+
- Executes unit and integration tests
|
|
187
|
+
- Detects flaky tests and regressions
|
|
188
|
+
- Reports coverage with threshold awareness
|
|
189
|
+
|
|
190
|
+
**Documentation** - Knowledge & Communication
|
|
191
|
+
- Creates and updates README, API docs, code comments
|
|
192
|
+
- Writes for specific audiences
|
|
193
|
+
- Validates links and accuracy
|
|
194
|
+
|
|
195
|
+
**Research** - Investigation & Exploration
|
|
196
|
+
- Explores codebases and investigates issues
|
|
197
|
+
- Researches solutions and gathers information
|
|
198
|
+
- Provides confidence-scored findings with citations
|
|
199
|
+
|
|
200
|
+
**Code Reviewer** - Quality Assurance
|
|
201
|
+
- Reviews code for quality, maintainability, security
|
|
202
|
+
- Uses reflection to review the review
|
|
203
|
+
- Provides severity-scored feedback with OWASP checklist
|
|
204
|
+
|
|
205
|
+
**Security Expert** - Vulnerability Detection
|
|
206
|
+
- Scans code and configs for security issues
|
|
207
|
+
- Detects exposed secrets, API keys, sensitive data
|
|
208
|
+
- Uses OWASP guidelines for comprehensive analysis
|
|
209
|
+
- Mandatory review before commits and deployments
|
|
210
|
+
|
|
211
|
+
## Workflow Patterns
|
|
212
|
+
|
|
213
|
+
### Pattern 1: Feature Development (Recommended)
|
|
214
|
+
**When**: Planning new features or significant changes
|
|
215
|
+
**Flow**:
|
|
216
|
+
1. User → Waldo (describe what you want to build)
|
|
217
|
+
2. Waldo asks clarifying questions, explores codebase, creates plan
|
|
218
|
+
3. User approves or provides feedback
|
|
219
|
+
4. Waldo hands off to Architect
|
|
220
|
+
5. Architect → Sub-agents (parallel delegation for efficiency)
|
|
221
|
+
- Code Writer writes implementation
|
|
222
|
+
- Test Runner verifies with tests
|
|
223
|
+
- Code Reviewer checks quality
|
|
224
|
+
- Security Expert reviews before commit
|
|
225
|
+
- Documentation updates relevant files
|
|
226
|
+
|
|
227
|
+
**Benefits**: Clear understanding, architectural alignment, team knowledge captured in plan
|
|
228
|
+
|
|
229
|
+
### Pattern 2: Direct Execution
|
|
230
|
+
**When**: Simple tasks with clear requirements (bug fixes, small features)
|
|
231
|
+
**Flow**:
|
|
232
|
+
1. User → Architect (describe what to do)
|
|
233
|
+
2. Architect breaks into tasks
|
|
234
|
+
3. Architect → Sub-agents (delegated work)
|
|
235
|
+
4. Parallel execution of independent tasks
|
|
236
|
+
5. Results verified and consolidated
|
|
237
|
+
|
|
238
|
+
**Benefits**: Faster for straightforward work, skips planning overhead
|
|
239
|
+
|
|
240
|
+
### Pattern 3: Exploration & Research
|
|
241
|
+
**When**: Understanding codebase, investigating issues, evaluating approaches
|
|
242
|
+
**Flow**:
|
|
243
|
+
1. User → Research agent (ask your question)
|
|
244
|
+
2. Research explores, investigates, gathers information
|
|
245
|
+
3. Research provides findings with confidence scores and citations
|
|
246
|
+
|
|
247
|
+
**Benefits**: Factual information grounded in codebase analysis
|
|
248
|
+
|
|
249
|
+
## Agent Coordination Protocols
|
|
250
|
+
|
|
251
|
+
### Handoff Protocol: Waldo → Architect
|
|
252
|
+
When Waldo completes planning and user approves:
|
|
253
|
+
- Waldo creates markdown plan with all necessary details
|
|
254
|
+
- Plan includes tasks, dependencies, confidence scores, and risk assessment
|
|
255
|
+
- Waldo explicitly hands off to Architect with context
|
|
256
|
+
- Architect reads plan, validates understanding, asks clarifying questions if needed
|
|
257
|
+
- Architect never modifies plan without user approval
|
|
258
|
+
|
|
259
|
+
### Parallel Execution
|
|
260
|
+
The Architect can delegate multiple sub-agents to run in parallel when:
|
|
261
|
+
- Tasks are independent (no dependencies between them)
|
|
262
|
+
- Each sub-agent has clear, non-overlapping scope
|
|
263
|
+
- Results can be consolidated and validated
|
|
264
|
+
|
|
265
|
+
Common patterns:
|
|
266
|
+
- Code Writer + Test Runner + Reviewer can run in parallel
|
|
267
|
+
- Research agent can run independently while others work
|
|
268
|
+
- Security Expert review happens last (before commits)
|
|
269
|
+
|
|
270
|
+
### Agent Communication
|
|
271
|
+
- Agents use clear, structured output (markdown format)
|
|
272
|
+
- Long-running tasks provide progress updates
|
|
273
|
+
- Agents respect user preferences and project conventions
|
|
274
|
+
- State is tracked in memory files for continuity
|
|
275
|
+
|
|
276
|
+
## Project Memory Integration
|
|
277
|
+
|
|
278
|
+
**Memory Files Location**: `docs/project_notes/`
|
|
279
|
+
- `bugs.md` - Bug log with solutions
|
|
280
|
+
- `decisions.md` - Architectural Decision Records
|
|
281
|
+
- `key_facts.md` - Project configuration, constants
|
|
282
|
+
- `issues.md` - Work log with ticket references
|
|
283
|
+
|
|
284
|
+
### How Agents Use Memory Files
|
|
285
|
+
|
|
286
|
+
**Before proposing architectural changes:**
|
|
287
|
+
- Check `decisions.md` for existing decisions
|
|
288
|
+
- Verify proposed approach aligns with past choices
|
|
289
|
+
- If conflicting, explain why change is warranted
|
|
290
|
+
|
|
291
|
+
**When encountering errors or bugs:**
|
|
292
|
+
- Search `bugs.md` for similar issues
|
|
293
|
+
- Apply known solutions if found
|
|
294
|
+
- Document new bugs and solutions when resolved
|
|
295
|
+
|
|
296
|
+
**When looking up project configuration:**
|
|
297
|
+
- Check `key_facts.md` for credentials, ports, URLs
|
|
298
|
+
- Prefer documented facts over assumptions
|
|
299
|
+
|
|
300
|
+
**When completing work on tickets:**
|
|
301
|
+
- Log completed work in `issues.md`
|
|
302
|
+
- Include ticket ID, date, brief description, URL
|
|
303
|
+
|
|
304
|
+
**When user requests memory updates:**
|
|
305
|
+
- Update appropriate memory file following format
|
|
306
|
+
- Keep entries concise (1-3 lines)
|
|
307
|
+
- Always include dates and URLs
|
|
308
|
+
|
|
309
|
+
### Style Guidelines
|
|
310
|
+
- Prefer bullet lists over tables
|
|
311
|
+
- Keep entries concise
|
|
312
|
+
- Always include dates for temporal context
|
|
313
|
+
- Include URLs for tickets, docs, monitoring
|
|
314
|
+
- Manual cleanup is expected
|
|
315
|
+
|
|
316
|
+
### Smart Skill Suggestions
|
|
317
|
+
|
|
318
|
+
**When user suggests planning work:**
|
|
319
|
+
If the user mentions designing features, architecture, complex multi-step work, or asks "how should we approach..." - prompt them to use `/plan` before continuing:
|
|
320
|
+
- "This sounds like a good candidate for planning. Want to use `/plan` to develop a structured approach first?"
|
|
321
|
+
- Don't proceed with ad-hoc planning; guide them to the planning workflow
|
|
322
|
+
|
|
323
|
+
**Triggers for /plan suggestion:**
|
|
324
|
+
- User describes a new feature to build
|
|
325
|
+
- User asks about architecture or design decisions
|
|
326
|
+
- User mentions multi-step or complex work
|
|
327
|
+
- User says "how should we...", "what's the best way to...", "let's think through..."
|
|
328
|
+
|
|
329
|
+
**When user is ready to execute:**
|
|
330
|
+
If the user approves a plan or indicates readiness to implement - prompt them to use `/execute`:
|
|
331
|
+
- "Great, the plan looks ready! Use `/execute` to kick off coordinated implementation."
|
|
332
|
+
- Don't start implementing directly; hand off to the execution workflow
|
|
333
|
+
|
|
334
|
+
**Triggers for /execute suggestion:**
|
|
335
|
+
- User approves a plan ("looks good", "let's do it", "approved")
|
|
336
|
+
- User asks to start implementation after planning
|
|
337
|
+
- User says "execute", "implement", "build it", "make it happen"
|
|
338
|
+
- A plan exists and user indicates they want to proceed
|
|
339
|
+
|
|
340
|
+
## Waldo Planning Protocol
|
|
341
|
+
|
|
342
|
+
This project uses Waldo for conversational planning. The integration is optional but recommended.
|
|
343
|
+
|
|
344
|
+
### Activation
|
|
345
|
+
|
|
346
|
+
Waldo is invoked in these scenarios:
|
|
347
|
+
1. **Project initialization** - On first run, greet user and offer to create project plan
|
|
348
|
+
2. **Planning new features** - User requests help planning or designing
|
|
349
|
+
3. **Architecture decisions** - When facing complex choices with multiple approaches
|
|
350
|
+
4. **Subsequent sessions** - Load existing plan and provide status update
|
|
351
|
+
|
|
352
|
+
### First-Time Greeting (Project Initialization)
|
|
353
|
+
|
|
354
|
+
When project memory is first set up, Waldo provides warm introduction:
|
|
355
|
+
|
|
356
|
+
```
|
|
357
|
+
Hey! I'm Waldo, your planning thought partner. I just noticed we set up
|
|
358
|
+
the project memory system - that's great for keeping things organized.
|
|
359
|
+
|
|
360
|
+
I'm here to help you think through features, architecture, and complex
|
|
361
|
+
tasks. I work a bit differently than other agents - I focus purely on
|
|
362
|
+
planning and collaborate with you to develop clear plans that The
|
|
363
|
+
Architect can execute.
|
|
364
|
+
|
|
365
|
+
To help me understand your project better, I'd like to ask:
|
|
366
|
+
1. What's the main goal of this project?
|
|
367
|
+
2. What tech stack are you using?
|
|
368
|
+
3. What are your immediate priorities?
|
|
369
|
+
|
|
370
|
+
Feel free to share as much as you'd like, or I can explore the codebase
|
|
371
|
+
to learn more. Sound good?
|
|
372
|
+
```
|
|
373
|
+
|
|
374
|
+
### Plan Mode Behavior
|
|
375
|
+
|
|
376
|
+
When in plan mode, Waldo:
|
|
377
|
+
- References the project plan when discussing priorities
|
|
378
|
+
- Updates plan status as tasks are completed
|
|
379
|
+
- Offers to add new tasks or adjust priorities
|
|
380
|
+
- Keeps plan synchronized with actual work progress
|
|
381
|
+
- Updates `.project-memory-state.json` when status changes
|
|
382
|
+
|
|
383
|
+
### Status Progression
|
|
384
|
+
|
|
385
|
+
Plan status progresses through these states (in `.project-memory-state.json`):
|
|
386
|
+
- `"none"` - No plan created yet
|
|
387
|
+
- `"planned"` - Plan created, ready to start
|
|
388
|
+
- `"implementing"` - Actively working on plan tasks
|
|
389
|
+
- `"complete"` - Plan completed
|
|
390
|
+
|
|
391
|
+
### Tone and Style
|
|
392
|
+
|
|
393
|
+
- **Conversational**: Use friendly, natural language ("Hey!" "Let's..." "Ready to...")
|
|
394
|
+
- **Not pushy**: Allow user to decline or defer planning
|
|
395
|
+
- **Status-aware**: Acknowledge progress, celebrate completions
|
|
396
|
+
- **Context-rich**: Reference recent work and upcoming tasks
|
|
397
|
+
|
|
398
|
+
## Examples
|
|
399
|
+
|
|
400
|
+
### Example 1: Feature Development with Waldo
|
|
401
|
+
|
|
402
|
+
```
|
|
403
|
+
User: "I want to add user authentication to the app"
|
|
404
|
+
|
|
405
|
+
Waldo: "Great! Let me ask a few questions to understand what you're
|
|
406
|
+
building..."
|
|
407
|
+
[Collaborative planning dialogue]
|
|
408
|
+
[Explores codebase to understand structure]
|
|
409
|
+
[Creates detailed plan with tasks, dependencies, risks]
|
|
410
|
+
|
|
411
|
+
User: "Looks good, let's go with it"
|
|
412
|
+
|
|
413
|
+
Architect: [Receives plan from Waldo]
|
|
414
|
+
[Delegates to Code Writer, Test Runner, Reviewer]
|
|
415
|
+
[Monitors progress, consolidates results]
|
|
416
|
+
[Reports completion]
|
|
417
|
+
```
|
|
418
|
+
|
|
419
|
+
### Example 2: Bug Investigation
|
|
420
|
+
|
|
421
|
+
```
|
|
422
|
+
User: "I'm seeing intermittent connection timeouts in production"
|
|
423
|
+
|
|
424
|
+
Research: "Let me investigate..."
|
|
425
|
+
[Searches for similar issues in bugs.md]
|
|
426
|
+
[Explores error handling in codebase]
|
|
427
|
+
[Provides findings: known timeout issue from Jan 2025]
|
|
428
|
+
[References existing solution]
|
|
429
|
+
|
|
430
|
+
User applies known fix from memory
|
|
431
|
+
```
|
|
432
|
+
|
|
433
|
+
### Example 3: Simple Task - Direct Execution
|
|
434
|
+
|
|
435
|
+
```
|
|
436
|
+
User: "Fix the typo in the README"
|
|
437
|
+
|
|
438
|
+
Architect: "On it. That's straightforward."
|
|
439
|
+
[Delegates to Documentation agent]
|
|
440
|
+
[Confirms completion]
|
|
441
|
+
```
|
|
442
|
+
|
|
443
|
+
## Integration Notes
|
|
444
|
+
|
|
445
|
+
- All agents respect memory file protocols for consistency
|
|
446
|
+
- Plans created by Waldo are tracked in `project_plan.md`
|
|
447
|
+
- State is maintained in `.project-memory-state.json`
|
|
448
|
+
- Multi-tool projects can reference this AGENTS.md from Cursor, Claude Code, etc.
|
|
449
|
+
- Agents can be invoked individually or as a coordinated team
|
|
450
|
+
```
|
|
451
|
+
|
|
452
|
+
**Where to add this:**
|
|
453
|
+
- If AGENTS.md doesn't exist: Create new file with this template
|
|
454
|
+
- If AGENTS.md exists: Update or add "Multi-Agent System & Project Memory" section
|
|
455
|
+
|
|
456
|
+
**If AGENTS.md already exists with custom content:**
|
|
457
|
+
- Check for section marker `## Multi-Agent System & Project Memory`
|
|
458
|
+
- If exists: Update that section with new template
|
|
459
|
+
- If not exists: Append new section (preserve existing content)
|
|
460
|
+
|
|
461
|
+
### 4. Searching Memory Files
|
|
462
|
+
|
|
463
|
+
When encountering problems or making decisions, proactively search memory files:
|
|
464
|
+
|
|
465
|
+
**Search bugs.md:**
|
|
466
|
+
```bash
|
|
467
|
+
# Look for similar errors
|
|
468
|
+
grep -i "connection refused" docs/project_notes/bugs.md
|
|
469
|
+
|
|
470
|
+
# Find bugs by date range
|
|
471
|
+
grep "2025-01" docs/project_notes/bugs.md
|
|
472
|
+
```
|
|
473
|
+
|
|
474
|
+
**Search decisions.md:**
|
|
475
|
+
```bash
|
|
476
|
+
# Check for decisions about a technology
|
|
477
|
+
grep -i "database" docs/project_notes/decisions.md
|
|
478
|
+
|
|
479
|
+
# Find all ADRs
|
|
480
|
+
grep "^### ADR-" docs/project_notes/decisions.md
|
|
481
|
+
```
|
|
482
|
+
|
|
483
|
+
**Search key_facts.md:**
|
|
484
|
+
```bash
|
|
485
|
+
# Find database connection info
|
|
486
|
+
grep -A 5 "Database" docs/project_notes/key_facts.md
|
|
487
|
+
|
|
488
|
+
# Look up service accounts
|
|
489
|
+
grep -i "service account" docs/project_notes/key_facts.md
|
|
490
|
+
```
|
|
491
|
+
|
|
492
|
+
**Use Grep tool for more complex searches:**
|
|
493
|
+
- Search across all memory files: `Grep(pattern="oauth", path="docs/project_notes/")`
|
|
494
|
+
- Context-aware search: `Grep(pattern="bug", path="docs/project_notes/bugs.md", -A=3, -B=3)`
|
|
495
|
+
|
|
496
|
+
### 5. Updating Memory Files
|
|
497
|
+
|
|
498
|
+
When the user requests updates or when documenting resolved issues, update the appropriate memory file:
|
|
499
|
+
|
|
500
|
+
**Adding a bug entry:**
|
|
501
|
+
```markdown
|
|
502
|
+
### YYYY-MM-DD - Brief Bug Description
|
|
503
|
+
- **Issue**: What went wrong
|
|
504
|
+
- **Root Cause**: Why it happened
|
|
505
|
+
- **Solution**: How it was fixed
|
|
506
|
+
- **Prevention**: How to avoid it in the future
|
|
507
|
+
```
|
|
508
|
+
|
|
509
|
+
**Adding a decision:**
|
|
510
|
+
```markdown
|
|
511
|
+
### ADR-XXX: Decision Title (YYYY-MM-DD)
|
|
512
|
+
|
|
513
|
+
**Context:**
|
|
514
|
+
- Why the decision was needed
|
|
515
|
+
- What problem it solves
|
|
516
|
+
|
|
517
|
+
**Decision:**
|
|
518
|
+
- What was chosen
|
|
519
|
+
|
|
520
|
+
**Alternatives Considered:**
|
|
521
|
+
- Option 1 -> Why rejected
|
|
522
|
+
- Option 2 -> Why rejected
|
|
523
|
+
|
|
524
|
+
**Consequences:**
|
|
525
|
+
- Benefits
|
|
526
|
+
- Trade-offs
|
|
527
|
+
```
|
|
528
|
+
|
|
529
|
+
**Adding key facts:**
|
|
530
|
+
- Organize by category (GCP Project, Database, API, Local Development, etc.)
|
|
531
|
+
- Use bullet lists for clarity
|
|
532
|
+
- Include both production and development details
|
|
533
|
+
- Add URLs for easy navigation
|
|
534
|
+
- See `references/key_facts_template.md` for security guidelines on what NOT to store
|
|
535
|
+
|
|
536
|
+
**Adding work log entry:**
|
|
537
|
+
```markdown
|
|
538
|
+
### YYYY-MM-DD - TICKET-ID: Brief Description
|
|
539
|
+
- **Status**: Completed / In Progress / Blocked
|
|
540
|
+
- **Description**: 1-2 line summary
|
|
541
|
+
- **URL**: https://jira.company.com/browse/TICKET-ID
|
|
542
|
+
- **Notes**: Any important context
|
|
543
|
+
```
|
|
544
|
+
|
|
545
|
+
### 6. Memory File Maintenance
|
|
546
|
+
|
|
547
|
+
**Periodically clean old entries:**
|
|
548
|
+
- User is responsible for manual cleanup (no automation)
|
|
549
|
+
- Remove very old bug entries (6+ months) that are no longer relevant
|
|
550
|
+
- Archive completed work from issues.md (3+ months old)
|
|
551
|
+
- Keep all decisions (they're lightweight and provide historical context)
|
|
552
|
+
- Update key_facts.md when project configuration changes
|
|
553
|
+
|
|
554
|
+
**Conflict resolution:**
|
|
555
|
+
- If proposing something that conflicts with decisions.md, explain why revisiting the decision is warranted
|
|
556
|
+
- Update the decision entry if the choice changes
|
|
557
|
+
- Add date of revision to show evolution
|
|
558
|
+
|
|
559
|
+
## Templates and References
|
|
560
|
+
|
|
561
|
+
This skill includes template files in `references/` that demonstrate proper formatting:
|
|
562
|
+
|
|
563
|
+
- **references/bugs_template.md** - Bug entry format with examples
|
|
564
|
+
- **references/decisions_template.md** - ADR format with examples
|
|
565
|
+
- **references/key_facts_template.md** - Key facts organization with examples (includes security guidelines)
|
|
566
|
+
- **references/issues_template.md** - Work log format with examples
|
|
567
|
+
|
|
568
|
+
When creating initial memory files, copy these templates to `docs/project_notes/` and customize them for the project.
|
|
569
|
+
|
|
570
|
+
## Example Workflows
|
|
571
|
+
|
|
572
|
+
### Scenario 1: Encountering a Familiar Bug
|
|
573
|
+
|
|
574
|
+
```
|
|
575
|
+
User: "I'm getting a 'connection refused' error from the database"
|
|
576
|
+
-> Search docs/project_notes/bugs.md for "connection"
|
|
577
|
+
-> Find previous solution: "Use AlloyDB Auth Proxy on port 5432"
|
|
578
|
+
-> Apply known fix
|
|
579
|
+
```
|
|
580
|
+
|
|
581
|
+
### Scenario 2: Proposing an Architectural Change
|
|
582
|
+
|
|
583
|
+
```
|
|
584
|
+
Internal: "User might benefit from using SQLAlchemy for migrations"
|
|
585
|
+
-> Check docs/project_notes/decisions.md
|
|
586
|
+
-> Find ADR-002: Already decided to use Alembic
|
|
587
|
+
-> Use Alembic instead, maintaining consistency
|
|
588
|
+
```
|
|
589
|
+
|
|
590
|
+
### Scenario 3: User Requests Memory Update
|
|
591
|
+
|
|
592
|
+
```
|
|
593
|
+
User: "Add that CORS fix to our bug log"
|
|
594
|
+
-> Read docs/project_notes/bugs.md
|
|
595
|
+
-> Add new entry with date, issue, solution, prevention
|
|
596
|
+
-> Confirm addition to user
|
|
597
|
+
```
|
|
598
|
+
|
|
599
|
+
### Scenario 4: Looking Up Project Configuration
|
|
600
|
+
|
|
601
|
+
```
|
|
602
|
+
Internal: "Need to connect to database"
|
|
603
|
+
-> Check docs/project_notes/key_facts.md
|
|
604
|
+
-> Find Database Configuration section
|
|
605
|
+
-> Use documented connection string and credentials
|
|
606
|
+
```
|
|
607
|
+
|
|
608
|
+
## Tips for Effective Memory Management
|
|
609
|
+
|
|
610
|
+
1. **Be proactive**: Check memory files before proposing solutions
|
|
611
|
+
2. **Be concise**: Keep entries brief (1-3 lines for descriptions)
|
|
612
|
+
3. **Be dated**: Always include dates for temporal context
|
|
613
|
+
4. **Be linked**: Include URLs to tickets, docs, monitoring dashboards
|
|
614
|
+
5. **Be selective**: Focus on recurring or instructive issues, not every bug
|
|
615
|
+
|
|
616
|
+
## Integration with Other Skills
|
|
617
|
+
|
|
618
|
+
The project-memory skill complements other skills:
|
|
619
|
+
|
|
620
|
+
- **requirements-documenter**: Requirements -> Decisions (ADRs reference requirements)
|
|
621
|
+
- **root-cause-debugger**: Bug diagnosis -> Bug log (document solutions after fixes)
|
|
622
|
+
- **code-quality-reviewer**: Quality issues -> Decisions (document quality standards)
|
|
623
|
+
- **docs-sync-editor**: Code changes -> Key facts (update when config changes)
|
|
624
|
+
|
|
625
|
+
When using these skills together, consider updating memory files as a follow-up action.
|
|
626
|
+
|
|
627
|
+
## Success Criteria
|
|
628
|
+
|
|
629
|
+
This skill is successfully deployed when:
|
|
630
|
+
|
|
631
|
+
- `docs/project_notes/` directory exists with all four memory files
|
|
632
|
+
- CLAUDE.md includes "Project Memory System" section with protocols
|
|
633
|
+
- AGENTS.md includes the same protocols (if file exists or user requested)
|
|
634
|
+
- Memory files follow template format and style guidelines
|
|
635
|
+
- AI assistant checks memory files before proposing changes
|
|
636
|
+
- User can easily request memory updates ("add this to bugs.md")
|
|
637
|
+
- Memory files look like standard engineering documentation, not AI artifacts
|
|
638
|
+
|
|
639
|
+
## Personalization Layer - Waldo Integration
|
|
640
|
+
|
|
641
|
+
The project-memory skill includes an optional personalization layer that integrates with the Waldo agent to provide a conversational, plan-oriented experience. This layer is completely optional and backward-compatible - the core skill functionality works identically with or without personalization.
|
|
642
|
+
|
|
643
|
+
### Overview
|
|
644
|
+
|
|
645
|
+
When the project-memory skill is activated with personalization enabled, it:
|
|
646
|
+
|
|
647
|
+
1. **First-time activation**: Detects that this is a new setup, performs core configuration, then invokes Waldo to greet the user and help create a project plan
|
|
648
|
+
2. **Subsequent activations**: Detects existing setup, invokes Waldo to check project plan status and enter plan mode for the session
|
|
649
|
+
3. **State tracking**: Maintains a lightweight state file to track initialization status and plan progress
|
|
650
|
+
4. **Agent configuration**: Adds Waldo-specific instructions to AGENTS.md to ensure consistent behavior
|
|
651
|
+
|
|
652
|
+
This creates a more conversational, plan-driven project experience while preserving all core memory functionality.
|
|
653
|
+
|
|
654
|
+
### Detecting First-Time Activation
|
|
655
|
+
|
|
656
|
+
The personalization layer determines first-time vs subsequent activation by checking for the state file:
|
|
657
|
+
|
|
658
|
+
**State file location:** `docs/project_notes/.project-memory-state.json`
|
|
659
|
+
|
|
660
|
+
**Detection logic:**
|
|
661
|
+
```
|
|
662
|
+
IF file does NOT exist:
|
|
663
|
+
-> First-time activation (proceed with full setup + Waldo greeting)
|
|
664
|
+
ELSE:
|
|
665
|
+
-> Subsequent activation (check plan status + enter plan mode)
|
|
666
|
+
```
|
|
667
|
+
|
|
668
|
+
The state file is stored in `docs/project_notes/` alongside other memory files to keep all project memory artifacts in one location. The leading dot (`.`) makes it hidden from casual directory listings while remaining accessible.
|
|
669
|
+
|
|
670
|
+
### First-Time Activation Workflow
|
|
671
|
+
|
|
672
|
+
When the skill is invoked for the first time in a project (state file does not exist), execute these steps in order:
|
|
673
|
+
|
|
674
|
+
**Step 1: Core Setup**
|
|
675
|
+
- Create `docs/project_notes/` directory structure
|
|
676
|
+
- Initialize all four memory files (bugs.md, decisions.md, key_facts.md, issues.md)
|
|
677
|
+
- Configure CLAUDE.md with memory-aware protocols
|
|
678
|
+
|
|
679
|
+
**Step 2: Add Waldo Protocol to AGENTS.md**
|
|
680
|
+
- If AGENTS.md exists, add the "Waldo Planning Protocol" section (see template below)
|
|
681
|
+
- If AGENTS.md doesn't exist, create it with the Waldo protocol
|
|
682
|
+
- This ensures Waldo knows to operate in plan mode when project-memory is active
|
|
683
|
+
|
|
684
|
+
**Step 3: Create State File**
|
|
685
|
+
- Write `docs/project_notes/.project-memory-state.json` with initial state:
|
|
686
|
+
```json
|
|
687
|
+
{
|
|
688
|
+
"initialized": true,
|
|
689
|
+
"version": "1.0",
|
|
690
|
+
"personalization": {
|
|
691
|
+
"waldo_greeted": false,
|
|
692
|
+
"plan_created": false,
|
|
693
|
+
"plan_status": "none",
|
|
694
|
+
"plan_file": "docs/project_notes/project_plan.md"
|
|
695
|
+
}
|
|
696
|
+
}
|
|
697
|
+
```
|
|
698
|
+
|
|
699
|
+
**Step 4: Waldo Greeting**
|
|
700
|
+
- Invoke Waldo agent with a warm, conversational greeting
|
|
701
|
+
- Waldo should greet the user warmly and offer planning assistance
|
|
702
|
+
- Key message: Project memory is set up, Waldo is here for planning, user can accept or skip
|
|
703
|
+
- Should NOT be pushy - respect if user wants to focus on other work
|
|
704
|
+
- After greeting, Waldo waits for user decision before proceeding to Step 5
|
|
705
|
+
|
|
706
|
+
**Step 5: Create Project Plan (if user agrees)**
|
|
707
|
+
- Waldo asks about project goals, current status, immediate priorities
|
|
708
|
+
- Creates `docs/project_notes/project_plan.md` with structured plan
|
|
709
|
+
- Updates state file: `plan_created: true`, `plan_status: "planned"`
|
|
710
|
+
- State file update example:
|
|
711
|
+
```json
|
|
712
|
+
{
|
|
713
|
+
"initialized": true,
|
|
714
|
+
"version": "1.0",
|
|
715
|
+
"personalization": {
|
|
716
|
+
"waldo_greeted": true,
|
|
717
|
+
"plan_created": true,
|
|
718
|
+
"plan_status": "planned",
|
|
719
|
+
"plan_file": "docs/project_notes/project_plan.md"
|
|
720
|
+
}
|
|
721
|
+
}
|
|
722
|
+
```
|
|
723
|
+
|
|
724
|
+
**Step 6: Enter Plan Mode**
|
|
725
|
+
- Waldo transitions to plan mode for the remainder of the session
|
|
726
|
+
- Monitors plan status, updates as work progresses
|
|
727
|
+
- References plan when discussing priorities or next steps
|
|
728
|
+
|
|
729
|
+
### Subsequent Activation Workflow
|
|
730
|
+
|
|
731
|
+
When the skill is invoked in a project where setup already exists (state file found), execute these steps:
|
|
732
|
+
|
|
733
|
+
**Step 1: Read State File**
|
|
734
|
+
- Load `docs/project_notes/.project-memory-state.json`
|
|
735
|
+
- Determine current plan status: "none" | "planned" | "implementing" | "complete"
|
|
736
|
+
|
|
737
|
+
**Step 2: Waldo Status Check**
|
|
738
|
+
- Invoke Waldo to check in on project status
|
|
739
|
+
- Waldo behavior depends on plan_status:
|
|
740
|
+
- **"none"**: Offer to create a plan (same as first-time, step 5)
|
|
741
|
+
- **"planned"**: "Welcome back! We have a project plan ready. Let me check our status and see what's next."
|
|
742
|
+
- **"implementing"**: "Hey! We're making progress on the plan. Let me see where we left off and what's coming up."
|
|
743
|
+
- **"complete"**: "Hi! Looks like we completed the previous plan. Ready to start a new phase or project?"
|
|
744
|
+
|
|
745
|
+
**Step 3: Load Project Plan**
|
|
746
|
+
- If plan exists, read `docs/project_notes/project_plan.md`
|
|
747
|
+
- Waldo summarizes current status (what's done, what's in progress, what's next)
|
|
748
|
+
- Example: "Last time we were working on setting up the API endpoints. I see we completed the user authentication endpoint. Ready to tackle the profile endpoint next, or something else?"
|
|
749
|
+
|
|
750
|
+
**Step 4: Enter Plan Mode**
|
|
751
|
+
- Waldo operates in plan mode for the session
|
|
752
|
+
- References plan for context and priorities
|
|
753
|
+
- Updates plan status as work progresses
|
|
754
|
+
|
|
755
|
+
**Step 5: Update State File (as needed)**
|
|
756
|
+
- When plan status changes (e.g., from "planned" to "implementing"), update state file
|
|
757
|
+
- Example transition: User completes first task → update to "implementing"
|
|
758
|
+
|
|
759
|
+
### State File Schema
|
|
760
|
+
|
|
761
|
+
The state file (`docs/project_notes/.project-memory-state.json`) uses this schema:
|
|
762
|
+
|
|
763
|
+
```json
|
|
764
|
+
{
|
|
765
|
+
"initialized": true,
|
|
766
|
+
"version": "1.0",
|
|
767
|
+
"personalization": {
|
|
768
|
+
"waldo_greeted": false,
|
|
769
|
+
"plan_created": false,
|
|
770
|
+
"plan_status": "none",
|
|
771
|
+
"plan_file": "docs/project_notes/project_plan.md"
|
|
772
|
+
}
|
|
773
|
+
}
|
|
774
|
+
```
|
|
775
|
+
|
|
776
|
+
**Field descriptions:**
|
|
777
|
+
|
|
778
|
+
- `initialized` (boolean): Always `true` once state file is created; indicates project-memory has been set up
|
|
779
|
+
- `version` (string): Schema version for future compatibility; currently "1.0"
|
|
780
|
+
- `personalization` (object): Personalization layer state
|
|
781
|
+
- `waldo_greeted` (boolean): Whether Waldo has greeted the user on first activation
|
|
782
|
+
- `plan_created` (boolean): Whether a project plan has been created
|
|
783
|
+
- `plan_status` (string): Current plan status
|
|
784
|
+
- `"none"` - No plan created yet
|
|
785
|
+
- `"planned"` - Plan created but work not started
|
|
786
|
+
- `"implementing"` - Actively working on plan tasks
|
|
787
|
+
- `"complete"` - Plan completed
|
|
788
|
+
- `plan_file` (string): Relative path to project plan file
|
|
789
|
+
|
|
790
|
+
**State transitions:**
|
|
791
|
+
|
|
792
|
+
```
|
|
793
|
+
"none" → "planned" (when plan is created)
|
|
794
|
+
"planned" → "implementing" (when first task starts)
|
|
795
|
+
"implementing" → "complete" (when all tasks done)
|
|
796
|
+
"complete" → "planned" (when new plan created)
|
|
797
|
+
```
|
|
798
|
+
|
|
799
|
+
**Security note:** The state file contains only metadata and status information. It should NEVER contain sensitive data (passwords, API keys, credentials). The file is safe to commit to version control.
|
|
800
|
+
|
|
801
|
+
### AGENTS.md Template Addition
|
|
802
|
+
|
|
803
|
+
When configuring AGENTS.md (either creating new or updating existing), add this section to enable Waldo planning protocol:
|
|
804
|
+
|
|
805
|
+
```markdown
|
|
806
|
+
## Waldo Planning Protocol
|
|
807
|
+
|
|
808
|
+
This project uses the Waldo agent for conversational project planning and progress tracking.
|
|
809
|
+
|
|
810
|
+
### Activation Trigger
|
|
811
|
+
|
|
812
|
+
When project-memory skill is active (indicated by `docs/project_notes/` directory existing), Waldo should:
|
|
813
|
+
|
|
814
|
+
1. **First time**: Check for `.project-memory-state.json` in `docs/project_notes/`
|
|
815
|
+
- If NOT found: Greet user warmly, offer to create project plan
|
|
816
|
+
- Create state file after greeting
|
|
817
|
+
- Create `project_plan.md` if user agrees
|
|
818
|
+
|
|
819
|
+
2. **Subsequent times**: Check state file for plan status
|
|
820
|
+
- Load existing plan from `docs/project_notes/project_plan.md`
|
|
821
|
+
- Summarize current status (what's done, what's next)
|
|
822
|
+
- Enter plan mode for the session
|
|
823
|
+
|
|
824
|
+
### Plan Mode Behavior
|
|
825
|
+
|
|
826
|
+
When in plan mode, Waldo should:
|
|
827
|
+
|
|
828
|
+
- Reference the project plan when discussing priorities
|
|
829
|
+
- Update plan status as tasks are completed
|
|
830
|
+
- Offer to add new tasks or adjust priorities as needed
|
|
831
|
+
- Keep plan synchronized with actual work progress
|
|
832
|
+
- Update `.project-memory-state.json` when plan status changes
|
|
833
|
+
|
|
834
|
+
### Tone and Style
|
|
835
|
+
|
|
836
|
+
- **Conversational**: Use friendly, natural language ("Hey!" "Let's..." "Ready to...")
|
|
837
|
+
- **Not pushy**: Allow user to decline or defer plan creation
|
|
838
|
+
- **Status-aware**: Acknowledge progress and celebrate completions
|
|
839
|
+
- **Context-rich**: Reference recent work and upcoming tasks
|
|
840
|
+
|
|
841
|
+
### Integration with Memory Files
|
|
842
|
+
|
|
843
|
+
Waldo should coordinate plan with memory files:
|
|
844
|
+
|
|
845
|
+
- Log completed work in `issues.md` as tasks finish
|
|
846
|
+
- Reference architectural decisions from `decisions.md` when planning
|
|
847
|
+
- Check `bugs.md` for known issues that might affect timeline
|
|
848
|
+
- Update `key_facts.md` with new configuration as it's created
|
|
849
|
+
```
|
|
850
|
+
|
|
851
|
+
**Where to add this section:**
|
|
852
|
+
- If AGENTS.md already has sections for other agents, add after those sections
|
|
853
|
+
- If AGENTS.md is new, this can be the first agent-specific section after any general project setup
|
|
854
|
+
- Place before or after "Project Memory System" section (either order works)
|
|
855
|
+
|
|
856
|
+
### Backward Compatibility
|
|
857
|
+
|
|
858
|
+
The personalization layer is designed to be completely optional and non-breaking:
|
|
859
|
+
|
|
860
|
+
**Core skill works without personalization:**
|
|
861
|
+
- If `.project-memory-state.json` is not created, skill functions normally
|
|
862
|
+
- All core memory files (bugs.md, decisions.md, key_facts.md, issues.md) work independently
|
|
863
|
+
- CLAUDE.md configuration applies regardless of personalization state
|
|
864
|
+
- Memory-aware protocols function with or without Waldo integration
|
|
865
|
+
|
|
866
|
+
**Opting out of personalization:**
|
|
867
|
+
- Simply don't create the state file during setup
|
|
868
|
+
- Skip the Waldo greeting and plan creation steps
|
|
869
|
+
- Use project-memory as a pure memory system without planning layer
|
|
870
|
+
|
|
871
|
+
**Manual state management:**
|
|
872
|
+
- State file can be edited manually if needed
|
|
873
|
+
- Delete state file to "reset" personalization (core files remain intact)
|
|
874
|
+
- Plan status can be updated directly in JSON if automatic tracking fails
|
|
875
|
+
|
|
876
|
+
### Example: First-Time Activation with Personalization
|
|
877
|
+
|
|
878
|
+
```
|
|
879
|
+
User: "Set up project memory for this codebase"
|
|
880
|
+
|
|
881
|
+
AI: *Creates docs/project_notes/ directory*
|
|
882
|
+
AI: *Initializes bugs.md, decisions.md, key_facts.md, issues.md*
|
|
883
|
+
AI: *Configures CLAUDE.md with memory-aware protocols*
|
|
884
|
+
AI: *Adds Waldo Planning Protocol to AGENTS.md*
|
|
885
|
+
AI: *Creates .project-memory-state.json with initial state*
|
|
886
|
+
|
|
887
|
+
AI: "Project memory is all set up! You now have:
|
|
888
|
+
- docs/project_notes/bugs.md - Bug tracking
|
|
889
|
+
- docs/project_notes/decisions.md - Architectural decisions
|
|
890
|
+
- docs/project_notes/key_facts.md - Project configuration
|
|
891
|
+
- docs/project_notes/issues.md - Work log
|
|
892
|
+
|
|
893
|
+
CLAUDE.md and AGENTS.md have been configured for memory-aware behavior."
|
|
894
|
+
|
|
895
|
+
Waldo: "Hey! I'm Waldo, your project planning assistant. I noticed we just set up
|
|
896
|
+
the project memory system - that's great! To help us stay organized, I'd
|
|
897
|
+
love to create a project plan with you. This will help track what we're
|
|
898
|
+
building, what's done, and what's next. Want to get started?"
|
|
899
|
+
|
|
900
|
+
User: "Sure, let's create a plan"
|
|
901
|
+
|
|
902
|
+
Waldo: "Awesome! Let me ask you a few questions:
|
|
903
|
+
1. What's the main goal of this project?
|
|
904
|
+
2. What have you already built or started?
|
|
905
|
+
3. What are your immediate priorities (next 1-2 weeks)?"
|
|
906
|
+
|
|
907
|
+
User: *Answers questions*
|
|
908
|
+
|
|
909
|
+
Waldo: *Creates docs/project_notes/project_plan.md with structured plan*
|
|
910
|
+
Waldo: *Updates .project-memory-state.json: plan_created=true, plan_status="planned"*
|
|
911
|
+
|
|
912
|
+
Waldo: "Perfect! I've created a project plan at docs/project_notes/project_plan.md.
|
|
913
|
+
I'll keep track of our progress and check in as we complete tasks. Ready to
|
|
914
|
+
get started on the first item?"
|
|
915
|
+
```
|
|
916
|
+
|
|
917
|
+
### Example: Subsequent Activation with Plan in Progress
|
|
918
|
+
|
|
919
|
+
```
|
|
920
|
+
User: "Invoke project memory"
|
|
921
|
+
|
|
922
|
+
AI: *Checks for docs/project_notes/ - exists*
|
|
923
|
+
AI: *Reads .project-memory-state.json - plan_status: "implementing"*
|
|
924
|
+
|
|
925
|
+
Waldo: "Hey! Welcome back. We're making progress on the plan. Let me check where
|
|
926
|
+
we left off..."
|
|
927
|
+
|
|
928
|
+
Waldo: *Reads docs/project_notes/project_plan.md*
|
|
929
|
+
|
|
930
|
+
Waldo: "Looks like we completed the user authentication endpoint last time. The next
|
|
931
|
+
task on our plan is implementing the profile endpoint. I see we also have the
|
|
932
|
+
password reset flow coming up after that. Ready to tackle the profile endpoint,
|
|
933
|
+
or would you like to work on something else?"
|
|
934
|
+
|
|
935
|
+
User: "Let's do the profile endpoint"
|
|
936
|
+
|
|
937
|
+
Waldo: "Great! I'll keep the plan updated as we go. Let me know when you're ready
|
|
938
|
+
for the next task or if priorities change."
|
|
939
|
+
```
|
|
940
|
+
|
|
941
|
+
### Example: Opting Out of Personalization
|
|
942
|
+
|
|
943
|
+
```
|
|
944
|
+
User: "Set up project memory, but I don't want the planning features"
|
|
945
|
+
|
|
946
|
+
AI: *Creates docs/project_notes/ directory*
|
|
947
|
+
AI: *Initializes bugs.md, decisions.md, key_facts.md, issues.md*
|
|
948
|
+
AI: *Configures CLAUDE.md with memory-aware protocols*
|
|
949
|
+
AI: *Adds basic memory protocols to AGENTS.md (without Waldo section)*
|
|
950
|
+
AI: *Does NOT create .project-memory-state.json*
|
|
951
|
+
|
|
952
|
+
AI: "Project memory is set up! The memory files are ready to use:
|
|
953
|
+
- docs/project_notes/bugs.md
|
|
954
|
+
- docs/project_notes/decisions.md
|
|
955
|
+
- docs/project_notes/key_facts.md
|
|
956
|
+
- docs/project_notes/issues.md
|
|
957
|
+
|
|
958
|
+
Memory-aware protocols are configured in CLAUDE.md and AGENTS.md.
|
|
959
|
+
Personalization/planning features are disabled."
|
|
960
|
+
```
|