@g3nomaly/skills 1.0.0 → 1.0.1

package/dist/plugins/using-hooks/skills/hook-post-tool-use/SKILL.md

@@ -1,79 +0,0 @@
----
-name: hook-post-tool-use
-description: Writing a PostToolUse lifecycle hook — the one that reacts to a finished tool call and can feed the result back to the agent.
-registryDependencies: [writing-great-hooks]
-disable-model-invocation: true
----
-
-Shared rules for every hook — the invariants, the script mechanics, registration: [`writing-great-hooks`](../writing-great-hooks/SKILL.md).
-
-`PostToolUse` fires immediately after a tool has run. **The work is already done** — nothing this hook returns can undo it. What it can do is see the result and put a consequence in front of the agent, which makes it the event for verification, bookkeeping, and anything that must happen _because_ a file changed.
-
-## Payload
-
-The four common fields, the call, and what came back:
-
-```json
-{
-  "session_id": "abc123",
-  "transcript_path": "/home/you/.claude/projects/<slug>/<session>.jsonl",
-  "cwd": "/home/you/project",
-  "hook_event_name": "PostToolUse",
-  "tool_name": "Edit",
-  "tool_input": { "file_path": "/home/you/project/src/index.ts", "old_string": "…", "new_string": "…" },
-  "tool_response": { "filePath": "/home/you/project/src/index.ts", "success": true }
-}
-```
-
-`tool_input` and `tool_response` are both shaped by the tool. Branch on `tool_name` before reading either.
-
-## Matcher
-
-Same tool-name regex as [`hook-pre-tool-use`](../hook-pre-tool-use/SKILL.md), and the same reason to keep it tight:
-
-```json
-{
-  "matcher": "Edit|MultiEdit|Write",
-  "hooks": [{ "type": "command", "command": "$CLAUDE_PROJECT_DIR/.claude/hooks/format-edited-file.ts" }]
-}
-```
-
-## What the exit code does
-
-- **`0` — nothing further happens.** stdout goes to the transcript, not to the agent.
-- **`2` — stderr is fed to the agent** as something it must address. The tool result still stands; this is a correction, not a rollback.
-- **anything else** — a non-blocking error; stderr goes to the user.
-
-The JSON form does the same job with a reason attached:
-
-```json
-{
-  "decision": "block",
-  "reason": "tsc reported 2 errors in src/index.ts:\n  L14 Property 'id' does not exist on type 'Order'\n  L22 Object is possibly 'undefined'"
-}
-```
-
-To hand the agent information without framing it as a failure, use `hookSpecificOutput.additionalContext` instead — it lands in context without asserting that something went wrong.
-
-_Return the diagnostic, not the fact of it._ "Typecheck failed" costs the agent a whole turn rediscovering what this hook already knew; the compiler's actual lines let it fix the problem immediately.
-
-## What it is for
-
-- **Formatting and linting what was just edited** — the deterministic pass that should never be a request in prose.
-- **Typechecking the touched file** and returning the errors, so a broken edit is corrected in the same turn it was made.
-- **Tracking what changed.** Recording edited paths gives later turns, and a `Stop` hook, something concrete to act on.
-- **Feeding back a consequence the agent cannot see** — a failing test, a schema that no longer matches, a generated file now stale.
-
-## What it is not for
-
-**Do not use it to prevent anything.** The tool has run; a hook that reads like a guard here is a guard that arrives too late. Prevention is [`hook-pre-tool-use`](../hook-pre-tool-use/SKILL.md).
-
-Be careful making it write. A hook that reformats the file the agent just edited changes content the agent believes it knows, and the next edit is built on a stale picture. Either keep the rewrite small and mechanical, or report instead of rewriting.
-
-## Failure modes
-
-- _Whole-project work on one file's event._ Typechecking the entire monorepo because one file changed. It fires on every edit; scope it to `tool_input.file_path` or don't do it here.
-- _Verdict without evidence._ Blocking with "lint failed" and swallowing the output. The agent has to re-run the tool it can't see to learn what this hook already had.
-- _Silent rewrite._ Reformatting the edited file and returning `0`. The agent's next edit targets text that no longer exists, and the failure looks like the agent's mistake.
-- _Blocking on the expected._ Returning `decision: "block"` for a condition that is normal mid-task — a half-written module that doesn't typecheck yet. The agent is dragged into fixing something it was already about to finish.
-- _Assuming success._ Reading `tool_response` without checking whether the call actually succeeded, then reporting failures caused by a tool that never ran.

package/dist/plugins/using-hooks/skills/hook-post-tool-use/agents/openai.yaml

@@ -1,5 +0,0 @@
-interface:
-  display_name: "Hook: PostToolUse"
-  short_description: "React to a finished tool call and feed the result back"
-policy:
-  allow_implicit_invocation: false

