superkit-mcp-server 1.2.1 → 1.2.3

package/skills/workflows/doc.md

@@ -1,95 +1,95 @@
----
-description: Update folder-level documentation and component changelogs. Use after modifying components or adding new ones.
----
-
-# /doc - Update Folder Documentation
-
-Maintain living, component-level documentation in folder README files.
-
-> **Why /doc?** Component-level context evaporates quickly. Documenting the "why" and "when" of changes ensures the codebase remains understandable as it grows.
-
-## When To Use
-
-- After modifying a component's core logic
-- When adding a new file to a directory
-- As a handoff step in the `/review` workflow
-- When referencing a new ADR in a component
-
----
-
-## Workflow
-
-### Step 1: Identify Target Folder
-
-Identify which folder's `README.md` needs updating.
-
-```bash
-# If not provided, list modified folders
-git diff main --name-only | xargs -n1 dirname | sort -u
-```
-
-### Step 2: Read Existing README
-
-Check if a `README.md` exists. If not, bootstrap it using the template.
-
-```bash
-# Check for README
-ls {folder_path}/README.md
-
-# If missing, use bootstrap script
-Call MCP `call_tool_docs_manager` { action: "bootstrap", folder: "{folder_path}" }
-```
-
-### Step 3: Update Components Table
-
-If a new component was added, ensure it's in the table.
-
-| Component | Purpose | Status |
-|-----------|---------|--------|
-| `NewComponent.tsx` | {Purpose} | `🏗️ Building` |
-
-### Step 4: Add Tiered Component Details
-
-Update the `## Component Details` section with depth based on the component's [Tier](../../docs/templates/component-tier-guide.md).
-
-- **🔴 Critical**: Full detail (Purpose, Functionality, Tech, Error Handling, Usage).
-- **🟡 Supporting**: Brief purpose and key exports.
-- **🟢 Generated**: One-line description.
-
-### Step 5: Add Changelog Entry
-
-Document the change, including the "why" and relevant references.
-
-```markdown
-### {YYYY-MM-DD}
-- {Change description} (Response to: {Link to TODO/Spec/ADR})
-```
-
-### Step 6: Verify Links
-
-Ensure any newly added links to ADRs or other documentation are valid.
-
-### Step 7: Integration Audit (Sibling Parity)
-
-If you created a NEW folder, ensure it is covered by the validation system:
-1. Run `Call MCP `call_tool_docs_manager` { action: "discover" }` to verify discovery.
-2. Run `Call MCP `call_tool_docs_manager` { action: "validate", strict: false }` to verify structure.
-3. If new patterns were established, update `docs/solutions/patterns/critical-patterns.md`.
-
----
-
-## Quality Guidelines
-
-- ✅ Focus on the **Why**, not just the **What**.
-- ✅ Keep the components table updated and sorted.
-- ✅ Link to relevant ADRs for architectural decisions.
-- ✅ Ensure changelog entries are dated and specific.
-
----
-
-## References
-
-- Template: `docs/templates/folder-readme-template.md`
-- Tier Guide: `docs/templates/component-tier-guide.md`
-- Documentation Map: `docs/architecture/codebase-map.md`
-- ADRs: `docs/decisions/`
+---
+description: Update folder-level documentation and component changelogs. Use after modifying components or adding new ones.
+---
+
+# /doc - Update Folder Documentation
+
+Maintain living, component-level documentation in folder README files.
+
+> **Why /doc?** Component-level context evaporates quickly. Documenting the "why" and "when" of changes ensures the codebase remains understandable as it grows.
+
+## When To Use
+
+- After modifying a component's core logic
+- When adding a new file to a directory
+- As a handoff step in the `/review` workflow
+- When referencing a new ADR in a component
+
+---
+
+## Workflow
+
+### Step 1: Identify Target Folder
+
+Identify which folder's `README.md` needs updating.
+
+```bash
+# If not provided, list modified folders
+git diff main --name-only | xargs -n1 dirname | sort -u
+```
+
+### Step 2: Read Existing README
+
+Check if a `README.md` exists. If not, bootstrap it using the template.
+
+```bash
+# Check for README
+ls {folder_path}/README.md
+
+# If missing, use bootstrap script
+Call MCP `call_tool_docs_manager` { action: "bootstrap", folder: "{folder_path}" }
+```
+
+### Step 3: Update Components Table
+
+If a new component was added, ensure it's in the table.
+
+| Component | Purpose | Status |
+|-----------|---------|--------|
+| `NewComponent.tsx` | {Purpose} | `🏗️ Building` |
+
+### Step 4: Add Tiered Component Details
+
+Update the `## Component Details` section with depth based on the component's [Tier](../../docs/templates/component-tier-guide.md).
+
+- **🔴 Critical**: Full detail (Purpose, Functionality, Tech, Error Handling, Usage).
+- **🟡 Supporting**: Brief purpose and key exports.
+- **🟢 Generated**: One-line description.
+
+### Step 5: Add Changelog Entry
+
+Document the change, including the "why" and relevant references.
+
+```markdown
+### {YYYY-MM-DD}
+- {Change description} (Response to: {Link to TODO/Spec/ADR})
+```
+
+### Step 6: Verify Links
+
+Ensure any newly added links to ADRs or other documentation are valid.
+
+### Step 7: Integration Audit (Sibling Parity)
+
+If you created a NEW folder, ensure it is covered by the validation system:
+1. Run `Call MCP `call_tool_docs_manager` { action: "discover" }` to verify discovery.
+2. Run `Call MCP `call_tool_docs_manager` { action: "validate", strict: false }` to verify structure.
+3. If new patterns were established, update `docs/solutions/patterns/critical-patterns.md`.
+
+---
+
+## Quality Guidelines
+
+- ✅ Focus on the **Why**, not just the **What**.
+- ✅ Keep the components table updated and sorted.
+- ✅ Link to relevant ADRs for architectural decisions.
+- ✅ Ensure changelog entries are dated and specific.
+
+---
+
+## References
+
+- Template: `docs/templates/folder-readme-template.md`
+- Tier Guide: `docs/templates/component-tier-guide.md`
+- Documentation Map: `docs/architecture/codebase-map.md`
+- ADRs: `docs/decisions/`

