fix: rewrite skills to follow skill-creator standard

Changes:
- Remove user-invocable field from all skills
- Add clear trigger keywords in descriptions
- Trim content to be more concise
- Add explicit MCP tool usage examples

Skills fixed:
- sidstack-aware: clearer task management triggers
- sidstack-impact-safe: trimmed, focused
- sidstack-knowledge-first: trimmed, focused
- sidstack-lesson-detector: trimmed examples
- sidstack-training-context: trimmed examples

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Author: Dchuong03

packages/cli/templates/skills/sidstack/sidstack-aware/SKILL.md

@@ -1,44 +1,54 @@
 ---
 name: sidstack-aware
-description: Use SidStack MCP tools for project management. Automatically apply when working on code changes, tasks, or needing project context.
-user-invocable: false
+description: >
+  Use SidStack MCP tools for project management. Trigger when: (1) user asks to
+  "check task", "list tasks", or mentions "task" (use task_list), (2) user asks to
+  create/add/implement feature (use task_create), (3) working on code changes (use
+  task_update with progress), (4) completing work (use task_complete).
 ---
 
-# SidStack Integration
-
-You have access to SidStack MCP tools. Use them when appropriate:
+# SidStack MCP Tools
 
 ## Task Management
 
-- `task_list({projectId, preset: "actionable"})` — see current work
-- `task_create({title, description, projectId})` — track new work
-- `task_update({taskId, progress, status})` — report progress at milestones (30%, 60%, 90%)
-- `task_complete({taskId})` — finish with quality gate check
+| Action | Tool | Example |
+|--------|------|---------|
+| Check tasks | `task_list({projectId: "folder-name"})` | "check task", "what tasks" |
+| Create task | `task_create({projectId, title, description})` | "implement X", "add feature" |
+| Update progress | `task_update({taskId, progress: 50})` | During implementation |
+| Complete | `task_complete({taskId})` | After finishing work |
 
 ## Knowledge
 
-- `knowledge_search({projectPath, query})` — find patterns, decisions, business logic
-- `knowledge_context({projectPath, moduleId})` — get context for a module
+| Action | Tool | When |
+|--------|------|------|
+| Search | `knowledge_search({projectPath: ".", query})` | Before implementing |
+| Context | `knowledge_context({projectPath: ".", moduleId})` | Understanding module |
 
 ## Impact Analysis
 
-- `impact_analyze({description})` — assess risk before significant changes
-- `impact_check_gate({analysisId})` — check if safe to proceed
+| Action | Tool | When |
+|--------|------|------|
+| Analyze | `impact_analyze({description})` | Before risky changes |
+| Check gate | `impact_check_gate({analysisId})` | After analysis |
+
+## Quick Reference
 
-## When to Use
+```
+# User says "check task" or "list tasks"
+task_list({ projectId: "project-folder-name" })
 
-- **Starting implementation?** → `knowledge_search` first to find existing patterns
-- **Changing core modules?** → `impact_analyze` first to assess risk
-- **Working on task?** → `task_update(progress)` at milestones
-- **Completing work?** → `task_complete` to run quality gates
+# User wants to implement something
+task_create({
+  projectId: "project-folder-name",
+  title: "[feature] Description",
+  description: "What and why",
+  taskType: "feature"
+})
 
-## Tool Reference
+# During work - update progress
+task_update({ taskId: "xxx", progress: 50, status: "in_progress" })
 
-| Category | Tools |
-|----------|-------|
-| Tasks | `task_list`, `task_create`, `task_update`, `task_complete`, `task_get` |
-| Knowledge | `knowledge_list`, `knowledge_get`, `knowledge_search`, `knowledge_context` |
-| Impact | `impact_analyze`, `impact_check_gate`, `impact_list` |
-| Tickets | `ticket_list`, `ticket_create`, `ticket_update`, `ticket_convert_to_task` |
-| Training | `lesson_create`, `skill_create`, `rule_check` |
-| Sessions | `session_launch` |
+# Done - complete task
+task_complete({ taskId: "xxx" })
+```

packages/cli/templates/skills/sidstack/sidstack-impact-safe/SKILL.md

@@ -1,72 +1,43 @@
 ---
 name: sidstack-impact-safe
-description: Run impact analysis before modifying core modules, APIs, or database schemas.
-user-invocable: false
+description: >
+  Run impact analysis before risky changes. Trigger when: modifying core modules
+  (shared, database, auth), changing APIs or schemas, touching security code,
+  or affecting multiple modules. Use impact_analyze then impact_check_gate.
 ---
 
 # Impact-Safe Changes
 
