sublation-os 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/.claude/agents/sublation-os/implementation-verifier.md +141 -0
- package/.claude/agents/sublation-os/implementer-v2.md +542 -0
- package/.claude/agents/sublation-os/implementer.md +53 -0
- package/.claude/agents/sublation-os/product-planner.md +210 -0
- package/.claude/agents/sublation-os/spec-initializer.md +92 -0
- package/.claude/agents/sublation-os/spec-shaper.md +300 -0
- package/.claude/agents/sublation-os/spec-writer.md +139 -0
- package/.claude/agents/sublation-os/tasks-list-creator.md +236 -0
- package/.claude/commands/sublation-os/address-comments.md +74 -0
- package/.claude/commands/sublation-os/commit-message.md +84 -0
- package/.claude/commands/sublation-os/create-tasks.md +40 -0
- package/.claude/commands/sublation-os/implement-tasks.md +55 -0
- package/.claude/commands/sublation-os/investigate.md +164 -0
- package/.claude/commands/sublation-os/learn.md +131 -0
- package/.claude/commands/sublation-os/optimise.md +108 -0
- package/.claude/commands/sublation-os/plan-product.md +36 -0
- package/.claude/commands/sublation-os/pr-description.md +15 -0
- package/.claude/commands/sublation-os/recall.md +114 -0
- package/.claude/commands/sublation-os/review-v2.md +701 -0
- package/.claude/commands/sublation-os/review.md +12 -0
- package/.claude/commands/sublation-os/shape-spec.md +52 -0
- package/.claude/commands/sublation-os/test-plan.md +12 -0
- package/.claude/commands/sublation-os/write-spec.md +22 -0
- package/.sublation-os/config.yml +13 -0
- package/.sublation-os/memory/MEMORY_GUIDE.md +344 -0
- package/.sublation-os/memory/architecture-lessons.md +41 -0
- package/.sublation-os/memory/backend-lessons.md +41 -0
- package/.sublation-os/memory/frontend-lessons.md +41 -0
- package/.sublation-os/memory/general-lessons.md +41 -0
- package/.sublation-os/memory/index.md +94 -0
- package/.sublation-os/memory/learned-lessons.md +75 -0
- package/.sublation-os/memory/testing-lessons.md +41 -0
- package/.sublation-os/specs/.gitkeep +0 -0
- package/.sublation-os/standards/backend/api.md +10 -0
- package/.sublation-os/standards/backend/migrations.md +9 -0
- package/.sublation-os/standards/backend/models.md +10 -0
- package/.sublation-os/standards/backend/queries.md +9 -0
- package/.sublation-os/standards/frontend/accessibility.md +10 -0
- package/.sublation-os/standards/frontend/components.md +11 -0
- package/.sublation-os/standards/frontend/css.md +7 -0
- package/.sublation-os/standards/frontend/responsive.md +11 -0
- package/.sublation-os/standards/global/coding-style.md +10 -0
- package/.sublation-os/standards/global/commenting.md +5 -0
- package/.sublation-os/standards/global/conventions.md +11 -0
- package/.sublation-os/standards/global/error-handling.md +9 -0
- package/.sublation-os/standards/global/tech-stack.md +31 -0
- package/.sublation-os/standards/global/validation.md +11 -0
- package/.sublation-os/standards/testing/test-writing.md +9 -0
- package/LICENSE +21 -0
- package/README.md +155 -0
- package/bin/install.js +137 -0
- package/package.json +43 -0
|
@@ -0,0 +1,52 @@
|
|
|
1
|
+
# Spec Shaping Process
|
|
2
|
+
|
|
3
|
+
You are helping me shape and plan the scope for a new feature. The following process is aimed at documenting our key decisions regarding scope, design and architecture approach. We will use our findings from this process later when we write the formal spec document (but we are NOT writing the formal spec yet).
|
|
4
|
+
|
|
5
|
+
This process will follow 3 main phases, each with their own workflow steps:
|
|
6
|
+
|
|
7
|
+
Process overview (details to follow)
|
|
8
|
+
|
|
9
|
+
PHASE 1. Initilize spec
|
|
10
|
+
PHASE 2. Research requirements for this spec
|
|
11
|
+
PHASE 3. Inform the user that the spec has been initialized
|
|
12
|
+
|
|
13
|
+
Follow each of these phases and their individual workflows IN SEQUENCE:
|
|
14
|
+
|
|
15
|
+
## Multi-Phase Process:
|
|
16
|
+
|
|
17
|
+
### PHASE 1: Initialize Spec
|
|
18
|
+
|
|
19
|
+
Use the **spec-shaper** subagent to initialize a new spec.
|
|
20
|
+
|
|
21
|
+
IF the user has provided a description, provide that to the spec-initializer.
|
|
22
|
+
|
|
23
|
+
The spec-initializer will provide the path to the dated spec folder (YYYY-MM-DD-spec-name) they've created.
|
|
24
|
+
|
|
25
|
+
### PHASE 2: Research Requirements
|
|
26
|
+
|
|
27
|
+
After spec-initializer completes, immediately use the **spec-shaper** subagent:
|
|
28
|
+
|
|
29
|
+
Provide the spec-shaper with:
|
|
30
|
+
- The spec folder path from spec-initializer
|
|
31
|
+
|
|
32
|
+
The spec-shaper will give you several separate responses that you MUST show to the user. These include:
|
|
33
|
+
1. Numbered clarifying questions along with a request for visual assets (show these to user, wait for user's response)
|
|
34
|
+
2. Follow-up questions if needed (based on user's answers and provided visuals)
|
|
35
|
+
|
|
36
|
+
**IMPORTANT**:
|
|
37
|
+
- Display these questions to the user and wait for their response
|
|
38
|
+
- The spec-shaper may ask you to relay follow-up questions that you must present to user
|
|
39
|
+
|
|
40
|
+
### PHASE 3: Inform the user
|
|
41
|
+
|
|
42
|
+
After all steps complete, inform the user:
|
|
43
|
+
|
|
44
|
+
```
|
|
45
|
+
Spec shaping is complete!
|
|
46
|
+
|
|
47
|
+
✅ Spec folder created: `[spec-path]`
|
|
48
|
+
✅ Requirements gathered
|
|
49
|
+
✅ Visual assets: [Found X files / No files provided]
|
|
50
|
+
|
|
51
|
+
NEXT STEP 👉 Run `/write-spec` to generate the detailed specification document.
|
|
52
|
+
```
|
|
@@ -0,0 +1,22 @@
|
|
|
1
|
+
# Spec Writing Process
|
|
2
|
+
|
|
3
|
+
You are creating a comprehensive specification for a new feature.
|
|
4
|
+
|
|
5
|
+
Use the **spec-writer** subagent to create the specification document for this spec:
|
|
6
|
+
|
|
7
|
+
Provide the spec-writer with:
|
|
8
|
+
- The spec folder path (find the current one or the most recent in `.sublation-os/specs/*/`)
|
|
9
|
+
- The requirements from `planning/requirements.md`
|
|
10
|
+
- Any visual assets in `planning/visuals/`
|
|
11
|
+
|
|
12
|
+
The spec-writer will create `spec.md` inside the spec folder.
|
|
13
|
+
|
|
14
|
+
Once the spec-writer has created `spec.md` output the following to inform the user:
|
|
15
|
+
|
|
16
|
+
```
|
|
17
|
+
Your spec.md is ready!
|
|
18
|
+
|
|
19
|
+
✅ Spec document created: `[spec-path]`
|
|
20
|
+
|
|
21
|
+
NEXT STEP 👉 Run `/create-tasks` to generate your tasks list for this spec.
|
|
22
|
+
```
|
|
@@ -0,0 +1,13 @@
|
|
|
1
|
+
version: 2.1.0
|
|
2
|
+
last_compiled: 2025-11-03 20:31:17
|
|
3
|
+
|
|
4
|
+
# ================================================
|
|
5
|
+
# Compiled with the following settings:
|
|
6
|
+
#
|
|
7
|
+
# To change these settings, run ~/sublation-os/scripts/project-update.sh to re-compile your project with the new settings.
|
|
8
|
+
# ================================================
|
|
9
|
+
profile: default
|
|
10
|
+
claude_code_commands: true
|
|
11
|
+
use_claude_code_subagents: true
|
|
12
|
+
sublation_os_commands: false
|
|
13
|
+
standards_as_claude_code_skills: false
|
|
@@ -0,0 +1,344 @@
|
|
|
1
|
+
# Memory System Guide
|
|
2
|
+
|
|
3
|
+
Welcome to the Sublation-OS memory system! This guide explains how to effectively use the learning and memory features to build up institutional knowledge across AI-assisted development sessions.
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## 📖 What is the Memory System?
|
|
8
|
+
|
|
9
|
+
The memory system is a structured approach to capturing and reusing learnings from your development sessions. It helps you:
|
|
10
|
+
|
|
11
|
+
- **Preserve knowledge** across sessions (no more repeating the same mistakes)
|
|
12
|
+
- **Build institutional memory** about your codebase's patterns and gotchas
|
|
13
|
+
- **Speed up development** by applying proven patterns
|
|
14
|
+
- **Improve quality** by learning from past experiences
|
|
15
|
+
- **Onboard faster** by documenting codebase-specific insights
|
|
16
|
+
|
|
17
|
+
---
|
|
18
|
+
|
|
19
|
+
## 🗂️ Memory Structure
|
|
20
|
+
|
|
21
|
+
The memory system is organized into categorized files:
|
|
22
|
+
|
|
23
|
+
```
|
|
24
|
+
.sublation-os/memory/
|
|
25
|
+
├── index.md # Navigation and search hub
|
|
26
|
+
├── backend-lessons.md # APIs, databases, services, server-side logic
|
|
27
|
+
├── frontend-lessons.md # UI components, state management, interactions
|
|
28
|
+
├── testing-lessons.md # Testing strategies, frameworks, QA
|
|
29
|
+
├── architecture-lessons.md # System design, patterns, structure
|
|
30
|
+
├── general-lessons.md # Workflow, tooling, debugging
|
|
31
|
+
└── learned-lessons.md # Legacy unified file (backward compatibility)
|
|
32
|
+
```
|
|
33
|
+
|
|
34
|
+
Each category file contains learnings relevant to that domain, making it easier to:
|
|
35
|
+
- Find relevant lessons when working in a specific area
|
|
36
|
+
- Keep the system organized as it scales
|
|
37
|
+
- Allow agents to load only relevant learnings
|
|
38
|
+
|
|
39
|
+
---
|
|
40
|
+
|
|
41
|
+
## ✍️ Capturing Learnings
|
|
42
|
+
|
|
43
|
+
### Using the `/sublation-os:learn` Command
|
|
44
|
+
|
|
45
|
+
The easiest way to capture a learning is with the `/learn` command:
|
|
46
|
+
|
|
47
|
+
```
|
|
48
|
+
/sublation-os:learn
|
|
49
|
+
```
|
|
50
|
+
|
|
51
|
+
The command will:
|
|
52
|
+
1. Analyze your recent conversation context
|
|
53
|
+
2. Determine the appropriate category
|
|
54
|
+
3. Generate a structured entry with:
|
|
55
|
+
- Context (what happened)
|
|
56
|
+
- Lesson (the key insight)
|
|
57
|
+
- Application (how to use this knowledge)
|
|
58
|
+
- Example (optional code samples)
|
|
59
|
+
- Tags (for searchability)
|
|
60
|
+
4. Save it to the appropriate category file
|
|
61
|
+
|
|
62
|
+
### When to Capture Learnings
|
|
63
|
+
|
|
64
|
+
Capture a learning immediately when you:
|
|
65
|
+
- **Discover a pattern** in the codebase
|
|
66
|
+
- **Fix a bug** that revealed a gotcha
|
|
67
|
+
- **Learn a constraint** (e.g., "Service X uses .NET Framework 4.8")
|
|
68
|
+
- **Find the right approach** after trying alternatives
|
|
69
|
+
- **Correct a mistake** made by AI or human
|
|
70
|
+
- **Identify a performance optimization**
|
|
71
|
+
- **Document a workaround** for a known issue
|
|
72
|
+
|
|
73
|
+
---
|
|
74
|
+
|
|
75
|
+
## 🔍 Searching Learnings
|
|
76
|
+
|
|
77
|
+
### Using the `/sublation-os:recall` Command
|
|
78
|
+
|
|
79
|
+
Search across all memory files:
|
|
80
|
+
|
|
81
|
+
```
|
|
82
|
+
/sublation-os:recall [keyword or tag]
|
|
83
|
+
```
|
|
84
|
+
|
|
85
|
+
Examples:
|
|
86
|
+
- `/sublation-os:recall performance` - Find all performance-related learnings
|
|
87
|
+
- `/sublation-os:recall #database` - Search by tag
|
|
88
|
+
- `/sublation-os:recall API authentication` - Search by keywords
|
|
89
|
+
|
|
90
|
+
### Manual Search
|
|
91
|
+
|
|
92
|
+
You can also browse manually:
|
|
93
|
+
1. Open `.sublation-os/memory/index.md` to see all categories
|
|
94
|
+
2. Navigate to a specific category file
|
|
95
|
+
3. Use Ctrl+F to search within the file
|
|
96
|
+
4. Look for 🏷️ Tags sections for topic-based searching
|
|
97
|
+
|
|
98
|
+
---
|
|
99
|
+
|
|
100
|
+
## 📝 Entry Structure
|
|
101
|
+
|
|
102
|
+
Each learning entry follows a consistent structure:
|
|
103
|
+
|
|
104
|
+
```markdown
|
|
105
|
+
## Entry {N} - {YYYY-MM-DD HH:mm}
|
|
106
|
+
|
|
107
|
+
### 🧠 Context
|
|
108
|
+
Brief description of the situation or problem (1-2 sentences)
|
|
109
|
+
|
|
110
|
+
### 📘 Lesson
|
|
111
|
+
The core principle or insight - be specific to this codebase
|
|
112
|
+
|
|
113
|
+
### ⚙️ Application
|
|
114
|
+
Actionable steps for applying this lesson:
|
|
115
|
+
- Which files/services/patterns this applies to
|
|
116
|
+
- What to check before making similar changes
|
|
117
|
+
- What tools or approaches work best
|
|
118
|
+
|
|
119
|
+
### 🧩 Example (Optional)
|
|
120
|
+
Code examples showing before/after or do/don't patterns
|
|
121
|
+
|
|
122
|
+
### 🏷️ Tags
|
|
123
|
+
`#tag1` `#tag2` `#tag3`
|
|
124
|
+
```
|
|
125
|
+
|
|
126
|
+
---
|
|
127
|
+
|
|
128
|
+
## 🎯 Writing Quality Learnings
|
|
129
|
+
|
|
130
|
+
### ✅ Good Learnings Are:
|
|
131
|
+
|
|
132
|
+
**Specific to Your Codebase:**
|
|
133
|
+
- ✅ "In Work service bulk operations, use IWorkRepository.BulkUpdateAsync (WorkRepository.cs:245)"
|
|
134
|
+
- ❌ "Use async methods for better performance" (too generic)
|
|
135
|
+
|
|
136
|
+
**Actionable:**
|
|
137
|
+
- ✅ "Check WorkRepository.cs:245 for the pattern before adding new bulk operations"
|
|
138
|
+
- ❌ "Follow existing patterns" (not specific enough)
|
|
139
|
+
|
|
140
|
+
**Contextual:**
|
|
141
|
+
- ✅ "AR service uses .NET Framework 4.8 - cannot use C# 9+ features like records"
|
|
142
|
+
- ❌ "Use appropriate .NET version" (lacks context)
|
|
143
|
+
|
|
144
|
+
**Include File References:**
|
|
145
|
+
- ✅ "Multi-tenant queries MUST include TenantPermaKey filter (see WorkRepository.GetWorkItems:127)"
|
|
146
|
+
- ❌ "Remember to filter by tenant" (no reference point)
|
|
147
|
+
|
|
148
|
+
### ❌ Avoid These:
|
|
149
|
+
|
|
150
|
+
- Generic programming advice ("Write clean code", "Use SOLID principles")
|
|
151
|
+
- Lessons without file/class/method references
|
|
152
|
+
- Vague recommendations without actionable steps
|
|
153
|
+
- Lessons that don't help future AI sessions understand your codebase
|
|
154
|
+
|
|
155
|
+
---
|
|
156
|
+
|
|
157
|
+
## 🤖 How Agents Use Learnings
|
|
158
|
+
|
|
159
|
+
Sublation-OS agents automatically load and apply learnings:
|
|
160
|
+
|
|
161
|
+
### Spec Shaper
|
|
162
|
+
- Loads relevant learnings before asking requirement questions
|
|
163
|
+
- Applies past insights about product patterns
|
|
164
|
+
- Avoids asking about issues already documented
|
|
165
|
+
|
|
166
|
+
### Task List Creator
|
|
167
|
+
- Reads learnings to inform task ordering
|
|
168
|
+
- Applies lessons about dependencies and groupings
|
|
169
|
+
- Considers past mistakes when planning
|
|
170
|
+
|
|
171
|
+
### Implementer
|
|
172
|
+
- Loads category-specific learnings before coding
|
|
173
|
+
- Follows patterns documented in memory
|
|
174
|
+
- Avoids repeating past mistakes
|
|
175
|
+
- Applies optimization techniques from learnings
|
|
176
|
+
|
|
177
|
+
### Implementation Verifier
|
|
178
|
+
- Reads learnings about quality standards
|
|
179
|
+
- Checks for common issues documented in memory
|
|
180
|
+
- Applies testing patterns from past learnings
|
|
181
|
+
|
|
182
|
+
---
|
|
183
|
+
|
|
184
|
+
## 🏷️ Tagging Best Practices
|
|
185
|
+
|
|
186
|
+
Tags make learnings discoverable. Use these tag categories:
|
|
187
|
+
|
|
188
|
+
### Service/Component Tags
|
|
189
|
+
- `#WorkService` `#UserService` `#PaymentProcessor`
|
|
190
|
+
- Specific to your codebase components
|
|
191
|
+
|
|
192
|
+
### Domain Tags
|
|
193
|
+
- `#performance` `#security` `#authentication` `#validation`
|
|
194
|
+
- General software domains
|
|
195
|
+
|
|
196
|
+
### Technology Tags
|
|
197
|
+
- `#database` `#api` `#react` `#dotnet` `#sql`
|
|
198
|
+
- Specific technologies used
|
|
199
|
+
|
|
200
|
+
### Pattern Tags
|
|
201
|
+
- `#async` `#bulkoperations` `#pagination` `#caching`
|
|
202
|
+
- Implementation patterns
|
|
203
|
+
|
|
204
|
+
### Problem Tags
|
|
205
|
+
- `#debugging` `#memory-leak` `#race-condition`
|
|
206
|
+
- Problem types solved
|
|
207
|
+
|
|
208
|
+
**Aim for 3-5 tags per entry** for optimal discoverability.
|
|
209
|
+
|
|
210
|
+
---
|
|
211
|
+
|
|
212
|
+
## 📊 Maintenance
|
|
213
|
+
|
|
214
|
+
### Regular Review
|
|
215
|
+
|
|
216
|
+
Periodically review your learnings:
|
|
217
|
+
- Archive outdated learnings that no longer apply
|
|
218
|
+
- Update learnings when patterns change
|
|
219
|
+
- Add cross-references between related entries
|
|
220
|
+
- Consolidate duplicate or overlapping learnings
|
|
221
|
+
|
|
222
|
+
### Keep It Lean
|
|
223
|
+
|
|
224
|
+
Quality over quantity:
|
|
225
|
+
- Remove learnings that became irrelevant
|
|
226
|
+
- Merge similar learnings into comprehensive entries
|
|
227
|
+
- Archive learnings for deprecated features
|
|
228
|
+
|
|
229
|
+
### Team Collaboration
|
|
230
|
+
|
|
231
|
+
If working in a team:
|
|
232
|
+
- **Decide on versioning:** Keep memory files in git or gitignore them for personal use
|
|
233
|
+
- **Review together:** Discuss learnings during code reviews
|
|
234
|
+
- **Standardize tags:** Agree on common tag conventions
|
|
235
|
+
- **Share insights:** Review new learnings weekly
|
|
236
|
+
- **Assign ownership:** Designate who curates which categories
|
|
237
|
+
|
|
238
|
+
---
|
|
239
|
+
|
|
240
|
+
## 💡 Pro Tips
|
|
241
|
+
|
|
242
|
+
1. **Capture immediately** - Don't wait, the context will be lost
|
|
243
|
+
2. **Be specific** - Reference exact files, lines, classes, methods
|
|
244
|
+
3. **Include examples** - Before/after code is incredibly valuable
|
|
245
|
+
4. **Tag liberally** - More tags = easier discovery
|
|
246
|
+
5. **Review the index** - Start with `.sublation-os/memory/index.md`
|
|
247
|
+
6. **Use /recall often** - Search before implementing similar features
|
|
248
|
+
7. **Update as you learn** - Keep learnings current and relevant
|
|
249
|
+
8. **Link related learnings** - Cross-reference in the Application section
|
|
250
|
+
|
|
251
|
+
---
|
|
252
|
+
|
|
253
|
+
## 🚀 Getting Started
|
|
254
|
+
|
|
255
|
+
1. **Read the index:** Open `.sublation-os/memory/index.md`
|
|
256
|
+
2. **Browse categories:** Check out the category files to see the structure
|
|
257
|
+
3. **Capture your first learning:** Use `/sublation-os:learn` after fixing your next bug
|
|
258
|
+
4. **Search for relevance:** Use `/sublation-os:recall` when starting new features
|
|
259
|
+
5. **Let agents use it:** Agents will automatically load learnings relevant to their work
|
|
260
|
+
|
|
261
|
+
---
|
|
262
|
+
|
|
263
|
+
## 📚 Example Learning
|
|
264
|
+
|
|
265
|
+
Here's a real-world example of a quality learning:
|
|
266
|
+
|
|
267
|
+
```markdown
|
|
268
|
+
## Entry 1 - 2025-11-04 14:30
|
|
269
|
+
|
|
270
|
+
### 🧠 Context
|
|
271
|
+
When implementing pagination for the User list endpoint, the initial implementation loaded all users into memory before applying Skip/Take, causing performance issues with 10K+ users.
|
|
272
|
+
|
|
273
|
+
### 📘 Lesson
|
|
274
|
+
Always apply pagination at the database query level using IQueryable, not after materialization with ToList(). This ensures only the required page of data is fetched from the database.
|
|
275
|
+
|
|
276
|
+
### ⚙️ Application
|
|
277
|
+
1. Use IQueryable<T> in repository methods, not IEnumerable<T>
|
|
278
|
+
2. Apply `.Skip()` and `.Take()` before `.ToList()` or `.ToArrayAsync()`
|
|
279
|
+
3. Check UserRepository.GetPagedUsers (line 145) for the correct pattern
|
|
280
|
+
4. Add indexed columns for sorting fields to optimize query performance
|
|
281
|
+
5. Always test pagination with realistic data volumes (1000+ records)
|
|
282
|
+
|
|
283
|
+
### 🧩 Example
|
|
284
|
+
|
|
285
|
+
**❌ Wrong - loads all data then paginates in memory:**
|
|
286
|
+
```csharp
|
|
287
|
+
public async Task<List<User>> GetUsers(int page, int size)
|
|
288
|
+
{
|
|
289
|
+
var allUsers = await _context.Users.ToListAsync(); // ⚠️ Loads everything!
|
|
290
|
+
return allUsers.Skip(page * size).Take(size).ToList();
|
|
291
|
+
}
|
|
292
|
+
```
|
|
293
|
+
|
|
294
|
+
**✅ Correct - paginates at database level:**
|
|
295
|
+
```csharp
|
|
296
|
+
public async Task<List<User>> GetUsers(int page, int size)
|
|
297
|
+
{
|
|
298
|
+
return await _context.Users
|
|
299
|
+
.OrderBy(u => u.CreatedAt)
|
|
300
|
+
.Skip(page * size)
|
|
301
|
+
.Take(size)
|
|
302
|
+
.ToListAsync();
|
|
303
|
+
}
|
|
304
|
+
```
|
|
305
|
+
|
|
306
|
+
### 🏷️ Tags
|
|
307
|
+
`#performance` `#database` `#pagination` `#UserService` `#repository-pattern`
|
|
308
|
+
```
|
|
309
|
+
|
|
310
|
+
---
|
|
311
|
+
|
|
312
|
+
## 🔗 Related Documentation
|
|
313
|
+
|
|
314
|
+
- [Setup Guide](../../docs/setup-guide.md) - Initial setup of memory system
|
|
315
|
+
- [Agents & Commands](../../docs/agents-and-commands.md) - How agents use memory
|
|
316
|
+
- [Installation Guide](../../INSTALL.md) - Framework installation
|
|
317
|
+
|
|
318
|
+
---
|
|
319
|
+
|
|
320
|
+
## ❓ FAQ
|
|
321
|
+
|
|
322
|
+
**Q: Should I keep memory files in git?**
|
|
323
|
+
A: It depends! For team projects, keeping them in git shares knowledge. For personal projects, you might prefer to gitignore them.
|
|
324
|
+
|
|
325
|
+
**Q: How many learnings should I have?**
|
|
326
|
+
A: There's no limit, but aim for quality over quantity. 50-100 well-documented learnings is better than 500 vague ones.
|
|
327
|
+
|
|
328
|
+
**Q: Can I reorganize categories?**
|
|
329
|
+
A: Yes! The categories are a suggestion. Create custom categories that match your project's needs.
|
|
330
|
+
|
|
331
|
+
**Q: What if agents aren't using my learnings?**
|
|
332
|
+
A: Ensure learnings are specific and actionable. Generic advice is less useful to AI agents than concrete file references and patterns.
|
|
333
|
+
|
|
334
|
+
**Q: Can I manually edit memory files?**
|
|
335
|
+
A: Absolutely! Memory files are just markdown. Edit them directly if needed.
|
|
336
|
+
|
|
337
|
+
**Q: Should I capture every tiny detail?**
|
|
338
|
+
A: No. Focus on non-obvious patterns, gotchas, and codebase-specific insights that would help someone (or some AI) new to the project.
|
|
339
|
+
|
|
340
|
+
---
|
|
341
|
+
|
|
342
|
+
Happy learning! 🎓
|
|
343
|
+
|
|
344
|
+
For questions or feedback, consult the Sublation-OS documentation or your team lead.
|
|
@@ -0,0 +1,41 @@
|
|
|
1
|
+
# Architecture Lessons
|
|
2
|
+
|
|
3
|
+
This file contains learnings about system architecture, design patterns, project structure, and cross-cutting concerns.
|
|
4
|
+
|
|
5
|
+
**Search tips:**
|
|
6
|
+
- Use Ctrl+F to find specific patterns or technologies
|
|
7
|
+
- Look for 🏷️ Tags sections to find related lessons
|
|
8
|
+
- Entries are chronological - recent ones are at the bottom
|
|
9
|
+
|
|
10
|
+
---
|
|
11
|
+
|
|
12
|
+
## Entry Template
|
|
13
|
+
|
|
14
|
+
### 🧠 Context
|
|
15
|
+
Describe the situation or problem that led to this learning. What were you trying to accomplish?
|
|
16
|
+
|
|
17
|
+
### 📘 Lesson
|
|
18
|
+
The key insight or principle learned. What should future Claude sessions remember?
|
|
19
|
+
|
|
20
|
+
### ⚙️ Application
|
|
21
|
+
How to apply this lesson in practice. Specific steps or guidelines.
|
|
22
|
+
|
|
23
|
+
### 🧩 Example (Optional)
|
|
24
|
+
Code examples showing the right and wrong way:
|
|
25
|
+
|
|
26
|
+
**❌ Wrong:**
|
|
27
|
+
```language
|
|
28
|
+
// Anti-pattern code
|
|
29
|
+
```
|
|
30
|
+
|
|
31
|
+
**✅ Correct:**
|
|
32
|
+
```language
|
|
33
|
+
// Better approach
|
|
34
|
+
```
|
|
35
|
+
|
|
36
|
+
### 🏷️ Tags
|
|
37
|
+
`#tag1` `#tag2` `#tag3`
|
|
38
|
+
|
|
39
|
+
---
|
|
40
|
+
|
|
41
|
+
*Add architecture-specific learned lessons below this line.*
|
|
@@ -0,0 +1,41 @@
|
|
|
1
|
+
# Backend Lessons
|
|
2
|
+
|
|
3
|
+
This file contains learnings specific to backend development, APIs, databases, services, and server-side logic.
|
|
4
|
+
|
|
5
|
+
**Search tips:**
|
|
6
|
+
- Use Ctrl+F to find specific patterns or technologies
|
|
7
|
+
- Look for 🏷️ Tags sections to find related lessons
|
|
8
|
+
- Entries are chronological - recent ones are at the bottom
|
|
9
|
+
|
|
10
|
+
---
|
|
11
|
+
|
|
12
|
+
## Entry Template
|
|
13
|
+
|
|
14
|
+
### 🧠 Context
|
|
15
|
+
Describe the situation or problem that led to this learning. What were you trying to accomplish?
|
|
16
|
+
|
|
17
|
+
### 📘 Lesson
|
|
18
|
+
The key insight or principle learned. What should future Claude sessions remember?
|
|
19
|
+
|
|
20
|
+
### ⚙️ Application
|
|
21
|
+
How to apply this lesson in practice. Specific steps or guidelines.
|
|
22
|
+
|
|
23
|
+
### 🧩 Example (Optional)
|
|
24
|
+
Code examples showing the right and wrong way:
|
|
25
|
+
|
|
26
|
+
**❌ Wrong:**
|
|
27
|
+
```language
|
|
28
|
+
// Anti-pattern code
|
|
29
|
+
```
|
|
30
|
+
|
|
31
|
+
**✅ Correct:**
|
|
32
|
+
```language
|
|
33
|
+
// Better approach
|
|
34
|
+
```
|
|
35
|
+
|
|
36
|
+
### 🏷️ Tags
|
|
37
|
+
`#tag1` `#tag2` `#tag3`
|
|
38
|
+
|
|
39
|
+
---
|
|
40
|
+
|
|
41
|
+
*Add backend-specific learned lessons below this line.*
|
|
@@ -0,0 +1,41 @@
|
|
|
1
|
+
# Frontend Lessons
|
|
2
|
+
|
|
3
|
+
This file contains learnings specific to frontend development, UI components, state management, and user interactions.
|
|
4
|
+
|
|
5
|
+
**Search tips:**
|
|
6
|
+
- Use Ctrl+F to find specific patterns or technologies
|
|
7
|
+
- Look for 🏷️ Tags sections to find related lessons
|
|
8
|
+
- Entries are chronological - recent ones are at the bottom
|
|
9
|
+
|
|
10
|
+
---
|
|
11
|
+
|
|
12
|
+
## Entry Template
|
|
13
|
+
|
|
14
|
+
### 🧠 Context
|
|
15
|
+
Describe the situation or problem that led to this learning. What were you trying to accomplish?
|
|
16
|
+
|
|
17
|
+
### 📘 Lesson
|
|
18
|
+
The key insight or principle learned. What should future Claude sessions remember?
|
|
19
|
+
|
|
20
|
+
### ⚙️ Application
|
|
21
|
+
How to apply this lesson in practice. Specific steps or guidelines.
|
|
22
|
+
|
|
23
|
+
### 🧩 Example (Optional)
|
|
24
|
+
Code examples showing the right and wrong way:
|
|
25
|
+
|
|
26
|
+
**❌ Wrong:**
|
|
27
|
+
```language
|
|
28
|
+
// Anti-pattern code
|
|
29
|
+
```
|
|
30
|
+
|
|
31
|
+
**✅ Correct:**
|
|
32
|
+
```language
|
|
33
|
+
// Better approach
|
|
34
|
+
```
|
|
35
|
+
|
|
36
|
+
### 🏷️ Tags
|
|
37
|
+
`#tag1` `#tag2` `#tag3`
|
|
38
|
+
|
|
39
|
+
---
|
|
40
|
+
|
|
41
|
+
*Add frontend-specific learned lessons below this line.*
|
|
@@ -0,0 +1,41 @@
|
|
|
1
|
+
# General Lessons
|
|
2
|
+
|
|
3
|
+
This file contains learnings that don't fit into specific categories, including workflow practices, tooling, debugging, and cross-functional insights.
|
|
4
|
+
|
|
5
|
+
**Search tips:**
|
|
6
|
+
- Use Ctrl+F to find specific patterns or technologies
|
|
7
|
+
- Look for 🏷️ Tags sections to find related lessons
|
|
8
|
+
- Entries are chronological - recent ones are at the bottom
|
|
9
|
+
|
|
10
|
+
---
|
|
11
|
+
|
|
12
|
+
## Entry Template
|
|
13
|
+
|
|
14
|
+
### 🧠 Context
|
|
15
|
+
Describe the situation or problem that led to this learning. What were you trying to accomplish?
|
|
16
|
+
|
|
17
|
+
### 📘 Lesson
|
|
18
|
+
The key insight or principle learned. What should future Claude sessions remember?
|
|
19
|
+
|
|
20
|
+
### ⚙️ Application
|
|
21
|
+
How to apply this lesson in practice. Specific steps or guidelines.
|
|
22
|
+
|
|
23
|
+
### 🧩 Example (Optional)
|
|
24
|
+
Code examples showing the right and wrong way:
|
|
25
|
+
|
|
26
|
+
**❌ Wrong:**
|
|
27
|
+
```language
|
|
28
|
+
// Anti-pattern code
|
|
29
|
+
```
|
|
30
|
+
|
|
31
|
+
**✅ Correct:**
|
|
32
|
+
```language
|
|
33
|
+
// Better approach
|
|
34
|
+
```
|
|
35
|
+
|
|
36
|
+
### 🏷️ Tags
|
|
37
|
+
`#tag1` `#tag2` `#tag3`
|
|
38
|
+
|
|
39
|
+
---
|
|
40
|
+
|
|
41
|
+
*Add general learned lessons below this line.*
|