codeninja 3.2.0 → 4.0.1

package/ide/antigravity/.agents/workflows/codeninja-design.md

@@ -1,54 +1,68 @@
+This workflow runs when user invokes /codeninja:design
+
 ---
-slash_command: /codeninja:design
-personas: [global-orchestrator, nodejs-backend, database-architect]
-skills: [mcp-and-context, api-builder, database]
-description: Plan a feature, API contract, or database change before writing any code.
+type: workflow
+name: design
+description: >
+  Plan a feature, API contract, or database change before writing any code.
+  Produces a design document and optionally updates context with the planned
+  schema or routes for other agents to reference.
 ---
 
-# /codeninja:design
+# Workflow: @design
+
+## Goal
+Think before coding. Produce a structured design plan that becomes the
+contract for `@create-api`, `@initialize-project`, or manual implementation.
 
-## Before Running
-1. Call `context_read`
-2. Call `context_check_stale`
+## Rules
+- No files are generated unless user explicitly confirms
+- Design output is stored in `.codeninja/agent/designs/<feature_name>.design.md`
+- Approved designs update context with planned routes and schema
 
-## Execution — Full Step-by-Step
+---
+
+## Step-by-Step Execution
 
 ### Phase 1 — Scope
+1. Run task: `ask-design-target`
+   - Options: new feature, new API endpoint, database change, full module
+   - Stores: `context.current_design.type`
 
-**Step 1.** Ask: "What are you designing?"
-- Options: new feature / new API endpoint / database change / full module
-- Store: `context.current_design.type`
+2. Run task: `ask-feature-name`
+   - Stores: `context.current_design.feature_name`
 
-**Step 2.** Ask: "Feature or module name?"
-- Store: `context.current_design.feature_name`
+3. Run task: `ask-design-description`
+   - Free text: what should this feature do?
+   - Stores: `context.current_design.description`
 
-**Step 3.** Ask: "What should this feature do?" (free text)
-- Store: `context.current_design.description`
+---
 
 ### Phase 2 — Database Design (if applicable)
+4. If design involves data storage:
+   - Delegate to `database-agent`
+   - Design table structure, column types, indexes, relationships
+   - Present schema proposal to user for feedback
+   - Allow user to request changes (one change at a time)
 
-**Step 4.** If design involves data storage:
-- Delegate to database-agent
-- Design table structure, column types, indexes, relationships
-- Present schema proposal for feedback
-- Allow changes one at a time
+---
 
 ### Phase 3 — API Design (if applicable)
+5. If design involves API endpoints:
+   - Delegate to `nodejs-agent`
+   - Propose: method, path, request body, response shape, auth requirement
+   - Present to user for feedback
 
-**Step 5.** If design involves API endpoints:
-- Delegate to nodejs-agent
-- Propose: method, path, request body, response shape, auth requirement
-- Present for feedback
+---
 
 ### Phase 4 — Output
+6. Generate `.codeninja/agent/designs/<feature_name>.design.md` containing:
+   - Feature summary
+   - DB schema proposal (tables, columns)
+   - API contracts (method, path, request, response)
+   - Open questions / decisions needed
 
-**Step 6.** Generate `.codeninja/agent/designs/<feature_name>.design.md`:
-- Feature summary
-- DB schema proposal (tables, columns, indexes, relationships)
-- API contracts (method, path, request, response shape)
-- Open questions / decisions needed
-
-**Step 7.** Ask: "Save this design and mark planned routes/schema in context? (yes/no)"
-If yes → call `context_write` with operation "design", then `context_clear_scratchpad` ["current_design"]
-
-**Step 8.** Show final summary.
+7. Ask: "Save this design and mark planned routes/schema in context? (yes/no)"
+8. If yes → run task: `write-context` with operation = "design"
+   Then call: context_clear_scratchpad with keys: ["current_design"]
+9. Run task: `show-final-summary`

package/ide/antigravity/.agents/workflows/codeninja-explain.md

@@ -1,40 +1,61 @@
+This workflow runs when user invokes /codeninja:explain
+
 ---
-slash_command: /codeninja:explain
-personas: [global-orchestrator]
-skills: [mcp-and-context, code-intelligence]
-description: Explain any file, function, pattern, or concept using full project context.
+type: workflow
+name: explain
+description: >
+  Explain any file, function, pattern, or architectural concept in this project
+  using full project context. Useful for onboarding, code review, and exam prep.
 ---
 
-# /codeninja:explain
+# Workflow: @explain / /codeninja:explain
+
+## Goal
+Give a clear, context-aware explanation of any part of the codebase.
+Reference real file names, table names, service names — never placeholders.
+
+## Rules
+- Always read the actual file before explaining it
+- Use `context.db.schema` to reference real table/column names
+- Use `context.services` to reference real service names and ports
+- Explain the "why" not just the "what"
 
-## Before Running
-1. Call `context_read`
-2. Call `context_check_stale`
+---
 
-## Execution — Full Step-by-Step
+## Step-by-Step Execution
 
 ### Step 1 — Identify Target
 If not specified, ask: "What would you like me to explain?
-(e.g., a file path, a function name, a pattern like 'the auth middleware',
-or a concept like 'why we use DENSE_RANK')"
+(e.g., a file path, a function name, a pattern like 'the auth middleware', or a concept like 'why we use DENSE_RANK')"
 
 ### Step 2 — Load Context
-1. Call `fs_read` on the target file (if a file was specified)
-2. Read 1 related file to understand how the target fits in the system
-3. Reference `context.db.schema` for any table/column mentions
-4. Reference `context.services` for service names and ports
+1. Call MCP tool `context_read`
+2. Call MCP tool `fs_read` on the target file (if a file was specified)
+3. Read 1 related file to understand how the target fits in the system
 
 ### Step 3 — Explain
 
-Structure every explanation as:
+Structure the explanation as:
 
 **What it is** (1–2 sentences — plain English)
+> This is the route handler for the leaderboard endpoint. It validates the
+> incoming request, calls the model to fetch ranked scores, and returns them
+> in the project's standard response format.
 
 **How it works** (step-by-step walkthrough of the key logic)
-
-**Why this way** (the architectural decision behind it)
-
-**Where it connects** (related files and functions in this project — use real names)
+> 1. The `apiKeyMiddleware` checks the `api-key` header against the env value
+> 2. `validatorjs` ensures `weekId` is present and a non-empty string
+> 3. `LeaderboardModel.getTopScores(weekId)` runs the DENSE_RANK query
+> 4. The result is wrapped in `{ status: 1, message: lang.success, data: rows }`
+
+**Why this way** (the architectural decision)
+> We use DENSE_RANK instead of RANK because tied scores should get the same
+> position without gaps — position 3 should follow position 2, even with ties.
+
+**Where it connects** (related files/functions)
+> - Model: `modules/v1/Leaderboard/leaderboard_model.js`
+> - Language strings: `languages/en.js` → `leaderboard_success`
+> - Route registration: `modules/v1/route_manager.js` line ~45
 
 ### Step 4 — Offer Follow-up
 End with: "Want me to explain any part in more detail, or show how to modify it?"