@amsterdamdatalabs/enact-extensions 0.1.42 → 0.1.47

package/extensions/enact-factory/skills/testing-strategy/SKILL.md

@@ -1,172 +0,0 @@
----
-name: testing-strategy
-description: >
-  Defines when and how to write tests in the enact-gateway codebase. Trigger
-  keywords: testing, write a test, TDD, bug fix, regression test, live test,
-  e2e, integration test, test harness, evidence, red-green, scenario, validate.
----
-
-# testing-strategy
-
-> **Storage is GLOBAL — never write to a repo-local `.enact` dir.** Resolve the project's global dir:
-> 1. `ROOT="$(git rev-parse --show-toplevel)"`
-> 2. In `~/.enact/workspaces.json` → `workspaces`, find the entry whose `.root` == `$ROOT`; its object key is `<name>-<id>`.
-> 3. Factory planning artifacts go under `~/.enact/factory/projects/<key>/…`. Local `_evidence/` remains a repo-local proof surface for Mode 1 only.
-
-## Purpose
-
-Enforce a consistent, lightweight approach across the three testing modes used
-in `enact-gateway`. The mode is determined by the behavior under test — not by
-preference. Pick once, follow the contract for that mode.
-
----
-
-## Decision Rule
-
-| Situation | Mode |
-|-----------|------|
-| Pure function or isolated logic | Mode 0 — plain unit test |
-| Bug fix (any scope) | Mode 1 — TDD + `_evidence` |
-| Bug fix where behavior is runtime / live / cross-service (gateway → observe / iggy / questdb) | Mode 1 RED→GREEN + the regression test is a Mode-2 harness scenario |
-| New live-provider, cross-service, or e2e behavior | Mode 2 — harness scenario under `tests/integration/` or `tests/e2e/` |
-
----
-
-## Mode 0 — Plain Unit Tests
-
-Use for: pure functions, simple transformations, isolated module logic.
-
-- File location: co-located with the source file, e.g. `src/foo/bar.spec.ts`.
-- Stack: Jest + ts-jest (resolved from `packages/backend`).
-- No harness ceremony. No fixtures directory. No `output/` directory.
-- Run: `npm run test --workspace=packages/backend` (or `npx jest <pattern>`).
-
-Do NOT force the harness onto plain unit tests. Co-located `.spec.ts` is
-sufficient and preferred.
-
----
-
-## Mode 1 — Bug Fix: TDD with Captured `_evidence`
-
-### Contract
-
-1. **RED** — write a failing test that reproduces the bug before touching
-   implementation code. Capture the failure output:
-   ```
-   _evidence/<scenario>/red.txt
-   ```
-2. **Fix** — implement the minimal change that makes the test pass.
-3. **GREEN** — capture the passing output:
-   ```
-   _evidence/<scenario>/green.txt
-   ```
-
-`_evidence/` is **gitignored** — it is local proof, never committed source.
-
-### Regression test placement
-
-- If the bug is in pure/isolated logic, a co-located `.spec.ts` is sufficient.
-- If the bug involves runtime behavior — real provider calls, streaming,
-  cross-service interaction (gateway → observe / iggy / questdb) — the
-  regression test **must** be a Mode-2 harness scenario, not an ad-hoc script.
-
-### AzDO closure gate
-
-A bug work item in Azure DevOps (area `Enact\<leaf>`) must not be closed until:
-- A regression test exists (either `.spec.ts` or harness scenario).
-- `_evidence/<scenario>/red.txt` and `green.txt` are present locally.
-- The AzDO "Tests passing" Build boolean is green.
-
----
-
-## Mode 2 — Live / Integration Test Harness
-
-### Directory layout
-
-```
-tests/
-  integration/<scenario>/      # harness scenarios (non-billable, require a live gateway)
-    fixtures/
-      input.json               # request body POSTed to the gateway
-    run.py (or run.ts)         # sends the request, writes output/<timestamp>.json
-    validate.py (or validate.ts) # reads latest output, prints PASS:/FAIL: per check
-    output/                    # gitignored; populated by run.py
-  e2e/                         # live, billable suites — OPT-IN only
-    <suite>.e2e-spec.ts        # Jest spec; skipped unless ENACT_LIVE_PROVIDER_TESTS=1
-    <scenario>/                # standalone scenario dirs (same run.py/validate.py shape)
-  lib/                         # shared harness helpers (import from here, do not duplicate)
-```
-
-> **Known issue:** `cli.py` currently globs `domains/*/*` but scenarios are
-> now laid out flat at `tests/integration/<scenario>/`. This mismatch is being
-> fixed; do not work around it by restructuring existing scenarios.
-
-### Scenario contract
-
-**`fixtures/input.json`** — the full JSON request body. Secrets are never
-stored here; only structure.
-
-**`run.py`** — self-contained runner:
-- Reads `ENACT_GATEWAY_BASE_URL` (default `http://127.0.0.1:43201`).
-- Reads `ENACT_GATEWAY_API_KEY` or `GATEWAY_API_KEY` for the bearer token.
-  If absent, writes `status: "skip"` and exits 0 — no tokens spent.
-- Reads `ENACT_GATEWAY_TIMEOUT_SECS` (default `30`).
-- POSTs `fixtures/input.json` to `<base_url>/v1/responses`.
-- Writes `output/<YYYYMMDDTHHmmss>.json` with one of:
-  - `{"status": "ok", "http_status": 200, "response_body": {...}, ...}`
-  - `{"status": "http_error", "http_status": <N>, "reason": "...", ...}`
-  - `{"status": "skip", "reason": "...", ...}`
-- Prints the output path and exits 0 (even for `http_error` — validate decides).
-
-**`validate.py`** — assertion layer:
-- Reads the latest file in `output/` (sort by name, take last).
-- If `status == "skip"`: prints `SKIP: <reason>` and exits 0.
-- If `status != "ok"`: prints `FAIL: ...` and exits 1.
-- For each behavioral check: prints `PASS: <label>` or `FAIL: <label>`.
-- Exits non-zero if any check failed.
-
-Secrets are **only ever passed by env-var name**, never committed to fixtures or
-source.
-
-### Task runner
-
-```bash
-# from tests/integration/
-uv run tasks list                              # list all discovered scenarios
-uv run tasks run <scenario>                    # run + validate
-uv run tasks run <scenario> --run-only         # skip validate
-uv run tasks run <scenario> --validate-only    # skip run (re-validate last output)
-uv run tasks run --all                         # run every scenario
-```
-
-### Live / billable suites (`tests/e2e/`)
-
-Live tests make **real, billable upstream calls**. They are OPT-IN and skipped
-in all normal / CI runs unless the flag is set explicitly:
-
-```bash
-# from packages/backend
-ENACT_LIVE_PROVIDER_TESTS=1 \
-LIVE_GATEWAY_URL=http://127.0.0.1:43201 \
-LIVE_KEY_ENACT_CODING=engw_... \
-LIVE_KEY_OPENCODE_GO=engw_... \
-LIVE_KEY_NANOGPT=engw_... \
-LIVE_KEY_OPENROUTER=engw_... \
-  npx jest --config ../../tests/e2e/jest-e2e.json --runInBand
-```
-
-Each `describe` block gates on its own key env-var, so individual profiles can
-be run in isolation by omitting the others.
-
----
-
-## Output / Definition of Done
-
-A test is complete when:
-
-| Mode | Done when |
-|------|-----------|
-| Mode 0 | `npx jest <file>` exits 0; coverage covers the changed logic |
-| Mode 1 | `_evidence/<scenario>/red.txt` captured before fix; `green.txt` captured after; regression test in place |
-| Mode 2 — harness | `uv run tasks run <scenario>` exits 0 with all `PASS:` lines printed; or `SKIP:` when key absent (acceptable in CI) |
-| Mode 2 — live suite | Suite exits 0 under `ENACT_LIVE_PROVIDER_TESTS=1` with a live gateway; CI skips without the flag |