package/dist/plugins/using-hooks/skills/hook-pre-tool-use/SKILL.md

@@ -1,84 +0,0 @@
----
-name: hook-pre-tool-use
-description: Writing a PreToolUse lifecycle hook — the one that can allow, deny, or escalate a tool call before it runs.
-registryDependencies: [writing-great-hooks]
-disable-model-invocation: true
----
-
-Shared rules for every hook — the invariants, the script mechanics, registration: [`writing-great-hooks`](../writing-great-hooks/SKILL.md).
-
-`PreToolUse` fires after the agent has chosen a tool and filled in its arguments, but **before the tool runs**. It is the only event that can stop an action from happening at all, which makes it the place for guardrails and policy, and the wrong place for anything that merely wants to observe.
-
-## Payload
-
-The four common fields, plus the call about to be made:
-
-```json
-{
-  "session_id": "abc123",
-  "transcript_path": "/home/you/.claude/projects/<slug>/<session>.jsonl",
-  "cwd": "/home/you/project",
-  "hook_event_name": "PreToolUse",
-  "tool_name": "Write",
-  "tool_input": { "file_path": "/home/you/project/src/index.ts", "content": "…" }
-}
-```
-
-`tool_input` is shaped by the tool, so a hook matching more than one tool must branch on `tool_name` before reading a field. Never assume `file_path` exists.
-
-## Matcher
-
-This event selects by tool name, as a regex:
-
-```json
-{
-  "matcher": "Edit|MultiEdit|Write",
-  "hooks": [{ "type": "command", "command": "$CLAUDE_PROJECT_DIR/.claude/hooks/guard-protected-paths.ts" }]
-}
-```
-
-Omit `matcher` to see every tool call. **Scope it as tightly as the rule allows** — an unmatched hook is a process spawned on every tool call for the life of the session.
-
-## What the exit code does
-
-- **`0` — the call proceeds.** stdout goes to the transcript, not to the agent.
-- **`2` — the call is denied**, and stderr is fed to the agent as the reason. This is the veto, and the agent can read the reason and try something else.
-- **anything else** — a non-blocking error: the call still runs, and stderr goes to the user.
-
-For the full decision, print JSON and exit `0`:
-
-```json
-{
-  "hookSpecificOutput": {
-    "hookEventName": "PreToolUse",
-    "permissionDecision": "deny",
-    "permissionDecisionReason": "src/generated/ is written by `bun run codegen`. Edit the template instead."
-  }
-}
-```
-
-- **`allow`** runs the call and skips the permission prompt the user would otherwise see.
-- **`deny`** blocks it and hands the reason to the agent.
-- **`ask`** puts it to the user, whatever the current permission mode would have done.
-
-_Write the reason to the agent, not to a log._ It is the only thing the agent gets, and a good one turns a dead end into a corrected second attempt: name what was refused and what to do instead.
-
-## What it is for
-
-- **Protecting paths and resources** — generated directories, lockfiles, anything with a real source elsewhere.
-- **Steering to the project's own tooling.** This repo registers a `PreToolUse` guard on `Bash|Grep` and `Read|Glob` that pushes the agent to query the graph before raw searching — policy that would otherwise be a paragraph of prose the agent may or may not honour.
-- **Pre-flight validation** — refusing a command whose arguments are malformed, out of scope, or aimed outside the project.
-
-## What it is not for
-
-**Do not put a slow check here.** Every matching tool call waits on it, and the agent is idle while it runs. Verification of a result belongs in [`hook-post-tool-use`](../hook-post-tool-use/SKILL.md), which pays its cost after the work rather than in front of it.
-
-Nor should it encode judgement. A hard rule — this path is generated, that command is forbidden — is a guardrail. "Is this edit a good idea" is not, and hardcoding it produces a veto nobody can see or argue with.
-
-## Failure modes
-
-- _Blanket matcher._ No `matcher`, or `.*`, for a rule that concerns two tools. Every call in the session now pays for it.
-- _Wrong field, wrong tool._ Reading `tool_input.file_path` on a `Bash` call, getting `undefined`, and treating that as "not a protected path". Branch on `tool_name` first, and fail closed when the shape is unfamiliar.
-- _Reasonless denial._ Exit `2` with an empty stderr, or a JSON `deny` with no `permissionDecisionReason`. The agent knows only that it was stopped, so it retries the same thing.
-- _Path comparison by string._ Matching `"src/generated"` against a raw argument, which `./src/../src/generated` and an absolute path both defeat. Resolve, then compare.
-- _Shell interpolation._ Pasting a payload field into a shell command. The agent's arguments reach a shell running with the user's credentials.

package/dist/plugins/using-hooks/skills/hook-pre-tool-use/agents/openai.yaml

@@ -1,5 +0,0 @@
-interface:
-  display_name: "Hook: PreToolUse"
-  short_description: "Allow, deny, or escalate a tool call before it runs"
-policy:
-  allow_implicit_invocation: false

