workflow-supervisor 0.1.0

package/docs/skill-reference.md

@@ -0,0 +1,33 @@
+# Skill Reference
+
+## `workflow-supervisor`
+
+Coordinate explicit supervised or agent-loop workflows. It always starts with a complete intake gate before planning, implementation, goal binding, worker creation, or final disposition. The user must answer every intake item; the supervisor must not infer or skip steps from keywords. After complete intake, it selects either autonomous goal execution or human-in-the-loop execution, then orchestrates named worker threads or subagents from dossiers when the environment supports and authorizes delegation. Loading the skill itself does not spawn workers. It binds Codex goals only after complete intake and when the user or environment authorizes goal-oriented work, checks active goal state first, and avoids unrelated active-goal collisions.
+
+## `source-corpus`
+
+Rank and reconcile sources when authority, freshness, contradictions, access rights, or evidence gaps change the safe next action. It supports `allowed_next_action`: discovery, provisional draft, production change, or blocked.
+
+## `work-unit`
+
+Split broad work into bounded units with objective, scope, dependencies, readiness, done criteria, verification, sequencing, and parallel-safety notes.
+
+## `dossier-builder`
+
+Create a handoff contract for one already-bounded work unit. Use it for another agent, thread, future session, or formal worker prompt, not ordinary same-thread direct work. Dossiers can include deterministic thread names, start conditions, handoff messages, checkpoints, and report schemas.
+
+## `worker-roles`
+
+Define role contracts and solo-mode phase separation. It prevents role bleed: verifiers editing implementation, implementers self-approving, repair authors inventing scope, and documenters turning unresolved questions into facts.
+
+## `acceptance-matrix`
+
+Create formal evidence-mapped acceptance rows for high-risk, supervised, ambiguous, resumable, or handoff workflows.
+
+## `loop-policy`
+
+Define execution path, execution mode, thread or subagent orchestration, approval gates, repair limits, parallel safety, no-progress rules, and Codex goal tool policy.
+
+## `workflow-docs`
+
+Create durable workflow-state or documentation-production artifacts. Markdown artifacts default to `<workspace>/.workflow/` unless the user or project convention says otherwise. It also supports inline briefs, tickets, design annotations, runbooks, decision logs, and other usable state media.

package/docs/troubleshooting.md

@@ -0,0 +1,38 @@
+# Troubleshooting
+
+## The skills trigger too often
+
+Keep `policy.allow_implicit_invocation: false`. Use explicit `$skill-name` invocation until live routing tests prove trigger precision.
+
+## The agent cannot find the skills
+
+Run:
+
+```bash
+workflow-skills doctor --agent codex
+workflow-skills install --agent generic --target ./agent-skills --dry-run
+```
+
+Then verify the target directory contains folders such as `workflow-supervisor/SKILL.md`.
+
+## Goal tools are unavailable
+
+Use `.workflow/GOAL-STATE.md` or a workflow handoff document. The supervisor skill explicitly falls back to workflow docs when goal tools are unavailable or not permitted.
+
+## Too many docs are created
+
+Use `$workflow-docs` with a minimal artifact request. The skill must reject "create every document just in case."
+
+## Verification rubber-stamps the result
+
+Use `$acceptance-matrix` for formal evidence rows. A PASS requires row-by-row evidence or explicit waiver evidence.
+
+## An existing skill folder blocks install
+
+Use:
+
+```bash
+workflow-skills install --agent codex --force
+```
+
+Use `--dry-run` first if you want to inspect the target.

package/package.json

@@ -0,0 +1,45 @@
+{
+  "name": "workflow-supervisor",
+  "version": "0.1.0",
+  "description": "Installable workflow supervision skills for Codex, Claude Code, OpenCode, HermesAgent, and generic agent workspaces.",
+  "type": "module",
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/NikolaCehic/workflow-supervisor.git"
+  },
+  "bugs": {
+    "url": "https://github.com/NikolaCehic/workflow-supervisor/issues"
+  },
+  "homepage": "https://github.com/NikolaCehic/workflow-supervisor#readme",
+  "bin": {
+    "workflow-supervisor": "bin/workflow-skills",
+    "workflow-skills": "bin/workflow-skills"
+  },
+  "files": [
+    "skills",
+    "adapters",
+    "docs",
+    "assets",
+    "bin",
+    "README.md",
+    "LICENSE"
+  ],
+  "scripts": {
+    "test": "node --test tests/*.test.mjs",
+    "validate": "node ./bin/workflow-skills.mjs validate && npm test",
+    "prepublishOnly": "npm run validate"
+  },
+  "keywords": [
+    "codex",
+    "claude-code",
+    "opencode",
+    "hermesagent",
+    "skills",
+    "workflow",
+    "agent"
+  ],
+  "license": "MIT",
+  "engines": {
+    "node": ">=18"
+  }
+}

