outfitter-issue

name	outfitter-issue
version	0.4.1
description	Submit feedback to the Outfitter team via GitHub issues. Use after discovering bugs, missing features, unclear docs, or improvement opportunities in @outfitter/* packages.
allowed-tools	Bash(gh *), Bash(bun *), Bash(./scripts/*), Read
user-invocable	true
argument-hint	<description of the issue>

Outfitter Issue

Submit issues to outfitter-dev/outfitter when you discover problems with @outfitter/* packages.

Steps

1. Parse input — If $ARGUMENTS is provided, use it as the issue description to determine type, package, and title.
2. Search first — Check for duplicates before creating.
3. Classify — Determine issue type (bug, enhancement, docs, dx, unclear-pattern) from context.
4. Draft — Dry-run the create script, present the issue for user review.
5. Submit — After user approval, run with --submit.

Before Creating an Issue

Always search first to avoid duplicates:

./scripts/search-issues.sh "keywords describing the issue"

If a similar issue exists, comment on it instead of creating a new one.

Creating an Issue

Use the helper script with --submit to create an issue:

bun ./scripts/create-issue.ts \
  --type bug \
  --title "Brief description" \
  --package "@outfitter/contracts" \
  --description "What went wrong" \
  --actual "What actually happened" \
  --submit

Dry-Run (Default)

Without --submit, the script outputs the gh command for review:

bun ./scripts/create-issue.ts --type bug --title "..." --package "..."

Issue Types

Type	When to Use	Required Fields
bug	Something broke	package, description, actual
enhancement	Feature request	package, description, useCase
docs	Documentation gap	package, description, gap
dx	Poor developer experience	package, description, current
unclear-pattern	Confusing guidance	package, description, context

For migration-specific feedback, see references/migration-feedback.md.

View Template Requirements

bun ./scripts/create-issue.ts --type bug

Labels

All issues created via this skill get:

• Category label (bug, feature, documentation, etc.)
• feedback — marks it as community feedback
• source/agent — indicates it came from an agent session

Best Practices

• Be specific — include package name, function, and error if known
• Provide context — what task led to discovering this?
• Include workaround — if you found one, share it
• Stay constructive — focus on improvement, not complaint