refactor(sdd): make the feature spec issue-only (no committed spec.md)

The Gitea issue body is the single source of truth for a spec; the only
per-feature artifact in git is the RTM row (REQ-ID -> issue # -> test). Drops
per-feature spec.md/tasks.md/checklist files from the workflow (the _example
stays as a template/reference). Updates the guide, ADR-041, AGENTS.md, CLAUDE.md,
templates, the RTM (adds an Issue column), the implement/review-pr skills, and
replaces the file-spec CI jobs with an rtm-check.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

.claude/skills/implement/SKILL.md

@@ -54,12 +54,11 @@ Mark each concern with its source: reviewer name + comment excerpt.
 
 Also read:
 - `CLAUDE.md` for project conventions
-- **The feature's SDD artifacts**, if a spec exists for this issue: `.specify/features/<name>/spec.md`
-  (the `REQ-NNN` requirements + acceptance criteria), `tasks.md` (the red/green task list),
-  `api-contract.yaml` (the API shape), and `threat-model.md` (security obligations). If the
-  issue is a well-formed SDD spec but no `.specify/features/<name>/` directory exists yet,
-  create one from [the templates](../../../.specify/templates/) and mirror the spec into it.
-- [`.specify/rtm.md`](../../../.specify/rtm.md) — note each `REQ-NNN`'s current Status
+- **The issue body — it IS the spec** (issue-only; there is no committed `spec.md`). Extract its
+  `REQ-NNN` requirements, acceptance criteria, API stub, data-model delta, and any inline
+  STRIDE/threat notes. These are your contract.
+- [`.specify/rtm.md`](../../../.specify/rtm.md) — note each `REQ-NNN`'s current Status (rows are
+  keyed by this issue number)
 - Any relevant existing source files mentioned in the issue/comments
 - The current branch state (`git status`, `git log --oneline -10`)
 
@@ -101,9 +100,9 @@ Wait for the user to answer before continuing.
 
 ## Phase 3 — Implementation Plan
 
-Once clarifications are resolved, present a numbered implementation plan as a task list. **If
-the spec has a `tasks.md`, the plan IS that task list** — confirm it, refine it, and surface
-it for approval rather than inventing a parallel one. Each item must be:
+Once clarifications are resolved, present a numbered implementation plan as a task list,
+**derived from the issue's `REQ-NNN` requirements** (one or more tasks per requirement, in
+red/green order). Each item must be:
 
 - A single atomic unit of work (one behavior, one file change, one migration)
 - Written as a sentence that implies the test name: "Tag detail page returns 404 when tag does not exist"

.claude/skills/review-pr/SKILL.md

@@ -8,7 +8,7 @@ description: Multi-persona SDD code review of a Gitea PR. Each persona pairs its
 You will perform a thorough multi-persona code review of the given PR and post each persona's
 findings as a **separate comment**. Under SDD, the review verifies the diff against two
 contracts: the project [constitution](../../../.specify/constitution.md) and the feature's
-spec (`spec.md` — every `REQ-NNN` must be implemented **and** covered by a test).
+spec (the linked **Gitea issue body** — every `REQ-NNN` must be implemented **and** covered by a test).
 
 ## Argument
 
@@ -22,9 +22,8 @@ Parse it to extract `owner`, `repo`, and `pull_number`.
 Read before reviewing:
 - [`.specify/constitution.md`](../../../.specify/constitution.md) — rules the code must obey (esp. §4 Do-Not-Touch)
 - [`.specify/AGENTS.md`](../../../.specify/AGENTS.md) — constraints
-- The feature's spec, if the PR references one: `.specify/features/<name>/spec.md`, plus its
-  `api-contract.yaml`, `threat-model.md`, and `tasks.md`. Find the `REQ-NNN` ids it claims to
-  satisfy (from the PR description, `Closes #n`, or the spec's Traceability table).
+- The feature's spec — the **Gitea issue** the PR closes (`Closes #n`). Read its body for the
+  `REQ-NNN` requirements, acceptance criteria, inline API stub, and any STRIDE/threat notes.
 - [`.specify/rtm.md`](../../../.specify/rtm.md) — the requirement→test→status matrix
 
 ## Step 1 — Gather PR context