@amsterdamdatalabs/enact-extensions 0.1.42 → 0.1.47

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

@@ -1,120 +0,0 @@
----
-name: looplan
-description: "Plan-first loop execution wrapper: write a durable plan, enter the loop, drive to verified closure. Use when the work needs a reviewable plan before the loop starts."
----
-
-# Looplan
-
-> **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 planning artifacts go under `~/.enact/factory/projects/<key>/…`; loop runtime state under `~/.enact/loop/projects/<key>/…`.
-
-## Purpose
-
-Use `$looplan` when the work needs a reviewable execution plan before the loop starts. Looplan gates
-execution behind a plan the user or reviewer can inspect, then advances into the `$loop` contract
-runner with explicit stage verification.
-
-Looplan is the combination of `$plan` (write artifacts, define slices and verification) and `$loop`
-(durable contract-runner with closure gates). Neither sub-skill is optional.
-
-## Use When
-
-- the request is clear enough to plan but carries meaningful risk or complexity
-- a written plan artifact needs to exist before any code changes
-- verification stages need to be defined up front, not discovered mid-execution
-- the user wants to review the plan before execution begins
-
-## Do Not Use When
-
-- the request is still ambiguous — route through `$deep-interview` first, then return here
-- the work is trivial and a plan would add no value
-
-## Lifecycle
-
-```
-intent → $plan (write plan + verification map) → user review → $loop start → running → verifying → completed
-```
-
-Each transition is explicit. Never advance to the loop before the plan artifact exists and is reviewed.
-
-## Timestamped Artifact Naming
-
-All durable factory markdown artifacts use `YYMMDDHH-<slug>.md` where `YYMMDDHH=$(date +%y%m%d%H)`.
-Use the **same** prefix for the plan and verification map written in one planning pass.
-**Never overwrite** a prior plan file — each looplan run writes fresh timestamped artifacts.
-
-## Workflow
-
-### Phase 1 — Plan
-
-1. Read current artifacts and inspect the repo for brownfield context (latest timestamped files per `$plan` resolution rules).
-2. Write the plan to `~/.enact/factory/projects/<key>/plans/<YYMMDDHH>-<phase>.md` following `$plan` conventions:
-   - Named files per slice
-   - Explicit verification per slice
-   - Exit conditions stated
-3. Write the verification map to `~/.enact/factory/projects/<key>/plans/<YYMMDDHH>-<phase>-verification.md`.
-4. Present the plan for review. Do not advance until it is approved.
-
-### Phase 2 — Execute
-
-5. Start the loop with the goal and stages from the plan:
-   ```
-   loop_start  goal="<goal>"  contract=<stages from plan>
-   ```
-6. Confirm the loop is running: `loop_status`
-7. Execute each plan slice.
-   - Mechanical stages: `loop_grade({ stageId })` — the engine runs the stage `command` in the
-     loop root and records pass/fail from exit code. Do **not** run the command separately and
-     self-report `status` or `evidence` (rejected by the runtime).
-   - Judgment stages: `loop_grader_dispatch({ stageId })` → independent grader reviews → driver
-     relays GO/NO-GO via `loop_grader_verdict` with the minted `continuationId` (default:
-     `captureSource: "relayed"`). Grader child sessions have **no closure authority**.
-8. If blocked: `loop_block` with reason, resolve, then `loop_advance` back to `running`.
-
-### Phase 3 — Verify and Complete
-
-9. When all stages have evidence, advance to verifying:
-   ```
-   loop_advance  toPhase=verifying
-   ```
-10. Run `$review` against the completed work and plan artifacts.
-11. Write the closure summary via `enact-loop summary write` (CLI stamps fingerprint header into a new `YYMMDDHH-loop-summary.md`), then complete the loop:
-    ```
-    loop_complete  summary="<one-line summary>"
-    ```
-12. If review returns changes requested, advance back to running and address findings.
-
-## State Contract
-
-Reads:
-- `~/.enact/factory/projects/<key>/plans/*` (latest timestamped plan + verification map from Phase 1)
-- `~/.enact/loop/projects/<key>/state/loop.json` (loop state)
-- `~/.enact/loop/projects/<key>/state/summary-current.json` (pointer to current closure summary)
-
-Writes:
-- `~/.enact/factory/projects/<key>/plans/<YYMMDDHH>-<phase>.md`
-- `~/.enact/factory/projects/<key>/plans/<YYMMDDHH>-<phase>-verification.md`
-- Loop state and closure summary via MCP/CLI only (never raw file edits)
-
-## MCP Tools
-
-- `loop_start` — start a new loop with goal and stages
-- `loop_status` — read current loop state
-- `loop_advance` — transition to a new phase
-- `loop_grade` — run a mechanical stage `command` (`stageId` + optional `timeoutMs`); engine-derived pass/fail only
-- `loop_grader_dispatch` — mint `continuationId` and dispatch an independent grader for a judgment stage
-- `loop_grader_verdict` — record GO/NO-GO (driver-relayed default; direct only from registered grader child with valid `continuationId`)
-- `loop_block` — mark blocked with a reason
-- `loop_complete` — close the loop with a summary
-- `loop_abort` — abort with a reason
-
-## Final Check
-
-- Plan artifact exists at `~/.enact/factory/projects/<key>/plans/<YYMMDDHH>-<phase>.md` before loop was started
-- Mechanical stages passed via engine-run `loop_grade` (command exit code), not caller-supplied status
-- Judgment stages have valid independent grader verdicts (minted `continuationId`, driver-relayed or direct with provenance)
-- `$review` verdict is approved
-- `enact-loop summary write` produced a current timestamped closure summary before `loop_complete`
-- `loop_status` shows phase as `completed`

