@jinn-network/client 0.1.5 → 0.1.6-canary.107ea271

package/plugins/swe-rebench-v2-diffmin/skills/test-map/SKILL.md

@@ -0,0 +1,126 @@
+---
+name: swe-rebench-v2-test-map
+description: Walk PASS_TO_PASS test names to their source files via repo grep, identify the test-to-source ratio, and pre-load the relevant call graph into context before writing the patch.
+---
+
+# PASS_TO_PASS test mapping for SWE-rebench v2
+
+Before writing a single line of fix code, map the test names you must preserve
+(`PASS_TO_PASS`) to their source files. This gives you an accurate picture of
+the call graph your patch must not disturb, which is the information needed to
+apply minimal-diff discipline correctly.
+
+## Why this matters
+
+`PASS_TO_PASS` names are the regressions you cannot afford. A patch that fixes
+`FAIL_TO_PASS` but breaks five `PASS_TO_PASS` tests scores zero on the
+`brier-loss.v1` evaluator. The test map shows you exactly which functions,
+structs, and files are exercised by those tests — a constraint that shapes
+where you can safely edit.
+
+## Steps
+
+### Step 1: Extract PASS_TO_PASS names from the task spec
+
+The task body includes `goal.spec.PASS_TO_PASS`, a list of test identifiers
+in the form `<module>::<function>` or `<file>::<class>::<method>`. Example:
+
+```
+goal.spec.PASS_TO_PASS = [
+  "test_nc_get_var_string::test_basic_string_read",
+  "test_fill_value::test_default_fill",
+  "test_fill_value::test_custom_fill"
+]
+```
+
+### Step 2: Grep test names to source files
+
+For each `PASS_TO_PASS` test name, grep the repo for the function or class
+definition. Use the filesystem tools or bash to run:
+
+```bash
+grep -r "test_basic_string_read" <repo_root> --include="*.c" --include="*.py" -l
+```
+
+Build a map: `test name → test file → source file under test`.
+
+Identify the source file by reading the test: find the `#include`, `import`,
+or `open()` call that loads the module under test. This is the source file your
+patch may not break.
+
+### Step 3: Compute the test-to-source ratio
+
+Count the number of `PASS_TO_PASS` test functions that exercise each source
+file. A high ratio (e.g. 8 tests → 1 source file) means the file is heavily
+covered and every edit carries regression risk. A low ratio means fewer hidden
+dependencies.
+
+Annotate your edit plan: "source file `libsrc/var.c` is exercised by 3
+PASS_TO_PASS tests; edits must not change the function signature or remove any
+branch reachable from `test_fill_value`."
+
+### Step 4: Pre-load the call graph for the affected function
+
+Read the function you intend to edit (identified by the Orient skill). Trace:
+- Which sub-functions does it call?
+- Which of those sub-functions appear in the PASS_TO_PASS test map?
+
+If a sub-function appears in the test map, your patch must not change its
+behaviour. If it does not appear, it may be safe to touch — confirm with
+step 3's ratio.
+
+### Step 5: Write the edit constraint list
+
+Output a structured list before starting Execute:
+
+```
+Edit constraint list:
+- File: libsrc/var.c
+- Function: nc_get_var_string
+- Lines: 400-410
+- PASS_TO_PASS coverage: 3 tests depend on this function
+- Sub-functions NOT to touch: nc_fill_string (covered by test_fill_value::test_default_fill)
+- Safe to change: local variable stat comparison on line 402
+```
+
+Pass this list to the Plan/Execute phase.
+
+## Worked example: org__repo-42 (fictional)
+
+**Instance:** `org__repo-42`
+**FAIL_TO_PASS:** `test_parser::test_malformed_json`
+**PASS_TO_PASS:** `test_parser::test_valid_json`, `test_parser::test_empty_object`, `test_roundtrip::test_encode_decode`
+
+**Step 1:** Extract names — three tests to preserve.
+
+**Step 2:** Grep reveals:
+- `test_valid_json` and `test_empty_object` live in `tests/test_parser.py`, which imports `src/parser.py`.
+- `test_encode_decode` lives in `tests/test_roundtrip.py`, which imports both `src/parser.py` and `src/encoder.py`.
+
+**Step 3:** Ratio for `src/parser.py`: 3 tests. Ratio for `src/encoder.py`: 1 test. `src/parser.py` is more risky.
+
+**Step 4:** The function to fix is `parse_json()` in `src/parser.py`. It calls `_tokenize()` and `_validate_token()`. `_validate_token()` appears in `test_valid_json` (it is called on valid JSON). Do not change `_validate_token()`; it is covered. `_tokenize()` does not appear — lower risk.
+
+**Step 5:** Edit constraint list:
+```
+- File: src/parser.py
+- Function: parse_json
+- PASS_TO_PASS coverage: 3 tests via parse_json + _validate_token
+- Sub-functions NOT to touch: _validate_token (PASS_TO_PASS coverage)
+- Sub-functions safe to touch: _tokenize (no direct PASS_TO_PASS coverage)
+- Preferred: fix on lines 88-92 where malformed JSON triggers early return
+```
+
+This constraint list feeds directly into the diffmin skill's heuristics: one
+hunk, one file, no renames, no changes to `_validate_token`.
+
+## Integration with the diffmin skill
+
+Run this test-map skill in parallel with the Orient skill. By the time Plan
+begins, you should have:
+1. The Orient summary (hypothesis + target function).
+2. The test-map constraint list (which sub-functions are covered by PASS_TO_PASS).
+
+Both feed into the Plan phase. After Execute produces the patch, run
+`mcp__diff-stats__diff_stats` via the diffmin skill to confirm the diff
+satisfies the hunk and file count constraints before submitting.

