@groupby/ai-dev 0.2.0 → 0.2.3

package/toolsets/toolsets/rzlv-flow/skills/jira-status/SKILL.md

@@ -1,97 +0,0 @@
----
-name: jira-status
-description: Change a Jira ticket's status with transition validation and FCMP sync safety. Fetches current state, verifies status hasn't changed remotely, shows available transitions as a numbered list, and executes the selected transition. Use when you want to move a Jira ticket to a different status.
----
-
-Transition a Jira ticket's status with sync safety. Follows the FCMP protocol — fetches the current state, verifies no remote status change since last sync, presents valid transitions as a numbered list, and executes the selected transition via MCP.
-
-## Requirements
-
-Requires: Atlassian MCP (`atlassian-rovo`). See the rzlv-flow toolset README for setup.
-
-## Resources to Load
-
-Before executing, read this resource file:
-
-- `docs/ai/resources/fcmp-protocol.md` — follow the FCMP protocol for status transitions
-
-## Process
-
-### Step 1: Get Ticket Key
-
-- Use the `focused_ticket` from conversation context if available.
-- Otherwise, ask the user for the ticket key.
-
-### Step 2: FETCH — Get Current State
-
-Fetch the current ticket state via `mcp_atlassian-rovo_fetch()`:
-
-- Current status
-- Assignee and summary (for confirmation context)
-- Version field (for optimistic locking)
-
-### Step 3: COMPARE — Verify No Remote Change
-
-Compare the fetched status against the last known local state (from the `{TICKET-KEY}.md` frontmatter if available).
-
-- If the remote status has changed since last sync, warn the user:
-  ```
-  ⚠️ Status changed remotely: {old_status} → {current_remote_status}
-  Continue with transition from {current_remote_status}? (y/n)
-  ```
-
-### Step 4: Get Available Transitions
-
-Fetch available transitions for the ticket via MCP (e.g. `getTransitionsForJiraIssue` or equivalent).
-
-Present as a numbered list:
-
-```
-Current Status: {current_status}
-
-Available transitions:
-1. {transition_name_1}
-2. {transition_name_2}
-3. {transition_name_3}
-4. Cancel
-
-Choose transition [1]:
-```
-
-Do not assume a standard workflow (To Do → In Progress → Done). Always fetch the actual available transitions, as Jira workflows vary by project.
-
-### Step 5: Execute Transition
-
-After the user selects a transition number:
-
-1. Confirm: "Transition {TICKET-KEY} from {current_status} to {target_status}? (y/n)"
-2. **PUSH** — Execute the transition via MCP.
-3. On success: confirm with the new status.
-4. On failure: report the error (e.g. required fields missing, permission denied, transition not available).
-
-### Step 6: Update Local State
-
-If a local `{TICKET-KEY}.md` file exists:
-
-- Update `sync.status` to the new status
-- Update `sync.last_synced` to the current timestamp
-- Update `sync.version` with the new version from Jira
-
-## Output Format
-
-```
-## 🔄 Status: {TICKET-KEY}
-
-**Current Status:** {current_status}
-
-Available transitions:
-1. {transition_1}
-2. {transition_2}
-3. {transition_3}
-4. Cancel
-
-Choose transition [1]:
-
-{AFTER TRANSITION:}
-✓ {TICKET-KEY} transitioned: {old_status} → {new_status}
-```

package/toolsets/toolsets/rzlv-flow/skills/jira-sync/SKILL.md

