superkit-mcp-server 1.0.2 → 1.0.3

package/skills/tech/intelligent-routing/SKILL.md

@@ -233,10 +233,10 @@ User: "Add mobile support to the web app"
 - If task is unclear, still ask questions first
 - Then route to appropriate agent
 
-### With GEMINI.md Rules
+### With main AGENT.md (GEMINI.md, CLAUDE.md) Rules
 
-- **Priority**: GEMINI.md rules > intelligent-routing
-- If GEMINI.md specifies explicit routing, follow it
+- **Priority**: main AGENT.md (GEMINI.md, CLAUDE.md) rules > intelligent-routing
+- If main AGENT.md (GEMINI.md, CLAUDE.md) specifies explicit routing, follow it
 - Intelligent routing is the DEFAULT when no explicit rule exists
 
 ## Testing the System
@@ -305,7 +305,7 @@ still mention agents explicitly with `@agent-name` if you prefer.
 
 ### Enable Debug Mode (for development)
 
-Add to GEMINI.md temporarily:
+Add to main AGENT.md (GEMINI.md, CLAUDE.md) temporarily:
 
 ```markdown
 ## DEBUG: Intelligent Routing
@@ -332,4 +332,4 @@ Show selection reasoning:
 
 ---
 
-**Next Steps**: Integrate this skill into GEMINI.md TIER 0 rules.
+**Next Steps**: Integrate this skill into main AGENT.md (GEMINI.md, CLAUDE.md) TIER 0 rules.

package/workflows/kit-setup.md

@@ -26,7 +26,7 @@ Collect information:
 - Goals
 - Key features
 
-**Output:** `.gemini-kit/product.md`
+**Output:** `.docs/product.md`
 
 ### Step 2: Tech Stack
 
@@ -36,7 +36,7 @@ Collect information:
 - Database (PostgreSQL, MongoDB, etc.)
 - Other tools (Redis, S3, etc.)
 
-**Output:** `.gemini-kit/tech-stack.md`
+**Output:** `.docs/tech-stack.md`
 
 ### Step 3: Guidelines
 
@@ -46,14 +46,14 @@ Collect information:
 - Testing requirements
 - Documentation standards
 
-**Output:** `.gemini-kit/guidelines.md`
+**Output:** `.docs/guidelines.md`
 
 ---
 
 ## Generated Files
 
 ```
-.gemini-kit/
+.docs/
 ├── product.md           # Product context
 ├── tech-stack.md        # Technical choices
 └── guidelines.md        # Team conventions