package/skills/workflows/documentation-management.md

@@ -1,34 +1,34 @@
----
-name: documentation-management
-description: Guidelines on when and where to update documentation, covering READMEs, API docs, and comments.
----
-
-# Documentation Management
-
-## When to Update Docs
-
-- New features added
-- API changes
-- Breaking changes
-- Configuration updates
-
-## Documentation Locations
-
-| File | Purpose |
-|------|---------|
-| `README.md` | Project overview, install |
-| `CHANGELOG.md` | Version history |
-| `doc.md` | Gemini CLI reference |
-| `GEMINI.md` | AI context |
-
-## Standards
-
-### Code Comments
-- JSDoc for public functions
-- Inline comments for complex logic
-- TODO/FIXME with issue links
-
-### API Documentation
-- Input/output types
-- Error cases
-- Examples
+---
+name: documentation-management
+description: Guidelines on when and where to update documentation, covering READMEs, API docs, and comments.
+---
+
+# Documentation Management
+
+## When to Update Docs
+
+- New features added
+- API changes
+- Breaking changes
+- Configuration updates
+
+## Documentation Locations
+
+| File | Purpose |
+|------|---------|
+| `README.md` | Project overview, install |
+| `CHANGELOG.md` | Version history |
+| `doc.md` | Gemini CLI reference |
+| `GEMINI.md` | AI context |
+
+## Standards
+
+### Code Comments
+- JSDoc for public functions
+- Inline comments for complex logic
+- TODO/FIXME with issue links
+
+### API Documentation
+- Input/output types
+- Error cases
+- Examples

package/skills/workflows/explore.md

