nestjs-mcp-server: Command for Claude Code

WHERE THE SPECIFICATION GOES — this is the whole point of the stage, so it is stated first:

Artifact	Written to	Contains
spec.md	.project/tasks/issue-<N>/	The technical analysis — the source of truth
test-plan.md	.project/tasks/issue-<N>/	The QA / acceptance plan /develop will execute

The GitHub issue is READ, never written. No pointer, no summary, no comment, no label change — nothing. The issue is the requirement as its author wrote it; the specification is your local analysis of how to satisfy it. Two artifacts, two owners, no synchronisation between them and therefore no way for them to disagree.

You have no GitHub write tool in allowed-tools, deliberately. If you find yourself wanting to put the SPEC — or a summary of it, or a link to it — into the issue, that is the design saying no.

The specifier agent is the executor — it inspects the code, resolves real names, decides the Public API and SemVer impact, and records the architecture/security findings. You invoke it; you never replicate its work inline.

There is no subtask stage. One repository, one published package — Caperifai's work-breakdown stage has no equivalent here. One issue is one unit of work.

For anything unclear — an acceptance criterion that doesn't say what success looks like, a capability whose exported shape was never decided, a bug with no root cause yet — ask. Never invent the scope, the diagnosis, an acceptance criterion, or a dependency.

A bug issue with no root cause is not ready to spec. Point at /debug <#N> first: a SPEC built on a guessed cause specifies the wrong fix, and does it in a form that looks authoritative.

"Not ready to spec" is a valid, useful outcome. If the requirement admits several materially different designs and the choice was never made, the SPEC says so and names the specific question that must be answered — it does not invent a design that reads as decided. That outcome still gets written: the analysis is worth keeping, and the named question is the deliverable.

1. Read the issue AND its comments (issue_read, method: "get" then "get_comments") — its requirement and its full acceptance criteria. In this repository the load-bearing constraints frequently live in comments, not the body. Read only; you are not going to write back.

2. Check the workspace for prior work — .project/tasks/issue-<N>/. This is a re-entry check, and getting it wrong discards decisions the user already made:

   • spec.md exists → report what it says and ask whether to refine it (the spec-driven skill's Refine action) or leave it. Never blind-overwrite: .project/ is gitignored, so there is no diff and no history to recover a dropped section from.
   • notes.md exists → read it. It holds what was already tried and ruled out; re-proposing a rejected approach is the specific waste it exists to prevent.
   • verification.md exists → development already ran against the current SPEC. Say so before changing anything underneath it: a refine that moves the approach invalidates evidence already gathered, and the user needs to know which criteria would have to be re-proven.