@staff0rd/assist 0.318.2 → 0.318.4

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.
Files changed (17) hide show
  1. package/claude/CLAUDE.md +6 -3
  2. package/claude/commands/bug.md +5 -0
  3. package/claude/commands/comment.md +2 -0
  4. package/claude/commands/commit.md +2 -0
  5. package/claude/commands/draft.md +10 -0
  6. package/claude/commands/forward-comments.md +1 -1
  7. package/claude/commands/next.md +1 -0
  8. package/claude/commands/prompts.md +1 -0
  9. package/claude/commands/refine.md +7 -0
  10. package/claude/commands/seq.md +2 -0
  11. package/claude/commands/strip-comments.md +1 -1
  12. package/claude/commands/test-cover.md +15 -13
  13. package/claude/commands/test-review.md +9 -0
  14. package/claude/settings.json +3 -5
  15. package/dist/commands/netcap/netcap-extension/interceptor.js +5 -3
  16. package/dist/index.js +2 -2
  17. package/package.json +1 -1
package/claude/CLAUDE.md CHANGED
@@ -3,20 +3,23 @@ After any code change, run `/verify` to ensure all checks pass.
3
3
  `assist` is installed globally. Use it directly (e.g., `assist commit "message"`).
4
4
 
5
5
  When renaming TypeScript files or symbols, use the refactor commands instead of doing it manually:
6
+
6
7
  - `assist refactor rename file <source> <destination>` — rename/move a file and update all imports
7
8
  - `assist refactor rename symbol <file> <oldName> <newName>` — rename a variable, function, class, or type across the project
8
9
  - `assist refactor extract <file> <functionName> <destination>` — extract a function and its private dependencies to a new file
9
- All default to dry-run; add `--apply` to execute.
10
- When using extract, name the destination file after the exported function (e.g. `updateWorkerCapacity.ts` for `updateWorkerCapacity`) to satisfy `useFilenamingConvention` lint rules.
10
+ All default to dry-run; add `--apply` to execute.
11
+ When using extract, name the destination file after the exported function (e.g. `updateWorkerCapacity.ts` for `updateWorkerCapacity`) to satisfy `useFilenamingConvention` lint rules.
11
12
 
12
13
  Do not modify `claude/settings.json` without asking the user first. Only read-only commands should be added to the allow list — write operations (add, remove, set, delete) must require confirmation.
13
14
 
14
15
  ## Fetching Jira context
15
- When the user mentions a Jira issue key (e.g. `BAD-671`, `PROJ-123`), use the Atlassian MCP to fetch context.
16
16
 
17
+ When the user mentions a Jira issue key (e.g. `BAD-671`, `PROJ-123`), use the Atlassian MCP to fetch context.
17
18
 
18
19
  ## Commenting code
20
+
19
21
  Do not include comments for standard logic or syntax. Only comment if the specific line involves unintuitive complexity or a hack.
20
22
 
21
23
  ## Backlog items, PRs, and commits
24
+
22
25
  Do not mention assist backlog items in PR descriptions or PR comments. The reference goes the other way: mention the relevant commits or PRs in the assist backlog item.
package/claude/commands/bug.md CHANGED
@@ -33,6 +33,7 @@ Show the user the bug report:
33
33
  **Actual:** ...
34
34
 
35
35
  **Acceptance Criteria:**
36
+
36
37
  - (conditions that confirm the bug is fixed)
37
38
 
38
39
  Do NOT generate a plan — the implementer will determine how to fix it.
@@ -44,15 +45,19 @@ Ask the user if they want to change anything. Iterate until they confirm.
44
45
  ## Step 5: Save
45
46
 
46
47
  Once confirmed, add the item via CLI and capture the id it prints:
48
+
47
49
  ```
48
50
  assist backlog add --name "Bug title" --type bug --desc "**Repro:**\n1. ...\n\n**Expected:** ...\n\n**Actual:** ..." --ac "criterion 1" --ac "criterion 2" 2>&1
49
51
  ```
52
+
50
53
  Note the created item id from the output — you'll pass it to the done signal below.
51
54
 