@@ -1,148 +0,0 @@
----
-name: jira-sync
-description: Force-sync local Jira context to bring it up to date with the remote state. Runs the full FCMP protocol (Fetch-Compare-Merge-Push) for a specified ticket, showing diffs if remote changes are detected and resolving conflicts with user input. Use when you want to refresh your local Jira mirror or suspect your local state is stale.
----
-
-Force-sync a local Jira ticket file with the remote state. Runs the complete FCMP protocol — fetches the current remote state, compares against the local file, shows diffs if anything changed, and resolves conflicts with user input. Use this when your local state might be stale or after someone else updates the ticket in Jira.
-
-## Requirements
-
-Requires: Atlassian MCP (`atlassian-rovo`). See the rzlv-flow toolset README for setup.
-
-## Resources to Load
-
-Before executing, read these resource files:
-
-- `docs/ai/resources/fcmp-protocol.md` — **critical** — the full FCMP protocol to follow
-- `docs/ai/resources/jira-file-structure.md` — to locate the local ticket file
-- `docs/ai/resources/sync-state-format.md` — YAML frontmatter schema for reading and updating the ticket file
-
-## Process
-
-### Step 1: Get Ticket Key
-
-- Use `focused_ticket` from conversation context if available.
-- Otherwise, ask the user for the ticket key.
-
-### Step 2: Locate Local File
-
-Find the local `{TICKET-KEY}.md` file using the rules in `jira-file-structure.md`:
-
-1. Search under `docs/jira/{instance}/{project}/` for a file matching `{TICKET-KEY}.md`.
-2. It may be in an epic folder (`{epic-name}/stories/{TICKET-KEY}/{TICKET-KEY}.md`) or in `_orphans/`.
-3. If no local file exists, inform the user and offer to create one by fetching from Jira (effectively a first-time sync).
-
-### Step 3: FETCH — Get Remote State
-
-Fetch the full ticket state from Jira via `mcp_atlassian-rovo_fetch()`:
-
-- Summary, description, acceptance criteria
-- Status, assignee, priority, story points
-- Version number (for optimistic locking)
-- Last updated timestamp
-- Recent comments
-
-### Step 4: COMPARE — Diff Local vs Remote
-
-Compare the fetched remote state against the local file:
-
-- **Frontmatter fields:** `sync.status`, `sync.assignee`, `sync.priority`, `sync.story_points`, `sync.version`
-- **Body content:** description, acceptance criteria, technical notes
-- **Timestamps:** `sync.remote_updated` vs the remote `updated_at`
-
-Determine the scenario:
-
-| Scenario | Condition | Action |
-|----------|-----------|--------|
-| Already up to date | `sync.version` matches remote version | Report "Already up to date" |
-| Remote changed only | Remote version is newer, no local modifications | Apply remote changes |
-| Local changed only | Local has edits, remote is same as last sync | No action needed (local changes preserved) |
-| Both changed | Local edits AND remote version is newer | Conflict — proceed to merge |
-
-### Step 5: Show Diff
-
-If changes are detected, present them clearly:
-
-```
-### Changes Detected
-
-{FOR EACH CHANGED FIELD:}
-**{field_name}:**
-- Local: {local_value}
-- Remote: {remote_value}
-
-{FOR BODY CHANGES:}
-**Description:**
-- Lines added remotely: {n}
-- Lines removed remotely: {n}
-{Show abbreviated diff}
-```
-
-### Step 6: MERGE — Resolve Conflicts
-
-If both local and remote have changes:
-
-1. Present the conflict to the user.
-2. Offer resolution strategies:
-   ```
-   Conflict detected. How would you like to resolve?
-   1. Keep remote (discard local changes)
-   2. Keep local (your changes will overwrite on next push)
-   3. Manual merge (I'll show both versions side by side)
-   ```
-3. For **auto-merge** (changes in different sections), combine both changes automatically and confirm with the user.
-4. For **manual merge**, present both versions and let the user edit.
-
-If only the remote changed (no local edits), apply the remote changes directly.
-
-### Step 7: Update Local File
-
-After merge resolution:
-
-1. Write the merged content to the local `{TICKET-KEY}.md` file.
-2. Update frontmatter fields:
-   - `sync.status` — current remote status
-   - `sync.assignee` — current assignee
-   - `sync.priority` — current priority
-   - `sync.story_points` — current story points
-   - `sync.last_synced` — current timestamp
-   - `sync.version` — remote version number
-   - `sync.remote_updated` — remote last updated timestamp
-3. Preserve any `agile_companion` or `orchestrator` metadata that exists.
-
-### Step 8: Report Results
-
-Confirm what changed.
-
-## Output Format
-
-```
-## 🔄 Sync: {TICKET-KEY}
-
-{IF ALREADY UP TO DATE:}
-✓ {TICKET-KEY} is already up to date (version {version})
-
-{IF CHANGES APPLIED:}
-### Changes Applied
-{List of fields updated with old → new values}
-
-- **Status:** {old} → {new}
-- **Assignee:** {old} → {new}
-- **Description:** Updated ({n} lines changed)
-
-✓ Local file synced to version {version} at {timestamp}
-
-{IF CONFLICT RESOLVED:}
-### Conflict Resolved
-- Strategy: {keep_remote | keep_local | auto_merge | manual_merge}
-- Fields affected: {list}
-
-✓ Conflict resolved and local file updated to version {version}
-
-{IF NEW FILE CREATED:}
-### New File Created
-- Path: {relative_path_to_ticket_file}
-- Fetched from Jira: version {version}
-
-✓ Local file created for {TICKET-KEY}
-```

