@konductro/claude-plugin 2.1.0 → 2.2.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@konductro/claude-plugin",
-  "version": "2.1.0",
+  "version": "2.2.0",
   "description": "Claude Code plugin for the Konductro platform — technical analysis and delivery tasks",
   "license": "UNLICENSED",
   "type": "module",

package/servers/konductro-api.js

@@ -297,7 +297,7 @@ server.tool(
     title: z.string().describe('Task title'),
     description: z.string().describe('Technical description of the task'),
     repositoryId: z.string().describe('Repository ID from the context'),
-    type: z.enum(['ui_component', 'api_java', 'api_node', 'android', 'ios', 'infra']).default('api_node').describe('Task type'),
+    type: z.string().trim().max(24).optional().describe('Short free-text tech tag derived from the repo stack (e.g. C#, PHP, Node, Java, UI, Infra); one token, max 24 chars, no fixed list'),
     acceptanceCriteria: z.array(z.string()).default([]).describe('Technical acceptance criteria'),
     architecturalNotes: z.array(z.string()).default([]).describe('Implementation notes for the agent'),
     componentPath: z.string().optional().nullable().describe('Primary file/directory path for this task'),
@@ -348,6 +348,30 @@ server.tool(
   }
 );
 
+// Tool: Submit a regenerated developer brief (KON-325)
+server.tool(
+  'submit_regenerated_brief',
+  "Submit a freshly regenerated developer brief for a task to Konductro. It becomes the task's current brief and is appended to the brief history (the previous version is preserved). Regenerate the brief tailored to Claude Code conventions before calling this.",
+  {
+    ticketId: z.string().describe('The ticket ID or key (e.g. KON-325) to update'),
+    content: z.string().describe('The full regenerated developer brief (markdown)'),
+    toolset: z.enum(['claude', 'q', 'codex', 'cursor']).default('claude').describe("Coding toolset that produced this brief (this plugin: 'claude')"),
+  },
+  async ({ ticketId, content, toolset }) => {
+    const result = await konductroFetch(`/api/cli/tickets/${ticketId}/regenerate-brief`, {
+      method: 'POST',
+      body: JSON.stringify({ content, toolset }),
+    });
+
+    return {
+      content: [{
+        type: 'text',
+        text: `Developer brief regenerated for ${ticketId} — now version ${result.version} (${result.toolset}).`,
+      }],
+    };
+  }
+);
+
 // Tool: List my tickets
 server.tool(
   'list_my_tickets',

package/skills/decompose/SKILL.md

@@ -45,7 +45,7 @@ Based on the story requirements and your codebase understanding, plan the tasks.
 - **Execution order** — what needs to be built first (e.g., schema before API before UI)
 - **Task boundaries** — each task should be a single PR, touching one concern
 - **Repository assignment** — which repo does each task belong to
-- **Task type** — `api_node`, `api_java`, `ui_component`, `android`, `ios`, `infra`
+- **Task type** — a short free-text tech tag derived from the target repo's stack (e.g. `C#`, `PHP`, `Node`, `Java`, `Angular`, `UI`, `Infra`). One canonical token, max 24 chars — there is no fixed list; match the repo's actual language/domain.
 - **Dependencies between tasks** — task 2 may depend on task 1's API
 
 Present your proposed decomposition to the user before submitting.
@@ -57,7 +57,7 @@ For each task, produce the full developer brief — this is the complete impleme
 1. **title** — short, action-oriented (e.g., "Add sprint.projectId column and migration")
 2. **description** — technical description of what to build and how, referencing specific files, patterns, and APIs
 3. **repositoryId** — from the context (the repo this task targets)
-4. **type** — `api_node`, `api_java`, `ui_component`, `android`, `ios`, `infra`
+4. **type** — short free-text tech tag from the repo's stack (e.g. `C#`, `PHP`, `Node`, `Java`, `Angular`, `UI`, `Infra`); one canonical token, max 24 chars, no fixed list
 5. **acceptanceCriteria** — specific, testable criteria for this task
 6. **architecturalNotes** — implementation hints, patterns to follow, gotchas
 7. **componentPath** — primary file or directory being changed

package/skills/regenerate-brief/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: regenerate-brief
+description: Regenerate a task's developer brief using Claude Code, tailored to the current codebase, and submit it back to Konductro. Use when a developer wants a fresh, tool-tailored brief for an existing task.
+allowed-tools: Read, Grep, Glob, Bash, mcp__konductro__list_my_tickets, mcp__konductro__get_ticket_context, mcp__konductro__submit_regenerated_brief
+---
+
+# Regenerate Developer Brief
+
+Help a developer regenerate the developer brief for a Konductro task, tailored to Claude Code, then submit it back. The regenerated brief becomes the task's current brief; the previous version is preserved in the brief history (nothing is lost).
+
+## Workflow
+
+### Step 1: Pick the task
+
+Call `list_my_tickets` to show assigned tickets, or take a ticket key the developer gives you (e.g. `KON-325`). Choose the task whose brief to regenerate.
+
+### Step 2: Load current context
+
+Call `get_ticket_context` with the ticket ID. Review the **current brief** (context pack), description, acceptance criteria, architectural notes, and target repository — this is your starting point.
+
+### Step 3: Explore the codebase
+
+Use Read / Grep / Glob against the **local** repository to ground the brief in the actual code as it stands now — relevant files, existing patterns, entry points, and tests. A regenerated brief should reflect the current state of the code, not just the original decomposition.
+
+### Step 4: Regenerate the brief
+
+Write a fresh developer brief tailored to Claude Code conventions. Use clear, actionable sections:
+- **Architecture Context** — how this task fits, key constraints
+- **Files to Create / Files to Modify** — concrete paths + what changes
+- **Implementation Steps** — a numbered, ordered approach
+- **Out of Scope** — what this task explicitly does not cover
+
+Keep it focused on THIS task. Prefer concrete file paths and specifics over generic advice.
+
+### Step 5: Submit
+
+Call `submit_regenerated_brief` with the ticket ID and the regenerated brief as `content` (the `toolset` defaults to `claude` for this plugin). On success it becomes the current brief and is recorded as a new version.
+
+## Rules
+
+- This does not change the task's status or branch — it only updates the brief. To start work, use `/start-ticket`.
+- If `submit_regenerated_brief` fails (auth/validation), show the error clearly **and** show the brief you wrote so the developer can retry without losing it.
+- Regenerate against the real local code — don't just reword the existing brief.

package/skills/start-ticket/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: start-ticket
 description: Pick up an assigned ticket and start work — creates branch, pushes ticket spec, updates status. Use when a developer wants to begin working on a ticket.
-allowed-tools: Read, Grep, Glob, Bash, mcp__konductro__list_my_tickets, mcp__konductro__get_ticket_context, mcp__konductro__start_work
+allowed-tools: Read, Grep, Glob, Bash, mcp__konductro__list_my_tickets, mcp__konductro__get_ticket_context, mcp__konductro__submit_regenerated_brief, mcp__konductro__start_work
 ---
 
 # Start Ticket
@@ -24,6 +24,10 @@ Call `get_ticket_context` with the chosen ticket ID. Present a summary:
 - Target repository and default base branch
 - Any dependencies or architectural notes
 
+### Step 2.5 (optional): Regenerate the brief before starting
+
+Offer the developer the option to **regenerate the developer brief first**, tailored to Claude Code, so they start from a fresh, code-grounded brief. If they accept: explore the local codebase, write an updated brief, and submit it with `submit_regenerated_brief` (toolset `claude`) before moving on. If they decline, continue with the existing brief. (For a standalone regeneration without starting work, use `/regenerate-brief`.)
+
 ### Step 3: Confirm Branch Details
 
 Ask the developer: