@kamilmarzynski/scifi 0.1.1

package/skills/sf-continue/body.md

@@ -0,0 +1,90 @@
+# sf-continue
+
+Work on a feature was put down — maybe mid-grill, maybe mid-build — and you are
+picking it back up. Your job is orientation, not execution: read where the
+feature actually is, name the next workflow step, and hand control to the skill
+that owns it. You do the *least* work needed to point at the right next move.
+
+You are a router. `sf-feature`, `sf-plan`, and `sf-implement` do the real work
+and each resumes from its own partial state. You decide which one, and where it
+should pick up.
+
+## Flow
+
+### 1. Identify the feature and enter its workspace
+
+- `/sf-continue <slug>` — treat the argument as an exact feature slug.
+- `/sf-continue <description>` or no argument — discover candidates from **both**
+  `scifi list --json` (features whose specs are on the current checkout) **and**
+  `git worktree list` (an in-flight feature lives on its own `feat/<slug>` branch
+  and will *not* appear in `scifi list` run from the default checkout). Match by
+  slug and title. If one obviously fits, name it; if several could, present them
+  and **confirm the pick with the user**. Never guess silently.
+- **Enter the feature's worktree before reading its state.** An in-flight
+  feature's `docs/scifi/specs/<slug>/.scifi.json` exists only on its `feat/<slug>`
+  branch — not in the default checkout. Run `git worktree list`; if
+  `.worktrees/feat-<slug>` (branch `feat/<slug>`) exists, enter it and read state
+  from there. Running `scifi status <slug>` from the default checkout would
+  otherwise report `NOT_FOUND` for a feature that is merely on another branch.
+- Conclude the feature does **not** exist only when *both* hold: no `feat/<slug>`
+  worktree exists **and** `scifi status <slug>` returns `NOT_FOUND` from a
+  checkout that would contain it (e.g. the default branch for a merged feature).
+  Then say so and point the user at `sf-feature`. A `NOT_FOUND` while a matching
+  worktree exists just means you are in the wrong checkout — enter the worktree
+  and re-read; never route the user to start a new feature in that case.
+
+### 2. Read the state
+
+```
+scifi status <slug> --json
+```
+
+Run this **from inside the feature's worktree** (entered in step 1). Read
+`status`, the `artifacts` inventory (`artifacts.spec`, `artifacts.design`,
+`artifacts.taskCount`), the per-task statuses in `tasks[]`, and `fixes[]` — each
+fix carries its own `status`, so filter for the open ones. That single call
+tells you everything you need to route. Do not start reading or editing the
+spec/design yourself — the owning skill will. The `worktree`/`branch` fields
+confirm the workspace you entered.
+
+### 3. Route by lifecycle status
+
+Map the state to the next step. The lifecycle is
+`created → spec-ready → plan-ready → in-progress → done`.
+
+| Status | What the inventory shows | Where it actually stands | Next move |
+| --- | --- | --- | --- |
+| `created` | `spec` missing | container made, spec never written | **`sf-feature`** — resume the grill and write `spec.md`. The container already exists, so skip its create step (`scifi spec` would `CONFLICT`); grill, write the spec, review, then `scifi spec-ready`. |
+| `created` | `spec` present | spec drafted but never gated | **`sf-feature`** — finish it: run `sf-spec-review`, then `scifi spec-ready`. |
+| `spec-ready` | no `design`, no tasks | spec gated, planning not begun | **`sf-plan`** — start planning. |
+| `spec-ready` | some `design`/tasks | planning interrupted | **`sf-plan`** — it detects the partial state and resumes. |
+| `plan-ready` | — | planned, build not begun | **`sf-implement`** — it runs `scifi start` and begins. |
+| `in-progress` | tasks mixed (pending/in-progress/done) | build interrupted | **`sf-implement`** — it skips `done` tasks and resumes at the next runnable one. |
+| `in-progress` | all tasks `done` | build finished, not closed out | **`sf-implement`**'s finish path — final `sf-handover` verification, then `scifi finish`. |
+| `done` | open `fixes` | feature closed but a fix is open | **`sf-fix`** — resolve the open fix (it blocks `scifi finish`). |
+| `done` | no open fixes | nothing to continue | Say so. For new scope use `sf-change`; for a defect use `sf-fix`. |
+
+### 4. Hand off
+
+Tell the user, in a sentence or two: where the feature stands, what the next
+step is, and which skill owns it. Then invoke that skill.
+
+**Pause where a human handoff is required.** Spec and planning sessions
+(`sf-feature`, `sf-plan`) are interactive grills — the user drives them. Hand
+control over and let them resume; do not autonomously grill on their behalf. The
+build (`sf-implement`) resumes on its own. Where the next step is a human action
+the tool cannot take (e.g. anything in `docs/scifi/HANDOVER.md`), name it and
+stop rather than guessing.
+
+## Hard rules
+
+- Never route from anything but the live `scifi status` output — not memory, not
+  the directory listing alone.
+- Never treat a `NOT_FOUND` as "feature missing" until you have checked
+  `git worktree list` for a `feat/<slug>` worktree and read status from inside
+  it. An in-flight feature is invisible to `scifi status` from the default
+  checkout — routing such a user to `sf-feature` would start a duplicate.
+- Never re-create a container that already exists; a `created` feature resumes
+  inside `sf-feature` without `scifi spec`.
+- Never silently pick a feature when the match is ambiguous — confirm first.
+- Never do the next step's deep work here — orient and hand off.