package/toolsets/toolsets/rzlv-flow/skills/jira-ticket-focus/SKILL.md

@@ -1,245 +0,0 @@
----
-name: jira-ticket-focus
-description: Deep-load a Jira ticket with full context for focused work. Fetches ticket details, detects the parent epic, creates or navigates the local file structure, loads linked requirements, checks git branch status, and presents quick actions (branch creation, status transition, assignment). Use when you want to focus on a specific Jira ticket.
----
-
-Deep-load a single Jira ticket for focused development work. Fetches full ticket context via MCP, determines the correct local file location using epic detection and smart structure rules, sets up the developer workspace, checks git branch status, and presents actionable quick actions.
-
-## Requirements
-
-Requires: Atlassian MCP (`atlassian-rovo`). See the rzlv-flow toolset README for setup.
-Optional: Git CLI for branch detection and creation.
-
-## Resources to Load
-
-Before executing, read these resource files — they are critical for correct behavior:
-
-- `docs/ai/resources/fcmp-protocol.md` — follow for all Jira read/write operations
-- `docs/ai/resources/jira-file-structure.md` — **critical** for file placement logic and ownership rules
-- `docs/ai/resources/sync-state-format.md` — YAML frontmatter format for ticket files
-
-## Process
-
-### Step 1: Resolve Ticket Reference
-
-- If the user provides a **number** (e.g. "3"), look it up from the `numbered_ticket_list` stored in conversational context from a prior `jira-daily-triage` run.
-- If the user provides a **Jira key** (e.g. "PROJ-123"), use it directly.
-- If the key is **incomplete** (e.g. "123"), prepend the `confirmed_project` key from session context (e.g. "PROJ-123").
-- If neither a number mapping nor a project key is available, attempt fallback detection:
-  1. **Git branch:** Check the current branch name for a `{PROJECT}-{n}` pattern (e.g. `feature/PROJ-123` → project is `PROJ`).
-  2. **Config file:** Check for a `.jira.json` file in the project root containing `{ "project": "PROJ", "instance": "rezolve" }`.
-  3. If neither yields a project key, ask the user for the full ticket key.
-
-### Step 2: Fetch Ticket Details (FCMP Fetch Step)
-
-Use `mcp_atlassian-rovo_fetch()` to retrieve:
-
-- Summary, description, acceptance criteria
-- Comments and recent history
-- Sprint information (use `active_sprint_name` from session context if available)
-- Linked Confluence documents (if any)
-- **Subtasks** — fetch all subtasks of the ticket via JQL: `parent = {TICKET-KEY} ORDER BY status ASC, priority DESC`
-- **Linked issues** — fetch linked issues (blocks, is blocked by, relates to)
-
-**Parent Epic detection** — check in this order:
-
-1. Check `fields.parent` — if `parent.fields.issuetype.name == "Epic"`, that is the epic.
-2. Check for an Epic Link custom field (varies by instance; commonly `customfield_10014` or similar).
-3. If no epic is found, the ticket is **orphaned**.
-
-Store the epic key and summary for context display and file placement.
-
-### Step 3: Determine Ticket Location (Smart Structure Detection)
-
-Determine where the ticket file lives (or should be created) in the local Jira file structure. Follow the rules from `jira-file-structure.md`:
-
-```
-Base directory: docs/jira/{instance}/{project}/
-```
-
-**If an epic parent was found:**
-
-1. Check if an epic folder already exists locally:
-   ```
-   {base}/*{EPIC-KEY}*/
-   ```
-   (Glob match — the folder may include a slug, e.g. `PROJ-100-user-authentication/`)
-
-2. If the epic folder **exists**, place the ticket at:
-   ```
-   {base}/{epic-folder}/stories/{TICKET-KEY}/{TICKET-KEY}.md
-   ```
-
-3. If the epic folder **does not exist**, create it:
-   ```
-   {base}/{EPIC-KEY}-{epic-summary-slug}/
-   {base}/{EPIC-KEY}-{epic-summary-slug}/stories/
-   ```
-   Then place the ticket at:
-   ```
-   {base}/{EPIC-KEY}-{epic-summary-slug}/stories/{TICKET-KEY}/{TICKET-KEY}.md
-   ```
-   Note in output: "Created new epic folder structure for {EPIC-KEY}"
-
-**If no epic parent (orphan):**
-```
-{base}/_orphans/{TICKET-KEY}/{TICKET-KEY}.md
-```
-
-**If the parent is a Story or Task (i.e. ticket is a subtask):**
-```
-{base}/.../{PARENT-KEY}/subtasks/{TICKET-KEY}/{TICKET-KEY}.md
-```
-
-### Step 4: Load Requirements Context
-
-- **If an epic parent was detected:**
-  - Search for `epic.md` in the epic folder and load it for goals, scope, and technical approach.
-  - Check for a `_docs/` folder with generated documentation (architecture, decisions, strategic context).
-  - Check for linked Confluence documents in the epic or ticket metadata.
-  - If the epic folder was just created and `epic.md` doesn't exist, note that epic context is missing.
-
-- **If no epic or epic folder was not found:**
-  - Search for any related documentation by keyword matching in the project's `_docs/` folders.
-  - Note the gap — the user may want to run `atlassian-orchestrator` to generate context.
-
-### Step 5: Prepare Local Environment
-
-1. **Create or update `{TICKET-KEY}.md`** with sync state frontmatter following the schema in `sync-state-format.md`:
-   - Populate all `sync` fields from the fetched Jira data.
-   - Set `structure.type` based on the issue type.
-   - Set `structure.parent` as a relative path to the parent file (if applicable).
-   - Set `structure.epic` to the epic key (if applicable).
-   - Set `agile_companion.last_focused` to the current timestamp.
-
-2. **Create `_work/` folder** in the ticket directory for developer notes (this folder is gitignored).
-
-3. **Store the fetched Jira state** locally so that future FCMP operations can compare against it.
-
-### Step 6: Check Git Branch Status
-
-Run these git commands to detect branch state:
-
-```bash
-# Current branch
-git branch --show-current
-
-# Local branches matching ticket key
-git branch --list "*{TICKET-KEY}*"
-
-# Remote branches matching ticket key
-git branch -r --list "*{TICKET-KEY}*"
-```
-
-Common branch naming patterns to check:
-- `feature/{TICKET-KEY}`
-- `feature/{TICKET-KEY}-*`
-- `{TICKET-KEY}`
-- `{TICKET-KEY}-*`
-
-Determine which scenario applies:
-
-| Scenario | Condition | Action |
-|----------|-----------|--------|
-| No branch exists | Local and remote checks both empty | Offer to create `feature/{TICKET-KEY}` |
-| Local branch exists, not current | Found in local list, not current branch | Offer to switch |
-| Remote branch exists, not local | Found in remote list, not in local | Offer to checkout |
-| Already on correct branch | Current branch contains ticket key | Show checkmark, no action needed |
-
-### Step 7: Present Work Context
-
-Display the full ticket details, acceptance criteria as a checklist, requirements from loaded context, and technical notes — all in a scannable format.
-
-### Step 8: Offer Quick Actions
-
-Present numbered quick actions based on detected state:
-
-- **Git branch actions** (from Step 6 — only the relevant scenario).
-- **Assignment:** If the ticket is unassigned, offer to assign to the current user.
-- **Status transition:** If the ticket status is "To Do" or "Open", offer to move to "In Progress".
-- Always include a "Skip quick actions" option as the last number.
-
-## Output Format
-
-```
-## 🎯 Focus: {TICKET-KEY} — {Summary}
-
-**Project:** {confirmed_project} | **Epic:** {Epic Key}: {Epic Summary} (or "No Epic (Orphaned)")
-**Assignee:** {assignee or "Unassigned"} | **Status:** {status}
-**Points:** {story_points} | **Priority:** {priority}
-**Sprint:** {active_sprint_name}
-**Current Branch:** {current_git_branch}
-**Local Path:** {relative path to ticket file}
-
-{IF epic folder was just created:}
-✨ Created new epic folder structure for {EPIC-KEY}
-
-### Acceptance Criteria
-- [ ] {criterion 1}
-- [ ] {criterion 2}
-- [ ] {criterion 3}
-
-### Requirements Context
-{Content from epic.md, _docs/, or linked Confluence pages.
-If no context available: "No requirements context found. Consider running atlassian-orchestrator to generate epic documentation."}
-
-### Technical Notes
-{From architecture docs, epic technical notes, or _docs/ folder.
-If none: "No technical notes available."}
-
-### Recent Activity
-- {commenter}: "{comment excerpt}" ({time ago})
-- {commenter}: "{comment excerpt}" ({time ago})
-
----
-**Quick Actions:**
-
-{Based on git branch detection scenario — show only the relevant one:}
-
-{IF NO BRANCH EXISTS:}
-1. Create and switch to new branch: feature/{TICKET-KEY}
-
-{IF LOCAL BRANCH EXISTS BUT NOT CURRENT:}
-1. Switch to existing branch: {branch_name}
-
-{IF REMOTE BRANCH EXISTS BUT NOT LOCAL:}
-1. Checkout remote branch: {branch_name}
-
-{IF ALREADY ON CORRECT BRANCH:}
-✓ Already on feature branch: {branch_name}
-
-{Additional actions based on ticket state:}
-
-{IF UNASSIGNED:}
-{N}. Assign to me and move to "In Progress"
-
-{IF ASSIGNED BUT STATUS IS "To Do"/"Open":}
-{N}. Move to "In Progress"
-
-{ALWAYS:}
-{last}. Skip quick actions — start working as-is
-
-Choose [1]:
-```
-
-## Quick Action Execution
-
-When the user selects a numbered action:
-
-- **Branch creation:** `git checkout -b feature/{TICKET-KEY}`
-- **Branch switch:** `git checkout {branch_name}`
-- **Remote checkout:** `git checkout -b {branch_name} origin/{branch_name}`
-- **Assign to me:** Update the assignee field via MCP, following FCMP protocol. Fetch current state first, then update.
-- **Status transition:** Fetch available transitions via `mcp_atlassian-rovo_fetch()` (or equivalent MCP call for transitions), then execute the transition. Follow FCMP protocol — fetch current state, confirm transition is valid, then push.
-
-After executing any action, confirm what was done and re-display the relevant updated field.
-
-## Session Context
-
-After running, update conversational context with:
-
-- **focused_ticket** — The Jira ticket key currently being worked on
-- **focused_ticket_path** — The local file path for the ticket
-- **working_branch** — The git branch being used (after any branch action)
-
-The user may say "wrap" after completing work, which invokes the `jira-wrap-sync` skill using this context.