@@ -65,7 +65,7 @@ Collect information:
 
 ### product.md
 ```markdown
-# Product: Gemini-Kit
+# Product: Superkit
 
 ## Description
 Multi-agent AI development toolkit for Gemini CLI.
@@ -93,9 +93,9 @@ After setup complete:
 ✓ Setup complete!
 
 Files created:
-- .gemini-kit/product.md
-- .gemini-kit/tech-stack.md
-- .gemini-kit/guidelines.md
+- .docs/product.md
+- .docs/tech-stack.md
+- .docs/guidelines.md
 
 Next steps:
 1. Review and edit the generated files

package/workflows/map-codebase.md

@@ -0,0 +1,78 @@
+---
+description: (Brownfield) Map existing codebase architecture, tech stack, and conventions to ensure AI logic integrates smoothly.
+---
+
+# /map-codebase - Codebase Mapping Workflow
+
+Explore your existing application to document and structure its architecture, technology stack, testing conventions, and primary concerns. These foundational documents allow you and specialized agents to safely operate inside complex, pre-existing ("brownfield") codebases.
+
+> **Why map the codebase?** Writing code in an existing project without understanding its structure leads to duplicated patterns, fragmented architecture, and broken tests.
+
+## When To Use
+
+- **New Developer/Agent Onboarding:** First step when bringing an agent into a mature project.
+- **Before Major Refactors:** Taking a snapshot of the current state before altering the foundations.
+- **Project Documentation Sync:** After significant time has passed or dependencies have evolved.
+
+---
+
+## Workflow
+
+### Step 1: Run Sub-Task Planners in Parallel
+
+You will invoke multiple agents sequentially or in parallel using the `orchestrator` to generate specific documents:
+
+#### 1. Analyze Tech Stack and Integrations
+Use `explorer-agent` to analyze package files (e.g., package.json, requirements.txt, Cargo.toml), config files, and core application endpoints.
+- **Output:** `.planning/codebase/STACK.md` and `.planning/codebase/INTEGRATIONS.md`
+
+#### 2. Analyze Architecture and Structure
+Use `code-archaeologist` to analyze the directory structures, entry points, import patterns, and key abstractions across the project.
+- **Output:** `.planning/codebase/ARCHITECTURE.md` and `.planning/codebase/STRUCTURE.md`
+
+#### 3. Analyze Quality and Conventions
+Use `qa-automation-engineer` or `test-engineer` to read `.eslintrc`, `.prettierrc`, `jest.config.js`, and analyze common design patterns across `src/`.
+- **Output:** `.planning/codebase/CONVENTIONS.md` and `.planning/codebase/TESTING.md`
+
+#### 4. Map Out Concerns
+Use `penetration-tester` or `performance-optimizer` to map large files, scattered FIXME/TODO tags, fragile abstractions, and technical debt.
+- **Output:** `.planning/codebase/CONCERNS.md`
+
+### Step 2: Ensure Path Formatting
+
+> [!IMPORTANT]
+> **File Paths are Mandatory:** All generated mapping documents (`STACK.md`, `ARCHITECTURE.md`, `CONVENTIONS.md`, etc.) MUST use absolute or exact relative markdown file paths (e.g., `src/services/user.ts`), formatted with backticks. Vague descriptions like "User Service" are not actionable.
+
+### Step 3: Integrate with Project Knowledge
+
+Ensure the mapped output is linked in the master README, `GEMINI.md`, or the primary planner file so future workflows (`/plan-compound`, `/work`) automatically ingest the conventions.
+
+### Step 4: Validate
+
+Ensure these files do NOT include:
+- Passwords or tokens.
+- Content from `.env` files.
+- Proprietary or encrypted keys.
+
+Check that all 4 dimensions (Tech, Arch, Quality, Concerns) exist in the `.planning/codebase/` output directory.
+
+---
+
+## Output Template References
+
+When writing these documents, use the following structural guidelines:
+
+- **STACK.md**: Languages, Runtime, Frameworks, Key Dependencies, Platform Requirements.
+- **ARCHITECTURE.md**: Pattern Overview, Layers, Data Flow, Key Abstractions, Entry Points.
+- **CONVENTIONS.md**: Naming Patterns, Code Style, Error Handling, Logging, Comment Guidelines.
+- **CONCERNS.md**: Tech Debt, Known Bugs, Fragile Areas, Test Coverage Gaps.
+
+## Completion
+
+```bash
+✓ Codebase mapped into .planning/codebase/
+
+Next steps:
+1. /plan-compound - Start planning features using these new conventions
+2. /review - Review the identified technical debt (CONCERNS.md)
+```

package/workflows/plan-compound.md

@@ -291,6 +291,12 @@ Create plan file: `plans/{feature-name}.md`
 - [ ] Criterion 1
 - [ ] Criterion 2
 
+## Acceptance Criteria & Testing (Nyquist Validation Layer)
+> **Important:** Map each requirement to a specific automated test or manual verification command *before* execution.
+- [ ] Criterion 1 -> `npm test -- -t "criterion 1"`
+- [ ] Criterion 2 -> `pytest -k "criterion_2"`
+- [ ] Test scaffolding required: [List tests that need to be created]
+
 ## Technical Considerations
 
 ### Dependencies

package/workflows/plan_review.md

@@ -110,6 +110,11 @@ cat plans/{plan-name}.md
 - [ ] Data extremes and migration scenarios
 - [ ] User behavior edge cases
 
+**Reproducibility and Transparency (Scientific Review):**
+- [ ] **Data/State Availability:** Are initial states, dummy data, or prerequisites clearly defined?
+- [ ] **Methodological Detail:** Could an independent agent perfectly execute this plan without asking you clarifying questions? 
+- [ ] **Reporting Standards:** Does the plan link to specific codebase conventions (e.g. `CONVENTIONS.md`)?
+
 **Stakeholder Impact (Who else is affected?):**
 - [ ] End users notified of behavior changes?
 - [ ] Breaking changes communicated to other devs?
@@ -125,18 +130,29 @@ cat plans/{plan-name}.md
 
 ### Step 4: Provide Feedback
 
+Maintain a constructive, objective, and professional tone (Scientific Peer Review Standard):
+- **Be constructive:** Frame criticism as opportunities for improvement.
+- **Be specific:** Provide concrete examples and actionable suggestions.
+- **Be balanced:** Acknowledge strengths as well as weaknesses.
+
 ```markdown
 ## Plan Review: {Plan Name}
 