52
55
  Then show the user the item was created and suggest they can run `assist backlog run <id>` to start implementation.
53
56
 
54
57
  Finally, signal that the bug-filing task is complete, passing the created item id:
58
+
55
59
  ```
56
60
  assist signal done <id> 2>&1
57
61
  ```
62
+
58
63
  This lets a wrapping `assist bug --once` session end and surfaces the created item id to the session card; in a plain interactive session it has no effect.
package/claude/commands/comment.md CHANGED
@@ -12,6 +12,7 @@ Parse `$ARGUMENTS` as a comma-separated list of item numbers (e.g. `1,2` or `1,2
12
12
  ## Finding the Referenced List
13
13
 
14
14
  Look back through the conversation for the most recent numbered list of issues, suggestions, or comments. Each item should have enough context to determine:
15
+
15
16
  - **path**: the file path
16
17
  - **line**: the line number
17
18
  - **body**: a concise comment describing the issue
@@ -29,6 +30,7 @@ assist prs comment <path> <line> '<body>' 2>&1
29
30
  **Important:** Always use single quotes around `<body>`, never double quotes. Double quotes cause shell escaping issues with backticks and special characters.
30
31
 
31
32
  The body must:
33
+
32
34
  - Be a clear, concise description of the issue (1-2 sentences)
33
35
  - Not contain "claude" or "opus" (case-insensitive) — the command will reject it
34
36
  - Not contain single quotes (reword to avoid them)
package/claude/commands/commit.md CHANGED
@@ -7,10 +7,12 @@ Review the git status and create a commit with only the files that are relevant
7
7
  First run `assist commit status` to see the current state of the working tree.
8
8
 
9
9
  Then either:
10
+
10
11
  - `assist commit "your message"` to commit already-staged changes, or
11
12
  - `assist commit "your message" <file1> <file2> ...` to stage files and commit
12
13
 
13
14
  Where:
15
+
14
16
  - The first argument is the commit message
15
17
  - Any subsequent arguments are paths to git add before committing
16
18
  - The commit message is 40 characters or less
package/claude/commands/draft.md CHANGED
@@ -30,9 +30,11 @@ Once you have enough context, propose a complete backlog item. Show it to the us
30
30
  **Type:** story or bug
31
31
  **Description:** 1-3 sentences
32
32
  **Acceptance Criteria:**
33
+
33
34
  - (specific, testable criteria)
34
35
 
35
36
  **Plan:**
37
+
36
38
  - Phase 1: (name) — tasks...
37
39
  - Phase 2: (name) — tasks... [manual checks: ...]
38
40
 
@@ -41,12 +43,14 @@ Once you have enough context, propose a complete backlog item. Show it to the us
41
43
  **Phases must be vertical slices, not horizontal layers.** Each phase should deliver a thin, working increment of the feature that can be verified end-to-end. Do NOT decompose by architectural layer (e.g. "Phase 1: schema changes", "Phase 2: backend API", "Phase 3: UI"). Instead, each phase should cut through all necessary layers to produce something observable.
42
44
 
43
45
  Bad (horizontal):
46
+
44
47
  - Phase 1: Add database schema and types
45
48
  - Phase 2: Build API endpoints
46
49
  - Phase 3: Create UI components
47
50
  - Phase 4: Wire everything together
48
51
 
49
52
  Good (vertical):
53
+
50
54
  - Phase 1: Minimal working feature (hardcoded/simplified) visible end-to-end
51
55
  - Phase 2: Add real data handling and validation
52
56
  - Phase 3: Polish edge cases and error states
@@ -58,6 +62,7 @@ Good (vertical):
58
62
  - If a feature spans backend + UI, each phase carries its slice through both — e.g. "Phase 1: endpoint + UI button that calls it", not "Phase 1: endpoint, Phase 2: button".
59
63
 
60
64
  Two tests for each phase before proposing the plan:
65
+
61
66
  1. **Observable**: can you answer "does this work?" by running or inspecting the result? If a phase only produces internal plumbing with no observable effect, it's horizontal — restructure it.
62
67
  2. **Self-contained**: would `assist verify` pass with only this phase's code committed — no unused exports, no dead stubs awaiting a later phase? If not, merge the producer and its consumer into the same phase.
63
68
 
@@ -74,12 +79,15 @@ Ask the user if they want to change anything. Iterate until they confirm.
74
79
  Once confirmed, create the item and its phases via CLI commands.
75
80
 
76
81
  First, add the item and capture the id it prints:
82
+
77
83
  ```
78
84
  assist backlog add --name "Item name" --type story --desc "Description text" --ac "criterion 1" --ac "criterion 2" 2>&1
79
85
  ```
86
+
80
87
  Note the created item id from the output — you'll pass it to the done signal below.
81
88
 
82
89
  Then add each phase:
90
+
83
91
  ```
84
92
  assist backlog add-phase <id> "Phase name" --task "Task 1" --task "Task 2" --manual-check "optional check" 2>&1
85
93
  ```
@@ -87,7 +95,9 @@ assist backlog add-phase <id> "Phase name" --task "Task 1" --task "Task 2" --man
87
95
  Then show the user the item was created and suggest they can run `assist backlog run <id>` to start implementation.
88
96
 
89
97
  Finally, signal that the drafting task is complete, passing the created item id:
98
+
90
99
  ```
91
100
  assist signal done <id> 2>&1
92
101
  ```
102
+
93
103
  This lets a wrapping `assist draft --once` session end and surfaces the created item id to the session card; in a plain interactive session it has no effect.
package/claude/commands/forward-comments.md CHANGED
@@ -32,7 +32,7 @@ If either is missing or ambiguous, ask before proceeding. The PR is always the c
32
32
 
33
33
  Rules for the quote:
34
34
  - **Quote verbatim.** Preserve the reviewer's exact wording, including typos, repeated words, odd spacing, and punctuation. Do not paraphrase, "fix," or tidy. The reviewer's voice matters.
35
- - **Drop framing prose.** Only the actionable suggestion that maps to *this specific line* should appear. If the reviewer's sentence opens with broad framing ("the only thing that's slightly naff is...") and then states the suggestion, quote only the suggestion part.
35
+ - **Drop framing prose.** Only the actionable suggestion that maps to _this specific line_ should appear. If the reviewer's sentence opens with broad framing ("the only thing that's slightly naff is...") and then states the suggestion, quote only the suggestion part.
36
36
  - **Add backticks around symbols.** Identifier names, type names, file names, and function names should be wrapped in backticks (e.g. `` `displayValue` ``, `` `SurveyQuestionModel` ``, `` `resolvers.ts` ``) even if the reviewer didn't use them. This is the only formatting change permitted.
37
37
  - **No editorialising.** Do not add your own commentary, explanation, or restatement. The whole body is the attribution line plus the quote.
38
38
 
package/claude/commands/next.md CHANGED
@@ -5,6 +5,7 @@ description: Signal completion and chain into the next backlog item
5
5
  You are done with the current session. Write the signal file to terminate this session and chain into the next backlog item.
6
6
 
7
7
  Run:
8
+
8
9
  ```
9
10
  assist signal next $ARGUMENTS
10
11
  ```
package/claude/commands/prompts.md CHANGED
@@ -15,6 +15,7 @@ Otherwise, analyze each entry and suggest specific changes to auto-allow the rec
15
15
  Present your suggestions as a numbered list with the specific change for each. Group related suggestions together.
16
16
 
17
17
  **Important:**
18
+
18
19
  - Only suggest allowing read-only, non-destructive commands
19
20
  - Never suggest allowing write operations (git push, rm, npm publish, etc.) without flagging them as risky
20
21
  - Reference the deny reason from the output to explain why each command was blocked
package/claude/commands/refine.md CHANGED
@@ -34,6 +34,7 @@ Ask one focused question at a time. Wait for the user's response before continui
34
34
  Based on the user's input, apply changes using the appropriate commands. Always append `2>&1` to each command.
35
35
 
36
36
  **To update item fields:**
37
+
37
38
  ```
38
39
  assist backlog update-field <id> --name "New name"
39
40
  assist backlog update-field <id> --desc "New description"
@@ -44,6 +45,7 @@ assist backlog update-field <id> --ac "criterion 1" --ac "criterion 2"
44
45
  Note: `--ac` replaces all acceptance criteria, so include the full list (both existing and new).
45
46
 
46
47
  **To modify a plan phase** (phase is 0-indexed):
48
+
47
49
  ```
48
50
  assist backlog update-phase <id> <phase> --name "New phase name"
49
51
  assist backlog update-phase <id> <phase> --task "Task 1" --task "Task 2"
@@ -53,11 +55,13 @@ assist backlog update-phase <id> <phase> --manual-check "Check 1"
53
55
  Note: `--task` and `--manual-check` replace the full list for that phase, so include all items.
54
56
 
55
57
  **To remove a plan phase:**
58
+
56
59
  ```
57
60
  assist backlog remove-phase <id> <phase>
58
61
  ```
59
62
 
60
63
  **To add a new plan phase:**
64
+
61
65
  ```
62
66
  assist backlog add-phase <id> "Phase name" --task "Task 1" --task "Task 2"
63
67
  ```
@@ -71,6 +75,7 @@ When adding or restructuring plan phases, follow the same rules as /draft:
71
75
  - If the user proposes a horizontal split, point out that the earlier phase won't verify (knip will flag the unused exports) and suggest a vertical restructure instead.
72
76
 
73
77
  **To add a comment** (for context, decisions, or notes that don't fit in fields):
78
+
74
79
  ```
75
80
  assist backlog comment <id> "Comment text"
76
81
  ```
@@ -84,7 +89,9 @@ Ask if there is anything else to refine. Continue the conversation until the use
84
89
  ## Step 5: Signal completion
85
90
 
86
91
  Once the user confirms they are done refining, signal that the task is complete:
92
+
87
93
  ```
88
94
  assist signal done 2>&1
89
95
  ```
96
+
90
97
  This lets a wrapping `assist refine --once` session end; in a plain interactive session it has no effect.
package/claude/commands/seq.md CHANGED
@@ -7,10 +7,12 @@ The user wants to query Seq log events. The argument is either a Seq UI URL or a
7
7
  ## If the argument is a URL
8
8
 
9
9
  Parse it to extract:
10
+
10
11
  1. **Base URL** — the origin (e.g., `http://localhost:5341`)
11
12
  2. **Filter** — URL-decode the `filter` query parameter from the fragment (after `#`). For example, from `http://localhost:5341/#/events?filter=JobId%20%3D%3D%20%22abc%22`, extract filter `JobId == "abc"`.
12
13
 
13
14
  Then determine the correct connection:
15
+
14
16
  - Run `assist seq auth list` to see configured connections.
15
17
  - Match the base URL from the parsed URL against a connection's URL.
16
18
  - If a match is found, use that connection name with `-c <name>`.
package/claude/commands/strip-comments.md CHANGED
@@ -34,7 +34,7 @@ Read each file and remove only comments that violate the policy:
34
34
  **Never remove** the following, even if they look like noise:
35
35
 
36
36
  - **Functional directives** that the toolchain acts on: `eslint-disable*`, `@ts-expect-error`, `@ts-ignore`, `oxlint-disable`, `prettier-ignore`, `// @ts-nocheck`, coverage pragmas (`c8 ignore`, `istanbul ignore`), `noqa`, `type: ignore`, `#pragma`, `//go:`-style directives, and similar.
37
- - **Comments marking a genuine hack or workaround** — anything explaining *why* non-obvious code exists, including `HACK`/`WORKAROUND`/`FIXME`/`TODO` notes, links to issues, or rationale the code cannot convey on its own.
37
+ - **Comments marking a genuine hack or workaround** — anything explaining _why_ non-obvious code exists, including `HACK`/`WORKAROUND`/`FIXME`/`TODO` notes, links to issues, or rationale the code cannot convey on its own.
38
38
  - **Doc comments** that form part of an API contract (JSDoc/TSDoc, XML doc comments, docstrings) unless they only restate the signature.
39
39
 
40
40
  When in doubt, keep the comment. The cost of leaving a borderline comment is far lower than deleting one that carries intent.
package/claude/commands/test-cover.md CHANGED
@@ -26,6 +26,7 @@ From the uncovered files, prioritise by:
26
26
  3. **Complexity** — files with branching logic, edge cases, or error handling
27
27
 
28
28
  Skip files that are primarily:
29
+
29
30
  - Thin CLI wrappers (just parse args and call another function)
30
31
  - UI components (React/TSX)
31
32
  - Files that only re-export or wire things together
@@ -63,29 +64,30 @@ Example:
63
64
 
64
65
  ```typescript
65
66
  describe("parseToken", () => {
66
- describe("when given a valid token", () => {
67
- it("should return the decoded payload", () => {
68
- const token = createToken({ sub: "user-1" });
67
+ describe("when given a valid token", () => {
68
+ it("should return the decoded payload", () => {
69
+ const token = createToken({ sub: "user-1" });
69
70
 
70
- const result = parseToken(token);
71
+ const result = parseToken(token);
71
72
 
72
- expect(result.sub).toBe("user-1");
73
- });
74
- });
73
+ expect(result.sub).toBe("user-1");
74
+ });
75
+ });
75
76
 
76
- describe("when given an expired token", () => {
77
- it("should throw an expiration error", () => {
78
- const token = createToken({ exp: pastDate() });
77
+ describe("when given an expired token", () => {
78
+ it("should throw an expiration error", () => {
79
+ const token = createToken({ exp: pastDate() });
79
80
 
80
- expect(() => parseToken(token)).toThrow("expired");
81
- });
82
- });
81
+ expect(() => parseToken(token)).toThrow("expired");
82
+ });
83
+ });
83
84
  });
84
85
  ```
85
86
 
86
87
  ### Coverage targets
87
88
 
88
89
  Cover:
90
+
89
91
  - Happy path for each exported function
90
92
  - Edge cases (empty input, undefined, boundary values)
91
93
  - Error cases and invalid input
package/claude/commands/test-review.md CHANGED
@@ -18,21 +18,25 @@ For each test file, read both the test and the source file it covers. You need b
18
18
  Assess each test file against these criteria:
19
19
 
20
20
  ### Correctness
21
+
21
22
  - Do assertions actually verify the behaviour, or are they tautological (e.g., testing that a mock returns what you told it to)?
22
23
  - Are expected values correct and meaningful, not just copied from implementation output?
23
24
  - Do tests assert the right thing — return values, side effects, thrown errors — for each scenario?
24
25
 
25
26
  ### Coverage of behaviour
27
+
26
28
  - Are all exported functions tested?
27
29
  - Are conditional branches exercised (if/else, switch, early returns, error paths)?
28
30
  - Are edge cases covered (empty input, null/undefined, boundary values, large input)?
29
31
  - Are error cases tested (invalid arguments, missing data, thrown exceptions)?
30
32
 
31
33
  ### Test independence
34
+
32
35
  - Can each test run in isolation, or do tests depend on shared mutable state or execution order?
33
36
  - Are mocks reset properly between tests?
34
37
 
35
38
  ### BDD structure and Arrange-Act-Assert
39
+
36
40
  - Does the outer `describe` name the function or module under test?
37
41
  - Do inner `describe("when ...")` blocks group tests by shared setup/scenario?
38
42
  - Do `it` blocks use `should` phrasing with bare outcomes (e.g., `it("should allow")`, `it("should reject")`)? State specifiers (flags, syntax variants, conditions) belong in `when` blocks, never in `it` descriptions.
@@ -40,11 +44,13 @@ Assess each test file against these criteria:
40
44
  - Are assertions minimal per test — ideally one, at most two closely related? If multiple things are asserted about the same action, are they split into separate `it` blocks under the same `describe("when ...")`?
41
45
 
42
46
  ### Mocking discipline
47
+
43
48
  - Are mocks used only when necessary (external I/O, complex dependencies)?
44
49
  - Do mocks faithfully represent the real dependency's contract, or do they mask bugs?
45
50
  - Is there a risk that mocked tests pass but real integration would fail?
46
51
 
47
52
  ### Missing tests
53
+
48
54
  - Are there exported functions or significant code paths with no corresponding test?
49
55
  - Are there recently added functions (check git log) that lack tests?
50
56
 
@@ -57,12 +63,15 @@ For each test file, report:
57
63
  **Verdict:** Good / Needs improvement / Weak
58
64
 
59
65
  **Strengths:**
66
+
60
67
  - (what the tests do well)
61
68
 
62
69
  **Issues:**
70
+
63
71
  - (specific problems, each with a concrete recommendation)
64
72
 
65
73
  **Missing coverage:**
74
+
66
75
  - (untested functions or paths, with suggested test cases)
67
76
 
68
77
  ## Step 5: Summary
package/claude/settings.json CHANGED
@@ -29,7 +29,7 @@
29
29
  },
