@slycode/slycode 0.1.0 → 0.1.2

package/templates/tutorial-project/.agents/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/.agents/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/skills/checkpoint/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: checkpoint
+version: 1.3.1
+updated: 2026-02-22
+allowed-tools: Bash, Read
+argument-hint: [optional commit message]
+description: Create a git checkpoint of ALL recent changes
+---
+
+# Git Checkpoint Creation
+
+Create a checkpoint commit of ALL uncommitted changes in the repository.
+
+## Process
+
+1. **Check status**: Run `git status --short` to see all changes
+2. **Analyze changes**: For each modified/added file, briefly review what changed using `git diff <file> | head -50` or read new files
+3. **Stage everything**: Run `git add -A` to stage ALL changes (modified, new, and deleted files)
+4. **Write commit message**: Based on analysis, write a clear commit message that:
+   - Has a concise summary line (under 72 chars)
+   - Lists key changes as bullet points
+   - Groups related changes together
+5. **Commit**: Create the commit with the message
+
+## Important Rules
+
+- **Commit EVERYTHING**: Do not selectively pick files. All uncommitted changes should be included.
+- **Analyze first**: Read diffs or file contents to understand what changed before writing the commit message.
+- **Be descriptive**: The commit message should explain WHAT was done, not just list file names.
+- **No AI attribution**: Do not include "Co-Authored-By: Claude" or similar.
+
+## Example Commit Message Format
+
+```
+Summary of changes in imperative mood
+
+- Add feature X with support for Y
+- Fix bug in Z where condition was wrong
+- Update config to enable new option
+- Refactor module for better performance
+```
+
+If an optional message argument is provided, use it as the summary line.

package/templates/tutorial-project/.claude/skills/context-priming/SKILL.md

