@kamilmarzynski/scifi 0.1.1

package/dist/src/core/tasks/list.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"list.js","sourceRoot":"","sources":["../../../../src/core/tasks/list.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,OAAO,EAAE,MAAM,kBAAkB,CAAC;AAC3C,OAAO,EAAE,IAAI,EAAE,MAAM,WAAW,CAAC;AACjC,OAAO,EAAE,YAAY,EAAE,MAAM,kBAAkB,CAAC;AAChD,OAAO,EAAE,uBAAuB,EAAE,MAAM,YAAY,CAAC;AAGrD,SAAS,kBAAkB,CAAC,KAAc;IACxC,OAAO,KAAK,YAAY,KAAK,IAAI,MAAM,IAAI,KAAK,IAAI,KAAK,CAAC,IAAI,KAAK,QAAQ,CAAC;AAC9E,CAAC;AAED,MAAM,CAAC,KAAK,UAAU,SAAS,CAC7B,WAAmB,EACnB,WAAmB;IAEnB,MAAM,QAAQ,GAAG,uBAAuB,CAAC,WAAW,EAAE,WAAW,CAAC,CAAC;IAEnE,MAAM,OAAO,GAAG,MAAM,OAAO,CAAC,QAAQ,EAAE,EAAE,aAAa,EAAE,IAAI,EAAE,CAAC,CAAC,KAAK,CAAC,CAAC,KAAc,EAAE,EAAE;QACxF,IAAI,kBAAkB,CAAC,KAAK,CAAC;YAAE,OAAO,EAAE,CAAC;QACzC,MAAM,KAAK,CAAC;IACd,CAAC,CAAC,CAAC;IAEH,MAAM,SAAS,GAAG,OAAO,CAAC,MAAM,CAAC,CAAC,KAAK,EAAE,EAAE,CAAC,KAAK,CAAC,MAAM,EAAE,IAAI,KAAK,CAAC,IAAI,CAAC,QAAQ,CAAC,KAAK,CAAC,CAAC,CAAC;IAE1F,OAAO,OAAO,CAAC,GAAG,CAChB,SAAS,CAAC,GAAG,CAAC,CAAC,KAAK,EAAE,EAAE,CACtB,YAAY,CAAC,IAAI,CAAC,QAAQ,EAAE,KAAK,CAAC,IAAI,CAAC,CAAC,CAAC,IAAI,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC,IAAI,CAAC,WAAW,CAAC,CAC1E,CACF,CAAC;AACJ,CAAC"}

package/dist/src/core/tasks/paths.d.ts

@@ -0,0 +1,2 @@
+export declare function buildTasksDirectoryPath(projectRoot: string, featureSlug: string): string;
+export declare function buildTaskFilePath(projectRoot: string, featureSlug: string, taskSlug: string): string;

package/dist/src/core/tasks/paths.js

@@ -0,0 +1,11 @@
+import { join } from 'node:path';
+import { assertSafeSlug } from '../slugify.js';
+import { buildFeatureDirectoryPath } from '../specs/paths.js';
+export function buildTasksDirectoryPath(projectRoot, featureSlug) {
+    return join(buildFeatureDirectoryPath(projectRoot, featureSlug), 'tasks');
+}
+export function buildTaskFilePath(projectRoot, featureSlug, taskSlug) {
+    assertSafeSlug(taskSlug, 'task slug');
+    return join(buildTasksDirectoryPath(projectRoot, featureSlug), `${taskSlug}.md`);
+}
+//# sourceMappingURL=paths.js.map

package/dist/src/core/tasks/paths.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"paths.js","sourceRoot":"","sources":["../../../../src/core/tasks/paths.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,IAAI,EAAE,MAAM,WAAW,CAAC;AACjC,OAAO,EAAE,cAAc,EAAE,MAAM,eAAe,CAAC;AAC/C,OAAO,EAAE,yBAAyB,EAAE,MAAM,mBAAmB,CAAC;AAE9D,MAAM,UAAU,uBAAuB,CAAC,WAAmB,EAAE,WAAmB;IAC9E,OAAO,IAAI,CAAC,yBAAyB,CAAC,WAAW,EAAE,WAAW,CAAC,EAAE,OAAO,CAAC,CAAC;AAC5E,CAAC;AAED,MAAM,UAAU,iBAAiB,CAC/B,WAAmB,EACnB,WAAmB,EACnB,QAAgB;IAEhB,cAAc,CAAC,QAAQ,EAAE,WAAW,CAAC,CAAC;IACtC,OAAO,IAAI,CAAC,uBAAuB,CAAC,WAAW,EAAE,WAAW,CAAC,EAAE,GAAG,QAAQ,KAAK,CAAC,CAAC;AACnF,CAAC"}

