Update to Fullstack Dev Kit

{
  "description": "Turn an idea or description (in any format) into a well-formed backlog — epics, user stories with acceptance criteria, sub-tasks — and create it in the team's tracker after approval. Supports Jira, Linear, GitHub Issues, and Azure DevOps via adapters. Use when a product owner wants to draft or create tickets from an idea, brief, or document.",
  "included_files": [],
  "name": "plan-backlog",
  "skill_md_contents": "---\nname: plan-backlog\ndescription: Turn an idea or description (in any format) into a well-formed backlog — epics, user stories with acceptance criteria, sub-tasks — and create it in the team's tracker after approval. Supports Jira, Linear, GitHub Issues, and Azure DevOps via adapters. Use when a product owner wants to draft or create tickets from an idea, brief, or document.\n---\n\n# Plan Backlog\n\nTurn a product idea into a structured, well-formed backlog in the team's tracker — the **upstream** half of the issue-to-PR workflow, for the product-owner persona. It closes the loop **idea → backlog → ticket → PR** (created stories feed straight into `work-story`).\n\nThis is the *write* counterpart to `issue-fetch` (which reads). **Nothing is created until you approve the draft.**\n\n## Trigger\n\nA request to turn an idea / brief / description / document into tickets, epics, or a backlog — e.g. *\"draft stories for this feature\"*, *\"create Jira tickets from this doc\"*, *\"break this initiative into a backlog\"*.\n\n## Project configuration\n\nRead `.claude/dev-kit.json` at the consuming repo root. The `tracker` block names the active adapter and its settings:\n\n```json\n{ \"tracker\": { \"type\": \"jira\" | \"linear\" | \"github\" | \"azure\", ... } }\n```\n\n**If the file does not exist (or has no `tracker` block), run `dev-kit-setup` first** — it detects the tracker and persists the config, then returns here. Don't ask for values setup can discover.\n\n## 1. Intake — read the idea in whatever form it arrives\n\n- **Pasted text / chat description** → use directly.\n- **PDF** → read it (page range as needed).\n- **Word (`.docx`)** → not natively readable; convert first (`textutil -convert txt file.docx -output -` on macOS, or `pandoc file.docx -t markdown`), then read. If neither tool is available, ask the user to paste the text or export a PDF.\n- **Artifact / Confluence page / URL** → fetch it.\n- **Figma link** (`figma.com/(design|file)/…`) → run `figma-fetch` for design context.\n\nWork only from what the source says plus what the user confirms — **never invent scope or acceptance criteria.**\n\n## 2. Discovery-first — learn the team's hierarchy and conventions\n\nDon't impose a structure; **mirror the team's.** Using the adapter for `tracker.type`, discover:\n\n- the **issue types available and their hierarchy** (Epic / Story / Task / Feature / Sub-task, …),\n- the **fields that matter** (acceptance criteria, story points/estimate, epic/parent link, labels, components),\n- a **sample of recent issues** to calibrate granularity and writing style.\n\nAsk only what can't be discovered.\n\n## 3. Draft — a neutral model mapped to native types\n\nWork with a neutral backlog model, then map it onto the tracker's native types (§5):\n\n- **Initiative / Epic** → the outcome / theme.\n- **User Story** → *\"As a `<role>`, I want `<capability>`, so that `<value>`.\"* with **acceptance criteria** written as Given / When / Then, and **INVEST**-sized.\n- **Sub-tasks** → concrete steps, when they add clarity.\n- **Dependencies**, sizing hints, labels/components, and explicit **out-of-scope** notes.\n\nRecommend a shape based on discovery and **confirm it** with the user (e.g. *\"1 Epic + 5 stories, or split by feature/milestone?\"*) — don't force one.\n\n## 4. Approval gate (mandatory — create nothing yet)\n\nPresent the **full draft**: the hierarchy plus each item's title, description, acceptance criteria, labels, and links. **Wait for explicit approval**; the user may edit anything. Only after approval proceed to create. (Same doctrine as `work-story`'s plan gate — never create tickets without a human OK.)\n\n## 5. Create — via the tracker's write adapter\n\nCreate **parents before children**, link children to parents, and set labels/components/points where discovered. Report each created item with its key/URL.\n\n### Jira (`type: \"jira\"`) — Atlassian MCP\nConfig: `site`, `cloudId`, `projectKey`, `fields`.\n- Discover types/fields with `getJiraProjectIssueTypesMetadata` / `getJiraIssueTypeMetaWithFields`.\n- Create with `createJiraIssue` (project, issue type, summary, description, the acceptance-criteria field, labels, story points). Link stories to the epic via the epic-link field or `createIssueLink`; model dependencies with `createIssueLink` (Blocks / Relates).\n\n### Linear (`type: \"linear\"`) — Linear MCP\nConfig: `teamKey` (and optionally `workspace`).\n- Create issues under the team; use a **Project** (or a parent issue) as the epic, and **sub-issues** for sub-tasks; set labels/estimate/state. Put acceptance criteria in the description (a checklist).\n\n### GitHub Issues (`type: \"github\"`) — `gh`\nConfig: `repo` (`owner/name`; defaults to `origin`).\n- `gh issue create --repo <owner/name> --title <t> --body-file - --label <type>` (use `--milestone` as the epic/initiative). Acceptance criteria as a task list in the body; sub-tasks as sub-issues / task lists.\n- **Verify writes by read-back — never trust the exit code.** `gh issue edit`/label can fail while applying nothing on repos whose org ever used classic Projects. After creating/labelling, run `gh issue view <number> --json labels,milestone` and, on a miss, apply via REST (`gh api repos/<owner>/<repo>/issues/<number>/labels -f \"labels[]=<label>\"`).\n\n### Azure DevOps (`type: \"azure\"`) — Azure DevOps MCP / `az boards`\nConfig: `org`, `project`.\n- `az boards work-item create --type \"Epic|Feature|User Story|Task\" --title <t> --fields ...`; link parent/child with `az boards work-item relation add`. Acceptance criteria → `Microsoft.VSTS.Common.AcceptanceCriteria`.\n\n## Authentication\n\nIf the adapter's backend is not authenticated (MCP connector not authorized, `gh`/`az` not logged in), tell the user exactly how to authenticate — MCP connectors via `/mcp` or claude.ai connector settings; CLIs via `gh auth login` / `az login` — and stop. **Never create partial or placeholder items.**\n\n## 6. Handoff\n\nList the created items with their keys/URLs and hand off: each story is ready for **`work-story <KEY>` → PR**. That completes the loop **idea → backlog → ticket → PR**.\n\n## Guardrails\n\n- **Never create anything before explicit approval.**\n- **Discovery-first:** mirror the team's hierarchy and conventions; don't impose one.\n- **Don't fabricate** scope or acceptance criteria — ground everything in the source plus user confirmation.\n- Watch for **secrets/PII** in the source material; don't copy them into tickets.\n- On partial failure, report exactly what was created and what wasn't — never leave a half-built backlog unreported.\n"
}