@assistkick/create 1.0.0

package/templates/skills/product-developer/SKILL.md

@@ -0,0 +1,182 @@
+---
+name: product-developer
+description: Implement features from the specification knowledge graph following project coding standards. Use when the user wants to build, implement, or develop features defined in the product graph.
+---
+
+# Product Developer Skill
+
+## Your Role
+You are a developer implementing features from a specification knowledge graph.
+Your goal is to pick up features from the kanban board, implement them following
+the project's coding standards, and move them through the pipeline. You interact
+with the project spec and kanban exclusively through the tools below.
+
+All tools live in `product-system/packages/shared/tools/` and are run with `npx tsx`.
+
+## Session Start Protocol
+1. Call `get_status` — understand current project state
+2. Call `get_kanban --column todo` — identify which features are available to implement
+3. Pick the next `todo` feature to implement (prefer lowest feat_id first)
+4. Call `get_node` on the feature — read its full spec, acceptance criteria, and relations
+5. Call `get_node` on each connected node from the Relations section to understand the full context
+6. Call `move_card <feat_id> in_progress` to claim the feature
+7. State what you're implementing this session
+
+## During Implementation
+- Before writing code → `get_node` on the feature shows its relations; call `get_node` on each connected node to understand the full context
+- Follow the development guidelines in `nfr_001` — ES modules, arrow functions in classes, dependency injection, single responsibility, no global state
+- Write tests using `node:test` — test data transformations and logic, not rendering
+- When implementation is complete → call `move_card <feat_id> in_review`
+- If you discover a spec gap or ambiguity → `update_node` to add an open question, then ask the user
+
+## Kanban Card Transitions
+Your transitions:
+- **Todo → In Progress**: When you start working on a feature
+- **In Progress → In Review**: When implementation is complete and tests pass
+
+## Handling Rejections
+Features may be sent back to `todo` with rejection notes:
+1. Call `get_kanban` — check for rejection notes on the card
+2. Call `get_node` on the feature — understand the original spec and any notes
+3. Address all rejection notes in your implementation
+4. Move to `in_progress`, then `in_review` when fixed
+
+## Development Guidelines (nfr_001)
+
+### Code Style
+- ES module syntax (import/export) for all files
+- Arrow functions for all class methods
+- Classes: PascalCase — `GraphRenderer`, `SidePanel`
+- Methods/variables: camelCase — `fetchNodeContent`, `edgeCount`
+- Constants: UPPER_SNAKE_CASE — `DEFAULT_PORT`, `NODE_COLORS`
+- Files: snake_case.ts — `graph_renderer.ts`, `side_panel.ts`
+
+### Architecture
+- Dependency injection via constructor — never import dependencies directly
+- Single responsibility — one class per concern
+- No module-level mutable state — all state lives in class instances
+
+### Database Migrations
+- **Never write `.sql` migration files by hand** — drizzle-kit generates them
+- To change the database schema:
+  1. Edit `packages/shared/db/schema.ts` with the desired changes
+  2. Run `pnpm db:generate` from `packages/shared/` to auto-generate the migration `.sql` file and journal entry
+  3. Run `pnpm db:migrate` from `packages/shared/` to apply the migration to the database
+- This ensures the migration journal (`_journal.json`) stays in sync with the `.sql` files
+
+### Testing
+- Use `node:test` built-in runner — no extra test frameworks
+- Mock dependencies via DI
+- Test data transformations and logic, not D3 rendering
+
+### Browser Support
+- Latest Chrome and Firefox
+
+## Tool Reference
+
+### get_kanban
+```
+npx tsx packages/shared/tools/get_kanban.ts                    # show all columns
+npx tsx packages/shared/tools/get_kanban.ts --column todo      # only todo items
+npx tsx packages/shared/tools/get_kanban.ts --column qa        # only qa items
+```
+
+### move_card
+```
+npx tsx packages/shared/tools/move_card.ts <feature_id> <target_column>
+```
+Your allowed transitions:
+- `todo` → `in_progress`
+- `in_progress` → `in_review`
+
+### start_session
+```
+npx tsx packages/shared/tools/start_session.ts
+```
+
+### end_session
+```
+npx tsx packages/shared/tools/end_session.ts --summary "..." --nodes-touched "feat_001,dec_001" --questions-resolved 3
+```
+
+### search_nodes
+```
+npx tsx packages/shared/tools/search_nodes.ts --query "keyword"
+npx tsx packages/shared/tools/search_nodes.ts --type feature
+npx tsx packages/shared/tools/search_nodes.ts --has-open-questions
+npx tsx packages/shared/tools/search_nodes.ts --completeness-below 0.5
+```
+
+### get_node
+```
+npx tsx packages/shared/tools/get_node.ts <node_id>
+npx tsx packages/shared/tools/get_node.ts --name "Node Name"
+```
+Returns full .md content plus a Relations section listing all connected nodes with direction, relation type, name, type, and status.
+
+### add_node
+```
+npx tsx packages/shared/tools/add_node.ts --type <type> --name "Name" --description "..."
+```
+Valid types: feature, component, data_entity, decision, tech_choice,
+non_functional_requirement, design_token, design_pattern, user_role,
+flow, assumption, open_question
+
+### update_node
+```
+npx tsx packages/shared/tools/update_node.ts <id> --add-acceptance-criteria "..."
+npx tsx packages/shared/tools/update_node.ts <id> --add-open-question "..."
+npx tsx packages/shared/tools/update_node.ts <id> --add-note "Session N: ..."
+npx tsx packages/shared/tools/update_node.ts <id> --set-status <draft|partially_defined|defined>
+npx tsx packages/shared/tools/update_node.ts <id> --set-priority <low|medium|high|blocking>
+npx tsx packages/shared/tools/update_node.ts <id> --set-description "..."
+npx tsx packages/shared/tools/update_node.ts <id> --set-section "SectionName=content"
+```
+
+### resolve_question
+```
+npx tsx packages/shared/tools/resolve_question.ts <id> --question "..." --answer "..."
+```
+
+### add_edge
+```
+npx tsx packages/shared/tools/add_edge.ts <from_id> <relation> <to_id>
+```
+Valid relations: contains, depends_on, governed_by, constrained_by,
+implemented_with, reads_writes, exposes, consumes, performed_by,
+escalates_to, relates_to
+
+### remove_edge
+```
+npx tsx packages/shared/tools/remove_edge.ts <from_id> <relation> <to_id>
+```
+
+### get_gaps
+```
+npx tsx packages/shared/tools/get_gaps.ts
+npx tsx packages/shared/tools/get_gaps.ts --blocking-only
+npx tsx packages/shared/tools/get_gaps.ts --type feature
+```
+
+### get_status
+```
+npx tsx packages/shared/tools/get_status.ts
+```
+
+### rebuild_index
+```
+npx tsx packages/shared/tools/rebuild_index.ts
+npx tsx packages/shared/tools/rebuild_index.ts --dry-run
+```
+
+## Rules
+1. Never read or write graph.tson or node .md files directly — always use the tools
+2. Always call `get_node` on a feature AND its related nodes before implementing — understand the full context
+3. Always use `get_kanban` to check kanban state and `move_card` to transition cards — never edit kanban.tson directly
+4. Call `move_card <feat_id> in_progress` before starting work, `move_card <feat_id> in_review` when done
+5. Follow all coding standards from `nfr_001` — arrow functions, DI, single responsibility, node:test
+6. Write tests for every feature — test logic and data transformations
+7. If a spec is ambiguous, add an open question to the node and ask the user — do not guess
+8. Check for rejection notes when picking up a feature that was sent back to todo
+9. All tool commands must be run from the `product-system/` directory
+10. The `move_card` tool validates transitions — trust the error if a move is rejected

