a65d748f99
Port create-defect, create-story, estimate-issues, fix-defect, implement-feature and split-story commands, adapted for the Angular frontend (npm build/test, prettier gates, NCWF routing). implement-feature now walks subtasks, respects blocked-by, and reports cross-project (NCS/NCI) tasks. Ignore .claude/worktrees. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
160 lines
7.5 KiB
Markdown
160 lines
7.5 KiB
Markdown
# Implement Feature from YouTrack
|
|
|
|
Automated feature-implementation workflow. Ticket ID: `$ARGUMENTS`
|
|
|
|
This is the **NowChess-Frontend** repo (Angular 20 / TypeScript). In-project =
|
|
`NCWF`. Gates:
|
|
- Build: `npm run build`
|
|
- Test: `npm test -- --watch=false --browsers=ChromeHeadless`
|
|
- Format: `npx prettier --write .` (check with `npx prettier --check .`)
|
|
|
|
This workflow implements the given ticket **and all of its subtasks**, while
|
|
respecting `blocked by` dependencies. Tasks that live in other projects
|
|
(`NCS`, `NCI`, or any project other than `NCWF`) 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** = `NCWF`.
|
|
- **Out-of-project** = `NCS`, `NCI`, 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 (`NCWF`), 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`/`NCI`/etc.) — these can't be resolved here.
|
|
4. Produce two lists:
|
|
- **Implementable order** — `NCWF` 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 area (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/NCWF-456-add-board-theme-selector`
|
|
|
|
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. Run `npm run build` — confirm baseline is green.
|
|
2. Run `npm test -- --watch=false --browsers=ChromeHeadless` — confirm baseline is green.
|
|
3. For the root + each implementable subtask, spawn `cavecrew-investigator` with: that task's description + acceptance criteria → locate affected files under `src/app/`, relevant components/services/models, routes, integration touch-points.
|
|
4. **If anything is ambiguous (scope unclear, acceptance criteria missing, design decisions needed), use `AskUserQuestion` tool to ask — max 4 questions at once.**
|
|
5. **Report plan to user: per task — what will be added/changed, which files, which areas. 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. Run `npm run build` — must be green.
|
|
3. Run `npm test -- --watch=false --browsers=ChromeHeadless` — must be green (add new specs for new behaviour; do not modify existing specs unless requirements changed).
|
|
4. Run `npx prettier --write .` — **blocking, foreground only**. Wait for completion before continuing.
|
|
5. Run `npx prettier --check .` — **blocking, foreground only** (never `run_in_background`). Wait for exit code 0. Must be green.
|
|
- If it fails, fix all issues and re-run until exit code 0.
|
|
- **Do NOT proceed to the next task until build, tests and format check all pass.**
|
|
|
|
If any step fails, iterate until all pass. Once a task is fully green 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. Run `npm run build` — must be green.
|
|
3. Run `npm test -- --watch=false --browsers=ChromeHeadless` — must be green.
|
|
4. Run `npx prettier --write .` then `npx prettier --check .` — **blocking, foreground only**. Wait for exit code 0.
|
|
5. 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 area (`ui`, `components`, `services`, `models`, `core`, `routing`, `pages`, `styles`)
|
|
- 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 `NCWF` 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 / NCI / 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.
|