shipper issue list

shipper issue list

Usage: shipper issue list [options]

List shipper-managed issues by pipeline status

Arguments

Argument	Required	Description	Choices
None	-	-	-

Flags

Long	Short	Value	Default	Description	Choices
—status	-		-	filter to a single status (e.g. planned)	-
—priority	-		-	filter by priority	high, normal, low
—linked-pull-request	-		-	filter by stored pull request association	present, absent

Examples

List issues waiting for an external-closure decision.

shipper issue list --status held

List planned, high-priority issues with a stored pull request association.

shipper issue list --status planned --priority high --linked-pull-request present

Exit Codes

Code	When
0	Issues are listed successfully, including when no issues match.
1	Filter validation fails, or the local issue-state replica is unavailable or malformed.

Constraints

• Design, Plan, Implement, Review, Rework, and Ready name next work. Designed simple issues next Implement; complex or undecided issues next Plan. Packaged work next Review in either PR mode. Ready means ready for final integration, not shipped. New stays separate; held and failed are excluded (hold wins), while blocked, locked, paused, and running retain membership. CLI/MCP retain six next-step groups; desktop has five columns, with Implement combining Implement and Rework for the same population and attention exclusions. Current nextStep and nextStepPipeline are additive; completed-stage pipeline fields, labels, filters, commands, reset arguments, and historical records retain their meanings. Maintained label descriptions automatically refresh during next normal setup or maintenance, without separate initialization; successful cache skips repeats and force refresh reads again. Read-only status makes no label writes.
• Held issues render before failed issues and are excluded from the failed group even when their saved failed state is true.
• The held filter is store-backed and does not refresh GitHub attribution evidence.
• A row for an issue with a decided route carries a trailing [simple route] or [complex route] marker, so route distribution is readable from the listing alone. An undecided route omits the route suffix; completed-stage context remains visible.