package/dist/src/core/tasks/transition.d.ts

@@ -0,0 +1,8 @@
+import type { TaskStatus } from './types.js';
+export interface UpdateTaskStatusResult {
+    featureSlug: string;
+    taskSlug: string;
+    previousStatus: TaskStatus;
+    newStatus: TaskStatus;
+}
+export declare function updateTaskStatus(projectRoot: string, featureSlug: string, taskSlug: string, targetStatus: TaskStatus): Promise<UpdateTaskStatusResult>;

package/dist/src/core/tasks/transition.js

@@ -0,0 +1,30 @@
+import { ScifiError } from '../output/errors.js';
+import { readTaskFile, writeTaskFile } from './frontmatter.js';
+import { buildTaskFilePath } from './paths.js';
+function isMissingPathError(error) {
+    return error instanceof Error && 'code' in error && error.code === 'ENOENT';
+}
+export async function updateTaskStatus(projectRoot, featureSlug, taskSlug, targetStatus) {
+    const filePath = buildTaskFilePath(projectRoot, featureSlug, taskSlug);
+    const file = await readTaskFile(filePath).catch((error) => {
+        if (isMissingPathError(error)) {
+            throw new ScifiError('NOT_FOUND', `Task "${taskSlug}" does not exist in feature "${featureSlug}".`, { hint: 'Run `scifi task list <slug>` to see available tasks.' });
+        }
+        throw error;
+    });
+    if (targetStatus === 'done' && file.frontmatter.status !== 'in-progress') {
+        throw new ScifiError('PRECONDITION_FAILED', `Cannot mark task ${taskSlug} as done: task is not in-progress (current status: ${file.frontmatter.status}).`, { hint: 'Start it first with `scifi task start <slug> <task>`.' });
+    }
+    const previousStatus = file.frontmatter.status;
+    await writeTaskFile(filePath, {
+        ...file,
+        frontmatter: { ...file.frontmatter, status: targetStatus },
+    });
+    return {
+        featureSlug,
+        taskSlug,
+        previousStatus,
+        newStatus: targetStatus,
+    };
+}
+//# sourceMappingURL=transition.js.map

package/dist/src/core/tasks/transition.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"transition.js","sourceRoot":"","sources":["../../../../src/core/tasks/transition.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,UAAU,EAAE,MAAM,qBAAqB,CAAC;AACjD,OAAO,EAAE,YAAY,EAAE,aAAa,EAAE,MAAM,kBAAkB,CAAC;AAC/D,OAAO,EAAE,iBAAiB,EAAE,MAAM,YAAY,CAAC;AAU/C,SAAS,kBAAkB,CAAC,KAAc;IACxC,OAAO,KAAK,YAAY,KAAK,IAAI,MAAM,IAAI,KAAK,IAAI,KAAK,CAAC,IAAI,KAAK,QAAQ,CAAC;AAC9E,CAAC;AAED,MAAM,CAAC,KAAK,UAAU,gBAAgB,CACpC,WAAmB,EACnB,WAAmB,EACnB,QAAgB,EAChB,YAAwB;IAExB,MAAM,QAAQ,GAAG,iBAAiB,CAAC,WAAW,EAAE,WAAW,EAAE,QAAQ,CAAC,CAAC;IACvE,MAAM,IAAI,GAAG,MAAM,YAAY,CAAC,QAAQ,CAAC,CAAC,KAAK,CAAC,CAAC,KAAc,EAAS,EAAE;QACxE,IAAI,kBAAkB,CAAC,KAAK,CAAC,EAAE,CAAC;YAC9B,MAAM,IAAI,UAAU,CAClB,WAAW,EACX,SAAS,QAAQ,gCAAgC,WAAW,IAAI,EAChE,EAAE,IAAI,EAAE,sDAAsD,EAAE,CACjE,CAAC;QACJ,CAAC;QACD,MAAM,KAAK,CAAC;IACd,CAAC,CAAC,CAAC;IAEH,IAAI,YAAY,KAAK,MAAM,IAAI,IAAI,CAAC,WAAW,CAAC,MAAM,KAAK,aAAa,EAAE,CAAC;QACzE,MAAM,IAAI,UAAU,CAClB,qBAAqB,EACrB,oBAAoB,QAAQ,sDAAsD,IAAI,CAAC,WAAW,CAAC,MAAM,IAAI,EAC7G,EAAE,IAAI,EAAE,uDAAuD,EAAE,CAClE,CAAC;IACJ,CAAC;IAED,MAAM,cAAc,GAAG,IAAI,CAAC,WAAW,CAAC,MAAM,CAAC;IAE/C,MAAM,aAAa,CAAC,QAAQ,EAAE;QAC5B,GAAG,IAAI;QACP,WAAW,EAAE,EAAE,GAAG,IAAI,CAAC,WAAW,EAAE,MAAM,EAAE,YAAY,EAAE;KAC3D,CAAC,CAAC;IAEH,OAAO;QACL,WAAW;QACX,QAAQ;QACR,cAAc;QACd,SAAS,EAAE,YAAY;KACxB,CAAC;AACJ,CAAC"}

