@magic-ingredients/tiny-brain-local 0.13.1 → 0.14.10

package/templates/adr/_template/adr-schema.json

@@ -1,74 +0,0 @@
-{
-  "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "https://example.com/adr-schema.json",
-  "title": "Architecture Decision Record",
-  "description": "Schema for validating ADR YAML frontmatter",
-  "type": "object",
-  "required": ["adr_number", "title", "date", "status"],
-  "properties": {
-    "adr_number": {
-      "type": "integer",
-      "minimum": 1,
-      "description": "Sequential ADR number"
-    },
-    "title": {
-      "type": "string",
-      "minLength": 5,
-      "maxLength": 100,
-      "description": "Brief, descriptive title of the decision"
-    },
-    "date": {
-      "type": "string",
-      "pattern": "^[0-9]{4}-[0-9]{2}-[0-9]{2}$",
-      "description": "Decision date in YYYY-MM-DD format"
-    },
-    "status": {
-      "type": "string",
-      "enum": ["proposed", "accepted", "deprecated", "superseded"],
-      "description": "Current status of the ADR"
-    },
-    "supersedes": {
-      "oneOf": [
-        { "type": "null" },
-        { "type": "integer", "minimum": 1 }
-      ],
-      "description": "ADR number this decision replaces (if any)"
-    },
-    "superseded_by": {
-      "oneOf": [
-        { "type": "null" },
-        { "type": "integer", "minimum": 1 }
-      ],
-      "description": "ADR number that replaces this decision (if any)"
-    },
-    "tags": {
-      "type": "array",
-      "items": {
-        "type": "string",
-        "pattern": "^[a-z0-9-]+$"
-      },
-      "uniqueItems": true,
-      "description": "Tags for categorizing the ADR"
-    },
-    "decision_makers": {
-      "type": "array",
-      "items": {
-        "type": "string"
-      },
-      "description": "People involved in making this decision"
-    }
-  },
-  "additionalProperties": false,
-  "examples": [
-    {
-      "adr_number": 42,
-      "title": "Use PostgreSQL for Data Storage",
-      "date": "2025-01-15",
-      "status": "accepted",
-      "supersedes": null,
-      "superseded_by": null,
-      "tags": ["database", "infrastructure"],
-      "decision_makers": ["Alice", "Bob", "Charlie"]
-    }
-  ]
-}

package/templates/adr/_template/adr-template.md

@@ -1,136 +0,0 @@
----
-# ADR Metadata (YAML Frontmatter)
-adr_number: 0
-title: "Decision Title Here"
-date: YYYY-MM-DD
-status: proposed  # proposed | accepted | deprecated | superseded
-supersedes: null  # ADR number if replacing another decision
-superseded_by: null  # ADR number if this decision was replaced
-tags: []  # e.g., [infrastructure, testing, backend]
-decision_makers: []  # People involved in the decision
----
-
-# ADR-{adr_number}: {title}
-
-## Status
-
-**{status}** (Date: {date})
-
-<!-- Status values: proposed | accepted | deprecated | superseded -->
-<!-- If superseded, reference the new ADR: "Superseded by ADR-XXX" -->
-<!-- If superseding, reference the old ADR: "Supersedes ADR-XXX" -->
-
-## Context
-
-<!-- What is the issue we're facing? -->
-<!-- What constraints exist (technical, business, team, time)? -->
-<!-- What research/prototyping/experiments informed this decision? -->
-<!-- What problem are we trying to solve? -->
-
-### Background
-<!-- Additional context about the situation -->
-
-### Constraints
-<!-- List key constraints that influenced the decision -->
-- Constraint 1
-- Constraint 2
-
-## Decision
-
-<!-- The decision that was made - be specific and concrete -->
-<!-- Use clear, declarative language: "We will use..." -->
-
-### Implementation Details
-<!-- How will this decision be implemented? -->
-<!-- Key technical specifics -->
-
-## Consequences
-
-### Positive Consequences
-<!-- Benefits realized -->
-<!-- Problems solved -->
-- Benefit 1
-- Benefit 2
-
-### Negative Consequences
-<!-- Trade-offs accepted -->
-<!-- Technical debt incurred -->
-<!-- Limitations introduced -->
-- Trade-off 1
-- Trade-off 2
-
-### Neutral Consequences
-<!-- Future work required -->
-<!-- Dependencies created -->
-<!-- Changes to team workflow -->
-- Implication 1
-- Implication 2
-
-## Alternatives Considered
-
-### Alternative 1: {Name}
-**Description:** Brief description of this alternative
-
-**Pros:**
-- Pro 1
-- Pro 2
-
-**Cons:**
-- Con 1
-- Con 2
-
-**Rejection Reason:** Why this option was not chosen
-
----
-
-### Alternative 2: {Name}
-**Description:** Brief description of this alternative
-
-**Pros:**
-- Pro 1
-- Pro 2
-
-**Cons:**
-- Con 1
-- Con 2
-
-**Rejection Reason:** Why this option was not chosen
-
----
-
-## Validation
-
-<!-- How was this decision validated? -->
-<!-- What tests/experiments were performed? -->
-<!-- What metrics were collected? -->
-<!-- What success criteria were met? -->
-
-### Tests Performed
-- Test 1
-- Test 2
-
-### Metrics Collected
-- Metric 1: Value
-- Metric 2: Value
-
-### Success Criteria
-- [ ] Criterion 1
-- [ ] Criterion 2
-
-## References
-
-<!-- Links to relevant resources -->
-- [Prototype code](url)
-- [Benchmark results](url)
-- [Team discussion](url)
-- [Related documentation](url)
-
-## Notes
-
-<!-- Any additional notes, future considerations, or follow-up items -->
-
----
-
-**Related ADRs:**
-- ADR-XXX: Related Decision
-- ADR-YYY: Another Related Decision