30
30
  "permissions": {
31
31
  "allow": [
32
- "SlashCommand(/verify)",
32
+ "SlashCommand(/verify)",
33
33
  "SlashCommand(/commit)",
34
34
  "SlashCommand(/devlog)",
35
35
  "SlashCommand(/refactor)",
@@ -43,7 +43,7 @@
43
43
  "SlashCommand(/voice-logs)",
44
44
  "SlashCommand(/journal)",
45
45
  "SlashCommand(/standup)",
46
- "Skill(verify)",
46
+ "Skill(verify)",
47
47
  "Skill(commit)",
48
48
  "Skill(devlog)",
49
49
  "Skill(refactor)",
@@ -85,8 +85,6 @@
85
85
  "Bash(git ls-files:*)",
86
86
  "WebFetch(domain:staffordwilliams.com)"
87
87
  ],
88
- "deny": [
89
- "Bash(npm run:*)"
90
- ]
88
+ "deny": ["Bash(npm run:*)"]
91
89
  }
92
90
  }
package/dist/commands/netcap/netcap-extension/interceptor.js CHANGED
@@ -64,8 +64,7 @@
64
64
  if (type === "" || type === "text") return xhr.responseText ?? "";
65
65
  if (type === "json")
66
66
  return xhr.response == null ? "" : JSON.stringify(xhr.response);