@@ -0,0 +1,152 @@
+---
+name: context-priming
+version: 1.1.1
+updated: 2026-02-22
+description: Dynamic context provider for codebase knowledge. This skill should be used when working on code, answering questions about architecture, or making changes that require understanding of project structure. Maintains area-specific reference files that are loaded on demand. Self-updating based on observed drift between references and actual code. Load this skill early in work sessions - it contains essential workflow and update protocols.
+---
+
+# Context Priming
+
+Provide dynamic, accurate context about this project's architecture and code. Load knowledge on demand, update when drift is observed, self-improve based on experience.
+
+## When to Invoke
+
+**Load context when:**
+- Starting work requiring codebase knowledge not in current conversation
+- Making changes to unfamiliar areas
+- Answering questions about project architecture or patterns
+- User asks about functionality and current context is insufficient
+
+**Do NOT load when:**
+- Information is clearly present from last 3-5 exchanges
+- Task is trivial and doesn't require architectural understanding
+- Already loaded relevant areas in this session (unless significant time/work has passed)
+
+## How to Use
+
+1. **Load area-index.md first** - understand available areas, their update dates, load-when triggers
+2. **Load relevant area(s)** - based on current task and index guidance
+3. **Follow area's "when to expand"** - each area indicates when to open specific files
+4. **Evaluate freshness** - compare area's `updated` date against today (from system prompt); consider git activity if concerned
+
+## Callouts
+
+Prefix operational updates with `Priming:` to signal skill activity. Keep brief - one line.
+
+**When to call out:**
+- Loading an area: `Priming: Loading backend - API work detected.`
+- Loading multiple: `Priming: This spans backend and database areas, loading both.`
+- Staleness concern: `Priming: backend looks stale (Nov 20), will verify as I go.`
+- Making a note: `Priming: Quick note added - auth order matters.`
+- Skipping load: `Priming: Already have frontend context from earlier.`
+
+**Don't call out:** Every file read, minor internal decisions, routine checks.
+
+## Update Behavior
+
+| Situation | Action |
+|-----------|--------|
+| Loaded info contradicts code in misleading way | Update reference in stride |
+| Minor drift, no practical impact | Let it slide |
+| Unsure if update needed | Note concern, ask at end of task |
+| Multiple areas need restructuring | Consult user before proceeding |
+| New feature added affecting an area | Update area reference |
+| User says "context priming needs to know this" | Capture in relevant area |
+| User says "you should have known this" | Analyze failure, propose fix (see below) |
+
+**Small updates**: Make concisely, in stride, no announcement needed.
+**Large restructuring/defrag**: Consult first. See `references/maintenance.md`.
+
+## "You Should Have Known" Response
+
+When user indicates priming failed:
+
+1. **Identify cause**: Which of these?
+   - Area not loaded when it should have been (bad load-when criteria)
+   - Area loaded but info missing (incomplete reference)
+   - Info existed but outdated (stale reference)
+   - Area doesn't exist (missing area)
+   - Judgment call to skip loading was wrong (bad heuristic)
+
+2. **Propose fix** based on cause:
+   - Content/index updates → do in stride
+   - SKILL.md or maintenance.md changes → explain problem, propose change, await approval
+
+3. **Surface immediately** - don't wait for task end. User will indicate if disruptive.
+
+## Permission Model
+
+| File | Permission |
+|------|------------|
+| references/areas/*.md | Update in stride |
+| references/area-index.md | Update in stride |
+| Add/remove/split areas | Suggest, light confirmation |
+| SKILL.md | Explain, propose, await approval |
+| references/maintenance.md | Explain, propose, await approval |
+
+## Git Usage
+
+Use `git diff` or `git log` sparingly:
+- Before major refactors to verify scope
+- When user questions accuracy of loaded info
+- To check activity since area's last update date when staleness suspected
+
+Not for routine small changes.
+
+## Context Compaction
+
+No direct visibility into remaining context space. When user flags compaction is imminent, or after long exploration sessions: consider if valuable learnings should be captured before context is summarized.
+
+## Self-Improvement
+
+Area notes (in area-index.md) capture learnings:
+- Up to 10 notes per area, quality over quantity
+- Format: actionable guidance ("when X, do Y" or "don't assume Z")
+- Remove notes that no longer apply
+- If skill behavior is flawed, suggest improvement to user
+
+If suggestion timing/frequency becomes disruptive, user will indicate - adjust accordingly.
+
+## Operational Principles
+
+- Concise updates: prefer short phrase tweaks over paragraph additions
+- Don't bloat references - information density is the goal
+- When on fence about loading, lean toward loading
+- Trust the index's load-when triggers; refine them when wrong
+- No hardcoded "status" - freshness is evaluated dynamically
+
+## Skill Location & Cross-Provider Note
+
+**Canonical path (relative to project root):**
+```
+.claude/skills/context-priming/
+├── SKILL.md                        # This file
+├── references/
+│   ├── area-index.md               # Index of all areas (load first)
+│   ├── maintenance.md              # Defrag, pruning, area separation doctrine
+│   └── areas/
+│       └── [name].md               # Deep reference per area
+```
+
+**Resolution order — try these paths in order, use the first that exists:**
+
+1. **Primary:** `<project-root>/.claude/skills/context-priming/` — the canonical, most up-to-date copy. Always check here first.
+2. **Fallback:** The directory containing this SKILL.md (i.e. your own skill folder). If there is no `.claude/` directory in the project, the references were likely copied alongside this file.
+
+This matters when the skill is deployed to another provider (Codex at `.agents/skills/`, Gemini at `.gemini/skills/`). Those folders may contain just this SKILL.md for discovery, with the area files living in `.claude/`. But if the project has no `.claude/` directory at all (e.g. a pure Codex or Gemini project), fall back to reading from your own skill directory.
+
+**Resolved paths (primary):**
+- **Area index:** `<project-root>/.claude/skills/context-priming/references/area-index.md`
+- **Area files:** `<project-root>/.claude/skills/context-priming/references/areas/<name>.md`
+- **Maintenance:** `<project-root>/.claude/skills/context-priming/references/maintenance.md`
+
+**Resolved paths (fallback — relative to this SKILL.md):**
+- **Area index:** `./references/area-index.md`
+- **Area files:** `./references/areas/<name>.md`
+- **Maintenance:** `./references/maintenance.md`
+
+## Files
+
+- `references/area-index.md` - compact index of all areas
+- `references/maintenance.md` - defrag, pruning, area separation doctrine
+- `references/areas/[name].md` - deep reference per area