package/dist/plugins/using-hooks/skills/hook-stop/SKILL.md

@@ -1,69 +0,0 @@
----
-name: hook-stop
-description: Writing a Stop lifecycle hook — the one that can refuse to let the agent end its turn, and the one that can loop forever if written carelessly.
-registryDependencies: [writing-great-hooks]
-disable-model-invocation: true
----
-
-Shared rules for every hook — the invariants, the script mechanics, registration: [`writing-great-hooks`](../writing-great-hooks/SKILL.md).
-
-`Stop` fires when the agent is about to finish its response. Its power is refusal: exit `2` and the turn does not end — the agent reads your reason and keeps working. That makes it the place for "not done until…" conditions, and the one event that can trap a session in a loop.
-
-It takes **no matcher**. `SubagentStop` is the sibling event for subagents finishing, and needs its own registration.
-
-## Payload
-
-The four common fields, plus the loop guard:
-
-```json
-{
-  "session_id": "abc123",
-  "transcript_path": "/home/you/.claude/projects/<slug>/<session>.jsonl",
-  "cwd": "/home/you/project",
-  "hook_event_name": "Stop",
-  "stop_hook_active": false
-}
-```
-
-**`stop_hook_active` is `true` when the agent is only still running because this hook already blocked it.** Check it first and let the stop through when it is set. Without that guard, a condition the agent cannot satisfy — a test failing for an unrelated reason, a check with a bug — blocks, prompts, blocks again, and never terminates.
-
-```ts
-if (payload.stop_hook_active) process.exit(0);
-```
-
-## What the exit code does
-
-- **`0` — the turn ends** as it was going to.
-- **`2` — the agent is not allowed to stop**, and stderr becomes its instruction for what to do next.
-- **anything else** — a non-blocking error; the turn ends and stderr goes to the user.
-
-The JSON form requires the reason, because the reason _is_ the next instruction:
-
-```json
-{
-  "decision": "block",
-  "reason": "bun test failed in packages/core: 2 failing in tests/registry/io.test.ts. Fix these before finishing."
-}
-```
-
-A blocked stop with a vague reason is worse than no hook: the agent knows only that it may not stop, so it produces filler and tries again.
-
-## What it is for
-
-- **Refusing to finish over a broken build** — a failing typecheck or test suite in the package that was touched this turn.
-- **Enforcing a completion criterion the agent tends to skip** — the changelog entry, the regenerated artifact, the doc updated alongside the code.
-- **Closing the loop on tracked work**, using the paths a [`hook-post-tool-use`](../hook-post-tool-use/SKILL.md) hook recorded, so the check only covers what actually changed.
-
-## What it is not for
-
-**Do not use it as a chore runner.** Blocking is expensive — it spends a full turn of the agent's attention and the user's time. If the work is mechanical and does not need the agent's judgement, do it in the hook and exit `0`.
-
-And keep it cheap on the common path. It runs at the end of every turn, including the ones that only answered a question; a full test suite there taxes the entire session. Check whether anything relevant changed before doing real work.
-
-## Failure modes
-
-- _The infinite loop._ Blocking without honouring `stop_hook_active`, on a condition the agent cannot fix. This is the defining failure of the event and the reason the field exists.
-- _Blocking on the pre-existing._ Refusing the stop over a test that was already failing before the turn started. The agent is held responsible for something it did not touch and cannot resolve.
-- _Reason without a next step._ `"Checks failed."` The agent cannot act on it, so it stalls or invents work.
-- _Turn-end tax._ A full build on every stop, including turns that changed nothing. Gate on the tracked file list first.
-- _Silent success._ Exiting `0` when the check itself errored — a missing binary, a bad path — so a hook that has quietly stopped working looks exactly like a passing one. Report the breakage as a non-blocking error instead.

package/dist/plugins/using-hooks/skills/hook-stop/agents/openai.yaml

@@ -1,5 +0,0 @@
-interface:
-  display_name: "Hook: Stop"
-  short_description: "Refuse to let the agent end its turn until a condition is met"
-policy:
-  allow_implicit_invocation: false

package/dist/plugins/using-hooks/skills/hook-user-prompt-submit/SKILL.md