package/extensions/enact-factory/skills/paseo-dispatch/SKILL.md

@@ -1,141 +0,0 @@
----
-name: paseo-dispatch
-description: >-
-  Canonical Enact Factory reference for launching Paseo agents, reviewers,
-  graders, advisors, committees, and handoffs with correct provider/model/mode
-  selection across Codex, Claude Code, Kimi, OpenCode/MiniMax, and Cursor. Use
-  when a skill invokes Paseo, chooses a grader/advisor/committee model, runs
-  factory_paseo_grader_run, needs auto-review/nonblocking review modes, or must
-  prove model-distinct review provenance.
-metadata:
-  author: Amsterdam Data Labs
-  version: 1.0.0
----
-
-# paseo-dispatch
-
-Paseo dispatch is fragile because provider names, model ids, and permission modes
-are not interchangeable. Use this skill whenever factory work launches agents
-through Paseo or records an independent review verdict.
-
-## Discovery First
-
-Before choosing a provider or mode, inspect the live surface:
-
-```bash
-paseo provider ls --json
-paseo provider models <provider> --json
-```
-
-If `~/.paseo/orchestration-preferences.json` exists, read it and treat it as the
-user's preferred role map unless the task explicitly requires a different model.
-Do not assume a model id from old docs when live `paseo provider models` disagrees.
-
-Prefer explicit provider and model flags:
-
-```bash
-paseo run --provider <provider> --model <model-id> --mode <mode> --cwd <repo> "<prompt>"
-```
-
-This keeps provider, model, and permission mode separable. Record the actual
-model from `paseo inspect <id> --json` when a verdict or committee depends on
-independence.
-
-## Review Modes
-
-Use the provider's nonblocking review mode for graders, advisors, and committees.
-The prompt still makes the reviewer read-only; the mode only controls whether
-tool approvals stall the agent.
-
-| Provider | Review mode | Common model ids | Notes |
-|---|---|---|---|
-| `codex` | `--mode auto-review` | `gpt-5.6-sol`, `gpt-5.6-terra`, `gpt-5.6-luna` | Use Sol with `--thinking high` for reviewers/graders; use Terra for heavyweight work and Luna for lightweight fast execution. Never use `bypass`. |
-| `claude` | `--mode auto` | `claude-opus-4-8`, `claude-sonnet-4-6`, `claude-fable-5` | Claude Code's nonblocking review path is Auto mode. Use `--mode plan` only for pure planning where no tool approvals are expected. |
-| `kimi` | `--mode auto` | `kimi-code/kimi-for-coding` | Kimi K2.7 Code supports `--thinking on`; use it for review unless speed matters more. |
-| `opencode` | `--mode plan` for review, `--mode build` for implementation | `minimax-coding-plan/MiniMax-M3`, `opencode-go/kimi-k2.7-code` | MiniMax M3 is a MiniMax model, not an OpenCode model. Every OpenCode/MiniMax M3 dispatch MUST pass `--thinking on`. |
-| `cursor` | `--mode ask` or `--mode plan` for review, `--mode agent` for implementation | provider defaults vary | Do not pass Claude `bypass` to Cursor. Verify modes live before use. |
-
-## Standard Review Commands
-
-Codex Sol High grader:
-
-```bash
-paseo run --provider codex --model gpt-5.6-sol --mode auto-review \
-  --thinking high --cwd "$ROOT" --wait-timeout 10m \
-  --label role=reviewer "<review prompt>"
-```
-
-Claude strong reviewer:
-
-```bash
-paseo run --provider claude --model claude-opus-4-8 --mode auto \
-  --thinking high --cwd "$ROOT" --wait-timeout 10m \
-  --label role=reviewer "<review prompt>"
-```
-
-Kimi K2.7 reviewer:
-
-```bash
-paseo run --provider kimi --model kimi-code/kimi-for-coding --mode auto \
-  --thinking on --cwd "$ROOT" --wait-timeout 10m \
-  --label role=reviewer "<review prompt>"
-```
-
-MiniMax M3 reviewer:
-
-```bash
-paseo run --provider opencode --model minimax-coding-plan/MiniMax-M3 --mode plan \
-  --thinking on --cwd "$ROOT" --wait-timeout 10m \
-  --label role=reviewer "<review prompt>"
-```
-
-## Structured Verdict Capture
-
-For loop judgment stages, prefer `factory_paseo_grader_run`; it wraps
-`paseo run --output-schema --json --wait-timeout`, labels the run with the
-continuation id, and recovers the actual model for `loop_grader_verdict`.
-
-When direct CLI dispatch is required:
-
-```bash
-paseo run --provider <provider> --model <model-id> --mode <review-mode> \
-  --output-schema <verdict-schema.json> --json \
-  --label continuation=<continuationId> --cwd "$ROOT" "<grader prompt>"
-```
-
-Then recover provenance:
-
-```bash
-paseo ls -a --label continuation=<continuationId> --json
-paseo inspect <agent-id> --json
-```
-
-Relay `graderModelActual` exactly as resolved. A claimed GO without the actual
-model is weak evidence.
-
-## Model Choice
-
-Use model-distinct reviewers. For risky decisions, prefer vendor-distinct too.
-
-- Routine judgment: MiniMax M3 (`minimax-coding-plan/MiniMax-M3`, always `--thinking on`) or Kimi K2.7.
-- Strong single advisor or grader: Claude Opus 4.8 when the executor is Codex;
-  GPT-5.6 Sol with `--thinking high` when the executor is Claude/Sonnet;
-  MiniMax/Kimi when cost or breadth matters.
-- Heavyweight implementation and planning: GPT-5.6 Terra. Lightweight focused
-  execution and exploration: GPT-5.6 Luna.
-- Committee: launch two contrasting models. Default strong pair is Claude Opus
-  4.8 plus GPT-5.6 Terra. For a cost-sensitive or extra-breadth committee, use Kimi
-  K2.7 plus MiniMax M3, or add them as extra reviewers.
-- Never grade with the exact executor model/session. If distinct reviewers are
-  unavailable, stop or state reduced diversity loudly.
-
-## Operating Rules
-
-- Use `--label` for traceability: `role=...`, `workItem=...`, `continuation=...`.
-- Use `--wait-timeout` for synchronous review requests; otherwise detach and let
-  Paseo notify on finish.
-- Do not poll running agents. Use `paseo attach <id>` only when live output is
-  needed.
-- Do not restart the Paseo daemon to unstick a run; it kills active agents.
-- Do not confuse implementation modes with review modes. A read-only reviewer in
-  `auto-review` or `auto` is still read-only because of its prompt and role.

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

