Narrow the list to what needs you
octolens mentions list is the entry point. Bare, it prints your newest
mentions; the filter flags compose (AND), so stack them until the list is
exactly the slice you want to work through:
--relevance all— by default the list hides what the AI scored as low relevance. When you are hunting false negatives, widen it:octolens mentions list --relevance all --limit 20.--since/--until— both bounds are inclusive, each works alone, and the CLI applies no default time window (the web feed’s default 7-day view does not apply here). An empty result for a range means the workspace really has no matching mentions there.--feed— reuse a saved feed as the base filter (octolens mentions list --feed 42). Flags you pass next to it intersect with the feed’s own conditions — they narrow, never replace. Build feeds in Build feeds & filters.
Inspect one mention
Every list row carries a stablesourceId (like reddit_t3_1abc234) and an
internal numeric id — every mention-keyed command below accepts either.
--json emits the full canonical Mention document, and --web opens the
mention’s own permalink on the source platform in your browser.
Correct the AI’s verdict
mentions update overrides a mention’s relevance and/or sentiment — either
flag alone is a complete request:
--relevance clear removes your manual override and restores the AI’s
original verdict — the AI’s call is recorded the first time a mention is
overridden and never rewritten, so clear is always safe, no matter how many
overrides came before.
What comes back is the committed state, not an echo of your flags:
--relevance clear reports the restored AI verdict, and if a concurrent
triage (another shell, the web app, the live view’s keyboard triage) wins a
race, the response carries what the workspace actually holds. Branch on the
payload, never on the flag you passed.
octolens mentions update
Arguments
Flags
Teach the model, not just this mention
An override fixes one mention.feedback submit feeds the relevance model,
so the same mistake gets rarer:
--relevant / --not-relevant is required; --reason is
free-text context the relevance agent reads. Re-submitting for the same
mention replaces the stored feedback wholesale. To undo it:
--yes (on a TTY
the command confirms instead). The
response’s removed field distinguishes a real removal (true) from
“there was no feedback to remove” (false) — both exit 0, since the
desired end state holds either way. octolens feedback stats reports the
aggregate false-positive rate the loop is driving down.
Mark what you have handled — the engage trap
mentions engage sets the engaged-with flag: “we saw this and responded”.
It has two modes, and picking the wrong one is the classic scripting bug:
- With
--engaged true|false— an absolute, idempotent write. Marking an already-engaged mention engaged leaves it engaged; a retry after a timeout cannot undo the write it is retrying; two concurrent--engaged truecalls both land on engaged. - Bare (no flag) — a toggle, kept for the interactive “flip this” gesture. A toggle is inherently non-idempotent: re-running it undoes it, and two concurrent toggles cancel out.
--engaged. A retried toggle flips
the flag back to where it started, silently:
mentions update, the response’s engaged field is the committed
flag read back from the store, not a prediction — branch on it.
octolens mentions engage
Arguments
Flags
Script the loop
Everything above is headless-safe with--json — one JSON document on
stdout, errors as one envelope on stderr, stable exit codes (see
The —json contract and
Exit codes):
mentions update.