@staff0rd/assist 0.210.1 → 0.211.0
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/README.md +1 -0
- package/claude/commands/verify-new.md +40 -0
- package/dist/index.js +1 -1
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -59,6 +59,7 @@ After installation, the `assist` command will be available globally. You can als
|
|
|
59
59
|
- `/seq` - Query Seq logs from a URL or filter expression
|
|
60
60
|
- `/sql` - Query a MSSQL database via assist sql
|
|
61
61
|
- `/verify` - Run all verification commands in parallel
|
|
62
|
+
- `/verify-new` - Add a new verify:* run command to assist.yml
|
|
62
63
|
- `/transcript-format` - Format meeting transcripts from VTT files
|
|
63
64
|
- `/transcript-summarise` - Summarise transcripts missing summaries
|
|
64
65
|
- `/voice-setup` - Download required voice models (VAD, STT)
|
|
@@ -0,0 +1,40 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Add a new verify:* run command to assist.yml
|
|
3
|
+
allowed_args: "[description of the verify check to add]"
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
The user wants to register a new `verify:*` run command via `assist run add`. Entries named with the `verify:` prefix are picked up by `assist verify` and executed in parallel as part of the standard verification suite, so they must stay quiet on success and only print on failure.
|
|
7
|
+
|
|
8
|
+
## Step 1: Understand the request
|
|
9
|
+
|
|
10
|
+
If the user provided a description via $ARGUMENTS, use that as a starting point. Otherwise, ask what check they want to add and which tool will run it.
|
|
11
|
+
|
|
12
|
+
## Step 2: Determine the correct syntax
|
|
13
|
+
|
|
14
|
+
Run `assist run add --help` to see the current CLI usage and options. Use the output to construct the correct command.
|
|
15
|
+
|
|
16
|
+
## Step 3: Hunt for quietness flags
|
|
17
|
+
|
|
18
|
+
`assist verify` runs every `verify:*` entry in parallel and only surfaces output for the ones that fail. A noisy success drowns the signal, so before registering the command, find the flag(s) that make the wrapped tool silent on success:
|
|
19
|
+
|
|
20
|
+
- Check the tool's `--help` for options like `--silent`, `--quiet`, `-q`, `--reporter=dot`, `--reporter=line`, `--no-progress`, `--log-level=error`, `--no-color`, etc.
|
|
21
|
+
- Prefer reporters that print only failures (e.g. `vitest --reporter=dot`, `eslint --quiet`, `tsc --pretty false`, `biome check --reporter=summary`).
|
|
22
|
+
- If the tool always prints a banner or summary on success, look for a way to suppress it (redirect, `--no-summary`, etc.). Mention any unavoidable noise to the user.
|
|
23
|
+
|
|
24
|
+
Apply those flags as part of the args you pass to `assist run add`.
|
|
25
|
+
|
|
26
|
+
## Step 4: Add the command
|
|
27
|
+
|
|
28
|
+
Run `assist run add verify:<name> <command> [args...]` with the quiet flags applied. The name **must** be prefixed with `verify:` so `assist verify` picks it up. For example:
|
|
29
|
+
|
|
30
|
+
```
|
|
31
|
+
assist run add verify:test vitest run --reporter=dot
|
|
32
|
+
assist run add verify:lint eslint . --quiet
|
|
33
|
+
assist run add verify:types tsc --noEmit --pretty false
|
|
34
|
+
```
|
|
35
|
+
|
|
36
|
+
If the command needs a working directory, use `--cwd <dir>`.
|
|
37
|
+
|
|
38
|
+
## Step 5: Confirm with `assist verify`
|
|
39
|
+
|
|
40
|
+
Run `assist verify` and confirm the new entry passes and produces minimal output on success. If it prints noisy progress on success, return to Step 3 and tighten the flags before reporting done.
|
package/dist/index.js
CHANGED