package/skills/acceptance-matrix/SKILL.md

@@ -0,0 +1,77 @@
+---
+name: acceptance-matrix
+description: Convert requirements into formal, evidence-mapped acceptance criteria only for supervised, high-risk, ambiguous, resumable, or handoff workflows. Use when verification must map each requirement to evidence, adversarial cases, PASS/FAIL/BLOCKED states, review states, and residual risk. Do not use for ordinary code review, small scoped edits, routine test runs, trivial explicit acceptance, or declaring completion unless the user asks for an acceptance matrix or evidence-mapped verification.
+---
+
+# Acceptance Matrix
+
+Use this skill to define what counts as done and what evidence proves it.
+
+## Ownership Boundary
+
+This skill owns evidence rows and supervisor verdict mapping. `$work-unit` may draft coarse done criteria, `$dossier-builder` may embed or reference rows, and `$workflow-docs` may preserve the matrix. Those skills should not reinterpret evidence or silently change verdicts.
+
+## Matrix Rules
+
+- Every requirement needs evidence.
+- Evidence must name a source, command, artifact, UI state, test, inspection, or user decision.
+- PASS requires all material rows to be satisfied or explicitly waived by the user.
+- FAIL requires at least one material row with unmet evidence.
+- BLOCKED applies when evidence cannot be obtained or sources conflict.
+- Residual risks must not be hidden inside PASS.
+
+## Row Shape
+
+| ID | Requirement | Evidence Required | Verification Method | Adversarial Check | Status | Evidence |
+|---|---|---|---|---|---|---|
+
+Use statuses: Pending, PASS, FAIL, BLOCKED, Waived.
+
+For documentation and review workflows, also record a domain-specific review state when useful: Needs Revision, Approved With Caveats, Ready To Publish, SME Review Needed, Legal Review Needed, Stale, or Deferred. Map it back to PASS/FAIL/BLOCKED for supervisor decisions.
+
+## Adversarial Checks
+
+Consider:
+
+- malformed or missing input
+- stale source or version mismatch
+- unauthorized capability
+- schema or contract drift
+- unsupported kind or mode
+- no-op implementation
+- hardcoded fixture output
+- hidden network or filesystem dependency
+- ambiguous user approval
+- skipped required check
+- missing citation or unsupported claim
+- document structure regression
+- stakeholder requirement omitted
+- artifact cannot be reused by a fresh agent or human
+
+## Verification Report Shape
+
+```yaml
+status: PASS|FAIL|BLOCKED
+verified_work_unit:
+verified_thread:
+matrix:
+  - id:
+    requirement:
+    status:
+    evidence:
+    verification_method:
+    finding:
+findings:
+residual_risks:
+skipped_checks:
+repair_recommendations:
+reverify_required: true|false
+```
+
+Repair recommendations must link to the failed or blocked matrix row ID. Do not recommend repairs for requirements that were not in scope unless the verifier first records a separate scope gap.
+
+After repairs, verification must rerun against the affected rows and any regression rows. The supervisor may mark the workflow green only when material rows are PASS or explicitly waived with evidence.
+
+## Rubber-Stamp Guard
+
+Reject verification that says only "looks good", "tests pass", or "implemented" without row-by-row evidence. Ask for exact evidence or mark BLOCKED.

package/skills/acceptance-matrix/agents/openai.yaml

@@ -0,0 +1,7 @@
+interface:
+  display_name: "Acceptance Matrix"
+  short_description: "Turn goals into verifiable criteria"
+  default_prompt: "Use $acceptance-matrix to define evidence-backed pass, fail, and blocked criteria."
+
+policy:
+  allow_implicit_invocation: false

package/skills/dossier-builder/SKILL.md