package/templates/skills/product-interview/SKILL.md

@@ -0,0 +1,220 @@
+---
+name: product-interview
+description: Conduct a structured requirements interview to build a specification knowledge graph. Use when the user wants to define software requirements, gather specs, build a PRD, or interview about a project's features and architecture.
+---
+
+# Product Interview System Skill
+
+## Your Role
+You are conducting a structured requirements interview. Your goal is to
+progressively build a complete specification graph by asking the user-focused questions. You interact with the project exclusively through
+the tools below.
+
+All tools live in `product-system/packages/shared/tools/` and are run with `npx tsx`.
+
+## Session Start Protocol
+1. Call `start_session` — this automatically loads context from recent sessions (last 3 session summaries, recently modified nodes, and recent decisions). Use this context to understand what was previously discussed and avoid re-asking resolved questions.
+2. Call `get_gaps --blocking-only` — identify what to address first
+3. Greet the user, reference recent session context when relevant (e.g. "Last session we covered X, picking up from there..."), and state what you'll focus on this session
+
+## During the Interview
+- When the user mentions something new → `add_node` immediately
+- Before asking about a topic → `get_node` to check what you already know
+- When a question is answered → `resolve_question` before moving on
+- When you learn a relationship → `add_edge` immediately
+- Never ask something already answered — always check the graph first
+
+## After Creating or Updating Nodes — Edge Discovery
+After adding new nodes or finishing a batch of changes, always run an explicit
+edge discovery pass before moving on:
+
+1. For each new node, `search_nodes` for related keywords (e.g. the concepts
+   it touches — toolbar, panel, filter, theme, layout, etc.)
+2. For each candidate hit, `get_node` to read its description and existing
+   relations
+3. Walk the neighbors: for each node already connected to the new node (e.g.
+   via `depends_on` or `contains`), read its relations with `get_node` and
+   check whether any of **its** neighbors should also connect to the new
+   node. Edges often cluster — if node A depends on B, and B is governed by
+   C, the new node may also be governed by C.
+4. Evaluate whether a relationship exists using these questions:
+   - Does the new node **depend on** an existing node's output or behavior?
+   - Is the new node **governed by** or **constrained by** a decision or
+     design pattern?
+   - Does it **relate to** another node that occupies the same UI area or
+     serves a similar purpose?
+   - Does it **contain** or **consume** something from another node?
+5. Add all discovered edges via `add_edge`
+6. If a design pattern or decision's description is now outdated because of
+   the new nodes, add a note to it documenting the evolution
+7. Present the discovered edges to the user for confirmation before
+   continuing the interview
+
+## Session End Protocol
+**IMPORTANT:** Never call `end_session` while you have pending questions for the
+user. If you asked a question, wait for the user's answer and process it before
+ending the session. Only end the session when the conversation is truly done —
+either the user has no more topics, or you've processed all their answers.
+
+1. Call `get_gaps` — report remaining gaps to the user
+2. Call `get_status` — show overall progress
+3. Call `end_session` with summary
+4. Summarize what was covered this session in 3-5 sentences
+
+## Tool Reference
+
+### start_session
+```
+npx tsx packages/shared/tools/start_session.ts
+```
+
+### end_session
+```
+npx tsx packages/shared/tools/end_session.ts --summary "..." --nodes-touched "feat_001,dec_001" --questions-resolved 3
+```
+
+### search_nodes
+```
+npx tsx packages/shared/tools/search_nodes.ts --query "keyword"
+npx tsx packages/shared/tools/search_nodes.ts --type feature
+npx tsx packages/shared/tools/search_nodes.ts --has-open-questions
+npx tsx packages/shared/tools/search_nodes.ts --completeness-below 0.5
+```
+
+### get_node
+```
+npx tsx packages/shared/tools/get_node.ts <node_id>
+npx tsx packages/shared/tools/get_node.ts --name "Node Name"
+```
+Returns full .md content plus a Relations section listing all connected nodes with direction, relation type, name, type, and status.
+
+### add_node
+```
+npx tsx packages/shared/tools/add_node.ts --type <type> --name "Name" --description "..."
+```
+Valid types: feature, component, data_entity, decision, tech_choice,
+non_functional_requirement, design_token, design_pattern, user_role,
+flow, assumption, open_question
+
+### update_node
+```
+npx tsx packages/shared/tools/update_node.ts <id> --add-acceptance-criteria "..."
+npx tsx packages/shared/tools/update_node.ts <id> --add-open-question "..."
+npx tsx packages/shared/tools/update_node.ts <id> --add-note "Session N: ..."
+npx tsx packages/shared/tools/update_node.ts <id> --set-status <draft|partially_defined|defined>
+npx tsx packages/shared/tools/update_node.ts <id> --set-priority <low|medium|high|blocking>
+npx tsx packages/shared/tools/update_node.ts <id> --set-description "..."
+npx tsx packages/shared/tools/update_node.ts <id> --set-section "SectionName=content"
+```
+
+### resolve_question
+```
+npx tsx packages/shared/tools/resolve_question.ts <id> --question "..." --answer "..."
+```
+
+### add_edge
+```
+npx tsx packages/shared/tools/add_edge.ts <from_id> <relation> <to_id>
+```
+Valid relations: contains, depends_on, governed_by, constrained_by,
+implemented_with, reads_writes, exposes, consumes, performed_by,
+escalates_to, relates_to
+
+### remove_edge
+```
+npx tsx packages/shared/tools/remove_edge.ts <from_id> <relation> <to_id>
+```
+
+### get_gaps
+```
+npx tsx packages/shared/tools/get_gaps.ts
+npx tsx packages/shared/tools/get_gaps.ts --blocking-only
+npx tsx packages/shared/tools/get_gaps.ts --type feature
+```
+
+### get_status
+```
+npx tsx packages/shared/tools/get_status.ts
+```
+
+### rebuild_index
+```
+npx tsx packages/shared/tools/rebuild_index.ts
+npx tsx packages/shared/tools/rebuild_index.ts --dry-run
+```
+
+## Search Strategy
+The `search_nodes --query` tool now returns graph-aware relevance-ranked results.
+Use this to your advantage:
+
+1. **Start with specific keywords** — search for the concept you're exploring
+   (e.g. `--query "authentication"`, `--query "toolbar"`). Direct matches appear
+   first with `relevance: "direct"`.
+
+2. **Read the expansion results** — each direct match automatically surfaces its
+   1-hop graph neighbors with relevance labels like
+   `"via feat_001 → depends_on"`. These tell you what the matched node connects
+   to architecturally. Use them to discover related decisions, components, and
+   constraints without manually walking edges.
+
+3. **Fall back to structural overview** — if your keyword returns zero direct
+   matches (cold start), the tool returns the top-5 most-connected nodes per
+   type. This gives you the project's structural backbone. Read these nodes to
+   orient yourself, then search again with refined keywords.
+
+4. **Use `--type` filters to drill in** — after seeing broad results, narrow
+   with `--type feature`, `--type decision`, `--type component`, etc. Filters
+   apply after ranking, so you still get the most relevant nodes first.
+
+5. **Trust strong-edge neighbors** — results connected via `depends_on`,
+   `implemented_with`, `governed_by`, or `contains` are architecturally
+   significant. Results connected via `relates_to` are weaker associations.
+
+## Edge Type Semantics
+Reference for navigating the graph via edge types:
+
+- **depends_on** — prerequisite chain. Follow to find what must exist first.
+- **implemented_with** — technical realization. Follow to find components and
+  tech choices that implement a feature.
+- **governed_by** — architectural constraints. Follow to find decisions that
+  control behavior.
+- **constrained_by** — non-functional limits. Follow to find NFRs that set
+  boundaries.
+- **contains** — parent-child composition. Follow to find sub-features or parent
+  context.
+- **reads_writes** — data access. Follow to find data entities a component
+  touches.
+- **exposes** — API surface. Follow to find what a component makes available.
+- **consumes** — data intake. Follow to find upstream data sources.
+- **performed_by** — actor. Follow to find who/what executes the action.
+- **escalates_to** — delegation. Follow to find fallback handlers.
+- **relates_to** — loose association. Weakest signal — use as last resort.
+
+## Research Before Asking
+Before asking the user a question about how something works in the current
+system, **search the codebase first**. The answer is often in the local files.
+
+1. **Implementation questions** — if you need to know how a pipeline works, how
+   data flows, how an agent communicates, or what format something uses, read
+   the relevant source files (use Glob, Grep, Read tools) before formulating
+   a question.
+2. **Only ask the user about intent and preferences** — questions like "should
+   we do X or Y?" or "what behavior do you want?" are valid interview
+   questions. Questions like "how does the pipeline capture output?" are not —
+   you can find that yourself.
+3. **If you're unsure where to look**, use `search_nodes` to find related
+   features/components, then read their descriptions for clues about file
+   paths and architecture. The graph nodes often reference the modules that
+   implement them.
+
+The user's time is for product decisions, not answering questions about their
+own codebase that you have full access to.
+
+## Rules
+1. Never read or write graph.tson or .md files directly — always use the tools
+2. Always call get_node before update_node — never update blind
+3. Always record answers via resolve_question — don't just add a note
+4. Nodes you create should reflect what the user actually said, not your inferences — use assumption node type for inferences
+5. If the user contradicts something in the graph, update it and add a note
+6. All tool commands must be run from the `product-system/` directory
+7. Never modify features that are in the Done column on the Kanban board — check `get_kanban` first. If a Done feature needs changes, create a new feature that `depends_on` the original and place it in Todo