+### Summary Statement
+- {Brief synopsis of the plan and bottom-line assessment of soundness}
+
 ### Strengths
 - {What's good about the plan}
 
-### Concerns
-- {Issues that need addressing}
+### Major Concerns (Critical)
+- {Issues that fundamentally break the plan or block reproducibility}
 
-### Suggestions
+### Minor Suggestions (Improvements)
 - {Improvements to consider}
 
+### Questions for Author
+- {Clarifications needed before execution}
+
 ### Existing Solutions Referenced
 - {Any solutions from docs/solutions/ that apply}
 

package/workflows/review-compound.md

@@ -127,12 +127,13 @@ grep -rn "forEach.*await\|map.*await" --include="*.ts" src/
 
 ---
 
-#### Pass 3: 🏛️ Architecture Review
+#### Pass 3: 🏛️ Architecture & Visual Review
 
-Check structural integrity:
+Check structural integrity and visual communication:
 
 - [ ] **Single Responsibility:** Each function does one thing?
 - [ ] **Dependencies:** Proper layering? No circular deps?
+- [ ] **Schematics:** Are complex workflows visually documented (mermaid/diagrams)?
 - [ ] **Naming:** Clear, consistent naming?
 - [ ] **Patterns:** Following project conventions?
 - [ ] **Tests:** Adequate test coverage?
@@ -161,6 +162,17 @@ Check for unnecessary complexity:
 
 ---
 
+#### Pass 6: 🔬 Algorithmic & State Rigor (Scientific Review)
+
+Apply rigorous scientific evaluation to the core logic:
+
+- [ ] **Circular Logic Check:** Are conclusions/states derived independently?
+- [ ] **Control Variables:** Are side-effects properly controlled/isolated?
+- [ ] **Statistical/Algorithmic Soundness:** Are the algorithms appropriate for the scale? Are edge-cases proven handled?
+- [ ] **Reproducibility:** If this fails in production, is there enough logging to perfectly reproduce the state?
+
+---
+
 ### Step 4: Stakeholder Perspective Analysis
 
 Think through each stakeholder's view:
@@ -227,31 +239,38 @@ For each P1/P2 finding, create a todo.
 ### Step 8: Generate Review Summary
 
 ```markdown
-## Review Summary: {PR Title}
+## Peer Review Report: {PR Title}
 
 **Reviewed:** {date}
 **Files Changed:** {count}
 **Lines:** +{added} / -{removed}
 
-### Findings
-
-#### 🔴 P1 - Critical ({count})
-- {Finding 1}
-- {Finding 2}
+### Summary Statement
+Provide a concise overall assessment containing:
+- Brief synopsis of the changes
+- Overall recommendation (APPROVE, REQUEST_CHANGES, NEEDS_DISCUSSION)
+- Key strengths
+- Key weaknesses
 
-#### 🟡 P2 - Important ({count})
-- {Finding 1}
+### Major Comments (Critical/P1)
+Critical flaws that must be addressed (security, architectural errors, data loss):
+- 1. {Finding 1} - *Suggested fix*
+- 2. {Finding 2} - *Suggested fix*
 
-#### 🔵 P3 - Nice to Have ({count})
-- {Finding 1}
+### Minor Comments (P2/P3)
+Important to Nice-to-Have improvements (performance, conventions, dead code):
+- 1. {Finding 1} - *Suggested fix*
+- 2. {Finding 2} - *Suggested fix*
 
-### Recommendation
-{APPROVE / REQUEST_CHANGES / NEEDS_DISCUSSION}
+### Questions for Author
+Requests for clarification, unstated assumptions, or missing reproduction steps:
+- 1. Why was {approach} chosen over {alternative}?
+- 2. How are we handling {edge case} in {file}?
 
 ### Next Steps
-- [ ] Address P1 findings
-- [ ] Consider P2 findings
-- [ ] Create follow-up issues for P3
+- [ ] Address Major Comments
+- [ ] Answer Questions
+- [ ] Create follow-up issues for Minor Comments (if deferred)
 ```
 
 ### Step 9: Offer Next Actions

package/workflows/specs.md

@@ -206,7 +206,7 @@ if [ -n "$active_spec" ]; then
 fi
 ```
 
-This is built into `/plan` Step 0.5 and GEMINI.md agent behavior.
+This is built into `/plan` Step 0.5 and main AGENT.md (GEMINI.md, CLAUDE.md) agent behavior.
 
 ---