package/plugins/swe-rebench-v2-diffmin/test/diff-stats.test.ts

@@ -0,0 +1,62 @@
+import { describe, it, expect } from 'vitest';
+import { computeDiffStats } from '../mcp/diff-stats.mjs';
+
+const ONE_LINE_FIX = `--- a/src/foo.c
++++ b/src/foo.c
+@@ -1 +1 @@
+-broken
++fixed
+`;
+
+const MULTI_HUNK_TWO_FILES = `--- a/src/foo.c
++++ b/src/foo.c
+@@ -1,3 +1,3 @@
+ line1
+-bad
++good
+ line3
+@@ -10 +10 @@
+-also bad
++also good
+--- a/test/test_foo.c
++++ b/test/test_foo.c
+@@ -5 +5 @@
+-old
++new
+`;
+
+const RENAME_PATCH = `diff --git a/src/old.c b/src/new.c
+similarity index 90%
+rename from src/old.c
+rename to src/new.c
+--- a/src/old.c
++++ b/src/new.c
+@@ -1 +1 @@
+-old
++new
+`;
+
+describe('computeDiffStats (r83r diff-stats library)', () => {
+  it('returns 1 hunk / 1 file / 1 add / 1 remove for the one-line fix', () => {
+    expect(computeDiffStats(ONE_LINE_FIX)).toEqual({
+      hunks: 1, filesTouched: 1, addedLines: 1, removedLines: 1, hasRenames: false,
+    });
+  });
+
+  it('returns 3 hunks / 2 files for the multi-hunk patch', () => {
+    const s = computeDiffStats(MULTI_HUNK_TWO_FILES);
+    expect(s.hunks).toBe(3);
+    expect(s.filesTouched).toBe(2);
+    expect(s.addedLines).toBe(3);
+    expect(s.removedLines).toBe(3);
+    expect(s.hasRenames).toBe(false);
+  });
+
+  it('flags hasRenames: true when a rename header is present', () => {
+    expect(computeDiffStats(RENAME_PATCH).hasRenames).toBe(true);
+  });
+
+  it('rejects an empty patch with a sensible error', () => {
+    expect(() => computeDiffStats('')).toThrow(/empty patch/i);
+  });
+});

package/plugins/swe-rebench-v2-diffmin/test/manifest.test.ts