@@ -0,0 +1,93 @@
+---
+name: dossier-builder
+description: Create a concrete handoff contract only when one already-bounded work unit needs a dossier for another agent, thread, future session, formal worker prompt, or durable handoff. Use when objective, sources, boundaries, acceptance rows, checks or evidence, stop gates, thread naming, start conditions, and report schemas must be captured before delegation. Do not use to plan work Codex will perform directly in the current turn, for unbounded work, or for ordinary same-thread implementation.
+---
+
+# Dossier Builder
+
+Use this skill to prevent vague handoffs. A dossier is the contract between the supervisor and a worker.
+
+## Domain Neutral Inputs
+
+Use repository fields only when the task is repository-shaped. For documentation, research, design, operations, or planning work, translate "surface" into the relevant mutable artifact: document section, source set, decision area, dataset, prompt, workflow, design, or deliverable.
+
+For documentation production, the dossier may be a content brief. It should name audience, reader task, document type, required sections, source requirements, tone, reviewers, publication target, and maintenance needs.
+
+The dossier does not own acceptance design. It references or embeds acceptance rows produced by `$acceptance-matrix`, or marks acceptance as draft when rows still need evidence.
+
+## Required Inputs
+
+- bounded work unit
+- source corpus or source list
+- known allowed and forbidden surfaces or artifacts
+- acceptance criteria or acceptance draft
+- required checks or evidence
+- worker role and report expectations
+
+If these inputs are missing, create a discovery dossier or return BLOCKED.
+
+For early discovery, the only source may be conversation context and the only allowed surface may be a planned brief, doc, or question list. Do not require repository paths or existing files.
+
+Use a provisional dossier for low-risk drafts, plans, outlines, rubrics, and options when sources are thin but the output can clearly mark assumptions. Use BLOCKED for factual, irreversible, regulated, publication, or production changes that lack material sources or boundaries.
+
+## Dossier Shape
+
+```yaml
+workflow:
+work_unit:
+dossier_id:
+thread_name:
+thread_role:
+start_condition:
+title:
+objective:
+non_goals:
+source_corpus:
+must_read:
+allowed_surfaces:
+forbidden_surfaces:
+read_only_neighbors:
+work_points:
+audience:
+reader_task:
+document_type:
+publication_target:
+reviewers:
+acceptance_matrix:
+adversarial_checks:
+required_commands_or_evidence:
+worker_role:
+handoff_message:
+supervisor_checkpoints:
+completion_report_schema:
+verification_report_schema:
+stop_gates:
+assumptions:
+open_questions:
+```
+
+## Handoff Rules
+
+- Name exact files, docs, systems, or artifact paths when available.
+- Prefer concrete boundaries over broad module names.
+- Include forbidden surfaces even when the worker seems trustworthy.
+- Convert unknowns into open questions, not hidden assumptions.
+- Include adversarial checks for malformed input, stale state, authorization, schema drift, replay, no-op implementation, and untrusted sources when relevant.
+- Require workers to report skipped checks and assumptions.
+- For non-code work, use evidence such as citations, before/after excerpts, review rubrics, examples, artifact diffs, or explicit user decisions instead of commands.
+- Require repair tickets to cite the verification finding or acceptance row they repair.
+- Include a deterministic `thread_name` when delegation is planned. Use `wf/<workflow-slug>/<unit-id>-<role>-<dossier-slug>`.
+- Include `start_condition`, such as `after path gate`, `after human plan approval`, `after autonomous execution plan`, `after implementer report`, `after verification FAIL`, or `after repairs complete`.
+- Include a ready-to-send `handoff_message` that contains only the worker's role, dossier, sources, acceptance rows, stop gates, and report schema.
+- Include supervisor checkpoints for kickoff acknowledgement, blocker questions, terminal report, and closeout.
+
+## Failure Modes
+
+Return BLOCKED rather than producing a dossier when:
+
+- material sources are absent or contradictory for the proposed next action
+- the work unit is unbounded and cannot be converted into discovery or provisional drafting
+- allowed and forbidden surfaces cannot be named
+- acceptance cannot be verified
+- the worker role would need to make product decisions
+- a waiver or approval is remembered but not evidenced by a user decision, artifact, or source

package/skills/dossier-builder/agents/openai.yaml

@@ -0,0 +1,7 @@
+interface:
+  display_name: "Dossier Builder"
+  short_description: "Create concrete thread handoff contracts"
+  default_prompt: "Use $dossier-builder to create a grounded handoff dossier with thread name, start condition, and report schema for this work unit."
+
+policy:
+  allow_implicit_invocation: false