@@ -1,64 +0,0 @@
----
-name: hook-user-prompt-submit
-description: Writing a UserPromptSubmit lifecycle hook — the one that can add context to a prompt or reject it before the agent reads it.
-registryDependencies: [writing-great-hooks]
-disable-model-invocation: true
----
-
-Shared rules for every hook — the invariants, the script mechanics, registration: [`writing-great-hooks`](../writing-great-hooks/SKILL.md).
-
-`UserPromptSubmit` fires the instant the user submits, **before the agent has seen the prompt**. That position is the whole point: it is the only event that can put words in front of the agent that nobody typed, and the only one that can make a prompt never happen.
-
-It takes **no matcher** — there is no tool to match. Register it with an entry that has only a `hooks` array.
-
-## Payload
-
-The four common fields, plus the prompt itself:
-
-```json
-{
-  "session_id": "abc123",
-  "transcript_path": "/home/you/.claude/projects/<slug>/<session>.jsonl",
-  "cwd": "/home/you/project",
-  "hook_event_name": "UserPromptSubmit",
-  "prompt": "add a migration for the orders table"
-}
-```
-
-## What the exit code does
-
-- **`0` — stdout is injected into the agent's context.** This event and `SessionStart` are the only places where plain stdout reaches the agent as content rather than transcript noise. Print nothing and nothing is added.
-- **`2` — the prompt is blocked and erased.** It never reaches the agent, and stderr is shown to the user alone. Use it to refuse, not to advise.
-- **anything else** — the prompt proceeds untouched; stderr goes to the user as a non-blocking error.
-
-Because bare stdout is already the injection channel, the simplest useful hook is an `echo` and an exit `0`. Reach for JSON when you need a field the plain channel can't express:
-
-```json
-{
-  "hookSpecificOutput": {
-    "hookEventName": "UserPromptSubmit",
-    "additionalContext": "Current sprint: S-42. Active branch: fix/orders-migration."
-  }
-}
-```
-
-To reject from JSON instead of exit `2`, print `{"decision": "block", "reason": "..."}` — the reason is shown to the user in place of the prompt.
-
-## What it is for
-
-- **Injecting state the agent cannot see** — current branch, sprint, ticket, today's date, which service the user is in. Cheap, and it lands before the first token of reasoning.
-- **Routing to skills.** Match the prompt against trigger patterns and inject a line naming the skill that fits, so activation stops depending on the agent noticing.
-- **Refusing prompts that must not run** — a production-touching phrase, a missing ticket reference — by exiting `2` with a reason.
-
-## What it is not for
-
-**Do not use it to rewrite what the user meant.** Injected context is invisible to the person who typed the prompt: they see their words, the agent sees yours, and every downstream surprise is unattributable. Add facts, not instructions that contradict the prompt.
-
-Keep it fast. It sits between the user pressing enter and anything at all happening, so its latency is felt directly on every single turn.
-
-## Failure modes
-
-- _Silent hijack._ Injected text that redirects the task rather than informing it. The user cannot see it, cannot tell why the agent went sideways, and cannot turn it off.
-- _Context creep._ A paragraph injected on every prompt, most of it irrelevant to this one. It is paid on every turn for the whole session — inject the fields that change, not a status dump.
-- _Blocking too eagerly._ Exit `2` on a pattern that also matches innocent prompts. The user has no override and the prompt is already gone; prefer injecting a warning unless the action is genuinely unrecoverable.
-- _Leaking the payload._ Echoing the whole prompt into a log or an error message. Prompts carry secrets, and this hook sees every one of them.

package/dist/plugins/using-hooks/skills/hook-user-prompt-submit/agents/openai.yaml

@@ -1,5 +0,0 @@
-interface:
-  display_name: "Hook: UserPromptSubmit"
-  short_description: "Add context to a prompt, or reject it, before the agent reads it"
-policy:
-  allow_implicit_invocation: false

package/dist/plugins/workflow/.claude-plugin/plugin.json

@@ -1,16 +0,0 @@
-{
-  "name": "workflow",
-  "description": "Work a phase of a plan through plan, execute, review and sync, one agent per step, with hooks deciding when a step is finished.",
-  "version": "0.1.0",
-  "license": "UNLICENSED",
-  "dependencies": ["task-manager@g3n"],
-  "skills": [
-    "./skills/run",
-    "./skills/plan",
-    "./skills/execute",
-    "./skills/review",
-    "./skills/sync",
-    "./skills/orchestrator",
-    "./skills/worktree"
-  ]
-}

package/dist/plugins/workflow/agents/reviewer.md

@@ -1,9 +0,0 @@
----
-name: reviewer
-description: Read-only reviewer for the review step of the workflow. Judges each in-review task of a phase against its own brief and moves it to completed or back to in-progress. Use for the review step of a workflow run.
-disallowedTools: Edit, Write, NotebookEdit
----
-
-You review the tasks of one phase by following the `/review` skill. Load it before anything else.
-
-You change no file. The only state you move is a task's status, through `g3n-skills hook set-state`. Your findings go into your final report, which is the one thing the agent that spawned you will read, so each finding names the file and line, what is wrong, and what done looks like.

package/dist/plugins/workflow/skills/execute/SKILL.md