package/skills/sf-continue/manifest.ts

@@ -0,0 +1,8 @@
+import type { SkillManifest } from "scifi/skill-types";
+
+export const manifest: SkillManifest = {
+  id: "sf-continue",
+  description:
+    "Resume an interrupted feature. Reads `scifi status <slug> --json`, determines the next workflow step from lifecycle status, and runs the matching skill, pausing where human handoff is required.",
+  argumentHint: "[feature-slug | description]",
+};

package/skills/sf-feature/ADR-TEMPLATE.md

@@ -0,0 +1,16 @@
+# NNNN: <short decision title>
+
+- Status: Accepted
+- Date: <YYYY-MM-DD>
+
+## Context
+
+<The forces at play: the problem, the constraints, and the alternatives that existed.>
+
+## Decision
+
+<The choice that was made, stated plainly.>
+
+## Consequences
+
+<What becomes easier, what becomes harder, what we are now committed to.>

package/skills/sf-feature/DISPATCH-SPEC-REVIEW.md

@@ -0,0 +1,16 @@
+# Dispatch template: spec review
+
+Dispatch a subagent with the prompt below. Replace `{SPEC_PATH}` with the path
+returned by `scifi spec` (e.g. `docs/scifi/specs/<slug>/spec.md`). The
+review criteria and output format live in the `sf-spec-review` skill — do not
+restate them here.
+
+```
+You are reviewing a spec. Load and follow the `sf-spec-review` skill.
+
+This is a SPEC review (not a code review).
+Spec to review: {SPEC_PATH}
+
+Read the spec plus docs/scifi/CONTEXT.md,
+then return your report and verdict exactly as the sf-spec-review skill defines.
+```

package/skills/sf-feature/SPEC-TEMPLATE.md

@@ -0,0 +1,37 @@
+# Spec: <title>
+
+- **Slug:** <slug>
+- **Status:** draft
+
+## Problem / Why
+
+What problem does this solve, for whom, and why now? One or two paragraphs.
+Ground it in a real need, not a solution looking for a problem.
+
+## Scope
+
+### In scope
+
+- <what this feature will do>
+
+### Out of scope (non-goals)
+
+- <what this feature explicitly will NOT do>
+
+## Acceptance criteria
+
+Testable checklist. Each item must be verifiable as done or not done.
+
+- [ ] <criterion>
+- [ ] <criterion>
+
+## Architecture & Context impact
+
+- **Modules touched:** <files / areas this work changes>
+- **New CONTEXT.md terms:** <terms added, or "none">
+- **ADRs:** <decision records written or affected by this work, or "none">
+
+## Edge cases & open questions
+
+- **Edge cases:** <error states, boundaries, tricky inputs>
+- **Open questions:** <anything unresolved — must be empty or owned before spec-ready>

package/skills/sf-feature/body.md