-Before modifying critical code, run impact analysis to understand risks and dependencies.
+## When to Run Impact Analysis
 
-## When to Apply
-
-Run `impact_analyze` before touching:
-
-- **Core modules**: packages/shared, src-tauri, database
-- **APIs**: Route handlers, request/response schemas
-- **Database**: Schema changes, migrations
-- **Security**: Authentication, authorization, encryption
-- **Integrations**: External services, MCP tools
+- Modifying core modules (database, auth, shared)
+- Changing API routes or response schemas
+- Database schema changes or migrations
+- Security-related code (auth, encryption)
+- Changes affecting 3+ files across modules
 
 ## Process
 
-### Step 1: Analyze Impact
+### 1. Analyze
 
 ```
 impact_analyze({
   description: "What you're changing and why",
-  targetModules: ["affected-module-1", "affected-module-2"],
-  changeType: "feature" | "refactor" | "bugfix" | "migration" | "deletion"
+  targetModules: ["module1", "module2"],
+  changeType: "feature" | "refactor" | "bugfix" | "migration"
 })
 ```
 
-### Step 2: Check Gate Status
+### 2. Check Gate
 
 ```
-impact_check_gate({
-  analysisId: "from-step-1"
-})
+impact_check_gate({ analysisId: "from-step-1" })
 ```
 
-### Step 3: Interpret Results
-
-| Status | Meaning | Action |
-|--------|---------|--------|
-| `clear` | Safe to proceed | Continue with implementation |
-| `warning` | Caution needed | Review risks, proceed carefully |
-| `blocked` | High risk | Address blockers before proceeding |
-
-## Risk Indicators
-
-**High Risk:**
-- Breaking API changes
-- Database schema modifications
-- Security-sensitive code changes
-- Multiple modules affected
-
-**Medium Risk:**
-- Internal API changes
-- Adding new dependencies
-- Modifying shared utilities
-
-**Low Risk:**
-- Isolated bug fixes
-- Documentation updates
-- Test additions
-
-## Best Practices
+### 3. Interpret
 
-1. **Always analyze before implementing** risky changes
-2. **Document the analysis** in your commit message
-3. **If blocked**, create tasks to address blockers first
-4. **If warning**, add extra tests for affected areas
+| Status | Action |
+|--------|--------|
+| `clear` | Safe to proceed |
+| `warning` | Proceed with extra care |
+| `blocked` | Fix blockers first |

packages/cli/templates/skills/sidstack/sidstack-knowledge-first/SKILL.md

@@ -1,24 +1,23 @@
 ---
 name: sidstack-knowledge-first
-description: Search SidStack knowledge before implementing features or making architectural decisions.
-user-invocable: false
+description: >
+  Search project knowledge before implementing. Trigger when: starting a new
+  feature, making architectural decisions, working in unfamiliar code, or
+  modifying business logic. Use knowledge_search and knowledge_context.
 ---
 
 # Knowledge-First Development
 
-Before implementing features or making architectural decisions, search existing knowledge to ensure consistency with the codebase.
+## When to Search Knowledge
 
-## When to Apply
-
-- Implementing a new feature
+- Starting a new feature implementation
 - Making architectural decisions
-- Modifying business logic
-- Changing data models or APIs
-- Working in unfamiliar parts of the codebase
+- Working in unfamiliar modules
+- Changing business logic or data models
 
 ## Process
 
-### Step 1: Search for Existing Patterns
+### 1. Search for Patterns
 
 ```
 knowledge_search({
@@ -27,15 +26,7 @@ knowledge_search({
 })
 ```
 
-Look for:
-- Similar implementations
-- Design patterns used
-- Business rules documented
-- API conventions
-
-### Step 2: Get Module Context
-
-If working in a specific module:
+### 2. Get Module Context
 
 ```
 knowledge_context({
@@ -44,31 +35,10 @@ knowledge_context({
 })
 ```
 
-This provides:
-- Module overview and purpose
-- Related documentation
-- Dependencies and relationships
-- Known constraints
-
-### Step 3: Check for Related Decisions
-
-Search for architectural decisions:
+## What to Look For
 
-```
-knowledge_search({
-  projectPath: ".",
-  query: "decision architecture"
-})
-```
-
-Look in:
-- `.sidstack/knowledge/` for documented patterns
-- `openspec/` for change proposals
-- `docs/` for technical documentation
-
-## Benefits
-
-- **Consistency**: Follow established patterns
-- **Efficiency**: Don't reinvent existing solutions
-- **Quality**: Build on proven approaches
-- **Context**: Understand why things are the way they are
+- Similar implementations
+- Design patterns used
+- Business rules
+- API conventions
+- Known constraints