@staff0rd/assist 0.361.0 → 0.362.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/dist/index.js
CHANGED
|
@@ -6,7 +6,7 @@ import { Command } from "commander";
|
|
|
6
6
|
// package.json
|
|
7
7
|
var package_default = {
|
|
8
8
|
name: "@staff0rd/assist",
|
|
9
|
-
version: "0.
|
|
9
|
+
version: "0.362.1",
|
|
10
10
|
type: "module",
|
|
11
11
|
main: "dist/index.js",
|
|
12
12
|
bin: {
|
|
@@ -6966,7 +6966,8 @@ import { execFile as execFile3 } from "child_process";
|
|
|
6966
6966
|
import { promisify as promisify4 } from "util";
|
|
6967
6967
|
var execFileAsync3 = promisify4(execFile3);
|
|
6968
6968
|
var CACHE_TTL_MS = 3e4;
|
|
6969
|
-
function createCachedGhJson(args, parse3, fallback) {
|
|
6969
|
+
function createCachedGhJson(args, parse3, fallback, options2 = {}) {
|
|
6970
|
+
const { cacheFallback = true } = options2;
|
|
6970
6971
|
const cache = /* @__PURE__ */ new Map();
|
|
6971
6972
|
return async (cwd, extraArgs = []) => {
|
|
6972
6973
|
const key = extraArgs.length ? `${cwd}\0${extraArgs.join("\0")}` : cwd;
|
|
@@ -6983,7 +6984,8 @@ function createCachedGhJson(args, parse3, fallback) {
|
|
|
6983
6984
|
} catch {
|
|
6984
6985
|
value = fallback;
|
|
6985
6986
|
}
|
|
6986
|
-
|
|
6987
|
+
if (cacheFallback || value !== fallback)
|
|
6988
|
+
cache.set(key, { value, expires: now + CACHE_TTL_MS });
|
|
6987
6989
|
return value;
|
|
6988
6990
|
};
|
|
6989
6991
|
}
|
|
@@ -7035,7 +7037,8 @@ var prFields = "number,title,author,createdAt,url";
|
|
|
7035
7037
|
var getPrByNumber = createCachedGhJson(
|
|
7036
7038
|
["pr", "view", "--json", prFields],
|
|
7037
7039
|
(stdout) => toPrSummary(JSON.parse(stdout)),
|
|
7038
|
-
null
|
|
7040
|
+
null,
|
|
7041
|
+
{ cacheFallback: false }
|
|
7039
7042
|
);
|
|
7040
7043
|
var getOpenPrForBranch = createCachedGhJson(
|
|
7041
7044
|
["pr", "list", "--state", "open", "--json", prFields],
|
|
@@ -7044,7 +7047,8 @@ var getOpenPrForBranch = createCachedGhJson(
|
|
|
7044
7047
|
if (!Array.isArray(parsed) || parsed.length === 0) return null;
|
|
7045
7048
|
return toPrSummary(parsed[0]);
|
|
7046
7049
|
},
|
|
7047
|
-
null
|
|
7050
|
+
null,
|
|
7051
|
+
{ cacheFallback: false }
|
|
7048
7052
|
);
|
|
7049
7053
|
async function getCurrentBranch(cwd) {
|
|
7050
7054
|
try {
|
package/package.json
CHANGED
|
@@ -1,34 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
description: Associate a Jira ticket with a backlog item
|
|
3
|
-
allowed_args: "<JIRA-KEY> [backlog item id]"
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
You are associating a Jira ticket with a backlog item by calling the `assist backlog associate-jira` CLI command, which validates the key, confirms the issue exists in Jira, and stores it on the item.
|
|
7
|
-
|
|
8
|
-
## Step 1: Parse arguments
|
|
9
|
-
|
|
10
|
-
`$ARGUMENTS` contains a Jira key (e.g. `PROJ-123`) and an optional backlog item id. Identify which token is the Jira key (matches `[A-Z]+-\d+`) and which, if any, is the item id (a bare number).
|
|
11
|
-
|
|
12
|
-
## Step 2: Resolve the target item
|
|
13
|
-
|
|
14
|
-
If an explicit item id was provided, use it.
|
|
15
|
-
|
|
16
|
-
Otherwise, use 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). Use its id directly.
|
|
17
|
-
|
|
18
|
-
If there is no explicit id and this session is not working on a backlog item, there is nothing to associate the key with — tell the user and ask them to pass an explicit item id.
|
|
19
|
-
|
|
20
|
-
## Step 3: Associate the key
|
|
21
|
-
|
|
22
|
-
Call the CLI command with the resolved id and the Jira key:
|
|
23
|
-
|
|
24
|
-
```
|
|
25
|
-
assist backlog associate-jira <id> <JIRA-KEY> 2>&1
|
|
26
|
-
```
|
|
27
|
-
|
|
28
|
-
The command validates the key shape, fetches the issue to confirm it exists, prints its title, and stores the key. To remove an existing association instead, run:
|
|
29
|
-
|
|
30
|
-
```
|
|
31
|
-
assist backlog associate-jira <id> --clear 2>&1
|
|
32
|
-
```
|
|
33
|
-
|
|
34
|
-
Display the command output so the user can see the result. If the command reports an error (item not found, malformed key, or the issue could not be fetched), relay it to the user — no key is stored on failure.
|
|
@@ -1,53 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
description: Post a concise summary of this session's findings to a Jira ticket
|
|
3
|
-
allowed_args: "[JIRA-KEY]"
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
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.
|
|
7
|
-
|
|
8
|
-
## Step 1: Resolve the session's backlog item
|
|
9
|
-
|
|
10
|
-
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.
|
|
11
|
-
|
|
12
|
-
## Step 2: Resolve the Jira key
|
|
13
|
-
|
|
14
|
-
If `$ARGUMENTS` contains a Jira key (matches `[A-Z]+-\d+`), attach it to the session's current backlog item, then use it:
|
|
15
|
-
|
|
16
|
-
```
|
|
17
|
-
assist backlog associate-jira <id> <JIRA-KEY> 2>&1
|
|
18
|
-
```
|
|
19
|
-
|
|
20
|
-
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.
|
|
21
|
-
|
|
22
|
-
If no key was passed, read it from the session item:
|
|
23
|
-
|
|
24
|
-
```
|
|
25
|
-
assist backlog show <id> 2>&1
|
|
26
|
-
```
|
|
27
|
-
|
|
28
|
-
Use the `Jira: <KEY>` line from the output.
|
|
29
|
-
|
|
30
|
-
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.
|
|
31
|
-
|
|
32
|
-
## Step 3: Fetch the issue and resolve the comment target
|
|
33
|
-
|
|
34
|
-
Fetch the issue with the `mcp__claude_ai_Atlassian__getJiraIssue` tool, requesting fields including `issuetype` and `parent`.
|
|
35
|
-
|
|
36
|
-
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.
|
|
37
|
-
|
|
38
|
-
## Step 4: Compose a concise comment
|
|
39
|
-
|
|
40
|
-
Draft a terse summary of this session's findings from the conversation context:
|
|
41
|
-
|
|
42
|
-
- One summary line stating what was done or found.
|
|
43
|
-
- A few short bullets with the concrete specifics (files, decisions, outcomes).
|
|
44
|
-
|
|
45
|
-
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.
|
|
46
|
-
|
|
47
|
-
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.
|
|
48
|
-
|
|
49
|
-
## Step 5: Preview and confirm before posting
|
|
50
|
-
|
|
51
|
-
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.
|
|
52
|
-
|
|
53
|
-
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.
|