Orchestre Memory Templates Reference

Overview

Orchestre v5 uses a distributed memory system that creates structured documentation alongside your code. This reference covers the memory templates and patterns used by Orchestre commands.

Memory Structure

When initialized, Orchestre creates the following memory structure:

.orchestre/
├── CLAUDE.md           # Orchestration-specific context
├── prompts.json        # Available prompts configuration
├── memory/             # Memory storage
│   ├── semantic/       # Concepts and facts
│   ├── episodic/       # Experiences and solutions
│   ├── procedural/     # Patterns and workflows
│   └── working/        # Current session context
├── knowledge/          # Project insights
├── templates/          # Memory templates
├── plans/              # Development plans
├── tasks/              # Task tracking
├── sessions/           # Session history
├── reviews/            # Code reviews
└── patterns/           # Discovered patterns

Memory Template Types

1. Project Memory Template

Location: CLAUDE.md (project root)

# Project: [Project Name]

## Overview
[Brief project description]

## Architecture
- **Type**: [monolith/microservices/serverless]
- **Stack**: [technology stack]
- **Patterns**: [architectural patterns used]

## Key Decisions
1. [Decision]: [Rationale]
2. [Decision]: [Rationale]

## Development Guidelines
- [Guideline 1]
- [Guideline 2]

## Known Issues
- [Issue]: [Status/Workaround]

## Future Considerations
- [Consideration 1]
- [Consideration 2]

2. Feature Memory Template

Location: .orchestre/memory/features/[feature-name].md

# Feature: [Feature Name]

## Overview
[Feature description and purpose]

## Implementation Details
- **Added**: [Date]
- **Modified**: [Dates]
- **Dependencies**: [List of dependencies]

## Architecture
### Components
- [Component 1]: [Description]
- [Component 2]: [Description]

### Data Flow
1. [Step 1]
2. [Step 2]

## Configuration
```yaml
[Configuration details]

Testing

• Unit Tests: [Location]
• Integration Tests: [Location]
• Test Coverage: [Percentage]

Security Considerations

• [Consideration 1]
• [Consideration 2]

Performance Notes

Troubleshooting

Common Issues

Future Improvements

• [ ] [Improvement 1]
• [ ] [Improvement 2]

### 3. Session Memory Template

**Location:** `.orchestre/sessions/[date]-[session-id].md`

```markdown
# Development Session: [Date]

## Session Goals
- [ ] [Goal 1]
- [ ] [Goal 2]

## Context
- **Previous State**: [Description]
- **Target State**: [Description]

## Tasks Completed
1. ✓ [Task 1]
   - [Details]
   - Files: [file1.ts, file2.ts]
2. ✓ [Task 2]
   - [Details]
   - Files: [file3.ts]

## Decisions Made
- **[Decision]**: [Rationale]
- **[Decision]**: [Rationale]

## Problems Encountered
### [Problem 1]
- **Issue**: [Description]
- **Solution**: [How it was resolved]
- **Learning**: [Key takeaway]

## Code Changes
### Added
- `path/to/file.ts`: [Description]

### Modified
- `path/to/file.ts`: [Changes made]

### Removed
- `path/to/file.ts`: [Reason]

## Testing Results
- **Tests Run**: [Number]
- **Tests Passed**: [Number]
- **Coverage Change**: [+/-X%]

## Next Steps
1. [Next task 1]
2. [Next task 2]

## Session Metrics
- **Duration**: [Time]
- **Files Changed**: [Number]
- **Lines Added**: [Number]
- **Lines Removed**: [Number]

4. Pattern Memory Template

Location: .orchestre/patterns/[pattern-name].md

# Pattern: [Pattern Name]

## Classification
- **Type**: [structural/behavioral/creational]
- **Category**: [architecture/implementation/integration]
- **Frequency**: [common/occasional/rare]