@@ -1,21 +0,0 @@
----
-name: execute
-description: Carry out the tasks of one phase, each in its own worktree, and hand every one to review. Use as the execute step of the workflow, when a phase has open or in-progress tasks, or when review sent a task back.
-registryDependencies: [task-manager, worktree, vocabulary, decisions]
-disable-model-invocation: false
----
-
-The execute step ends when no task of the phase is `open` or `in-progress`. A task leaves your hands as `in-review`, or as `blocked` with the reason in your report.
-
-The hooks come from the `/task-manager` skill. Load it first when `g3n-skills` is not on `PATH`.
-
-1. **Take your tasks.** A brief that names tasks gives you exactly those. Otherwise `g3n-skills hook current-step --phase <phase>` lists them under `holding`. Work them in that order, and start a task only once every id in its `depends_on` is `in-review` or `completed`.
-2. **Open the task** with `g3n-skills hook get-entry --id <task>`, then claim it with `g3n-skills hook set-state --id <task> --to in-progress`. A task that is already `in-progress` came back from review. Its findings are in your brief, and they are the whole job this time.
-3. **Get a worktree** through the `/worktree` skill, from the task's `worktree_type` and `id`. All edits happen inside it. The checkout you started in stays untouched.
-4. **Do the work the brief describes.** Stay inside its goals. Something the brief did not foresee goes into your report, never into the diff. Use the `/vocabulary` skill on the task's `vocabulary` array before naming anything, and the `/decisions` skill before choosing between designs, since the plan may have chosen already.
-5. **Prove it.** Tick a requirement only after checking it against the running code. Run the package's own type check and tests from inside the worktree. Done when every box is ticked and both pass.
-6. **Commit inside the worktree**, one commit per task, with the task id in the subject line. Pushing belongs to nobody in this workflow.
-7. **Hand it over** with `g3n-skills hook set-state --id <task> --to in-review`. A task you cannot finish goes to `blocked` instead, and your report says what would release it.
-8. **Finish** once your tasks are handed over. Holding the whole phase, run `g3n-skills hook advance-step --phase <phase> --from execute`. Exit `1` lists the tasks still to be worked, so go back to step 1 for them. Holding only some of the tasks, leave `advance-step` to the parent.
-
-Your report lists, per task, the branch, the commit, the final status, and anything the brief did not foresee.

package/dist/plugins/workflow/skills/execute/agents/openai.yaml

@@ -1,5 +0,0 @@
-interface:
-  display_name: "Execute"
-  short_description: "Carry out a phase's tasks, each in its own worktree, and hand them to review"
-policy:
-  allow_implicit_invocation: false

package/dist/plugins/workflow/skills/orchestrator/SKILL.md

@@ -1,27 +0,0 @@
----
-name: orchestrator
-description: Runs a whole plan, phase by phase, opening each phase's gate once the phases it depends on are completed.
-registryDependencies: [task-manager, run]
-disable-model-invocation: true
----
-
-A plan is a **graph**. Its phases are the nodes, and `depends_on` draws the edges. Each phase sits behind a **gate** that opens once everything it depends on is `completed`. You open gates. The `/run` skill does everything behind them.
-
-The hooks come from the `/task-manager` skill. Load it first when `g3n-skills` is not on `PATH`.
-
-`g3n-skills hook ready-phases --plan <plan>` sorts the plan's phases by gate:
-
-| Field | Holds |
-|---|---|
-| `ready` | phases whose gate is open, in queue order, each in full |
-| `waiting` | phases behind a closed gate, with the phases they are `waiting_on` |
-| `blocked` | phases set to `blocked` |
-| `completed` | finished phases |
-
-1. **Claim the plan** with `g3n-skills hook set-state --id <plan> --to in-progress`, unless it already is.
-2. **Read the gates** with `ready-phases`.
-   - `ready` and `waiting` both empty means no gate is left to open. Go to step 5.
-   - `ready` empty with anything in `waiting` means the graph is stuck behind a `blocked` phase. Go to step 5.
-3. **Pick what runs.** Take the first phase in `ready`. Add every other `ready` phase marked `parrallel: true`, provided the first one is marked so too. Otherwise run the first one alone.
-4. **Run each picked phase with the `/run` skill, from this session.** You are the parent of every agent in the plan, for the reason [`sub-agents.md`](../run/references/sub-agents.md) opens with, so a phase is never handed to one agent as a whole. With several phases picked, walk their `/run` loops side by side, spawning the agents of one round in one message. Done when each picked phase reads `done` or `blocked`. Then go to step 2.
-5. **Close out.** With every phase `completed`, run `g3n-skills hook set-state --id <plan> --to completed`. Otherwise leave the plan `in-progress`. Report each phase with its status, what blocks the blocked ones, and which `waiting` phases they hold back.

package/dist/plugins/workflow/skills/orchestrator/agents/openai.yaml