@@ -1,103 +0,0 @@
----
-name: plan
-description: "Execution-plan mode that turns intent into small, verifiable slices backed by durable global loop artifacts."
----
-
-# Plan
-
-> **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 planning artifacts go under `~/.enact/factory/projects/<key>/…`.
-
-## Purpose
-
-Use `$plan` to create execution-ready slices. The output is not a strategy memo. It is the
-prompt-quality plan that downstream execution can follow without improvising core behavior.
-
-## Use When
-
-- the work is bigger than a one-shot edit
-- the request is clear enough to plan but not yet safe to execute
-- verification, dependencies, or sequencing need to be locked in
-
-## Do Not Use When
-
-- the task is still ambiguous enough for `$deep-interview`
-- the change is a trivial single-file fix
-- the user explicitly wants direct execution and the risk is low
-
-## Execution Policy
-
-- gather repo facts before asking about internals
-- plans are prompts for execution, not prose for humans only
-- every slice must fit in one focused context window
-- every slice must have explicit verification
-- prefer a small number of high-quality slices over a long TODO dump
-- **never overwrite an existing plan artifact in place** — each planning pass writes a new timestamped file
-
-## Timestamped Artifact Naming
-
-All durable factory markdown artifacts use `YYMMDDHH-<slug>.md` where `YYMMDDHH=$(date +%y%m%d%H)` (8 digits, hour granularity).
-
-Examples:
-- `plans/26062203-foundations-hardening.md`
-- `plans/26062203-foundations-hardening-verification.md`
-- `plans/26062203-foundations-hardening-requirements.md`
-- `plans/26062203-foundations-brownfield-map.md`
-- `research/26062203-auth-token-research.md`
-
-Use the **same** `YYMMDDHH` prefix for a plan and its verification map written in the same pass.
-
-## Active Artifact Resolution
-
-When reading (not writing), resolve the latest matching artifact:
-
-1. Prefer the path recorded in the current session/run if one was emitted.
-2. Else pick the lexicographically greatest `YYMMDDHH` among files matching the semantic suffix:
-   - requirements: `*-requirements.md`
-   - plan: `*-{phase}.md` (exclude `-verification` and `-requirements`)
-   - verification: `*-{phase}-verification.md`
-   - brownfield: `*-brownfield-map.md`
-3. If no timestamped file exists, fall back to legacy unprefixed names only for migration reads — never write new unprefixed files.
-
-## Plan Anatomy
-
-Each slice should answer:
-
-- what files are likely to change
-- what the slice must do
-- how to verify it
-- what counts as done
-- what it depends on
-
-## Workflow
-
-1. Read current intent artifacts (latest by rules above):
-   - `~/.enact/factory/projects/<key>/plans/*-requirements.md`
-   - `~/.enact/factory/projects/<key>/plans/*-brownfield-map.md`
-   - any `hyperplan/<sessionId>/` debate bundle from `$hyperplan` when present
-2. Derive the must-haves from the goal backward:
-   - what must be true when this is done?
-   - what artifacts and connections are required for those truths?
-3. Split the work into waves and slices:
-   - interface or contracts first
-   - implementation second
-   - verification and wiring last
-4. Write **new** timestamped artifacts (do not edit prior plan files):
-   - active phase plan
-   - verification map
-   - loop contract stages (mechanical vs. judgment per slice)
-
-## Quality Bar
-
-- no vague acceptance criteria
-- no "make it work" tasks
-- no giant slice that hides three subsystems
-- no verify step that depends on hope
-
-## Deliverables
-
-- `~/.enact/factory/projects/<key>/plans/<YYMMDDHH>-<phase>.md`
-- `~/.enact/factory/projects/<key>/plans/<YYMMDDHH>-<phase>-verification.md`
-- write **new** `~/.enact/factory/projects/<key>/plans/<YYMMDDHH>-<topic>-brownfield-map.md` when the brownfield map changes (append-only; never edit a prior brownfield file in place)