package/templates/prd/PRD_CREATION_INSTRUCTIONS.md

@@ -1,268 +0,0 @@
-# PRD Creation Instructions for Claude Code
-
-## When to Create a PRD
-
-Create a PRD automatically when the user describes:
-- A new product feature or capability
-- A system enhancement or improvement
-- A major technical initiative
-- A user-facing functionality change
-- Multi-step implementation requiring planning
-
-## PRD Creation Process
-
-### Step 1: Engage in Interactive Planning
-
-When a user describes requirements, engage in collaborative discussion:
-- Ask clarifying questions about scope and goals
-- Discuss constraints (technical, time, budget, team)
-- Explore user needs and pain points
-- Consider alternatives and trade-offs
-- Validate understanding before creating PRD
-
-### Step 2: Determine PRD Structure
-
-From the conversation, extract:
-- **Purpose**: What problem are we solving?
-- **Goals**: What do we want to achieve?
-- **User needs**: Who benefits and how?
-- **Features**: What functionality is needed?
-- **Success criteria**: How do we measure success?
-- **Constraints**: What limitations exist?
-
-### Step 3: Create PRD Document
-
-Use the template at `docs/prd/_template/prd-template.md` and populate:
-
-**YAML Frontmatter:**
-```yaml
-id: [descriptive-kebab-case-id]
-title: "[Clear, User-Focused Title]"
-version: 1.0.0  # Start with 1.0.0
-status: not_started  # or in_progress if work has begun
-created: [YYYY-MM-DD - today's date]
-updated: [YYYY-MM-DD - today's date]
-author: [Claude Code or user name if provided]
-```
-
-**Content Sections:**
-
-1. **Purpose and Goals**
-   - Clear problem statement
-   - High-level objectives
-   - Value proposition
-
-2. **User Needs**
-   - Target audience definition
-   - User stories in "As a [role], I want [action] so that [benefit]" format
-   - Pain points being addressed
-
-3. **Features and Functionality**
-   - List each major feature
-   - Link to separate feature markdown files
-   - Brief description of each feature
-   - Initial status (usually "planned")
-
-4. **Design and User Experience** (Optional)
-   - Directory structures if relevant
-   - Workflow visualizations
-   - UI/UX considerations
-
-5. **Release Criteria**
-   - Functional requirements (must-haves)
-   - Usability requirements
-   - Technical requirements
-   - Use checkboxes for trackability
-
-6. **Success Metrics (KPIs)**
-   - Measurable goals
-   - Target values
-   - How success will be evaluated
-
-7. **Constraints and Dependencies**
-   - Technical constraints
-   - Dependencies on other systems
-   - Known limitations or trade-offs
-
-### Step 4: Create Feature Files
-
-For each feature identified in the PRD:
-
-1. Create `docs/prd/{prd-id}/features/{feature-name}.md`
-2. Use the feature template at `docs/prd/_template/feature-template.md`
-3. Fill out:
-   - **YAML frontmatter** with feature metadata
-   - **Description** of what the feature does
-   - **Acceptance Criteria** with checkboxes
-   - **Tasks** broken down with files and expected changes
-   - **Dependencies** on other features
-   - **Testing Strategy** for validation
-
-**Feature YAML Frontmatter:**
-```yaml
-id: [feature-kebab-case-id]
-prd_id: [parent-prd-id]
-title: "[Feature Title]"
-status: planned  # planned | in_progress | complete
-created: [YYYY-MM-DD]
-updated: [YYYY-MM-DD]
-```
-
-### Step 5: Organize Directory Structure
-
-Create the following structure:
-```
-docs/prd/{prd-id}/
-├── prd.md
-└── features/
-    ├── feature-1.md
-    ├── feature-2.md
-    └── feature-3.md
-```
-
-### Step 6: Save and Confirm
-
-1. Save PRD to `docs/prd/{prd-id}/prd.md`
-2. Save features to `docs/prd/{prd-id}/features/{feature-name}.md`
-3. Tell user: "I've created PRD '{title}' with {N} features at docs/prd/{prd-id}/"
-4. Offer to make adjustments or add more features
-
-## Quality Checklist
-
-Before finalizing a PRD, verify:
-
-- [ ] All YAML frontmatter fields are filled
-- [ ] ID is in kebab-case and unique
-- [ ] Purpose clearly states the problem being solved
-- [ ] User needs include specific user stories
-- [ ] Each feature has its own markdown file
-- [ ] Features link correctly from main PRD
-- [ ] Acceptance criteria are testable
-- [ ] Tasks are broken down granularly
-- [ ] Success metrics are measurable
-- [ ] No TODO or FIXME comments remain
-- [ ] Markdown formatting is correct
-- [ ] File names follow conventions
-
-## Example Workflows
-
-### Workflow 1: New Feature Request
-
-```
-User: "We need to add user authentication to our app"
-
-Claude:
-1. Ask: "What authentication methods? Email/password? OAuth? Both?"
-2. Ask: "Any specific security requirements or compliance needs?"
-3. Ask: "Do we need password reset, MFA, session management?"
-4. Once clarified, create PRD:
-   - ID: user-authentication-system
-   - Features: email-auth, oauth-integration, password-reset, session-management
-5. Create feature files for each
-6. Save and confirm
-```
-
-### Workflow 2: Enhancement to Existing System
-
-```
-User: "Let's add real-time notifications to our chat app"
-
-Claude:
-1. Ask: "What events should trigger notifications?"
-2. Ask: "Desktop, mobile, or both? Browser notifications?"
-3. Ask: "How should users control notification preferences?"
-4. Create PRD:
-   - ID: real-time-notifications
-   - Features: push-notifications, notification-preferences, notification-history
-5. Create feature files
-6. Reference any existing PRDs if relevant
-7. Save and confirm
-```
-
-### Workflow 3: Technical Initiative
-
-```
-User: "We should refactor our API to use GraphQL"
-
-Claude:
-1. Ask: "What's driving this? Performance? Developer experience?"
-2. Ask: "Full migration or gradual? Timeline?"
-3. Ask: "Keep REST endpoints or deprecate them?"
-4. Create PRD:
-   - ID: graphql-api-migration
-   - Features: graphql-schema-design, resolver-implementation, client-migration
-5. Include migration strategy in PRD
-6. Create feature files with detailed tasks
-7. Save and confirm
-```
-
-## Common Pitfalls to Avoid
-
-❌ **Don't**: Create PRD without understanding user needs
-✅ **Do**: Have a collaborative discussion first
-
-❌ **Don't**: Write vague acceptance criteria like "Works well"
-✅ **Do**: Be specific "User can log in within 2 seconds"
-
-❌ **Don't**: Lump all functionality into one feature
-✅ **Do**: Break down into logical, testable features
-
-❌ **Don't**: Skip the constraints section
-✅ **Do**: Document limitations upfront to set expectations
-
-❌ **Don't**: Forget to link features in the main PRD
-✅ **Do**: Use relative links: `[features/auth.md](features/auth.md)`
-
-❌ **Don't**: Use technical jargon without explanation
-✅ **Do**: Write for both technical and non-technical stakeholders
-
-## Template Shortcuts
-
-### Simple Feature PRD
-```
-Purpose: Add [capability] to [system] for [user benefit]
-Features: 1-3 core features, each in separate file
-Success: [Measurable outcome]
-Timeline: [Estimated completion]
-```
-
-### System Enhancement PRD
-```
-Purpose: Improve [existing system] by [enhancement]
-Current Problems: [List pain points]
-Proposed Solution: [High-level approach]
-Features: Broken down by component or workflow
-Migration Strategy: If replacing existing functionality
-```
-
-### Technical Initiative PRD
-```
-Purpose: [Technical improvement] to achieve [business goal]
-Technical Context: Current architecture and limitations
-Proposed Architecture: New approach
-Features: Implementation phases or components
-Validation: How to test and measure success
-```
-
-## Integration with Planning System
-
-PRDs work alongside the planning system:
-- **Plan tool**: Use `plan accept` to create implementation plans
-- **Plan feature**: Add features to existing PRDs
-- **Plan implement**: Execute task-by-task with TDD
-- **Git hooks**: Automatically track commit SHAs in feature files
-
-When creating a PRD, you can offer to:
-1. Create the PRD structure
-2. Use the plan tool to create an implementation plan
-3. Begin implementation with `plan implement`
-
-## Final Notes
-
-- **Be collaborative**: PRDs are living documents; expect iteration
-- **Be thorough**: Better to over-document than under-document
-- **Be clear**: Write for diverse audiences
-- **Be realistic**: Set achievable goals and acknowledge constraints
-- **Be helpful**: Offer to create PRD even if not explicitly requested
-
-When in doubt, ask the user: "Would you like me to create a PRD to document these requirements?"