67
- if (type === "arraybuffer")
68
- return new TextDecoder().decode(xhr.response);
67
+ if (type === "arraybuffer") return new TextDecoder().decode(xhr.response);
69
68
  if (type === "document")
70
69
  return xhr.response?.documentElement?.outerHTML ?? "";
71
70
  if (type === "blob") return xhr.response;
@@ -80,7 +79,10 @@
80
79
  const open = OriginalXHR.prototype.open;
81
80
  const send = OriginalXHR.prototype.send;
82
81
  OriginalXHR.prototype.open = function (method, url, ...rest) {
83
- this.__netcap = { method: String(method).toUpperCase(), url: String(url) };
82
+ this.__netcap = {
83
+ method: String(method).toUpperCase(),
84
+ url: String(url),
85
+ };
84
86
  return open.call(this, method, url, ...rest);
85
87
  };
86
88
  OriginalXHR.prototype.send = function (body) {
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.318.2",
9
+ version: "0.318.4",
10
10
  type: "module",
11
11
  main: "dist/index.js",
12
12
  bin: {
@@ -20536,7 +20536,7 @@ function refreshActivity(session) {
20536
20536
  session.claudeSessionId = activity2.claudeSessionId;
20537
20537
  }
20538
20538
 
20539
- // src/commands/sessions/daemon/watchThinking.ts
20539
+ // src/commands/sessions/daemon/noteOutputForThinking.ts
20540
20540
  var ACTIVATE_MS = 500;
20541
20541
  var GAP_MS = 1e3;
20542
20542
  function noteOutputForThinking(session, onStatusChange) {
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@staff0rd/assist",
3
- "version": "0.318.2",
3
+ "version": "0.318.4",
4
4
  "type": "module",
5
5
  "main": "dist/index.js",
6
6
  "bin": {