[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DVQ55SFS221VRZ2F0RW1TZ":3,"skill-same:01M6DVQ55SFS221VRZ2F0RW1TZ":76},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":43,"linkOnly":44,"markdownContent":45,"markdownBody":46,"frontMatter":47,"refName":48,"commitSha":49,"skillDirectory":50,"forksCount":51,"repositoryHtmlUrl":52,"repositoryHomepageUrl":6,"ownerHtmlUrl":53,"ownerBlogUrl":54,"ownerDescription":6,"updatedAt":55,"install":56,"resources":69},"01M6DVQ55SFS221VRZ2F0RW1TZ","spec",null,"Functional contract of the goal workflow — normalize any planning source (Jira US, GitHub issue, spec file, PRD\u002FBMAD story, a ticket cut by \u002Fgoal:tickets, brainstorm, inline note), grill the functional gaps closed one question at a time, build the functional Definition of Done (an observable acceptance criterion per business rule — no project command named here), run the opt-in adversarial grill, and OPTIONALLY mirror the intent as a GitHub issue. Technical grill, decomposition and the locked plan are \u002Fgoal:plan's.","FabienSalles\u002Fclaude-marketplace","FabienSalles","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F937901?v=4","01M6DVJBD31CJKRB382FQFZ5FH","Fabien Salles","01M6DVJBQNY8Q18KJD1ESAD6TX",9,"MIT","https:\u002F\u002Fgithub.com\u002FFabienSalles\u002Fclaude-marketplace\u002Fblob\u002Fmain\u002Fplugins\u002Fgoal\u002Fskills\u002Fspec\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000037","律师与法务","PROFESSION","适用职业",[5,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42],"goal","ticket","cut","decomposition","project","time","done","intent","grill","issue","command","question","brainstorm","plan","acceptance","run","jira","workflow","definition of done","2026-11-10 10:12:30",false,"---\nname: spec\ndescription: Functional contract of the goal workflow — normalize any planning source (Jira US, GitHub issue, spec file, PRD\u002FBMAD story, a ticket cut by \u002Fgoal:tickets, brainstorm, inline note), grill the functional gaps closed one question at a time, build the functional Definition of Done (an observable acceptance criterion per business rule — no project command named here), run the opt-in adversarial grill, and OPTIONALLY mirror the intent as a GitHub issue. Technical grill, decomposition and the locked plan are \u002Fgoal:plan's.\n---\n\n## Portability\n\nThis skill degrades gracefully outside Claude Code:\n\n- Shared fallbacks: read `\u003Croot>\u002Fshared\u002Fportability.md`.\n- No Atlassian MCP → ask the developer to paste the Jira source inline (see the\n  `$ARGUMENTS` table below, which already routes to this fallback).\n- No `pbcopy` → print the content instead of copying it to the clipboard.\n\n## Host\n\n`\u003Croot>` is Claude Code's substituted `${CLAUDE_PLUGIN_ROOT}`. A host that leaves it literal\n(Copilot CLI) reads `\u003Croot>` as two levels above `Base directory for this skill:`.\nA host that injects no base-directory line and reads `SKILL.md` itself (Codex CLI) takes `\u003Croot>` as two levels\nabove that file's directory.\n`$ARGUMENTS` left literal is the text typed after the command (empty when none).\nUse `\u003Croot>` wherever a command below says `${CLAUDE_PLUGIN_ROOT}`.\n\nWhen `\u003Croot>\u002Fsrc\u002Fartifacts.ts` or a shared file this skill names is missing, print\n`cannot locate the goal plugin scripts`, the host, and the install commands, run nothing and write nothing:\n`copilot plugin marketplace add \u003Crepository>` then\n`copilot plugin install goal@fabien-claude-marketplace` under Copilot,\n`codex plugin marketplace add \u003Crepository>` then\n`codex plugin add goal@fabien-claude-marketplace` under Codex,\n`\u002Fplugin install goal@fabien-claude-marketplace` under Claude Code.\n\nThen read `\u003Croot>\u002Fshared\u002Fhost.md`.\n\n# \u002Fgoal:spec — Source → functional contract (+ optional GitHub issue)\n\nYou are turning a raw planning artifact into the **functional contract** that\n`\u002Fgoal:plan` executes against: the need, the scope, the business rules, and a\n**functional Definition of Done** — one observable acceptance criterion per rule.\nCreating a GitHub issue from it is **optional** — you **ask**, you never impose it.\n\nThis is the level where **what must become true** is settled. **How** it is proven\n(commands), decomposed and delivered is `\u002Fgoal:plan`'s level, and stays out of this\nsession entirely.\n\n```\n(chantier too big for one spec)\n   └─ \u002Fgoal:tickets ─▶ ordered backlog; each ticket lands here at its turn\n(idea \u002F Jira US \u002F GitHub issue \u002F PRD \u002F BMAD story \u002F brainstorm)\n   └─ \u002Fgoal:spec ← YOU ARE HERE\n        ├─ functional contract written to \u003Cplans>\u002F\u003Cwork-id>-spec.md   (always)\n        └─ GitHub issue mirror                                             (only if the developer says yes)\n             └─ \u002Fgoal:plan \u003Csource>\n                  └─ manual: \u002Fgoal + \u002Fgoal:next · commit+pr: \u002Fgoal:supervise\n```\n\n## Project artifact root\n\nBefore resolving the source, run the existing resolver from the installed goal plugin:\n\n```bash\nproject=\"$(git rev-parse --show-toplevel)\"\nnode \"${CLAUDE_PLUGIN_ROOT}\u002Fsrc\u002Fartifacts.ts\" \"$project\"\n```\n\nThen read `\u003Croot>\u002Fshared\u002Fartifact-root.md`.\n\nIf `supplied` is false, ask for **docs\u002Fgoal\u002F**, **.goal\u002F** or a **custom path** and\nwait for the answer. Ask which project-root file, `.env` or `.env.local`, should\nhold `GOAL_ROOT_PATH`. Preserve all unrelated content; update only its assignment,\nquoting the chosen literal path. Do not execute shell expressions or expand variable\nreferences. A selected empty or invalid value is an error, never an absent value.\nIf `supplied` is true, use the effective value without asking for a location.\nUse the chosen value for this session by passing it as the resolver process's\n`GOAL_ROOT_PATH`; a child cannot change the parent session's environment. Resolve\nagain with that value before writing. Do not create Claude JSON configuration.\n\n## Argument — resolve the source\n\nSource: `$ARGUMENTS`\n\n| `$ARGUMENTS` shape | How to read it | work-id |\n|---|---|---|\n| Jira key `^[A-Z][A-Z0-9]+-[0-9]+$` (e.g. `CT-1234`) | Atlassian MCP — see below | key lowercased → `ct-1234` |\n| Bare integer `42` or `#42` | `gh issue view 42 --json number,title,body,labels,comments` (needs `gh auth`) | `issue-42` |\n| A backlog written by `\u002Fgoal:tickets` (file starts `# Backlog:`) | Take the ticket marked `← next` — and only it. The rest of the backlog is context, not scope | ≤40-char kebab slug of the ticket title |\n| Any other path ending in `.md` | Read the file | ≤40-char kebab slug of the title |\n| `inline` or empty | Ask the developer to paste the source now | ≤40-char kebab slug of the title |\n| A path that doesn't exist | STOP and tell the developer | — |\n\n**Reading a Jira source via MCP:** read `\u003Croot>\u002Fshared\u002Fjira-source.md` and follow it.\n\n## Phase 0 — Preconditions\n\n- `git rev-parse --show-toplevel` succeeds (we're in a repo)\n- **Only if the source is Jira:** the Atlassian MCP resolves\n- **Only if the source is a GitHub issue:** `gh auth status` succeeds\n- **Do NOT check `gh` otherwise.** GitHub as an *output* is only touched in\n  Phase 5, and only if the developer opts in.\n\nIf a needed check fails, STOP and say what to fix.\n\n## Phase 1 — Read & extract\n\nNormalize the source into these sections (headings vary by upstream tool):\n\n| Target section | Upstream synonyms |\n|---|---|\n| **Title** | first `# …`, BMAD `story.title`, spec-first \"Feature\", Jira summary |\n| **Problem** | \"Why\", \"Context\", \"Background\", \"Pain\", the incident that triggered the ticket |\n| **Objective** | \"Goal\", \"Outcome\", \"Definition of success\", BMAD `story.description` |\n| **Success signal** | \"How we'll know\", \"Metric\", \"KPI\" — rarely present, usually to be built |\n| **Affected** | \"Users\", \"Personas\", \"Impacted teams\", the caller named in a bug report |\n| **Business intent** | the prose that connects the four above, Jira description |\n| **Scope IN** | \"In scope\", \"Requirements\", BMAD `acceptance_criteria` (positive), Jira AC |\n| **Scope OUT** | \"Out of scope\", \"Non-goals\", \"Will not do\" |\n| **Acceptance criteria** | \"Done when\", \"Success criteria\", Jira AC |\n| **Files to touch** (optional) | \"Files to create\u002Fmodify\", \"Affected files\" |\n| **Decisions** (optional) | \"Q&A\", \"Clarifications\", Jira comment thread |\n\nNote which target sections the source is **missing** — a Jira US usually lacks a\nreal Definition of Done and often has functional gaps. Missing functional\nsections are not carried forward as flags: Phase 3 grills them closed **here**,\nwhile the developer is present. Only *technical* consequences you notice while\nreading (a migration, a coupling, a contract change) are flagged, for\n`\u002Fgoal:plan`.\n\n### Size verdict — one outcome, or a chantier?\n\nBefore grilling, rule on size. A spec covers **one outcome**: one success signal,\none delivery. When the source carries **several independent outcomes** — parts\nthat each have their own success signal and could ship weeks apart — or no single\nsuccess signal at all, it is a **chantier**: STOP and route to `\u002Fgoal:tickets`,\nwhich cuts it into an ordered backlog and sends each ticket back here at its\nturn. Grilling a chantier as one spec freezes guesses about parts nobody has\nlearned anything about yet.\n\nWhen the verdict is borderline or the developer disputes it, load\n`product:vertical-slice` and judge with it: parts that only mean something\ntogether are one outcome; parts that ship alone and stay valuable alone are a\nchantier's tickets.\n\n### Reproduce the problem\n\nBefore anything is graded against it, reproduce the Problem the source states — the\nsame commands and readings the source's own evidence points at, or the ones the\ndeveloper names when it doesn't. Record each command run and the value it produced;\nthat pair, verbatim, is what Phase 4 writes into `## Reproduction`. A problem that\ncannot be pointed at with a command is still caught by Phase 2's blocker for\nunevidenced problems — this step is for one that *can* be pointed at, and no longer\nshows what the source says it shows.\n\n## Phase 2 — Validate the need\n\n| Issue | Severity | Action |\n|---|---|---|\n| Empty business intent | ❌ blocker | Ask the developer to provide it now |\n| **Problem asserted with no evidence** (\"it would be better if…\") | ❌ blocker | A problem nobody can point at has no way to be closed. Ask for the incident, the measurement, the file and line. |\n| **Problem does not reproduce** (the commands run in Phase 1 now show something the source didn't claim, or already fixed) | ❌ blocker | STOP. Say what changed since the source was written, and do not write a contract against a premise that no longer holds. |\n| **Objective written as a solution** (\"rewrite X in Y\") | ⚠️ warn | Ask what must become *true*. A solution stated as an objective freezes a design before the grill has looked at it. |\n| No success signal | ⚠️ warn | Note it. Acceptance criteria prove behavior is in place; they never prove the problem is gone. |\n| No acceptance criteria at all | ⚠️ warn | Fine — Phase 3 builds the functional DoD; that is this session's deliverable |\n| Scope IN\u002FOUT mixed | ⚠️ warn | Propose a split |\n| Criteria not observable (\"code is clean\") | ℹ️ info | Rewrite as observable behavior in Phase 3; `\u002Fgoal:plan` maps it to a command later |\n\nResolve blockers with the developer before Phase 3.\n\n## Phase 3 — Functional grill (one question at a time)\n\nGoal: **close every functional gap**, so that `\u002Fgoal:plan` never has to ask a\nfunctional question — once decomposition starts, a functional hole is rework.\nTechnical consequences are NOT grilled here: when one surfaces, write it under\n`## Flags for \u002Fgoal:plan` and move on.\n\nPick the best available interview approach: read `\u003Croot>\u002Fshared\u002Fgrill-approach.md`, then:\n3. **`common:spec-first-dev` Phase 1 questions** if `common` is installed.\n4. **Inlined baseline** (below) — always works.\n\n### Inlined baseline questions (fallback)\n\nAsk one at a time, each with your recommended answer. Skip anything the source\nalready answers.\n\n- Who triggers this? (end user \u002F admin \u002F batch \u002F external system)\n- Precise end-to-end happy path, step by step?\n- Which **business rules** apply? (validations, computations, conditions, limits)\n- Vocabulary: project-specific terms to align with? Where do they live?\n- Business edge cases (not technical — real domain cases)?\n- What is explicitly **out of scope** for this delivery?\n- For each business rule: **what would you observe** to know it holds?\n  Behavior, not a command — naming the command is `\u002Fgoal:plan`'s job.\n\n### Stop condition\n\nStop grilling when: every functional gap is closed, every business rule carries\nan observable acceptance criterion, and no \"it depends\" remains. Typical: 5–15\nquestions for a small US, more for a feature. **One question per message** —\nbatch questionnaires reduce signal. A question the developer explicitly defers\nis recorded under `## Deferred decisions` with what was assumed instead — never\nsilently dropped.\n\n## Phase 3b — Adversarial grill (opt-in, runs HERE)\n\nThe baseline grill resolves the branches that get **raised**. It does not\nenumerate the interaction state space — so broken invariants and broken\nexecution schemas (interface\u002Fusage incoherence) slip through and surface later\nas rework. The `goal:grill-adversarial` skill closes that gap, and this is the\none place it runs: before anything downstream freezes. It is heavy — so it is\n**opt-in**.\n\nAsk the developer with `AskUserQuestion`:\n\n> **Run the adversarial grill on this spec now?**\n> - **yes (recommended for front \u002F interactive work, or when unsure)** —\n>   enumerate states, extract invariants, build the `(state × action)`\n>   transition matrix, and turn every hole into an owned rule with an\n>   observable criterion. Take altitude and question everything, including\n>   what was never defined.\n> - **no** — small US whose scenarios you fully enumerate and are confident\n>   about; or pure back \u002F transactional work where actions are coarse and\n>   server-owned.\n\nRecommend **yes** whenever the feature is **front \u002F interactive**, state lives\nclient-side, or Phase 1 flagged functional gaps. If yes → load\n**`goal:grill-adversarial`** and run it to termination; its states, invariants\nand transition matrix land in the contract below. Either way, record the\noutcome on the contract's `Adversarial grill:` line (`ran` \u002F `skipped — \u003Cwhy>`),\nso `\u002Fgoal:plan` and any later reader know whether the state space was\nenumerated or waved through.\n\n## Phase 4 — Write the functional contract\n\nWrite a new contract at `\u003Cplans>\u002F\u003Cwork-id>-spec.md`. When updating an explicitly\nselected existing contract, keep its path and update it in place:\n\n````markdown\n# Spec: \u003Ctitle>\n\nSource: \u003CJira CT-1234 | gh issue #42 | spec file path | ticket \u003Crank> of \u003Cchantier-id> | inline>\nWork-id: \u003Cwork-id>\nStatus: spec — functional contract settled; \u002Fgoal:plan builds the executable plan.\nAdversarial grill: \u003Cran | skipped — why>\n\n## Business intent\n\n**Problem.** \u003Cwhat fails today, with the evidence you can point at — an incident, a\nmeasurement, a file and a line. Never \"it would be better if\".>\n\n**Objective.** \u003Cwhat must become *true*. An outcome, not a solution: \"a locked plan runs\novernight and I wake up to PRs or a diagnosis\", not \"replace the loop with a script\".>\n\n**Success signal.** \u003Chow you would know it worked out in the real world. Distinct from the\nacceptance criteria, which only ever prove that behavior is in place.>\n\n**Affected.** \u003Cwho lives with the problem today, and what changes for them.>\n\n\u003CThen 1–3 paragraphs connecting the problem to the objective, in the developer's own domain\nvocabulary.>\n\n## Reproduction\n\u003Cthe exact commands run in Phase 1, each followed by the value it produced — the same evidence\nthe Problem line points at, kept alongside it so \u002Fgoal:plan and any later reader can re-run it>\n\n## Scope IN\n- \u003Citems>\n\n## Scope OUT\n- \u003Citems>\n\n## Business rules (functional DoD — one observable criterion per rule)\n- \u003Crule> → observed when: \u003Cthe behavior a human or a test can watch. No command named here — \u002Fgoal:plan maps each criterion to one>\n\n## States, invariants & transitions (only if the adversarial grill ran)\n- **States:** \u003CS1…Sk>\n- **Invariants:** \u003CI1…In — each with its owner; front-only ⇒ the front owns it>\n- **Transition matrix:** \u003C(state × action) → resulting state \u002F blocked \u002F invariant preserved>\n\n## Deferred decisions\n- \u003Cquestion the developer chose not to settle now, and what was assumed instead — or \"none\">\n\n## Files (as found in source)\n- `\u003Cpath>` — \u003Crole — only when the source named them; suspecting files is \u002Fgoal:plan's job>\n\n## Flags for \u002Fgoal:plan\n- \u003Ctechnical consequence noticed while reading — a migration, a cross-repo coupling, a contract change>\n\n## Notes \u002F decisions from source\n- \u003CQ\u002FA or comment-thread decision worth preserving>\n````\n\nShow the title and the contract to the developer, and read the **Business\nintent** block back to them explicitly. It is the one section nothing downstream\ncan reconstruct: `\u002Fgoal:plan` can map rules to commands, but it cannot invent\nwhy the work matters or how anyone would know it worked. WAIT for their\nconfirmation before Phase 5.\n\n## Phase 5 — Ask: create a GitHub issue? (opt-in)\n\nAsk explicitly:\n\n> **Do you also want a GitHub issue mirroring this contract?**\n> - **no** (default) — keep it local; go straight to `\u002Fgoal:plan`.\n> - **yes** — I'll `gh issue create` from it. (Optional: labels, milestone,\n>   assignee — I create nothing you didn't name.)\n\nWAIT for the answer.\n\nIf **no** → skip to Phase 6 with no GitHub involvement.\n\nIf **yes**:\n1. Now verify `gh auth status` and that `gh repo view` works. If either fails,\n   STOP, report, and fall back to the local-only handoff.\n2. Render the **intent projection** — and only it — into a temp file. The projection is\n   `## Business intent`, `## Scope IN`, `## Scope OUT` and the flags: the sections that will\n   still be true in three weeks. Add one closing line saying the executable plan lives locally\n   (versioned according to Git ignore rules) and that the pull request body is where the\n   delivered work is read.\n\n   Everything `\u002Fgoal:plan` will later produce — the command-mapped Definition of Done, the\n   iterations, the `gate` blocks — stays **out**. Those change at every slice, and an issue\n   holding a copy of them is wrong by the second commit while looking authoritative. The issue\n   is the log; the PR is the deliverable.\n\n   ```bash\n   TMP=$(mktemp -t goal-spec-XXXXXX.md)\n   ```\n3. Create it:\n   ```bash\n   gh issue create --title \"\u003Ctitle>\" --body-file \"$TMP\" \\\n     [--label \"\u003Clabels>\"] [--milestone \"\u003Cmilestone>\"] [--assignee \"\u003Cassignee>\"]\n   ```\n4. Capture the issue number `\u003CN>`. From now on the work-id is `issue-\u003CN>`; rename\n   the newly created spec to `\u003Cplans>\u002Fissue-\u003CN>-spec.md` so `\u002Fgoal:plan \u003CN>` finds it.\n   An explicitly selected existing contract stays in place; hand off its full path instead.\n\nDo **not** auto-create labels\u002Fmilestones\u002Fassignees — only what the developer named.\n\n## Phase 6 — Handoff\n\nThe developer has to be able to tell, from this output alone, **what now exists, what\ndeliberately does not yet, and the single next command.** Print exactly that shape, and make\nthe command the last thing on screen — nothing after it, no commentary, no summary.\n\n```\n✓ Functional contract written — \u003Cplans>\u002F\u003Cwork-id>-spec.md\n✓ GitHub issue created — \u003CURL>            (omit this line when local-only)\n\nThis contract has\n  · the need — problem, objective, success signal, who is affected\n  · scope IN and scope OUT\n  · \u003CR> business rules, each with an observable acceptance criterion\n  · states, invariants & transitions        (omit when the adversarial grill was skipped)\n  · \u003CD> deferred decisions and \u003CF> flags for \u002Fgoal:plan\n\nIt deliberately does NOT have yet\n  · no command-mapped Definition of Done — \u002Fgoal:plan gives every criterion its command\n  · no iterations, no branch, no code\n  · nothing is committed and nothing was pushed\n\nNext\n    \u002Fgoal:plan \u003CN or work-id>\n```\n\nFill `\u003CR>`, `\u003CD>` and `\u003CF>` with the real counts, and name the two or three flags that will\ncost the most to resolve — a developer who reads \"4 flags\" learns nothing, one who reads\n\"the export coupling is unconfirmed, and the flag mechanism is undecided\" knows what the next\nsession will ask them.\n\nIf the source was local-only, drop the issue line and use the work-id in the command.\nWhen an existing contract was selected explicitly, print its actual path and pass that\nfull path to `\u002Fgoal:plan`, rather than an identifier or a current-root substitute.\n\n## Rules\n\n- **GitHub as output is opt-in.** Never call `gh` to create anything unless the developer\n  said yes in Phase 5.\n- **Do not write production code, do not create branches** — everything here is contract.\n- **The functional DoD is built HERE.** Every business rule leaves this session with an\n  observable acceptance criterion. What is NOT built here: the command that proves it —\n  naming project commands is `\u002Fgoal:plan`'s verifiability round.\n- **No technical grilling.** A coupling, a migration, a data source you notice goes to\n  `## Flags for \u002Fgoal:plan`, never into a question round.\n- **One spec = one outcome.** Several independent outcomes are a chantier — route to\n  `\u002Fgoal:tickets` instead of writing a contract no single plan can execute.\n- **The adversarial grill runs here or not at all.** Downstream never re-opens the state\n  space; an unenumerated interaction discovered later is a spec fault that comes back to\n  this file.\n- **Standalone** — needs only a git repo, plus the Atlassian MCP for a Jira source and\n  `gh` only for a GitHub-issue source or the opt-in mirror.\n- **Never assert a problem the source did not evidence.** If it says \"improve X\", the problem\n  is missing and Phase 2 blocks. Inventing a plausible one puts a fabricated premise at the\n  head of a chain that will never re-examine it.\n- **One question at a time.**\n- **The handoff command is the last line you print.** Anything printed after it buries the\n  one thing the developer came for.\n","## Portability\n\nThis skill degrades gracefully outside Claude Code:\n\n- Shared fallbacks: read `\u003Croot>\u002Fshared\u002Fportability.md`.\n- No Atlassian MCP → ask the developer to paste the Jira source inline (see the\n  `$ARGUMENTS` table below, which already routes to this fallback).\n- No `pbcopy` → print the content instead of copying it to the clipboard.\n\n## Host\n\n`\u003Croot>` is Claude Code's substituted `${CLAUDE_PLUGIN_ROOT}`. A host that leaves it literal\n(Copilot CLI) reads `\u003Croot>` as two levels above `Base directory for this skill:`.\nA host that injects no base-directory line and reads `SKILL.md` itself (Codex CLI) takes `\u003Croot>` as two levels\nabove that file's directory.\n`$ARGUMENTS` left literal is the text typed after the command (empty when none).\nUse `\u003Croot>` wherever a command below says `${CLAUDE_PLUGIN_ROOT}`.\n\nWhen `\u003Croot>\u002Fsrc\u002Fartifacts.ts` or a shared file this skill names is missing, print\n`cannot locate the goal plugin scripts`, the host, and the install commands, run nothing and write nothing:\n`copilot plugin marketplace add \u003Crepository>` then\n`copilot plugin install goal@fabien-claude-marketplace` under Copilot,\n`codex plugin marketplace add \u003Crepository>` then\n`codex plugin add goal@fabien-claude-marketplace` under Codex,\n`\u002Fplugin install goal@fabien-claude-marketplace` under Claude Code.\n\nThen read `\u003Croot>\u002Fshared\u002Fhost.md`.\n\n# \u002Fgoal:spec — Source → functional contract (+ optional GitHub issue)\n\nYou are turning a raw planning artifact into the **functional contract** that\n`\u002Fgoal:plan` executes against: the need, the scope, the business rules, and a\n**functional Definition of Done** — one observable acceptance criterion per rule.\nCreating a GitHub issue from it is **optional** — you **ask**, you never impose it.\n\nThis is the level where **what must become true** is settled. **How** it is proven\n(commands), decomposed and delivered is `\u002Fgoal:plan`'s level, and stays out of this\nsession entirely.\n\n```\n(chantier too big for one spec)\n   └─ \u002Fgoal:tickets ─▶ ordered backlog; each ticket lands here at its turn\n(idea \u002F Jira US \u002F GitHub issue \u002F PRD \u002F BMAD story \u002F brainstorm)\n   └─ \u002Fgoal:spec ← YOU ARE HERE\n        ├─ functional contract written to \u003Cplans>\u002F\u003Cwork-id>-spec.md   (always)\n        └─ GitHub issue mirror                                             (only if the developer says yes)\n             └─ \u002Fgoal:plan \u003Csource>\n                  └─ manual: \u002Fgoal + \u002Fgoal:next · commit+pr: \u002Fgoal:supervise\n```\n\n## Project artifact root\n\nBefore resolving the source, run the existing resolver from the installed goal plugin:\n\n```bash\nproject=\"$(git rev-parse --show-toplevel)\"\nnode \"${CLAUDE_PLUGIN_ROOT}\u002Fsrc\u002Fartifacts.ts\" \"$project\"\n```\n\nThen read `\u003Croot>\u002Fshared\u002Fartifact-root.md`.\n\nIf `supplied` is false, ask for **docs\u002Fgoal\u002F**, **.goal\u002F** or a **custom path** and\nwait for the answer. Ask which project-root file, `.env` or `.env.local`, should\nhold `GOAL_ROOT_PATH`. Preserve all unrelated content; update only its assignment,\nquoting the chosen literal path. Do not execute shell expressions or expand variable\nreferences. A selected empty or invalid value is an error, never an absent value.\nIf `supplied` is true, use the effective value without asking for a location.\nUse the chosen value for this session by passing it as the resolver process's\n`GOAL_ROOT_PATH`; a child cannot change the parent session's environment. Resolve\nagain with that value before writing. Do not create Claude JSON configuration.\n\n## Argument — resolve the source\n\nSource: `$ARGUMENTS`\n\n| `$ARGUMENTS` shape | How to read it | work-id |\n|---|---|---|\n| Jira key `^[A-Z][A-Z0-9]+-[0-9]+$` (e.g. `CT-1234`) | Atlassian MCP — see below | key lowercased → `ct-1234` |\n| Bare integer `42` or `#42` | `gh issue view 42 --json number,title,body,labels,comments` (needs `gh auth`) | `issue-42` |\n| A backlog written by `\u002Fgoal:tickets` (file starts `# Backlog:`) | Take the ticket marked `← next` — and only it. The rest of the backlog is context, not scope | ≤40-char kebab slug of the ticket title |\n| Any other path ending in `.md` | Read the file | ≤40-char kebab slug of the title |\n| `inline` or empty | Ask the developer to paste the source now | ≤40-char kebab slug of the title |\n| A path that doesn't exist | STOP and tell the developer | — |\n\n**Reading a Jira source via MCP:** read `\u003Croot>\u002Fshared\u002Fjira-source.md` and follow it.\n\n## Phase 0 — Preconditions\n\n- `git rev-parse --show-toplevel` succeeds (we're in a repo)\n- **Only if the source is Jira:** the Atlassian MCP resolves\n- **Only if the source is a GitHub issue:** `gh auth status` succeeds\n- **Do NOT check `gh` otherwise.** GitHub as an *output* is only touched in\n  Phase 5, and only if the developer opts in.\n\nIf a needed check fails, STOP and say what to fix.\n\n## Phase 1 — Read & extract\n\nNormalize the source into these sections (headings vary by upstream tool):\n\n| Target section | Upstream synonyms |\n|---|---|\n| **Title** | first `# …`, BMAD `story.title`, spec-first \"Feature\", Jira summary |\n| **Problem** | \"Why\", \"Context\", \"Background\", \"Pain\", the incident that triggered the ticket |\n| **Objective** | \"Goal\", \"Outcome\", \"Definition of success\", BMAD `story.description` |\n| **Success signal** | \"How we'll know\", \"Metric\", \"KPI\" — rarely present, usually to be built |\n| **Affected** | \"Users\", \"Personas\", \"Impacted teams\", the caller named in a bug report |\n| **Business intent** | the prose that connects the four above, Jira description |\n| **Scope IN** | \"In scope\", \"Requirements\", BMAD `acceptance_criteria` (positive), Jira AC |\n| **Scope OUT** | \"Out of scope\", \"Non-goals\", \"Will not do\" |\n| **Acceptance criteria** | \"Done when\", \"Success criteria\", Jira AC |\n| **Files to touch** (optional) | \"Files to create\u002Fmodify\", \"Affected files\" |\n| **Decisions** (optional) | \"Q&A\", \"Clarifications\", Jira comment thread |\n\nNote which target sections the source is **missing** — a Jira US usually lacks a\nreal Definition of Done and often has functional gaps. Missing functional\nsections are not carried forward as flags: Phase 3 grills them closed **here**,\nwhile the developer is present. Only *technical* consequences you notice while\nreading (a migration, a coupling, a contract change) are flagged, for\n`\u002Fgoal:plan`.\n\n### Size verdict — one outcome, or a chantier?\n\nBefore grilling, rule on size. A spec covers **one outcome**: one success signal,\none delivery. When the source carries **several independent outcomes** — parts\nthat each have their own success signal and could ship weeks apart — or no single\nsuccess signal at all, it is a **chantier**: STOP and route to `\u002Fgoal:tickets`,\nwhich cuts it into an ordered backlog and sends each ticket back here at its\nturn. Grilling a chantier as one spec freezes guesses about parts nobody has\nlearned anything about yet.\n\nWhen the verdict is borderline or the developer disputes it, load\n`product:vertical-slice` and judge with it: parts that only mean something\ntogether are one outcome; parts that ship alone and stay valuable alone are a\nchantier's tickets.\n\n### Reproduce the problem\n\nBefore anything is graded against it, reproduce the Problem the source states — the\nsame commands and readings the source's own evidence points at, or the ones the\ndeveloper names when it doesn't. Record each command run and the value it produced;\nthat pair, verbatim, is what Phase 4 writes into `## Reproduction`. A problem that\ncannot be pointed at with a command is still caught by Phase 2's blocker for\nunevidenced problems — this step is for one that *can* be pointed at, and no longer\nshows what the source says it shows.\n\n## Phase 2 — Validate the need\n\n| Issue | Severity | Action |\n|---|---|---|\n| Empty business intent | ❌ blocker | Ask the developer to provide it now |\n| **Problem asserted with no evidence** (\"it would be better if…\") | ❌ blocker | A problem nobody can point at has no way to be closed. Ask for the incident, the measurement, the file and line. |\n| **Problem does not reproduce** (the commands run in Phase 1 now show something the source didn't claim, or already fixed) | ❌ blocker | STOP. Say what changed since the source was written, and do not write a contract against a premise that no longer holds. |\n| **Objective written as a solution** (\"rewrite X in Y\") | ⚠️ warn | Ask what must become *true*. A solution stated as an objective freezes a design before the grill has looked at it. |\n| No success signal | ⚠️ warn | Note it. Acceptance criteria prove behavior is in place; they never prove the problem is gone. |\n| No acceptance criteria at all | ⚠️ warn | Fine — Phase 3 builds the functional DoD; that is this session's deliverable |\n| Scope IN\u002FOUT mixed | ⚠️ warn | Propose a split |\n| Criteria not observable (\"code is clean\") | ℹ️ info | Rewrite as observable behavior in Phase 3; `\u002Fgoal:plan` maps it to a command later |\n\nResolve blockers with the developer before Phase 3.\n\n## Phase 3 — Functional grill (one question at a time)\n\nGoal: **close every functional gap**, so that `\u002Fgoal:plan` never has to ask a\nfunctional question — once decomposition starts, a functional hole is rework.\nTechnical consequences are NOT grilled here: when one surfaces, write it under\n`## Flags for \u002Fgoal:plan` and move on.\n\nPick the best available interview approach: read `\u003Croot>\u002Fshared\u002Fgrill-approach.md`, then:\n3. **`common:spec-first-dev` Phase 1 questions** if `common` is installed.\n4. **Inlined baseline** (below) — always works.\n\n### Inlined baseline questions (fallback)\n\nAsk one at a time, each with your recommended answer. Skip anything the source\nalready answers.\n\n- Who triggers this? (end user \u002F admin \u002F batch \u002F external system)\n- Precise end-to-end happy path, step by step?\n- Which **business rules** apply? (validations, computations, conditions, limits)\n- Vocabulary: project-specific terms to align with? Where do they live?\n- Business edge cases (not technical — real domain cases)?\n- What is explicitly **out of scope** for this delivery?\n- For each business rule: **what would you observe** to know it holds?\n  Behavior, not a command — naming the command is `\u002Fgoal:plan`'s job.\n\n### Stop condition\n\nStop grilling when: every functional gap is closed, every business rule carries\nan observable acceptance criterion, and no \"it depends\" remains. Typical: 5–15\nquestions for a small US, more for a feature. **One question per message** —\nbatch questionnaires reduce signal. A question the developer explicitly defers\nis recorded under `## Deferred decisions` with what was assumed instead — never\nsilently dropped.\n\n## Phase 3b — Adversarial grill (opt-in, runs HERE)\n\nThe baseline grill resolves the branches that get **raised**. It does not\nenumerate the interaction state space — so broken invariants and broken\nexecution schemas (interface\u002Fusage incoherence) slip through and surface later\nas rework. The `goal:grill-adversarial` skill closes that gap, and this is the\none place it runs: before anything downstream freezes. It is heavy — so it is\n**opt-in**.\n\nAsk the developer with `AskUserQuestion`:\n\n> **Run the adversarial grill on this spec now?**\n> - **yes (recommended for front \u002F interactive work, or when unsure)** —\n>   enumerate states, extract invariants, build the `(state × action)`\n>   transition matrix, and turn every hole into an owned rule with an\n>   observable criterion. Take altitude and question everything, including\n>   what was never defined.\n> - **no** — small US whose scenarios you fully enumerate and are confident\n>   about; or pure back \u002F transactional work where actions are coarse and\n>   server-owned.\n\nRecommend **yes** whenever the feature is **front \u002F interactive**, state lives\nclient-side, or Phase 1 flagged functional gaps. If yes → load\n**`goal:grill-adversarial`** and run it to termination; its states, invariants\nand transition matrix land in the contract below. Either way, record the\noutcome on the contract's `Adversarial grill:` line (`ran` \u002F `skipped — \u003Cwhy>`),\nso `\u002Fgoal:plan` and any later reader know whether the state space was\nenumerated or waved through.\n\n## Phase 4 — Write the functional contract\n\nWrite a new contract at `\u003Cplans>\u002F\u003Cwork-id>-spec.md`. When updating an explicitly\nselected existing contract, keep its path and update it in place:\n\n````markdown\n# Spec: \u003Ctitle>\n\nSource: \u003CJira CT-1234 | gh issue #42 | spec file path | ticket \u003Crank> of \u003Cchantier-id> | inline>\nWork-id: \u003Cwork-id>\nStatus: spec — functional contract settled; \u002Fgoal:plan builds the executable plan.\nAdversarial grill: \u003Cran | skipped — why>\n\n## Business intent\n\n**Problem.** \u003Cwhat fails today, with the evidence you can point at — an incident, a\nmeasurement, a file and a line. Never \"it would be better if\".>\n\n**Objective.** \u003Cwhat must become *true*. An outcome, not a solution: \"a locked plan runs\novernight and I wake up to PRs or a diagnosis\", not \"replace the loop with a script\".>\n\n**Success signal.** \u003Chow you would know it worked out in the real world. Distinct from the\nacceptance criteria, which only ever prove that behavior is in place.>\n\n**Affected.** \u003Cwho lives with the problem today, and what changes for them.>\n\n\u003CThen 1–3 paragraphs connecting the problem to the objective, in the developer's own domain\nvocabulary.>\n\n## Reproduction\n\u003Cthe exact commands run in Phase 1, each followed by the value it produced — the same evidence\nthe Problem line points at, kept alongside it so \u002Fgoal:plan and any later reader can re-run it>\n\n## Scope IN\n- \u003Citems>\n\n## Scope OUT\n- \u003Citems>\n\n## Business rules (functional DoD — one observable criterion per rule)\n- \u003Crule> → observed when: \u003Cthe behavior a human or a test can watch. No command named here — \u002Fgoal:plan maps each criterion to one>\n\n## States, invariants & transitions (only if the adversarial grill ran)\n- **States:** \u003CS1…Sk>\n- **Invariants:** \u003CI1…In — each with its owner; front-only ⇒ the front owns it>\n- **Transition matrix:** \u003C(state × action) → resulting state \u002F blocked \u002F invariant preserved>\n\n## Deferred decisions\n- \u003Cquestion the developer chose not to settle now, and what was assumed instead — or \"none\">\n\n## Files (as found in source)\n- `\u003Cpath>` — \u003Crole — only when the source named them; suspecting files is \u002Fgoal:plan's job>\n\n## Flags for \u002Fgoal:plan\n- \u003Ctechnical consequence noticed while reading — a migration, a cross-repo coupling, a contract change>\n\n## Notes \u002F decisions from source\n- \u003CQ\u002FA or comment-thread decision worth preserving>\n````\n\nShow the title and the contract to the developer, and read the **Business\nintent** block back to them explicitly. It is the one section nothing downstream\ncan reconstruct: `\u002Fgoal:plan` can map rules to commands, but it cannot invent\nwhy the work matters or how anyone would know it worked. WAIT for their\nconfirmation before Phase 5.\n\n## Phase 5 — Ask: create a GitHub issue? (opt-in)\n\nAsk explicitly:\n\n> **Do you also want a GitHub issue mirroring this contract?**\n> - **no** (default) — keep it local; go straight to `\u002Fgoal:plan`.\n> - **yes** — I'll `gh issue create` from it. (Optional: labels, milestone,\n>   assignee — I create nothing you didn't name.)\n\nWAIT for the answer.\n\nIf **no** → skip to Phase 6 with no GitHub involvement.\n\nIf **yes**:\n1. Now verify `gh auth status` and that `gh repo view` works. If either fails,\n   STOP, report, and fall back to the local-only handoff.\n2. Render the **intent projection** — and only it — into a temp file. The projection is\n   `## Business intent`, `## Scope IN`, `## Scope OUT` and the flags: the sections that will\n   still be true in three weeks. Add one closing line saying the executable plan lives locally\n   (versioned according to Git ignore rules) and that the pull request body is where the\n   delivered work is read.\n\n   Everything `\u002Fgoal:plan` will later produce — the command-mapped Definition of Done, the\n   iterations, the `gate` blocks — stays **out**. Those change at every slice, and an issue\n   holding a copy of them is wrong by the second commit while looking authoritative. The issue\n   is the log; the PR is the deliverable.\n\n   ```bash\n   TMP=$(mktemp -t goal-spec-XXXXXX.md)\n   ```\n3. Create it:\n   ```bash\n   gh issue create --title \"\u003Ctitle>\" --body-file \"$TMP\" \\\n     [--label \"\u003Clabels>\"] [--milestone \"\u003Cmilestone>\"] [--assignee \"\u003Cassignee>\"]\n   ```\n4. Capture the issue number `\u003CN>`. From now on the work-id is `issue-\u003CN>`; rename\n   the newly created spec to `\u003Cplans>\u002Fissue-\u003CN>-spec.md` so `\u002Fgoal:plan \u003CN>` finds it.\n   An explicitly selected existing contract stays in place; hand off its full path instead.\n\nDo **not** auto-create labels\u002Fmilestones\u002Fassignees — only what the developer named.\n\n## Phase 6 — Handoff\n\nThe developer has to be able to tell, from this output alone, **what now exists, what\ndeliberately does not yet, and the single next command.** Print exactly that shape, and make\nthe command the last thing on screen — nothing after it, no commentary, no summary.\n\n```\n✓ Functional contract written — \u003Cplans>\u002F\u003Cwork-id>-spec.md\n✓ GitHub issue created — \u003CURL>            (omit this line when local-only)\n\nThis contract has\n  · the need — problem, objective, success signal, who is affected\n  · scope IN and scope OUT\n  · \u003CR> business rules, each with an observable acceptance criterion\n  · states, invariants & transitions        (omit when the adversarial grill was skipped)\n  · \u003CD> deferred decisions and \u003CF> flags for \u002Fgoal:plan\n\nIt deliberately does NOT have yet\n  · no command-mapped Definition of Done — \u002Fgoal:plan gives every criterion its command\n  · no iterations, no branch, no code\n  · nothing is committed and nothing was pushed\n\nNext\n    \u002Fgoal:plan \u003CN or work-id>\n```\n\nFill `\u003CR>`, `\u003CD>` and `\u003CF>` with the real counts, and name the two or three flags that will\ncost the most to resolve — a developer who reads \"4 flags\" learns nothing, one who reads\n\"the export coupling is unconfirmed, and the flag mechanism is undecided\" knows what the next\nsession will ask them.\n\nIf the source was local-only, drop the issue line and use the work-id in the command.\nWhen an existing contract was selected explicitly, print its actual path and pass that\nfull path to `\u002Fgoal:plan`, rather than an identifier or a current-root substitute.\n\n## Rules\n\n- **GitHub as output is opt-in.** Never call `gh` to create anything unless the developer\n  said yes in Phase 5.\n- **Do not write production code, do not create branches** — everything here is contract.\n- **The functional DoD is built HERE.** Every business rule leaves this session with an\n  observable acceptance criterion. What is NOT built here: the command that proves it —\n  naming project commands is `\u002Fgoal:plan`'s verifiability round.\n- **No technical grilling.** A coupling, a migration, a data source you notice goes to\n  `## Flags for \u002Fgoal:plan`, never into a question round.\n- **One spec = one outcome.** Several independent outcomes are a chantier — route to\n  `\u002Fgoal:tickets` instead of writing a contract no single plan can execute.\n- **The adversarial grill runs here or not at all.** Downstream never re-opens the state\n  space; an unenumerated interaction discovered later is a spec fault that comes back to\n  this file.\n- **Standalone** — needs only a git repo, plus the Atlassian MCP for a Jira source and\n  `gh` only for a GitHub-issue source or the opt-in mirror.\n- **Never assert a problem the source did not evidence.** If it says \"improve X\", the problem\n  is missing and Phase 2 blocks. Inventing a plausible one puts a fabricated premise at the\n  head of a chain that will never re-examine it.\n- **One question at a time.**\n- **The handoff command is the last line you print.** Anything printed after it buries the\n  one thing the developer came for.\n",{"name":5,"description":7},"main","479b264ec17cc5fafbf36287a1087472d3a386d3","plugins\u002Fgoal\u002Fskills\u002Fspec",2,"https:\u002F\u002Fgithub.com\u002FFabienSalles\u002Fclaude-marketplace","https:\u002F\u002Fgithub.com\u002FFabienSalles","https:\u002F\u002Ffabiensalles.com","2026-10-13 04:33:22",{"source":8,"skillName":5,"commands":57,"prompt":67,"zipAvailable":68},[58,61,64],{"tool":59,"command":60},"npx","npx skills add FabienSalles\u002Fclaude-marketplace --skill spec",{"tool":62,"command":63},"bunx","bunx skills add FabienSalles\u002Fclaude-marketplace --skill spec",{"tool":65,"command":66},"pnpm","pnpm dlx skills add FabienSalles\u002Fclaude-marketplace --skill spec","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FFabienSalles\u002Fclaude-marketplace\u002Fblob\u002Fmain\u002Fplugins\u002Fgoal\u002Fskills\u002Fspec\u002FSKILL.md",true,[70],{"path":71,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":74,"sourceHtmlUrl":75},"index.json","REFERENCE","参考文档",500,"https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fmalware-family-ransomware\u002Findex.json",[77,107,126,147,170,187],{"skillNo":78,"name":79,"nameZh":6,"description":80,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":81,"categories":82,"keywords":88,"publishedAt":43},"01M6DW2YS1MGF65JNS1QQ15QHS","vitest-test-conventions","ACTIVATE when writing Vitest tests, creating test files, using vi.fn()\u002Fvi.mock()\u002Fvi.spyOn(), or test factories. ACTIVATE for 'Vitest', 'it.each', 'NestJS testing module', 'supertest', 'vi.fn', 'vi.mock', 'spyOn'. Provides Vitest\u002FNestJS-specific testing patterns; cross-language testing principles (DAMP, AAA, spy over mock, what NOT to test) live in craft:testing-principles. DO NOT use for: node:test files (a file importing node:test) or a project whose tests run under node --test (see node-test:node-test-conventions), TDD workflow\u002Fiterations (see vitest:vitest-tdd-workflow), PHP\u002FPHPUnit tests (see phpunit:php-test-conventions).","https:\u002F\u002Fgithub.com\u002FFabienSalles\u002Fclaude-marketplace\u002Fblob\u002Fmain\u002Fplugins\u002Fvitest\u002Fskills\u002Fvitest-test-conventions\u002FSKILL.md",[83],{"categoryNo":84,"categoryName":85,"taxonomyType":86,"taxonomyTypeDesc":87},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[89,90,91,92,93,94,95,41,96,97,98,99,100,101,102,28,103,104,105,106],"test","vitest","conventions","vitest test conventions","testing","writing","tdd","file","testing patterns","use","files","nestjs","activate","do","tests","module","fn","testing principles",{"skillNo":108,"name":109,"nameZh":6,"description":110,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":111,"categories":112,"keywords":116,"publishedAt":43},"01M6DW2VFE6NPFCGQKQ68P1MVZ","vitest-tdd-workflow","ACTIVATE when building new features, endpoints, or user stories using TDD with Vitest in a TypeScript\u002FNestJS context. ACTIVATE for '\u002Ffeature-tdd-dev', 'TDD', 'red-green-refactor' in TS context. Provides Vitest\u002FNestJS-specific TDD examples and commands; cross-language TDD workflow (cross-layer iterations, RED-GREEN-REFACTOR, working app, bug-fix-first-test, mocks-hiding-bugs) lives in craft:tdd-workflow-principles. DO NOT use for: node:test files (a file importing node:test) or a project whose tests run under node --test (see node-test:node-test-conventions), test writing conventions (see vitest:vitest-test-conventions), PHP TDD (see phpunit:php-tdd-workflow).","https:\u002F\u002Fgithub.com\u002FFabienSalles\u002Fclaude-marketplace\u002Fblob\u002Fmain\u002Fplugins\u002Fvitest\u002Fskills\u002Fvitest-tdd-workflow\u002FSKILL.md",[113],{"categoryNo":114,"categoryName":115,"taxonomyType":86,"taxonomyTypeDesc":87},"01JBSEEDCAT000000000000023","Skill与智能体开发",[95,41,117,90,118,94,119,96,120,121,98,122,99,101,102,123,28,103,124,125],"tdd workflow","vitest tdd workflow","dev","examples","fix","red-green-refactor","green","feature","app",{"skillNo":127,"name":128,"nameZh":6,"description":129,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":130,"categories":131,"keywords":132,"publishedAt":43},"01M6DW2RGMQE10D8C5Z5MA2RMY","ts-refactoring","ACTIVATE when refactoring TypeScript code. ACTIVATE for 'refactor', 'extract', 'redesign', 'simplify', or 'clean up' in a TypeScript \u002F Node \u002F NestJS context. This skill provides TS-specific examples for the cross-language refactoring rules defined in craft:refactoring-principles. DO NOT use for: writing new features from scratch, general OOP patterns (see ts-oop).","https:\u002F\u002Fgithub.com\u002FFabienSalles\u002Fclaude-marketplace\u002Fblob\u002Fmain\u002Fplugins\u002Ftypescript\u002Fskills\u002Fts-refactoring\u002FSKILL.md",[],[133,134,94,135,136,120,137,138,139,140,141,98,142,143,144,100,145,101,102,146],"refactoring","ts refactoring","typescript","code","refactor","simplify","Rules","node","redesign","up","general","clean","craft","patterns",{"skillNo":148,"name":149,"nameZh":6,"description":150,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":151,"categories":152,"keywords":154,"publishedAt":43},"01M6DW2MHYXNBBVYEGB058Y48J","ts-ports-adapters","ACTIVATE when a TypeScript codebase with no dependency-injection container has to declare a port and wire its adapter — a repository, a clock, an id generator, an event dispatcher the domain depends on. ACTIVATE for 'port', 'adapter', 'SPI', 'dependency inversion' or 'composition root' in a codebase that wires its dependencies by hand. Covers: the port as a type of functions in the domain layer, the adapter as an object literal annotated with it, the handler that takes its dependencies first and its data second, the composition root in the infrastructure layer, and the in-memory stub that substitutes for the adapter in a unit test. DO NOT use for: NestJS, or any container-based DI with decorators and tokens (see nest-ddd-conventions), aggregate operations and smart constructors (see ddd-ts-fp), the Result type itself (see ts-functional).","https:\u002F\u002Fgithub.com\u002FFabienSalles\u002Fclaude-marketplace\u002Fblob\u002Fmain\u002Fplugins\u002Ftypescript\u002Fskills\u002Fts-ports-adapters\u002FSKILL.md",[153],{"categoryNo":84,"categoryName":85,"taxonomyType":86,"taxonomyTypeDesc":87},[155,156,157,89,158,159,98,160,161,100,162,101,102,163,164,165,166,167,168,169],"ports","ts ports adapters","memory","ddd","Composition","container","functions","Literal","dependency-injection","domain","tokens","as","type","id","adapter",{"skillNo":171,"name":172,"nameZh":6,"description":173,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":174,"categories":175,"keywords":176,"publishedAt":43},"01M6DW2GRXZFYT05HEDB26C9B8","ts-oop","ACTIVATE when designing TypeScript classes, and the value objects or collections modelled as classes, or when the user asks about object design, encapsulation, Tell Don't Ask, or Symbol.iterator. Provides TS-specific examples for the cross-language OOP rules defined in craft:oop-principles, plus TS-specific patterns (Symbol.iterator, branded types for primitive identifiers). DO NOT use for: a value object or an aggregate modelled as an immutable record rather than a class (see ddd-ts-fp), refactoring methodology (see ts-refactoring).","https:\u002F\u002Fgithub.com\u002FFabienSalles\u002Fclaude-marketplace\u002Fblob\u002Fmain\u002Fplugins\u002Ftypescript\u002Fskills\u002Fts-oop\u002FSKILL.md",[],[177,178,179,135,158,120,180,181,133,139,182,98,183,145,101,102,184,185,186,166],"oop","ts oop","design","methodology","immutable","ask","refactoring methodology","objects","record","collections",{"skillNo":188,"name":189,"nameZh":6,"description":190,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":191,"categories":192,"keywords":193,"publishedAt":43},"01M6DW2D26XG5MJMTP9MSE43S2","ts-layer-boundaries","ACTIVATE when wiring a Worker entry point, a Router, a controller, or a domain event consumer in a TypeScript CQRS codebase, or when deciding where a port belongs. ACTIVATE for 'composition root', 'layer boundary', 'ESLint zones', 'domain must not import infrastructure'. Covers: the *Worker.ts composition root, the curried consumer, Router wiring of command endpoints, the five-gesture controller, the domain-to-infrastructure import boundary enforced by ESLint, infrastructure-only ports, in-memory doubles for every port, the read-can-reach-write asymmetry, and read endpoints going through a domain handler. DO NOT use for: the port's own shape and adapter binding (see ts-ports-adapters), the Result type (see ts-functional), domain event structure (see ts-ddd-events).","https:\u002F\u002Fgithub.com\u002FFabienSalles\u002Fclaude-marketplace\u002Fblob\u002Fmain\u002Fplugins\u002Ftypescript\u002Fskills\u002Fts-layer-boundaries\u002FSKILL.md",[],[194,157,158,195,196,159,155,98,197,198,199,101,102,200,164,201,202,167,169,203],"ts layer boundaries","controller","boundary","router","only","endpoints","structure","cqrs","worker","import"]