package/toolsets/toolsets/rzlv-flow/skills/jira-ticket-trace/SKILL.md

@@ -1,112 +0,0 @@
----
-name: jira-ticket-trace
-description: Trace code back to its Jira requirements. Uses git blame to find the commit, extracts the ticket reference, fetches the ticket and its epic context, and presents the full "why" chain (business context, technical decisions, original requirements). Use when you need to understand why code exists or trace a feature to its origin.
----
-
-Context recovery — trace code back to its Jira requirements. Performs git archaeology to find the originating commit and ticket key, then fetches the full context chain from Jira (ticket, epic, linked docs) to explain *why* the code exists.
-
-## Requirements
-
-Requires: Atlassian MCP (`atlassian-rovo`). See the rzlv-flow toolset README for setup.
-Also uses: Git CLI (`git blame`, `git log`).
-
-## Resources to Load
-
-Before executing, read this resource file:
-
-- `docs/ai/resources/fcmp-protocol.md` — follow read protocols for Jira fetch operations
-
-## Process
-
-### Step 1: Identify Target
-
-Determine what code the user wants to trace. Accept any of:
-
-- A **selected code block** in the editor
-- A **file and line reference** (e.g. `src/auth.ts:42`)
-- A **feature or function name** (e.g. "the rate limiting logic")
-
-If the user provides a feature description rather than a specific location, search the codebase to find the relevant file(s) and line(s) first.
-
-### Step 2: Git Archaeology
-
-Trace the code to its originating commit:
-
-1. Run `git blame -L {start},{end} {file}` to find the commit(s) that introduced the target code.
-2. For the most relevant commit, extract:
-   - Commit hash, author, date
-   - Full commit message: `git log -1 --format="%B" {hash}`
-3. Look for a Jira ticket key in the commit message (pattern: `[A-Z]+-\d+`).
-4. If no ticket key in the commit message, check:
-   - The PR/MR associated with the commit: `git log -1 --format="%s" {hash}` may reference a PR number
-   - The branch name at the time of merge (often contains ticket keys)
-   - Adjacent commits for context
-5. If still no ticket key found, report to the user and offer to search Jira by keyword.
-
-### Step 3: Trace to Jira
-
-Once a ticket key is found:
-
-1. **Fetch ticket details** via `mcp_atlassian-rovo_fetch()` — summary, description, status, acceptance criteria.
-2. **Get the parent epic** — use the same epic detection logic as `jira-ticket-focus`:
-   - Check `fields.parent` for an epic type
-   - Check for Epic Link custom field
-3. **Get linked initiative** (if the epic has a parent or linked initiative).
-4. **Check for linked Confluence docs** in the ticket or epic metadata.
-
-### Step 4: Load Context Chain
-
-Build the full "why" chain by loading available context:
-
-- **Original requirements** — from the ticket description, acceptance criteria, and any linked Confluence requirement pages.
-- **Decision logs** — from `_docs/decisions.md` in the epic folder if it exists locally.
-- **Assumptions** — from technical notes in the ticket or epic documentation.
-- **Strategic context** — from `_docs/strategic-context.md` if available.
-
-If local `_docs/` folders don't exist, note what's available from Jira/Confluence only.
-
-### Step 5: Present the "Why"
-
-Assemble and present the full trace from code to business context.
-
-## Output Format
-
-```
-## 🔍 Why: {code reference}
-
-### Git Trail
-- **Commit:** {hash} by {author} on {date}
-- **Message:** "{commit message}"
-- **Ticket:** {TICKET-KEY}
-{IF PR FOUND:}
-- **PR:** #{pr_number} — {pr_title}
-
-### Business Context
-{From epic or initiative context — the high-level "why" this feature exists.
-If no epic context: "No epic context available for this ticket."}
-
-### Technical Decision
-{From decision logs or technical notes — why this approach was chosen over alternatives.
-If none available: "No decision log found."}
-
-### Original Requirement
-> "{Quote from the ticket description or acceptance criteria that drove this code}"
-— {TICKET-KEY}: {ticket summary}
-
-{IF CONFLUENCE DOCS LINKED:}
-### Related Documentation
-- {Confluence page title}: {url}
-
-### Key Assumptions
-- {Assumption that drove this implementation choice}
-- {Constraint that shaped the approach}
-
----
-Need more context? I can load the full epic documentation or search for related tickets.
-```
-
-## Edge Cases
-
-- **No ticket key found in git history:** Report the commit details and offer to search Jira by keywords from the commit message or code context.
-- **Ticket deleted or inaccessible:** Report the ticket key and note that it may have been moved, deleted, or is in a project you don't have access to.
-- **Multiple commits / multiple tickets:** If git blame shows multiple commits for the target code, trace the most significant one (largest change) and note the others.