@@ -1,146 +1,146 @@
----
-description: Deep investigation before planning. Use for best practices, implications, and systematic analysis.
----
-
-# /explore - Research and Deep Thinking
-
-Conduct a deep, systematic pre-planning investigation to gather industry best practices, analyze multi-order effects, and understand complex problems before committing to a formal plan.
-
-> **Why explore?** A plan built on assumptions is a liability. 30 minutes of deep exploration compounds into architectural excellence and prevents costly rework.
-
-## When To Use
-
-- Before any `/plan` for complex features
-- When investigating unfamiliar technologies or patterns
-- For bugs requiring deep root-cause analysis
-- Anytime you think: "I need to understand this better before I decide."
-
----
-
-## Workflow
-
-### Step 0: Search & Log
-
-```bash
-// turbo
-Call MCP `call_tool_logger_manager` { action: "logWorkflow", name: "/explore", outcome: "success" }
-Call MCP `call_tool_compound_manager` { action: "search", terms: [ "exploration"] }
-```
-
-### Step 1: Search Existing Knowledge (MANDATORY)
-
-> [!CAUTION]
-> **BLOCKING STEP.** Search both solutions AND prior explorations.
-
-```bash
-// turbo
-Call MCP `call_tool_compound_manager` { action: "search", terms: [ "{keywords}"] }
-ls docs/explorations/*.md | grep "{keyword}"
-```
-
-### Step 1.5: Define the Question
-
-State exactly what we are trying to understand.
-*Example: "What is the most robust way to handle multi-session task orchestration in a stateless agentic system?"*
-
-### Step 2: Scope & Time-box
-
-Set boundaries to avoid rabbit holes.
-- **Time-box:** How long will we explore? (e.g., 30m, 1h, 1 day)
-- **Success Criteria:** What specific answer or evidence do we need?
-
----
-
-### Step 3: Internet Research (Recommended)
-
-> [!TIP]
-> **Best Practice.** Verification of industry standards is highly encouraged.
-
-```bash
-// turbo
-search_web("{topic} best practices software engineering")
-search_web("{topic} common pitfalls and anti-patterns")
-search_web("{topic} design patterns comparison")
-```
-
-**Summarize industry standards in the exploration artifact.**
-
----
-
-### Step 4: Deep Systematic Analysis
-
-Apply multi-order thinking and holistic analysis.
-
-**Multi-Order Consequences ("And Then What?"):**
-- **1st order:** Immediate impact of the potential change.
-- **2nd order:** What depends on those changes?
-- **3rd order:** Cascading effects (drift, technical debt).
-- **4th order:** Long-term cultural or architectural shifts.
-
-**Stakeholder Impact Matrix:**
-Assess impact on End Users, Developers, Ops/Support, and Downstream Systems.
-
----
-
-### Step 5: Document Findings
-
-Create the exploration file at `docs/explorations/{topic}-{YYYYMMDD}.md`.
-Use the template at `docs/explorations/templates/exploration-template.md`.
-
-### Step 6: Long-Term Implications Check
-
-- **6 months/1 year:** How will this age?
-- **Reversibility:** Can we undo this? (Type 1 vs Type 2 decisions)
-- **Technical Debt:** Does this create or pay down debt?
-
----
-
-### Step 7: Decision Gate
-
-Decide on the next logical action:
-1. **Proceed to /plan:** We have enough understanding to build.
-2. **Proceed to /specs:** This is a major iniciativa.
-3. **Create Todo:** Defer based on findings.
-4. **No Action:** Learning captured, no change needed.
-5. **Escalate:** Needs human stakeholder input.
-
-### Phase 5: Completion & Handoff
-
-#### Step 1: Establish Terminal UI State
-
-```javascript
-await task_boundary({
-  TaskName: "[COMPLETED] Exploration: {Topic}",
-  TaskStatus: "Exploration complete. Offering next steps.",
-  Mode: "VERIFICATION",
-  TaskSummary: "Completed deep exploration of {topic}. Findings documented in docs/explorations/{filename}. Decision: {Gate Decision}."
-});
-```
-
-#### Step 2: Mandatory Handoff
-
-```bash
-✓ Exploration complete
-
-Next steps:
-1. /plan - Create plan based on findings (if proceed)
-2. /specs - Create specification (if major initiative)
-3. /triage - File found issues as todos
-```
-
----
-
-## Quality Guidelines
-
-- ✅ Internet search for industry standards is encouraged.
-- ✅ Document "And Then What?" at least to 3rd order.
-- ✅ Explicitly state when something is a "Type 1" (irreversible) decision.
-- ✅ Link findings back to codebase patterns.
-
----
-
-## References
-
-- Explorations directory: `docs/explorations/`
-- Solutions: `docs/solutions/`
-- Pattern #11: Explore Before Plan
+---
+description: Deep investigation before planning. Use for best practices, implications, and systematic analysis.
+---
+
+# /explore - Research and Deep Thinking
+
+Conduct a deep, systematic pre-planning investigation to gather industry best practices, analyze multi-order effects, and understand complex problems before committing to a formal plan.
+
+> **Why explore?** A plan built on assumptions is a liability. 30 minutes of deep exploration compounds into architectural excellence and prevents costly rework.
+
+## When To Use
+
+- Before any `/plan` for complex features
+- When investigating unfamiliar technologies or patterns
+- For bugs requiring deep root-cause analysis
+- Anytime you think: "I need to understand this better before I decide."
+
+---
+
+## Workflow
+
+### Step 0: Search & Log
+
+```bash
+// turbo
+Call MCP `call_tool_logger_manager` { action: "logWorkflow", name: "/explore", outcome: "success" }
+Call MCP `call_tool_compound_manager` { action: "search", terms: [ "exploration"] }
+```
+
+### Step 1: Search Existing Knowledge (MANDATORY)
+
+> [!CAUTION]
+> **BLOCKING STEP.** Search both solutions AND prior explorations.
+
+```bash
+// turbo
+Call MCP `call_tool_compound_manager` { action: "search", terms: [ "{keywords}"] }
+ls docs/explorations/*.md | grep "{keyword}"
+```
+
+### Step 1.5: Define the Question
+
+State exactly what we are trying to understand.
+*Example: "What is the most robust way to handle multi-session task orchestration in a stateless agentic system?"*
+
+### Step 2: Scope & Time-box
+
+Set boundaries to avoid rabbit holes.
+- **Time-box:** How long will we explore? (e.g., 30m, 1h, 1 day)
+- **Success Criteria:** What specific answer or evidence do we need?
+
+---
+
+### Step 3: Internet Research (Recommended)
+
+> [!TIP]
+> **Best Practice.** Verification of industry standards is highly encouraged.
+
+```bash
+// turbo
+search_web("{topic} best practices software engineering")
+search_web("{topic} common pitfalls and anti-patterns")
+search_web("{topic} design patterns comparison")
+```
+
+**Summarize industry standards in the exploration artifact.**
+
+---
+
+### Step 4: Deep Systematic Analysis
+
+Apply multi-order thinking and holistic analysis.
+
+**Multi-Order Consequences ("And Then What?"):**
+- **1st order:** Immediate impact of the potential change.
+- **2nd order:** What depends on those changes?
+- **3rd order:** Cascading effects (drift, technical debt).
+- **4th order:** Long-term cultural or architectural shifts.
+
+**Stakeholder Impact Matrix:**
+Assess impact on End Users, Developers, Ops/Support, and Downstream Systems.
+
+---
+
+### Step 5: Document Findings
+
+Create the exploration file at `docs/explorations/{topic}-{YYYYMMDD}.md`.
+Use the template at `docs/explorations/templates/exploration-template.md`.
+
+### Step 6: Long-Term Implications Check
+
+- **6 months/1 year:** How will this age?
+- **Reversibility:** Can we undo this? (Type 1 vs Type 2 decisions)
+- **Technical Debt:** Does this create or pay down debt?
+
+---
+
+### Step 7: Decision Gate
+
+Decide on the next logical action:
+1. **Proceed to /plan:** We have enough understanding to build.
+2. **Proceed to /specs:** This is a major iniciativa.
+3. **Create Todo:** Defer based on findings.
+4. **No Action:** Learning captured, no change needed.
+5. **Escalate:** Needs human stakeholder input.
+
+### Phase 5: Completion & Handoff
+
+#### Step 1: Establish Terminal UI State
+
+```javascript
+await task_boundary({
+  TaskName: "[COMPLETED] Exploration: {Topic}",
+  TaskStatus: "Exploration complete. Offering next steps.",
+  Mode: "VERIFICATION",
+  TaskSummary: "Completed deep exploration of {topic}. Findings documented in docs/explorations/{filename}. Decision: {Gate Decision}."
+});
+```
+
+#### Step 2: Mandatory Handoff
+
+```bash
+✓ Exploration complete
+
+Next steps:
+1. /plan - Create plan based on findings (if proceed)
+2. /specs - Create specification (if major initiative)
+3. /triage - File found issues as todos
+```
+
+---
+
+## Quality Guidelines
+
+- ✅ Internet search for industry standards is encouraged.
+- ✅ Document "And Then What?" at least to 3rd order.
+- ✅ Explicitly state when something is a "Type 1" (irreversible) decision.
+- ✅ Link findings back to codebase patterns.
+
+---
+
+## References
+
+- Explorations directory: `docs/explorations/`
+- Solutions: `docs/solutions/`
+- Pattern #11: Explore Before Plan