@slycode/slycode 0.1.1 → 0.1.3
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/bridge/pty-handler.js +7 -1
- package/dist/bridge/pty-handler.js.map +1 -1
- package/dist/web/.next/BUILD_ID +1 -1
- package/dist/web/.next/build-manifest.json +2 -2
- package/dist/web/.next/server/app/_global-error.html +2 -2
- package/dist/web/.next/server/app/_global-error.rsc +1 -1
- package/dist/web/.next/server/app/_global-error.segments/__PAGE__.segment.rsc +1 -1
- package/dist/web/.next/server/app/_global-error.segments/_full.segment.rsc +1 -1
- package/dist/web/.next/server/app/_global-error.segments/_head.segment.rsc +1 -1
- package/dist/web/.next/server/app/_global-error.segments/_index.segment.rsc +1 -1
- package/dist/web/.next/server/app/_global-error.segments/_tree.segment.rsc +1 -1
- package/dist/web/.next/server/app/_not-found.html +1 -1
- package/dist/web/.next/server/app/_not-found.rsc +1 -1
- package/dist/web/.next/server/app/_not-found.segments/_full.segment.rsc +1 -1
- package/dist/web/.next/server/app/_not-found.segments/_head.segment.rsc +1 -1
- package/dist/web/.next/server/app/_not-found.segments/_index.segment.rsc +1 -1
- package/dist/web/.next/server/app/_not-found.segments/_not-found/__PAGE__.segment.rsc +1 -1
- package/dist/web/.next/server/app/_not-found.segments/_not-found.segment.rsc +1 -1
- package/dist/web/.next/server/app/_not-found.segments/_tree.segment.rsc +1 -1
- package/dist/web/.next/server/chunks/[root-of-the-server]__198f01e0._.js +1 -1
- package/dist/web/.next/server/chunks/[root-of-the-server]__884d73e4._.js +1 -1
- package/dist/web/.next/server/chunks/[root-of-the-server]__aa814a86._.js +1 -1
- package/dist/web/.next/server/chunks/[root-of-the-server]__b90bbd70._.js +1 -1
- package/dist/web/.next/server/chunks/node_modules_next_dist_esm_build_templates_app-route_ffc6c790.js +1 -1
- package/dist/web/.next/server/pages/404.html +1 -1
- package/dist/web/.next/server/pages/500.html +2 -2
- package/dist/web/src/app/api/git-status/route.ts +1 -0
- package/dist/web/src/app/api/projects/analyze/route.ts +1 -0
- package/dist/web/src/app/api/projects/route.ts +1 -0
- package/dist/web/src/app/api/transcribe/route.ts +1 -1
- package/dist/web/src/app/api/version-check/route.ts +1 -0
- package/lib/cli/doctor.d.ts.map +1 -1
- package/lib/cli/doctor.js +2 -1
- package/lib/cli/doctor.js.map +1 -1
- package/lib/cli/start.d.ts.map +1 -1
- package/lib/cli/start.js +1 -0
- package/lib/cli/start.js.map +1 -1
- package/lib/cli/stop.d.ts.map +1 -1
- package/lib/cli/stop.js +6 -4
- package/lib/cli/stop.js.map +1 -1
- package/lib/cli/update.d.ts.map +1 -1
- package/lib/cli/update.js +8 -5
- package/lib/cli/update.js.map +1 -1
- package/package.json +1 -1
- package/templates/kanban-seed.json +1 -1
- package/templates/tutorial-project/.agents/skills/checkpoint/SKILL.md +43 -0
- package/templates/tutorial-project/.agents/skills/context-priming/SKILL.md +152 -0
- package/templates/tutorial-project/.agents/skills/context-priming/references/area-index.md +101 -0
- package/templates/tutorial-project/.agents/skills/context-priming/references/areas/claude-actions.md +120 -0
- package/templates/tutorial-project/.agents/skills/context-priming/references/areas/messaging.md +177 -0
- package/templates/tutorial-project/.agents/skills/context-priming/references/areas/scripts-deployment.md +138 -0
- package/templates/tutorial-project/.agents/skills/context-priming/references/areas/skills.md +135 -0
- package/templates/tutorial-project/.agents/skills/context-priming/references/areas/terminal-bridge.md +232 -0
- package/templates/tutorial-project/.agents/skills/context-priming/references/areas/web-frontend.md +252 -0
- package/templates/tutorial-project/.agents/skills/context-priming/references/maintenance.md +128 -0
- package/templates/tutorial-project/.agents/skills/design/SKILL.md +141 -0
- package/templates/tutorial-project/.agents/skills/feature/SKILL.md +159 -0
- package/templates/tutorial-project/.agents/skills/implement/SKILL.md +132 -0
- package/templates/tutorial-project/.agents/skills/kanban/SKILL.md +264 -0
- package/templates/tutorial-project/.claude/skills/checkpoint/SKILL.md +43 -0
- package/templates/tutorial-project/.claude/skills/context-priming/SKILL.md +152 -0
- package/templates/tutorial-project/.claude/skills/context-priming/references/area-index.md +101 -0
- package/templates/tutorial-project/.claude/skills/context-priming/references/areas/claude-actions.md +120 -0
- package/templates/tutorial-project/.claude/skills/context-priming/references/areas/messaging.md +177 -0
- package/templates/tutorial-project/.claude/skills/context-priming/references/areas/scripts-deployment.md +138 -0
- package/templates/tutorial-project/.claude/skills/context-priming/references/areas/skills.md +135 -0
- package/templates/tutorial-project/.claude/skills/context-priming/references/areas/terminal-bridge.md +232 -0
- package/templates/tutorial-project/.claude/skills/context-priming/references/areas/web-frontend.md +252 -0
- package/templates/tutorial-project/.claude/skills/context-priming/references/maintenance.md +128 -0
- package/templates/tutorial-project/.claude/skills/design/SKILL.md +141 -0
- package/templates/tutorial-project/.claude/skills/feature/SKILL.md +159 -0
- package/templates/tutorial-project/.claude/skills/implement/SKILL.md +132 -0
- package/templates/tutorial-project/.claude/skills/kanban/SKILL.md +264 -0
- package/templates/tutorial-project/CLAUDE.md +16 -0
- package/templates/tutorial-project/documentation/designs/example_welcome_dashboard.md +38 -0
- package/templates/tutorial-project/documentation/events.json +1 -0
- package/templates/tutorial-project/documentation/features/example_in_card_deliverable_feature.md +31 -0
- package/templates/tutorial-project/documentation/kanban.json +385 -0
- /package/dist/web/.next/static/{cut-BpEHnH8_V_vl0UOOW → QUrfyJ4-tKEk_x5K_NIKK}/_buildManifest.js +0 -0
- /package/dist/web/.next/static/{cut-BpEHnH8_V_vl0UOOW → QUrfyJ4-tKEk_x5K_NIKK}/_clientMiddlewareManifest.json +0 -0
- /package/dist/web/.next/static/{cut-BpEHnH8_V_vl0UOOW → QUrfyJ4-tKEk_x5K_NIKK}/_ssgManifest.js +0 -0
package/templates/tutorial-project/.claude/skills/context-priming/references/areas/web-frontend.md
ADDED
|
@@ -0,0 +1,252 @@
|
|
|
1
|
+
# Web Frontend
|
|
2
|
+
|
|
3
|
+
Updated: 2026-02-14
|
|
4
|
+
|
|
5
|
+
## Overview
|
|
6
|
+
|
|
7
|
+
Next.js 16 command center for project management. Features project cards with health scoring, kanban boards with drag-drop, card modals, command configuration, system health monitoring, cross-project toolkit/asset management, global search, activity feed, project scaffolding, and graceful reconnection handling. Neon-minimalist theme (SlyCode Neon) with Tailwind CSS v4, featuring lane-colored gradients, SVG noise textures, and theme-aware terminal styling.
|
|
8
|
+
|
|
9
|
+
## Key Files
|
|
10
|
+
|
|
11
|
+
### Pages & Layout
|
|
12
|
+
- `web/src/app/page.tsx` - Home dashboard, lists projects from registry
|
|
13
|
+
- `web/src/app/project/[id]/page.tsx` - Project detail page with kanban
|
|
14
|
+
- `web/src/components/ProjectPageClient.tsx` - Client wrapper for project pages, global terminal activity polling
|
|
15
|
+
- `web/src/components/ProjectView.tsx` - Project view wrapper, manages archive toggle state
|
|
16
|
+
|
|
17
|
+
### Core Components
|
|
18
|
+
- `web/src/components/Dashboard.tsx` - Project card grid + Toolkit tab, global search, number-key shortcuts
|
|
19
|
+
- `web/src/components/ProjectKanban.tsx` - Kanban board container, drag-drop logic
|
|
20
|
+
- `web/src/components/KanbanColumn.tsx` - Stage columns (backlog, design, impl, testing, done)
|
|
21
|
+
- `web/src/components/KanbanCardItem.tsx` - Individual card, status indicators, active glow effect
|
|
22
|
+
- `web/src/components/CardModal.tsx` - Full card editor with dynamic tabs, edit session protection
|
|
23
|
+
- `web/src/components/ProjectHeader.tsx` - Header with Commands, Archive toggle, HealthMonitor
|
|
24
|
+
|
|
25
|
+
### Project Management
|
|
26
|
+
- `web/src/components/ProjectCard.tsx` - Enhanced project card with health dot, platform badges, edit/delete
|
|
27
|
+
- `web/src/components/AddProjectModal.tsx` - Multi-phase project creation wizard (details → analysis → scaffold → done)
|
|
28
|
+
- `web/src/components/HealthDot.tsx` - Health score indicator with tooltip (green/amber/red)
|
|
29
|
+
- `web/src/components/PlatformBadges.tsx` - Detected AI platform badges (Claude, Gemini, Codex)
|
|
30
|
+
- `web/src/components/SearchBar.tsx` - Global/contextual search across all kanban cards
|
|
31
|
+
|
|
32
|
+
### Terminal & Commands
|
|
33
|
+
- `web/src/components/ClaudeTerminalPanel.tsx` - Reusable terminal with provider selector, startupCommands/activeCommands, card area filtering
|
|
34
|
+
- `web/src/components/Terminal.tsx` - xterm.js terminal with ConnectionManager integration
|
|
35
|
+
- `web/src/components/CommandConfigModal.tsx` - Command configuration UI with Command Assistant terminal
|
|
36
|
+
- `web/src/components/GlobalClaudePanel.tsx` - Floating panel for project-wide session, supports session/CWD/class overrides
|
|
37
|
+
|
|
38
|
+
### Toolkit & Assets
|
|
39
|
+
- `web/src/components/ToolkitTab.tsx` - Asset management tab with matrix view and pending changes
|
|
40
|
+
- `web/src/components/AssetMatrix.tsx` - Cross-project asset deployment matrix with click-to-deploy/remove
|
|
41
|
+
- `web/src/components/AssetViewer.tsx` - Modal viewer for asset content with frontmatter display
|
|
42
|
+
|
|
43
|
+
### Activity & Content
|
|
44
|
+
- `web/src/components/ActivityFeed.tsx` - Collapsible event log with day grouping and stage indicators
|
|
45
|
+
- `web/src/components/MarkdownContent.tsx` - Markdown renderer using react-markdown with GFM support
|
|
46
|
+
|
|
47
|
+
### Health & Connection
|
|
48
|
+
- `web/src/components/HealthMonitor.tsx` - System stats widget (CPU, memory, terminals)
|
|
49
|
+
- `web/src/components/ConnectionStatusIndicator.tsx` - Reconnection toast indicator
|
|
50
|
+
- `web/src/lib/connection-manager.ts` - Centralized SSE reconnection with Page Visibility API
|
|
51
|
+
|
|
52
|
+
### Hooks
|
|
53
|
+
- `web/src/hooks/useConnectionStatus.ts` - Hook for connection state subscription
|
|
54
|
+
- `web/src/hooks/useKeyboardShortcuts.ts` - Keyboard navigation (1-9 project jump, Escape)
|
|
55
|
+
- `web/src/hooks/useCommandsConfig.ts` - Polling-based commands config loader (30s intervals)
|
|
56
|
+
- `web/src/hooks/usePolling.ts` - Generic polling hook
|
|
57
|
+
|
|
58
|
+
### Utilities
|
|
59
|
+
- `web/src/lib/types.ts` - All shared types (see Data Models)
|
|
60
|
+
- `web/src/lib/claude-actions.ts` - getStartupCommands(), getActiveCommands(), renderTemplate()
|
|
61
|
+
- `web/src/lib/registry.ts` - Project registry loader with kanban, health scoring, platform detection
|
|
62
|
+
- `web/src/lib/paths.ts` - Dynamic path resolution for SlyCode root and project directories
|
|
63
|
+
- `web/src/lib/kanban-paths.ts` - Project-aware kanban file path resolution with tiered backup
|
|
64
|
+
- `web/src/lib/asset-scanner.ts` - Asset scanning, frontmatter parsing, version comparison, platform detection
|
|
65
|
+
- `web/src/lib/event-log.ts` - Append-only activity log with filtering/querying (500 event cap)
|
|
66
|
+
- `web/src/lib/health-score.ts` - Health score calculator with configurable weights
|
|
67
|
+
- `web/src/lib/tab-sync.ts` - Cross-tab synchronization using BroadcastChannel API
|
|
68
|
+
|
|
69
|
+
### API Routes
|
|
70
|
+
- `web/src/app/api/kanban/route.ts` - Kanban CRUD
|
|
71
|
+
- `web/src/app/api/bridge/[...path]/route.ts` - Bridge proxy
|
|
72
|
+
- `web/src/app/api/commands/route.ts` - Commands CRUD
|
|
73
|
+
- `web/src/app/api/commands/stream/route.ts` - SSE for command file changes
|
|
74
|
+
- `web/src/app/api/system-stats/route.ts` - CPU/memory metrics
|
|
75
|
+
- `web/src/app/api/areas/route.ts` - Available areas list
|
|
76
|
+
- `web/src/app/api/terminal-classes/route.ts` - Terminal class definitions
|
|
77
|
+
- `web/src/app/api/claude-actions/route.ts` - Commands in ClaudeActionsConfig format
|
|
78
|
+
- `web/src/app/api/toolkit/route.ts` - Scan all project assets, build matrix
|
|
79
|
+
- `web/src/app/api/toolkit/sync/route.ts` - Batch deploy/remove assets
|
|
80
|
+
- `web/src/app/api/toolkit/import/route.ts` - Import asset from project to ClaudeMaster
|
|
81
|
+
- `web/src/app/api/events/route.ts` - Query activity log with filters
|
|
82
|
+
- `web/src/app/api/search/route.ts` - Cross-project card search
|
|
83
|
+
- `web/src/app/api/projects/route.ts` - List/create projects
|
|
84
|
+
- `web/src/app/api/projects/[id]/route.ts` - GET/PUT/DELETE individual project
|
|
85
|
+
- `web/src/app/api/projects/analyze/route.ts` - Analyze directory before scaffolding
|
|
86
|
+
- `web/src/app/api/providers/route.ts` - GET/PUT for providers.json (provider list + stage defaults)
|
|
87
|
+
- `web/src/app/api/file/route.ts` - Read files from approved directories
|
|
88
|
+
- `web/src/app/api/git-status/route.ts` - Git status for projects
|
|
89
|
+
|
|
90
|
+
## Key Functions
|
|
91
|
+
|
|
92
|
+
- `ProjectKanban.handleDragEnd()` - Reorders cards, handles cross-column moves
|
|
93
|
+
- `ConnectionManager.createManagedEventSource()` - Auto-reconnecting SSE with backoff
|
|
94
|
+
- `getStartupCommands(commands, terminalClass, hasHistory)` - Filter commands for session start
|
|
95
|
+
- `getActiveCommands(commands, terminalClass)` - Filter commands for running session toolbar
|
|
96
|
+
- `scanProjectAssets()` - Scan commands/skills/agents across projects, build matrix
|
|
97
|
+
- `calculateHealthScore()` - Score 0-100 based on configurable weighted factors
|
|
98
|
+
|
|
99
|
+
## CardModal Tabs
|
|
100
|
+
|
|
101
|
+
- **Details** - Edit fields, dropdowns for stage/priority, editable areas/tags chips, delete button
|
|
102
|
+
- **Design** - Shows if `design_ref` exists, renders markdown with copy path button
|
|
103
|
+
- **Feature** - Shows if `feature_ref` exists, renders markdown
|
|
104
|
+
- **Test** - Shows if `test_ref` exists, renders markdown
|
|
105
|
+
- **Checklist** - Interactive checkboxes with progress bar (uses ref-based state for rapid clicks)
|
|
106
|
+
- **Terminal** - AI session with provider selector, auto-connect, startupCommands/activeCommands
|
|
107
|
+
|
|
108
|
+
CardModal uses edit session protection: last-known-value tracking, 2000ms grace period for field editing, prevents overwriting active edits from external updates.
|
|
109
|
+
|
|
110
|
+
## Health Scoring
|
|
111
|
+
|
|
112
|
+
- **Factors**: outdated assets, stale cards, unresolved problems, missing CLAUDE.md, non-compliant frontmatter
|
|
113
|
+
- **Levels**: green (≥80), amber (≥50), red (<50)
|
|
114
|
+
- **Display**: HealthDot component with tooltip showing score breakdown
|
|
115
|
+
- Located on ProjectCard in Dashboard
|
|
116
|
+
|
|
117
|
+
## Toolkit (Asset Management)
|
|
118
|
+
|
|
119
|
+
- Scans commands/skills/agents across all projects
|
|
120
|
+
- Frontmatter validation: name, version, updated, description required
|
|
121
|
+
- Version comparison for detecting outdated assets
|
|
122
|
+
- Matrix view: rows=assets, columns=projects, cells=status
|
|
123
|
+
- Batch operations: deploy to / remove from projects
|
|
124
|
+
- Import from project back to ClaudeMaster
|
|
125
|
+
|
|
126
|
+
## Connection Management
|
|
127
|
+
|
|
128
|
+
- `ConnectionManager` - Singleton managing all SSE connections
|
|
129
|
+
- Page Visibility API detection for sleep/wake cycles
|
|
130
|
+
- Exponential backoff with jitter (1s initial, 30s max)
|
|
131
|
+
- `ConnectionStatusIndicator` - Toast showing "Reconnecting..." during recovery
|
|
132
|
+
|
|
133
|
+
## Data Models
|
|
134
|
+
|
|
135
|
+
- `KanbanCard` - id, title, description, type, priority, order, areas[], tags[], problems[], checklist[], archived?, design_ref?, feature_ref?, test_ref?, claude_session?
|
|
136
|
+
- `Command` - label, description, group, cardTypes[], prompt, visibleIn, scope, sessionState
|
|
137
|
+
- `BridgeStats` - bridgeTerminals, connectedClients, activelyWorking, sessions[]
|
|
138
|
+
- `SystemStats` - cpu (0-100), memory {used, total}, swap {used, total}
|
|
139
|
+
- `SessionActivity` - name, status, lastOutputAt, isActive
|
|
140
|
+
- `AssetInfo` - name, type, version, updated, description, filePath, frontmatter
|
|
141
|
+
- `AssetCell` - status (present|outdated|missing|extra), masterVersion?, projectVersion?
|
|
142
|
+
- `ToolkitData` - rows (AssetRow[]), projects (string[])
|
|
143
|
+
- `HealthScore` - score (0-100), level (green|amber|red), factors[]
|
|
144
|
+
- `ActivityEvent` - type, timestamp, project, detail, cardId?
|
|
145
|
+
- `SearchResult` - card, project, matchedFields[]
|
|
146
|
+
- `ProjectWithBacklog` - extends Project with assets, gitUncommitted, healthScore, platforms, lastActivity, activeSessions
|
|
147
|
+
- `ProvidersData` - providers (Record<id, ProviderConfig>), defaults (stages, global, projects)
|
|
148
|
+
- `ProviderConfig` - id, displayName, command, permissions, resume, prompt
|
|
149
|
+
|
|
150
|
+
## Design System — SlyCode Neon Theme
|
|
151
|
+
|
|
152
|
+
### Philosophy
|
|
153
|
+
Neon-minimalist aesthetic. Clean surfaces with subtle texture for life and depth. Never sterile/flat, never over-the-top. The theme should feel like a premium tool — atmospheric but professional. Light mode is clean with color; dark mode is moody with glow.
|
|
154
|
+
|
|
155
|
+
### Color Palette
|
|
156
|
+
- **Neon Blue** (`--neon-blue: #00bfff`) — Primary accent, design/implementation lanes, links, active states
|
|
157
|
+
- **Neon Orange** (`--neon-orange: #ff8c00`) — Global/project terminal headers, warnings
|
|
158
|
+
- **Red-Orange** (`#ff6a33`) — Testing lane (NOT standard orange, which looks brown in dark mode)
|
|
159
|
+
- **Green** — Done lane, success states, running indicators
|
|
160
|
+
- **Void** — Neutral grey scale for backgrounds, borders, muted text
|
|
161
|
+
- **Red** (`#ff3b5c`) — Critical/bug indicators, stop buttons
|
|
162
|
+
|
|
163
|
+
### Critical Color Lesson
|
|
164
|
+
Dark-end scale colors (e.g. `neon-orange-950 = #2b1700`) are inherently brown. For vibrant dark mode colors, use the BRIGHT color at LOW OPACITY (e.g. `neon-orange-400/15`) instead of dark scale values.
|
|
165
|
+
|
|
166
|
+
### Texture System (globals.css)
|
|
167
|
+
Three-layer texture approach for gradient surfaces:
|
|
168
|
+
|
|
169
|
+
1. **Fine grain** (`.grain`) — High-frequency SVG feTurbulence noise (`baseFrequency: 0.65`), overlay blend. Desaturate with `feColorMatrix type='saturate' values='0'` when color neutrality matters.
|
|
170
|
+
2. **Perlin noise** (`.depth-glow`) — Low-frequency organic texture (`baseFrequency: 0.015` light, `0.012` dark), large 400px tiles. Light mode uses `screen` blend (lightens), dark mode uses `soft-light`. Masked with left-to-right gradient fade.
|
|
171
|
+
3. **Terminal texture** (`.terminal-texture`) — CRT-like grain + vignette + lane-colored tint via `--terminal-tint` CSS variable. Box-shaped mask (edges visible, centre clear). Light: `soft-light` blend. Dark: `screen` blend (avoids warm/red cast from `soft-light` on dark backgrounds).
|
|
172
|
+
|
|
173
|
+
### Blend Mode Rules
|
|
174
|
+
- `soft-light` on dark backgrounds produces warm/red cast — avoid for dark mode textures
|
|
175
|
+
- `overlay` is neutral but can be invisible on very dark surfaces
|
|
176
|
+
- `screen` always adds light — use for dark mode when you need visible texture
|
|
177
|
+
- `mix-blend-multiply` makes white backgrounds transparent (light mode logos)
|
|
178
|
+
- `mix-blend-lighten` makes black backgrounds transparent (dark mode logos)
|
|
179
|
+
- `filter: drop-shadow()` traces the ALPHA boundary — creates rectangular glow on images with opaque backgrounds. Incompatible with blend-mode logo transparency.
|
|
180
|
+
|
|
181
|
+
### Logo Handling
|
|
182
|
+
Logos have opaque backgrounds (white for light, black for dark). Two `<img>` tags per location:
|
|
183
|
+
- Light: `mix-blend-multiply dark:hidden`
|
|
184
|
+
- Dark: `mix-blend-lighten hidden dark:block`
|
|
185
|
+
- All CSS drop-shadow/filter glow DISABLED (creates rectangular artifacts with blend modes). Logos have baked-in glow.
|
|
186
|
+
- Files: `slycode_light.png` / `slycode.png` (hero), `slycode_logo_light.png` / `slycode_logo.png` (nav)
|
|
187
|
+
|
|
188
|
+
### Lane-Colored Theming
|
|
189
|
+
Stage colors flow through multiple layers:
|
|
190
|
+
- **KanbanColumn headers** — `colorClasses` map with header gradient, text, count badge, border
|
|
191
|
+
- **CardModal header/tabs** — `stageModalStyles` map with gradients, borders per stage. Uses transparency (85% → 50%) for subtle glass quality
|
|
192
|
+
- **CardModal footer** — `stageTerminalColors` with colored top border
|
|
193
|
+
- **Terminal tint** — `stageTerminalTint` map provides rgba color → passed as `tintColor` prop → sets `--terminal-tint` CSS variable on terminal overlay
|
|
194
|
+
|
|
195
|
+
### Gradient Direction Convention
|
|
196
|
+
Left-to-right, vibrant-to-soft. The left/start side is always the stronger color, fading lighter toward the right. Never center-out fades (looks artificial).
|
|
197
|
+
|
|
198
|
+
### Button Aesthetic — Neon Glass
|
|
199
|
+
Terminal/action buttons use semi-transparent backgrounds with colored borders and hover glow:
|
|
200
|
+
```
|
|
201
|
+
border border-{color}-400/40 bg-{color}-400/15 text-{color}-400
|
|
202
|
+
hover:bg-{color}-400/25 hover:shadow-[0_0_12px_rgba(...,0.3)]
|
|
203
|
+
```
|
|
204
|
+
|
|
205
|
+
### Health Monitor
|
|
206
|
+
Uses inline gradient fills + glow shadows (not flat CSS classes):
|
|
207
|
+
- Normal: `linear-gradient(90deg, #00e676, #00bfff)` + blue glow
|
|
208
|
+
- Warning: `linear-gradient(90deg, #ff8c00, #ffaa00)` + orange glow
|
|
209
|
+
- Critical: `linear-gradient(90deg, #ff3b5c, #ff6b81)` + red glow
|
|
210
|
+
|
|
211
|
+
### Terminal Background
|
|
212
|
+
Theme-aware: `#222228` (light mode, slightly lighter) / `#1a1a1a` (dark mode). Detected at xterm mount via `document.documentElement.classList.contains('dark')`. Wrapper divs use `bg-[#222228] dark:bg-[#1a1a1a]`.
|
|
213
|
+
|
|
214
|
+
### Dark Mode Borders
|
|
215
|
+
Card modals get colored outer borders in dark mode (`dark:border dark:border-{color}/25-30`). Section dividers (header/tabs/terminal) use lane colors in both modes.
|
|
216
|
+
|
|
217
|
+
## Patterns & Invariants
|
|
218
|
+
|
|
219
|
+
- Cards auto-save on changes via `/api/kanban` PUT
|
|
220
|
+
- Kanban data stored in `documentation/kanban.json` per project
|
|
221
|
+
- Stage order: backlog → design → implementation → testing → done
|
|
222
|
+
- Active glow: `active-glow-card` CSS class with pulse animation (2s activity threshold)
|
|
223
|
+
- Commands use `startupCommands` (session start) and `activeCommands` (running toolbar)
|
|
224
|
+
- SSE connections managed centrally via ConnectionManager for reconnection
|
|
225
|
+
- Dynamic path resolution via paths.ts (no hardcoded paths)
|
|
226
|
+
- Cross-tab sync via BroadcastChannel API
|
|
227
|
+
- Number keys 1-9 jump to projects, Escape closes modals
|
|
228
|
+
- Event log capped at 500 entries, append-only
|
|
229
|
+
- Session names include provider segment: `{projectId}:{provider}:card:{cardId}`
|
|
230
|
+
- Provider selector shown on no-session screen, pre-filled from stage defaults
|
|
231
|
+
- CardModal detects existing session's provider from session name for pre-selection
|
|
232
|
+
- ProjectKanban/ProjectPageClient use regex patterns to match both new and legacy session names
|
|
233
|
+
|
|
234
|
+
## When to Expand
|
|
235
|
+
|
|
236
|
+
- Editing card behavior → CardModal.tsx
|
|
237
|
+
- Kanban drag/drop issues → ProjectKanban.tsx, KanbanColumn.tsx
|
|
238
|
+
- Adding new card fields → types.ts, CardModal.tsx
|
|
239
|
+
- Command configuration → CommandConfigModal.tsx, data/commands.json
|
|
240
|
+
- Health monitoring → HealthMonitor.tsx, /api/system-stats
|
|
241
|
+
- Connection issues → connection-manager.ts, ConnectionStatusIndicator.tsx
|
|
242
|
+
- Terminal panel behavior → ClaudeTerminalPanel.tsx
|
|
243
|
+
- Provider selection → ClaudeTerminalPanel.tsx, /api/providers, data/providers.json
|
|
244
|
+
- Provider detection for existing sessions → CardModal.tsx (session name parsing)
|
|
245
|
+
- Asset management → asset-scanner.ts, ToolkitTab.tsx, AssetMatrix.tsx
|
|
246
|
+
- Health scoring → health-score.ts, HealthDot.tsx
|
|
247
|
+
- Activity feed → event-log.ts, ActivityFeed.tsx
|
|
248
|
+
- Project scaffolding → AddProjectModal.tsx, /api/projects
|
|
249
|
+
- Search → SearchBar.tsx, /api/search
|
|
250
|
+
- Path resolution → paths.ts, kanban-paths.ts
|
|
251
|
+
- Keyboard shortcuts → useKeyboardShortcuts.ts
|
|
252
|
+
- Theme/design system → globals.css (texture classes), CardModal.tsx (stageModalStyles), KanbanColumn.tsx (colorClasses), GlobalClaudePanel.tsx (terminal header), Terminal.tsx (tintColor, terminal-texture)
|
|
@@ -0,0 +1,128 @@
|
|
|
1
|
+
# Maintenance Doctrine
|
|
2
|
+
|
|
3
|
+
Rules for maintaining context-priming references. Changes to this file require user approval.
|
|
4
|
+
|
|
5
|
+
## Area File Structure
|
|
6
|
+
|
|
7
|
+
Area files should be as lean as the area requires. Include sections that add value; omit those that don't.
|
|
8
|
+
|
|
9
|
+
**Always include:**
|
|
10
|
+
```markdown
|
|
11
|
+
# [Area Name]
|
|
12
|
+
|
|
13
|
+
Updated: YYYY-MM-DD
|
|
14
|
+
|
|
15
|
+
## Overview
|
|
16
|
+
What this area does, boundaries. 2-3 sentences.
|
|
17
|
+
|
|
18
|
+
## Key Files
|
|
19
|
+
- `file.py` - purpose
|
|
20
|
+
[Most important files/modules]
|
|
21
|
+
|
|
22
|
+
## When to Expand
|
|
23
|
+
- [task] → [files to open]
|
|
24
|
+
```
|
|
25
|
+
|
|
26
|
+
**Include when relevant:**
|
|
27
|
+
|
|
28
|
+
| Section | When to include |
|
|
29
|
+
|---------|-----------------|
|
|
30
|
+
| Key Functions | Area has important entry points, APIs, or non-obvious control flow |
|
|
31
|
+
| Data Models | Area defines data structures used internally or externally |
|
|
32
|
+
| Shared Objects | Area defines or consumes objects used across multiple areas |
|
|
33
|
+
| Patterns & Invariants | Area has critical rules that must hold |
|
|
34
|
+
| Interfaces | Area connects to other areas with data flow |
|
|
35
|
+
|
|
36
|
+
**Section formats (when used):**
|
|
37
|
+
|
|
38
|
+
```markdown
|
|
39
|
+
## Key Functions
|
|
40
|
+
- `process_message()` in handlers.py - entry point for incoming messages
|
|
41
|
+
|
|
42
|
+
## Data Models
|
|
43
|
+
- `Message` (models.py) - id, content, sender_id, timestamp | core envelope
|
|
44
|
+
|
|
45
|
+
## Shared Objects
|
|
46
|
+
- `Message` - DEFINED HERE, used by: frontend, api, workers
|
|
47
|
+
- `Config` - defined in core, IMPORTED HERE
|
|
48
|
+
|
|
49
|
+
## Patterns & Invariants
|
|
50
|
+
- Auth middleware runs before handlers
|
|
51
|
+
|
|
52
|
+
## Interfaces
|
|
53
|
+
- → frontend: sends Message via WebSocket
|
|
54
|
+
- ← api: receives Request, returns Response
|
|
55
|
+
```
|
|
56
|
+
|
|
57
|
+
Keep area files under 200 lines. Simple areas may be 20-30 lines; complex areas will be longer.
|
|
58
|
+
|
|
59
|
+
**Shared Objects note**: When present, prevents duplicate definitions. Mark canonical location.
|
|
60
|
+
|
|
61
|
+
## Defragmentation
|
|
62
|
+
|
|
63
|
+
**When to defrag an area:**
|
|
64
|
+
- Information is scattered/duplicated within the file
|
|
65
|
+
- Sections contain outdated content mixed with current
|
|
66
|
+
- File has grown beyond 200 lines
|
|
67
|
+
- Reading the file doesn't quickly answer "what do I need to know?"
|
|
68
|
+
|
|
69
|
+
**Defrag process:**
|
|
70
|
+
1. Read the entire area file
|
|
71
|
+
2. Identify: duplicates, outdated info, poor organization
|
|
72
|
+
3. Consolidate related information
|
|
73
|
+
4. Remove obsolete content (don't comment it out - delete)
|
|
74
|
+
5. Verify remaining content is accurate against current code
|
|
75
|
+
6. Update the `Updated` date
|
|
76
|
+
|
|
77
|
+
**Consult user before defragging if:**
|
|
78
|
+
- Multiple areas need simultaneous restructuring
|
|
79
|
+
- Unsure whether information is obsolete or still relevant
|
|
80
|
+
- Defrag would take significant time
|
|
81
|
+
|
|
82
|
+
## Area Separation
|
|
83
|
+
|
|
84
|
+
**Heuristics for deciding areas:**
|
|
85
|
+
- Group by logical module/subsystem, not by file type
|
|
86
|
+
- An area should be loadable and useful independently
|
|
87
|
+
- If two areas are always loaded together, consider merging
|
|
88
|
+
- If an area covers unrelated concerns, consider splitting
|
|
89
|
+
|
|
90
|
+
**When to split an area:**
|
|
91
|
+
- File exceeds 200 lines despite being concise
|
|
92
|
+
- Contains distinct subsystems that don't interact
|
|
93
|
+
- Load-when triggers have diverged (some tasks need part A, others need part B)
|
|
94
|
+
|
|
95
|
+
**When to merge areas:**
|
|
96
|
+
- Two areas are nearly always loaded together
|
|
97
|
+
- Combined size would still be under 150 lines
|
|
98
|
+
- Separation creates artificial boundaries
|
|
99
|
+
|
|
100
|
+
**Cross-references:**
|
|
101
|
+
- Areas can note "see also: [other-area]" for related context
|
|
102
|
+
- Don't auto-load chains - let the index's load-when guide loading
|
|
103
|
+
- If area A heavily depends on area B, note this in A's Interfaces section
|
|
104
|
+
|
|
105
|
+
## Note Pruning
|
|
106
|
+
|
|
107
|
+
Notes in area-index.md capture learnings. Prune when:
|
|
108
|
+
- Note contradicts newer information (keep newer)
|
|
109
|
+
- Code changed and note no longer applies
|
|
110
|
+
- Note is vague or not actionable
|
|
111
|
+
- Area exceeds 10 notes
|
|
112
|
+
|
|
113
|
+
**Pruning is lightweight** - remove stale notes during routine updates, don't treat as separate task.
|
|
114
|
+
|
|
115
|
+
## New Project Initialization
|
|
116
|
+
|
|
117
|
+
When skill is introduced to a new codebase:
|
|
118
|
+
|
|
119
|
+
1. Clear `areas/` directory
|
|
120
|
+
2. Reset area-index.md to template state
|
|
121
|
+
3. Keep SKILL.md and maintenance.md intact
|
|
122
|
+
4. Scan project structure:
|
|
123
|
+
- Look for obvious module boundaries (directories, packages)
|
|
124
|
+
- Check build configs (package.json, pyproject.toml, etc.)
|
|
125
|
+
- Read CLAUDE.md for existing documentation pointers
|
|
126
|
+
5. Propose 3-6 initial areas to user
|
|
127
|
+
6. After approval, create area files with initial discovery
|
|
128
|
+
7. Mark all as freshly created - validate through actual use
|
|
@@ -0,0 +1,141 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: design
|
|
3
|
+
version: 1.1.1
|
|
4
|
+
updated: 2026-02-22
|
|
5
|
+
allowed-tools: Read, Write, Edit, Bash, Glob, Grep, SlashCommand
|
|
6
|
+
argument-hint: "design topic (e.g., Session management system)"
|
|
7
|
+
description: "Start iterative requirements gathering for a design document"
|
|
8
|
+
---
|
|
9
|
+
|
|
10
|
+
# Design Discovery
|
|
11
|
+
|
|
12
|
+
Start an iterative requirements-gathering session for a new design. Creates a lightweight document in `documentation/designs/` focused on exploring the problem space, not implementation details.
|
|
13
|
+
|
|
14
|
+
## Mode: Requirements Gathering
|
|
15
|
+
|
|
16
|
+
This command sets you into **requirements mode**:
|
|
17
|
+
- Ask clarifying questions rather than making assumptions
|
|
18
|
+
- Explore alternatives and trade-offs with the user
|
|
19
|
+
- Focus on WHAT and WHY, not HOW
|
|
20
|
+
- Keep the document evolving as understanding grows
|
|
21
|
+
- No implementation details, no code, no file lists
|
|
22
|
+
|
|
23
|
+
## Instructions
|
|
24
|
+
|
|
25
|
+
1. **Create initial design doc** with the problem statement and open questions
|
|
26
|
+
2. **Enter conversational mode** - engage the user to flesh out requirements
|
|
27
|
+
3. **Update the doc iteratively** as decisions are made
|
|
28
|
+
4. **Flag when design is ready** to become a feature spec
|
|
29
|
+
|
|
30
|
+
## Workflow
|
|
31
|
+
|
|
32
|
+
1. **Get current date** using bash
|
|
33
|
+
2. **Create design document** in `documentation/designs/`
|
|
34
|
+
3. **Name the file** as `{descriptive_name}.md` (snake_case, no date prefix)
|
|
35
|
+
4. **Link design to card** - Run this command to attach the design doc to the kanban card:
|
|
36
|
+
```bash
|
|
37
|
+
node scripts/kanban.js update <card-id> --design-ref "documentation/designs/{name}.md"
|
|
38
|
+
```
|
|
39
|
+
**IMPORTANT:** This is a separate CLI command you must execute. Do NOT add the path to the card's description field. The `--design-ref` flag sets a dedicated field on the card that links to this design document.
|
|
40
|
+
5. **Engage user** with initial clarifying questions
|
|
41
|
+
6. **Update doc** as requirements solidify
|
|
42
|
+
|
|
43
|
+
## Document Format
|
|
44
|
+
|
|
45
|
+
```md
|
|
46
|
+
# Design: {topic}
|
|
47
|
+
|
|
48
|
+
**Status:** Discovery
|
|
49
|
+
**Created:** YYYY-MM-DD
|
|
50
|
+
**Last Updated:** YYYY-MM-DD
|
|
51
|
+
|
|
52
|
+
## Problem Statement
|
|
53
|
+
|
|
54
|
+
<What problem are we solving? Why does it matter? Who is affected?>
|
|
55
|
+
|
|
56
|
+
## Goals
|
|
57
|
+
|
|
58
|
+
<What must this solution achieve?>
|
|
59
|
+
1. <goal>
|
|
60
|
+
2. <goal>
|
|
61
|
+
|
|
62
|
+
## Non-Goals
|
|
63
|
+
|
|
64
|
+
<What is explicitly out of scope?>
|
|
65
|
+
- <non-goal>
|
|
66
|
+
|
|
67
|
+
## Context
|
|
68
|
+
|
|
69
|
+
<Background info, constraints, related systems>
|
|
70
|
+
|
|
71
|
+
## Approach Options
|
|
72
|
+
|
|
73
|
+
### Option A: <name>
|
|
74
|
+
<Description, pros, cons>
|
|
75
|
+
|
|
76
|
+
### Option B: <name>
|
|
77
|
+
<Description, pros, cons>
|
|
78
|
+
|
|
79
|
+
## Decisions
|
|
80
|
+
|
|
81
|
+
<Record decisions as they're made>
|
|
82
|
+
|
|
83
|
+
| Decision | Choice | Rationale |
|
|
84
|
+
|----------|--------|-----------|
|
|
85
|
+
| <topic> | <choice> | <why> |
|
|
86
|
+
|
|
87
|
+
## Open Questions
|
|
88
|
+
|
|
89
|
+
<Questions that need answers before implementation>
|
|
90
|
+
- [ ] <question>
|
|
91
|
+
- [ ] <question>
|
|
92
|
+
|
|
93
|
+
## Related Areas
|
|
94
|
+
|
|
95
|
+
<Context-priming areas relevant to this design>
|
|
96
|
+
- <area>: <why relevant>
|
|
97
|
+
|
|
98
|
+
## Notes
|
|
99
|
+
|
|
100
|
+
<Captured thoughts, references, examples>
|
|
101
|
+
```
|
|
102
|
+
|
|
103
|
+
## Conversational Guidelines
|
|
104
|
+
|
|
105
|
+
When in design mode:
|
|
106
|
+
|
|
107
|
+
1. **Start with questions** - Don't assume you understand the problem
|
|
108
|
+
- "What problem are you trying to solve?"
|
|
109
|
+
- "Who will use this? In what context?"
|
|
110
|
+
- "What constraints should I know about?"
|
|
111
|
+
|
|
112
|
+
2. **Present options** - When there are multiple approaches
|
|
113
|
+
- "I see two main ways to approach this..."
|
|
114
|
+
- "Option A trades X for Y, Option B does the opposite..."
|
|
115
|
+
|
|
116
|
+
3. **Capture decisions** - When the user makes a choice
|
|
117
|
+
- Update the Decisions table with rationale
|
|
118
|
+
- Remove resolved items from Open Questions
|
|
119
|
+
|
|
120
|
+
4. **Check readiness** - When requirements feel complete
|
|
121
|
+
- "I think we've covered the requirements. Ready to create a feature spec?"
|
|
122
|
+
- If yes: "Run `/feature {design name}` to create the implementation plan"
|
|
123
|
+
|
|
124
|
+
## Transition to Feature Spec
|
|
125
|
+
|
|
126
|
+
When the design is ready for implementation:
|
|
127
|
+
1. Update Status to "Ready"
|
|
128
|
+
2. Inform user to run `/feature` referencing this design
|
|
129
|
+
3. The feature spec will link back via `design_ref`
|
|
130
|
+
|
|
131
|
+
## Reporting
|
|
132
|
+
|
|
133
|
+
After creating the initial document:
|
|
134
|
+
- File created: `documentation/designs/{name}.md`
|
|
135
|
+
- Card linked: (if in card session) design_ref updated
|
|
136
|
+
- Status: Discovery
|
|
137
|
+
- Mode: Requirements gathering active
|
|
138
|
+
- First question: Start exploring the problem space
|
|
139
|
+
|
|
140
|
+
## Design Topic
|
|
141
|
+
$ARGUMENTS
|
|
@@ -0,0 +1,159 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: feature
|
|
3
|
+
version: 1.1.1
|
|
4
|
+
updated: 2026-02-22
|
|
5
|
+
allowed-tools: Read, Write, Edit, Bash, Glob, Grep, SlashCommand
|
|
6
|
+
argument-hint: "feature description (e.g., Add bulk message operations)"
|
|
7
|
+
description: "Create a numbered feature specification following project standards"
|
|
8
|
+
---
|
|
9
|
+
|
|
10
|
+
# Feature Planning
|
|
11
|
+
|
|
12
|
+
Create a new feature specification in `documentation/features/` with the next available number. The plan will follow a comprehensive feature planning format.
|
|
13
|
+
|
|
14
|
+
## Instructions
|
|
15
|
+
|
|
16
|
+
1. **Scan for next feature number** - Check existing features to determine next number
|
|
17
|
+
2. **Check project context** - If you need more context about specific areas:
|
|
18
|
+
- Review relevant project documentation (if available: `/prime <area>` or CLAUDE.md)
|
|
19
|
+
- Identify key architectural areas the feature touches
|
|
20
|
+
3. **Research the codebase** to understand existing patterns and architecture
|
|
21
|
+
4. **Create comprehensive plan** following the format below
|
|
22
|
+
5. **Name the file** as `{number}_{feature_name}.md` (e.g., `038_bulk_message_operations.md`)
|
|
23
|
+
|
|
24
|
+
## Workflow
|
|
25
|
+
|
|
26
|
+
1. **Determine next feature number**:
|
|
27
|
+
- List files in `documentation/features/`
|
|
28
|
+
- Find highest numbered feature
|
|
29
|
+
- Next number = highest + 1
|
|
30
|
+
2. **Analyze feature requirements** from description
|
|
31
|
+
3. **Check if sufficient context** is loaded for the feature
|
|
32
|
+
4. **Create the plan** in `documentation/features/` directory
|
|
33
|
+
5. **Link feature to card** - Run this command to attach the feature spec to the kanban card:
|
|
34
|
+
```bash
|
|
35
|
+
node scripts/kanban.js update <card-id> --feature-ref "documentation/features/{number}_{name}.md"
|
|
36
|
+
```
|
|
37
|
+
**IMPORTANT:** This is a separate CLI command you must execute. Do NOT add the path to the card's description field. The `--feature-ref` flag sets a dedicated field on the card that links to this feature spec.
|
|
38
|
+
|
|
39
|
+
## Context Integration
|
|
40
|
+
|
|
41
|
+
Before creating the plan:
|
|
42
|
+
- Identify which project areas/modules the feature touches
|
|
43
|
+
- Check if sufficient context exists (project docs, CLAUDE.md, architecture files)
|
|
44
|
+
- If needed, suggest: "This feature involves {areas}. Consider reviewing {relevant docs} for better context."
|
|
45
|
+
|
|
46
|
+
## Plan Format
|
|
47
|
+
|
|
48
|
+
```md
|
|
49
|
+
# Feature {number}: {feature name}
|
|
50
|
+
|
|
51
|
+
**Status**: DRAFT
|
|
52
|
+
**Created**: YYYY-MM-DD
|
|
53
|
+
**Last Updated**: YYYY-MM-DD
|
|
54
|
+
|
|
55
|
+
## Feature Description
|
|
56
|
+
<describe the feature in detail, including its purpose and value to users>
|
|
57
|
+
|
|
58
|
+
## User Story
|
|
59
|
+
As a <type of user>
|
|
60
|
+
I want to <action/goal>
|
|
61
|
+
So that <benefit/value>
|
|
62
|
+
|
|
63
|
+
## Problem Statement
|
|
64
|
+
<clearly define the specific problem or opportunity this feature addresses>
|
|
65
|
+
|
|
66
|
+
## Solution Statement
|
|
67
|
+
<describe the proposed solution approach and how it solves the problem>
|
|
68
|
+
|
|
69
|
+
## Context Areas
|
|
70
|
+
<note which project areas/modules are relevant to this feature>
|
|
71
|
+
- Required areas: [list areas like frontend, backend, api, database, etc.]
|
|
72
|
+
- Additional context: [reference relevant documentation or architecture files]
|
|
73
|
+
|
|
74
|
+
## Relevant Files
|
|
75
|
+
Use these files to implement the feature:
|
|
76
|
+
|
|
77
|
+
<find and list the files that are relevant to the feature describe why they are relevant in bullet points. Reference patterns from CLAUDE.md and project documentation.>
|
|
78
|
+
|
|
79
|
+
### New Files
|
|
80
|
+
<if any new files need to be created, list them here following project conventions>
|
|
81
|
+
|
|
82
|
+
## Implementation Plan
|
|
83
|
+
### Phase 1: Foundation
|
|
84
|
+
<describe the foundational work needed before implementing the main feature>
|
|
85
|
+
|
|
86
|
+
### Phase 2: Core Implementation
|
|
87
|
+
<describe the main implementation work for the feature>
|
|
88
|
+
|
|
89
|
+
### Phase 3: Integration
|
|
90
|
+
<describe how the feature will integrate with existing functionality>
|
|
91
|
+
|
|
92
|
+
## Step by Step Tasks
|
|
93
|
+
IMPORTANT: Execute every step in order, top to bottom.
|
|
94
|
+
|
|
95
|
+
<list step by step tasks as h3 headers plus bullet points. Reference project patterns from CLAUDE.md and documentation.>
|
|
96
|
+
|
|
97
|
+
### Task 1: <descriptive name>
|
|
98
|
+
- <specific actions following project conventions>
|
|
99
|
+
- <file modifications>
|
|
100
|
+
|
|
101
|
+
### Task 2: <descriptive name>
|
|
102
|
+
- <specific actions>
|
|
103
|
+
- <file modifications>
|
|
104
|
+
|
|
105
|
+
### Task N: Run Full Validation
|
|
106
|
+
- Execute all validation commands
|
|
107
|
+
- Verify feature works end-to-end
|
|
108
|
+
- Check for regressions
|
|
109
|
+
|
|
110
|
+
## Testing Strategy
|
|
111
|
+
### Unit Tests
|
|
112
|
+
<describe unit tests needed following project test standards>
|
|
113
|
+
|
|
114
|
+
### Integration Tests
|
|
115
|
+
<describe integration tests needed>
|
|
116
|
+
|
|
117
|
+
### E2E Tests
|
|
118
|
+
<if applicable, describe end-to-end tests>
|
|
119
|
+
|
|
120
|
+
### Edge Cases
|
|
121
|
+
<list edge cases that need to be tested>
|
|
122
|
+
|
|
123
|
+
## Acceptance Criteria
|
|
124
|
+
<list specific, measurable criteria that must be met for the feature to be considered complete>
|
|
125
|
+
- [ ] Feature works as described
|
|
126
|
+
- [ ] All tests pass
|
|
127
|
+
- [ ] No regressions introduced
|
|
128
|
+
- [ ] Documentation updated
|
|
129
|
+
- [ ] <specific criteria for this feature>
|
|
130
|
+
|
|
131
|
+
## Validation Commands
|
|
132
|
+
Execute every command to validate the feature works correctly with zero regressions.
|
|
133
|
+
|
|
134
|
+
<list project-specific validation commands - examples:>
|
|
135
|
+
- Run test suite (e.g., `pytest`, `npm test`, `make test`)
|
|
136
|
+
- Run linters (e.g., `npm run lint`, `flake8`, `eslint`)
|
|
137
|
+
- Run type checking (e.g., `mypy`, `tsc --noEmit`)
|
|
138
|
+
- Build the project (e.g., `npm run build`, `make build`)
|
|
139
|
+
- Manual testing steps
|
|
140
|
+
- <specific tests for this feature>
|
|
141
|
+
|
|
142
|
+
## Future Considerations
|
|
143
|
+
<optional: future enhancements or related features to consider>
|
|
144
|
+
|
|
145
|
+
## Notes
|
|
146
|
+
<optionally list any additional notes, dependencies, or context that are relevant to the feature>
|
|
147
|
+
```
|
|
148
|
+
|
|
149
|
+
## Reporting
|
|
150
|
+
|
|
151
|
+
After creating the plan, report:
|
|
152
|
+
- File created: `documentation/features/{number}_{feature_name}.md`
|
|
153
|
+
- Card linked: feature_ref updated via CLI command
|
|
154
|
+
- Feature number: {number}
|
|
155
|
+
- Status: DRAFT
|
|
156
|
+
- Next step: Run `/implement` with the plan path when ready
|
|
157
|
+
|
|
158
|
+
## Feature
|
|
159
|
+
$ARGUMENTS
|