package/skills/loop-policy/SKILL.md

@@ -0,0 +1,103 @@
+---
+name: loop-policy
+description: Define execution policy only for supervised, multi-agent, multi-thread, long-running, resumable, autonomous-goal, human-in-loop, approval-gated, or repair-loop workflows. Use for execution path selection, sequential or parallel execution, thread orchestration, retry and repair limits, budgets, escalation, Codex goal binding, blocking rules, continuation criteria, and no-progress detection. Do not use for one failing command, normal retrying, routine user approval, or a one-shot task with obvious completion.
+---
+
+# Loop Policy
+
+Use this skill to decide how the workflow moves before the loop starts.
+
+## No-Prerequisite Rule
+
+The policy must not require a repository, test suite, issue tracker, or documentation folder unless the task itself does. When prerequisites are missing, choose discovery-first mode or require a lightweight intake artifact before production work.
+
+## Goal Policy
+
+For loop-oriented supervisor work, define how the workflow uses Codex goals after complete intake is satisfied:
+
+- goal_start: create, reuse, skip, or ask
+- execution_path: `autonomous_goal` or `human_in_loop`, from completed intake only
+- codex_goal_tool_actions: `get_goal` at start/resume, `create_goal` at most once when explicitly allowed, `update_goal` only for terminal complete or blocked
+- goal_state_mirror_cadence: each work unit, each verification result, each repair loop, and final outcome
+- goal_completion_rule: evidence required before completion
+- goal_blocked_rule: same material blocker across the required consecutive goal turns and no meaningful progress
+- goal_resume_rule: read active goal before workflow docs, then reconcile
+
+Do not create goals for small direct tasks. A goal is the state container for open-ended loops, not a wrapper around every command.
+
+## Policy Dimensions
+
+- Intake: whether every required intake decision has an explicit user answer, and which unanswered items must be re-asked before any work can start.
+- Execution path: autonomous_goal or human_in_loop, from completed intake only.
+- Mode: sequential, parallel, staged parallel, or discovery-first, from completed intake only.
+- Approval: none, before thread creation, before implementation, before verification, before repair, before publication, before irreversible action, before each unit, or path-gated.
+- Delegation orchestration: thread or subagent availability, naming scheme, spawn timing, supervisor checkpoint cadence, terminal report collection, and fallback when delegation tools are unavailable.
+- Repair limit: maximum repair loops per unit.
+- Budget: time, token, command, cost, or file-change limits.
+- Escalation: when to ask the user, spawn a specialist, or stop.
+- Completion: evidence required before marking done.
+- Resume: artifacts needed before pausing or compacting.
+- Mutation conflict: whether units touch the same mutable surfaces or decisions.
+
+## Default Policy
+
+Use this default unless the task says otherwise:
+
+```yaml
+intake_required_when: every supervisor invocation before goal creation, planning beyond intake, thread or subagent creation, implementation, verification, repair, final disposition, publication, or irreversible action
+intake_question_count: ask the complete intake packet first; on follow-up ask every unanswered or ambiguous item
+required_intake_decisions: objective_and_source, execution_path, mode, delegation, final_disposition, mutation_boundaries, state_artifacts
+use_judgment_defaults: none; user must answer every required intake decision explicitly
+keyword_shortcuts: forbidden; do not infer path, mode, delegation, final disposition, or boundaries from prompt keywords
+mode: from completed intake only
+execution_path: from completed intake only
+approval_gate: path-gated; complete intake before any path-specific plan; human approval for human_in_loop plans; explicit completed-intake authorization for autonomous_goal; explicit completed-intake authorization for irreversible or user-visible publication
+repair_limit_per_unit: 2
+parallel_allowed_when: units do not share mutable surfaces
+thread_spawn_rule: after complete intake, path gate, and concrete dossier
+subagent_spawn_rule: after complete intake, path gate, and concrete dossier when the environment exposes subagent tools
+thread_name_template: wf/<workflow-slug>/<unit-id>-<role>-<dossier-slug>
+supervisor_checkpoint_cadence: after handoff acknowledgement, terminal report, repair ticket creation, re-verification, and final disposition
+final_disposition_policy: from completed intake only; if set to ask_at_end, stop and ask at final disposition
+workflow_unit_blocked_after: first material blocker may stop the unit while the Codex goal remains active
+codex_goal_blocked_after: same material blocker across 3 consecutive goal turns and no meaningful progress
+completion_requires: acceptance evidence plus residual risk report
+resume_requires: handoff or outcome doc for long workflows
+missing_prerequisites: discovery-first, not failure
+goal_start: after complete intake only; create only when completed intake and environment authorize goal binding, otherwise mirror state in docs
+goal_state_mirror_cadence: after unit terminal states and final outcome
+```
+
+## No-Progress Detection
+
+Treat the loop as no-progress when:
+
+- the same missing input recurs
+- repairs do not address verifier findings
+- verification repeats without new evidence
+- scope keeps expanding to avoid completion
+- checks cannot run and no substitute evidence exists
+
+## Parallel Safety
+
+Do not run units in parallel when they edit the same files, documents, datasets, decisions, workflows, design surfaces, or publication artifacts. If overlap is unclear, run sequentially or create a discovery unit to map ownership first.
+
+## Output Shape
+
+```yaml
+workflow:
+intake:
+execution_path:
+mode:
+approval_gates:
+delegation_policy:
+repair_limit:
+parallel_rules:
+budgets:
+escalation_rules:
+stop_gates:
+completion_rule:
+resume_artifacts:
+goal_policy:
+final_disposition_policy:
+```

