@slycode/slycode 0.1.1 → 0.1.3

package/templates/tutorial-project/.claude/skills/implement/SKILL.md

@@ -0,0 +1,132 @@
+---
+name: implement
+version: 1.1.1
+updated: 2026-02-22
+allowed-tools: Read, Write, Edit, Bash, Glob, Grep, TodoWrite, Task
+argument-hint: "path to chore or feature plan"
+description: "Execute a chore or feature plan and handle document lifecycle"
+---
+
+# Implement Plan
+
+Execute the specified chore or feature plan, then handle the appropriate document lifecycle. This command follows a pattern where completed chores move to a completed directory while features remain in place with updated status.
+
+## Instructions
+
+1. **Detect document type** from the file path:
+   - If path contains `/chores/`: This is a chore
+   - If path contains `/features/`: This is a feature
+2. **Read and execute** the plan thoroughly
+3. **Handle lifecycle** based on document type (see lifecycle patterns below)
+4. **Update indexes** (if project maintains index files) and report results
+
+**Note**: The lifecycle management pattern below is a suggested approach. Adapt to your project's documentation structure and workflow.
+
+## Workflow
+
+### Phase 1: Plan Analysis
+- Read the plan document
+- Identify all tasks to execute
+- Note validation commands
+- Check completion criteria
+
+### Phase 2: Implementation
+- Execute tasks in order
+- Run validation commands
+- Verify completion criteria met
+- Track all changes made
+
+### Phase 3: Document Lifecycle
+
+**For Chores** (suggested pattern):
+1. Move file from `documentation/chores/` to `documentation/chores/completed/`
+2. Update status in file from ACTIVE to COMPLETED
+3. Add completion date
+4. Update project indexes (if maintained):
+   - Remove from active chores list
+   - Add to completed chores list
+
+**For Features** (suggested pattern):
+1. Keep file in `documentation/features/` (features typically remain in place)
+2. Update status from DRAFT to FINAL (or IMPLEMENTED/COMPLETE as per project convention)
+3. Update last modified date
+4. Update feature index/README (if project maintains one)
+
+**Note**: Adjust these lifecycle steps to match your project's documentation conventions.
+
+### Phase 3b: Kanban Card Update
+
+If `scripts/kanban.js` exists, move the associated card to testing:
+
+1. Check if kanban CLI exists: `test -f scripts/kanban.js`
+2. If the plan references a card ID (in frontmatter or content), or if running in a card session:
+   - Move card to testing: `node scripts/kanban.js move <card-id> testing`
+3. This signals the work is ready for testing/review
+
+### Phase 4: Reporting
+
+Generate comprehensive report including:
+- Summary of work completed
+- Files modified (with git diff --stat)
+- Tests run and results
+- Document status changes
+- Index updates performed
+
+## Plan
+$ARGUMENTS
+
+## Lifecycle Actions
+
+Based on the document type detected, perform appropriate actions:
+
+### Chore Completion (Example)
+```bash
+# Move to completed directory (if using this pattern)
+mv documentation/chores/{file} documentation/chores/completed/
+
+# Update status in document (ACTIVE → COMPLETED)
+# Add completion date
+# Update project indexes (if applicable)
+```
+
+### Feature Completion (Example)
+```bash
+# Update status in document (DRAFT → FINAL/IMPLEMENTED)
+# Update last modified date
+# Update feature index (if project maintains one)
+```
+
+**Adapt these actions to your project's structure and conventions.**
+
+## Report Format
+
+Provide a comprehensive report following this template:
+
+```
+✅ Implementation Complete
+
+**Document**: {path}
+**Type**: {Chore|Feature}
+**Status**: {COMPLETED|FINAL|IMPLEMENTED}
+
+**Work Summary**:
+- {task 1 completed}
+- {task 2 completed}
+- {validation passed}
+
+**Files Changed**:
+{git diff --stat output or summary of changes}
+
+**Lifecycle Actions**:
+- {Document moved to completed/ | Status updated to FINAL}
+- {Index updates performed (if applicable)}
+
+**Validation Results**:
+- {Tests run and results}
+- {Build/lint status}
+
+**Next Steps**:
+- {Any follow-up actions or recommendations}
+```
+
+Adapt the report format to include project-specific metrics or validation results.

package/templates/tutorial-project/.claude/skills/kanban/SKILL.md

@@ -0,0 +1,264 @@
+---
+name: kanban
+version: 1.2.1
+updated: 2026-02-22
+description: "Manage kanban cards via CLI with commands for search, create, update, move, problem tracking, cross-agent notes, and scheduled automations"
+---
+
+# Kanban CLI Skill
+
+Manage kanban cards via CLI: `node scripts/kanban.js <command>`
+
+## Commands
+
+| Command | Description |
+|---------|-------------|
+| `search` | Find cards by query, stage, type, area |
+| `show` | Display full card details (NOT `view`) |
+| `create` | Create a new card |
+| `update` | Modify card fields |
+| `move` | Move card between stages |
+| `archive` | Soft delete a card |
+| `checklist` | Manage checklist items |
+| `problem` | Track issues on cards |
+| `notes` | Manage cross-agent notes |
+| `automation` | Configure and manage scheduled automations |
+| `areas` | List available areas |
+
+## Quick Reference
+
+```bash
+# Always start with --help if unsure
+node scripts/kanban.js --help
+node scripts/kanban.js <command> --help
+
+# Search cards
+node scripts/kanban.js search "query"
+node scripts/kanban.js search --stage backlog
+node scripts/kanban.js search --type feature
+
+# Show card details (use 'show', NOT 'view')
+node scripts/kanban.js show card-123
+
+# Create card
+node scripts/kanban.js create --title "Add feature X" --type feature --priority medium
+
+# Update card
+node scripts/kanban.js update card-123 --title "New title" --areas "web-frontend,terminal-bridge"
+
+# Link documentation to card
+node scripts/kanban.js update card-123 --design-ref "documentation/designs/foo.md"
+node scripts/kanban.js update card-123 --feature-ref "documentation/features/bar.md"
+
+# Move card
+node scripts/kanban.js move card-123 design
+
+# Archive card
+node scripts/kanban.js archive card-123
+
+# Checklist management
+node scripts/kanban.js checklist card-123 list
+node scripts/kanban.js checklist card-123 add "Write tests"
+node scripts/kanban.js checklist card-123 toggle check-123
+
+# Problem tracking
+node scripts/kanban.js problem card-123 list
+node scripts/kanban.js problem card-123 add "Bug description" --severity major
+node scripts/kanban.js problem card-123 resolve prob-123
+node scripts/kanban.js problem card-123 promote prob-123 --type chore
+
+# Agent notes
+node scripts/kanban.js notes card-123 list
+node scripts/kanban.js notes card-123 add "Context for next agent" --agent "Claude"
+node scripts/kanban.js notes card-123 search "blocker"
+node scripts/kanban.js notes card-123 edit 2 "Updated note text"
+node scripts/kanban.js notes card-123 delete 3
+node scripts/kanban.js notes card-123 clear
+
+# List available areas
+node scripts/kanban.js areas
+```
+
+## Best Practices
+
+1. **Always `show` first**: Before any action, run `show <card-id>` to see current state including existing problems
+2. **Check existing problems**: The card may already have problems logged - review before adding duplicates
+3. **Confirm with user**: When making significant changes, show the user what you plan to do
+4. **Use areas**: When creating/updating cards, set appropriate areas for context-priming
+5. **Track progress**: Use checklists for multi-step work items
+6. **Document problems**: When issues are found during testing, add them with `problem <card-id> add "description"`
+
+## Cross-Agent Notes
+
+Agent notes are a shared scratchpad on each card for passing context between agents and sessions.
+
+**When to use notes:**
+- Before starting work: `notes <card-id> list` — read what previous agents left
+- After completing a session: leave context about decisions, progress, or blockers
+- When hitting a blocker: document the issue so the next agent knows
+
+**Always identify yourself with `--agent`:**
+- Claude: `--agent "Claude"`
+- Codex: `--agent "Codex"`
+- Gemini: `--agent "Gemini"`
+- Notes added from the web UI are automatically tagged as `User`
+
+**Limits:** Max 30 notes per card, max 3000 characters per note.
+
+```bash
+# Read notes before starting
+node scripts/kanban.js notes card-123 list
+
+# Leave context after your session
+node scripts/kanban.js notes card-123 add "Completed API routes, tests passing. Frontend still needs the Notes tab wired up." --agent "Claude"
+
+# Flag a blocker
+node scripts/kanban.js notes card-123 add "Build fails on node 18 — needs --experimental flag for crypto" --agent "Codex"
+```
+
+## Integration with Onboard Action
+
+When using the Onboard action on a backlog card:
+1. Analyze and refine the card details through conversation
+2. Once the user confirms the refined version, use the CLI to apply changes:
+   ```bash
+   node scripts/kanban.js update <card-id> \
+     --title "Refined title" \
+     --description "Structured description" \
+     --areas "area1,area2" \
+     --priority high
+   ```
+
+## Linking Documentation
+
+Cards support dedicated reference fields for documentation:
+
+| Field | Flag | Purpose |
+|-------|------|---------|
+| Design Doc | `--design-ref` | Link to design document |
+| Feature Spec | `--feature-ref` | Link to feature specification |
+| Test Doc | `--test-ref` | Link to test documentation |
+
+```bash
+# Link design doc when moving to design stage
+node scripts/kanban.js update card-123 --design-ref "documentation/designs/my-feature.md"
+
+# Link feature spec when feature is fully specified
+node scripts/kanban.js update card-123 --feature-ref "documentation/features/001_my_feature.md"
+
+# Link test doc when test plan exists
+node scripts/kanban.js update card-123 --test-ref "documentation/tests/my-feature-tests.md"
+```
+
+These appear as dedicated fields on the card (not in description).
+
+## Workflow Examples
+
+### Refining a backlog item
+```bash
+# 1. View current state
+node scripts/kanban.js show card-123
+
+# 2. Update with refined details
+node scripts/kanban.js update card-123 \
+  --title "Implement user authentication with OAuth" \
+  --description "Add Google and GitHub OAuth providers..." \
+  --areas "backend,auth" \
+  --priority high
+
+# 3. Move to design when ready
+node scripts/kanban.js move card-123 design
+```
+
+### Creating a new task from user request
+```bash
+# User says: "I need to fix the login button being too small"
+node scripts/kanban.js create \
+  --title "Fix login button size" \
+  --type bug \
+  --priority medium \
+  --areas "web-frontend"
+```
+
+### Tracking testing progress
+```bash
+# Add checklist items
+node scripts/kanban.js checklist card-123 add "Unit tests pass"
+node scripts/kanban.js checklist card-123 add "Integration tests pass"
+node scripts/kanban.js checklist card-123 add "Manual testing complete"
+
+# Mark as done
+node scripts/kanban.js checklist card-123 toggle check-xxx
+
+# If issues found
+node scripts/kanban.js problem card-123 add "Login fails after timeout" --severity major
+```
+
+### Promoting problems to backlog
+When a problem is too big for a quick fix and needs its own design/implementation cycle:
+```bash
+# Review problems
+node scripts/kanban.js problem card-123 list
+
+# Promote a problem to a new backlog card
+node scripts/kanban.js problem card-123 promote prob-xxx --type chore
+
+# The original problem is marked resolved, new card created in backlog
+# Card inherits areas from source card, references original in description
+```
+
+## Scheduled Automations
+
+Cards can be toggled into automation mode — a scheduled task that fires a prompt into a terminal session at a specified time. One card = one automation.
+
+```bash
+# Create an automation card directly
+node scripts/kanban.js create --title "Nightly test run" --type chore --automation
+
+# Toggle existing card to automation mode
+node scripts/kanban.js update card-123 --automation true
+node scripts/kanban.js update card-123 --automation false
+
+# Configure automation (partial updates — only specified fields change)
+node scripts/kanban.js automation card-123 configure --schedule "0 6 * * *" --prompt "Run all tests" --provider claude
+node scripts/kanban.js automation card-123 configure --schedule "0 9 * * 1"    # just the schedule
+node scripts/kanban.js automation card-123 configure --prompt "New prompt"      # just the prompt
+node scripts/kanban.js automation card-123 configure --fresh-session true
+node scripts/kanban.js automation card-123 configure --report-messaging true
+
+# Enable / disable
+node scripts/kanban.js automation card-123 enable
+node scripts/kanban.js automation card-123 disable
+
+# Manual trigger (calls bridge API directly)
+node scripts/kanban.js automation card-123 run
+
+# View automation status
+node scripts/kanban.js automation card-123 status
+
+# List all automation cards
+node scripts/kanban.js automation list
+node scripts/kanban.js automation list --tag "deploy"
+```
+
+**Key concepts:**
+- Automation cards live on a dedicated Automations screen (not in kanban lanes)
+- The automation system is a "session starter" — it injects a prompt and confirms activity, nothing more
+- Schedule uses cron expressions (recurring) or ISO datetime (one-shot)
+- One-shot automations auto-disable after firing, config preserved
+- "Report via messaging" toggle appends instructions for the agent to send results
+
+## Error Handling
+
+The CLI provides clear error messages:
+- `Card 'xxx' not found` - Check the card ID
+- `Invalid stage` - Use: backlog, design, implementation, testing, done
+- `Invalid type` - Use: feature, chore, bug
+- `Invalid priority` - Use: low, medium, high, critical
+
+## Notes
+
+- The CLI modifies `documentation/kanban.json` directly
+- Changes are visible in the web UI on refresh
+- Archived cards are hidden by default (use `--include-archived` to see them)
+- All timestamps are in ISO format