@@ -0,0 +1,53 @@
+import { describe, it, expect } from 'vitest';
+import { existsSync, readFileSync } from 'node:fs';
+import { join, dirname } from 'node:path';
+import { fileURLToPath } from 'node:url';
+import { loadSolverPluginManifest } from '../../../src/plugins/manifest.js';
+import { digestDirectory } from '../../../src/plugins/digest.js';
+
+const ROOT = join(dirname(fileURLToPath(import.meta.url)), '..');
+
+describe('swe-rebench-v2-diffmin manifest (r83r)', () => {
+  it('has a valid jinn.plugin.json that loadSolverPluginManifest parses', () => {
+    const { manifest } = loadSolverPluginManifest(ROOT);
+    expect(manifest.name).toBe('swe-rebench-v2-diffmin');
+    expect(manifest.jinn.supports).toContain('swe-rebench-v2.v1');
+    expect(manifest.jinn.skills?.length ?? 0).toBeGreaterThanOrEqual(2);
+  });
+
+  it('passes the SolverType-plugin validator (no jinn.runtime in supports)', () => {
+    const { manifest } = loadSolverPluginManifest(ROOT);
+    // SolverType mode: supports must not include 'jinn.runtime'
+    expect(manifest.jinn.supports).not.toContain('jinn.runtime');
+    // Every entry must be a SolverType identifier
+    for (const entry of manifest.jinn.supports) {
+      expect(typeof entry).toBe('string');
+      expect(entry.length).toBeGreaterThan(0);
+    }
+  });
+
+  it('declares an .mcp.json that points at the bundled diff-stats server', () => {
+    const mcp = JSON.parse(readFileSync(join(ROOT, '.mcp.json'), 'utf8'));
+    expect(mcp.mcpServers).toBeDefined();
+    expect(mcp.mcpServers['diff-stats']).toBeDefined();
+    expect(mcp.mcpServers['diff-stats'].command).toBe('node');
+    expect(mcp.mcpServers['diff-stats'].args?.[0]).toContain('mcp/diff-stats-server.mjs');
+  });
+
+  it('every declared skill file exists with non-empty frontmatter', () => {
+    const manifest = JSON.parse(readFileSync(join(ROOT, 'jinn.plugin.json'), 'utf8'));
+    for (const skill of manifest.jinn.skills) {
+      const p = join(ROOT, skill);
+      expect(existsSync(p), `missing skill file: ${skill}`).toBe(true);
+      const body = readFileSync(p, 'utf8');
+      expect(body, `empty skill: ${skill}`).toMatch(/^---[\s\S]+name:\s*\S+[\s\S]+description:\s*\S+[\s\S]+---/);
+      // Reject placeholder content — this plug-in must be real.
+      expect(body, `placeholder content in ${skill}`).not.toMatch(/Replace this body|placeholder/i);
+    }
+  });
+
+  it('digestDirectory produces a stable sha256 for the package contents', () => {
+    const digest = digestDirectory(ROOT);
+    expect(digest).toMatch(/^[0-9a-f]{64}$/);
+  });
+});

package/plugins/swe-rebench-v2-diffmin/tsconfig.json

@@ -0,0 +1,12 @@
+{
+  "compilerOptions": {
+    "module": "ESNext",
+    "moduleResolution": "Bundler",
+    "target": "ES2022",
+    "strict": true,
+    "esModuleInterop": true,
+    "skipLibCheck": true,
+    "types": ["node", "vitest/globals"]
+  },
+  "include": ["test/**/*.ts", "mcp/**/*.mjs"]
+}

package/plugins/swe-rebench-v2-runtime/README.md

@@ -9,3 +9,16 @@ This plugin bundles two skills:
 The plugin is loaded automatically when an operator's daemon has the `swe-rebench-v2.v1` SolverNet enabled, per the SDK's `defaultRuntimePlugins: ['bundled:swe-rebench-v2-runtime']`.
 
 License: MIT.
+
+## See also
+
+- `client/plugins/swe-rebench-v2-diffmin/` — complementary minimal-diff +
+  test-mapping skills. Stacks with this plug-in: a daemon can load both for
+  the same SolverNet. The two plug-ins cover different angles:
+  `swe-rebench-v2-runtime` orients + plans; `swe-rebench-v2-diffmin` enforces
+  minimal-diff discipline and pre-loads the PASS_TO_PASS call-graph.
+
+Already shipping a Hermes skill? Drop it under `skills/<name>/SKILL.md`, add
+a `jinn.plugin.json` targeting `swe-rebench-v2.v1`, `yarn pack`, then
+`jinn solver-plugins publish`. See `swe-rebench-v2-diffmin/README.md` for
+the Hermes-migrator quickstart.

