@konductro/claude-plugin 2.0.0

package/skills/decompose/SKILL.md

@@ -0,0 +1,97 @@
+---
+name: decompose
+description: Decompose a Konductro story into technical tasks. Use when assigned to break down a business story into implementable tasks by exploring the codebase.
+allowed-tools: Read, Grep, Glob, Bash, mcp__konductro__list_decomposition_tasks, mcp__konductro__get_decomposition_context, mcp__konductro__submit_decomposition_task, mcp__konductro__complete_decomposition
+---
+
+# 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
+
+The user has the target repository/repositories cloned locally. Use Glob, Grep, and Read to understand:
+
+- **Where the change lands** — which modules, services, or components are affected
+- **Existing patterns** — how similar features are already built (routes, services, components)
+- **Data model** — relevant database tables, entities, relationships
+- **API surface** — existing endpoints, request/response shapes
+- **Test patterns** — how tests are structured for this area of the codebase
+- **Dependencies** — what the affected code depends on and what depends on it
+
+Focus your exploration on what's relevant to the story. Don't scan the entire codebase.
+
+### 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 — this is the complete implementation guide that a developer or agent will use. Include ALL of these fields:
+
+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`
+5. **acceptanceCriteria** — specific, testable criteria for this task
+6. **architecturalNotes** — implementation hints, patterns to follow, gotchas
+7. **componentPath** — primary file or directory being changed
+8. **order** — execution order (0-based, tasks with same order can be parallel)
+9. **filesToCreate** — list of new files that need to be created
+10. **filesToModify** — list of `{ path, change }` objects describing what to modify in existing files
+11. **implementationSteps** — ordered step-by-step implementation guide
+12. **outOfScope** — what is explicitly NOT included in this task
+
+### Step 6: Submit Tasks One by One
+
+After the user approves the decomposition, submit each task individually by calling `submit_decomposition_task` once per task. This keeps payloads small and generates the developer brief for each task as it's created.
+
+After ALL tasks are submitted, call `complete_decomposition` with:
+- The story ID
+- A conversation summary capturing key decisions and rationale
+
+Confirm success and let the user know the tasks are available in Konductro.
+
+## Task Decomposition Guidelines
+
+- **Right-size tasks** — each task should be completable in a single focused session. Not too large (multi-day), not too small (trivial rename).
+- **Self-contained** — a task should make sense on its own. Include enough context in the description that someone unfamiliar with the discussion can implement it.
+- **Backend before frontend** — schema/migration tasks 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 to follow.
+- **Include test expectations** — note what tests should be added or updated.
+- **Complete developer brief** — every task must include filesToCreate, filesToModify, implementationSteps, and outOfScope. This is the brief the developer/agent will work from.
+
+## Important Rules
+
+- Always start by loading tasks from Konductro — don't skip this step
+- 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 using `submit_decomposition_task`, then call `complete_decomposition`
+- The conversation summary should explain WHY you decomposed it this way

package/skills/find-prototype/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: find-prototype
+description: Find and download UX prototypes for the current project. Use when a developer wants to reference the approved prototype while building features.
+allowed-tools: Bash, Write, mcp__konductro__find_project_prototypes
+---
+
+# 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 using `curl`:
+
+```bash
+mkdir -p .konductro/prototype
+curl -o .konductro/prototype/index.html "<url>"
+curl -o .konductro/prototype/dashboard.html "<url>"
+# etc.
+```
+
+Use `.konductro/prototype/` (not `./prototype/`) to avoid clashing with the prototype build skill's output directory.
+
+### 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/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: profile-repository
+description: Scan the current repository and submit its profile to Konductro. Use when you want to analyse and register a codebase's tech stack, dependencies, APIs, and architecture.
+allowed-tools: Read, Grep, Glob, Bash, mcp__konductro__profile_repository
+---
+
+# 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 URL. This will be used to match the repo in Konductro.
+
+### 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.
+
+## Important 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/SKILL.md

@@ -0,0 +1,92 @@
+---
+name: prototype
+description: Build a UX prototype for a Konductro engagement. Loads design system and approved documents, generates multi-page HTML locally, publishes to S3, and submits back to Konductro.
+allowed-tools: Read, Grep, Glob, Bash, Write, mcp__konductro__list_prototype_tasks, mcp__konductro__get_prototype_context, mcp__konductro__start_prototype_work, mcp__konductro__request_upload_credentials, mcp__konductro__submit_prototype
+---
+
+# 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 (tokens and components) 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 to the user 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 (name, description)
+- The design system (tokens: colours, typography, spacing; components: buttons, cards, forms, etc.)
+- Approved documents from earlier UX steps (hypotheses, personas, feature matrix)
+- The preview HTML from the Design Studio step (locked visual direction)
+- S3 configuration for publishing
+
+Review all the context carefully. The design system tokens and components define exactly how the prototype should look. The feature matrix defines what screens to build. The preview HTML shows the visual direction that was already approved.
+
+### 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 in the current working directory. Build multi-page HTML files:
+
+**Structure:**
+- `index.html` — landing/home page (entry point)
+- Additional pages as defined by the feature matrix (e.g., `dashboard.html`, `settings.html`, `profile.html`)
+
+**Design rules:**
+- Use **Tailwind CSS via CDN** (`<script src="https://cdn.tailwindcss.com"></script>`)
+- Use **Google Fonts** if the design system specifies typography
+- Apply design system tokens directly: colours as Tailwind config overrides, spacing, border radius, shadows
+- Build components exactly as defined in the design system: buttons, cards, forms, navigation, modals, tables, badges, alerts
+- Every page must include consistent navigation linking to all other pages
+- Pages must be fully self-contained HTML files — no external JS frameworks
+- Make the prototype feel real: use realistic placeholder content, not lorem ipsum
+- Responsive design — should work on desktop and tablet widths at minimum
+
+**Quality bar:**
+- The prototype should look like a real application, not a wireframe
+- Use the approved preview HTML as the visual reference — match its aesthetic
+- Interactive elements should have hover/focus states
+- Forms should have proper labels and structure (they don't need to submit)
+
+### Step 5: Review with User
+
+Let the user know the prototype is ready for review. They can open the HTML files in their browser directly from the `./prototype/` directory. Iterate based on feedback — update files as needed.
+
+### Step 6: Publish to S3
+
+When the user is happy with the prototype:
+
+1. Call `request_upload_credentials` with the job ID to get temporary S3 credentials
+2. Upload each HTML file from `./prototype/` to S3 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>
+```
+
+If `aws` CLI is not available, the upload will fail. In that case, inform the user they need the AWS CLI installed, or offer to try using curl with presigned URLs as a fallback.
+
+### Step 7: Submit to Konductro
+
+After uploading, call `submit_prototype` with:
+- The job ID
+- A `pages` array listing each uploaded file with its filename and title
+
+This marks the task as complete and notifies the SDM.
+
+## Important Rules
+
+- Always start by loading tasks from Konductro — don't skip this step
+- Use the design system tokens and components faithfully — don't invent your own styles
+- The preview HTML from Design Studio is the approved visual direction — match it
+- Build ALL pages defined in the feature matrix, not just a subset
+- Ask the user for feedback before publishing — prototypes are communication tools
+- The `./prototype/` directory stays local after publish for reference
+- Credentials expire in 15 minutes — request fresh ones if upload takes longer

