@konductro/cursor-plugin 1.0.0

package/skills/bug-enrich.mdc

@@ -0,0 +1,61 @@
+---
+description: USE WHEN the user wants to enrich a bug ticket with technical analysis — explores the codebase and submits structured context back to Konductro
+globs:
+alwaysApply: false
+---
+
+# Konductro Bug Enrichment
+
+You are enriching an existing bug ticket with technical context for the Konductro delivery platform. Your role is to add structured technical detail — never to rewrite or modify the user's original bug description.
+
+## Critical Constraint
+
+**DO NOT modify the original `description` of the ticket.** The enrichment is append-only. Your job is to add technical context (root cause, affected components, investigation steps).
+
+## Workflow
+
+### Step 1: Accept Ticket ID
+
+The user provides a ticket ID (e.g. `KON-42` or a UUID).
+
+### Step 2: Load Bug Context
+
+Call `get_bug_for_enrichment` with the ticket ID. This returns:
+- The bug title, description, and existing acceptance criteria
+- Project and phase context
+- Any existing architectural notes or component path
+
+Review the bug report and share a summary with the user.
+
+### Step 3: Explore the Codebase
+
+Use file reading and search tools to investigate:
+- **Affected code paths** — trace the flow described in the bug report
+- **Potential root cause** — look for the code that could produce the described behaviour
+- **Related components** — what files/modules are involved
+- **Stack trace clues** — if error messages are mentioned, find where they originate
+- **Fix verification** — what would need to be true for the bug to be resolved
+
+### Step 4: Plan the Enrichment
+
+Prepare structured enrichment fields:
+- **suspectedRootCause** — your best assessment of why the bug occurs (reference specific code)
+- **affectedComponents** — file paths or module names involved
+- **stackTraceHints** — relevant error origins, log lines, or exception paths
+- **investigationSteps** — what you checked and what you found
+- **verifyFixCriteria** — specific conditions that confirm the bug is fixed
+
+Present your findings to the user before submitting.
+
+### Step 5: Submit Enrichment
+
+After the user approves, call `submit_bug_enrichment` with the ticket ID and your structured findings.
+
+## Rules
+
+- Always load the bug context first — don't assume or hallucinate ticket contents
+- Explore the ACTUAL local codebase — don't invent file paths or code snippets
+- Reference specific files, line numbers, and function names in your findings
+- Present findings for user review before submitting
+- Never modify the original description — enrichment is additive only
+- If you can't find relevant code, say so honestly rather than guessing

package/skills/decompose.mdc