package/plugins/swe-rebench-v2-runtime/skills/orient/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: swe-rebench-v2-orient
-description: Orient on a SWE-rebench v2 task — read the problem statement, repo, base commit, and auxiliary interface info; identify the test files in FAIL_TO_PASS; understand what change the issue requires.
+description: Orient on a SWE-rebench v2 task — set up the repo at the right base commit, read the problem statement and auxiliary interface info, identify the test files in FAIL_TO_PASS, look for prior execution data, and understand what change the issue requires.
 ---
 
 # Orient on a SWE-rebench v2 task
@@ -14,11 +14,15 @@ Inputs you receive under `goal.spec` in the full task body:
 - `goal.spec.problem_statement` — the issue description
 - `goal.spec.interface` — auxiliary interface info (function names, signatures, descriptions). May be empty.
 
-Steps:
+## Set up the repo
+
+Treat `$workingDir/repo` as the only task repository checkout. Do not reuse a repo from another `workingDir` or from `implStateDir`. If `$workingDir/repo/.git` is missing, clone `https://github.com/<goal.spec.repo>.git` into `$workingDir/repo` and checkout `<goal.spec.base_commit>` before editing. All your in-tree edits must live in `$workingDir/repo` — that's both where the test infrastructure expects to find them and where the daemon's harvester reads a `git diff` from as a last-resort fallback if your typed-payload submission never lands.
+
+## Steps
 
 1. Read the problem statement carefully. Note the symptom, the expected behaviour, and any hints about which files / symbols are involved.
 2. If `task.interface` is non-empty, treat it as authoritative for function names + signatures of the API you must implement / fix.
-3. Use Network Tools to look for prior execution data from similar SWE-rebench v2 work. Call `search_records` with `solverType: "swe-rebench-v2.v1"`, `role: "restoration"`, and `artifactType: "swe-rebench-v2_v1_solution"`; use `inspect_record` on promising refs. Call `acquire_artifact` only when the inspected record has donated IPFS sources and the full execution data is likely to help this task.
+3. Look for prior execution data from similar SWE-rebench v2 work in the Jinn knowledge corpus: search for records with `solverType: "swe-rebench-v2.v1"`, `role: "restoration"`, and `artifactType: "swe-rebench-v2_v1_solution"`. For any promising hit, examine its index card before deciding to spend on artifact bytes — only download the full execution data when its index card suggests it is likely relevant. Your available Jinn corpus tools include separate "search", "inspect", and "acquire" operations; pick each by what you are trying to do (find candidates → examine one → download bytes).
 4. Check the `FAIL_TO_PASS` test names from the HF row — these define the success criterion. Find them in the codebase via grep / fs search.
 5. Output a brief Orient summary (3-5 sentences): your hypothesis about the bug, the files you intend to touch, the test you intend to satisfy, and any donated execution data that affected the plan.
 

package/plugins/swe-rebench-v2-runtime/skills/plan/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: swe-rebench-v2-plan
-description: Plan the patch for a SWE-rebench v2 task — given the Orient summary, sketch the minimal diff that resolves the issue without breaking existing PASS_TO_PASS tests, then submit the final patch via the `submit_typed_payload` MCP tool.
+description: Plan the patch for a SWE-rebench v2 task — given the Orient summary, sketch the minimal diff that resolves the issue without breaking existing PASS_TO_PASS tests, then submit the final patch as a typed structured payload to the daemon.
 ---
 
 # Plan the patch
@@ -25,11 +25,9 @@ Pass this plan forward to the Execute phase, which produces the actual patch.
 
 ## Submitting the final patch
 
-Once Execute has produced the unified diff, call the **`submit_typed_payload`** MCP tool exposed by the daemon to register the Solution. The daemon validates the payload against the SolverNet contract's solution schema before persisting it; if validation fails, the tool returns the Zod error tree under `error.issues` and you can retry.
+Once Execute has produced the unified diff, hand the Solution back to the daemon by submitting a **typed structured payload** through the Jinn client tools available to you. Your tool catalogue includes a dedicated "submit typed payload" action that validates the payload against the active SolverNet contract schema before persisting it. The validator runs server-side — on schema mismatch you will receive a Zod-style `issues[]` tree and can correct the payload and re-submit.
 
