create-claude-context 1.0.0 → 1.2.0

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

@@ -1,150 +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}}*
+# 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

@@ -1,144 +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 |
+# 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

@@ -1,49 +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
+# 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