@@ -1,5 +0,0 @@
-interface:
-  display_name: "Orchestrator"
-  short_description: "Run a whole plan, opening each phase's gate once its dependencies are completed"
-policy:
-  allow_implicit_invocation: false

package/dist/plugins/workflow/skills/plan/SKILL.md

@@ -1,18 +0,0 @@
----
-name: plan
-description: Turn one phase of a plan into task files an agent can execute without asking anything. Use as the plan step of the workflow, when a phase has no tasks yet, or when the user wants a phase broken down.
-registryDependencies: [task-manager, writing-great-tasks, vocabulary, decisions, grilling]
-disable-model-invocation: false
----
-
-The plan step ends with a phase whose every deliverable belongs to exactly one task. You write briefs here. Code comes in the next step.
-
-The hooks come from the `/task-manager` skill. Load it first when `g3n-skills` is not on `PATH`.
-
-1. **Read the phase** with `g3n-skills hook get-entry --id <phase>`. Its `trail` names the plan. Its `vocabulary` array lists the terms the phase mentions. Use the `/vocabulary` skill to read that array, and write every task in those terms.
-2. **Read what is already closed** with `g3n-skills hook list-decisions --in <plan> --status accepted`, through the `/decisions` skill. A task never reopens an accepted decision. It builds on it.
-3. **Close the open questions.** Where the phase leaves scope, an interface or an order of work undecided, use the `/grilling` skill with the user. Running as a spawned agent, you have no user to grill, so return the questions in your report and stop. Done when you could name every file the phase will touch.
-4. **Cut the tasks.** One task is one agent's uninterrupted work with one reviewable diff. Two tasks that edit the same file get a `depends_on` between them, so they never run side by side. Done when each deliverable in the phase body maps to one task and no task holds two unrelated ones.
-5. **Write each task** at `<phase folder>/tasks/<id>.md`. Copy the frontmatter from [`references/task-frontmatter.md`](references/task-frontmatter.md), which is the contract the hooks check. Use the `/writing-great-tasks` skill for the body only. Done when every task file opens with that frontmatter, filled in.
-6. **Record what you settled.** A choice that passes the three tests goes through the `/decisions` skill. A concept you had to name goes through the `/vocabulary` skill.
-7. **Finish** with `g3n-skills hook sync-tree`, then `g3n-skills hook advance-step --phase <phase> --from plan`. Exit `1` names what is missing. Fix that and run it again. The step is finished when it prints `"step": "execute"`.

package/dist/plugins/workflow/skills/plan/agents/openai.yaml

@@ -1,5 +0,0 @@
-interface:
-  display_name: "Plan"
-  short_description: "Turn one phase into task files an agent can execute"
-policy:
-  allow_implicit_invocation: false

package/dist/plugins/workflow/skills/plan/references/task-frontmatter.md

@@ -1,33 +0,0 @@
-# Task frontmatter
-
-The frontmatter every task file opens with. The hooks check it against `TaskSchema` and reject any key not listed here. This is the disclosed reference for the [`plan`](../SKILL.md) skill.
-
-```yaml
----
-id: TASK-012
-title: Session table migration
-package: skills
-priority: high
-depends_on: [TASK-011]
-summary: Adds the sessions table and its indexes.
-complexity: 2
-worktree: true
-worktree_type: feature
-status: open
----
-```
-
-| Key | Rule |
-|---|---|
-| `id` | A prefix, a hyphen, then digits. Equal to the file name. Unique across the whole tree, so continue from the highest in use, which `g3n-skills hook list-entries --in <phase>` shows per phase |
-| `title` | A few words naming the deliverable |
-| `package` | The package the work lands in |
-| `priority` | `critical`, `high`, `medium` or `low` |
-| `depends_on` | Ids of tasks that must be handed over first. Leave the key out when there are none |
-| `summary` | One sentence saying what is different once the task is done |
-| `complexity` | `1` to `5`. Optional |
-| `worktree` | Always `true` |
-| `worktree_type` | `feature`, `fix`, `refactor`, `chore`, `docs`, `snapshot`, `demo` or `experiment`. Becomes the branch prefix |
-| `status` | `open` at creation |
-
-Where the `/writing-great-tasks` skill shows another frontmatter, this one wins.

package/dist/plugins/workflow/skills/review/SKILL.md