package/skills/loop-policy/agents/openai.yaml

@@ -0,0 +1,7 @@
+interface:
+  display_name: "Loop Policy"
+  short_description: "Control path, threads, retries, and gates"
+  default_prompt: "Use $loop-policy to enforce complete intake before work starts, forbid keyword shortcuts, require explicit user answers for every intake field, then define execution path, delegation, retry, approval, and stopping rules."
+
+policy:
+  allow_implicit_invocation: false

package/skills/source-corpus/SKILL.md

@@ -0,0 +1,92 @@
+---
+name: source-corpus
+description: Identify, rank, and reconcile sources of truth only when choosing, ranking, or reconciling authoritative sources is material to whether work can proceed. Use when source authority, freshness, contradictions, access rights, citation requirements, or evidence gaps change the safe next action. Do not use for routine citation gathering, straightforward file inspection, simple web lookup, ordinary repo inspection for a scoped change, self-contained answers, or obvious uncontested source grounding.
+---
+
+# Source Corpus
+
+Use this skill to turn scattered context into a source map that a workflow can trust.
+
+## No-Prerequisite Mode
+
+Do not assume a repository, wiki, ticket tracker, or documentation folder exists. If the only available source is the user's prompt, classify it as conversation context and mark missing sources explicitly.
+
+Use `allowed_next_action` instead of treating missing sources as a universal block:
+
+- `discovery_only`: enough to ask questions or gather sources
+- `provisional_draft`: enough for a low-risk draft, outline, rubric, plan, or options list with assumptions marked
+- `production_change`: enough for a material edit, implementation, publication, or decision
+- `blocked`: not enough because the next action would make factual, irreversible, regulated, or high-risk claims
+
+Block only when the missing source is material to the proposed next action.
+
+## Source Classes
+
+- Primary executable: code, tests, schemas, configs, fixtures, generated lockfiles.
+- Primary written: product specs, RFCs, architecture docs, contracts, tickets with owner decisions.
+- Operational evidence: logs, CI output, metrics, customer reports, previous run artifacts.
+- Conversation context: user instructions, chat summaries, design decisions.
+- Created artifacts: drafts, outlines, diagrams, slide decks, spreadsheets, screenshots, prototypes, decision records.
+- External references: web docs, standards, vendor docs. Verify freshness when unstable.
+- Inference: model reasoning from sources. Mark clearly as inference, not evidence.
+
+For documentation work, also capture source owner, access constraints, usage rights, citation requirement, confidentiality, last reviewed date, coverage, and review risk when known.
+
+## Ranking Rules
+
+Rank each source by:
+
+- authority: who or what owns the truth
+- proximity: how close it is to the behavior or decision
+- freshness: whether it may have changed
+- specificity: whether it directly addresses the task
+- executability: whether it can be tested or inspected
+- conflict risk: whether another source disagrees
+
+Prefer executable repo reality over stale prose for current behavior. Prefer explicit user constraints over inferred product intent.
+For documentation, research, design, and planning workflows, prefer the artifact under revision and explicit stakeholder instructions over generic best practices.
+
+## Process
+
+1. List candidate sources and how they were found.
+2. Classify each source.
+3. Read the minimum authoritative set before recommending action.
+4. Identify missing sources and whether they block progress.
+5. Detect contradictions and label them material or non-material.
+6. Extract only task-relevant claims.
+7. Produce a source corpus map with evidence gaps.
+
+## Output Shape
+
+```yaml
+objective:
+sources:
+  - path_or_ref:
+    class:
+    authority:
+    freshness:
+    relevant_claims:
+    owner:
+    access:
+    usage_rights:
+    citation_needed:
+    last_reviewed:
+    coverage:
+    risk:
+    confidence:
+missing_sources:
+contradictions:
+  - source_a:
+    source_b:
+    issue:
+    material: true|false
+evidence_gaps:
+must_read_before_action:
+safe_to_proceed: true|false
+allowed_next_action: discovery_only|provisional_draft|production_change|blocked
+blocking_question:
+```
+
+## Stop Gates
+
+Stop when the task depends on a source that is missing, inaccessible, contradicted by a higher-authority source, or likely stale and unstable. Continue only if the missing source is non-material and the output states the assumption.

