Create GitHub Issues for client deliverables in DaveX2001/deliverable-tracking repo (discovery: rubber-duck). Evaluate at requirements-clarity when user mentions tracking, deliverables, commitments, or 'create deliverable'. Extracts What/Why/Done from conversation context, prompts for missing info via AskUserQuestion, applies dynamic client labels.
npx claudepluginhub mariuswilsch/claude-code-team-marketplaceThis skill uses the workspace's default tool permissions.
Create structured GitHub Issues for client deliverables after clarity phases establish shared understanding.
Breaks plans, specs, or PRDs into thin vertical-slice issues on the project issue tracker using tracer bullets. Useful for converting plans into approved, grabbable tickets.
Starts collaborative intake for new feature or bug tracks: verifies draft init, loads project context (product.md, tech-stack.md), checks overlaps, refines scope, generates spec.md and plan.md.
Mandates invoking relevant skills via tools before any response in coding sessions. Covers access, priorities, and adaptations for Claude Code, Copilot CLI, Gemini CLI.
Share bugs, ideas, or general feedback.
Create structured GitHub Issues for client deliverables after clarity phases establish shared understanding.
Review the conversation above to extract:
Use AskUserQuestion to gather any fields not clearly extractable from context:
Required fields:
- Client name (for label and title prefix)
- Brief description (for title)
- What (if not clear from conversation)
- Why (if not clear from conversation)
- Definition of Done (if not clear from conversation)
Optional:
- Notes (references, blockers, context)
- Human Witness Hints (anything the tester should watch out for during Human Witness)
Format questions with 2-4 concrete options when possible. For free-form input, let user select "Other".
Title format: {Client}: {Brief description}
Body format (minimal - details live in tracking file):
## What?
[Deliverable description]
## Why?
[Motivation/importance]
## Tracking
๐ [DoD + AC](https://github.com/{owner}/{repo}/blob/main/.claude/tracking/issue-{N}/tracking.md)
## Human Witness Hints
[Optional: things the tester should watch out for during Human Witness - "pay attention to X", "test this in context Y"]
## Notes
[Optional: references, blockers, context]
๐ค
Note: The Tracking link is a placeholder. It will be updated after the tracking file is created and pushed in Step 5.5.
IF client == "CLAUDE-CODE-IMPROVEMENTS":
repo = "DaveX2001/claude-code-improvements"
ELSE:
repo = "DaveX2001/deliverable-tracking"
Create the issue with backlog label + client label:
# Check plugin path first, then ~/.claude/lib
script="$([ -f "${CLAUDE_PLUGIN_ROOT}/lib/create_tracking_issue.sh" ] && echo "${CLAUDE_PLUGIN_ROOT}/lib/create_tracking_issue.sh" || echo ~/.claude/lib/create_tracking_issue.sh)"
"$script" --repo {repo} --title "{title}" --body "{formatted body}" --label "backlog,{client}"
Label strategy:
backlog = initial triage status (all new issues start here){client} = client label for filtering (e.g., WILSCH-AI-INTERNAL, IITR)When creating tracking file for an EXISTING issue:
Move DoD from issue body โ tracking file
Update issue body to minimal format:
## What?
[Keep existing description]
## Why?
[Keep existing motivation]
## Tracking
๐ [DoD + AC](https://github.com/{owner}/{repo}/blob/main/.claude/tracking/issue-{N}/tracking.md)
## Human Witness Hints
[Optional: things the tester should watch out for]
## Notes
[Keep existing notes]
gh issue edit to update body:gh issue edit {N} --repo {repo} --body "{minimal body WITHOUT DoD}"
Why: Single source of truth. DoD in issue body + tracking file = confusion.
Before creating tracking.md, use AI judgment to determine if AC content exists in the conversation.
Why this matters: A tracking.md without AC content is a pointless placeholder. The file should only be created when there's actual AC to put in it.
YOU MUST create the tracking file immediately after issue creation. No exceptions.
After issue is created (or for legacy issues, after deciding to add tracking), extract the issue number and:
# Check plugin path first, then ~/.claude/lib
script="$([ -f "${CLAUDE_PLUGIN_ROOT}/lib/create_tracking_file.sh" ] && echo "${CLAUDE_PLUGIN_ROOT}/lib/create_tracking_file.sh" || echo ~/.claude/lib/create_tracking_file.sh)"
"$script" {N} "{title}"
Pass Structure Preservation: If ac-create produced DoD with pass headers (### Pass N: [description]), YOU MUST preserve this structure when writing to tracking.md. Do NOT flatten passes into a single list.
## Definition of Done
### Pass 1: [description]
- [ ] item 1
- [ ] item 2
### Pass 2: [description]
- [ ] item 3
Same applies to AC section - preserve pass headers and AC numbering (AC1.1, AC2.1, etc.).
Markdown Line Break Rule (REQUIRED for readability):
Any element you want on its own line MUST have a blank line before it. Without blank lines, markdown renders consecutive lines as a single paragraph - unreadable for humans.
**Line 1** content here
**Line 2** content here
**Line 3** content here
git add .claude/tracking/issue-{N}/
git commit -m "Create tracking file for #{N}"
git push
gh issue edit {N} --repo {repo} --body "{updated body with correct GitHub URL}"
Why this matters: The tracking file must be pushed before linking. Local paths = version conflicts. Pushed = authoritative source.
Report:
Trigger: After /rubber-duck session defines AC in conversation.
Extract AC from conversation (Given-When-Then format)
Update tracking file:
# Edit .claude/tracking/issue-{N}/tracking.md
# Replace AC placeholder with defined AC
git add .claude/tracking/issue-{N}/
git commit -m "Add AC for #{N}"
git push
Note: This step is invoked separately after rubber-duck, not during initial issue creation.