@amsterdamdatalabs/enact-extensions 0.1.37 → 0.1.47

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

@@ -1,67 +0,0 @@
----
-name: review
-description: "Findings-first pre-landing review against code, plan completion, verification evidence, and loop state."
----
-
-# Review
-
-> **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 under `~/.enact/loop/projects/<key>/…`.
-
-## Purpose
-
-Use `$review` to answer one question: is this actually ready to land? Review is not a summary pass.
-It is a bug, regression, coverage, and state-integrity pass.
-
-## Execution Policy
-
-- findings first, summary second
-- prefer evidence over author claims
-- check the code, the tests, the plan, and the loop artifacts
-- if the current context authored the change, prefer a separate reviewer role for approval
-
-## Active Artifact Resolution
-
-Resolve the plan and verification map to review:
-
-1. Prefer paths recorded in the active loop/run session when available.
-2. Else under `~/.enact/factory/projects/<key>/plans/`, pick the lexicographically greatest `YYMMDDHH` among:
-   - plan files matching `*-{phase}.md` (exclude `-verification` and `-requirements`)
-   - verification files matching `*-{phase}-verification.md` with the **same** `YYMMDDHH` prefix as the plan when possible
-3. Fall back to legacy unprefixed plan names only for reads during migration — never treat them as the write contract.
-
-For loop closure, read the current summary via `enact-loop summary show` or `summary-current.json` under `~/.enact/loop/projects/<key>/state/`.
-
-## Review Order
-
-1. Read the changed code.
-2. Read the active plan and verification map (resolved per rules above).
-3. Check what was supposed to happen vs what actually landed.
-4. Verify:
-   - tests and typechecks
-   - docs drift
-   - `~/.enact/factory/projects/<key>/` state drift
-   - judgment stages have valid independent grader verdicts
-   - closure summary exists and fingerprint is current when the loop is closure-ready
-5. Produce a verdict:
-   - approved
-   - changes requested
-   - blocked
-
-## Mandatory Checks
-
-- missing or fake verification
-- uncovered changed paths
-- stale docs or setup instructions
-- task marked done but still pending review evidence
-- judgment stages with self-reported verdicts (flag as grader-independence-missing)
-- closure-ready loop without a current timestamped summary artifact
-
-## Output Standard
-
-- findings ordered by severity
-- file references and why they matter
-- residual risk
-- final verdict and next action

package/extensions/enact-factory/skills/security-research/SKILL.md

@@ -1,57 +0,0 @@
----
-name: security-research
-description: "Multi-agent security research with hunter/PoC split and optional critical bug auto-creation in Azure DevOps."
----
-
-# Security Research
-
-> **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. Security findings go under `~/.enact/factory/projects/<key>/security/…`.
-
-Use `$security-research` to run a focused vulnerability hunt, produce ranked findings, and optionally create Azure DevOps Bug work items for critical issues.
-
-## Parameters
-
-- `autoCreateBugs: boolean` (default `true`)
-- when `false`, no `factory_workitem_sync_once` call is allowed regardless of severity
-
-## Team Topology
-
-- 3 hunter agents:
-- hunter 1: CWE classification
-- hunter 2: CVSS v4 scoring
-- hunter 3: OWASP category mapping
-- 2 PoC engineer agents:
-- PoC 1 and PoC 2: exploitability proof and reproduction quality
-
-## Required Workflow
-
-1. Launch hunters to identify and classify potential vulnerabilities.
-2. Launch PoC engineers on top-ranked findings to validate exploitability.
-3. Merge outputs into a single findings report.
-4. Write report to `~/.enact/factory/projects/<key>/security/<sessionId>/<YYMMDDHH>-findings.md` (e.g. `security/abc123/26062101-findings.md`). Resolve `<key>` from `~/.enact/workspaces.json`; get the timestamp prefix via `date +%y%m%d%H`.
-5. Rank findings in the report by CVSS v4 severity.
-6. For each finding with CVSS v4 `>= 9.0`, if `autoCreateBugs=true`, call `factory_workitem_sync_once` to create a `Bug` work item.
-7. If `autoCreateBugs=false`, skip all bug auto-creation calls.
-
-## Azure DevOps-Only Contract
-
-- use factory MCP work-item surfaces for bug creation
-- no GitHub Security Advisories, GitHub issue creation, or GitHub-specific security automation assumptions
-
-## Behavioral Constraints
-
-- CVSS scoring must be v4, not v3 fallback
-- critical auto-bug creation threshold is fixed at `>= 9.0`
-- findings must include at least one of: CWE, CVSS v4 vector/score, OWASP mapping
-
-## Verification Expectations
-
-- integration test: findings report includes at least one CWE classification entry
-- integration test: with `autoCreateBugs=false`, verify no `factory_workitem_sync_once` call is made
-
-## Activation
-
-Invoke with `$security-research` or `$enact-factory:security-research`. This skill uses enact-factory MCP tools for work-item creation. No durable workflow state is started automatically — the skill produces findings within a single session.

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

@@ -1,62 +0,0 @@
----
-name: tdd
-description: "Red-green-refactor mode for behavior with clear inputs, outputs, and regression value."
----
-
-# TDD
-
-> **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 `$tdd` when behavior can be specified before implementation. TDD is for design pressure and
-regression safety, not for ritual.
-
-## Good TDD Candidates
-
-- business rules
-- API contracts
-- parsing, formatting, or validation
-- state transitions
-- algorithms and utility behavior
-
-## Skip TDD For
-
-- pure layout and styling work
-- config-only changes
-- trivial glue code
-- exploratory prototypes where behavior is not yet known
-
-## Iron Law
-
-No production code without a failing test first.
-
-## Cycle
-
-1. Red
-   - write the smallest failing test for the next behavior
-   - run it and prove it fails for the right reason
-2. Green
-   - write the minimum code to make it pass
-   - rerun the test and the relevant suite
-3. Refactor
-   - clean up only after green
-   - keep the suite green after every change
-
-## Rules
-
-- one behavior per cycle
-- do not batch multiple features into one red-green pass
-- prefer regression tests for changed behavior
-- record the verify command in the current timestamped plan artifact (for example
-  `~/.enact/factory/projects/<key>/plans/<YYMMDDHH>-<phase>.md`) or in linked task notes
-
-## Output Standard
-
-- what behavior the test locked in
-- the failing signal
-- the minimal implementation
-- the final verification command

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"
-      ]
-    }
-  }
-}