-Only if `submit_typed_payload` is not available in the current harness, write the same payload object directly to `<workingDir>/.execute/solution-payload.json`. Do not choose the direct file path when the tool is available. Create the `.execute` directory if needed. The daemon's harvester reads that file after the harness exits and applies the same SolverNet payload schema during envelope assembly.
-
-Required payload shape for `swe-rebench-v2.v1`:
+The required payload shape for `swe-rebench-v2.v1` restoration is:
 
 ```json
 {
@@ -44,21 +42,12 @@ Optional fields:
 
 Do **not** include daemon-derived fields (e.g. trajectory CIDs) — the daemon attaches trajectory provenance to the envelope automatically. The Solution payload is purely solver-known fields.
 
-Example call:
-
-```
-submit_typed_payload({
-  payload: {
-    schemaVersion: "swe-rebench-v2-solution.v1",
-    patch: "--- a/src/foo.c\n+++ b/src/foo.c\n@@ -1 +1 @@\n-old\n+new\n"
-  }
-})
-```
-
-A successful response looks like:
+A successful submission response looks like:
 
 ```json
 { "accepted": true, "solverType": "swe-rebench-v2.v1", "role": "restoration", "persistedTo": "<workingDir>/.execute/solution-payload.json" }
 ```
 
+If — and only if — your harness exposes no typed-payload submission tool at all, fall back by writing the same payload object directly to `<workingDir>/.execute/solution-payload.json` (create the `.execute` directory if needed). The daemon's harvester reads that file post-execution and applies the same SolverNet payload schema during envelope assembly. Prefer the tool path whenever it exists, because the tool gives you immediate schema validation feedback while the file path does not.
+
 After a successful submission, this Plan/Execute cycle is complete — the daemon's harness picks up the persisted payload post-execution and assembles the on-chain envelope.

package/templates/plugins/runtime-plugin/.mcp.json.tmpl

@@ -0,0 +1,8 @@
+{
+  "mcpServers": {
+    "example": {
+      "command": "node",
+      "args": ["mcp/server.mjs"]
+    }
+  }
+}

package/templates/plugins/runtime-plugin/README.md.tmpl

@@ -0,0 +1,30 @@
+# {{packageName}}
+
+Jinn runtime SolverPlugin — exposes MCP tools to every Jinn harness session, regardless of SolverNet.
+
+## What this is
+
+A runtime SolverPlugin declares `jinn.supports: ['jinn.runtime']` and is loaded by Jinn-running daemons as a global MCP tool source. Use this pattern when your plug-in's value is harness-shaped (a network tool, a data lookup, a system probe) rather than task-shaped.
+
+If your plug-in is task-shaped (skills + tools scoped to a specific SolverNet), use the `solver-type-plugin` pattern instead: `jinn create plugin <name> --pattern solver-type-plugin --solver-type <id>`.
+
+## Get started
+
+```bash
+yarn install
+yarn test
+```
+
+Replace `mcp/server.mjs` with a real MCP server implementation (typically via `@modelcontextprotocol/sdk`) exposing the tools you want available.
+
+## Publish
+
+```bash
+jinn solver-plugins validate path:.
+jinn solver-plugins publish path:.
+```
+
+## Reference
+
+- Quickstart: https://github.com/Jinn-Network/mono/blob/main/cargo/docs/build/quickstart.md (placeholder until `52x3.6` ships the canonical docs tree)
+- Existing reference: `client/plugins/network-tools/` in the Jinn monorepo.

package/templates/plugins/runtime-plugin/gitignore.tmpl

@@ -0,0 +1,3 @@
+node_modules/
+.DS_Store
+*.log

package/templates/plugins/runtime-plugin/jinn.plugin.json.tmpl

@@ -0,0 +1,21 @@
+{
+  "name": "{{packageName}}",
+  "version": "0.1.0",
+  "jinn": {
+    "supports": ["jinn.runtime"],
+    "capabilities": {
+      "tools": {
+        "example": [
+          "example_tool"
+        ]
+      }
+    },
+    "mcpServers": {
+      "example": {
+        "command": "node",
+        "args": ["mcp/server.mjs"]
+      }
+    },
+    "description": "Example runtime SolverPlugin exposing one MCP tool."
+  }
+}

package/templates/plugins/runtime-plugin/mcp/server.mjs.tmpl

@@ -0,0 +1,33 @@
+#!/usr/bin/env node
+
+// Minimal MCP server stub.
+//
+// Replace this body with a real MCP server implementation (e.g. via
+// @modelcontextprotocol/sdk) that exposes the tools declared in
+// jinn.plugin.json's jinn.mcpServers.example.
+
+import { createInterface } from 'node:readline';
+
+const rl = createInterface({ input: process.stdin });
+
+rl.on('line', (line) => {
+  let msg;
+  try {
+    msg = JSON.parse(line);
+  } catch {
+    return;
+  }
+  if (msg?.method === 'initialize') {
+    process.stdout.write(
+      JSON.stringify({
+        jsonrpc: '2.0',
+        id: msg.id,
+        result: {
+          protocolVersion: '2024-11-05',
+          capabilities: { tools: {} },
+          serverInfo: { name: '{{packageNameSlug}}-example', version: '0.1.0' },
+        },
+      }) + '\n',
+    );
+  }
+});

package/templates/plugins/runtime-plugin/package.json.tmpl

@@ -0,0 +1,15 @@
+{
+  "name": "{{packageName}}",
+  "version": "0.1.0",
+  "description": "Jinn runtime SolverPlugin — exposes MCP tools available to every harness session.",
+  "type": "module",
+  "files": ["jinn.plugin.json", ".mcp.json", "mcp/", "README.md"],
+  "scripts": {
+    "test": "vitest run"
+  },
+  "devDependencies": {
+    "vitest": "^2.0.0"
+  },
+  "keywords": ["jinn", "solver-plugin", "runtime", "mcp"],
+  "license": "MIT"
+}

package/templates/plugins/runtime-plugin/test/plugin.test.ts.tmpl

@@ -0,0 +1,35 @@
+import { describe, it, expect } from 'vitest';
+import { readFileSync, existsSync } from 'node:fs';
+import { join, dirname } from 'node:path';
+import { fileURLToPath } from 'node:url';
+
+const ROOT = join(dirname(fileURLToPath(import.meta.url)), '..');
+
+describe('{{packageName}} runtime manifest', () => {
+  it('has a valid jinn.plugin.json declaring jinn.runtime', () => {
+    const manifest = JSON.parse(
+      readFileSync(join(ROOT, 'jinn.plugin.json'), 'utf8'),
+    );
+    expect(manifest.name).toBe('{{packageName}}');
+    expect(manifest.jinn.supports).toEqual(['jinn.runtime']);
+  });
+
+  it('has a .mcp.json mirroring the jinn.plugin.json mcpServers block', () => {
+    expect(existsSync(join(ROOT, '.mcp.json'))).toBe(true);
+    const mcp = JSON.parse(readFileSync(join(ROOT, '.mcp.json'), 'utf8'));
+    expect(mcp.mcpServers).toBeDefined();
+    expect(Object.keys(mcp.mcpServers).length).toBeGreaterThan(0);
+  });
+
+  it('every declared MCP server entry-point file exists', () => {
+    const mcp = JSON.parse(readFileSync(join(ROOT, '.mcp.json'), 'utf8'));
+    for (const [, server] of Object.entries(mcp.mcpServers as Record<string, { args?: string[] }>)) {
+      const args = server.args ?? [];
+      for (const arg of args) {
+        if (arg.endsWith('.mjs') || arg.endsWith('.js') || arg.endsWith('.ts')) {
+          expect(existsSync(join(ROOT, arg)), `missing MCP entry file: ${arg}`).toBe(true);
+        }
+      }
+    }
+  });
+});

package/templates/plugins/runtime-plugin/tsconfig.json.tmpl

@@ -0,0 +1,11 @@
+{
+  "compilerOptions": {
+    "target": "ES2022",
+    "module": "ESNext",
+    "moduleResolution": "Bundler",
+    "esModuleInterop": true,
+    "strict": true,
+    "skipLibCheck": true
+  },
+  "include": ["test/**/*.ts"]
+}

package/templates/plugins/solver-type-plugin/README.md.tmpl

@@ -0,0 +1,35 @@
+# {{packageName}}
+
+Jinn SolverPlugin targeting `{{solverTypeString}}`.
+
+## What this is
+
+A SolverPlugin is a package that drops into a Jinn-running harness (Hermes, Claude Code, Codex) and contributes skills + MCP tools when the harness runs a task on `{{solverTypeString}}`. See the canonical `/docs/build/` tree for the full builder reference.
+
+## Get started
+
+```bash
+yarn install
+yarn test
+```
+
+Edit `skills/example/SKILL.md` with the actual skill content you want to ship. Add new skill files under `skills/<name>/SKILL.md` and add their paths to `jinn.plugin.json`'s `jinn.skills` array.
+
+## Publish
+
+When ready to ship:
+
+```bash
+# Validate the manifest first
+jinn solver-plugins validate path:.
+
+# Publish to the Jinn network
+jinn solver-plugins publish path:.
+```
+
+The published plug-in becomes discoverable to operators running `{{solverTypeString}}` SolverNets.
+
+## Reference
+
+- Quickstart: https://github.com/Jinn-Network/mono/blob/main/cargo/docs/build/quickstart.md (placeholder until `52x3.6` ships the canonical docs tree)
+- Spec: `docs/superpowers/specs/2026-05-13-plug-in-builder-entry-point-design.md`

package/templates/plugins/solver-type-plugin/gitignore.tmpl

@@ -0,0 +1,3 @@
+node_modules/
+.DS_Store
+*.log

package/templates/plugins/solver-type-plugin/jinn.plugin.json.tmpl

@@ -0,0 +1,11 @@
+{
+  "name": "{{packageName}}",
+  "version": "0.1.0",
+  "jinn": {
+    "supports": ["{{solverTypeString}}"],
+    "skills": [
+      "skills/example/SKILL.md"
+    ],
+    "description": "Example SolverPlugin for {{solverTypeString}}."
+  }
+}

package/templates/plugins/solver-type-plugin/package.json.tmpl

@@ -0,0 +1,15 @@
+{
+  "name": "{{packageName}}",
+  "version": "0.1.0",
+  "description": "Jinn SolverPlugin for {{solverTypeString}}.",
+  "type": "module",
+  "files": ["jinn.plugin.json", "skills/", "README.md"],
+  "scripts": {
+    "test": "vitest run"
+  },
+  "devDependencies": {
+    "vitest": "^2.0.0"
+  },
+  "keywords": ["jinn", "solver-plugin", "{{solverTypeString}}"],
+  "license": "MIT"
+}

package/templates/plugins/solver-type-plugin/skills/example/SKILL.md.tmpl

@@ -0,0 +1,10 @@
+---
+name: {{packageNameSlug}}-example
+description: An example skill that ships with the {{packageName}} plug-in. Replace this body with your plug-in's actual skill content.
+---
+
+# Example skill
+
+This skill is a placeholder. Replace its body with content that helps a solver agent attempt `{{solverTypeString}}` tasks.
+
+Skills are markdown files with YAML frontmatter. The frontmatter's `name` and `description` are used by harnesses to decide when to load the skill into context.

package/templates/plugins/solver-type-plugin/test/plugin.test.ts.tmpl

@@ -0,0 +1,25 @@
+import { describe, it, expect } from 'vitest';
+import { readFileSync, existsSync } from 'node:fs';
+import { join, dirname } from 'node:path';
+import { fileURLToPath } from 'node:url';
+
+const ROOT = join(dirname(fileURLToPath(import.meta.url)), '..');
+
+describe('{{packageName}} manifest', () => {
+  it('has a valid jinn.plugin.json', () => {
+    const manifestPath = join(ROOT, 'jinn.plugin.json');
+    expect(existsSync(manifestPath)).toBe(true);
+    const manifest = JSON.parse(readFileSync(manifestPath, 'utf8'));
+    expect(manifest.name).toBe('{{packageName}}');
+    expect(manifest.jinn.supports).toContain('{{solverTypeString}}');
+    expect(Array.isArray(manifest.jinn.skills)).toBe(true);
+  });
+
+  it('every declared skill file exists', () => {
+    const manifestPath = join(ROOT, 'jinn.plugin.json');
+    const manifest = JSON.parse(readFileSync(manifestPath, 'utf8'));
+    for (const skill of manifest.jinn.skills ?? []) {
+      expect(existsSync(join(ROOT, skill)), `missing skill file: ${skill}`).toBe(true);
+    }
+  });
+});

package/templates/plugins/solver-type-plugin/tsconfig.json.tmpl

@@ -0,0 +1,11 @@
+{
+  "compilerOptions": {
+    "target": "ES2022",
+    "module": "ESNext",
+    "moduleResolution": "Bundler",
+    "esModuleInterop": true,
+    "strict": true,
+    "skipLibCheck": true
+  },
+  "include": ["test/**/*.ts"]
+}