@@ -0,0 +1,88 @@
+---
+description: USE WHEN the user wants to decompose a Konductro story into technical implementation tasks by exploring the codebase
+globs:
+alwaysApply: false
+---
+
+# Konductro Story Decomposition
+
+You are decomposing a business-level story into technical tasks for the Konductro delivery platform. Each task you produce will be picked up by a developer or agent, so tasks must be specific, implementable, and self-contained.
+
+## Workflow
+
+### Step 1: Load Your Assignments
+
+Call `list_decomposition_tasks` to see which stories are assigned to you for decomposition. Present the list to the user and ask which story to work on.
+
+### Step 2: Load Context
+
+Call `get_decomposition_context` with the story ID. This loads:
+- The story details (title, description, acceptance criteria, complexity)
+- Approved requirements and architecture documents
+- Repository information with profiles
+- Existing tasks (if any were already created)
+- Sibling stories for cross-story context
+
+Share a summary with the user and confirm you're ready to begin.
+
+### Step 3: Explore the Codebase
+
+Use file reading and search tools to understand:
+- **Where the change lands** — which modules, services, or components are affected
+- **Existing patterns** — how similar features are already built
+- **Data model** — relevant database tables, entities, relationships
+- **API surface** — existing endpoints, request/response shapes
+- **Test patterns** — how tests are structured for this area
+- **Dependencies** — what the affected code depends on
+
+Focus your exploration on what's relevant to the story.
+
+### Step 4: Plan the Decomposition
+
+Based on the story requirements and your codebase understanding, plan the tasks. Consider:
+- **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`
+- **Dependencies between tasks** — task 2 may depend on task 1's API
+
+Present your proposed decomposition to the user before submitting.
+
+### Step 5: Define Each Task (Developer Brief)
+
+For each task, produce the full developer brief including:
+1. **title** — short, action-oriented
+2. **description** — technical description referencing specific files and patterns
+3. **repositoryId** — from the context
+4. **type** — task type enum
+5. **acceptanceCriteria** — specific, testable criteria
+6. **architecturalNotes** — implementation hints, patterns to follow
+7. **componentPath** — primary file or directory being changed
+8. **order** — execution order (0-based)
+9. **filesToCreate** — list of new files
+10. **filesToModify** — list of `{ path, change }` objects
+11. **implementationSteps** — ordered step-by-step guide
+12. **outOfScope** — what is explicitly NOT included
+
+### Step 6: Submit Tasks
+
+After the user approves, submit each task individually by calling `submit_decomposition_task` once per task.
+
+After ALL tasks are submitted, call `complete_decomposition` with the story ID and a conversation summary.
+
+## Guidelines
+
+- **Right-size tasks** — completable in a single focused session
+- **Self-contained** — makes sense on its own with enough context to implement
+- **Backend before frontend** — schema/migration first, then API, then UI
+- **One repo per task** — don't create cross-repo tasks
+- **Reference specific code** — mention file paths, function names, existing patterns
+- **Include test expectations** — note what tests should be added or updated
+
+## Rules
+
+- Always start by loading tasks from Konductro
+- Explore the ACTUAL codebase — don't assume or hallucinate file contents
+- Ask the user questions about business logic, edge cases, or priorities
+- Present the full task list for user review before submitting
+- Submit tasks ONE AT A TIME, then call `complete_decomposition`

package/skills/find-prototype.mdc

@@ -0,0 +1,53 @@
+---
+description: USE WHEN the user wants to find and download UX prototypes for the current project to reference while building features
+globs:
+alwaysApply: false
+---
+
+# Find Project Prototype
+
+You are helping a developer find and download the UX prototype for their current project so they can reference it while building features.
+
+## Workflow
+
+### Step 1: Get the git remote URL
+
+Run `git remote get-url origin` to get the repository's remote URL.
+
+### Step 2: Find prototypes
+
+Call `find_project_prototypes` with the git remote URL. This matches the repo to a Konductro project and returns any published prototypes with their file URLs.
+
+If no prototypes are found, let the user know and stop.
+
+### Step 3: Present the results
+
+Show the user what was found:
+- Engagement name and version
+- List of pages with their URLs
+
+Ask if they want to download the files locally.
+
+### Step 4: Download
+
+If the user wants to download, create a `.konductro/prototype/` directory and download each file:
+
+```bash
+mkdir -p .konductro/prototype
+curl -o .konductro/prototype/index.html "<url>"
+```
+
+### Step 5: Confirm
+
+Let the user know the files are downloaded and they can open them in their browser:
+```
+open .konductro/prototype/index.html
+```
+
+## Rules
+
+- Always detect the git remote automatically — don't ask the user for it
+- Use `.konductro/prototype/` as the download directory
+- The files are public S3 URLs — no credentials needed
+- If multiple prototypes exist, let the user pick which one to download
+- Don't modify the prototype files — they're reference material

package/skills/profile-repository.mdc

@@ -0,0 +1,51 @@
+---
+description: USE WHEN the user wants to scan the current repository and submit its tech profile to Konductro
+globs:
+alwaysApply: false
+---
+
+# Konductro Repository Profiling
+
+You are profiling a codebase to submit its technical profile to the Konductro delivery platform. This profile helps Konductro understand the repository for planning, estimation, and ticket generation.
+
+## Workflow
+
+### Step 1: Identify the Repository
+
+Run `git remote get-url origin` to get the repository's remote URL.
+
+### Step 2: Scan the Codebase
+
+Explore the repository to build a comprehensive profile:
+- **Project structure** — folder layout, monorepo or single project
+- **Tech stack** — check package.json, pom.xml, build.gradle, requirements.txt, go.mod, etc.
+- **Framework** — Angular, React, Spring Boot, Express, Fastify, Django, etc.
+- **API endpoints** — scan routes, controllers, handlers
+- **Dependencies** — key libraries with versions
+- **Database** — schemas, migrations, ORM config
+- **Build tools** — webpack, vite, gradle, maven, docker
+- **Test framework** — jest, mocha, junit, pytest, etc.
+
+### Step 3: Determine Role and Domain
+
+Based on the codebase, determine:
+- **Role**: Is this an application, library, service, or infrastructure repo?
+- **Domain**: What business domain does it own? (e.g., payments, auth, booking, notifications)
+
+### Step 4: Submit the Profile
+
+Call `profile_repository` with:
+- The git remote URL
+- Role and domain
+- API endpoints found
+- Key dependencies
+- Any events produced or consumed (message queues, webhooks, etc.)
+
+Present a summary to the user before submitting and ask for confirmation.
+
+## Rules
+
+- Scan the ACTUAL codebase — don't guess
+- Focus on the key dependencies and APIs, not every single package
+- Be specific about versions where possible
+- If you can't determine the domain, ask the user

package/skills/prototype.mdc

@@ -0,0 +1,81 @@
+---
+description: USE WHEN the user wants to build a UX prototype for a Konductro engagement — loads design system, generates multi-page HTML, publishes to S3, and submits back to Konductro
+globs:
+alwaysApply: false
+---
+
+# Konductro Prototype Build
+
+You are building a multi-page HTML prototype for a UX engagement on the Konductro platform. The prototype uses the project's design system and implements the screens defined in the approved feature matrix.
+
+## Workflow
+
+### Step 1: Load Your Assignments
+
+Call `list_prototype_tasks` to see which prototype tasks are assigned to you. Present the list and ask which one to work on.
+
+### Step 2: Load Context
+
+Call `get_prototype_context` with the job ID. This loads:
+- The UX engagement details
+- The design system (tokens: colours, typography, spacing; components: buttons, cards, forms)
+- Approved documents (hypotheses, personas, feature matrix)
+- The preview HTML from Design Studio (locked visual direction)
+- S3 configuration for publishing
+
+### Step 3: Start Work
+
+Call `start_prototype_work` with the job ID to mark the task as in progress.
+
+### Step 4: Build the Prototype
+
+Create a `./prototype/` directory. Build multi-page HTML files:
+
+**Structure:**
+- `index.html` — landing/home page (entry point)
+- Additional pages as defined by the feature matrix
+
+**Design rules:**
+- Use **Tailwind CSS via CDN**
+- Use **Google Fonts** if the design system specifies typography
+- Apply design system tokens directly as Tailwind config overrides
+- Build components exactly as defined in the design system
+- Every page must include consistent navigation linking to all other pages
+- Pages must be fully self-contained HTML files — no external JS frameworks
+- Use realistic placeholder content, not lorem ipsum
+- Responsive design — desktop and tablet widths minimum
+
+**Quality bar:**
+- Should look like a real application, not a wireframe
+- Match the approved preview HTML aesthetic
+- Interactive elements should have hover/focus states
+
+### Step 5: Review with User
+
+Let the user know the prototype is ready for review. Iterate based on feedback.
+
+### Step 6: Publish to S3
+
+When the user is happy:
+1. Call `request_upload_credentials` with the job ID
+2. Upload each HTML file using the credentials:
+
+```bash
+export AWS_ACCESS_KEY_ID=<from credentials>
+export AWS_SECRET_ACCESS_KEY=<from credentials>
+export AWS_SESSION_TOKEN=<from credentials>
+aws s3 cp ./prototype/ s3://<bucket>/<prefix>/ --recursive --content-type "text/html" --region <region>
+```
+
+### Step 7: Submit to Konductro
+
+Call `submit_prototype` with the job ID and a `pages` array listing each uploaded file with its filename and title.
+
+## Rules
+
+- Always start by loading tasks from Konductro
+- Use the design system tokens and components faithfully
+- The preview HTML is the approved visual direction — match it
+- Build ALL pages defined in the feature matrix
+- Ask the user for feedback before publishing
+- Credentials expire in 15 minutes — request fresh ones if upload takes longer

package/skills/start-ticket.mdc

@@ -0,0 +1,56 @@
+---
+description: USE WHEN the user wants to pick up a Konductro ticket, create a branch, and start working on it
+globs:
+alwaysApply: false
+---
+
+# Start Ticket
+
+You are helping a developer pick up and start work on a Konductro ticket.
+
+## Workflow
+
+### Step 1: List Assigned Tickets
+
+Call `list_my_tickets` to show what's available. Focus on tickets in `assigned` or `in_sprint` status — these are ready to be picked up.
+
+If the developer already knows which ticket they want, skip to Step 2.
+
+### Step 2: Load Ticket Context
+
+Call `get_ticket_context` with the chosen ticket ID. Present a summary:
+- Title and description
+- Acceptance criteria
+- Target repository and default base branch
+- Any dependencies or architectural notes
+
+### Step 3: Confirm Branch Details
+
+Ask the developer:
+- **Branch from:** Show the repo's default base branch (from the context). Ask if they want to branch from somewhere else.
+- **Branch name:** Show the default (`feature/{TICKET-KEY}`). Ask if they want to override it.
+
+Most of the time the defaults are fine — don't over-prompt. A simple "I'll create `feature/MRB-15` from `dev` — good?" is enough.
+
+### Step 4: Start Work
+
+Call `start_work` with the ticket ID and branch details. This will:
+1. Create the branch in ADO
+2. Push the ticket spec file to `.tickets/{KEY}.md`
+3. Set the ticket status to `in_progress`
+
+### Step 5: Checkout Locally
+
+After success, tell the developer to run:
+```
+git fetch && git checkout {branchName}
+```
+
+Then offer to help them get started — explore the codebase, review the acceptance criteria against existing code, etc.
+
+## Rules
+
+- Only show tickets that are assigned to the user and ready to start
+- Always confirm the branch-from before calling start_work
+- If start_work fails (e.g. branch already exists, ADO error), show the error clearly
+- Don't skip the branch confirmation step — branching from the wrong base is hard to fix

package/skills/technical-analysis.mdc

@@ -0,0 +1,74 @@
+---
+description: USE WHEN the user wants to perform a technical analysis for a Konductro project phase — examining patterns, dependencies, risks, and recommending an approach
+globs:
+alwaysApply: false
+---
+
+# Konductro Technical Analysis
+
+You are performing a technical analysis of a codebase for the Konductro delivery platform. This analysis will feed into the architecture stage and ultimately into delivery ticket generation.
+
+## Workflow
+
+### Step 1: Load Your Tasks
+
+Call `list_tech_analysis_tasks` to see what's assigned to you. Present the list to the user and ask which task to work on.
+
+### Step 2: Load Context
+
+Call `get_task_context` with the phase ID. This loads:
+- The approved requirements document (what needs to be built)
+- Project and client context
+- Repository information
+
+Share a summary of the requirements with the user and confirm you're ready to begin.
+
+### Step 3: Explore the Codebase
+
+Analyse the local codebase using file reading and search tools:
+- **Project structure** — folder layout, module organisation
+- **Tech stack** — frameworks, versions, build tools
+- **Architecture patterns** — how the app is structured
+- **Existing APIs** — routes, controllers, endpoints
+- **Data models** — database schemas, entities, types
+- **Dependencies** — external libraries, their versions, what they're used for
+- **Testing** — test framework, coverage, test patterns
+- **Configuration** — environment handling, feature flags
+- **Integration points** — external services, message queues, APIs consumed
+
+Discuss findings with the user as you go. Ask clarifying questions.
+
+### Step 4: Impact Analysis
+
+Based on the requirements and your codebase exploration, assess:
+- **What needs to change** — which files, modules, or services
+- **What needs to be created** — new components, services, APIs
+- **Risks and constraints** — technical debt, tight coupling, performance concerns
+- **Dependencies between changes** — what order should things be built in
+- **Recommended approach** — how to implement given the current codebase
+
+### Step 5: Produce the Document
+
+Produce a structured technical analysis document including:
+1. **Codebase Overview** — what exists today
+2. **Technical Stack** — frameworks, versions, build tools, deployment
+3. **Architecture Patterns** — structure, key design decisions
+4. **Existing APIs & Services** — current endpoints and integrations
+5. **Data Model** — current schema, entities, relationships
+6. **Impact Analysis** — what needs to change
+7. **Risks & Constraints** — technical debt, performance, coupling
+8. **Recommended Approach** — how to implement, including sequencing
+9. **Dependencies** — external libraries, services, inter-module
+10. **Testing Strategy** — how to test the changes
+
+### Step 6: Submit
+
+Ask the user to review the document. When approved, call `submit_tech_analysis` with the phase ID, the complete document, and a conversation summary.
+
+## Rules
+
+- Always start by loading tasks from Konductro
+- Explore the ACTUAL codebase — don't assume or hallucinate file contents
+- Be thorough but focused — analyse what's relevant to the requirements
+- Ask the user questions — they know the codebase context you don't
+- Produce a complete, standalone document an architect can use without additional context