package/extensions/enact-factory/skills/remove-deadcode/SKILL.md

@@ -1,46 +0,0 @@
----
-name: remove-deadcode
-description: "LSP-verified symbol deletion with entry-point guards and candidate-parallel execution."
----
-
-# Remove Deadcode
-
-> **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. Loop artifacts go under `~/.enact/factory/projects/<key>/…`.
-
-## Purpose
-
-Use `$remove-deadcode` to remove provably unused code symbols without damaging runtime entry points.
-
-## Preconditions
-
-- collect candidate symbols before any deletion
-- load optional entry-point guard list from `~/.enact/factory/projects/<key>/remove-deadcode/entry-points.txt`
-
-## Required Safety Contract
-
-For each candidate symbol, the deletion gate is strict:
-
-1. If symbol is listed in the entry-point guard file, skip deletion unconditionally.
-2. Otherwise call `lsp_find_references` (via enact-context).
-3. If references are non-empty, abort deletion for that symbol and emit an explanatory message.
-4. Only delete when references are exactly zero and the symbol is not guarded.
-
-## Execution Model
-
-- batching is explicit: enumerate all candidates first
-- then dispatch parallel `executor` subagents, one candidate per subagent
-- each subagent must apply the same guard-list and `lsp_find_references` checks
-
-## Behavioral Constraints
-
-- no heuristic-only deletion
-- no bypass of entry-point guard list
-- no GitHub-specific assumptions or workflows in deletion decisions
-
-## Verification Expectations
-
-- unit test: non-empty `lsp_find_references` result must refuse deletion
-- unit test: guard-listed symbol must be skipped even when reference count is zero

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

