docs: note that incident get has no time-window flags

--since/--until (list) and --start-time/--end-time (sdp-request-list)
are the only time-range filters in the incident card; get <id>
[<id2>...] takes ids only. Nothing said so, and get takes any of these
flags as an unknown-flag parse error rather than a hint that it isn't
supported there, so add a one-line gotcha calling it out.

Author: ysyneu

skills/flashduty/reference/incident.md

@@ -497,6 +497,7 @@ Update a work item
 - **Search with `--query`, don't substring-match `title` from list output.** A `--fields` list projection may come back with long values clipped to fit its byte budget (a stderr note names the fields when it happens), so a local `jq test()` / `contains()` over `title` can miss rows that really do match, and an empty result is indistinguishable from a genuine non-match. `--query` is a server-side full-text search over title/labels/content — correct regardless of projection, and cheaper than pulling pages to filter locally. (It also resolves a 24-char `incident_id` or 6-char `num` to a direct lookup.)
 - **Use `--fields` to keep list scans compact.** When the goal is to identify matching incidents or collect IDs/numbers/titles, project only the needed columns first, then fetch one target incident with `detail` / `alerts` / `timeline`.
 - **`list` window cap**: `--since`/`--until` window must be < 31 days; `--limit` max 100. Empty result is authoritative — do not widen filters or retry.
+- **`get` has no time-window flags**: `get <id> [<id2>...]` takes one or more incident IDs, not a window — it has no `--since`, `--until`, `--start-time`, or `--end-time` at all, so passing one errors as an unknown flag rather than filtering; use `list` for time-range filtering.
 - **`merge` is irreversible**: source incidents are absorbed into target permanently. Always list and confirm both IDs before running.
 - **`remove --force`** bypasses the interactive confirmation prompt — never pass `--force` unless the user has explicitly said so.
 - **`assign` needs `--data` for the nested `assigned_to` object** (either `person_ids` or `escalate_rule_id`). Pass member IDs from `member list` in the API field: `--data '{"incident_ids":["<id>"],"assigned_to":{"person_ids":[101]}}'`. `reassign <id> --person <ids>` is simpler for direct member assignment.