Update to Fullstack Dev Kit

{
  "description": "Work a user story end to end — fetch the ticket, plan (with approval), implement, verify the applicable gates, self-review, open the PR, and update the tracker. Use when given an issue key like PROJ-1234, ENG-42, or",
  "included_files": [],
  "name": "work-story",
  "skill_md_contents": "---\nname: work-story\ndescription: Work a user story end to end — fetch the ticket, plan (with approval), implement, verify the applicable gates, self-review, open the PR, and update the tracker. Use when given an issue key like PROJ-1234, ENG-42, or #123. This is the orchestration playbook for hosts without a dedicated orchestrator subagent (Codex, and other Agent-Plugins clients); on Claude Code the `/work-story` command + `coding-agent` subagent do this instead.\n---\n\n# Work Story (orchestration)\n\nYou are the story orchestrator. Input: an issue key from the team's tracker. Output: a\npull request that satisfies the story's acceptance criteria with verified quality gates,\nand a tracker ticket that reflects it. **You run every step yourself, in order** — invoke\nthe kit's other skills as the steps below call for them; there is no separate orchestrator\nprocess here.\n\nIf no issue reference is given, ask for one — don't guess. Accept the shapes the configured\ntracker uses (`PROJ-1234` Jira, `ENG-42` Linear, `#123` GitHub/Azure).\n\n**Stack-agnostic.** Carry no assumptions about language, framework, or test runner. Read the\nrepo's `AGENTS.md` / `CLAUDE.md` and `.claude/` for build/test/lint/coverage commands and\nconventions, and follow them exactly; when silent, detect conventions from the repo — never\nimpose a stack. The always-on rules in `instructions/secure-coding.md` and\n`instructions/testing-standards.md` bind every step.\n\n## 1. Context\n- If `.claude/dev-kit.json` is missing, run **`dev-kit-setup`** first (one-time bootstrap:\n  tracker, project/team, field IDs).\n- Run **`issue-fetch`** for the ticket and show the summary.\n- If the ticket references Figma, run **`figma-fetch`** and summarize the UI intent.\n- Read the repo's project instructions and load the baseline stack profile\n  (`instructions/stacks/<id>.md` for the `stacks` in `.claude/dev-kit.json`); the repo's own\n  instructions always win, the profile fills gaps.\n\n## 2. Plan — WAIT FOR APPROVAL\nValidate assumptions against the running product when feasible (boot the app / exercise the\nflow) before writing the plan. Then present, **in the chat**, the ticket summary and a full\nplan — Understanding, Affected areas, numbered Implementation steps, Test plan, Open\nquestions — and **wait for the user's explicit approval**. Write no code until they approve\n(unless the invocation says the plan is pre-approved, e.g. an automated run).\n\n## 3. Implement\n- Follow the repo's conventions and architecture. Keep the diff scoped to the story — no\n  opportunistic refactors.\n- Update every side of any changed contract (payload/route/enum/schema/validation) together.\n- For user-facing frontend work, write accessible markup as you go (semantic HTML, labels,\n  `alt`, keyboard/focus) — cheaper than fixing it at review.\n\n## 4. Verify (gates — adaptive to the project)\nApply the gates that fit the project (detect its setup each run; see\n`instructions/testing-standards.md`). Report each as passed, failed (with output), or **not\napplicable** (reason + recommendation) — never silently skip. A `gates` policy in\n`.claude/dev-kit.json` can force `required`/`off`; default is auto-detect.\n- Unit tests for touched files pass — if the project has a test framework (don't scaffold one).\n- **`coverage-check`** — if the project has coverage tooling (touched files meet the bar,\n  default ≥ 95%, no regression). If none: recommend, don't fail.\n- **`e2e-generate`** for user-facing changes — if the project already does e2e.\n- Lint clean on touched files (when the project lints).\n- **Security pass (always applies):** review the diff against `instructions/secure-coding.md`;\n  any automatic-blocker is a gate — fix and re-check.\n\n## 5. Self-review\nRun **`pr-review`** on the full diff. Fix blocking findings (its counterpart playbook is\n**`fix-pr`**) and re-verify; note the non-blocking ones.\n\n## 6. Ship\nRun **`create-pr`**. Report the PR URL, the verification evidence, and any follow-up risks.\n\n## 7. Update the ticket\nRun **`issue-update`**: comment a product-facing summary (plain language) plus the PR link,\nand transition the ticket to the team's review status. The story isn't done until the\ntracker reflects it.\n\n## 8. Track follow-ups (offer — never force)\nIf the story left **loose ends** (out-of-scope notes in the PR, deferred `pr-review`/`fix-pr`\nfindings, deliberate TODOs), run **`follow-ups`**: offer to create them as tracked work items\nlinked to this story. Approval-gated — present the list, create nothing until approved; the\nuser may edit or skip. No genuine loose ends → say so and skip. Never fabricate follow-ups.\n\n## Reporting\nAt every step, state plainly what passed, what failed (with output), and what was skipped.\nNever report a gate as passed without having run it.\n"
}