package/extensions/enact-factory/skills/trace/SKILL.md

@@ -1,42 +0,0 @@
----
-name: trace
-description: "Execution-path mapping for entry points, data flow, side effects, and blast radius before risky work."
----
-
-# Trace
-
-> **Storage is GLOBAL — never write to a repo-local `.enact` dir.** Resolve the project's global dir:
-> 1. `ROOT="$(git rev-parse --show-toplevel)"`
-> 2. In `~/.enact/workspaces.json` → `workspaces`, find the entry whose `.root` == `$ROOT`; its object key is `<name>-<id>`.
-> 3. Factory planning artifacts go under `~/.enact/factory/projects/<key>/…`.
-
-## Purpose
-
-Use `$trace` before a risky edit or review when you need to know what code path actually runs, what
-it touches, and what could break downstream.
-
-## Workflow
-
-1. Find the entry points.
-2. Follow data flow through the changed or targeted path.
-3. Map side effects:
-   - storage writes
-   - network calls
-   - UI state changes
-   - background work
-4. Identify risky branches and missing guards.
-5. Name the concrete files the next pass should touch.
-
-## Suggested Tools
-
-- `ctx_search` for symbol and path discovery
-- `ctx_read` for call-path confirmation
-- `ctx_semantic_search` or `ctx_graph` when lexical search is not enough
-
-## Output Standard
-
-- entry points
-- downstream side effects
-- risky branches
-- likely blast radius
-- recommended edit boundary

