gh-featurelisted

# gh-feature Create a single issue for actionable work, using whichever native primitive is available. ## When to use - User wants one piece of functionality built - Work fits in one logical PR - For bugs use `/gh-pms:gh-bug`, for multi-feature work `/gh-pms:gh-plan` ## What it does ### Step 1 — Collect inputs Required: - `title` (imperative) - `objective` (1–3 sentences) - `kind` (default `feature`; one of: feature/chore/hotfix/testcase) Optional: - `services` — `svc:*` labels - `parent_feature` — required if `kind=testcase` - `milestone` — milestone title or number to attach to (if working under a plan) - `severity` — `critical | high | medium | low` (default: `medium`, per `workflows/default.yaml.severities.default`). Applies to every kind — a P0 feature blocking launch is meaningfully different from a polish item. Hotfixes default to `critical`. Resolved against `workflows/default.yaml.severities.values[]` so per-repo scales work. - `effort` — `S | M | L | XL` (default: unset). T-shirt sizing for forecasting + velocity tracking. Applied as the `Effort` Project v2 field when a board is attached, and always as an `effort:*` label so the dashboard can group by effort without a project board. ### Step 2 — Resolve issue type (if available) ```bash FEATURES=$(${CLAUDE_PLUGIN_ROOT}/lib/ghcall.sh detect-features) USE_TYPES=$(echo "$FEATURES" | jq -r .issue_types) OWNER_KIND=$(echo "$FEATURES" | jq -r .owner_kind) ``` Map `kind` → GitHub type via `workflows/default.yaml.