@@ -1,83 +0,0 @@
----
-name: research
-description: "Evidence-first research mode for current patterns, implementation risks, and decision support."
----
-
-# 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>` (e.g. `enact-evolve-a38d1e`).
-> 3. Factory planning artifacts go under `~/.enact/factory/projects/<key>/…`.
-
-## Active Artifact Resolution
-
-When reading prior research, pick the lexicographically greatest `YYMMDDHH` among files in `research/<YYMMDDHH>-*.md`. Never write unprefixed research filenames.
-
-## Purpose
-
-Use `$research` when the correct implementation depends on facts you do not yet have, either from the repo or from current external sources.
-
-## Execution Policy
-
-- start with brownfield evidence from the repo
-- use primary sources for technical questions
-- end with a decision-ready recommendation, not a wall of notes
-- persist findings so the next pass does not repeat the work
-
-## Workflow
-
-1. Identify the actual unknowns.
-2. Separate:
-   - repo truth
-   - external truth
-   - assumptions
-3. Gather only the evidence needed to decide.
-4. Write the result into `~/.enact/factory/projects/<key>/research/<YYMMDDHH>-<kebab-title>.md` (e.g. `research/26062101-auth-token-research.md`). Resolve `<key>` from `~/.enact/workspaces.json` as described in the Storage banner above; get the timestamp prefix via `date +%y%m%d%H`.
-5. Update any linked loop contract or task state if the research is part of an active execution lane.
-
-## Parallel Sweep
-
-Run concurrent research agents for independent evidence lanes. The floor is 2 concurrent agents whenever there are both repo-truth and external-truth unknowns.
-
-- minimum concurrent-agent floor: 2
-- recommended split: one agent for internal repo evidence and one agent for external primary sources
-- increase concurrency only when unknowns are independent and synthesis cost remains manageable
-
-Anti-stop rule: do not stop at the first result. Continue each lane until at least one corroborating source is collected per lane, or until an explicit blocker is documented.
-
-## Runtime Clarification
-
-- `$research` is an evidence pass, not a closure-owning runtime lane.
-- If research output is being used to support closure on a live loop, rely
-  on the real loop proof surfaces rather than treating research notes as
-  equivalent to stage evidence:
-  - `loop_grade({ stageId })` — engine runs the mechanical stage `command`; caller-supplied
-    `status`/`evidence` are rejected
-  - `loop_grader_dispatch` + driver-relayed `loop_grader_verdict` (minted `continuationId`) for judgment stages
-  - `loop_contract_parity` (for contract-parity checks)
-
-## Deliverables
-
-- current pattern or contract summary
-- risk list
-- recommendation with concrete tradeoffs
-- open questions that still block planning or execution
-
-### Internal Evidence
-
-- repo paths inspected
-- commands or tools used
-- concrete findings tied to files, code, or runtime state
-- unresolved internal gaps
-
-### External Evidence
-
-- primary sources consulted
-- dated facts and version-sensitive constraints
-- corroboration across at least one additional source
-- unresolved external gaps
-
-## Activation
-
-Invoke with `$research` or `$enact-loop:research`. This skill is a stateless evidence pass — no durable workflow state is started automatically. If enact-loop MCP tools are available, use them for stage recording that flows from research output — mechanical via `loop_grade({ stageId })`, judgment via dispatched grader + relayed verdict — not by citing research markdown as pass evidence.

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