package/skills/start-ticket/SKILL.md

@@ -0,0 +1,56 @@
+---
+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
+---
+
+# 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/SKILL.md

@@ -0,0 +1,83 @@
+---
+name: technical-analysis
+description: Perform a technical analysis for a Konductro project phase. Use when the user wants to analyse a codebase for technical planning — examining patterns, dependencies, risks, and recommending an approach.
+allowed-tools: Read, Grep, Glob, mcp__konductro__list_tech_analysis_tasks, mcp__konductro__get_task_context, mcp__konductro__submit_tech_analysis
+---
+
+# 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
+
+Start by calling `list_tech_analysis_tasks` to see what's assigned to you. Present the list to the user and ask which task they want to work on.
+
+### Step 2: Load Context
+
+Once the user picks a task, 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
+
+Now analyse the local codebase. The user has the repository/repositories cloned in their current working directory. Use Glob, Grep, and Read to explore:
+
+- **Project structure** — folder layout, module organisation
+- **Tech stack** — frameworks, versions, build tools (check package.json, pom.xml, build.gradle, etc.)
+- **Architecture patterns** — how the app is structured (MVC, layered, microservices, etc.)
+- **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, deployment config
+- **Integration points** — external services, message queues, APIs consumed
+
+Discuss your findings with the user as you go. Ask clarifying questions about design decisions, business context, or areas of concern.
+
+### Step 4: Impact Analysis
+
+Based on the requirements and your codebase exploration, assess:
+
+- **What needs to change** — which files, modules, or services need modification
+- **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 the requirements given the current codebase
+
+### Step 5: Produce the Document
+
+When the user is satisfied with the analysis, produce a structured technical analysis document. The document must include:
+
+1. **Codebase Overview** — what exists today (structure, stack, patterns)
+2. **Technical Stack** — frameworks, versions, build tools, deployment
+3. **Architecture Patterns** — how the app is structured, 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 for the requirements
+7. **Risks & Constraints** — technical debt, performance concerns, coupling issues
+8. **Recommended Approach** — how to implement, including sequencing
+9. **Dependencies** — external libraries, services, and inter-module dependencies
+10. **Testing Strategy** — how to test the changes given current test infrastructure
+
+### Step 6: Submit
+
+Ask the user to review the document. When they approve, call `submit_tech_analysis` with:
+- The phase ID from the task
+- The complete document
+- A conversation summary covering: key findings, decisions made, areas of concern discussed
+
+After submission, confirm success and let the user know the document is available in Konductro for review and approval.
+
+## Important Rules
+
+- Always start by loading tasks from Konductro — don't skip this step
+- 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 that an architect can use without additional context
+- The conversation summary should capture the "why" behind decisions, not just the findings