package/dist/src/core/tasks/types.d.ts

@@ -0,0 +1,8 @@
+export declare const TASK_STATUS_VALUES: readonly ["pending", "in-progress", "done"];
+export type TaskStatus = (typeof TASK_STATUS_VALUES)[number];
+export interface TaskFrontmatter {
+    id: string;
+    slug: string;
+    status: TaskStatus;
+    dependsOn: string[];
+}

package/dist/src/core/tasks/types.js

@@ -0,0 +1,2 @@
+export const TASK_STATUS_VALUES = ['pending', 'in-progress', 'done'];
+//# sourceMappingURL=types.js.map

package/dist/src/core/tasks/types.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"types.js","sourceRoot":"","sources":["../../../../src/core/tasks/types.ts"],"names":[],"mappings":"AAAA,MAAM,CAAC,MAAM,kBAAkB,GAAG,CAAC,SAAS,EAAE,aAAa,EAAE,MAAM,CAAU,CAAC"}

package/package.json

@@ -0,0 +1,67 @@
+{
+  "name": "@kamilmarzynski/scifi",
+  "version": "0.1.1",
+  "description": "Specification-driven CLI scaffolding for agentic workflows",
+  "type": "module",
+  "bin": {
+    "scifi": "./dist/src/cli/index.js"
+  },
+  "exports": {
+    ".": "./dist/src/cli/index.js",
+    "./skill-types": {
+      "types": "./dist/src/core/skills/types.d.ts",
+      "default": "./dist/src/core/skills/types.js"
+    }
+  },
+  "files": [
+    "dist",
+    "skills"
+  ],
+  "scripts": {
+    "build": "tsc -p tsconfig.json && node -e \"const fs=require('node:fs'); const path='dist/src/cli/index.js'; const shebang='#!/usr/bin/env node\\n'; const contents=fs.readFileSync(path, 'utf8'); if (!contents.startsWith(shebang)) { fs.writeFileSync(path, shebang + contents); } fs.chmodSync(path, 0o755);\"",
+    "prepack": "npm run build && node -e \"require('node:fs').accessSync('dist/src/cli/index.js')\"",
+    "typecheck": "tsc --noEmit -p tsconfig.json",
+    "test": "vitest run",
+    "test:watch": "vitest",
+    "coverage": "vitest run --coverage",
+    "lint": "biome lint .",
+    "lint:fix": "biome lint --write .",
+    "format": "biome format --write .",
+    "check": "biome check .",
+    "check:fix": "biome check --write ."
+  },
+  "keywords": [
+    "cli",
+    "scaffolding",
+    "specification",
+    "typescript"
+  ],
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/KamilMarzynski/sci-fi.git"
+  },
+  "bugs": {
+    "url": "https://github.com/KamilMarzynski/sci-fi/issues"
+  },
+  "homepage": "https://github.com/KamilMarzynski/sci-fi",
+  "engines": {
+    "node": ">=22.0.0"
+  },
+  "license": "MIT",
+  "publishConfig": {
+    "access": "public",
+    "provenance": true
+  },
+  "dependencies": {
+    "commander": "^15.0.0",
+    "yaml": "^2.9.0",
+    "zod": "^4.4.3"
+  },
+  "devDependencies": {
+    "@biomejs/biome": "2.4.16",
+    "@types/node": "^24.0.0",
+    "@vitest/coverage-v8": "^4.0.0",
+    "typescript": "^5.9.0",
+    "vitest": "^4.0.0"
+  }
+}

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

