chore(claude): add YouTrack command suite
Port create-defect, create-story, estimate-issues, fix-defect, implement-feature and split-story commands, adapted for GitOps (kustomize build + kubectl dry-run gates, NCI routing). implement-feature now walks subtasks, respects blocked-by, and reports cross-project (NCS/NCWF) tasks. Ignore .claude/worktrees. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
Janis Eccarius
Executable
+99
@@ -0,0 +1,99 @@
|
||||
# Create Defect in YouTrack
|
||||
|
||||
Automated defect creation workflow. Topic/hint: `$ARGUMENTS`
|
||||
|
||||
This is the **GitOps** repo (Kustomize / Helm / Argo CD / Kargo on Kubernetes).
|
||||
Defects raised here usually belong to project `NCI`, but routing in Step 5 still
|
||||
applies.
|
||||
|
||||
## Step 1 — Gather Context
|
||||
|
||||
Use `AskUserQuestion` tool to ask the user (max 4 questions at once):
|
||||
|
||||
1. **Component** — Where does the bug occur? (e.g. argocd, kargo, ingress-nginx, cert-manager, postgres, redis, sealed-secrets, a nowchess overlay, a region/deployment)
|
||||
2. **What breaks** — What is the actual (broken) behavior? (sync failure, render error, pod crashloop, cert not issued, etc.)
|
||||
3. **Expected** — What should happen instead?
|
||||
4. **Reproducibility** — Always reproducible? Which cluster/region/overlay triggers it?
|
||||
|
||||
If `$ARGUMENTS` already answers some of these, skip those questions.
|
||||
|
||||
## Step 2 — Research (if needed)
|
||||
|
||||
If the bug involves manifests, overlays, or rendering:
|
||||
- Search repo for relevant paths (`Grep`/`Bash`) under the affected component dir.
|
||||
- Render the suspect path: `kustomize build --enable-helm <path>` and inspect output.
|
||||
- Validate: `kustomize build --enable-helm <path> | kubectl apply --dry-run=client -f -`.
|
||||
- Do NOT guess at root cause. Surface findings before drafting.
|
||||
|
||||
## Step 3 — Draft Defect
|
||||
|
||||
Compose the full defect report using this template:
|
||||
|
||||
```
|
||||
Summary
|
||||
|
||||
[One-sentence description of what is broken.]
|
||||
|
||||
|
||||
Steps to Reproduce
|
||||
|
||||
1. Step one
|
||||
2. Step two
|
||||
3. Step three
|
||||
|
||||
|
||||
Expected Behavior
|
||||
|
||||
[What should happen.]
|
||||
|
||||
|
||||
Actual Behavior
|
||||
|
||||
[What actually happens.]
|
||||
|
||||
|
||||
Environment / Notes
|
||||
|
||||
[Any relevant context: cluster/region, overlay path, Argo CD app name, kustomize/helm versions, error output — only if applicable.]
|
||||
```
|
||||
|
||||
Rules:
|
||||
- Steps must be minimal and reproducible (prefer a `kustomize build` / `kubectl --dry-run` command).
|
||||
- Expected vs actual: concrete and unambiguous.
|
||||
- Omit "Environment / Notes" section if not relevant.
|
||||
|
||||
## Step 4 — Clarify
|
||||
|
||||
Show the draft to the user.
|
||||
**Use `AskUserQuestion` tool to ask:**
|
||||
- Are steps to reproduce complete and accurate?
|
||||
- Severity: Blocker / Critical / Major / Minor / Trivial?
|
||||
- Any related tickets or recent changes to link?
|
||||
|
||||
Incorporate feedback. Repeat until user approves.
|
||||
|
||||
## Step 5 — Determine Project
|
||||
|
||||
> **Project routing rules (always apply these):**
|
||||
> - Infrastructure (Kubernetes, Argo CD, Kargo, pipelines, CI/CD, DB setup, cloud infra) → `NCI`
|
||||
> - Backend code (game engine, bots, API, services, coordinator) → `NCS`
|
||||
> - Frontend code (UI, UX, web app) → `NCWF`
|
||||
|
||||
- Kubernetes / Argo CD / Kargo / pipelines / infrastructure → project: `NCI` (default for this repo)
|
||||
- Backend / coordinator / systems / bot / engine → project: `NCS`
|
||||
- Frontend / UI / UX → project: `NCWF`
|
||||
|
||||
If ambiguous, ask the user.
|
||||
|
||||
## Step 6 — Create Issue
|
||||
|
||||
Call `mcp__youtrack__create_issue` with:
|
||||
- `project`: determined in Step 5
|
||||
- `summary`: concise title describing what is broken (≤72 chars, sentence case)
|
||||
- `description`: full formatted defect report from Step 3 (Markdown)
|
||||
- `type`: `Bug`
|
||||
|
||||
## Step 7 — Report
|
||||
|
||||
Display the created issue ID and URL.
|
||||
Ask if a linked investigation or fix task is needed.
|
||||
Executable
+117
@@ -0,0 +1,117 @@
|
||||
# Create User Story in YouTrack
|
||||
|
||||
Automated user-story creation workflow. Topic/hint: `$ARGUMENTS`
|
||||
|
||||
This is the **GitOps** repo (Kustomize / Helm / Argo CD / Kargo on Kubernetes).
|
||||
Stories raised here usually belong to project `NCI`, but routing in Step 5 still
|
||||
applies. Note: infra work is often framed as a task rather than a user story —
|
||||
use `Task` type when there is no end-user-facing value.
|
||||
|
||||
## Step 1 — Gather Context
|
||||
|
||||
Use `AskUserQuestion` tool to ask the user (max 4 questions at once):
|
||||
|
||||
1. **Domain** — Is this infrastructure work, or does it touch backend/frontend?
|
||||
2. **Actor** — Who benefits? (e.g. operator, developer, deployment pipeline, the platform itself)
|
||||
3. **Action** — What capability/change is needed? (new component, region, rollout strategy, secret, ingress, etc.)
|
||||
4. **Goal/value** — Why? What outcome does it enable? (reliability, security, cost, velocity)
|
||||
|
||||
If `$ARGUMENTS` already answers some of these, skip those questions.
|
||||
|
||||
## Step 2 — Research (if needed)
|
||||
|
||||
If the topic involves unfamiliar manifests, charts, or constraints:
|
||||
- Search the repo for relevant paths (use `Grep`/`Bash`); read `ARCHITECTURE.md` / `CONFIGURATION.md` for structure.
|
||||
- Render relevant overlays: `kustomize build --enable-helm <path>`.
|
||||
- Use `WebSearch` for Helm chart docs, Argo CD / Kargo / Kubernetes API references.
|
||||
- Do NOT guess. Surface findings before drafting.
|
||||
|
||||
## Step 3 — Draft Story
|
||||
|
||||
Compose the full story using this template:
|
||||
|
||||
```
|
||||
As a [type of user/actor]
|
||||
I want to [perform an action / have a capability]
|
||||
So that [achieve a goal or value]
|
||||
|
||||
|
||||
Description
|
||||
|
||||
[Additional context or operational rationale for this story.]
|
||||
|
||||
|
||||
Acceptance Criteria
|
||||
|
||||
[List the specific, measurable criteria that define when this story is done:]
|
||||
|
||||
- Criterion 1
|
||||
- Criterion 2
|
||||
- Criterion 3
|
||||
|
||||
|
||||
Implementation Notes
|
||||
|
||||
[Technical notes: affected components/overlays, charts, regions, design refs, constraints.]
|
||||
```
|
||||
|
||||
Rules:
|
||||
- User story line: plain English, present tense, from the actor's perspective.
|
||||
- Acceptance criteria: testable, unambiguous, one condition each (e.g. "kustomize build renders without error", "Argo CD app syncs healthy").
|
||||
- Implementation notes: optional — only include if there are known constraints, related tickets, or design refs.
|
||||
|
||||
## Step 4 — Clarify Acceptance Criteria
|
||||
|
||||
Show the draft to the user.
|
||||
**Use `AskUserQuestion` tool to ask:**
|
||||
- Are the acceptance criteria complete and correct?
|
||||
- Any implementation constraints to add?
|
||||
- Priority (if known)?
|
||||
|
||||
Incorporate feedback. Repeat until user approves.
|
||||
|
||||
## Step 5 — Determine Project
|
||||
|
||||
> **Project routing rules (always apply these):**
|
||||
> - Infrastructure (Kubernetes, Argo CD, Kargo, pipelines, CI/CD, DB setup, cloud infra) → `NCI`
|
||||
> - Backend code (game engine, bots, API, services, coordinator) → `NCS`
|
||||
> - Frontend code (UI, UX, web app) → `NCWF`
|
||||
|
||||
- Kubernetes / Argo CD / Kargo / pipelines / infrastructure → project: `NCI` (default for this repo)
|
||||
- Backend / coordinator / systems / bot / engine → project: `NCS`
|
||||
- Frontend / UI / UX → project: `NCWF`
|
||||
|
||||
If still ambiguous, ask the user.
|
||||
|
||||
## Step 6 — Create Issue
|
||||
|
||||
Call `mcp__youtrack__create_issue` with:
|
||||
- `project`: determined in Step 5
|
||||
- `summary`: concise title derived from the "I want to" clause (≤72 chars, sentence case)
|
||||
- `description`: full formatted story from Step 3 (Markdown)
|
||||
- `type`: `Task` for purely technical infra work (default here), `Feature` if it delivers user-facing value.
|
||||
|
||||
## Step 7 — Link Issues
|
||||
|
||||
After creation, ask the user (use `AskUserQuestion` if interactive, otherwise infer from context):
|
||||
|
||||
> Are there related issues to link? (skip if none)
|
||||
|
||||
Collect any issue IDs the user mentions. For each, determine the correct relation and call `mcp__youtrack__link_issues`:
|
||||
|
||||
| Situation | Relation to use |
|
||||
|-----------|----------------|
|
||||
| This must be done before another | `blocks` |
|
||||
| Another must be done before this | `is blocked by` |
|
||||
| They share domain or are related | `relates to` |
|
||||
| This is a child of an epic/story | `subtask of` |
|
||||
| This is a parent grouping subtasks | `parent for` |
|
||||
| This depends on another ticket's output | `depends on` |
|
||||
|
||||
If the user mentions an issue in the description or implementation notes (e.g. "see NCS-42", "after NCI-12 is done"), auto-detect and suggest linking it — confirm before creating the link.
|
||||
|
||||
## Step 8 — Report
|
||||
|
||||
Display the created issue ID and URL.
|
||||
List any links created (relation type + linked issue ID).
|
||||
Ask if a linked sub-task or implementation ticket is needed.
|
||||
Executable
+92
@@ -0,0 +1,92 @@
|
||||
# Estimate Issue Time in YouTrack
|
||||
|
||||
Sprint planning time estimator. Issue ID or empty for full current sprint: `$ARGUMENTS`
|
||||
|
||||
This is the **GitOps** repo. Sprint mode defaults to project `NCI`.
|
||||
|
||||
## Step 1 — Determine Scope
|
||||
|
||||
**Single-issue mode** (`$ARGUMENTS` set):
|
||||
- Call `mcp__youtrack__get_issue` on `$ARGUMENTS`.
|
||||
- Proceed with that issue only.
|
||||
|
||||
**Sprint mode** (`$ARGUMENTS` empty):
|
||||
- Call `mcp__youtrack__search_issues` with query `project: NCI Sprints: {current sprint} #Unresolved`.
|
||||
- If query returns 0 results, use `AskUserQuestion` to ask for the sprint name, then retry with `project: NCI Sprints: {name}`.
|
||||
- Collect all returned issues.
|
||||
|
||||
## Step 2 — Build Issue Tree
|
||||
|
||||
For each top-level issue from Step 1:
|
||||
1. Fetch full details via `mcp__youtrack__get_issue`: summary, description, acceptance criteria, Type, existing `Zeitschätzung`, linked issues.
|
||||
2. Identify subtasks from links with relation `subtask of` (i.e. issues where the fetched issue is the parent).
|
||||
3. Recursively fetch subtasks until all leaves are known.
|
||||
4. Group into tree: Epic → Story → Task/Subtask.
|
||||
|
||||
**Leaf node** = issue with no subtask children.
|
||||
**Parent node** = issue that has at least one subtask child.
|
||||
|
||||
## Step 3 — Estimate Leaf Nodes
|
||||
|
||||
For each leaf node:
|
||||
1. Read: summary, description, acceptance criteria, implementation notes.
|
||||
2. If scope is unclear, search the repo (`Grep`/`Bash`) and render affected overlays (`kustomize build --enable-helm <path>`) to gauge complexity.
|
||||
3. Assign estimate using this scale:
|
||||
|
||||
| Size | Criteria | Estimate |
|
||||
|------|----------|----------|
|
||||
| Trivial | Single value/label/tag change, 1-file tweak | 30m |
|
||||
| Small | One overlay/patch, clear scope, no unknowns | 1h–2h |
|
||||
| Medium | New component overlay or chart values + Argo CD app wiring | 3h–5h |
|
||||
| Large | New region/deployment, cross-component, secret + ingress + rollout | 1d–2d |
|
||||
| XL | New cluster/platform component, migration, research spike | 3d–5d |
|
||||
|
||||
4. Record: estimate + one-line reasoning.
|
||||
5. Skip leaf if it already has `Zeitschätzung` set — note it as pre-estimated.
|
||||
|
||||
## Step 4 — Roll Up for Display
|
||||
|
||||
YouTrack auto-sums `Zeitschätzung` from subtasks up to parents — **do not write estimates to parent nodes**.
|
||||
|
||||
Compute display-only rolled-up totals:
|
||||
- Parent total = sum of all descendant leaf estimates (including pre-estimated ones).
|
||||
- Flag any branch where some leaves are missing estimates (partial roll-up).
|
||||
|
||||
## Step 5 — Show Summary + Confirm
|
||||
|
||||
Display full tree with estimates. Format:
|
||||
|
||||
```
|
||||
Epic NCI-10: Multi-region rollout [4h 30m] ← rolled up
|
||||
Story NCI-11: Add eu-central-1 overlay [2h 30m] ← rolled up
|
||||
Task NCI-12: Region kustomization 1h 30m ← leaf (new)
|
||||
Task NCI-13: Argo CD app + sync wave 1h ← leaf (new)
|
||||
Story NCI-14: Cert + ingress for region [2h] ← rolled up
|
||||
Task NCI-15: cert-manager Certificate 2h ← leaf (pre-set, skipped)
|
||||
```
|
||||
|
||||
Legend: `[X]` = display-only roll-up (not written). Plain = will be written to YouTrack.
|
||||
|
||||
If sprint mode, show grand total at bottom:
|
||||
```
|
||||
Sprint total: Xd Yh Zm (N issues, M leaves to update)
|
||||
```
|
||||
|
||||
**Use `AskUserQuestion` tool:**
|
||||
- Does the breakdown look right?
|
||||
- Any estimates to adjust before writing to YouTrack?
|
||||
|
||||
Incorporate all feedback before proceeding.
|
||||
|
||||
## Step 6 — Write Estimates
|
||||
|
||||
On user approval, write estimates **only to leaf nodes** (bottom-up order):
|
||||
- For each leaf with a new estimate, call `mcp__youtrack__update_issue` with field `Zeitschätzung` = approved estimate.
|
||||
- YouTrack period format: `"30m"`, `"1h 30m"`, `"1d"`, `"2d 4h"`.
|
||||
- Skip leaves already pre-estimated.
|
||||
|
||||
## Step 7 — Report
|
||||
|
||||
List all updated issues with set estimates.
|
||||
Show final rolled-up totals per Epic/Story (read back from YouTrack via `mcp__youtrack__get_issue` if needed).
|
||||
In sprint mode, show total sprint estimate.
|
||||
Executable
+141
@@ -0,0 +1,141 @@
|
||||
# Fix Defect from YouTrack
|
||||
|
||||
Automated defect-fix workflow. Ticket ID: `$ARGUMENTS`
|
||||
|
||||
This is the **GitOps** repo (Kustomize / Helm / Argo CD / Kargo). There is no
|
||||
compile/unit-test step — validation gates are:
|
||||
- Render: `kustomize build --enable-helm <path>` (must succeed for every changed path)
|
||||
- Dry-run: `kustomize build --enable-helm <path> | kubectl apply --dry-run=client -f -`
|
||||
|
||||
Run both for **every overlay/path touched by the fix**.
|
||||
|
||||
## Step 1 — Fetch Ticket
|
||||
|
||||
Call `mcp__youtrack__get_issue` with ID `$ARGUMENTS`.
|
||||
Extract and display: summary, description, steps to reproduce, Priority, Subsystem.
|
||||
|
||||
## Step 2 — Create Worktree
|
||||
|
||||
Derive branch name from ticket:
|
||||
- `type` from YouTrack issue type: `bug` → `fix`, `feature`/`task` → `feat`, `refactor` → `refactor`, else `chore`
|
||||
- `scope` from affected component (kebab-case, omit if unclear)
|
||||
- `description` from ticket summary: lowercase, kebab-case, max 40 chars, drop articles
|
||||
|
||||
Branch format: `<type>/<ticket-id>-<description>`
|
||||
Example: `fix/NCI-123-argocd-app-sync-loop`
|
||||
|
||||
Call `EnterWorktree` with that branch name.
|
||||
All subsequent file work happens inside this worktree.
|
||||
|
||||
## Step 3 — Identify Root Cause (read-only)
|
||||
|
||||
1. Render the suspect path(s): `kustomize build --enable-helm <path>` — capture errors.
|
||||
2. Dry-run validate: `kustomize build --enable-helm <path> | kubectl apply --dry-run=client -f -` — capture failures.
|
||||
3. Spawn `cavecrew-investigator` with: ticket description + render/dry-run output → locate root cause (files, line numbers, what's wrong).
|
||||
4. **If anything is ambiguous (reproduction unclear, scope uncertain, conflicting signals), use `AskUserQuestion` tool to ask — max 4 questions at once.**
|
||||
5. **Report findings to user. No file writes yet. Wait for acknowledgement before continuing.**
|
||||
|
||||
## Step 3b — Complexity Assessment + Subtasks
|
||||
|
||||
After root cause confirmed, assess scope:
|
||||
|
||||
**Simple** (1–2 files, single overlay, < 1 hour estimated): proceed directly to Step 4.
|
||||
|
||||
**Complex** (3+ files, multiple components/regions, or estimated > 1 hour): create subtasks before changing manifests.
|
||||
|
||||
To create subtasks:
|
||||
1. Break fix into discrete, independently-completable tasks (e.g. "Fix sync-wave annotation on argocd app", "Patch ingress host in eu-central-1 overlay", "Update sealed-secret for redis").
|
||||
2. For each subtask call `mcp__youtrack__create_issue` with:
|
||||
- `project`: based on subtask content — do **not** inherit from parent. Infrastructure → `NCI`; backend code → `NCS`; frontend/UI → `NCWF`. If ambiguous, ask user.
|
||||
- `summary`: concise action-oriented title
|
||||
- `type`: `Task`
|
||||
- `description`: what to do and why
|
||||
3. Call `mcp__youtrack__link_issues` to link each subtask to `$ARGUMENTS` with relation `subtask of`.
|
||||
4. Check if the ticket description or comments mention other issue IDs. For each mentioned ID, suggest a link and confirm with user:
|
||||
- Fix depends on another fix finishing first → `is blocked by`
|
||||
- This fix blocks another ticket → `blocks`
|
||||
- Logically related but independent → `relates to`
|
||||
5. List created subtask IDs and any additional links to user.
|
||||
|
||||
Then proceed to Step 4, implementing subtasks in order.
|
||||
|
||||
## Step 4 — Fix
|
||||
|
||||
1. Implement fix (use the `general-purpose` agent for non-trivial multi-file changes; inline edits for small ones).
|
||||
2. For **every changed path**, run `kustomize build --enable-helm <path>` — must render without error.
|
||||
3. For **every changed path**, run `kustomize build --enable-helm <path> | kubectl apply --dry-run=client -f -` — must pass.
|
||||
4. If the change touches secrets, re-seal as required (`scripts/seal-secrets.sh`) — never commit plaintext secrets.
|
||||
- **Do NOT proceed to Step 5 until all changed paths render and dry-run clean.**
|
||||
If any step fails, iterate until all pass.
|
||||
|
||||
## Step 5 — Review
|
||||
|
||||
Spawn `cavecrew-reviewer` on the full diff.
|
||||
Display findings grouped by severity.
|
||||
|
||||
## Step 5b — Apply Review Findings
|
||||
|
||||
If the review produced any findings (any severity):
|
||||
1. Implement all agreed fixes.
|
||||
2. Re-render + re-dry-run every changed path (Step 4.2–4.3) — must be clean.
|
||||
3. Re-spawn `cavecrew-reviewer` on the updated diff to confirm all findings are resolved.
|
||||
|
||||
Repeat until review is clean or user explicitly accepts remaining findings.
|
||||
|
||||
## Step 6 — Confirm + Push
|
||||
|
||||
Show summary: ticket, branch, files changed, review findings.
|
||||
**Use `AskUserQuestion` tool to ask for explicit approval before pushing.** Include any open questions about commit message scope or body if unclear.
|
||||
|
||||
On approval, commit following Conventional Commits:
|
||||
|
||||
```
|
||||
<type>(<scope>): <short description, imperative, ≤50 chars>
|
||||
|
||||
<optional body: what changed and why, wrap at 72 chars>
|
||||
|
||||
Closes $ARGUMENTS
|
||||
https://knockoutwhist.youtrack.cloud/issue/$ARGUMENTS
|
||||
```
|
||||
|
||||
- `type`: same as branch type (`fix`, `feat`, `refactor`, `chore`, etc.)
|
||||
- `scope`: affected component (`argocd`, `kargo`, `nowchess`, `ingress-nginx`, `cert-manager`, `postgres`, `redis`, `sealed-secrets`, `metrics-server`, or region e.g. `eu-central-1`, `htwg-1`)
|
||||
- Subject: imperative mood, no period, lowercase
|
||||
- Footer `Closes $ARGUMENTS` and ticket URL always present
|
||||
|
||||
Push branch to remote.
|
||||
|
||||
## Step 7 — Comment on Ticket
|
||||
|
||||
After successful push, call `mcp__youtrack__add_issue_comment` on `$ARGUMENTS` with:
|
||||
|
||||
```
|
||||
Branch `<branch-name>` pushed.
|
||||
|
||||
<one-sentence summary of what was changed and why>
|
||||
|
||||
Files changed:
|
||||
- <file1>
|
||||
- <file2>
|
||||
```
|
||||
|
||||
## Step 7b — Additional Links
|
||||
|
||||
After commenting, ask the user if `$ARGUMENTS` should be linked to any other issues not already linked:
|
||||
|
||||
| Situation | Relation |
|
||||
|-----------|---------|
|
||||
| This fix blocks another open ticket | `blocks` |
|
||||
| Another ticket must ship first | `is blocked by` |
|
||||
| Related defect or story | `relates to` |
|
||||
| Duplicate of another defect | `duplicates` |
|
||||
|
||||
Scan the ticket description and comments for any issue IDs that were mentioned but not yet linked. Suggest those automatically.
|
||||
|
||||
Call `mcp__youtrack__link_issues` for each confirmed link.
|
||||
|
||||
## Step 8 — Cleanup
|
||||
|
||||
Call `ExitWorktree` with `discard_changes: true` to delete the worktree.
|
||||
(Branch was pushed in step 6 — commits are safe on remote; `discard_changes: true` bypasses the local-ahead guard.)
|
||||
Report: branch pushed, ticket commented, links created, worktree deleted, done.
|
||||
Executable
+154
@@ -0,0 +1,154 @@
|
||||
# Implement Feature from YouTrack
|
||||
|
||||
Automated feature-implementation workflow. Ticket ID: `$ARGUMENTS`
|
||||
|
||||
This is the **GitOps** repo (Kustomize / Helm / Argo CD / Kargo). In-project =
|
||||
`NCI`. There is no compile/unit-test step — validation gates are:
|
||||
- Render: `kustomize build --enable-helm <path>` (must succeed for every changed path)
|
||||
- Dry-run: `kustomize build --enable-helm <path> | kubectl apply --dry-run=client -f -`
|
||||
|
||||
This workflow implements the given ticket **and all of its subtasks**, while
|
||||
respecting `blocked by` dependencies. Tasks that live in other projects
|
||||
(`NCS`, `NCWF`, or any project other than `NCI`) are never edited here — they
|
||||
are collected and reported at the end with a ready-to-run prompt.
|
||||
|
||||
## Step 1 — Fetch Ticket + Build Task Tree
|
||||
|
||||
1. Call `mcp__youtrack__get_issue` with ID `$ARGUMENTS`.
|
||||
2. Extract and display: summary, description, acceptance criteria, Priority, Subsystem, and the **issue links**.
|
||||
3. From the links, build the task tree:
|
||||
- **Subtasks** = issues linked as `subtask of` / `parent for` (children of `$ARGUMENTS`). Recurse: fetch each subtask with `get_issue` and collect its subtasks too.
|
||||
- **Blocked-by** = for every task in the tree, record issues linked as `is blocked by`.
|
||||
4. Classify each task by project (the prefix before the dash in the issue ID):
|
||||
- **In-project** = `NCI`.
|
||||
- **Out-of-project** = `NCS`, `NCWF`, or any other prefix. These are **never implemented here**.
|
||||
5. Display the full tree: root, subtasks (nested), and for each its blockers + project tag.
|
||||
|
||||
## Step 2 — Resolve Implementation Order
|
||||
|
||||
1. Filter to **in-project (`NCI`), not-yet-resolved** tasks only (root + subtasks). Out-of-project tasks are excluded from implementation.
|
||||
2. Topologically sort by `blocked by`: a task is only implementable once all its in-project blockers are resolved.
|
||||
3. A task is **blocked** (cannot start) if any blocker is:
|
||||
- an in-project task that is not yet resolved in this run, **or**
|
||||
- an out-of-project task (`NCS`/`NCWF`/etc.) — these can't be resolved here.
|
||||
4. Produce two lists:
|
||||
- **Implementable order** — `NCI` tasks, dependency-sorted.
|
||||
- **Blocked tasks** — with the blocker(s) that stop them.
|
||||
5. **Report both lists to the user.** Wait for acknowledgement before continuing.
|
||||
|
||||
## Step 3 — Create Worktree
|
||||
|
||||
Derive branch name from the root ticket `$ARGUMENTS`:
|
||||
- `type` from YouTrack issue type: `feature`/`task` → `feat`, `refactor` → `refactor`, `bug` → `fix`, else `chore`
|
||||
- `scope` from affected component (kebab-case, omit if unclear)
|
||||
- `description` from ticket summary: lowercase, kebab-case, max 40 chars, drop articles
|
||||
|
||||
Branch format: `<type>/<ticket-id>-<description>`
|
||||
Example: `feat/NCI-456-add-eu-central-1-region`
|
||||
|
||||
Call `EnterWorktree` with that branch name.
|
||||
All subsequent file work happens inside this worktree. All implementable
|
||||
tasks (root + subtasks) are implemented on this one branch.
|
||||
|
||||
## Step 4 — Understand Requirements (read-only)
|
||||
|
||||
1. Render the relevant baseline overlays (`kustomize build --enable-helm <path>`) — confirm they render clean before changing anything.
|
||||
2. For the root + each implementable subtask, spawn `cavecrew-investigator` with: that task's description + acceptance criteria → locate affected components/overlays, charts, Argo CD apps, regions, integration touch-points. Use `ARCHITECTURE.md` / `CONFIGURATION.md` for structure.
|
||||
3. **If anything is ambiguous (scope unclear, acceptance criteria missing, design decisions needed), use `AskUserQuestion` tool to ask — max 4 questions at once.**
|
||||
4. **Report plan to user: per task — what will be added/changed, which paths, which components. No file writes yet. Wait for acknowledgement before continuing.**
|
||||
|
||||
## Step 5 — Implement (per task, in dependency order)
|
||||
|
||||
For each task in the implementable order from Step 2, do the following before moving to the next:
|
||||
|
||||
1. Implement task (use the `general-purpose` agent for non-trivial multi-file changes; inline edits for small ones).
|
||||
2. For **every changed path**, run `kustomize build --enable-helm <path>` — must render without error.
|
||||
3. For **every changed path**, run `kustomize build --enable-helm <path> | kubectl apply --dry-run=client -f -` — must pass.
|
||||
4. If the change touches secrets, re-seal as required (`scripts/seal-secrets.sh`) — never commit plaintext secrets.
|
||||
- **Do NOT proceed to the next task until all changed paths render and dry-run clean.**
|
||||
|
||||
If any step fails, iterate until all pass. Once a task is fully validated it
|
||||
counts as **resolved** for the purpose of unblocking later tasks — re-check
|
||||
Step 2's blocked list: any task whose blockers are now all resolved becomes
|
||||
implementable.
|
||||
|
||||
## Step 6 — Review
|
||||
|
||||
Spawn `cavecrew-reviewer` on the full diff (covering all implemented tasks).
|
||||
Display findings grouped by severity.
|
||||
|
||||
## Step 6b — Apply Review Findings
|
||||
|
||||
If the review produced any findings (any severity):
|
||||
1. Implement all agreed fixes.
|
||||
2. Re-render + re-dry-run every changed path (Step 5.2–5.3) — must be clean.
|
||||
3. Re-spawn `cavecrew-reviewer` on the updated diff to confirm all findings are resolved.
|
||||
|
||||
Repeat until review is clean or user explicitly accepts remaining findings.
|
||||
|
||||
## Step 7 — Confirm + Push
|
||||
|
||||
Show summary: root ticket, implemented subtasks, branch, files changed, review findings.
|
||||
**Use `AskUserQuestion` tool to ask for explicit approval before pushing.** Include any open questions about commit message scope or body if unclear.
|
||||
|
||||
On approval, commit following Conventional Commits:
|
||||
|
||||
```
|
||||
<type>(<scope>): <short description, imperative, ≤50 chars>
|
||||
|
||||
<optional body: what changed and why, wrap at 72 chars>
|
||||
|
||||
Closes $ARGUMENTS
|
||||
<also list Closes <ID> for each implemented subtask>
|
||||
https://knockoutwhist.youtrack.cloud/issue/$ARGUMENTS
|
||||
```
|
||||
|
||||
- `type`: same as branch type (`feat`, `refactor`, `chore`, etc.)
|
||||
- `scope`: affected component (`argocd`, `kargo`, `nowchess`, `ingress-nginx`, `cert-manager`, `postgres`, `redis`, `sealed-secrets`, `metrics-server`, or region e.g. `eu-central-1`, `htwg-1`)
|
||||
- Subject: imperative mood, no period, lowercase
|
||||
- Footer `Closes <ID>` for the root and every resolved subtask, plus the root ticket URL.
|
||||
|
||||
Push branch to remote.
|
||||
|
||||
## Step 8 — Comment on Tickets
|
||||
|
||||
After successful push, call `mcp__youtrack__add_issue_comment` on `$ARGUMENTS` **and on each implemented subtask** with:
|
||||
|
||||
```
|
||||
Branch `<branch-name>` pushed.
|
||||
|
||||
<one-sentence summary of what was added and why>
|
||||
|
||||
Files changed:
|
||||
- <file1>
|
||||
- <file2>
|
||||
```
|
||||
|
||||
## Step 9 — Cleanup
|
||||
|
||||
Call `ExitWorktree` with `discard_changes: true` to delete the worktree.
|
||||
(Branch was pushed in step 7 — commits are safe on remote; `discard_changes: true` bypasses the local-ahead guard.)
|
||||
|
||||
## Step 10 — Report Blocked + Cross-Project Tasks
|
||||
|
||||
Final report to the user, in two sections:
|
||||
|
||||
### Blocked in-project tasks
|
||||
List any `NCI` tasks that could **not** be implemented, with the blocker(s)
|
||||
that stopped them. (These can be re-run with this command once blockers clear.)
|
||||
|
||||
### Cross-project tasks (NCS / NCWF / other)
|
||||
For every out-of-project task discovered in the tree (whether it was a subtask
|
||||
or a blocker), output one entry:
|
||||
|
||||
```
|
||||
- <ID> [<PROJECT>]: <summary>
|
||||
Prompt: /implement-feature <ID>
|
||||
```
|
||||
|
||||
Where `Prompt` is a short, copy-pasteable instruction to implement that task in
|
||||
its own project — e.g. the ticket ID plus a one-line description of what the
|
||||
other project needs to do so this project's blocked tasks can proceed.
|
||||
|
||||
End with: branch pushed, tickets commented, worktree deleted, plus the counts of
|
||||
implemented / blocked / cross-project tasks.
|
||||
Executable
+112
@@ -0,0 +1,112 @@
|
||||
# Split Story into Subtasks in YouTrack
|
||||
|
||||
Split a user story into smaller, implementable subtasks. Story ID: `$ARGUMENTS`
|
||||
|
||||
This is the **GitOps** repo. Infrastructure subtasks route to `NCI`.
|
||||
|
||||
## Step 1 — Fetch Story
|
||||
|
||||
Call `mcp__youtrack__get_issue` with ID `$ARGUMENTS`.
|
||||
Extract and display: summary, description, acceptance criteria, implementation notes.
|
||||
|
||||
## Step 2 — Research (if needed)
|
||||
|
||||
If the story involves unfamiliar manifests, charts, or constraints:
|
||||
- Search repo for relevant paths (`Grep`/`Bash`); read `ARCHITECTURE.md` / `CONFIGURATION.md`.
|
||||
- Render affected overlays: `kustomize build --enable-helm <path>`.
|
||||
- Use `WebSearch` for Helm chart / Argo CD / Kargo / Kubernetes API references.
|
||||
- Do NOT guess. Surface findings before proposing splits.
|
||||
|
||||
## Step 3 — Propose Split
|
||||
|
||||
Analyse the story and propose a set of subtasks. Rules:
|
||||
- Each subtask = one unit of work, completable independently or in sequence.
|
||||
- No subtask should exceed ~2 days of work.
|
||||
- Name subtasks in imperative mood (e.g. "Add region kustomization", "Wire Argo CD app + sync wave", "Add cert-manager Certificate").
|
||||
- Cover the full scope of the parent story — no gaps.
|
||||
|
||||
Show proposed subtask list to user (titles only) and ask:
|
||||
**Use `AskUserQuestion` tool:**
|
||||
- Does the split look right?
|
||||
- Any subtasks to add, remove, or merge?
|
||||
- Should any subtask be assigned to a specific person?
|
||||
|
||||
Incorporate feedback. Repeat until user approves the list.
|
||||
|
||||
## Step 4 — Draft Each Subtask
|
||||
|
||||
For each approved subtask, compose description using this template:
|
||||
|
||||
```
|
||||
[Brief description of what needs to be done for this subtask.]
|
||||
|
||||
|
||||
Steps / Tasks
|
||||
|
||||
- Task 1
|
||||
- Task 2
|
||||
- Task 3
|
||||
|
||||
|
||||
Definition of Done
|
||||
|
||||
What must be true for this subtask to be considered complete:
|
||||
|
||||
- Manifests / overlays updated
|
||||
- `kustomize build` renders clean and `kubectl apply --dry-run=client` passes
|
||||
- Reviewed and merged (Argo CD syncs healthy if applicable)
|
||||
```
|
||||
|
||||
Rules:
|
||||
- Steps/Tasks: concrete, ordered where order matters.
|
||||
- Definition of Done: adjust per subtask — not all subtasks need the same criteria (e.g. a research spike has different DoD than a manifest change).
|
||||
- Keep description short — one paragraph max.
|
||||
|
||||
## Step 5 — Determine Project per Subtask
|
||||
|
||||
Assign each subtask's project based on its content — do **not** inherit blindly from parent:
|
||||
|
||||
- Infrastructure (Kubernetes, Argo CD, Kargo, pipelines, CI/CD, DB setup) → `NCI`
|
||||
- Backend code (game engine, bots, API, services, coordinator) → `NCS`
|
||||
- Frontend code (UI, UX, web app) → `NCWF`
|
||||
|
||||
If a subtask's project is ambiguous, ask the user before creating it.
|
||||
|
||||
## Step 6 — Create Subtasks
|
||||
|
||||
For each subtask call `mcp__youtrack__create_issue` with:
|
||||
- `project`: from Step 5
|
||||
- `summary`: subtask title (≤72 chars, sentence case)
|
||||
- `description`: full formatted description from Step 4 (Markdown)
|
||||
- `type`: `Task`
|
||||
|
||||
Then call `mcp__youtrack__link_issues` to link each created subtask to `$ARGUMENTS` with relation `subtask of`.
|
||||
|
||||
## Step 6b — Inter-Subtask Links
|
||||
|
||||
If subtasks must be done in sequence (one depends on output of another), add ordering links:
|
||||
- For each dependency pair call `mcp__youtrack__link_issues` with relation `is blocked by` (subtask B is blocked by subtask A).
|
||||
|
||||
Ask the user to confirm sequencing before adding these links:
|
||||
|
||||
> Do any subtasks have ordering dependencies? (e.g. "Add region kustomization must come before Wire Argo CD app")
|
||||
|
||||
## Step 6c — External Links
|
||||
|
||||
Scan `$ARGUMENTS` description and implementation notes for any referenced issue IDs not already linked. For each:
|
||||
|
||||
| Situation | Relation |
|
||||
|-----------|---------|
|
||||
| Parent story blocks another epic/story | `blocks` |
|
||||
| Story depends on another epic completing | `is blocked by` |
|
||||
| Related story in same domain | `relates to` |
|
||||
| This story duplicates or supersedes | `duplicates` |
|
||||
|
||||
Suggest links to the user and call `mcp__youtrack__link_issues` on confirmation.
|
||||
|
||||
## Step 7 — Report
|
||||
|
||||
List all created subtask IDs and summaries.
|
||||
List all links created (subtask-of, blocking chains, external).
|
||||
Display parent story link.
|
||||
Ask if any subtask needs further splitting.
|
||||
@@ -109,3 +109,6 @@ fabric.properties
|
||||
# kustomization.yaml and *.yaml are tracked; raw *.yml files are not
|
||||
secrets/**/*.yml
|
||||
/scripts/sealed-secrets-key-backup.yaml
|
||||
|
||||
# Claude Code
|
||||
/.claude/worktrees/
|
||||
|
||||
Reference in New Issue
Block a user