@@ -1,25 +0,0 @@
----
-name: review
-description: Judge each in-review task of a phase against its own requirements and either complete it or send it back. Use as the review step of the workflow, when every remaining task of a phase is in-review, or when the user wants a phase's work checked before it is merged.
-registryDependencies: [task-manager, writing-great-tasks, vocabulary, decisions]
-disable-model-invocation: false
----
-
-You are the **reviewer**, and you change no file. Your output is one verdict per task, moved through `set-state`, and findings exact enough that the next agent can act without asking you anything.
-
-The hooks come from the `/task-manager` skill. Load it first when `g3n-skills` is not on `PATH`.
-
-1. **List the tasks** with `g3n-skills hook current-step --phase <phase>`. `holding` names every task waiting for a verdict.
-2. **Read the brief before the diff**, with `g3n-skills hook get-entry --id <task>`. The `/writing-great-tasks` skill says what each section of it promises. Then read the work with `git diff <base>...<task branch>`, using the branch names from your own brief.
-3. **Check it, in this order.** Stop at the first failure only if it makes the rest unreadable.
-   - **Requirements.** Every ticked box is true of the diff. Check each one yourself.
-   - **Scope.** The diff stays inside the brief's goals and touches nothing listed under non-goals.
-   - **Proof.** The package's type check and tests pass when you run them in the task's worktree.
-   - **Words.** Through the `/vocabulary` skill: no avoided word in a new identifier, comment or doc.
-   - **Decisions.** Through the `/decisions` skill: nothing in the diff contradicts an `accepted` decision of the plan.
-4. **Give the verdict.**
-   - Pass: `g3n-skills hook set-state --id <task> --to completed`.
-   - Fail: `g3n-skills hook set-state --id <task> --to in-progress`. Each finding names the file and line, what is wrong, and what done looks like. A finding is a defect against the brief. Your taste is not a finding.
-5. **Finish** with `g3n-skills hook advance-step --phase <phase> --from review` once `holding` is empty. It prints `"step": "sync"` when everything passed and `"step": "execute"` when anything went back. Both are a finished review.
-
-Your report lists every task with its verdict, and the findings for each one sent back. The parent carries those findings into the next execute brief, so write them for a reader who has not seen the diff.

package/dist/plugins/workflow/skills/review/agents/openai.yaml

@@ -1,5 +0,0 @@
-interface:
-  display_name: "Review"
-  short_description: "Judge each in-review task against its brief and complete it or send it back"
-policy:
-  allow_implicit_invocation: false

package/dist/plugins/workflow/skills/run/SKILL.md

@@ -1,33 +0,0 @@
----
-name: run
-description: Work one phase of a plan through its four steps, plan, execute, review and sync, giving each step to a fresh agent and letting a hook decide when the step is finished. Use when the user wants a phase worked or names a phase to run, or when the orchestrator skill hands over a phase.
-registryDependencies: [task-manager, plan, execute, review, sync]
-disable-model-invocation: false
----
-
-You are the **parent**. You never do a step's work. You find out which step the phase is on, hand that step to one agent, and check what came back. Holding to that is what keeps each agent's context down to a single step.
-
-The hooks come from the `/task-manager` skill. Load it first when `g3n-skills` is not on `PATH`.
-
-## The step is read, never remembered
-
-`g3n-skills hook current-step --phase <phase>` returns the phase's `step`:
-
-| `step` | Meaning | Hand it to |
-|---|---|---|
-| `plan` | the phase has no tasks, or is still `open` | an agent running the `/plan` skill |
-| `execute` | a task is `open` or `in-progress` | agents running the `/execute` skill |
-| `review` | every remaining task is `in-review` | the **reviewer** agent running the `/review` skill |
-| `sync` | every task is `completed` | an agent running the `/sync` skill |
-| `done` | the phase is `completed` | nobody. Report and stop |
-| `blocked` | the phase or a task in `holding` is `blocked` | nobody. Report and stop |
-
-The step is worked out from the statuses on disk each time, so a task the reviewer sends back puts the phase on `execute` again with nothing to reset. `holding` names the tasks keeping the phase on its step.
-
-## The loop
-
-1. **Name the phase.** Use the one the user gave. With only a plan named, take the first phase from `g3n-skills hook ready-phases --plan <plan>`. Done when you hold one phase name.
-2. **Read the step** with `current-step`. On `done` or `blocked`, go to step 5.
-3. **Spawn the agent** for that step, briefed as [`references/sub-agents.md`](references/sub-agents.md) lays out. Read that file before the first spawn of a session. Done when every agent you spawned has returned its report.
-4. **Read the step again.** The agent ends its own step with `advance-step`, so a finished step shows up here as a new `step`. After several execute agents side by side, run `g3n-skills hook advance-step --phase <phase> --from execute` yourself first, since none of them does. An unchanged `step` means the agent stopped early. Spawn that step again and put the last report and the `holding` list in the brief. After the third return with no change, run `g3n-skills hook set-state --id <phase> --to blocked` and go to step 5. Otherwise go to step 2.
-5. **Report.** Tell the user the final `step`, each task with its status, the decisions and terms recorded along the way, and for `blocked` what is holding it and what would release it. Blocked work waits for the user.

package/dist/plugins/workflow/skills/run/agents/openai.yaml

@@ -1,5 +0,0 @@
-interface:
-  display_name: "Run"
-  short_description: "Work one phase through plan, execute, review and sync, one agent per step"
-policy:
-  allow_implicit_invocation: false