package/extensions/enact-factory/skills/ultraqa/SKILL.md

@@ -1,85 +0,0 @@
----
-name: ultraqa
-description: "QA cycling workflow with hard-stop verification gates: tests, lint, smoke execution, and loop-contract persistence."
-lane: true
----
-
-# UltraQA
-
-> **Storage is GLOBAL — never write to a repo-local `.enact` dir.** Resolve the project's global dir:
-> 1. `ROOT="$(git rev-parse --show-toplevel)"`
-> 2. In `~/.enact/workspaces.json` → `workspaces`, find the entry whose `.root` == `$ROOT`; its object key is `<name>-<id>` (e.g. `enact-evolve-a38d1e`).
-> 3. Factory artifacts go under `~/.enact/factory/projects/<key>/…`; loop runtime state lives under `~/.enact/loop/projects/<key>/…`.
-
-## Purpose
-Combines `$loop` (durable contract-runner with closure gates) with an explicit set of QA gates. Each gate must pass before the loop advances. The cycle is: implement a fix, run all gates, advance only when green, repeat until every gate is clean in a single run.
-
-## Use When
-- Verification has failed and a structured fix-verify cycle is needed
-- A feature must be proven working end-to-end before merging
-- A hard record of each verification pass and failure is required
-
-## Execution Policy
-
-- start from the repo and `~/.enact/factory/projects/<key>/` truth, not chat memory
-- drive the QA loop through loop MCP tools; CLI commands are the fallback
-- keep loop state current as you go
-- do not stop until all gates pass in a single clean run
-
-## Workflow
-1. Start a loop contract scoped to the QA goal:
-   - MCP: `loop_start` with `goal` and QA gate stages as the contract
-   - CLI fallback: use the `enact-loop` runtime only for `status` / `summary write`; contract start remains MCP-first
-2. Check current loop status before each iteration:
-   - MCP: `loop_status`
-   - CLI fallback: `enact-loop status --json`
-3. Run each QA gate in sequence. All must pass before advancing:
-   - Unit and integration tests (run the project's test command)
-   - Lint and type checks (run the project's lint command)
-   - Doctor / readiness check (run the project's doctor command if present)
-   - Real-execution smoke test (invoke the primary feature with real inputs, not mocks)
-4. Record each mechanical gate via the engine:
-   - MCP: `loop_grade({ stageId, timeoutMs? })` — engine runs the stage command in loop root; rejects caller `status`/`evidence`
-5. After all mechanical gates pass, advance to verifying:
-   - MCP: `loop_advance` with `toPhase=verifying`
-6. If a judgment review is required, dispatch a grader and relay the verdict:
-   - MCP: `loop_grader_dispatch({ stageId })` → driver relays via `loop_grader_verdict` (`captureSource: "relayed"`)
-7. When all required stages are passed, write the closure summary then complete the loop:
-   - CLI: `enact-loop summary write` (stamps fingerprint into `~/.enact/loop/projects/<key>/state/<YYMMDDHH>-loop-summary.md` and updates `summary-current.json`)
-   - MCP: `loop_complete` with `summary`
-   - CLI fallback: use MCP for completion; `summary write` is the required CLI closure step
-
-## Proof Path
-
-- Use `loop_contract_parity` for contract-parity checks when QA is part of closure.
-- Judgment stages require an independent grader (different vendor/model) via `loop_grader_dispatch`.
-- Do not substitute inferred status for command-backed evidence.
-
-## State Contract
-- Reads: `enact-loop status --json` (current loop state), `enact-loop summary show` / `summary-current.json` (current closure summary), test and lint output
-- Writes: loop state via MCP tools (`loop_grade`, `loop_advance`, `loop_complete`) and `enact-loop summary write` for the append-only closure summary artifact
-
-## MCP Tools
-
-- `loop_start` — start a loop contract scoped to the QA goal
-- `loop_status` — read current loop state
-- `loop_advance` — transition to the next phase
-- `loop_grade` — run a mechanical stage command in loop root (engine-derived pass/fail)
-- `loop_grader_dispatch` — dispatch an independent grader for a judgment gate
-- `loop_grader_verdict` — record an independent grader's GO/NO-GO
-- `loop_block` — mark blocked with a reason
-- `loop_complete` — close the loop after all gates pass
-- `loop_abort` — abort the loop with a reason
-- `loop_contract_parity` — run contract-parity check
-
-## Activation
-
-Invoke with `$ultraqa` or `$enact-loop:ultraqa`. The SessionStart hook auto-resumes any active loop; use `enact-loop status --json` to inspect the current state. The Stop boulder blocks exit until all required stages are passed and the loop phase is terminal.
-
-## Final Check
-- Every gate (tests, lint, doctor, smoke) passed in a single iteration with command evidence
-- `loop_grade` passed all mechanical stages (engine-run, exit 0) before `loop_complete`
-- Judgment stages have valid independent grader verdicts from `loop_grader_verdict`
-- No gate was skipped or bypassed
-- `enact-loop summary write` produced the current timestamped closure summary before `loop_complete`
-- `loop_complete` was called; no loop left in `running` or `verifying` state

package/extensions/enact-factory/skills/work-with-workitem/SKILL.md

@@ -1,56 +0,0 @@
----
-name: work-with-workitem
-description: "Lightweight Azure DevOps work-item delivery lane: implement and hand off; factory owns tracking and closure."
----
-
-# Work With Workitem
-
-> **Storage is GLOBAL — never write to a repo-local `.enact` dir.** Resolve the project's global dir:
-> 1. `ROOT="$(git rev-parse --show-toplevel)"`
-> 2. In `~/.enact/workspaces.json` → `workspaces`, find the entry whose `.root` == `$ROOT`; its object key is `<name>-<id>`.
-> 3. Factory planning artifacts go under `~/.enact/factory/projects/<key>/…`; loop runtime state and closure summaries go under `~/.enact/loop/projects/<key>/…`.
-
-## Purpose
-
-Use `$work-with-workitem` for agent-driven delivery tied to a single Azure DevOps work item.
-
-## Domain Boundary
-
-- agent scope is intentionally lightweight: load, isolate, implement, PR, handoff, cleanup
-- enact-factory owns CI heartbeat tracking, branch policy waits, auto-merge, and lifecycle advance to `Closed`
-- this skill must not add CI polling loops or unbounded branch-policy waiting
-
-## Azure DevOps-Only Contract
-
-- use `factory_workitem_get` and `factory_assignment_record` for work-item reads and closing notes
-- use `az repos pr create --work-items <id>` to link the PR to the work item
-- do not assume or reference GitHub APIs, GitHub Actions, GitHub checks, or GitHub branch protection primitives
-
-## Required Sequence
-
-1. `factory_workitem_get` loads the target work item and confirms readiness.
-2. `EnterWorktree` isolates the implementation workspace.
-3. Execute implementation (use a loop contract or inline execution for simple tasks).
-4. Create atomic commits with clear work-item-linked intent.
-5. Run `az repos pr create --work-items <id>` and capture the PR URL.
-6. Call `factory_assignment_record` with a closing note that includes PR URL and commit SHA.
-7. `ExitWorktree` cleans up the isolated workspace.
-
-## Behavioral Constraints
-
-- no CI poll loop in this skill; CI heartbeat belongs to `factory_watchdog_status`
-- no merge waiting or policy-wait ownership in this skill
-- no lifecycle mutation to `Closed` from this skill
-- if PR creation fails, record failure context and exit through normal cleanup
-
-## Verification Expectations
-
-- integration target is a work item tagged `test-fixture`
-- verify PR link uses `--work-items <id>`
-- verify `factory_assignment_record` includes PR URL and commit SHA
-- verify `ExitWorktree` cleanup is executed
-- do not verify CI completion or merge here
-
-## Activation
-
-Invoke with `$work-with-workitem` or `$enact-factory:work-with-workitem`. The skill uses enact-factory MCP tools (`factory_workitem_get`, `factory_assignment_record`) for all work-item interactions. No durable workflow state is started automatically — the skill runs to completion within a single session.

package/extensions/enact-factory/skills/workitem-triage/SKILL.md

@@ -1,42 +0,0 @@
----
-name: workitem-triage
-description: >-
-  Read-only triage of Enact Factory WorkItems — assess queue state and
-  individual WorkItem details without scheduling, mutation, or execution. Use
-  when reviewing the board, checking a WorkItem's status/blockers, or triaging
-  the queue. Triggers on "triage", "workitem status", "queue state",
-  "$workitem-triage".
----
-
-# workitem-triage
-
-> **Storage is GLOBAL — never write to a repo-local `.enact` dir.** Resolve the project's global dir:
-> 1. `ROOT="$(git rev-parse --show-toplevel)"`
-> 2. In `~/.enact/workspaces.json` → `workspaces`, find the entry whose `.root` == `$ROOT`; its object key is `<name>-<id>`.
-> 3. Factory planning artifacts and queue-state handoff notes go under `~/.enact/factory/projects/<key>/…` when a downstream skill persists them.
-
-## Purpose
-Provide a read-only triage surface for Factory WorkItems. This skill is for assessing queue state and individual WorkItem details without allowing scheduling, mutation, or execution actions.
-
-## Activation Contract
-- Activate with `factory_skill_activate` and `skill="workitem-triage"`.
-- Deactivate with `factory_skill_deactivate` when triage is complete.
-- While active, visible MCP tools must be limited to:
-  - `factory_workitem_list`
-  - `factory_workitem_get`
-
-## Forbidden Operations
-- Do not call scheduler, assignment, lifecycle, watchdog, sync, or closure mutation tools while this skill is active.
-- Do not update WorkItem state, queue entries, assignments, or process state.
-- Do not dispatch agent lanes or terminate processes.
-
-## Output Contract
-- Return concise, factual triage output only.
-- Include WorkItem ids, statuses, and blockers when present.
-- If required data is missing, explicitly state unknowns instead of inferring.
-- Keep recommendations non-mutating unless the operator explicitly switches out of triage mode.
-
-## Related
-- For the Azure DevOps branch/PR/release strategy and the `az` CLI/REST recipes
-  (branch policies, PR creation/promotion, build-failure diagnosis), see the
-  sibling `azdo-ci-strategy` skill.

package/extensions/enact-wiki/.agents/plugin.json

@@ -1,43 +0,0 @@
-{
-  "name": "enact-wiki",
-  "version": "0.1.0",
-  "description": "Vault-backed knowledge base with semantic search, dream consolidation, and MCP tools for agent memory workflows.",
-  "license": "UNLICENSED",
-  "keywords": [
-    "enact-wiki",
-    "wiki",
-    "vault",
-    "memory",
-    "knowledge-base",
-    "qdrant",
-    "semantic-search"
-  ],
-  "targets": [
-    "claude",
-    "codex",
-    "cursor",
-    "enact"
-  ],
-  "skills": "./skills/",
-  "mcpServers": "./.mcp.json",
-  "interface": {
-    "displayName": "Enact Wiki",
-    "shortDescription": "Vault skills, MCP tools, and runtime bootstrap via `enact-wiki bootstrap`.",
-    "longDescription": "Install this plugin to expose enact-wiki MCP tools in Claude, Codex, and Cursor and enable semantic search over the workspace Qdrant collection, dream consolidation, and vault-backed knowledge workflows.",
-    "developerName": "enact-wiki",
-    "category": "Developer Tools",
-    "composerIcon": "./assets/icon.png",
-    "logo": "./assets/logo.png",
-    "capabilities": [
-      "semantic search",
-      "vault knowledge base",
-      "dream consolidation",
-      "mcp tools",
-      "qdrant vector search"
-    ]
-  },
-  "factory": {
-    "firstParty": true,
-    "operatorScope": "global"
-  }
-}

package/extensions/enact-wiki/.mcp.json

@@ -1,15 +0,0 @@
-{
-  "mcpServers": {
-    "enact-wiki": {
-      "command": "enact-wiki",
-      "args": ["mcp", "."],
-      "env_vars": [
-        "ENACT_WIKI_EMBEDDING_API_KEY",
-        "AZURE_OPENAI_API_KEY",
-        "ENACT_GATEWAY_API_KEY",
-        "ENACT_WIKI_LINT_API_KEY",
-        "ENACT_WIKI_QUERY_API_KEY"
-      ]
-    }
-  }
-}

package/extensions/enact-wiki/README.md

@@ -1,44 +0,0 @@
-# enact-wiki plugin
-
-Plugin manifests for Claude Code and Codex. The Codex plugin is self-contained:
-it carries plugin-local `skills/`, `.mcp.json`, and branding assets so Codex can
-discover all capabilities from the installed plugin root.
-
-## Layout
-
-| Path | Role |
-|------|------|
-| `.claude-plugin/plugin.json` | Claude Code plugin manifest |
-| `.codex-plugin/plugin.json` | Codex plugin manifest |
-| `.mcp.json` | MCP server entry (`enact-wiki mcp .`) |
-| `skills/` | Codex-visible Enact Wiki skills |
-| `assets/` | Branding icons |
-
-## Bootstrap a vault
-
-Use `enact-wiki bootstrap <runtime>` to scaffold any directory for a
-specific provider. This copies the canonical surfaces from `vault-bootstrap/`
-into the target:
-
-```bash
-enact-wiki bootstrap claude          # .claude/commands/, .claude/settings.json, .mcp.json
-enact-wiki bootstrap opencode        # .opencode/commands/, .mcp.json, opencode.json
-enact-wiki bootstrap all             # every provider surface
-```
-
-See `enact-wiki bootstrap --help` for all supported runtimes.
-
-## Claude Code plugin registration
-
-Installing the npm package auto-registers this plugin in `~/.claude/settings.json`
-via the postinstall script. To register manually:
-
-```bash
-claude plugin add /path/to/enact-wiki/extensions
-```
-
-## Marketplace (Codex)
-
-`.agents/plugins/marketplace.json` at the repo root registers this plugin
-for local dev. For global use, point `~/.agents/plugins/marketplace.json`
-to the absolute path of this directory.

package/extensions/enact-wiki/skills/document-parser/SKILL.md

@@ -1,17 +0,0 @@
----
-name: document-parser
-description: Parse documents with the Kreuzberg v4 CLI via the repo-local `scripts/parse.sh` wrapper.
----
-
-# document-parser
-
-Use when you need consistent text + metadata extraction from supported files: PDF, DOCX, PPTX, XLSX, HTML, EML, and images.
-
-## Entry point
-
-```bash
-./.codex/skills/document-parser/scripts/parse.sh <path>
-./.codex/skills/document-parser/scripts/parse.sh <path> --json
-```
-
-This wrapper is the canonical local interface and keeps parsing behavior aligned between direct skill use and repo runtime.

package/extensions/enact-wiki/skills/document-parser/scripts/parse.sh

@@ -1,60 +0,0 @@
-#!/bin/bash
-# parse.sh - Extract text or JSON from a document using Kreuzberg CLI
-# Usage: parse.sh <file> [--json]
-
-set -euo pipefail
-
-export PATH="${HOME}/.kreuzberg/bin:${PATH:-}"
-
-if [[ $# -lt 1 ]]; then
-  echo "Usage: parse.sh <file> [--json]" >&2
-  exit 1
-fi
-
-FILE="$1"
-FORMAT="text"
-if [[ "${2:-}" == "--json" ]]; then
-  FORMAT="json"
-fi
-
-if [[ ! -f "$FILE" ]]; then
-  echo "File not found: $FILE" >&2
-  exit 1
-fi
-
-file_size() {
-  if stat -f%z "$1" >/dev/null 2>&1; then
-    stat -f%z "$1"
-  else
-    stat -c%s "$1"
-  fi
-}
-
-run_with_timeout() {
-  if command -v gtimeout >/dev/null 2>&1; then
-    gtimeout 60 "$@"
-    return
-  fi
-  if command -v timeout >/dev/null 2>&1; then
-    timeout 60 "$@"
-    return
-  fi
-  "$@"
-}
-
-if [[ "$(file_size "$FILE")" -gt 100000000 ]]; then
-  echo "File exceeds 100MB limit" >&2
-  exit 1
-fi
-
-if ! command -v kreuzberg >/dev/null 2>&1; then
-  echo "kreuzberg not found on PATH. Install it into \$HOME/.kreuzberg/bin or PATH first." >&2
-  exit 1
-fi
-
-CMD=(kreuzberg extract "$FILE")
-if [[ "$FORMAT" == "json" ]]; then
-  CMD+=(--format json)
-fi
-
-run_with_timeout "${CMD[@]}"

package/extensions/enact-wiki/skills/document-parser/skill.json

@@ -1,9 +0,0 @@
-{
-  "name": "document-parser",
-  "version": "1.0.0",
-  "description": "Parse and extract text + metadata from PDF, DOCX, PPTX, XLSX, HTML, EML, images using Kreuzberg v4 CLI.",
-  "commands": {
-    "parse": "Extract text or JSON from a document via Kreuzberg (scripts/parse.sh <file> [--json])"
-  },
-  "requires": ["kreuzberg"]
-}

package/extensions/enact-wiki/skills/enact-wiki/SKILL.md

@@ -1,30 +0,0 @@
----
-name: enact-wiki
-description: "Enact Wiki vault workflows: query and search, ingest and sync, and CLI management. Use the reference files under references/ for the slice you need."
----
-
-# enact-wiki
-
-Codex entry for the same workflows Claude exposes as `/wiki-*` commands. This skill is an **umbrella**: open the right reference for the task.
-
-## References (read the matching file)
-
-| Topic | File |
-|------|------|
-| Query / search / read | `references/query.md` |
-| Ingest, sync, dream | `references/ingest.md` |
-| Lint, build, export, init, MCP, etc. | `references/manage.md` |
-
-## Invariants
-
-- Vault root: run `enact-wiki` from the vault directory.
-- Keep **`raw/`** immutable except through prescribed sync / ingest flows.
-- Prefer the **CLI** for mechanical steps; use the model only where a reference file says to.
-
-## Full pipeline (lint → build → links)
-
-When the user wants the end-to-end quality pass, follow `.claude/commands/wiki-all.md` or run:
-
-```bash
-enact-wiki all
-```