@@ -0,0 +1,22 @@
+# Dispatch template: bug-fix code review
+
+Dispatch a subagent to review the bug fix before it is accepted. Replace
+`{COMMIT_RANGE}` with the commit(s) the fix produced (a SHA or `<base>..HEAD`)
+and `{CHANGE_BRIEF}` with the root cause and the solution the user agreed to, in
+a sentence or two. There is no feature directory and no task file — this is a
+**fix-mode** review. The criteria and output format live in the `sf-code-review`
+skill — do not restate them here.
+
+```
+You are reviewing a bug fix. Load and follow the `sf-code-review` skill.
+
+This is a CODE review in FIX MODE (no task file, no feature directory).
+Changes to review: {COMMIT_RANGE}
+Agreed change (the contract): {CHANGE_BRIEF}
+
+Judge the change against that brief: it implements the agreed solution and only
+that, a regression test reproduces the bug and now guards it, and no
+non-negotiable is triggered. 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-bug/body.md

@@ -0,0 +1,117 @@
+# sf-bug
+
+You run down ONE bug with the user and drive it to a fix. The session has two
+halves: first you investigate *together* until the cause is understood and a fix
+is chosen, then you implement that fix test-first under review. This skill is
+rigid about the seam between them — you do not start fixing until the user has
+agreed on which solution to build.
+
+There is no spec and no tracked artifact for a bug. A bug is not a feature: its
+solution emerges from diagnosis, not design. Keep the work in code and tests,
+not in documents.
+
+## The Iron Law
+
+```
+INVESTIGATE → REPORT → AGREE → FIX. NEVER FIX BEFORE THE USER AGREES.
+```
+
+The user reported a bug, not a fix. Your job in the first half is to understand
+it well enough to lay out real options; the choice between them is theirs.
+
+## Flow
+
+### 1. Capture the report
+
+- 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 they hit it under — environment, data, version, steps.
+
+Before investigating, create an isolated workspace from the default branch
+(shown as `main` below — substitute your repo's default branch if it differs):
+
+```
+git worktree add -b fix/<slug> .worktrees/fix-<slug> main
+```
+
+Derive `<slug>` from the bug (e.g. `stale-token-refresh`). Work inside it; open
+the PR from it. A bug is untracked, so there is no `scifi` pointer to record.
+
+### 2. 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 from the user — an unreproducible bug is not
+  ready to fix.
+- **Diagnose**: state a single hypothesis about the cause 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.
+- 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. This is a
+debugging session, not a silent report you deliver at the end.
+
+### 3. 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.
+
+Then debug it together. The user may push back, add context, or reframe the
+problem — fold that in and re-propose. Do not move on until the user has chosen
+a solution. If diagnosis turns up that this is really a missing feature or a
+design decision, say so and stop — that belongs in `sf-feature`, not here.
+
+### 4. Fix, test-first under review
+
+Once the user has chosen, implement that solution — and only that solution.
+
+- **Hold `sf-tdd`.** The bug 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 2), 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), 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.
+
+The regression test is the point: it proves the bug existed and guards its
+return.
+
+## 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. |
+| User picks a patch over the real fix | Build it — but record the leftover cause as known debt. |
+
+## Done
+
+The bug is done when:
+
+- you can state the root cause in one sentence,
+- the user agreed on the solution you built,
+- a test reproduces the bug, 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.
+
+## Hard rules
+
+- Never start fixing before the user has chosen a solution.
+- Never present the symptom as the cause.
+- Never ship a fix with no failing test behind it.
+- Never catch or silence the error in place of removing its cause.
+- Never mark done before the code review clears (**Pass**, or **With fixes** with
+  its Minor items handled).

package/skills/sf-bug/manifest.ts

@@ -0,0 +1,8 @@
+import type { SkillManifest } from "scifi/skill-types";
+
+export const manifest: SkillManifest = {
+  id: "sf-bug",
+  description:
+    "Investigate one bug with the user, agree on a solution, then fix it test-first under review. No spec or tracked artifact.",
+  argumentHint: "[description]",
+};

package/skills/sf-change/body.md

@@ -0,0 +1,178 @@
+# sf-change
+
+The scope of ONE existing feature has changed. Your job is to absorb that
+change cleanly: figure out where the feature currently sits, work out how deep
+the change cuts, update the affected artifacts under the same grilling and
+review gates that produced them, and reset the feature's lifecycle status so it
+never sits *ahead* of the artifacts that back it.
+
+You do not re-invent the pipeline. `sf-feature`, `sf-plan`, and `sf-implement`
+already own spec creation, planning, and implementation — each with its own
+grill and its own review gate. Your job is to decide **how far back the change
+rolls the feature**, reset the status to that point, and re-enter the pipeline
+there so the right gate runs again. A change that touches the *what* is not the
+same as one that touches the *how*; getting that judgement right is the work.
+
+## The Iron Law
+
+```
+IDENTIFY → ASSESS STATE → SCOPE THE CHANGE → DECIDE BLAST RADIUS →
+RESET STATUS → RE-ENTER THE PIPELINE.
+NEVER LET STATUS RUN AHEAD OF THE ARTIFACTS.
+```
+
+## Flow
+
+### 1. Identify the feature
+
+The change must attach to one feature. Resolve it before anything else.
+
+- `/sf-change <slug>` — treat the argument as an exact feature slug.
+- `/sf-change <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 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's workspace, then confirm it exists.** Run
+  `git worktree list`; if `.worktrees/feat-<slug>` (branch `feat/<slug>`) exists,
+  enter it and confirm with `scifi status <slug>` from there. 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: for
+  genuinely new work point the user at `sf-feature`; for a defect rather than a
+  scope change, `sf-fix`. A `NOT_FOUND` while a worktree exists just means you
+  are in the wrong checkout, not that the feature is gone.
+
+### 2. Assess current state
+
+Read where the feature is before touching anything:
+
+```
+scifi status <slug> --json
+```
+
+Read `status`, the `artifacts` inventory (`artifacts.spec`, `artifacts.design`,
+`artifacts.taskCount`), the per-task statuses in `tasks[]`, and `fixes[]` (each
+carries its own `status`, so filter for the open ones). Then read the artifacts
+themselves —
+`<path>/spec.md`, `<path>/design.md`, the task files under `<path>/tasks/` — and
+grep `docs/scifi/adr/` for decisions touching the area. `<path>` is
+`docs/scifi/specs/<slug>/`. You cannot scope a change without knowing the
+current contract.
+
+Enter the feature's worktree (the `worktree` field, fallback
+`.worktrees/feat-<slug>`) before editing any artifact. If the feature was `done`
+and its worktree was cleaned up, recreate one off the default branch
+(`git worktree add -b feat/<slug> .worktrees/feat-<slug> main`, substituting your
+default branch for `main` if it differs) and re-record it
+with `scifi worktree set <slug> --branch feat/<slug> --path
+.worktrees/feat-<slug>`.
+
+### 3. Scope the change (grill it)
+
+Interrogate the change the same way `sf-feature` interrogates a new idea — one
+question at a time, concrete either/or where possible. Drive toward:
+
+- **What actually changes** — a requirement, an acceptance criterion, something
+  moving in or out of scope, or only an internal mechanism.
+- **Why now**, and what the change must *not* break.
+- **Confront it against the existing artifacts.** Does it contradict the spec's
+  stated scope? A recorded ADR? The agreed design? Surface the conflict; do not
+  paper over it.
+
+You are ready to act when you can state, in one sentence, exactly what changes
+and which artifact owns it.
+
+### 4. Decide the blast radius
+
+Classify the change by the deepest artifact it invalidates. This decides how far
+back the feature rolls.
+
+| The change touches… | Deepest artifact | Roll back to | Re-enter via |
+| --- | --- | --- | --- |
+| The **what** — a requirement, acceptance criterion, in/out-of-scope line | `spec.md` | `spec-ready` | `sf-feature`'s grill + `sf-spec-review`, then `sf-plan`, then `sf-implement` |
+| The **how** — module shape, seams, task breakdown; spec still holds | `design.md` / tasks | `plan-ready` | `sf-plan`'s grill + `sf-plan-review`, then `sf-implement` |
+| A single in-flight task, within the current design | one task file | stay | `sf-implement` (or finish the task in place) |
+
+When in doubt, roll back further, not less. A spec change that you treat as a
+mere task tweak leaves the design and code quietly contradicting the contract —
+exactly the failure this skill exists to prevent.
+
+### 5. Reset the status
+
+Lower the lifecycle status to the rollback point from step 4, using the CLI
+levers — never by hand-editing metadata:
+
+- **Spec-level** → edit `spec.md` first (or re-enter `sf-feature`'s grill for
+  the affected sections), then `scifi spec-ready <slug>`. This re-anchors the
+  feature at the spec stage; design, tasks, and code are now downstream of a
+  changed contract and must be brought back in line.
+- **Design-level** → update `design.md` and the task files, then
+  `scifi plan-ready <slug>`.
+- **Task-level** → no status change. `in-progress` stays `in-progress`.
+
+Note the one-way gate: `in-progress` is only reachable *from* `plan-ready` via
+`scifi start <slug>`. So a feature you rolled back to `spec-ready` climbs back
+the normal way — `spec-ready → plan-ready → in-progress` — as each gate passes.
+You do not get to jump straight back to where it was.
+
+**If the feature was `done`,** a spec- or design-level change reopens it: reset
+the status as above and the feature re-enters the pipeline. Do not leave a `done`
+feature whose contract has changed.
+
+### 6. Re-enter the pipeline
+
+Hand control to the owning skill for the rollback point — that is where the
+grill and the review gate live:
+
+- Rolled to `spec-ready` → run `sf-feature` to settle the changed spec under
+  `sf-spec-review`, then `sf-plan`, then `sf-implement`. Each gate re-runs.
+  `sf-feature` reopens the *existing* container in this case — it skips its
+  `scifi spec` create step, so you keep working against the original feature
+  rather than scaffolding a new one.
+- Rolled to `plan-ready` → run `sf-plan` to settle the changed design and tasks
+  under `sf-plan-review`, then `sf-implement`.
+- Stayed `in-progress` → run `sf-implement`; it resumes from the next runnable
+  task and picks up the added or removed task files.
+
+Adding or removing a task means adding or deleting a file under `<path>/tasks/`
+(`sf-plan` owns the task template and the decomposition rules — re-enter it
+rather than hand-rolling task files for anything beyond a trivial edit). The CLI
+tracks task *status* (`scifi task start|done`), not task creation.
+
+**Re-open the tasks the change invalidated.** A design change usually rewrites
+tasks that are already `done`, and `sf-implement` *skips* `done` tasks on resume
+— so a changed-but-done task would never be rebuilt. For each existing task the
+change invalidates, run `scifi task start <slug> <task>` to flip it back to
+`in-progress` before re-entering `sf-implement`; it then picks the task up as
+runnable. A brand-new task file already starts `pending`, so it needs no reset.
+
+## When you are stuck
+
+| Problem | Move |
+| --- | --- |
+| Unsure if it's a spec or design change | Ask: does an *acceptance criterion* move? Yes → spec. No → design. |
+| Change contradicts a recorded ADR | Surface it. The decision may need revisiting before the change lands. |
+| Feature is `done` and change is large | Reopen via `spec-ready`; treat it as a near-fresh pass through the pipeline. |
+| Change turns out to be a defect, not new scope | Stop. Route to `sf-fix`. |
+| Change is really a brand-new feature | Stop. Route to `sf-feature`; don't overload this one. |
+
+## Done
+
+The change is absorbed when:
+
+- the target feature is identified and its current state read,
+- the change is scoped to exactly the artifact it invalidates,
+- that artifact is updated under its own grill and review gate,
+- the lifecycle status is reset to match — never ahead of — the artifacts,
+- and the feature has re-entered the pipeline at the rollback point.
+
+## Hard rules
+
+- Never change scope silently — grill it and confront it against the artifacts.
+- Never lower a feature past `spec-ready`/`plan-ready` without re-running that
+  stage's review gate.
+- Never leave the status ahead of the artifacts: a changed spec means the
+  feature is no longer `done`.
+- Never hand-edit lifecycle metadata — use `scifi spec-ready` / `plan-ready`.
+- Never absorb a defect or a new feature here — route to `sf-fix` / `sf-feature`.