@@ -0,0 +1,145 @@
+# sf-feature
+
+You run a grilling session for ONE feature. The session ends with a written
+`spec.md` and the feature marked spec-ready. This is spec creation only — no
+plan, no code.
+
+The skill is inspired by hard, friendly grilling: you interrogate the idea
+until it is unambiguous, confronting it against what the project already is.
+
+## Long-term memory
+
+Before grilling, read `docs/scifi/CONTEXT.md` (if present) — the project's
+ubiquitous language: the canonical glossary of domain terms. Use it to keep
+naming consistent. When the feature introduces a new domain term, define it in
+`CONTEXT.md` and apply the edit live once the user approves.
+
+For prior architectural decisions, see "Architecture Decision Records" below —
+grep them on demand rather than reading one big doc up front.
+
+## Architecture Decision Records
+
+Decisions live in `docs/scifi/adr/` as numbered records `NNNN-slug.md`. The
+directory is lazy — it does not exist until the first record.
+
+- **Read on demand.** When the feature touches an area that may already carry a
+  recorded decision, grep `docs/scifi/adr/` for relevant keywords — the same
+  instinct as grepping the codebase while grilling. Do not contradict a recorded
+  decision without surfacing it to the user.
+- **Write sparingly.** Record an ADR only when ALL THREE hold:
+  1. Difficult reversal — meaningful cost to changing course later.
+  2. Non-obvious rationale — a future reader will question the choice.
+  3. Genuine trade-offs — real alternatives existed; one was chosen deliberately.
+  A routine, obvious, or easily-reversed choice gets no ADR.
+- **Numbering.** Run `ls docs/scifi/adr/` and take `max + 1`, zero-padded (e.g.
+  `0007`). If the directory is absent, start at `0001` and create it. Copy
+  `ADR-TEMPLATE.md` (ships beside this skill) into the new file and fill it.
+
+## Flow
+
+### 1. Name and create (or reopen) the container
+
+**If you were sent here to resume or reopen an existing feature** — by
+`sf-continue` on a `created` feature, or by `sf-change` rolling a feature back to
+the spec stage — the container already exists. Do **not** run `scifi spec`; it
+would `CONFLICT`. Confirm the feature with `scifi status <slug> --json`; its
+worktree is reported as `worktree` (fallback: `.worktrees/feat-<slug>`). Enter
+that worktree and go straight to grilling against the spec that is already
+there. Skip the rest of this step.
+
+**Otherwise, for genuinely new work,** create the container:
+
+- Derive a short kebab-case slug from the request (e.g. `google-auth`).
+- If the user pasted an issue reference instead of a description — an issue
+  number, a URL, a Jira ticket, anything — resolve it however is appropriate
+  for that tracker to recover the actual request, then derive the slug.
+- **Create the feature's branch and worktree (this is automatic now).** From the
+  repository's default/integration branch, run (the commands below show it as
+  `main` — substitute your repo's actual default branch if it differs):
+
+  ```
+  git worktree add -b feat/<slug> .worktrees/feat-<slug> main
+  ```
+
+  This gives the feature an isolated workspace so several features can be in
+  flight at once without colliding. Work from inside `.worktrees/feat-<slug>`
+  for the rest of this skill and for planning and implementation. If the path
+  already exists, the feature was started before — treat this as the reopen case
+  above instead of creating a second worktree.
+- Create the container:
+
+  ```
+  scifi spec <slug> --title "<human title>" --json
+  ```
+
+  - `<slug>` is the kebab-case folder name. `--title` is optional prose.
+  - `--json` gives you a structured result. Read `path` from it — that is the
+    feature directory. Your spec goes at `<path>/spec.md`.
+  - On success the status is `created`.
+  - If it errors with `CONFLICT`, the slug already exists. If you meant to start
+    new work, pick a different slug; do not overwrite. If you actually meant to
+    revise that feature, this is the reopen case above — work against the
+    existing `<path>` instead of creating.
+- Record the workspace on the feature so status and resume can find it:
+
+  ```
+  scifi worktree set <slug> --branch feat/<slug> --path .worktrees/feat-<slug>
+  ```
+- Tell the user the slug you picked and the path.
+
+### 2. Grill (this is the real work)
+
+Interrogate until you can fill EVERY section of the spec template with no
+gaps. Do not write the spec before then.
+
+- One question at a time. Prefer concrete either/or questions.
+- Confront the idea against the codebase and any relevant ADRs (grep
+  `docs/scifi/adr/`). If it contradicts a recorded decision or existing
+  structure, surface it.
+- Drive toward: the real problem, what is explicitly out of scope, testable
+  acceptance criteria, the edge cases that will bite, and which modules the
+  work touches.
+- When you hit a new domain term, propose the `CONTEXT.md` edit and apply it
+  once the user agrees. When the grilling settles a hard, non-obvious
+  architectural decision, record an ADR (see above).
+
+You are convinced when every template section below has a real answer, not a
+placeholder.
+
+### 3. Write the spec
+
+- Copy `SPEC-TEMPLATE.md` (ships beside this skill) into `<path>/spec.md` —
+  where `<path>` is the directory returned by `scifi spec` — and fill every
+  section from the grilling.
+- No `TBD` / `TODO` left behind. Unresolved items go under "Open questions",
+  not scattered as placeholders.
+
+### 4. Review loop (gate)
+
+- Dispatch the review subagent using `DISPATCH-SPEC-REVIEW.md` (ships beside
+  this skill), filling in the spec path.
+- Process its report with the `sf-receiving-review` skill, passing **review
+  type: spec**. That skill governs how you act on the findings.
+- Re-dispatch until the verdict is **Pass** or **With fixes**; a **Fail**
+  re-loops. On **With fixes**, address the Minor items (or defer them with the
+  user's ok) before finalizing. Do not skip this.
+
+### 5. Finalize
+
+- Only after the review passes, run:
+
+  ```
+  scifi spec-ready <slug> --json
+  ```
+
+  - This validates that `<path>/spec.md` exists and transitions the feature
+    `created → spec-ready`.
+  - If it errors with `PRECONDITION_FAILED` (spec.md missing), you put the spec
+    in the wrong place — write it to `<path>/spec.md` and retry.
+- This is the end of spec creation. Planning happens later via `sf-plan`.
+
+## Hard rules
+
+- Never run `scifi spec-ready` before `sf-spec-review` passes.
+- Never write `spec.md` while any template section is still unanswered.
+- Never invent project facts — read the docs or ask.

package/skills/sf-feature/manifest.ts

@@ -0,0 +1,8 @@
+import type { SkillManifest } from "scifi/skill-types";
+
+export const manifest: SkillManifest = {
+  id: "sf-feature",
+  description:
+    "Start grilling session for new feature. Greps docs/scifi/adr/ for relevant decisions; records an ADR only for hard, non-obvious choices. Writes spec.md.",
+  argumentHint: "[title]",
+};

package/skills/sf-fix/DISPATCH-CODE-REVIEW.md

@@ -0,0 +1,25 @@
+# Dispatch template: tracked-fix code review
+
+Dispatch a subagent to review the fix before it is resolved. Replace
+`{COMMIT_RANGE}` with the commit(s) the fix produced (a SHA or `<base>..HEAD`),
+`{CHANGE_BRIEF}` with the root cause and the solution the user agreed to (a
+sentence or two), and `{FEATURE_PATH}` with the owning feature directory (e.g.
+`docs/scifi/specs/<slug>`). There is no task file — this is a **fix-mode**
+review, but the feature's spec/design are available as original intent. The
+criteria and output format live in the `sf-code-review` skill — do not restate
+them here.
+
+```
+You are reviewing a tracked fix. Load and follow the `sf-code-review` skill.
+
+This is a CODE review in FIX MODE (no task file; an owning feature exists).
+Changes to review: {COMMIT_RANGE}
+Agreed change (the contract): {CHANGE_BRIEF}
+Owning feature: {FEATURE_PATH}
+
+Judge the change against the brief: it implements the agreed solution and only
+that, a regression test reproduces the defect and now guards it, and it does not
+reintroduce a deviation from {FEATURE_PATH}/spec.md or {FEATURE_PATH}/design.md.
+Use docs/scifi/CONTEXT.md for glossary context if it exists. Return your report
+and verdict exactly as the sf-code-review skill defines.
+```

package/skills/sf-fix/body.md

@@ -0,0 +1,174 @@
+# sf-fix
+
+You run down ONE defect in an EXISTING feature and drive it to a fix. Unlike
+`sf-bug`, the work is anchored to a specific feature — you diagnose against that
+feature's original intent (its `spec.md`, `design.md`, and ADRs) — and it leaves
+a tracked artifact: a fix recorded under the feature, which blocks `scifi finish`
+until you resolve it.
+
+The session has two halves separated by a hard seam: first you investigate
+*together* until the cause is understood and a fix is chosen, then you implement
+that fix test-first under review. You do not start fixing until the user agrees
+on which solution to build.
+
+## The Iron Law
+
+```
+IDENTIFY FEATURE → INVESTIGATE → REPORT → AGREE → TRACK → FIX → RESOLVE.
+NEVER FIX BEFORE THE USER AGREES.
+```
+
+## Flow
+
+### 1. Identify the feature
+
+The fix must attach to one feature. Resolve it before anything else.
+
+- `/sf-fix <slug>` — treat the argument as an exact feature slug.
+- `/sf-fix <description>` — you were given prose, not a slug. Discover candidates
+  from **both** `scifi list --json` and `git worktree list` (an in-flight feature
+  lives on its own `feat/<slug>` branch and will not appear in `scifi list` from
+  the default checkout). Match candidate features by slug and title. Present your
+  best match (or the candidates, if ambiguous) and **confirm the pick with the
+  user**. Never guess silently.
+- **Locate the feature, then confirm it exists.** Run `git worktree list`; if a
+  `feat/<slug>` worktree exists, read `scifi status <slug>` from inside it. Only
+  when *no* matching worktree exists **and** `scifi status <slug>` returns
+  `NOT_FOUND` from a checkout that would contain it is the feature truly absent —
+  then stop: a defect with no owning feature goes to `sf-bug` (untracked), real
+  new work to `sf-feature`. A `NOT_FOUND` while a `feat/<slug>` worktree exists
+  just means you are in the wrong checkout, not that the feature is gone.
+
+Once identified, read the feature's `spec.md` and `design.md`, and grep
+`docs/scifi/adr/` for decisions touching the area. Diagnosis is grounded in the
+feature's original intent.
+
+**Warn if the feature is not `done`.** A defect in an in-progress feature usually
+belongs in `sf-implement`'s own review loop, not a separate tracked fix. Say so,
+and proceed only if the user confirms `sf-fix` is what they want.
+
+Create an isolated workspace for the fix before investigating (the base branch
+shows as `main` — substitute your repo's default branch if it differs):
+
+```
+git worktree add -b fix/<slug> .worktrees/fix-<slug> main
+```
+
+where `<slug>` is the feature slug (or a short fix-specific slug if you are
+fixing several defects in one feature). Work inside it; open the PR from it.
+
+### 2. Capture the symptom
+
+Pin the symptom in the user's words: the error text *verbatim*, the wrong
+output, the failing case. Quote it; do not paraphrase. Note the conditions —
+environment, data, version, steps.
+
+### 3. Investigate
+
+Reproduce, then find the root cause. One hypothesis at a time.
+
+- **Reproduce** by the smallest path you can. If you cannot make it happen on
+  demand, say so and gather more — an unreproducible defect is not ready to fix.
+- **Diagnose**: state a single hypothesis in one sentence, confirm or kill it by
+  *reading the code* and adding observation (a log, a probe), not by editing a
+  fix and watching the symptom move. When a hypothesis is wrong, record what you
+  learned and form the next.
+- **Confront against the feature.** Check the behavior against `spec.md` and
+  `design.md`. A deviation from the original design is itself a strong lead — and
+  if the spec is what's wrong, that is a finding, not a code fix.
+
+You have the root cause when you can trace the full chain from trigger to symptom
+and point at the line that is wrong and say why. Investigate openly with the
+user — share what you find as you find it.
+
+### 4. Report and propose (the gate)
+
+Stop and bring it back to the user. Present:
+
+- **The issue** — the root cause in plain language: what is actually wrong and
+  why it produces the symptom. Not the symptom restated.
+- **A few solutions** — typically two or three. For each: what it changes, the
+  trade-off, and the blast radius. Be honest about a quick patch vs. a deeper fix
+  that removes the cause for good. Recommend one and say why.
+
+Debug it together. Fold in pushback and re-propose. Do not move on until the user
+has chosen a solution. If this turns out to be a missing feature or a design
+change, stop and route it to `sf-feature` — that is not a fix.
+
+### 5. Track
+
+Only *after* the user has chosen, record the tracked artifact:
+
+```
+scifi fix create "<description>" --feature <slug> --json
+```
+
+Read the returned `id` (e.g. `FIX-0001`) — you need it to resolve the fix later.
+Creating it here, after agreement, keeps the recorded description accurate to the
+fix you are about to build.
+
+### 6. Fix, test-first under review
+
+Implement the chosen solution — and only that solution.
+
+- **Hold `sf-tdd`.** The defect becomes its first failing test: write a test that
+  reproduces it through the public interface at the smallest scope that captures
+  it, watch it fail for the *right* reason (the root cause from step 3), then make
+  it pass with the minimal change at the cause. Keep the full suite green.
+- **Review gate.** Dispatch a code-review subagent with `DISPATCH-CODE-REVIEW.md`
+  (ships beside this skill) — a fix-mode review: you pass the **change brief**
+  (the root cause and the agreed solution) and the owning feature path, not a
+  task file. Act on its report under `sf-receiving-review` with **review type:
+  code**. Re-review until the verdict is **Pass** or **With fixes**; a **Fail**
+  re-loops. On **With fixes**, address the Minor items (or defer them with the
+  user's ok) before accepting. Do not skip it and do not review your own fix.
+
+### 7. Record and resolve
+
+- Write a **lightweight record** into the fix file body (the file at the `path`
+  from step 5): the root cause in one or two sentences, the chosen solution, and
+  the regression test that now guards it. Keep it short — this is an audit trail,
+  not a spec.
+- Close the artifact:
+
+  ```
+  scifi fix resolve <slug> <id>
+  ```
+
+  This transitions the fix `open → resolved` and unblocks `scifi finish`. Use
+  `scifi fix wont-fix <slug> <id>` only if the agreed outcome was deliberately
+  not to fix — record why in the body first.
+
+## When you are stuck
+
+| Problem | Move |
+| --- | --- |
+| Can't reproduce | Shrink the variables: pin env, data, version one at a time. |
+| Many possible causes | Bisect — halve the suspect surface each step, don't scan it. |
+| Symptom moves when you touch it | You patched downstream of the cause. Go upstream. |
+| Fix contradicts the feature's spec/design | Surface it — the spec may be the thing that's wrong. |
+| User picks a patch over the real fix | Build it — but record the leftover cause as known debt. |
+
+## Done
+
+The fix is done when:
+
+- the target feature is identified and its context read,
+- you can state the root cause in one sentence,
+- the user agreed on the solution you built,
+- a test reproduces the defect, which you watched fail then pass,
+- the code review cleared (**Pass**, or **With fixes** with its Minor items
+  handled) and the full suite is green,
+- the fix file carries the lightweight record and is transitioned to `resolved`
+  (or `wont-fix`).
+
+## Hard rules
+
+- Never start fixing before the user has chosen a solution.
+- Never fix without first identifying and reading the target feature.
+- Never present the symptom as the cause.
+- Never ship a fix with no failing test behind it.
+- Never leave the tracked fix `open`/`in-progress` once the work is settled —
+  resolve it or mark it wont-fix.
+- Never mark a fix resolved before the code review clears (**Pass**, or **With
+  fixes** with its Minor items handled).

package/skills/sf-fix/manifest.ts

@@ -0,0 +1,8 @@
+import type { SkillManifest } from "scifi/skill-types";
+
+export const manifest: SkillManifest = {
+  id: "sf-fix",
+  description:
+    "Fix a defect in an existing feature: diagnose against its spec/design with the user, agree on a solution, then fix it test-first under review and record a tracked fix.",
+  argumentHint: "[feature-slug | description]",
+};

package/skills/sf-handover/body.md

@@ -0,0 +1,67 @@
+# sf-handover
+
+You are the final subagent of one feature's implementation. Every task is built
+and its per-task code review passed. Your job is to verify the *completed*
+feature against its contract and apply a final quality pass, then report back.
+You do not fix anything — you read, you judge, you report. The orchestrator
+(`sf-implement`) routes your findings to a fix subagent and re-dispatches you
+until your verdict is **Pass**.
+
+Your context is clean: build everything you need from the inputs below, not from
+any session history.
+
+## Inputs
+
+The orchestrator gives you:
+
+- `{FEATURE_PATH}` — the feature directory (e.g. `docs/scifi/specs/<slug>`).
+- `{COMMIT_RANGE}` — the full range of the feature's work (e.g. `<base>..HEAD`).
+
+Read as your contract:
+
+- `{FEATURE_PATH}/spec.md` — what the feature must satisfy.
+- `{FEATURE_PATH}/design.md` — the technical design: modules, seams, strategy.
+- `docs/scifi/CONTEXT.md` — the ubiquitous-language glossary.
+- The diff for `{COMMIT_RANGE}` — the whole change, across all tasks.
+
+Optionally, if it exists:
+
+- `docs/scifi/HANDOVER.md` — user-defined finishing actions (smoke tests, PR
+  creation, pointers to process skills). You do **not** run these — the
+  orchestrator does. Read it only so you can list what remains (see Output).
+
+If `{FEATURE_PATH}/spec.md` or `design.md` is missing, stop and say so — you
+cannot verify without the contract.
+
+## Checks (always run)
+
+1. **Spec compliance.** Walk every requirement in `spec.md`. For each, point to
+   where the implementation satisfies it. Flag any requirement that is missing,
+   partial, or contradicted.
+
+2. **Design compliance.** Confirm the change is built along the modules and
+   seams `design.md` describes. Flag drift: responsibilities placed in the wrong
+   unit, seams that leak, a structure that diverges from the agreed design
+   without justification.
+
+3. **Final quality check.** Look across the whole change for what no single task
+   owns: cross-task coherence, integration seams, placeholders presented as
+   finished work, silent failures, and whether the project's required checks are
+   green. Run the suite and build if that is how this repo confirms green.
+
+## HANDOVER.md awareness
+
+If `docs/scifi/HANDOVER.md` exists, list the finishing actions it defines so the
+orchestrator can run them after you pass. Do not execute them yourself — some
+are irreversible or externally visible (PR creation, pushes) and stay at the
+orchestrator's top level.
+
+## Output
+
+Report back exactly:
+
+- **Verdict:** `Pass` or `Fail`.
+- **Findings:** a list, each tied to the check it came from (spec / design /
+  quality). Empty on `Pass`.
+- **Handover actions:** the actions from `HANDOVER.md` the orchestrator should
+  run, in order — or "none" if the file is absent or empty.

package/skills/sf-handover/manifest.ts

@@ -0,0 +1,7 @@
+import type { SkillManifest } from "scifi/skill-types";
+
+export const manifest: SkillManifest = {
+  id: "sf-handover",
+  description:
+    "Final implementation subagent. Verifies the completed feature against spec + design and runs a quality check before handover. Aware of the optional HANDOVER.md finishing actions the orchestrator runs.",
+};

package/skills/sf-implement/DISPATCH-CODE-REVIEW.md

@@ -0,0 +1,19 @@
+# Dispatch template: per-task code review
+
+Dispatch a subagent to review ONE completed task before it is marked done.
+Replace `{FEATURE_PATH}` with the feature directory, `{TASK_SLUG}` with the task,
+and `{COMMIT_RANGE}` with the commit(s) the implementer produced (e.g. a SHA or
+`<base>..HEAD`). The review criteria and output format live in the
+`sf-code-review` skill — do not restate them here.
+
+```
+You are reviewing the implementation of one task. Load and follow the `sf-code-review` skill.
+
+This is a CODE review (not a spec review, not a plan review).
+Task under review: {TASK_SLUG}  (feature: {FEATURE_PATH})
+Changes to review: {COMMIT_RANGE}
+
+Judge the change against {FEATURE_PATH}/design.md and the task's own
+acceptance/validation, with docs/scifi/CONTEXT.md for glossary context. Return
+your report and verdict exactly as the sf-code-review skill defines.
+```

package/skills/sf-implement/DISPATCH-HANDOVER.md

@@ -0,0 +1,19 @@
+# Dispatch template: handover
+
+Dispatch the final subagent once every task is `done`, before `scifi finish`.
+Replace `{FEATURE_PATH}` with the feature directory and `{COMMIT_RANGE}` with the
+full range of the feature's work (e.g. `<branch-base>..HEAD`). The checks and
+output format live in the `sf-handover` skill — do not restate them here.
+
+```
+You are running handover for a complete feature implementation. Load and follow the `sf-handover` skill.
+
+Feature: {FEATURE_PATH}
+Changes to verify: {COMMIT_RANGE}
+
+Verify the whole feature against {FEATURE_PATH}/spec.md and
+{FEATURE_PATH}/design.md, plus docs/scifi/CONTEXT.md, and run the final quality
+check the skill defines. If docs/scifi/HANDOVER.md exists, list its finishing
+actions for the orchestrator to run — do not execute them. Return your verdict,
+findings, and handover actions exactly as the sf-handover skill defines.
+```