sublation-os 1.0.2 → 1.1.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 +16 -0
- package/.claude/agents/sublation-os/implementer.md +16 -0
- package/.claude/commands/sublation-os/address-comments.md +13 -0
- package/.claude/commands/sublation-os/consolidate-learnings.md +553 -0
- package/.claude/commands/sublation-os/implement-tasks.md +10 -0
- package/.claude/commands/sublation-os/investigate.md +14 -4
- package/.claude/commands/sublation-os/optimise.md +14 -0
- package/.claude/commands/sublation-os/review.md +18 -1
- package/.claude/commands/sublation-os/test-plan.md +19 -2
- package/.claude/skills/README.md +274 -0
- package/.claude/skills/auto-learn/SKILL.md +233 -0
- package/.cursor/commands/sublation-os/address-comments.md +74 -0
- package/.cursor/commands/sublation-os/commit-message.md +84 -0
- package/.cursor/commands/sublation-os/consolidate-learnings.md +553 -0
- package/.cursor/commands/sublation-os/create-tasks.md +254 -0
- package/.cursor/commands/sublation-os/implement-tasks.md +207 -0
- package/.cursor/commands/sublation-os/investigate.md +164 -0
- package/.cursor/commands/sublation-os/learn.md +131 -0
- package/.cursor/commands/sublation-os/optimise.md +108 -0
- package/.cursor/commands/sublation-os/plan-product.md +241 -0
- package/.cursor/commands/sublation-os/pr-description.md +15 -0
- package/.cursor/commands/sublation-os/recall.md +114 -0
- package/.cursor/commands/sublation-os/review-v2.md +701 -0
- package/.cursor/commands/sublation-os/review.md +12 -0
- package/.cursor/commands/sublation-os/shape-spec.md +395 -0
- package/.cursor/commands/sublation-os/test-plan.md +12 -0
- package/.cursor/commands/sublation-os/write-spec.md +134 -0
- package/README.md +50 -13
- package/bin/install.js +103 -24
- package/package.json +3 -2
|
@@ -0,0 +1,131 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Append a new learning entry to categorized memory files so it can be reloaded by the agent for future reasoning
|
|
3
|
+
model: sonnet
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
You are capturing a learning moment from the current session to help future Claude sessions work more effectively on this codebase.
|
|
7
|
+
|
|
8
|
+
## Your Task
|
|
9
|
+
|
|
10
|
+
Analyze the recent conversation context and generate a structured learning entry. Focus on:
|
|
11
|
+
|
|
12
|
+
1. **What went wrong or required correction** (if applicable)
|
|
13
|
+
2. **What pattern or practice should be followed**
|
|
14
|
+
3. **Codebase-specific insights** (architecture, conventions, gotchas)
|
|
15
|
+
4. **Tool usage patterns** that worked well or should be avoided
|
|
16
|
+
|
|
17
|
+
## Step 1: Determine Category
|
|
18
|
+
|
|
19
|
+
First, determine which category this learning belongs to:
|
|
20
|
+
|
|
21
|
+
- **backend** - APIs, databases, services, server-side logic, data access
|
|
22
|
+
- **frontend** - UI components, state management, user interactions, styling
|
|
23
|
+
- **testing** - Testing strategies, frameworks, mocking, test organization
|
|
24
|
+
- **architecture** - System design, patterns, project structure, cross-cutting concerns
|
|
25
|
+
- **general** - Workflow, tooling, debugging, anything that doesn't fit above
|
|
26
|
+
|
|
27
|
+
The target file will be: `.sublation-os/memory/{category}-lessons.md`
|
|
28
|
+
|
|
29
|
+
## Entry Format
|
|
30
|
+
|
|
31
|
+
Generate the entry in this exact format:
|
|
32
|
+
|
|
33
|
+
```markdown
|
|
34
|
+
## Entry {N} - {YYYY-MM-DD HH:mm}
|
|
35
|
+
|
|
36
|
+
### 🧠 Context
|
|
37
|
+
{1-2 sentences: What happened? What was the task or correction?}
|
|
38
|
+
|
|
39
|
+
### 📘 Lesson
|
|
40
|
+
{Core principle or insight as a durable rule. Be specific to this codebase when possible.}
|
|
41
|
+
|
|
42
|
+
### ⚙️ Application
|
|
43
|
+
{How should this affect future reasoning? Be actionable and specific. Include:
|
|
44
|
+
- Which files/services/patterns this applies to
|
|
45
|
+
- What to check before making similar changes
|
|
46
|
+
- What tools or approaches work best}
|
|
47
|
+
|
|
48
|
+
### 🧩 Example
|
|
49
|
+
{OPTIONAL: Concrete before/after or do/don't example}
|
|
50
|
+
|
|
51
|
+
### 🏷️ Tags
|
|
52
|
+
{Comma-separated tags for searchability: e.g., "Work service, bulk operations, async patterns, testing"}
|
|
53
|
+
|
|
54
|
+
---
|
|
55
|
+
|
|
56
|
+
```
|
|
57
|
+
|
|
58
|
+
## Instructions
|
|
59
|
+
|
|
60
|
+
1. **Read the existing file** (if it exists) to:
|
|
61
|
+
- Determine the next entry number
|
|
62
|
+
- Ensure consistent formatting
|
|
63
|
+
- Avoid duplicate lessons
|
|
64
|
+
|
|
65
|
+
2. **Generate the entry** with:
|
|
66
|
+
- Current timestamp in format: YYYY-MM-DD HH:mm
|
|
67
|
+
- Specific references to files, services, or patterns
|
|
68
|
+
- Tags for easy searching (service names, patterns, concepts)
|
|
69
|
+
|
|
70
|
+
3. **Append to file**: `.sublation-os/memory/{category}-lessons.md`
|
|
71
|
+
- The file should already exist with a template header
|
|
72
|
+
- Append the new entry at the end of the file
|
|
73
|
+
- Ensure proper spacing between entries
|
|
74
|
+
|
|
75
|
+
4. **Update index** (optional): If adding significant new tags or this is a notable learning, you may update `.sublation-os/memory/index.md` to add the new tags to the tag index
|
|
76
|
+
|
|
77
|
+
5. **Confirm to user**:
|
|
78
|
+
- Show the generated entry
|
|
79
|
+
- Mention the category, entry number, and file location
|
|
80
|
+
- Suggest when this learning might be relevant
|
|
81
|
+
|
|
82
|
+
## File Header (if creating new file)
|
|
83
|
+
|
|
84
|
+
```markdown
|
|
85
|
+
# Learned Lessons
|
|
86
|
+
|
|
87
|
+
This file contains durable learnings from Claude Code sessions to help future sessions work more effectively on this codebase.
|
|
88
|
+
|
|
89
|
+
**Search tips:**
|
|
90
|
+
- Use Ctrl+F to find specific services or patterns
|
|
91
|
+
- Look for 🏷️ Tags sections to find related lessons
|
|
92
|
+
- Entries are chronological - recent ones are at the bottom
|
|
93
|
+
|
|
94
|
+
---
|
|
95
|
+
|
|
96
|
+
```
|
|
97
|
+
|
|
98
|
+
## Quality Standards
|
|
99
|
+
|
|
100
|
+
- **Be specific**: "In Work service bulk operations, always use IWorkRepository.BulkUpdateAsync" not "Use async methods"
|
|
101
|
+
- **Be actionable**: "Check WorkRepository.cs:245 for the pattern" not "Follow existing patterns"
|
|
102
|
+
- **Be contextual**: Reference actual files, classes, methods when possible
|
|
103
|
+
- **Be relevant**: Focus on lessons that will help future Claude sessions, not general programming advice
|
|
104
|
+
|
|
105
|
+
## Examples of Good Lessons
|
|
106
|
+
|
|
107
|
+
✅ "When adding new bulk operations to Work service, use BulkUpdate domain entity pattern (WorkRepository.cs:245-280) rather than individual update loops. Provides better performance and progress tracking."
|
|
108
|
+
|
|
109
|
+
✅ "AR service uses legacy .NET Framework 4.8. Cannot use C# 9+ features like records or init-only properties. Check .csproj TargetFramework before suggesting modern syntax."
|
|
110
|
+
|
|
111
|
+
✅ "Multi-tenant queries MUST include TenantPermaKey filter. Found missing in WorkRepository.GetWorkItems - caused cross-tenant data leak in testing."
|
|
112
|
+
|
|
113
|
+
❌ "Use async/await for better performance" (too generic)
|
|
114
|
+
❌ "Follow SOLID principles" (not actionable)
|
|
115
|
+
❌ "Write tests" (not specific to this codebase)
|
|
116
|
+
|
|
117
|
+
## After Writing
|
|
118
|
+
|
|
119
|
+
Confirm to the user:
|
|
120
|
+
```
|
|
121
|
+
✅ Learning captured as Entry {N} in .sublation-os/memory/{category}-lessons.md
|
|
122
|
+
|
|
123
|
+
Category: {category}
|
|
124
|
+
This lesson will help future sessions with: {brief description}
|
|
125
|
+
|
|
126
|
+
You can search for it using tags: {list key tags}
|
|
127
|
+
```
|
|
128
|
+
|
|
129
|
+
## Notes on Legacy File
|
|
130
|
+
|
|
131
|
+
The original `learned-lessons.md` file is maintained for backward compatibility. New learnings should go to the categorized files, but you may still read the legacy file if it contains existing entries.
|
|
@@ -0,0 +1,108 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Analyze this code for performance issues
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
# Performance Optimization Analysis
|
|
6
|
+
|
|
7
|
+
You are a performance optimization specialist for .NET applications. Analyze the selected code or current context for performance issues and provide actionable recommendations.
|
|
8
|
+
|
|
9
|
+
## Analysis Framework
|
|
10
|
+
|
|
11
|
+
### 1. Identify Performance Issues
|
|
12
|
+
Scan for these common .NET performance bottlenecks:
|
|
13
|
+
|
|
14
|
+
**Database & ORM Issues:**
|
|
15
|
+
- N+1 query problems (especially with NHibernate)
|
|
16
|
+
- Missing indexes or inefficient queries
|
|
17
|
+
- Large result sets without pagination
|
|
18
|
+
- SELECT * queries instead of specific columns
|
|
19
|
+
- Unnecessary database round-trips
|
|
20
|
+
- Missing async/await for database operations
|
|
21
|
+
|
|
22
|
+
**Memory & Resource Issues:**
|
|
23
|
+
- Improper disposal of IDisposable resources
|
|
24
|
+
- Large object allocations
|
|
25
|
+
- String concatenation in loops (use StringBuilder)
|
|
26
|
+
- Boxing/unboxing of value types
|
|
27
|
+
- Memory leaks from event handlers or static references
|
|
28
|
+
- Inefficient LINQ queries causing multiple enumerations
|
|
29
|
+
|
|
30
|
+
**Concurrency & Threading:**
|
|
31
|
+
- Blocking calls on async code (`.Result`, `.Wait()`)
|
|
32
|
+
- Missing ConfigureAwait(false) in library code
|
|
33
|
+
- Improper use of locks or synchronization
|
|
34
|
+
- Thread pool starvation
|
|
35
|
+
|
|
36
|
+
**Algorithm & Logic Issues:**
|
|
37
|
+
- Inefficient algorithms (O(n²) when O(n) or O(log n) possible)
|
|
38
|
+
- Unnecessary loops or iterations
|
|
39
|
+
- Redundant computations
|
|
40
|
+
- Missing caching for expensive operations
|
|
41
|
+
|
|
42
|
+
**API & Network:**
|
|
43
|
+
- Synchronous I/O operations
|
|
44
|
+
- Chatty API calls (multiple calls when one would suffice)
|
|
45
|
+
- Missing response compression
|
|
46
|
+
- Large payloads without pagination
|
|
47
|
+
|
|
48
|
+
### 2. Prioritize Issues
|
|
49
|
+
Rank findings by:
|
|
50
|
+
- **Impact**: High/Medium/Low performance impact
|
|
51
|
+
- **Effort**: Easy/Medium/Hard to fix
|
|
52
|
+
- **Risk**: Low/Medium/High risk of introducing bugs
|
|
53
|
+
|
|
54
|
+
### 3. Provide Specific Recommendations
|
|
55
|
+
For each issue found:
|
|
56
|
+
1. **What**: Clearly describe the problem
|
|
57
|
+
2. **Where**: Reference specific file and line numbers (file_path:line_number)
|
|
58
|
+
3. **Why**: Explain the performance impact with estimated improvement if possible
|
|
59
|
+
4. **How**: Provide concrete code examples showing before/after
|
|
60
|
+
5. **Trade-offs**: Mention any downsides or considerations
|
|
61
|
+
|
|
62
|
+
### 4. Optimization Techniques
|
|
63
|
+
Consider these .NET-specific optimizations:
|
|
64
|
+
- Use `Span<T>` and `Memory<T>` for memory-intensive operations
|
|
65
|
+
- Leverage `ValueTask<T>` for frequently synchronous async methods
|
|
66
|
+
- Apply `readonly struct` for immutable value types
|
|
67
|
+
- Use `ArrayPool<T>` for temporary buffers
|
|
68
|
+
- Implement proper async patterns throughout the call stack
|
|
69
|
+
- Apply lazy initialization for expensive objects
|
|
70
|
+
- Use compiled queries for repeated NHibernate/EF queries
|
|
71
|
+
|
|
72
|
+
## Output Format
|
|
73
|
+
|
|
74
|
+
Structure your analysis as:
|
|
75
|
+
|
|
76
|
+
### 🔴 Critical Issues (Fix Immediately)
|
|
77
|
+
- Issue description with file location
|
|
78
|
+
- Performance impact and fix recommendation
|
|
79
|
+
|
|
80
|
+
### 🟡 Significant Issues (Should Fix Soon)
|
|
81
|
+
- Issue description with file location
|
|
82
|
+
- Performance impact and fix recommendation
|
|
83
|
+
|
|
84
|
+
### 🟢 Minor Improvements (Nice to Have)
|
|
85
|
+
- Issue description with file location
|
|
86
|
+
- Performance impact and fix recommendation
|
|
87
|
+
|
|
88
|
+
### ✅ Good Practices Found
|
|
89
|
+
- Highlight any exemplary performance patterns
|
|
90
|
+
|
|
91
|
+
### 📊 Estimated Overall Impact
|
|
92
|
+
- Provide realistic expectations for performance improvements
|
|
93
|
+
|
|
94
|
+
## Context Awareness
|
|
95
|
+
- Consider the BalancedLabs multi-tenant architecture
|
|
96
|
+
- Account for NHibernate usage patterns
|
|
97
|
+
- Consider IIS hosting implications
|
|
98
|
+
- Be aware of SQL Server query optimization opportunities
|
|
99
|
+
- Reference the CLAUDE.md performance considerations
|
|
100
|
+
|
|
101
|
+
## Deliverables
|
|
102
|
+
1. Prioritized list of issues with file locations
|
|
103
|
+
2. Code snippets showing recommended changes
|
|
104
|
+
3. Rationale for each recommendation
|
|
105
|
+
4. Estimated performance impact
|
|
106
|
+
5. Implementation difficulty assessment
|
|
107
|
+
|
|
108
|
+
Begin your analysis now with the selected code or current file context.
|
|
@@ -0,0 +1,241 @@
|
|
|
1
|
+
You are helping to plan and document the mission, roadmap and tech stack for the current product. This will include:
|
|
2
|
+
|
|
3
|
+
- **Gathering Information**: The user's product vision, user personas, problems and key features
|
|
4
|
+
- **Mission Document**: Take what you've gathered and create a concise mission document
|
|
5
|
+
- **Roadmap**: Create a phased development plan with prioritized features
|
|
6
|
+
- **Tech stack**: Establish the technical stack used for all aspects of this product's codebase
|
|
7
|
+
|
|
8
|
+
Carefully read and execute the instructions in the following files IN SEQUENCE, following their numbered file names. Only proceed to the next numbered instruction file once the previous numbered instruction has been executed.
|
|
9
|
+
|
|
10
|
+
Instructions to follow in sequence:
|
|
11
|
+
|
|
12
|
+
# PHASE 1: Product Concept
|
|
13
|
+
|
|
14
|
+
This begins a multi-step process for planning and documenting the mission and roadmap for the current product.
|
|
15
|
+
|
|
16
|
+
The FIRST STEP is to confirm the product details by following these instructions:
|
|
17
|
+
|
|
18
|
+
Collect comprehensive product information from the user:
|
|
19
|
+
|
|
20
|
+
```bash
|
|
21
|
+
# Check if product folder already exists
|
|
22
|
+
if [ -d "agent-os/product" ]; then
|
|
23
|
+
echo "Product documentation already exists. Review existing files or start fresh?"
|
|
24
|
+
# List existing product files
|
|
25
|
+
ls -la agent-os/product/
|
|
26
|
+
fi
|
|
27
|
+
```
|
|
28
|
+
|
|
29
|
+
Gather from user the following required information:
|
|
30
|
+
- **Product Idea**: Core concept and purpose (required)
|
|
31
|
+
- **Key Features**: Minimum 3 features with descriptions
|
|
32
|
+
- **Target Users**: At least 1 user segment with use cases
|
|
33
|
+
- **Tech stack**: Confirmation or info regarding the product's tech stack choices
|
|
34
|
+
|
|
35
|
+
If any required information is missing, prompt user:
|
|
36
|
+
```
|
|
37
|
+
Please provide the following to create your product plan:
|
|
38
|
+
1. Main idea for the product
|
|
39
|
+
2. List of key features (minimum 3)
|
|
40
|
+
3. Target users and use cases (minimum 1)
|
|
41
|
+
4. Will this product use your usual tech stack choices or deviate in any way?
|
|
42
|
+
```
|
|
43
|
+
|
|
44
|
+
|
|
45
|
+
Then WAIT for me to give you specific instructions on how to use the information you've gathered to create the mission and roadmap.
|
|
46
|
+
|
|
47
|
+
|
|
48
|
+
## User Standards & Preferences Compliance
|
|
49
|
+
|
|
50
|
+
When planning the product's tech stack, mission statement and roadmap, use the user's standards and preferences for context and baseline assumptions, as documented in these files:
|
|
51
|
+
|
|
52
|
+
@agent-os/standards/global/coding-style.md
|
|
53
|
+
@agent-os/standards/global/commenting.md
|
|
54
|
+
@agent-os/standards/global/conventions.md
|
|
55
|
+
@agent-os/standards/global/error-handling.md
|
|
56
|
+
@agent-os/standards/global/tech-stack.md
|
|
57
|
+
@agent-os/standards/global/validation.md
|
|
58
|
+
|
|
59
|
+
# PHASE 2: Create Mission
|
|
60
|
+
|
|
61
|
+
Now that you've gathered information about this product, use that info to create the mission document in `agent-os/product/mission.md` by following these instructions:
|
|
62
|
+
|
|
63
|
+
Create `agent-os/product/mission.md` with comprehensive product definition following this structure for its' content:
|
|
64
|
+
|
|
65
|
+
#### Mission Structure:
|
|
66
|
+
```markdown
|
|
67
|
+
# Product Mission
|
|
68
|
+
|
|
69
|
+
## Pitch
|
|
70
|
+
[PRODUCT_NAME] is a [PRODUCT_TYPE] that helps [TARGET_USERS] [SOLVE_PROBLEM]
|
|
71
|
+
by providing [KEY_VALUE_PROPOSITION].
|
|
72
|
+
|
|
73
|
+
## Users
|
|
74
|
+
|
|
75
|
+
### Primary Customers
|
|
76
|
+
- [CUSTOMER_SEGMENT_1]: [DESCRIPTION]
|
|
77
|
+
- [CUSTOMER_SEGMENT_2]: [DESCRIPTION]
|
|
78
|
+
|
|
79
|
+
### User Personas
|
|
80
|
+
**[USER_TYPE]** ([AGE_RANGE])
|
|
81
|
+
- **Role:** [JOB_TITLE/CONTEXT]
|
|
82
|
+
- **Context:** [BUSINESS/PERSONAL_CONTEXT]
|
|
83
|
+
- **Pain Points:** [SPECIFIC_PROBLEMS]
|
|
84
|
+
- **Goals:** [DESIRED_OUTCOMES]
|
|
85
|
+
|
|
86
|
+
## The Problem
|
|
87
|
+
|
|
88
|
+
### [PROBLEM_TITLE]
|
|
89
|
+
[PROBLEM_DESCRIPTION]. [QUANTIFIABLE_IMPACT].
|
|
90
|
+
|
|
91
|
+
**Our Solution:** [SOLUTION_APPROACH]
|
|
92
|
+
|
|
93
|
+
## Differentiators
|
|
94
|
+
|
|
95
|
+
### [DIFFERENTIATOR_TITLE]
|
|
96
|
+
Unlike [COMPETITOR/ALTERNATIVE], we provide [SPECIFIC_ADVANTAGE].
|
|
97
|
+
This results in [MEASURABLE_BENEFIT].
|
|
98
|
+
|
|
99
|
+
## Key Features
|
|
100
|
+
|
|
101
|
+
### Core Features
|
|
102
|
+
- **[FEATURE_NAME]:** [USER_BENEFIT_DESCRIPTION]
|
|
103
|
+
|
|
104
|
+
### Collaboration Features
|
|
105
|
+
- **[FEATURE_NAME]:** [USER_BENEFIT_DESCRIPTION]
|
|
106
|
+
|
|
107
|
+
### Advanced Features
|
|
108
|
+
- **[FEATURE_NAME]:** [USER_BENEFIT_DESCRIPTION]
|
|
109
|
+
```
|
|
110
|
+
|
|
111
|
+
#### Important Constraints
|
|
112
|
+
|
|
113
|
+
- **Focus on user benefits** in feature descriptions, not technical details
|
|
114
|
+
- **Keep it concise** and easy for users to scan and get the more important concepts quickly
|
|
115
|
+
|
|
116
|
+
|
|
117
|
+
|
|
118
|
+
## User Standards & Preferences Compliance
|
|
119
|
+
|
|
120
|
+
IMPORTANT: Ensure the product mission is ALIGNED and DOES NOT CONFLICT with the user's preferences and standards as detailed in the following files:
|
|
121
|
+
|
|
122
|
+
@agent-os/standards/global/coding-style.md
|
|
123
|
+
@agent-os/standards/global/commenting.md
|
|
124
|
+
@agent-os/standards/global/conventions.md
|
|
125
|
+
@agent-os/standards/global/error-handling.md
|
|
126
|
+
@agent-os/standards/global/tech-stack.md
|
|
127
|
+
@agent-os/standards/global/validation.md
|
|
128
|
+
|
|
129
|
+
# PHASE 3: Create Roadmap
|
|
130
|
+
|
|
131
|
+
Now that you've created this product's mission.md, use that to guide your creation of the roadmap in `agent-os/product/roadmap.md` by following these instructions:
|
|
132
|
+
|
|
133
|
+
Generate `agent-os/product/roadmap.md` with an ordered feature checklist:
|
|
134
|
+
|
|
135
|
+
Do not include any tasks for initializing a new codebase or bootstrapping a new application. Assume the user is already inside the project's codebase and has a bare-bones application initialized.
|
|
136
|
+
|
|
137
|
+
#### Creating the Roadmap:
|
|
138
|
+
|
|
139
|
+
1. **Review the Mission** - Read `agent-os/product/mission.md` to understand the product's goals, target users, and success criteria.
|
|
140
|
+
|
|
141
|
+
2. **Identify Features** - Based on the mission, determine the list of concrete features needed to achieve the product vision.
|
|
142
|
+
|
|
143
|
+
3. **Strategic Ordering** - Order features based on:
|
|
144
|
+
- Technical dependencies (foundational features first)
|
|
145
|
+
- Most direct path to achieving the mission
|
|
146
|
+
- Building incrementally from MVP to full product
|
|
147
|
+
|
|
148
|
+
4. **Create the Roadmap** - Use the structure below as your template. Replace all bracketed placeholders (e.g., `[FEATURE_NAME]`, `[DESCRIPTION]`, `[EFFORT]`) with real content that you create based on the mission.
|
|
149
|
+
|
|
150
|
+
#### Roadmap Structure:
|
|
151
|
+
```markdown
|
|
152
|
+
# Product Roadmap
|
|
153
|
+
|
|
154
|
+
1. [ ] [FEATURE_NAME] — [1-2 SENTENCE DESCRIPTION OF COMPLETE, TESTABLE FEATURE] `[EFFORT]`
|
|
155
|
+
2. [ ] [FEATURE_NAME] — [1-2 SENTENCE DESCRIPTION OF COMPLETE, TESTABLE FEATURE] `[EFFORT]`
|
|
156
|
+
3. [ ] [FEATURE_NAME] — [1-2 SENTENCE DESCRIPTION OF COMPLETE, TESTABLE FEATURE] `[EFFORT]`
|
|
157
|
+
4. [ ] [FEATURE_NAME] — [1-2 SENTENCE DESCRIPTION OF COMPLETE, TESTABLE FEATURE] `[EFFORT]`
|
|
158
|
+
5. [ ] [FEATURE_NAME] — [1-2 SENTENCE DESCRIPTION OF COMPLETE, TESTABLE FEATURE] `[EFFORT]`
|
|
159
|
+
6. [ ] [FEATURE_NAME] — [1-2 SENTENCE DESCRIPTION OF COMPLETE, TESTABLE FEATURE] `[EFFORT]`
|
|
160
|
+
7. [ ] [FEATURE_NAME] — [1-2 SENTENCE DESCRIPTION OF COMPLETE, TESTABLE FEATURE] `[EFFORT]`
|
|
161
|
+
8. [ ] [FEATURE_NAME] — [1-2 SENTENCE DESCRIPTION OF COMPLETE, TESTABLE FEATURE] `[EFFORT]`
|
|
162
|
+
|
|
163
|
+
> Notes
|
|
164
|
+
> - Order items by technical dependencies and product architecture
|
|
165
|
+
> - Each item should represent an end-to-end (frontend + backend) functional and testable feature
|
|
166
|
+
```
|
|
167
|
+
|
|
168
|
+
Effort scale:
|
|
169
|
+
- `XS`: 1 day
|
|
170
|
+
- `S`: 2-3 days
|
|
171
|
+
- `M`: 1 week
|
|
172
|
+
- `L`: 2 weeks
|
|
173
|
+
- `XL`: 3+ weeks
|
|
174
|
+
|
|
175
|
+
#### Important Constraints
|
|
176
|
+
|
|
177
|
+
- **Make roadmap actionable** - include effort estimates and dependencies
|
|
178
|
+
- **Priorities guided by mission** - When deciding on order, aim for the most direct path to achieving the mission as documented in mission.md
|
|
179
|
+
- **Ensure phases are achievable** - start with MVP, build incrementally
|
|
180
|
+
|
|
181
|
+
|
|
182
|
+
|
|
183
|
+
## User Standards & Preferences Compliance
|
|
184
|
+
|
|
185
|
+
IMPORTANT: Ensure the product roadmap is ALIGNED and DOES NOT CONFLICT with the user's preferences and standards as detailed in the following files:
|
|
186
|
+
|
|
187
|
+
@agent-os/standards/global/coding-style.md
|
|
188
|
+
@agent-os/standards/global/commenting.md
|
|
189
|
+
@agent-os/standards/global/conventions.md
|
|
190
|
+
@agent-os/standards/global/error-handling.md
|
|
191
|
+
@agent-os/standards/global/tech-stack.md
|
|
192
|
+
@agent-os/standards/global/validation.md
|
|
193
|
+
|
|
194
|
+
# PHASE 4: Create Tech Stack
|
|
195
|
+
|
|
196
|
+
The final part of our product planning process is to document this product's tech stack in `agent-os/product/tech-stack.md`. Follow these instructions to do so:
|
|
197
|
+
|
|
198
|
+
Create `agent-os/product/tech-stack.md` with a list of all tech stack choices that cover all aspects of this product's codebase.
|
|
199
|
+
|
|
200
|
+
### Creating the Tech Stack document
|
|
201
|
+
|
|
202
|
+
#### Step 1: Note User's Input Regarding Tech Stack
|
|
203
|
+
|
|
204
|
+
IF the user has provided specific information in the current conversation in regards to tech stack choices, these notes ALWAYS take precidence. These must be reflected in your final `tech-stack.md` document that you will create.
|
|
205
|
+
|
|
206
|
+
#### Step 2: Gather User's Default Tech Stack Information
|
|
207
|
+
|
|
208
|
+
Reconcile and fill in the remaining gaps in the tech stack list by finding, reading and analyzing information regarding the tech stack. Find this information in the following sources, in this order:
|
|
209
|
+
|
|
210
|
+
1. If user has provided their default tech stack under "User Standards & Preferences Compliance", READ and analyze this document.
|
|
211
|
+
2. If the current project has any of these files, read them to find information regarding tech stack choices for this codebase:
|
|
212
|
+
- `claude.md`
|
|
213
|
+
- `agents.md`
|
|
214
|
+
|
|
215
|
+
#### Step 3: Create the Tech Stack Document
|
|
216
|
+
|
|
217
|
+
Create `agent-os/product/tech-stack.md` and populate it with the final list of all technical stack choices, reconciled between the information the user has provided to you and the information found in provided sources.
|
|
218
|
+
|
|
219
|
+
|
|
220
|
+
## Display confirmation and next step
|
|
221
|
+
|
|
222
|
+
Once you've created tech-stack.md, output the following message:
|
|
223
|
+
|
|
224
|
+
```
|
|
225
|
+
✅ I have documented the product's tech stack at `agent-os/product/tech-stack.md`.
|
|
226
|
+
|
|
227
|
+
Review it to ensure all of the tech stack details are correct for this product.
|
|
228
|
+
|
|
229
|
+
You're ready to start planning a feature spec! You can do so by running `shape-spec.md` or `write-spec.md`.
|
|
230
|
+
```
|
|
231
|
+
|
|
232
|
+
## User Standards & Preferences Compliance
|
|
233
|
+
|
|
234
|
+
The user may provide information regarding their tech stack, which should take precidence when documenting the product's tech stack. To fill in any gaps, find the user's usual tech stack information as documented in any of these files:
|
|
235
|
+
|
|
236
|
+
@agent-os/standards/global/coding-style.md
|
|
237
|
+
@agent-os/standards/global/commenting.md
|
|
238
|
+
@agent-os/standards/global/conventions.md
|
|
239
|
+
@agent-os/standards/global/error-handling.md
|
|
240
|
+
@agent-os/standards/global/tech-stack.md
|
|
241
|
+
@agent-os/standards/global/validation.md
|
|
@@ -0,0 +1,15 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Generate a pull request description
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
## Title
|
|
6
|
+
{Summarize the PR with a clear, concise title}
|
|
7
|
+
|
|
8
|
+
## What does this PR do?
|
|
9
|
+
{Describe what this PR accomplishes from a product or user-facing perspective}
|
|
10
|
+
|
|
11
|
+
## How does it do it?
|
|
12
|
+
{Explain the key code or architectural changes that implement the solution}
|
|
13
|
+
|
|
14
|
+
## Notes / Validation (optional)
|
|
15
|
+
{Include any testing notes, known issues, or next steps if applicable}
|
|
@@ -0,0 +1,114 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Search across all memory files to find relevant learnings by keyword or tag
|
|
3
|
+
model: haiku
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
You are helping the user search for relevant learnings in the Sublation-OS memory system.
|
|
7
|
+
|
|
8
|
+
## Your Task
|
|
9
|
+
|
|
10
|
+
Search across all memory files to find learnings that match the user's query. The user may search by:
|
|
11
|
+
- **Keywords** - Any text that might appear in context, lesson, or application sections
|
|
12
|
+
- **Tags** - Specific tags like `#performance`, `#database`, `#api`, etc.
|
|
13
|
+
- **Category** - backend, frontend, testing, architecture, general
|
|
14
|
+
|
|
15
|
+
## Memory File Locations
|
|
16
|
+
|
|
17
|
+
Search in these files:
|
|
18
|
+
- `.sublation-os/memory/backend-lessons.md`
|
|
19
|
+
- `.sublation-os/memory/frontend-lessons.md`
|
|
20
|
+
- `.sublation-os/memory/testing-lessons.md`
|
|
21
|
+
- `.sublation-os/memory/architecture-lessons.md`
|
|
22
|
+
- `.sublation-os/memory/general-lessons.md`
|
|
23
|
+
- `.sublation-os/memory/learned-lessons.md` (legacy file for backward compatibility)
|
|
24
|
+
|
|
25
|
+
## Instructions
|
|
26
|
+
|
|
27
|
+
1. **Understand the query**: Analyze what the user is looking for
|
|
28
|
+
- If they mention a specific category, focus on that file first
|
|
29
|
+
- If they use a hashtag (e.g., `#performance`), search for tags
|
|
30
|
+
- Otherwise, search for keywords in all text content
|
|
31
|
+
|
|
32
|
+
2. **Use Grep tool** to search across files:
|
|
33
|
+
- Use pattern matching for keywords or tags
|
|
34
|
+
- Search in all memory files unless user specified a category
|
|
35
|
+
- Use `-A` and `-B` flags to show context around matches
|
|
36
|
+
|
|
37
|
+
3. **Present results**:
|
|
38
|
+
- Show entry number, date, and category for each match
|
|
39
|
+
- Display the relevant sections (Context, Lesson, Application)
|
|
40
|
+
- If many matches, show top 5 most relevant
|
|
41
|
+
- Include the file path for reference
|
|
42
|
+
|
|
43
|
+
4. **Provide navigation**:
|
|
44
|
+
- Suggest related tags the user might want to search
|
|
45
|
+
- Mention how many total matches were found
|
|
46
|
+
- Offer to show more results if there are many
|
|
47
|
+
|
|
48
|
+
## Example Search Patterns
|
|
49
|
+
|
|
50
|
+
**Search by tag:**
|
|
51
|
+
```
|
|
52
|
+
User query: "performance"
|
|
53
|
+
→ Use Grep with pattern: `#performance` or `performance` in all memory files
|
|
54
|
+
```
|
|
55
|
+
|
|
56
|
+
**Search by keyword:**
|
|
57
|
+
```
|
|
58
|
+
User query: "database queries"
|
|
59
|
+
→ Use Grep with pattern: `database.*queries` or just `database` in all memory files
|
|
60
|
+
```
|
|
61
|
+
|
|
62
|
+
**Search by category:**
|
|
63
|
+
```
|
|
64
|
+
User query: "backend learnings about APIs"
|
|
65
|
+
→ Focus on backend-lessons.md, search for `API` or `api`
|
|
66
|
+
```
|
|
67
|
+
|
|
68
|
+
## Output Format
|
|
69
|
+
|
|
70
|
+
Present results like this:
|
|
71
|
+
|
|
72
|
+
```
|
|
73
|
+
🔍 Found {N} learning(s) matching "{query}":
|
|
74
|
+
|
|
75
|
+
---
|
|
76
|
+
|
|
77
|
+
**Entry {N} - {Category}** ({date})
|
|
78
|
+
File: .sublation-os/memory/{category}-lessons.md
|
|
79
|
+
|
|
80
|
+
### 🧠 Context
|
|
81
|
+
{context text}
|
|
82
|
+
|
|
83
|
+
### 📘 Lesson
|
|
84
|
+
{lesson text}
|
|
85
|
+
|
|
86
|
+
### ⚙️ Application
|
|
87
|
+
{application text}
|
|
88
|
+
|
|
89
|
+
### 🏷️ Tags
|
|
90
|
+
{tags}
|
|
91
|
+
|
|
92
|
+
---
|
|
93
|
+
|
|
94
|
+
💡 Related tags you might want to search: {suggested tags}
|
|
95
|
+
```
|
|
96
|
+
|
|
97
|
+
## If No Results
|
|
98
|
+
|
|
99
|
+
If no matches are found:
|
|
100
|
+
```
|
|
101
|
+
❌ No learnings found matching "{query}"
|
|
102
|
+
|
|
103
|
+
Suggestions:
|
|
104
|
+
- Try broader keywords
|
|
105
|
+
- Check spelling and try synonyms
|
|
106
|
+
- Browse categories: backend, frontend, testing, architecture, general
|
|
107
|
+
- Use `/sublation-os:learn` to capture a new learning on this topic
|
|
108
|
+
```
|
|
109
|
+
|
|
110
|
+
## Additional Features
|
|
111
|
+
|
|
112
|
+
- If user asks to "show more", display additional results beyond the first 5
|
|
113
|
+
- If user wants to see a specific entry in full, read that file and show the complete entry
|
|
114
|
+
- Suggest creating a new learning if the topic isn't well covered
|