create-claude-context 1.0.0

package/templates/base/knowledge/sessions/TEMPLATE.md

@@ -0,0 +1,150 @@
+# Session Handoff: {{DATE}} {{TIME}}
+
+## Metadata
+
+| Field | Value |
+|-------|-------|
+| **Session ID** | {{SESSION_ID}} |
+| **Date** | {{DATE}} |
+| **Duration** | {{DURATION}} |
+| **Member** | {{MEMBER_NAME}} |
+| **Next Owner** | {{NEXT_OWNER}} (or "Any") |
+
+## Session Summary
+
+Brief overview of what was accomplished in this session.
+
+## Work Completed
+
+### Tasks Finished
+
+- [ ] Task 1 - Brief description
+  - Files modified: `path/to/file.ext`
+  - Commit: `abc1234`
+
+- [ ] Task 2 - Brief description
+  - Files modified: `path/to/file.ext`
+  - Commit: `def5678`
+
+### Code Changes
+
+| File | Change Type | Description |
+|------|-------------|-------------|
+| `path/to/file.ext` | Modified | What changed |
+| `path/to/new.ext` | Created | Why created |
+| `path/to/old.ext` | Deleted | Why deleted |
+
+### Tests
+
+- Tests added: X
+- Tests modified: X
+- Test status: Passing / Failing (details if failing)
+
+### Documentation Updated
+
+- [ ] `path/to/doc.md` - What was updated
+- [ ] Workflow files updated per CODE_TO_WORKFLOW_MAP.md
+
+## Work In Progress
+
+### Incomplete Tasks
+
+1. **Task Name**
+   - Status: XX% complete
+   - Current state: Description
+   - Files being modified: `path/to/file.ext`
+   - Next steps: What needs to be done
+
+2. **Task Name**
+   - Status: XX% complete
+   - Current state: Description
+   - Blockers: What's blocking progress
+
+### Uncommitted Changes
+
+```bash
+# Output of git status
+```
+
+### Temporary Files / Notes
+
+- `.claude/temp/notes.md` - Working notes
+- Local branch: `feature/xyz`
+
+## Blockers and Issues
+
+### Active Blockers
+
+1. **Blocker Title**
+   - Description: What's blocking
+   - Impact: What can't proceed
+   - Needed: What would unblock
+
+### Issues Encountered
+
+1. **Issue Title**
+   - Description: What happened
+   - Attempted solutions: What was tried
+   - Current status: Resolved / Workaround / Open
+
+### Open Questions
+
+1. Question that needs team input?
+2. Architectural decision needed?
+
+## Context for Next Session
+
+### Key Files to Review
+
+- `path/to/important.ext` - Why it's important
+- `path/to/related.ext` - How it relates
+
+### Relevant Documentation
+
+- [Workflow document](../../context/workflows/domain.md)
+- [Architecture section](../../context/ARCHITECTURE_SNAPSHOT.md#section)
+
+### Important Context
+
+Information the next person needs to know that isn't in the files:
+- Business context
+- Stakeholder requirements
+- Technical constraints discovered
+
+## Recommended Next Steps
+
+### Immediate (Next Session)
+
+1. [ ] First priority task
+2. [ ] Second priority task
+3. [ ] Third priority task
+
+### Short-term (This Week)
+
+1. [ ] Task for this week
+2. [ ] Another task
+
+### Notes for Specific Scenarios
+
+**If continuing the same work:**
+- Start with X
+- Be aware of Y
+
+**If blocked by Z:**
+- Alternative approach: Description
+- Who to contact: Person/team
+
+## Session Metrics
+
+| Metric | Value |
+|--------|-------|
+| Files Modified | X |
+| Lines Added | X |
+| Lines Removed | X |
+| Tests Added | X |
+| Commits Made | X |
+| Context Used | ~Xk tokens |
+
+---
+
+*Generated by /collab handoff on {{TIMESTAMP}}*

package/templates/base/knowledge/shared/decisions/0001-adopt-context-engineering.md

@@ -0,0 +1,144 @@
+# ADR-0001: Adopt Context Engineering Template
+
+## Metadata
+
+| Field | Value |
+|-------|-------|
+| **Status** | accepted |
+| **Created** | {{DATE}} |
+| **Updated** | {{DATE}} |
+| **Author** | {{AUTHOR_NAME}} |
+| **Reviewers** | Team |
+| **Supersedes** | N/A |
+| **Superseded by** | N/A |
+
+## Context
+
+When working with Claude Code on complex codebases, we face several challenges:
+
+### Background
+
+- Claude Code has a 200k token context window
+- Loading entire codebases exceeds this limit
+- Ad-hoc exploration wastes tokens and time
+- Knowledge is lost between sessions
+- Team members lack shared context
+
+### Current State
+
+Without structured context management:
+- Each session starts from scratch
+- Developers manually guide Claude to relevant code
+- Documentation and code drift apart
+- Tribal knowledge remains undocumented
+
+## Decision
+
+Adopt the Context Engineering Template for Claude Code, implementing:
+
+1. **3-Level Chain-of-Index Architecture** - Progressive detail loading
+2. **RPI Workflow** - Research-Plan-Implement methodology
+3. **Self-Maintaining Documentation** - Code-to-workflow mapping
+4. **Specialized Agents** - Domain-specific assistants
+
+### Key Points
+
+1. Keep context budget under 40% (80k tokens) for working room
+2. Use indexes to navigate, not to hold all information
+3. Update documentation when code changes
+4. Use RPI workflow for all significant features
+
+## Alternatives Considered
+
+### Alternative 1: Flat Documentation
+
+**Description:** Single large CLAUDE.md with all information
+
+**Pros:**
+- Simple to maintain
+- Everything in one place
+
+**Cons:**
+- Quickly exceeds context budget
+- No progressive loading
+- Hard to navigate
+
+**Why not chosen:** Doesn't scale with codebase size
+
+### Alternative 2: No Documentation Structure
+
+**Description:** Rely on Claude's code exploration
+
+**Pros:**
+- Zero maintenance overhead
+- Always up-to-date with code
+
+**Cons:**
+- Wastes context on exploration
+- No curated knowledge
+- Inconsistent results
+
+**Why not chosen:** Inefficient use of context window
+
+## Consequences
+
+### Positive
+
+- Efficient context utilization
+- Consistent navigation patterns
+- Knowledge persists across sessions
+- Team shares common understanding
+
+### Negative
+
+- Initial setup overhead
+- Requires maintenance discipline
+- Learning curve for team
+
+### Risks
+
+- Documentation drift if not maintained
+  - Mitigation: Use CODE_TO_WORKFLOW_MAP.md and /verify-docs-current
+- Over-documentation consuming budget
+  - Mitigation: Regular audits, keep to 40% target
+
+## Implementation
+
+### Steps
+
+1. Copy template to project root
+2. Run initialization (`npx claude-context init`)
+3. Customize placeholders for project
+4. Train team on RPI workflow
+5. Establish documentation update habits
+
+### Affected Components
+
+- Development workflow: Add documentation updates
+- Code review: Include documentation check
+- CI/CD: Add validation workflow
+
+### Migration Plan
+
+Gradual adoption - start with core workflows, expand as team learns.
+
+## Verification
+
+- [ ] Context budget stays under 40%
+- [ ] Team can navigate without manual guidance
+- [ ] Documentation accuracy above 80%
+- [ ] Session handoffs are effective
+
+## References
+
+- [Context Engineering Template README](../../../README.md)
+- [RPI Workflow Plan](../../../RPI_WORKFLOW_PLAN.md)
+- [Chain-of-Index Architecture](../../../indexes/README.md)
+
+---
+
+## Revision History
+
+| Date | Author | Changes |
+|------|--------|---------|
+| {{DATE}} | {{AUTHOR_NAME}} | Initial adoption decision |

package/templates/base/knowledge/shared/decisions/README.md

@@ -0,0 +1,49 @@
+# Architecture Decision Records (ADRs)
+
+This directory contains Architecture Decision Records documenting significant technical decisions.
+
+## Index
+
+| ADR | Title | Status | Date |
+|-----|-------|--------|------|
+| [0001](0001-adopt-context-engineering.md) | Adopt Context Engineering Template | accepted | {{DATE}} |
+
+## Creating a New ADR
+
+1. Copy `TEMPLATE.md` to `NNNN-descriptive-title.md`
+2. Use the next sequential number
+3. Fill in all sections
+4. Set status to `proposed`
+5. Request review from team
+6. Update status to `accepted` or `rejected` after review
+
+## ADR Lifecycle
+
+```
+proposed → accepted → deprecated
+              ↓
+          rejected
+```
+
+## Naming Convention
+
+`NNNN-lowercase-hyphenated-title.md`
+
+- NNNN: 4-digit sequential number
+- Use lowercase letters
+- Separate words with hyphens
+- Keep title concise but descriptive
+
+## When to Write an ADR
+
+Write an ADR when:
+- Choosing between significant alternatives
+- Making irreversible or costly-to-reverse decisions
+- Establishing patterns the team should follow
+- Adopting new technologies or frameworks
+- Changing architectural direction
+
+Don't write an ADR for:
+- Minor implementation details
+- Obvious choices with no alternatives
+- Temporary decisions

package/templates/base/knowledge/shared/decisions/TEMPLATE.md

@@ -0,0 +1,123 @@
+# ADR-NNNN: Title
+
+## Metadata
+
+| Field | Value |
+|-------|-------|
+| **Status** | proposed / accepted / deprecated / rejected |
+| **Created** | YYYY-MM-DD |
+| **Updated** | YYYY-MM-DD |
+| **Author** | {{AUTHOR_NAME}} |
+| **Reviewers** | {{REVIEWER_NAMES}} |
+| **Supersedes** | ADR-XXXX (if applicable) |
+| **Superseded by** | ADR-XXXX (if applicable) |
+
+## Context
+
+Describe the context and problem statement. What is the issue that we're seeing that is motivating this decision or change?
+
+### Background
+
+- Relevant technical background
+- Business requirements driving this decision
+- Constraints we must work within
+
+### Current State
+
+Describe the current situation, if applicable.
+
+## Decision
+
+Describe the change that we're proposing or have made.
+
+### Key Points
+
+1. Point 1
+2. Point 2
+3. Point 3
+
+## Alternatives Considered
+
+### Alternative 1: [Name]
+
+**Description:** Brief description
+
+**Pros:**
+- Pro 1
+- Pro 2
+
+**Cons:**
+- Con 1
+- Con 2
+
+**Why not chosen:** Explanation
+
+### Alternative 2: [Name]
+
+**Description:** Brief description
+
+**Pros:**
+- Pro 1
+- Pro 2
+
+**Cons:**
+- Con 1
+- Con 2
+
+**Why not chosen:** Explanation
+
+## Consequences
+
+### Positive
+
+- Positive consequence 1
+- Positive consequence 2
+
+### Negative
+
+- Negative consequence 1
+- Negative consequence 2
+
+### Risks
+
+- Risk 1 and mitigation
+- Risk 2 and mitigation
+
+## Implementation
+
+### Steps
+
+1. Step 1
+2. Step 2
+3. Step 3
+
+### Affected Components
+
+- Component 1: How it's affected
+- Component 2: How it's affected
+
+### Migration Plan
+
+Describe any migration required, if applicable.
+
+## Verification
+
+How will we verify this decision is successful?
+
+- [ ] Verification criteria 1
+- [ ] Verification criteria 2
+- [ ] Verification criteria 3
+
+## References
+
+- [Link to relevant documentation]()
+- [Link to related issue/PR]()
+- [Link to external resources]()
+
+---
+
+## Revision History
+
+| Date | Author | Changes |
+|------|--------|---------|
+| YYYY-MM-DD | Name | Initial draft |

package/templates/base/knowledge/shared/patterns/README.md

@@ -0,0 +1,62 @@
+# Reusable Patterns
+
+This directory contains proven solutions to common problems encountered in the codebase.
+
+## Categories
+
+| Category | Description |
+|----------|-------------|
+| `api/` | API design and implementation patterns |
+| `data/` | Data handling, validation, transformation |
+| `ui/` | User interface components and interactions |
+| `testing/` | Testing strategies and patterns |
+| `security/` | Security implementation patterns |
+| `performance/` | Performance optimization patterns |
+
+## Pattern Template
+
+Each pattern document should include:
+
+```markdown
+# Pattern Name
+
+## Problem
+What problem does this pattern solve?
+
+## Context
+When should this pattern be applied?
+
+## Solution
+How does the pattern work?
+
+## Code Example
+Concrete implementation example.
+
+## Consequences
+Trade-offs and considerations.
+
+## Related Patterns
+Links to related patterns.
+```
+
+## Adding a Pattern
+
+1. Identify a recurring problem with a proven solution
+2. Create document in appropriate category
+3. Follow the template structure
+4. Include working code examples
+5. Reference actual codebase usage
+
+## Using Patterns
+
+1. Identify the problem you're solving
+2. Check relevant category for existing patterns
+3. Adapt the pattern to your specific context
+4. Reference the pattern in your implementation
+
+## Pattern Quality Criteria
+
+- **Proven**: Used successfully in production
+- **Documented**: Clear explanation and examples
+- **Maintained**: Updated when implementation changes
+- **Reviewed**: Approved by team lead or senior developer

package/templates/base/knowledge/shared/patterns/TEMPLATE.md

@@ -0,0 +1,120 @@
+# Pattern: [Pattern Name]
+
+## Metadata
+
+| Field | Value |
+|-------|-------|
+| **Category** | api / data / ui / testing / security / performance |
+| **Created** | YYYY-MM-DD |
+| **Updated** | YYYY-MM-DD |
+| **Author** | {{AUTHOR_NAME}} |
+| **Status** | draft / approved / deprecated |
+
+## Problem
+
+Describe the problem this pattern solves.
+
+- What symptoms indicate this problem?
+- What are the consequences of not addressing it?
+
+## Context
+
+When should this pattern be applied?
+
+### Use When
+
+- Condition 1
+- Condition 2
+- Condition 3
+
+### Don't Use When
+
+- Condition 1
+- Condition 2
+
+## Solution
+
+### Overview
+
+Brief description of how the pattern works.
+
+### Structure
+
+```
+[Diagram or structure description]
+```
+
+### Implementation Steps
+
+1. Step 1
+2. Step 2
+3. Step 3
+
+## Code Example
+
+### Basic Usage
+
+```{{LANGUAGE}}
+// Example code demonstrating the pattern
+```
+
+### Advanced Usage
+
+```{{LANGUAGE}}
+// More complex example with edge cases
+```
+
+### Anti-Pattern (What NOT to Do)
+
+```{{LANGUAGE}}
+// Example of incorrect implementation
+// Explain why this is wrong
+```
+
+## Codebase References
+
+Where this pattern is used in our codebase:
+
+| Location | Description |
+|----------|-------------|
+| `path/to/file.ext:123` | Brief description |
+| `path/to/other.ext:456` | Brief description |
+
+## Consequences
+
+### Benefits
+
+- Benefit 1
+- Benefit 2
+- Benefit 3
+
+### Trade-offs
+
+- Trade-off 1
+- Trade-off 2
+
+### Risks
+
+- Risk 1 and mitigation
+- Risk 2 and mitigation
+
+## Related Patterns
+
+| Pattern | Relationship |
+|---------|--------------|
+| [Pattern Name](./path.md) | How they relate |
+| [Pattern Name](./path.md) | How they relate |
+
+## References
+
+- [External resource]()
+- [Documentation]()
+- [Original source]()
+
+---
+
+## Revision History
+
+| Date | Author | Changes |
+|------|--------|---------|
+| YYYY-MM-DD | Name | Initial version |