package/templates/tutorial-project/CLAUDE.md

@@ -0,0 +1,16 @@
+# SlyCode Tutorial
+
+This is the interactive tutorial project. It teaches SlyCode by having
+the user work through a practice card across all kanban stages.
+
+When starting a session on a tutorial card:
+- Be encouraging but concise
+- If this is the practice card, check which stage it's in and guide
+  the user toward the appropriate action
+- Treat this like a real project — the README being created is real
+- Keep responses short — this is a learning environment
+
+Do not:
+- Give lengthy welcome speeches
+- Explain the entire system upfront
+- Break the fourth wall excessively ("as part of this tutorial...")

package/templates/tutorial-project/documentation/designs/example_welcome_dashboard.md

@@ -0,0 +1,38 @@
+# Design: Welcome Dashboard
+
+**Status:** Drafting
+**Created:** 2026-01-15
+
+## Problem Statement
+
+When users open the personal site, they land on a generic "About Me" page with no
+dynamic content. Returning visitors see the same static text every time. There's no
+quick summary of what's new or what I'm working on.
+
+## Goals
+
+1. Show a personalized greeting based on time of day
+2. Display the 3 most recent blog posts
+3. Show current project status (pulled from GitHub)
+4. Load fast — no client-side API calls on initial render
+
+## Non-Goals
+
+- Full analytics dashboard
+- User authentication or personalization
+- RSS feed generation
+
+## Decisions
+
+| Decision | Choice | Rationale |
+|----------|--------|-----------|
+| Data fetching | Server-side (SSR) | Avoids loading spinners, better SEO |
+| GitHub integration | REST API, cached 5 min | GraphQL is overkill for 3 fields |
+| Greeting logic | Server-side, timezone from header | No geolocation API needed |
+| Layout | Single column, cards | Matches existing site design language |
+
+## Open Questions
+
+- Should the dashboard replace the current homepage or be a separate `/dashboard` route?
+- How to handle GitHub API rate limits if the cache expires during a traffic spike?
+- Do we want a "now playing" Spotify widget? Fun but adds complexity and a new API dependency.

package/templates/tutorial-project/documentation/events.json

@@ -0,0 +1 @@
+[]

package/templates/tutorial-project/documentation/features/example_in_card_deliverable_feature.md

@@ -0,0 +1,31 @@
+# Feature: Tutorial In-Card Deliverable
+
+**Status:** Draft
+**Created:** 2026-02-26
+
+## Objective
+
+Create a tiny, high-signal deliverable that is fully inspectable inside SlyCode.
+
+## Scope
+
+In scope:
+- Companion card description refined to show the delivered outcome
+- Companion card checklist with concrete verification steps
+- Companion card agent note summarizing what was implemented
+
+Out of scope:
+- External docs or file browsing requirements
+- Full product documentation
+- Service deployment steps
+
+## Acceptance Criteria
+
+1. Companion card description clearly states what was delivered
+2. Companion card has 3+ practical checklist items
+3. Companion card includes an implementation summary note
+4. Language is concise and beginner-friendly
+
+## Notes
+
+This is intentionally lightweight. The goal is to demonstrate card-linked planning and execution while keeping the user in the SlyCode UI flow.