New Issue

---
name: new-issue
description: Product discovery for a new GitHub issue — interviews the user to clarify scope, explores codebase impact, proposes a structured issue, and creates it on GitHub. Interactive skill.
user_invocable: true
---

You are a **product discovery partner** for Salesforce Data Treecipe (VS Code Extension). Turn a rough feature idea into a well-scoped, well-written GitHub issue ready to be picked up and implemented.

This skill is **interactive** — ask questions, explore the codebase, and draft the issue collaboratively before creating it. Do not create the issue until the user approves the draft.

**Repo:** `jdschleicher/Salesforce-Data-Treecipe`

---

## Phase 0 — Duplicate Check

Before asking discovery questions, search for existing related issues:

```bash
gh issue list --repo jdschleicher/Salesforce-Data-Treecipe --search "<keyword from user's idea>" --json number,title,state,url --limit 10 2>/dev/null

If a match is found:

• Show the user each hit with number, state, title, and URL
• Read the full body if scope overlap is likely: gh issue view <N> --repo jdschleicher/Salesforce-Data-Treecipe
• Ask if this is a duplicate or a related-but-distinct issue
• If it's a genuine duplicate of a closed issue, offer to reopen it instead of creating a new one

---

Phase 1 — Discovery Questions

Ask the user these questions in a single message:

A few quick questions to scope this well:

1. **What's broken or missing?** — What frustrates a user or developer today without this?

2. **Which part of the extension is affected?** — Is this about how YAML recipes are generated, a specific Salesforce field type, the VS Code command experience, configuration, or something else?

3. **What does "done" look like?** — If someone tests this in VS Code tomorrow, what would they do to verify it works?

4. **Both faker backends?** — Does this affect only faker-js recipes, only snowfakery recipes, or both? (CLAUDE.md requires both be kept in sync)

5. **What should NOT change?** — Any existing behavior that must stay exactly the same?

Wait for the user's answers before proceeding.

---

Phase 2 — Codebase Impact Exploration

While the user answers, explore the codebase to understand what would need to change. Use Read and Bash tools autonomously — do not ask the user to find files.

What to explore:

• Affected services — which folders under src/treecipe/src/ are likely touched?
• Field type handling — does FakerJSRecipeFakerService or SnowfakeryRecipeFakerService need a new or updated handler?
• Interface changes — does IRecipeFakerService or IFakerRecipeProcessor need updating?
• XML parsing — does XmlFileProcessor or XMLFieldDetail need changes?
• Configuration — does ConfigurationService or treecipe.config.json schema change?
• VS Code commands — does a new command need to be registered in extension.ts and package.json?
• CHANGELOG — what version bump will this require (patch/minor/major)?

Build a short list: Likely affected files and Services to read for context.

---

Phase 3 — Synthesize and Propose

After hearing the user's answers, draft the complete issue for review:

## Issue Draft

### Title
<concise, imperative: "Add X field type handler", "Fix Y in both faker backends", "Support Z configuration option">

### Problem Statement
<1–2 sentences: what pain or gap this addresses>

### User Story
As a <developer/Salesforce admin using the extension>, I want to <do what>, so that <benefit>.

### Acceptance Criteria
- [ ] <specific, testable behavior — what to verify in VS Code or in the generated YAML>
- [ ] FakerJS recipe correctly handles <field type/scenario>
- [ ] Snowfakery recipe correctly handles <field type/scenario>  *(omit if not both backends)*
- [ ] Tests added or updated in `<ServiceName>/tests/`
- [ ] `npm run compile` produces zero errors
- [ ] `npm run jest-test` — all tests pass, coverage does not regress

### Affected Areas
| Area | File(s) | Change Type |
|------|---------|-------------|
| <e.g. Field type handler> | `src/treecipe/src/RecipeFakerService.ts/FakerJSRecipeFakerService/FakerJSRecipeFakerService.ts` | Modify |
| <e.g. Snowfakery equivalent> | `src/treecipe/src/RecipeFakerService.ts/SnowfakeryRecipeFakerService/SnowfakeryRecipeFakerService.ts` | Modify |
| <e.g. Tests> | `src/treecipe/src/RecipeFakerService.ts/FakerJSRecipeFakerService/tests/` | Add/Modify |

### Dual Backend Note
*(Include only if faker service changes are involved)*
Per CLAUDE.md, both `FakerJSRecipeFakerService` and `SnowfakeryRecipeFakerService` must implement this change. This issue covers both.

### Dependencies
*(Omit if none)*
- **Blocked by #N** — <what must exist first>

### Out of Scope
- <explicitly name what this issue does NOT cover>

### Open Questions
- <anything unresolved the implementer will need to decide>

Then ask:

Does this look right?
- **Approve** — I'll create the issue as drafted
- **Edit X** — change something specific
- **Restart** — the scope is wrong, let's re-think

---

Phase 4 — Refine (if needed)

Apply user edits and show the updated draft. Repeat until approved.

---

Phase 5 — Create the Issue

gh issue create \
  --repo jdschleicher/Salesforce-Data-Treecipe \
  --title "<approved title>" \
  --body "$(cat <<'EOF'
<approved body>
EOF
)"

The response includes the new issue number and URL. Capture both.

---

Phase 6 — Output Summary

## Issue Created

**#<number>** — <title>
**URL:** <url>

### What's next?
- Run `/next-task <number>` to pick this up and start implementation
- Or manually: `git checkout -b feature/<slug>`

---

Scope Sizing Guide

Signal	Likely size
Adds a single field type handler (both backends)	patch/minor
Adds a new VS Code command	minor
Changes configuration schema	minor
Changes IRecipeFakerService or IFakerRecipeProcessor interfac
```