@harness-engineering/cli 2.6.1 → 2.7.1

package/dist/agents/skills/gemini-cli/naming-craft/SKILL.md

@@ -0,0 +1,244 @@
+# Naming Craft
+
+> LLM-judgment skill that critiques identifier names — variables, functions, types, and files — for clarity, concreteness, weight, and predictive power. First member of the craft-pipeline initiative (sub-project #1 of 10). Uses a curated rubric catalog seeded from Martin / Beck / Karlton. Emits 3-axis findings (tier × impact × confidence per ADR 0019).
+
+## When to Use
+
+- During PR review on code that adds or renames identifiers
+- When onboarding a new contributor (audit names they introduced)
+- When refactoring a module (verify renamed names earn their letters)
+- As the cross-cutting naming critic for other craft skills (docs-craft, test-craft, code-craft will call into this)
+- NOT for code-convention enforcement (use ESLint rules — this is ceiling, those are floor)
+- NOT for autofix / rename codemod (this is judgment-only; the v2 sibling `align-naming` ships the fix path)
+- NOT for module / branch / commit-subject naming (v1.x — different infrastructure)
+- NOT for languages beyond TS/JS in v1 (Python/Go/Rust idiom catalogs are v1.x)
+
+## Process
+
+### Phase 1: EXTRACT — Identifier walk
+
+1. **Read project configuration.** Check `harness.config.json` for:
+   - `craft.naming.enabled` — gate (default `true`)
+   - `craft.naming.maxFiles` — file count cap (default 100)
+   - `craft.naming.maxIdentifiersPerFile` — per-file sampling cap (default 15)
+
+2. **Walk project files** (.ts / .tsx / .js / .jsx). Skip `node_modules`, `dist`, `build`, `coverage`, dotdirs.
+
+3. **Extract identifiers per file** via TS Compiler API:
+   - **variable** — `const x =`, `let x =`, destructuring binders
+   - **function** — `function x()`, `const x = () =>`, class methods, arrow functions assigned to a name
+   - **type** — `type X`, `interface X`, `class X`
+   - For each: capture file, line, exported status, scope size (`short` = body ≤10 lines; `long` = otherwise), and ±2 context lines for LLM prompt construction.
+
+### Phase 2: SAMPLE — Convention inference
+
+For each identifier kind, sample up to N=500 identifiers across the project and infer the dominant convention via majority-rule:
+
+- **variables / functions** — camelCase / snake_case / PascalCase
+- **types** — PascalCase / camelCase
+- **files** — kebab-case / camelCase / PascalCase (basenames sans extension)
+
+`>50%` majority threshold per kind. Below threshold → `null` (no dominant convention) and the convention-conformance rubric silently skips.
+
+### Phase 3: CRITIQUE — Per-rubric LLM loop
+
+For each file:
+
+1. **Sample identifiers** weighted by importance:
+   - Exported identifiers first
+   - Then long-scope (file-level, methods on long classes)
+   - Then short-scope random fill
+   - Cap at `maxIdentifiersPerFile` per file (default 15).
+
+2. **For each (identifier, rubric)** in the cross-product:
+   - Build a prompt with rubric description + identifier + context lines + project convention.
+   - LLM returns fenced JSON: either `null` (rubric doesn't apply / name is fine) or `{ tier, impact, confidence, message }`.
+   - On non-null: emit a `NamingFinding` with `cite.rubricId` populated for ADR 0020 traceability.
+
+3. **v1 rubric catalog (6 seed rubrics):**
+   - `NAME-R001` **predictive power** (Martin) — does the name predict the contract?
+   - `NAME-R002` **concreteness** (Martin / Beck) — concrete > vague
+   - `NAME-R003` **verb/noun honesty** (Beck) — verb for functions; noun for types; questions for booleans
+   - `NAME-R004` **convention conformance** (Karlton) — matches project convention
+   - `NAME-R005` **scope match** (Beck) — length proportional to scope
+   - `NAME-R006` **encoded measure** (Pragmatic Programmer) — silent units cause real bugs
+
+### Phase 4: REPORT — Aggregate + cost telemetry
+
+Emit `NamingCraftOutput`:
+
+```ts
+{
+  findings: NamingFinding[];
+  summary: {
+    phaseRun: ['critique'];
+    durationMs: number;
+    llmCalls: { provider, model, count, costUsd };
+    catalog: { rubricsApplied: string[] };
+    convention: { variables, functions, types, files };
+    runId: string;
+  }
+}
+```
+
+## Harness Integration
+
+- **`harness naming-craft`** — CLI entry. `--files <glob>` / `--kinds <variable|function|type|file>` / `--max-files <n>` / `--max-identifiers-per-file <n>` / `--json` / `--verbose`.
+- **`mcp__harness__naming_craft`** — MCP tool. Two modes (see "In-session flow" below).
+- **`mcp__harness__naming_craft_finalize`** — MCP tool that completes the in-session flow.
+- **Cross-cutting API:** `critiqueNamesInFile(file, opts)` exported from `packages/cli/src/naming-craft/index.ts`. Future craft skills (docs-craft, test-craft, code-craft) import and invoke this when they want naming critique on a file they're already processing — no project re-walk needed.
+- **LLM provider:** configured in `harness.config.json`. The shared selector in `packages/cli/src/shared/craft/llm/provider.ts` reads two blocks:
+  - **`agent.backends`** — named backend definitions, shared with the orchestrator. Supported types: `claude`, `anthropic`, `openai`, `local`, `pi`, `mock`. (`local` and `pi` are OpenAI-compatible — point them at Ollama / LM Studio / vLLM / LiteLLM / any compliant server.)
+  - **`craft.llm`** — either `{ "backend": "<name>" }` to route through one of the entries above, or `{ "mode": "in-session" | "mock" }` for the non-backend modes. Default when nothing is set: `in-session` (host chat answers prompts via the two-step MCP flow).
+  - **`HARNESS_CRAFT_LLM`** env var overrides the file. Accepts `in-session`, `mock`, or the name of any entry in `agent.backends`.
+
+### Migration from `harness.orchestrator.md`
+
+If you already declared `agent.backends` in `harness.orchestrator.md`, the craft selector reads from it as a fallback and emits a one-time warning on first run. Run `harness migrate backends` (preview with `--dry-run`) to copy the entries into `harness.config.json` so both files share a single source of truth.
+
+### Example
+
+Example config snippet for routing craft skills to a local Ollama:
+
+```jsonc
+{
+  "agent": {
+    "backends": {
+      "ollama": {
+        "type": "local",
+        "endpoint": "http://localhost:11434/v1",
+        "model": ["deepseek-coder-v2", "qwen3:8b"],
+      },
+    },
+  },
+  "craft": { "llm": { "backend": "ollama" } },
+}
+```
+
+## In-session flow (default)
+
+When `HARNESS_CRAFT_LLM` is unset (or set to `in-session`), the MCP tool does **not** call any LLM. Instead it returns a list of prompts for the calling agent to answer with its own model. This is a two-step protocol:
+
+**Step 1 — `mcp__harness__naming_craft({ path, ... })`** returns:
+
+```json
+{
+  "status": "collected",
+  "runId": "<uuid>",
+  "pendingPrompts": [
+    { "promptId": "p1", "systemPrompt": "...", "userPrompt": "..." },
+    ...
+  ],
+  "projection": { "promptCount": N, "budget": 100 }
+}
+```
+
+If `projection.promptCount > budget`, `status` is `"budget-exceeded"` and `pendingPrompts` is empty — re-invoke with smaller `maxFiles` / `maxIdentifiersPerFile`, or pass `promptBudget` to raise the ceiling.
+
+**Step 2** — for each pending prompt, generate the fenced-JSON response as if you were a senior engineer applying the rubric to the identifier. The required response shape (per prompt) is:
+
+````
+```json
+null
+```
+````
+
+if the rubric does not apply or the name is fine, OR:
+
+````
+```json
+{
+  "tier": "foundational|polish|aspirational",
+  "impact": "small|medium|large",
+  "confidence": "high|medium|low",
+  "message": "<critique with suggested rename when possible>"
+}
+```
+````
+
+**Step 3 — `mcp__harness__naming_craft_finalize({ path, runId, responses: [{ promptId, raw }, ...] })`** parses the responses, applies the same validation the inline path uses, and returns the standard `NamingCraftOutput`.
+
+If you want the inline behavior (skill calls an LLM directly), pass `mode: 'inline'` to step 1 and set `HARNESS_CRAFT_LLM` to a non-`in-session` provider.
+
+## Success Criteria
+
+See `docs/changes/craft-pipeline/naming-craft/proposal.md` for the full 34 success criteria. Highlights:
+
+- 6 seed rubrics ship in `catalog/rubrics/<id>.ts` (file-per-rubric matches design-craft pattern)
+- 3-axis output preserved (tier × impact × confidence, never collapsed) per ADR 0019
+- `cite.rubricId` populated on every finding per ADR 0020
+- Convention sampler returns `null` when no dominant convention (>50% threshold)
+- Cross-cutting `critiqueNamesInFile` API exported for future craft skills
+- LlmProvider / MockLlmProvider IMPORTED from design-craft (no duplication)
+- MCP tool count bumps (running total maintained by parallel PRs)
+
+## Examples
+
+### Example: Vague function name
+
+**Input:** `src/orders/processor.ts`:
+
+```ts
+export function processData(orders: Order[]) { ... }
+```
+
+**Output (mock LLM):**
+
+```
+NAME-R002 [polish/medium/low] function processData:14
+  "processData" is a vague verb-pair where the operation and subject
+  are both unstated. Consider `applyDiscountsToOrders` or
+  `convertOrdersToInvoices` depending on the actual transform.
+NAME-R001 [polish/medium/medium] function processData:14
+  The name predicts neither the input shape (orders) nor the operation.
+```
+
+(Real LLM responses vary; mock provider returns deterministic low-confidence findings for test determinism.)
+
+### Example: Silent unit
+
+**Input:**
+
+```ts
+const timeout = 5000;
+```
+
+**Output:**
+
+```
+NAME-R006 [foundational/medium/high] variable timeout:1
+  "timeout" implies a time measure but the unit is silent. Use
+  `timeoutMs` so the call site can't be misread as seconds.
+```
+
+### Example: Mixed-convention project — convention sampler returns null
+
+**Input:** A project with 60% camelCase, 30% snake_case, 10% PascalCase variables. No >50% camelCase majority (60% IS >50%, so convention=camelCase). But with 45/40/15 split: no convention.
+
+**Output:** convention-conformance rubric (NAME-R004) silently skips for the variables kind. Other rubrics still run.
+
+## Gates
+
+- **No autofix.** This is ceiling-judgment. v2's `align-naming` may add safe-rename codemods.
+- **No NAMING.md authoring.** v1 derives convention from sampling.
+- **No language support beyond TS/JS.** v1.x.
+- **No modules / branches / commit subjects.** v1.x (and commit subjects go to copy-craft #5).
+- **No graph persistence.** Phase 1 MVP posture (matches design-craft).
+- **No deep/vision mode.** Naming is text-only.
+
+## Escalation
+
+- **When LLM cost is too high on a large project:** drop `maxIdentifiersPerFile` to 10 or `maxFiles` to 50. Cost = files × identifiers × rubrics × per-call cost.
+- **When a rubric produces high false-positive rate:** v1 has no per-rubric disable; v1.x adds `craft.naming.disabledRubrics: ['NAME-R005']`. Until then: filter findings by `cite.rubricId` in your consumer.
+- **When the convention sampler misidentifies a mid-migration project:** below 50% threshold returns null and convention rubric skips. Better silent skip than wrong findings. Wait until migration completes; until then disable NAME-R004 in v1.x or filter findings.
+- **When you want naming critique for a single file (e.g. in CI on changed files):** use `--files <glob>` or call `critiqueNamesInFile()` via the cross-cutting API.
+- **When you want module / branch / commit-subject naming today:** manual review. v1.x adds these surfaces.
+
+## Status
+
+**v1 — in implementation.** See:
+
+- Spec: `docs/changes/craft-pipeline/naming-craft/proposal.md`
+- Roadmap entry: `craft-pipeline sub-project #1` (the first member)
+- Sibling: `harness-design-craft` (design-pipeline #6 — the LLM-judgment template this follows)
+- Future cross-cutters: docs-craft (#2), test-craft (#3), code-craft (#4) will call into naming-craft's `critiqueNamesInFile()` for their domain-specific naming critique.

package/dist/agents/skills/gemini-cli/naming-craft/skill.yaml

@@ -0,0 +1,51 @@
+name: naming-craft
+version: "0.1.0"
+description: LLM-judgment skill that critiques identifier names (variables, functions, types, files) against a curated rubric catalog seeded from Martin / Beck / Karlton. First craft-pipeline ceiling skill; cross-cutting (other craft skills call into it for domain-specific naming).
+stability: draft
+cognitive_mode: constructive-architect
+triggers:
+  - manual
+  - on_pr
+  - on_new_feature
+platforms:
+  - claude-code
+tools:
+  - Bash
+  - Read
+  - Glob
+  - Grep
+cli:
+  command: harness naming-craft
+  args:
+    - name: path
+      description: Project root path
+      required: false
+    - name: files
+      description: Optional file/glob scope
+      required: false
+    - name: kinds
+      description: Restrict to variable / function / type / file
+      required: false
+mcp:
+  tool: naming_craft
+  input:
+    path: string
+type: rigid
+tier: 2
+phases:
+  - name: extract
+    description: TS Compiler API walk; gather identifiers + scope metadata + context lines
+    required: true
+  - name: sample
+    description: Derive project naming convention via majority-rule sampling
+    required: true
+  - name: critique
+    description: LLM-rubric loop per (identifier, rubric) pair; emit 3-axis findings
+    required: true
+  - name: report
+    description: Aggregate findings + LLM cost + convention summary
+    required: true
+state:
+  persistent: false
+depends_on:
+  - harness-design-craft

package/dist/agents/skills/gemini-cli/security-craft/SKILL.md

@@ -0,0 +1,205 @@
+# Security Craft
+
+> LLM-judgment critique of security posture for TS/JS source — the ceiling counterpart to `harness-security-scan` (CVE/OWASP rule-based floor) and `harness-security-reviewer` (procedural review). Threat-modeling-as-skill rather than pattern-matching. Critiques whether trust boundaries are respected, where implicit privilege escalation lurks, whether the code defends in depth or just at the gate, whether principle of least authority is honored. Sixth non-design member of the craft-pipeline initiative (#10 of 10; the final sub-project). Emits 3-axis findings (tier × impact × confidence per ADR 0019).
+
+## When to Use
+
+- During PR review on a substantively-changed handler / middleware / privileged op
+- After authoring a new endpoint, before exposing it to traffic
+- When onboarding a new contributor (audit security-relevant code they introduced)
+- Periodically (per-sprint or per-release) to catch security-shape drift
+- For threat-modeling shape questions a CVE scanner doesn't address (trust boundaries, fail-closed, authz ordering)
+- NOT for CVE / dependency scanning (use `harness-security-scan` — rule-based floor)
+- NOT for procedural review checklists (use `harness-security-reviewer`)
+- NOT for IaC critique (v1.x — Dockerfile / k8s / Terraform have different rubric vocabulary)
+- NOT for secret detection (floor concern; existing regex/entropy scanners cover this)
+- NOT for autofix / security rewriting (this is judgment-only; v1.x may add `align-security` with aggressive safeguards)
+- NOT for test files (v1 excludes — test security has a different shape; v1.x with dedicated rubrics)
+
+## Process
+
+### Phase 1: DISCOVER — Find source files
+
+1. Walk `packages/*/src/` recursively.
+2. Include `*.{ts,tsx,js,jsx,mjs,cjs}`; exclude test files (`*.test.*`, `*.spec.*`, `tests/`, `__tests__/`).
+3. Exclude generated / build / coverage dirs (`node_modules`, `dist`, `build`, `coverage`, `.next`, `.turbo`, `__snapshots__`).
+4. Honor `--packages` for explicit package scoping; `--files` overrides discovery.
+
+### Phase 2: SIGNAL — AST-driven security construct detection
+
+For each source file, the TS Compiler API walks the AST once and emits `SecuritySignal`s. Files with zero signals are **skipped entirely** — this is the FP-management strategy from the spec (no path-heuristic fallback).
+
+Detected signal kinds:
+
+| Kind              | What it matches                                                                                                                        |
+| ----------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
+| `http-handler`    | `(req, res)` / `(req, res, next)` shapes; `app.get/post/...`; `@Get/@Post/...`                                                         |
+| `middleware`      | `(req, res, next) =>` arrow / `(ctx, next)` shapes                                                                                     |
+| `auth-api`        | `jwt.{sign,verify}`, `bcrypt.{hash,compare}`, `argon2.*`, `passport.*`, `req.session.*`, `res.cookie`                                  |
+| `privileged-op`   | `child_process.{exec,spawn,...}`, `eval`, `new Function`, `vm.runIn*`, `fs.{writeFile,unlink,chmod,...}`                               |
+| `data-egress`     | `fetch`, `axios.*`, `http.request`, `https.request`, `net.connect`                                                                     |
+| `raw-query`       | `*.query(\`...${x}...\`)`, `*.raw(...)`, `$queryRaw`, `$executeRaw` with SQL-shaped argument                                           |
+| `secret-handling` | Secret-named variable (`token`, `password`, `apiKey`, …) flowing into `console.*`, `logger.*`, `JSON.stringify`, template-literal sink |
+
+AST awareness (not regex) avoids common false positives: `exec` in a comment, `eval` as a variable name, `token` in a CSS property name.
+
+### Phase 3: CRITIQUE — Per (file, signal, rubric) loop
+
+8 seed rubrics, each declaring `appliesToSignals` so per-signal pre-filtering minimizes LLM cost:
+
+| Rubric     | Title                                           | Applies to signals                                  |
+| ---------- | ----------------------------------------------- | --------------------------------------------------- |
+| `SEC-R001` | Trust boundary respected                        | http-handler, middleware, raw-query, privileged-op  |
+| `SEC-R002` | Principle of least authority honored            | auth-api, privileged-op, http-handler               |
+| `SEC-R003` | Defense in depth (not gate-only)                | auth-api, http-handler                              |
+| `SEC-R004` | Assumed adversary realistic for the deployment  | http-handler, middleware, auth-api                  |
+| `SEC-R005` | Data flow across trust boundaries is visible    | http-handler, raw-query, data-egress, privileged-op |
+| `SEC-R006` | Fail closed, not open                           | auth-api, middleware, http-handler                  |
+| `SEC-R007` | Secrets carried in a shape that resists leakage | secret-handling                                     |
+| `SEC-R008` | Authorization check happens before the action   | http-handler, privileged-op                         |
+
+For each (signal, rubric) pair where the rubric applies:
+
+1. Build a prompt with rubric description + file path + signal info + **1500-char window AROUND the signal line** (not the whole file — security-critical context is local).
+2. **Conservative-confidence system prompt** biases the LLM toward `medium` confidence by default; `high` requires a specific, named anti-pattern or visible missing guard.
+3. LLM returns fenced JSON: `null` (rubric doesn't apply / code is fine) OR `{ tier, impact, confidence, message }`.
+4. On non-null: emit a `SecurityFinding` with `cite.rubricId` populated for ADR 0020 traceability.
+
+### Phase 4: REPORT — Aggregate + cost telemetry
+
+Emit `SecurityCraftOutput`:
+
+```ts
+{
+  findings: SecurityFinding[];
+  summary: {
+    phaseRun: ['critique'];
+    mode: 'fast';
+    durationMs: number;
+    llmCalls: { provider, model, count, costUsd };
+    catalog: { rubricsApplied: string[] };
+    counts: { filesScanned, filesSkippedNoSignal, signalsDetected };
+    runId: string;
+  }
+}
+```
+
+`filesSkippedNoSignal` is tracked separately so report consumers can see how aggressively the AST pre-filter trimmed the corpus.
+
+## Harness Integration
+
+- **`harness security-craft`** — CLI entry. `--files <glob>` / `--packages <names>` / `--max-files <n>` / `--max-signals-per-file <n>` / `--json` / `--verbose`.
+- **`mcp__harness__security_craft`** — MCP tool. Same input/output. Consumed by agents.
+- **Cross-cutting API:** `critiqueSecurityInFile(file, opts)` exported from `packages/cli/src/security-craft/index.ts`. Returns `[]` for files with no security signals (consistent with the orchestrator's FP-management strategy).
+- **Shared craft infrastructure:** `LlmProvider`, `MockLlmProvider`, `derivePriority`, 3-axis types all live in `packages/cli/src/shared/craft/`.
+
+## Success Criteria
+
+See `docs/changes/craft-pipeline/security-craft/proposal.md` for the full 29 success criteria. Highlights:
+
+- 8 seed rubrics ship at `catalog/rubrics/<id>.ts` (file-per-rubric)
+- AST detector emits signals for all 7 signal kinds; comment / string contents don't fire (AST-aware, not regex)
+- Files with zero signals are skipped (`filesSkippedNoSignal` tracked)
+- Per-rubric `appliesToSignals` pre-filter avoids irrelevant LLM calls
+- 3-axis output preserved; confidence defaults to medium per the spec's Decision #3
+- `cite.rubricId` populated on every finding (ADR 0020)
+- `critiqueSecurityInFile` cross-cutting API works on a single file
+
+## Examples
+
+### Example: User input flowing into child_process
+
+**Input:** `packages/api/src/handlers/run-script.ts`:
+
+```ts
+import { exec } from 'child_process';
+import type { Request, Response } from 'express';
+
+export function runScript(req: Request, res: Response): void {
+  const userScript = req.body.script;
+  exec(`bash -c "${userScript}"`, (err, stdout) => {
+    res.json({ output: stdout });
+  });
+}
+```
+
+**Output (mock LLM):**
+
+```
+SEC-R001 [foundational/large/high] child_process.exec:5
+  User-controlled `req.body.script` flows directly into `bash -c "${userScript}"`.
+  This is a textbook command-injection sink. Either reject the entire pattern
+  (no user-supplied shell strings) or move to `execFile` with an allowlist of
+  binaries and pre-validated arg arrays. Never templated into a shell.
+SEC-R005 [foundational/large/high] child_process.exec:5
+  Untrusted input (`req.body.script`) crosses the trust boundary into a
+  privileged sink without any visible validation or escaping step. The crossing
+  is invisible — the variable is named generically and goes straight to exec.
+```
+
+### Example: Auth check after action
+
+**Input:** `packages/api/src/handlers/get-doc.ts`:
+
+```ts
+export async function getDoc(req: Request, res: Response) {
+  const doc = await db.docs.findOne({ id: req.params.id });
+  if (doc.ownerId !== req.user.id) return res.status(403).send();
+  return res.json(doc);
+}
+```
+
+**Output:**
+
+```
+SEC-R008 [foundational/medium/medium] req,res:1
+  The document is loaded BEFORE the authorization check. Even though the
+  response is denied, the load has already executed — observable side effects
+  (audit logs, rate-limit counters, cache populations) leak existence
+  information about documents the caller can't access. Authorize against the
+  identifier first (`req.params.id` + `req.user.id`), then load.
+```
+
+### Example: File with no security signals
+
+**Input:** A pure utility file with no http/auth/exec/fs/network constructs.
+
+**Output:**
+
+```
+No security findings.
+
+Summary: 0 findings across 0 files (12 skipped, 0 signals, 8 rubrics, 0 LLM calls, $0.0000, 4ms)
+```
+
+The 12 files were scanned for signals but skipped because none had security-relevant AST constructs — exactly the FP-management strategy at work.
+
+## Gates
+
+- **No autofix.** Sibling `align-security` deferred to v2 with aggressive FP safeguards (security rewrites have asymmetric downside).
+- **No IaC critique.** Dockerfile / k8s / Terraform need different rubrics; v1.x.
+- **No multi-file auth-flow tracing.** Cross-file privilege-escalation analysis (handler → middleware → service) needs a graph traversal layer; v1.x once cross-file critique pays for itself elsewhere.
+- **No dependency / CVE scanning.** `harness-security-scan` is the floor.
+- **No secret detection** (floor concern).
+- **No test-file critique.** Test security has a different shape; v1.x.
+- **No path-heuristic fallback.** If AST scan finds zero signals, the file is skipped. Tight scoping is part of the FP-management strategy.
+- **No B' bootstrap.**
+
+## Escalation
+
+- **When LLM cost is too high:** drop `maxFiles` to 50 or `maxSignalsPerFile` to 5, or scope explicitly with `--packages <name>`. Per-file cost = (signals × applicable rubrics × per-call); typical handler fires ~3-5 rubrics, not 8.
+- **When a specific rubric produces false positives:** v1 has no per-rubric disable; v1.x adds `craft.security.disabledRubrics: ['SEC-R004']`. Until then: filter findings by `cite.rubricId` downstream.
+- **When the AST detector misses a framework you use** (tRPC, Convex, Cloudflare Workers, Hono RPC): v1 ships baseline coverage for Express / Hono / Fastify / Koa / NestJS-decorator. Adding a framework is a 1-line config in `signals.ts`. Track as v1.x.
+- **When findings are too cautious (confidence floor):** the conservative-by-default is deliberate (FP management); v1.x adds `craft.security.confidenceFloor` to tighten further. Loosening below medium is intentionally not exposed.
+- **When you want IaC critique:** v1.x. For v1, scope explicitly to source files and accept the gap.
+- **When a finding is wrong:** dismiss it in your consumer; signal as a `suppressedAt` entry on the rubric for future catalog evolution.
+
+## Status
+
+**v1 — in implementation.** See:
+
+- Spec: `docs/changes/craft-pipeline/security-craft/proposal.md`
+- Roadmap entry: `craft-pipeline sub-project #10` (the final sub-project; the craft-pipeline initiative completes with this PR)
+- Sibling craft skills: `naming-craft` (#1), `spec-craft` (#6), `copy-craft` (#5), `test-craft` (#3), `knowledge-craft` (#9), `harness-design-craft` (design-pipeline #6)
+- Shared infrastructure: `packages/cli/src/shared/craft/`
+- Future: `align-security` (FIX side; aggressive safeguards), IaC critique, multi-file auth-flow tracing, test-file security, framework expansions (tRPC / Convex / Cloudflare Workers / Hono RPC).

package/dist/agents/skills/gemini-cli/security-craft/skill.yaml

@@ -0,0 +1,58 @@
+name: security-craft
+version: "0.1.0"
+description: LLM-judgment critique of security posture (TS/JS source). Threat-modeling-as-skill — critiques whether trust boundaries are respected, where implicit privilege escalation lurks, whether the code defends in depth, whether least authority is honored. AST-driven signal detection fires only on files with security-relevant constructs; conservative confidence defaults manage the FP risk inherent in judgment-based security. Sixth non-design craft-pipeline ceiling skill (the final sub-project, #10 of 10).
+stability: draft
+cognitive_mode: constructive-architect
+triggers:
+  - manual
+  - on_pr
+  - on_new_feature
+platforms:
+  - claude-code
+tools:
+  - Bash
+  - Read
+  - Glob
+  - Grep
+cli:
+  command: harness security-craft
+  args:
+    - name: path
+      description: Project root path
+      required: false
+    - name: files
+      description: Optional file scope (overrides discovery)
+      required: false
+    - name: packages
+      description: Restrict to specific packages under packages/
+      required: false
+    - name: max-files
+      description: Cap source-file count (default 100)
+      required: false
+    - name: max-signals-per-file
+      description: Cap per-file signal critique (default 10)
+      required: false
+mcp:
+  tool: security_craft
+  input:
+    path: string
+type: rigid
+tier: 2
+phases:
+  - name: discover
+    description: Walk packages/STAR/src/ recursively; exclude tests + build dirs
+    required: true
+  - name: signal
+    description: AST-driven security construct detection (http handlers, middleware, auth APIs, child_process/eval, fs writes, raw queries, network egress, secret handling)
+    required: true
+  - name: critique
+    description: LLM-rubric loop per (file, signal, rubric) with conservative-confidence bias
+    required: true
+  - name: report
+    description: Aggregate findings + cost telemetry + file/signal counts
+    required: true
+state:
+  persistent: false
+depends_on:
+  - harness-security-scan
+  - harness-security-review