package/dist/plugins/workflow/skills/run/references/sub-agents.md

@@ -1,46 +0,0 @@
-# Sub-agents
-
-How the parent of a workflow run spawns, briefs and retires the agent of each step. This is the disclosed reference for the [`run`](../SKILL.md) and [`orchestrator`](../../orchestrator/SKILL.md) skills.
-
-## One rule decides who spawns
-
-**A spawned agent cannot spawn agents.** Every agent of a run is therefore started by the session the user is talking to. That session is the **parent**. It stays the parent for the whole run and never becomes a step's agent, even when a whole plan is being worked.
-
-## Life cycle of one agent
-
-1. **Spawn** one agent per step. Execute is the exception and may get several, as laid out below.
-2. **Brief** it with the template below. The brief is everything the agent knows. It has not seen your conversation or the last agent's report.
-3. **Wait** for its report. Leave the branches and worktrees it is using alone while it runs.
-4. **Verify** with `g3n-skills hook current-step --phase <phase>`. The hook is the judge of whether the step is finished. The report only explains.
-5. **Retire** it. A finished agent is never resumed for the next step, and the next step gets a new one. What has to survive goes into the next brief, the tree, a decision, or a term.
-
-## The brief
-
-```
-Run the /<step> skill on phase <phase> of plan <plan>.
-Project root: <absolute path>. Phase branch: <branch>. Base branch: <branch>.
-Tasks: <ids, for execute and review>. Task branches: <id → branch, for review and sync>.
-Carried over: <findings from review, open questions, reports sync must read>.
-End with the report the skill asks for.
-```
-
-Give names, never contents. The agent reads the phase and its tasks through the hooks, which hand it the `vocabulary` along with them.
-
-## Which agent per step
-
-| Step | Agent | Can edit |
-|---|---|---|
-| `plan` | general purpose | the tree only |
-| `execute` | general purpose, one or several | its task's worktree |
-| `review` | **reviewer**, defined in the plugin's `agents/reviewer.md` | nothing |
-| `sync` | general purpose | the phase branch, the tree |
-
-Where no `reviewer` agent type is offered, which is the case after `g3n-skills add workflow`, spawn a general purpose agent for `review` and open its brief with _You change no file._
-
-## Running execute side by side
-
-Tasks whose `depends_on` are all `in-review` or `completed` can run at once, one agent per task, because each works in its own worktree. Spawn them in one message so they start together. A task waiting on another stays with the parent until that one is handed over. Each of these agents holds only some of the phase, so none of them calls `advance-step`. You run `g3n-skills hook advance-step --phase <phase> --from execute` once the last of them has returned.
-
-## Without sub-agents
-
-A harness with no agent tool, Codex among them, runs the same loop in one session. Load the step's skill, do the step, run its `advance-step`, then load the next skill. The hooks and gates are the same ones. What is lost is the fresh context per step, so re-read `current-step` before each step and trust it over your memory of the last one.

package/dist/plugins/workflow/skills/sync/SKILL.md

@@ -1,18 +0,0 @@
----
-name: sync
-description: Land a reviewed phase by merging its task branches, removing their worktrees, recording its decisions and terms, and closing the phase. Use as the sync step of the workflow, or when every task of a phase is completed and the phase is still open.
-registryDependencies: [task-manager, worktree, vocabulary, decisions]
-disable-model-invocation: false
----
-
-The sync step leaves one branch holding the whole phase, no stray worktrees, and a tree that matches the code. It merges locally. Pushing and opening a pull request stay with the user.
-
-The hooks come from the `/task-manager` skill. Load it first when `g3n-skills` is not on `PATH`.
-
-1. **Confirm the step** with `g3n-skills hook current-step --phase <phase>`. Go on only when it prints `"step": "sync"`.
-2. **Merge the task branches** into the phase branch, in the order `current-step` lists the tasks, through the `/worktree` skill. A conflict you can settle from the two task briefs alone, settle. Any other conflict stops the step. Set the phase to `blocked` and put both sides in your report. Done when every task branch is merged and the package's type check and tests pass on the phase branch.
-3. **Remove what is merged**, again through the `/worktree` skill. Done when `git worktree list` shows no worktree of this phase.
-4. **Record what the phase decided.** Read the reports in your brief for choices the agents made along the way. Each one that passes the three tests goes through the `/decisions` skill. Each concept that got a name goes through the `/vocabulary` skill.
-5. **Close the phase** with `g3n-skills hook sync-tree`, then `g3n-skills hook advance-step --phase <phase> --from sync`. The step is finished when it prints `"step": "done"`.
-
-Your report names the phase branch, the merged commits, the decisions and terms recorded, and the next phases whose gate this one opened, from `g3n-skills hook ready-phases --plan <plan>`.