package/skills/sf-change/manifest.ts

@@ -0,0 +1,8 @@
+import type { SkillManifest } from "scifi/skill-types";
+
+export const manifest: SkillManifest = {
+  id: "sf-change",
+  description:
+    "Absorb a scope change to an existing feature: scope it against spec/design, reset lifecycle status to the deepest artifact it invalidates, and re-enter the pipeline so the right review gate runs again.",
+  argumentHint: "[feature-slug | description]",
+};

package/skills/sf-code-review/body.md

@@ -0,0 +1,155 @@
+# sf-code-review
+
+You are a critic. You were dispatched to review ONE change before it is accepted
+— a planned feature task, or a defect fix. You do not write the code and you do
+not fix it. You read, you judge, you report back to the agent that dispatched
+you.
+
+You review by reading only. You do not run the suite or the build — the final
+`sf-handover` subagent owns that. Trust the diff and the files in front of
+you.
+
+## Inputs
+
+You review in one of two modes; the dispatcher tells you which by what it hands
+you.
+
+**Task mode** — dispatched by `sf-implement` to gate one task of a planned
+feature. You get:
+
+- `{COMMIT_RANGE}` — the commit(s) the implementer produced (a SHA, or
+  `<base>..HEAD`).
+- `{FEATURE_PATH}` — the feature directory (e.g. `docs/scifi/specs/<slug>`).
+- `{TASK_SLUG}` — which task under that feature this change implements.
+
+**Fix mode** — dispatched by `sf-bug` or `sf-fix` to gate a defect fix. There is
+no task file, and for an untracked bug no feature directory either. You get:
+
+- `{COMMIT_RANGE}` — the commit(s) the fix produced.
+- `{CHANGE_BRIEF}` — the root cause and the solution the user agreed to, in a
+  sentence or two. This is the contract the change must match.
+- `{FEATURE_PATH}` *(sf-fix only)* — the owning feature directory, so you can
+  judge the fix against its `spec.md` / `design.md` as original intent.
+
+In either mode, if `{COMMIT_RANGE}` is empty you cannot see the change — say so
+and stop. In task mode, if `{FEATURE_PATH}/design.md` is missing you have no
+contract to judge against — say so and stop. In fix mode there is no design
+contract; the `{CHANGE_BRIEF}` is the contract.
+
+## What to read
+
+- The diff — `git show {COMMIT_RANGE}` or `git diff {COMMIT_RANGE}`. Then read
+  the touched files in full where the diff alone hides context.
+- **Task mode:** `{FEATURE_PATH}/design.md` (the technical contract) and the task
+  file under `{FEATURE_PATH}/tasks/` for `{TASK_SLUG}` — its **Tests first**,
+  **Acceptance**, and **Validation** sections.
+- **Fix mode:** the `{CHANGE_BRIEF}`. For `sf-fix`, also `{FEATURE_PATH}/spec.md`
+  and `design.md` — the original intent the fix must restore, not contradict.
+- `docs/scifi/CONTEXT.md` — the project's ubiquitous language (canonical
+  glossary of domain terms), if it exists.
+
+Read everything that applies to your mode before judging. Never invent project
+facts; if something is unknowable from these files, flag it as a question
+instead of assuming.
+
+## What to check
+
+Go through the diff against this checklist. No fixed priority order — weigh each
+finding by its real impact on the change.
+
+- **Acceptance & design** — the change does what it was dispatched to do, and no
+  more. *Task mode:* it satisfies the task's acceptance criteria and matches
+  `design.md`; an acceptance item with no implementation, or code that
+  contradicts the design, is a defect. *Fix mode:* it implements the agreed
+  solution from `{CHANGE_BRIEF}` and only that — and, for `sf-fix`, does not
+  reintroduce a deviation from the feature's `spec.md` / `design.md`. Behavior
+  outside the dispatched scope is a defect in either mode — flag scope creep.
+- **TDD evidence** — the behavior is covered by a test written first. *Task
+  mode:* every behavior in the task's **Tests first** has a test. *Fix mode:* a
+  regression test reproduces the defect and now guards it. In both, the tests
+  exercise the change through its public interface, not by mocking the module
+  under test, and assert observable behavior, not shape. Production code with no
+  test behind it is a defect (see non-negotiables).
+- **Deep modules** — real behavior behind a narrow interface. Apply the deletion
+  test: would removing a unit *concentrate* complexity (keep it) or just
+  *scatter* it (inline it)? Flag shallow seams — pass-through wrappers, a class
+  that only forwards calls, a "utils" dumping ground, a function extracted solely
+  so a test can reach it.
+- **Seam declaration** — new seams (a new boundary, dependency, or
+  communication pattern). *Task mode:* they must be declared in `design.md`, not
+  introduced silently; judge against the design, not an external architecture
+  doc. *Fix mode:* a fix that quietly cuts a new seam is a smell — flag it; it
+  usually signals the change outgrew a fix and belongs in a feature.
+- **Simplification (code judo)** — is there a reframing that deletes a whole
+  branch, mode, flag, or conditional rather than adding to it? Flag incidental
+  complexity the change preserves when a clearly simpler shape exists. Do not
+  invent hypothetical rewrites — only call a simplification that is concrete and
+  visible.
+- **Spaghetti & types** — new conditionals bolted onto unrelated flows that make
+  surrounding code harder to reason about; unjustified casts, optionality, or
+  loosely-shaped objects that obscure the real invariant. Prefer explicit typed
+  boundaries.
+- **Naming / glossary** — domain terms used in the code or tests that are not in
+  `CONTEXT.md` (ubiquitous language) and were not proposed for it. A
+  naming-consistency check, not structural.
+- **Placeholders** — any `TBD` / `TODO` / stubbed body / empty implementation
+  presented as finished work.
+
+## Non-negotiables
+
+These are not judgment calls. When the diff contains one, assign at least the
+stated severity regardless of how small it looks. Generalize each rule to the
+project's language — e.g. "type escape" is `any`/`unknown`/an unchecked cast in
+TypeScript, an `interface{}` assertion in Go, a `# type: ignore` in Python.
+
+- **Type escape or cast without a justifying comment** → Critical.
+- **Production code with no failing-test origin** (no test exercises it) →
+  Critical.
+- **Silent failure** — a swallowed error, an empty catch, a discarded result, a
+  fallback that hides a broken invariant → Critical.
+- **Changed public behavior with no doc update** in the same change → Important.
+
+## How to report
+
+Open with a header that names what this is, so the receiving agent applies the
+right lens: **`Code review of <subject>`** — the task slug in task mode, or a
+short label for the change in fix mode. Then use this exact shape:
+
+```
+# Code review of <subject>
+
+### Strengths
+- <what the change gets right — be specific; accurate praise earns trust>
+
+### Issues
+
+#### Critical (must fix)
+- Where: <file:line / quoted diff hunk>
+  Problem: <what is wrong>
+  Fix: <concrete change, or the exact question to ask the user>
+
+#### Important (should fix)
+- ...
+
+#### Minor (nice to have)
+- ...
+
+### Verdict: Pass | Fail | With fixes
+<one-line technical reason>
+```
+
+Calibration:
+
+- **Pass** — acceptance (or the agreed fix) met, design matched where one
+  exists, tests cover every behavior (or a regression test guards the defect),
+  modules are deep, new seams declared, no non-negotiable triggered, no
+  placeholders. No Critical or Important issues.
+- **With fixes** — only Minor issues remain; the change is sound enough to land
+  once they are addressed.
+- **Fail** — any Critical or Important issue. An uncovered acceptance item,
+  untested production code, a triggered non-negotiable, an undeclared new seam,
+  or a placeholder is always at least Important.
+
+Be specific — quote the line, name the file. The receiving agent acts on your
+list directly, so vague feedback wastes a round trip. Do not mark nitpicks as
+Critical. Do not edit any file yourself.

package/skills/sf-code-review/manifest.ts

@@ -0,0 +1,7 @@
+import type { SkillManifest } from "scifi/skill-types";
+
+export const manifest: SkillManifest = {
+  id: "sf-code-review",
+  description:
+    "Read-only critic pass on one change: a feature task against design.md + the task's acceptance, or a bug/fix against the agreed solution. Returns a verdict that gates acceptance.",
+};