package/skills/source-corpus/agents/openai.yaml

@@ -0,0 +1,7 @@
+interface:
+  display_name: "Source Corpus"
+  short_description: "Rank and reconcile sources of truth"
+  default_prompt: "Use $source-corpus to map and reconcile the sources of truth for this task."
+
+policy:
+  allow_implicit_invocation: false

package/skills/work-unit/SKILL.md

@@ -0,0 +1,72 @@
+---
+name: work-unit
+description: Decompose fuzzy or broad objectives into bounded, sequenced, verifiable work units. Use when a task is too large, ambiguous, multi-phase, dependency-heavy, or risky to execute as one edit; when a supervisor needs packets, milestones, slices, tickets, or agent handoffs; or when scope must be narrowed before implementation. Do not use for already-small tasks with clear files and acceptance.
+---
+
+# Work Unit
+
+Use this skill to make work small enough that another agent can complete and verify it without guessing.
+
+## Boundary Types
+
+Work units can be bounded by code package, document section, source set, stakeholder decision, research question, design screen, workflow step, data slice, risk class, or output artifact. Do not force repository terminology onto non-code work.
+
+## Unit Quality Bar
+
+A good work unit has:
+
+- one objective
+- a stable unit ID suitable for dossier and thread naming
+- named dependencies
+- explicit in-scope and out-of-scope surfaces
+- known sources or source gaps
+- readiness criteria
+- done criteria
+- verification strategy
+- estimated sequencing position
+- a stop condition
+
+Reject units that are just themes, vague phases, or lists of unrelated work.
+
+Work-unit drafts coarse done criteria only. Use `$acceptance-matrix` when those criteria need evidence rows, PASS/FAIL/BLOCKED mapping, or adversarial verification.
+
+## Decomposition Process
+
+1. Restate the parent objective.
+2. Identify natural boundaries: user workflow, package, document, API contract, risk class, or dependency layer.
+3. Split into units that can be verified independently.
+4. Mark dependencies and ordering constraints.
+5. Mark which units can run in parallel only when they do not mutate the same surfaces.
+6. Define readiness and done criteria for each unit.
+7. If sources are absent, create a discovery/intake unit before production work.
+8. Identify the first unit that is safe to dossier.
+
+For over-broad one-pass requests, produce a sequencing recommendation and invoke or mirror `$loop-policy` fields for mode, parallel safety, approval gates, and repair limits.
+
+## Output Shape
+
+```yaml
+parent_objective:
+units:
+  - id:
+    thread_slug:
+    title:
+    objective:
+    in_scope:
+    out_of_scope:
+    dependencies:
+    sources_needed:
+    allowed_surfaces:
+    forbidden_surfaces:
+    readiness:
+    done_criteria:
+    verification:
+    sequence:
+parallel_groups:
+blocked_units:
+first_recommended_unit:
+```
+
+## Stop Gates
+
+Stop when a unit cannot name a done criterion, required source, or boundary. Ask for a decision or return a smaller discovery unit.

package/skills/work-unit/agents/openai.yaml

@@ -0,0 +1,7 @@
+interface:
+  display_name: "Work Unit"
+  short_description: "Decompose fuzzy goals into bounded units"
+  default_prompt: "Use $work-unit to split this goal into bounded, verifiable work units."
+
+policy:
+  allow_implicit_invocation: false