@staff0rd/assist 0.347.0 → 0.349.0

package/README.md

@@ -42,6 +42,7 @@ After installation, the `assist` command will be available globally. You can als
 
 - `/add-command` - Add a new run command to assist.yml
 - `/associate-jira <KEY> [id]` - Associate a Jira ticket with the backlog item this session is working on (or an explicit id) by calling `assist backlog associate-jira`
+- `/branch <description> [--jira KEY]` - Create a branch off the fresh remote default via `assist branch`, deriving a kebab-case slug from the description and auto-filling the Jira key from the session's backlog item when one is associated
 - `/bug` - File a bug with reproduction steps, expected and actual behavior
 - `/comment` - Add pending review comments to the current PR
 - `/commit` - Commit only relevant files from the session
@@ -58,6 +59,7 @@ After installation, the `assist` command will be available globally. You can als
 - `/restructure` - Analyze and restructure tightly-coupled files
 - `/review-comments` - Process PR review comments one by one
 - `/jira` - View a Jira work item
+- `/update-jira [JIRA-KEY]` - Post a concise summary of this session's findings to a Jira ticket via MCP; attaches a passed key to the session's backlog item (else reads the key from it), retargets sub-task comments to the parent, and previews the comment before posting on confirmation
 - `/journal` - Append a journal entry summarising recent work, decisions, and notable observations
 - `/next [id]` - Signal completion and chain into the next backlog item; pass an `id` to run a specific item directly (falls back to the picker if the id is missing, done, won't-do, or blocked)
 - `/standup` - Summarise recent journal entries as a standup update
@@ -93,7 +95,7 @@ After installation, the `assist` command will be available globally. You can als
 - `assist commit status` - Show git status and diff
 - `assist commit <message>` - Commit staged changes with validation
 - `assist commit <message> [files...]` - Stage files and create a git commit with validation
-- `assist branch <slug> [--jira <key>]` - Create and switch to a new branch off the fresh remote default branch. Assembles the name as `[<prefix>/][<JIRA>-]<slug>` (prefix from the optional `branch.prefix` config, Jira key used verbatim), fetches and branches from `origin/<default>` (resolved dynamically, not hardcoded to main), and rejects slugs whose numeric tokens look like backlog IDs
+- `assist branch <slug> [--jira <key>]` - Create and switch to a new branch off the fresh remote default branch. Assembles the name as `[<prefix>/][<JIRA>-]<slug>` (prefix from the optional `branch.prefix` config, Jira key used verbatim), fetches and branches from `origin/<default>` (resolved live from the remote, falling back to `main`, overridable via `branch.defaultBranch`), and rejects slugs whose numeric tokens look like backlog IDs
 - `assist prs` - List pull requests for the current repository
 - `assist prs raise --title <title> --what <what> --why <why> [--how <how>] [--resolves <key>] [--force]` - Raise a pull request, assembling the body from `## What`, `## Why` (with `--resolves` Jira URLs appended inline), and an optional `## How`; errors if a PR already exists unless `--force` overwrites its title and body
 - `assist prs edit [--title <title>] [--what <what>] [--why <why>] [--how <how>] [--resolves <key>]` - Update only the supplied sections of the current branch's pull request, preserving every other section of its body
@@ -298,6 +300,8 @@ When `commit.expectedBranch` is set (e.g. `main`), `assist commit` prints a prom
 
 When `branch.prefix` is set (e.g. `sw`), `assist branch <slug>` prepends `<prefix>/` to the branch name. With the key unset, no prefix segment is added.
 
+`assist branch` resolves the base branch live from the remote (`git ls-remote --symref origin HEAD`), so it never depends on a stale or unset local `origin/HEAD`. If the remote advertises no default it falls back to `main`. Set `branch.defaultBranch` (e.g. `develop`) to override the base branch outright.
+
 ## netcap browser extension
 
 `assist netcap` only runs the receiver; the browser side is a raw Manifest V3 extension (no build step) under `netcap-extension/`. A MAIN-world content script patches `fetch`/`XMLHttpRequest` to capture `{url, method, status, requestBody, responseBody, timestamp}`, relays each entry to the background service worker (`window.postMessage` → `chrome.runtime.sendMessage`), and the background worker POSTs it to the receiver. The XHR patch reads the response across every `responseType` (`json`, `blob`, `arraybuffer`, `document`, not just `text`) — LinkedIn's voyager GraphQL calls use `responseType: "json"`, which exposes no `responseText`, so reading `responseText` alone captured those bodies empty. Forwarding happens in the background context, so the page's CSP (`connect-src`) never blocks it — the limitation that killed the earlier console-paste approach.

package/claude/commands/branch.md

@@ -0,0 +1,34 @@
+---
+description: Create a branch off the fresh remote default via assist branch
+allowed_args: "<description of the work> [--jira KEY]"
+---
+
+You are creating a git branch by calling the `assist branch` CLI command, which fetches and branches off the fresh remote default (`origin/<default>`) and enforces the team naming convention.
+
+## Step 1: Derive the slug
+
+`$ARGUMENTS` is a free-text description of the work (e.g. "add login form"). Turn it into a concise kebab-case slug: lowercase, words joined by hyphens, no leading/trailing punctuation (e.g. `add-login-form`).
+
+Do not put backlog item numbers in the slug — `assist branch` rejects bare 1–4 digit numeric tokens and `#<number>` references, because they look like internal backlog IDs. If the description contains such a number, drop or reword it (e.g. "fix 404 page" → `fix-not-found-page`).
+
+## Step 2: Resolve the Jira key
+
+If `$ARGUMENTS` contains an explicit `--jira <KEY>` (or a bare `[A-Z]+-\d+` token), use that key.
+
+Otherwise, if this session is working on a backlog item, read its associated Jira key:
+
+```
+assist backlog show <id> 2>&1
+```
+
+If the output includes a `Jira: <KEY>` line, use that key. If there is no session item or no associated key, omit `--jira` entirely.
+
+## Step 3: Create the branch
+
+Run the command with the resolved slug and optional key:
+
+```
+assist branch <slug> --jira <KEY> 2>&1
+```
+
+Omit `--jira <KEY>` when no key was resolved. Display the command output so the user sees the created branch name and the `origin/<default>` it was based on. If the command reports an error (invalid slug, git failure), relay it to the user — no branch is created on failure.

package/claude/commands/update-jira.md

@@ -0,0 +1,53 @@
+---
+description: Post a concise summary of this session's findings to a Jira ticket
+allowed_args: "[JIRA-KEY]"
+---
+
+You are posting a concise comment summarising this session's findings to a Jira ticket via the Atlassian MCP. If a key is passed it is first attached to the session's current backlog item; otherwise the key is read from that item.
+
+## Step 1: Resolve the session's backlog item
+
+Determine the backlog item this session is working on — the one you are implementing, reviewing, or otherwise focused on (e.g. via `/next-backlog-item`, a `backlog run`, or earlier in this conversation). You need its id for the steps below.
+
+## Step 2: Resolve the Jira key
+
+If `$ARGUMENTS` contains a Jira key (matches `[A-Z]+-\d+`), attach it to the session's current backlog item, then use it:
+
+```
+assist backlog associate-jira <id> <JIRA-KEY> 2>&1
+```
+
+If the command reports an error (item not found, malformed key, or the issue could not be fetched), relay it to the user and stop — no key is stored on failure.
+
+If no key was passed, read it from the session item:
+
+```
+assist backlog show <id> 2>&1
+```
+
+Use the `Jira: <KEY>` line from the output.
+
+If no key can be resolved — none was passed and the item has no associated key (or there is no session item) — tell the user clearly that there is nothing to post to and do nothing further. Do not guess a key.
+
+## Step 3: Fetch the issue and resolve the comment target
+
+Fetch the issue with the `mcp__claude_ai_Atlassian__getJiraIssue` tool, requesting fields including `issuetype` and `parent`.
+
+If `fields.issuetype` indicates a sub-task (`fields.issuetype.subtask` is true), retarget the comment to the parent: use `fields.parent.key` as the issue you comment on. Otherwise comment on the key itself.
+
+## Step 4: Compose a concise comment
+
+Draft a terse summary of this session's findings from the conversation context:
+
+- One summary line stating what was done or found.
+- A few short bullets with the concrete specifics (files, decisions, outcomes).
+
+Keep it concise: no headers, no wall of text, no restating the whole session. If there is little of substance to report, keep it to the single summary line.
+
+Do not mention `assist`, the assist backlog, or any backlog item number in the comment — the Jira ticket is outward-facing and must not leak internal tooling references. Refer to commits, PRs, or the work itself instead.
+
+## Step 5: Preview and confirm before posting
+
+Show the drafted comment and the target issue key to the user. Do not post until the user explicitly confirms. If they ask for edits, revise and show the updated draft again.
+
+Once confirmed, post it with the `mcp__claude_ai_Atlassian__addCommentToJiraIssue` tool, using the resolved target key and `contentFormat: markdown`. Display the result so the user can see it landed.