## Description
[What this pattern does and why it's useful]

## When to Use
- [Scenario 1]
- [Scenario 2]

## Implementation
```typescript
// Example implementation
[Code example]

Variations

[Variation 1]

[Description and code]

[Variation 2]

[Description and code]

Trade-offs

Pros

• [Advantage 1]
• [Advantage 2]

Cons

• [Disadvantage 1]
• [Disadvantage 2]

Real Examples in Project

1. path/to/implementation1.ts
2. path/to/implementation2.ts

Related Patterns

Anti-patterns to Avoid

• [Anti-pattern 1]: [Why to avoid]
• [Anti-pattern 2]: [Why to avoid]

### 5. Architecture Decision Record (ADR) Template

**Location:** `.orchestre/knowledge/decisions/ADR-[number]-[title].md`

```markdown
# ADR-[Number]: [Title]

## Status
[Proposed/Accepted/Deprecated/Superseded by ADR-X]

## Context
[The issue motivating this decision]

## Decision
[The change that we're proposing or have agreed to implement]

## Consequences
### Positive
- [Consequence 1]
- [Consequence 2]

### Negative
- [Consequence 1]
- [Consequence 2]

### Neutral
- [Consequence 1]
- [Consequence 2]

## Alternatives Considered
1. **[Alternative 1]**
   - Pros: [List]
   - Cons: [List]
   - Reason not chosen: [Explanation]

2. **[Alternative 2]**
   - Pros: [List]
   - Cons: [List]
   - Reason not chosen: [Explanation]

## Implementation Notes
[Any specific implementation details or gotchas]

## References
- [Link 1]
- [Link 2]

6. Security Review Template

Location: .orchestre/reviews/security-[date].md

# Security Review: [Date]

## Scope
- **Areas Reviewed**: [List]
- **Excluded**: [What wasn't reviewed]

## Vulnerabilities Found
### Critical
1. **[Vulnerability]**
   - Location: `file.ts:line`
   - Impact: [Description]
   - Fix: [Solution]
   - Status: [Fixed/Pending]

### High
[Similar structure]

### Medium
[Similar structure]

### Low
[Similar structure]

## Security Improvements Implemented
1. [Improvement 1]
2. [Improvement 2]

## Dependency Audit
### Vulnerable Dependencies
- `package@version`: [CVE-ID] - [Description]

### Updated Dependencies
- `package`: `old-version` → `new-version`

## Security Best Practices
### Implemented
- [x] [Practice 1]
- [x] [Practice 2]

### Pending
- [ ] [Practice 1]
- [ ] [Practice 2]

## Recommendations
1. [Recommendation 1]
2. [Recommendation 2]

## Next Review Date
[Date]

7. Task Memory Template

Location: .orchestre/tasks/[task-id].md

# Task: [Task Title]

## Metadata
- **ID**: [task-id]
- **Created**: [Date]
- **Status**: [pending/in-progress/completed/blocked]
- **Priority**: [high/medium/low]
- **Estimated Effort**: [time]
- **Actual Effort**: [time]

## Description
[Detailed task description]

## Acceptance Criteria
- [ ] [Criterion 1]
- [ ] [Criterion 2]
- [ ] [Criterion 3]

## Dependencies
### Blocking
- [Task/Feature that must be completed first]

### Blocked By
- [What this task is blocking]

## Implementation Plan
1. [Step 1]
2. [Step 2]
3. [Step 3]

## Progress Log
### [Date]
- [What was done]
- [Issues encountered]
- [Next steps]

## Testing Requirements
- [ ] Unit tests for [component]
- [ ] Integration tests for [feature]
- [ ] Manual testing of [scenario]

## Documentation Updates
- [ ] Update API docs
- [ ] Update user guide
- [ ] Update CLAUDE.md

## Review Notes
[Any notes from code review or testing]

## Completion Checklist
- [ ] Code implemented
- [ ] Tests written and passing
- [ ] Documentation updated
- [ ] Code reviewed
- [ ] Deployed to staging
- [ ] Deployed to production

Memory Template Usage by Commands

Command	Templates Used
orchestre-orchestrate	Project Memory, ADR
orchestre-execute-task	Task Memory, Session Memory
orchestre-compose-saas-mvp	Feature Memory, Pattern Memory
orchestre-security-audit	Security Review
orchestre-add-enterprise-feature	Feature Memory, ADR
orchestre-migrate-to-teams	ADR, Architecture Memory
orchestre-document-feature	Feature Memory
orchestre-discover-context	All templates for synthesis

Best Practices

1. Keep It Current: Update memory files as you work
2. Be Specific: Include concrete examples and code snippets
3. Link Related Items: Reference other memory files when relevant
4. Version Control: Memory files are part of your codebase
5. Review Regularly: Periodically review and consolidate memory

Customizing Templates

You can customize templates by:

1. Modifying files in .orchestre/templates/
2. Adding new template types
3. Extending existing templates with project-specific sections

Templates use standard Markdown with:

• YAML frontmatter for metadata (optional)
• Consistent heading structure
• Code blocks with language hints
• Task lists for tracking
• Links to related resources