@orderful/droid 0.4.1 → 0.5.1

package/src/skills/project/references/templates.md

@@ -0,0 +1,124 @@
+# Project Templates
+
+Templates vary by `preset` setting.
+
+## Markdown Preset (default)
+
+### PROJECT.md
+
+```markdown
+---
+status: active
+---
+
+# Project: {Name}
+
+{Brief description}
+
+| | |
+|---|---|
+| **Version** | 0.1.0 |
+| **Started** | {today} |
+| **Status** | Active |
+
+## Overview
+
+{**What** this project does, **why** it exists}
+
+## Goals
+
+- {Goal 1}
+
+## Technical Details
+
+{Architecture, key files, patterns}
+
+## Changelog
+
+See [CHANGELOG.md](CHANGELOG.md) for full history.
+
+### 0.1.0 - {today}
+- Initial project setup
+```
+
+### CHANGELOG.md
+
+```markdown
+# Changelog
+
+All notable changes to the {Name} project.
+
+## 0.1.0 - {today}
+- Initial project setup
+```
+
+---
+
+## Obsidian Preset
+
+### PROJECT.md
+
+```markdown
+---
+type: project
+status: active
+created: {today}
+updated: {today}
+---
+
+# Project: {Name}
+
+{Brief description}
+
+| | |
+|---|---|
+| **Version** | 0.1.0 |
+| **Started** | {today} |
+| **Status** | Active |
+
+## Overview
+
+{**What** this project does, **why** it exists}
+
+## Goals
+
+- {Goal 1}
+
+## Technical Details
+
+{Architecture, key files, patterns}
+
+## Related
+
+- {Links to related notes}
+
+## Changelog
+
+See [[CHANGELOG|full history]].
+
+### 0.1.0 - {today}
+- Initial project setup
+```
+
+### CHANGELOG.md
+
+Same as markdown preset.
+
+---
+
+## Template Variables
+
+| Variable | Expands To |
+|----------|------------|
+| `{today}` | YYYY-MM-DD |
+| `{Name}` | Project name (Title Case) |
+| `{name}` | Project name (lowercase) |
+| `{kebab-name}` | Folder name (kebab-case) |
+
+## Preset Differences Summary
+
+| Feature | Markdown | Obsidian |
+|---------|----------|----------|
+| Links | `[text](path)` | `[[path\|text]]` |
+| YAML properties | Minimal (`status`) | Rich (`type`, `created`, `updated`) |
+| Related section | Optional | Included |

package/src/skills/project/references/updating.md

@@ -0,0 +1,64 @@
+# Updating a Project
+
+**Trigger:** `/project update` or user asks to capture/save learnings
+
+## Procedure
+
+1. **Identify the project:**
+   - If name provided: Find matching project (same logic as loading)
+   - If no name: Check conversation for prior project load
+   - If still unclear: List projects and ask which to update
+
+2. **Analyze the conversation for:**
+   - New implementation details or patterns
+   - Key decisions and rationale
+   - Technical constraints discovered
+   - Progress on features
+   - Important file paths or code locations
+   - Bug fixes or gotchas encountered
+
+3. **If significant new information found:**
+   - Propose specific sections/content to add or update
+   - Show what will be changed
+   - Ask for confirmation before proceeding
+
+4. **If no obvious updates:**
+   - Ask what the user would like to update
+   - Suggest sections: metadata, implementation details, technical decisions, notes
+
+5. **After approval:**
+   - Read current project file
+   - Make approved updates, preserving existing structure
+   - Determine version bump (see `versioning.md`)
+   - Add changelog entry (see `changelog.md`)
+   - Confirm what was updated
+
+## What to Capture
+
+Good project updates include:
+
+| Type | Examples |
+|------|----------|
+| **Decisions** | "Chose cursor-based pagination over offset" |
+| **Patterns** | "Using repository pattern for data access" |
+| **Constraints** | "Must support backwards compatibility with v1 API" |
+| **Gotchas** | "Watch out for timezone handling in date fields" |
+| **Progress** | "Completed validation layer, starting on UI" |
+| **File locations** | "Key files: `src/services/template.service.ts`" |
+
+## Example
+
+```
+User: /project update
+
+Claude: I'll update #project-transaction-templates with learnings from this session.
+
+Proposed changes:
+- Add "Permission Controls" section documenting the new RBAC approach
+- Update Technical Details with the Handlebars helper patterns we established
+- Note the decision to use soft deletes
+
+This looks like a minor version bump (0.16.0 → 0.17.0).
+
+Proceed with these updates?
+```

package/src/skills/project/references/versioning.md

@@ -0,0 +1,36 @@
+# Version Bumping Rules
+
+Use semantic versioning for project docs.
+
+## When to Bump
+
+| Type | When | Examples |
+|------|------|----------|
+| **Major** | Breaking changes, complete rewrites, fundamental architecture changes | New approach that invalidates previous docs |
+| **Minor** | New features, new sections, significant additions | New helper added, new endpoint, new workflow |
+| **Patch** | Clarifications, small updates, typo fixes, status changes | Wording tweaks, deferred features, bug notes |
+
+## Auto-Determination
+
+Analyze the changes being made:
+
+1. Default to **minor** for most content additions
+2. Use **patch** for small clarifications or status updates
+3. Use **major** only for fundamental changes (rare)
+4. Only ask user if genuinely ambiguous
+
+## Examples
+
+**Patch (0.1.0 -> 0.1.1):**
+- Fixed typo in technical details
+- Updated status from active to reference
+- Added note about known limitation
+
+**Minor (0.1.1 -> 0.2.0):**
+- Added new "Authentication" section
+- Documented new API endpoint
+- Added architecture diagram
+
+**Major (0.2.0 -> 1.0.0):**
+- Complete rewrite of implementation approach
+- Switched from REST to GraphQL (invalidates prior docs)