@g3nomaly/skills 1.0.0 → 1.0.1

package/dist/plugins/grilling/skills/domain-modeling/SKILL.md

@@ -1,74 +0,0 @@
----
-name: domain-modeling
-description: Build and sharpen a project's domain model. Use when the user wants to pin down domain terminology or a ubiquitous language, record an architectural decision, or when another skill needs to maintain the domain model.
----
-
-# Domain Modeling
-
-Actively build and sharpen the project's domain model as you design. This is the *active* discipline — challenging terms, inventing edge-case scenarios, and writing the glossary and decisions down the moment they crystallise. (Merely *reading* `CONTEXT.md` for vocabulary is not this skill — that's a one-line habit any skill can do. This skill is for when you're changing the model, not just consuming it.)
-
-## File structure
-
-Most repos have a single context:
-
-```
-/
-├── CONTEXT.md
-├── docs/
-│   └── adr/
-│       ├── 0001-event-sourced-orders.md
-│       └── 0002-postgres-for-write-model.md
-└── src/
-```
-
-If a `CONTEXT-MAP.md` exists at the root, the repo has multiple contexts. The map points to where each one lives:
-
-```
-/
-├── CONTEXT-MAP.md
-├── docs/
-│   └── adr/                          ← system-wide decisions
-├── src/
-│   ├── ordering/
-│   │   ├── CONTEXT.md
-│   │   └── docs/adr/                 ← context-specific decisions
-│   └── billing/
-│       ├── CONTEXT.md
-│       └── docs/adr/
-```
-
-Create files lazily — only when you have something to write. If no `CONTEXT.md` exists, create one when the first term is resolved. If no `docs/adr/` exists, create it when the first ADR is needed.
-
-## During the session
-
-### Challenge against the glossary
-
-When the user uses a term that conflicts with the existing language in `CONTEXT.md`, call it out immediately. "Your glossary defines 'cancellation' as X, but you seem to mean Y — which is it?"
-
-### Sharpen fuzzy language
-
-When the user uses vague or overloaded terms, propose a precise canonical term. "You're saying 'account' — do you mean the Customer or the User? Those are different things."
-
-### Discuss concrete scenarios
-
-When domain relationships are being discussed, stress-test them with specific scenarios. Invent scenarios that probe edge cases and force the user to be precise about the boundaries between concepts.
-
-### Cross-reference with code
-
-When the user states how something works, check whether the code agrees. If you find a contradiction, surface it: "Your code cancels entire Orders, but you just said partial cancellation is possible — which is right?"
-
-### Update CONTEXT.md inline
-
-When a term is resolved, update `CONTEXT.md` right there. Don't batch these up — capture them as they happen. Use the format in [CONTEXT-FORMAT.md](./CONTEXT-FORMAT.md).
-
-`CONTEXT.md` should be totally devoid of implementation details. Do not treat `CONTEXT.md` as a spec, a scratch pad, or a repository for implementation decisions. It is a glossary and nothing else.
-
-### Offer ADRs sparingly
-
-Only offer to create an ADR when all three are true:
-
-1. **Hard to reverse** — the cost of changing your mind later is meaningful
-2. **Surprising without context** — a future reader will wonder "why did they do it this way?"
-3. **The result of a real trade-off** — there were genuine alternatives and you picked one for specific reasons
-
-If any of the three is missing, skip the ADR. Use the format in [ADR-FORMAT.md](./ADR-FORMAT.md).

package/dist/plugins/grilling/skills/domain-modeling/agents/openai.yaml

@@ -1,3 +0,0 @@
-interface:
-  display_name: "Domain Modeling"
-  short_description: "Build and sharpen a domain model"

package/dist/plugins/grilling/skills/grill-me/SKILL.md

@@ -1,7 +0,0 @@
----
-name: grill-me
-description: A relentless interview to sharpen a plan or design.
-disable-model-invocation: true
----
-
-Run a `/grilling` session.

package/dist/plugins/grilling/skills/grill-me/agents/openai.yaml

@@ -1,5 +0,0 @@
-interface:
-  display_name: "Grill Me"
-  short_description: "Sharpen a plan through interview"
-policy:
-  allow_implicit_invocation: false

package/dist/plugins/grilling/skills/grill-with-docs/SKILL.md

@@ -1,7 +0,0 @@
----
-name: grill-with-docs
-description: A relentless interview to sharpen a plan or design, which also creates docs (ADR's and glossary) as we go.
-disable-model-invocation: true
----
-
-Run a `/grilling` session, using the `/domain-modeling` skill.

package/dist/plugins/grilling/skills/grill-with-docs/agents/openai.yaml

@@ -1,5 +0,0 @@
-interface:
-  display_name: "Grill with Docs"
-  short_description: "Grill a design and write its docs"
-policy:
-  allow_implicit_invocation: false

package/dist/plugins/grilling/skills/grilling/SKILL.md

@@ -1,12 +0,0 @@
----
-name: grilling
-description: Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test their thinking, or uses any 'grill' trigger phrases.
----
-
-Interview me relentlessly about every aspect of this until we reach a shared understanding. Walk down each branch of the decision tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.
-
-Ask the questions one at a time, waiting for feedback on each question before continuing. Asking multiple questions at once is bewildering.
-
-If a *fact* can be found by exploring the environment (filesystem, tools, etc.), look it up rather than asking me. The *decisions*, though, are mine — put each one to me and wait for my answer.
-
-Do not act on it until I confirm we have reached a shared understanding.

package/dist/plugins/grilling/skills/grilling/agents/openai.yaml

@@ -1,3 +0,0 @@
-interface:
-  display_name: "Grilling"
-  short_description: "Stress-test thinking one question at a time"

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

@@ -1,7 +0,0 @@
-{
-  "name": "speech",
-  "description": "Conventions for how an agent writes — emphasis markup and cutting AI tells.",
-  "version": "0.1.0",
-  "license": "UNLICENSED",
-  "skills": ["./skills/emphasise", "./skills/unslop"]
-}

package/dist/plugins/speech/skills/emphasise/SKILL.md

@@ -1,49 +0,0 @@
----
-name: emphasise
-description: The bold, italic, and backtick conventions for agent-facing Markdown — what **bold**, _italics_, and `code` each mean, and how to use them to make text instantly scannable. Use when writing or editing a skill, prompt, or doc the agent reads, or when the user asks how to emphasise a term.
-disable-model-invocation: false
----
-
-Emphasis is an **attention budget** designed to make text highly scannable on a first pass. A marker works by making one token stand out from its neighbours; spend it only where it helps the eye jump to the core meaning of a paragraph.
-
-Three markers, three jobs: `_italics_` highlights _core concepts and themes_, **bold** anchors _hard entities and structures_, and `` `code` `` protects _literal syntax_.
-
-## `_italics_` — the scannability anchor
-
-This is your primary tool for helping a reader (human or AI) skim a paragraph and instantly grasp its subject without reading every word. It does not mean the word is a strict variable; it means the word is the thematic core of the sentence.
-
-1. _Concept / Keyword_ — highlights architectural ideas, patterns, or focal points (e.g., _minimum viable product_, _god classes_, _domain segregation_). This draws the eye to the "what are we talking about" of the sentence. 
-2. _Stress_ — the pivot the meaning turns on: "the same _way_ on every run, not the same output".
-3. _Mention_ — a word or phrase named rather than used: a coined leading word (_tight_), or prompt text quoted as an example (_be thorough_).
-4. _Label_ — a short tag classifying the block it opens: `_Failure mode._` Mark the tag text and nothing else.
-
-## `**bold**` — the structural pointer
-
-Bold carries heavy weight. It is reserved for strict, defined entities, specific UI/document locations, and operative actions. 
-
-1. **Entity / Location** — a defined concept with an authoritative definition, or a specific destination like a file, document, or section (e.g., an extension gets reported in **Findings**).
-2. **Action / Point** — the operative clause of a bullet or step, front-loaded so the list can be skimmed by its first few words. **One trigger per branch.** Bold the instruction; leave the explanation after it plain.
-
-## `` `code` `` — this is literal
-
-Backticks are not emphasis. They mean "reproduce this exactly": paths, filenames, flags, field names, identifiers, commands. A concept that is also an identifier takes backticks in its identifier sense and italics in its concept sense — the `description` field is what you edit, but the _description_ is what makes a skill model-invoked.
-
-## Choosing
-
-| Test | Marker |
-|---|---|
-| Is it a key concept, pattern, or keyword I want the eye to catch when skimming? | `_italics_` (concept) |
-| Is it a defined strict entity, document name, or UI element? | `**bold**` (entity) |
-| Is it the operative point of a bullet? | `**bold**` (action) |
-| Would the sentence be misread without it? | `_italics_` (stress) |
-| Is it a word or quoted phrase being named rather than used? | `_italics_` (mention) |
-| Would you type it verbatim into a terminal or a file? | `` `backticks` `` |
-| None of the above | plain text |
-
-## Failure modes
-
-- _Emphasis inflation._ So much is marked that nothing reads as marked. The fix is subtraction: cut until what remains is exactly enough to allow a reader to skim and understand the paragraph.
-- _Marker collision._ The same word bolded in one passage and italicised in another. Decide whether the word is a hard entity (**bold**) or a thematic concept (_italics_) and stick to it.
-- _Double marking._ `**_both at once_**` spends two signals on one job and looks messy. Pick one.
-- _Runaway italics._ Italics past a few words — a whole paragraph or a long quotation. Concepts are punchy; if you italicise a whole sentence, you destroy the scannability. 
-- _Bold as outline._ Bolded lead-ins carrying a hierarchy across paragraphs, where a heading (`##`) or list is the real answer.

package/dist/plugins/speech/skills/emphasise/agents/openai.yaml

@@ -1,5 +0,0 @@
-interface:
-  display_name: "Emphasise"
-  short_description: "Bold and italic conventions for agent-facing Markdown"
-policy:
-  allow_implicit_invocation: false

package/dist/plugins/speech/skills/unslop/SKILL.md

@@ -1,80 +0,0 @@
----
-name: unslop
-description: Cut AI tells from any writing. Must always apply.
----
-
-# Unslop
-
-Edit text to remove AI patterns and add human voice.
-
-## Process
-
-1. Scan for the patterns below.
-2. Rewrite. Preserve meaning, match intended tone.
-3. Add soul (see next section).
-4. Self-audit: "What makes this obviously AI generated?" Fix remaining tells.
-
-## Adding soul
-
-Removing patterns is half the job. Sterile, voiceless writing is just as obvious.
-
-- **Have opinions.** React to facts instead of neutrally listing pros and cons.
-- **Vary rhythm.** Short sentences. Then longer ones that take their time. Mix it up.
-- **Acknowledge complexity.** "Impressive but also kind of unsettling" beats "impressive."
-- **Use "I" when it fits.** First person isn't unprofessional.
-- **Let some mess in.** Perfect structure looks machine-made.
-- **Be specific.** Not "this is concerning" but "there's something unsettling about agents churning away at 3am."
-
-## Patterns to detect and fix
-
-### Content
-
-1. **Puffery.** "pivotal moment", "testament to", "evolving landscape", "setting the stage for", "indelible mark", "deeply rooted". Cut puffery, state what happened.
-2. **Name-dropping.** Listing media outlets without context. Pick one, say what was said.
-3. **Superficial -ing phrases.** "highlighting...", "ensuring...", "reflecting...", "showcasing...", "fostering...". Delete or expand with real sources.
-4. **Promotional language.** "nestled", "vibrant", "breathtaking", "groundbreaking", "renowned", "stunning", "must-visit". Use neutral descriptions.
-5. **Vague attributions.** "Experts believe", "Industry reports suggest", "Some critics argue". Name the source or delete.
-6. **Formulaic challenges.** "Despite challenges... continues to thrive." Replace with specific facts.
-
-### Language
-
-7. **AI vocabulary.** Additionally, crucial, delve, enduring, enhance, fostering, garner, interplay, intricate, landscape (abstract), pivotal, showcase, tapestry (abstract), testament, underscore, vibrant. Replace with plain words.
-8. **Fancy ways to say "is".** "serves as", "stands as", "boasts", "features". Just say "is" or "has".
-9. **"Not just X, but Y."** State the point directly instead.
-10. **Rule of three.** Forcing ideas into groups of three. Use the natural number.
-11. **Synonym cycling.** Protagonist, main character, central figure, hero all in one paragraph. Pick one, repeat it.
-12. **False ranges.** "from X to Y" where X and Y aren't on a meaningful scale. List topics directly.
-
-### Style
-
-13. **Em dash overuse.** Avoid em dashes entirely. Use periods or commas only (no parentheses, no en dashes, no hyphen-as-dash substitutes). Em dashes are an AI tell, and reaching for parentheses instead just trades one tell for another. If a thought needs separation, end the sentence or use a comma.
-14. **Colon overuse.** Colons are fine before a list or example. Not as mid-sentence connectors. "If you're coming from traditional automation: instead of registering event handlers, you describe conditions" adds nothing with the colon. Rewrite to let the point stand on its own without comparison framing. "Describing when the scheduler should fire works best as plain English." Same meaning, no crutch punctuation.
-15. **Boldface overuse.** Don't bold every proper noun or acronym.
-16. **Inline-header lists.** The tell is a bold label and colon that restates the line: "**Performance:** Performance improved...". Convert those to prose. A bold lead-in that ends in a period, names the item, and is followed by genuinely new detail ("**Schema in TypeScript.** Tables live in one file.") is fine, not a tell.
-17. **Title case headings.** Use sentence case.
-18. **Decorative emojis.** Remove from headings and bullets.
-19. **Curly quotes.** Replace with straight quotes.
-
-### Communication artifacts
-
-20. **Chatbot phrases.** "I hope this helps!", "Let me know if...", "Of course!", "Certainly!", "Found the smoking gun!" Remove.
-21. **Cutoff disclaimers.** "While specific details are limited..." Find sources or remove.
-22. **Sycophantic tone.** "Great question! You're absolutely right!" Respond directly.
-
-### Filler
-
-23. **Filler phrases.** "In order to" becomes "To". "Due to the fact that" becomes "Because". "It is important to note that" gets deleted.
-24. **Excessive hedging.** "could potentially possibly be argued that it might" becomes "may".
-25. **Generic conclusions.** "The future looks bright." State specific plans or facts.
-
-### Jargon
-
-26. **Abstract metaphor nouns.** Substrate, wedge, vector, locus, vantage, nexus, primitive (as noun), harness (as metaphor), surface (as in "API surface"), bedrock, scaffolding (as metaphor), modality, paradigm, gold-plating, ratchet (as metaphor), evacuate (for moving code), endgame, north star, flywheel. These read as technical but usually have a plainer concrete word. "Substrate" becomes "base". "Wedge in" becomes "add". "Vector" becomes "way" or "method". "Gold-plating" becomes "more than the job needs". "Ratchet" becomes the mechanism's real name or "a limit that only tightens". "Evacuate" becomes "move out". "Endgame" becomes "the last phase". Pick the concrete word.
-
-### Plain speech
-
-27. **Say what it does, not how it feels.** "the database stays close at hand", "SQL you can read", "types that follow your schema" name a feeling. The fix names the mechanism or a number: "`.toSQL()` returns the exact string sent to the database", "a column rename fails the build". Ask what the sentence tells the reader to do or know, then write that. If you can't restate it as a concrete instruction, fact, or number, cut it. One more check: if the sentence could appear unchanged in another project's docs, it says nothing about this one. Cut it.
-28. **Shorten or split dense sentences.** If the reader has to backtrack to parse a sentence, break it in two or drop clauses. One idea per sentence.
-29. **Active voice.** Prefer it. Catch "is/are/was/were + past participle" and name the actor: "queries are validated" becomes "the compiler validates queries", "the file is parsed by the loader" becomes "the loader parses the file". Passive is fine only when the actor is unknown or genuinely doesn't matter.
-30. **Cut adverbs, or use a stronger verb.** "runs quickly" becomes "is fast" or the number. "significantly improves" becomes the measured delta. An adverb propping up a weak verb means the verb is wrong.
-31. **Prefer the plain word.** "utilize" becomes "use", "leverage" becomes "use", "facilitate" becomes "help", "numerous" becomes "many", "in the event that" becomes "if". The fancier synonym is rarely clearer.

package/dist/plugins/task-manager/.claude-plugin/plugin.json

@@ -1,11 +0,0 @@
-{
-  "name": "task-manager",
-  "description": "Query and drive a tree of plans, phases and tasks through hooks, with the plan's decisions and the project vocabulary kept beside them.",
-  "version": "0.1.0",
-  "license": "UNLICENSED",
-  "skills": [
-    "./skills/task-manager",
-    "./skills/vocabulary",
-    "./skills/decisions"
-  ]
-}

package/dist/plugins/task-manager/hooks/hooks.json

@@ -1,19 +0,0 @@
-{
-  "hooks": {
-    "SessionStart": [
-      {
-        "hooks": [
-          { "type": "command", "command": "g3n-skills hook sync-tree", "timeout": 30 }
-        ]
-      }
-    ],
-    "PreToolUse": [
-      {
-        "matcher": "Read|Grep|Glob",
-        "hooks": [
-          { "type": "command", "command": "g3n-skills hook guard-tree", "timeout": 10 }
-        ]
-      }
-    ]
-  }
-}

package/dist/plugins/task-manager/skills/decisions/SKILL.md

@@ -1,39 +0,0 @@
----
-name: decisions
-description: Record and look up the decisions a plan has made, stored as numbered files inside the plan and reached through hooks. Use when a hard-to-reverse choice is made while planning or working a phase, when a choice replaces an earlier one, when the user asks why something was done a certain way, or when another skill needs a plan's decisions.
-registryDependencies: [task-manager, domain-modeling]
-disable-model-invocation: false
----
-
-A **decision** is one paragraph saying what was chosen and why, filed under the plan it belongs to. Its job is to stop the next session from reopening a question this one closed.
-
-The hooks come from the `/task-manager` skill. Load it first when `g3n-skills` is not on `PATH`.
-
-**Reach decisions through the hooks only.** They sit inside the tree, in `<plan>/decisions/<id>.md`, so `guard-tree` denies a direct read.
-
-| Hook | Does | Use it when |
-|---|---|---|
-| `list-decisions` | Returns a plan's decisions in numbered order, metadata only | starting a phase, or checking whether a question is already closed |
-| `get-decision` | Returns one decision in full | the title is not enough |
-| `add-decision` | Numbers, dates and writes a new decision from stdin. **Writes.** | a choice passed the three tests below |
-
-Copy each invocation from [`references/usage.md`](references/usage.md). `add-decision` takes the decision text on stdin, as shown there.
-
-- **`--in <plan>`** is required everywhere. Numbers restart per plan.
-- **`--status`** is `proposed`, `accepted`, `deprecated` or `superseded`. `add-decision` defaults to `accepted`. `list-decisions` filters by it.
-- **`--supersedes <id>`** also moves the named decision to `superseded`.
-- `get-decision` exits `1` for an unknown id. `list-decisions` prints `[]` for a plan with none. `add-decision` exits `1` when nothing was piped in.
-
-## When to record
-
-All three must hold. The `/domain-modeling` skill argues each one in its ADR format, with examples of what qualifies.
-
-1. **Hard to reverse.** Changing course later costs real work.
-2. **Surprising without context.** A reader of the code would ask why.
-3. **A real trade-off.** There was an alternative, and it lost for a reason.
-
-## Writing one
-
-One to three sentences: the context, the choice, the reason. Name the alternative that lost. The title is the choice itself in a few words, because `list-decisions` shows titles only and the title has to close the question unaided.
-
-**A decision is never edited.** A changed mind is a new decision with `--supersedes`, so the trail of reasons stays readable.

package/dist/plugins/task-manager/skills/decisions/agents/openai.yaml

@@ -1,5 +0,0 @@
-interface:
-  display_name: "Decisions"
-  short_description: "Record and look up a plan's decisions through the task-manager hooks"
-policy:
-  allow_implicit_invocation: false

package/dist/plugins/task-manager/skills/decisions/references/usage.md

@@ -1,26 +0,0 @@
-# Decision hooks — usage
-
-Where decisions sit and how each hook is called. This is the disclosed reference for the [`decisions`](../SKILL.md) skill.
-
-## On disk
-
-```
-docs/task-manager/auth-rework/
-├── auth-rework.md
-└── decisions/
-    ├── 0001-use-jwt-for-sessions.md
-    └── 0002-use-opaque-tokens.md
-```
-
-## Invocations
-
-```bash
-g3n-skills hook list-decisions --in auth-rework --status accepted
-g3n-skills hook get-decision --in auth-rework --id 0001-use-jwt-for-sessions
-
-g3n-skills hook add-decision --in auth-rework --title "Use opaque tokens" \
-  --supersedes 0001-use-jwt-for-sessions <<'TEXT'
-Sessions move to opaque tokens looked up per request. Revoking a JWT before
-expiry needed a denylist, which cost the statelessness we chose JWTs for.
-TEXT
-```

package/dist/plugins/task-manager/skills/task-manager/SKILL.md

@@ -1,99 +0,0 @@
----
-name: task-manager
-description: Query and drive a tree of plans, phases and tasks that lives on disk as folders of Markdown files with a rebuilt index per folder. Use whenever the user asks what to work on next, refers to a plan, phase or task by name or TASK-### id, wants something moved to open, in-progress, in-review, completed or blocked, or wants finished work cleared out. Every read and every write goes through the `g3n-skills hook` commands — never open a tree file directly.
-disable-model-invocation: false
----
-
-## Before anything else
-
-```bash
-command -v g3n-skills >/dev/null 2>&1 || bun add -g @g3nomaly/skills
-```
-
-If the command exists, print nothing and carry on.
-
-The tree is **three levels deep** and nothing else: the root holds **plans**, a plan holds **phases**, a phase holds **tasks**.
-
-```
-docs/task-manager/                 # set by skills.settings.filetreeRoot
-├── root-index.json                # the plans, in order
-└── auth-rework/
-    ├── auth-rework.md             # the plan itself
-    ├── plan-index.json            # the phases, in order
-    └── 01-schema/
-        ├── 01-schema.md           # the phase itself
-        ├── phase-index.json       # the tasks, in order
-        └── tasks/
-            └── TASK-006.md
-```
-
-Every `.md` file opens with frontmatter carrying exactly the fields its index entry carries. **The index is rebuilt from the files, never edited** — a hand-written index is overwritten on the next sync.
-
-**Order is the alphabetical order of the names on disk.** There is no rank field, no queue number and nothing to renumber: `01-schema` runs before `02-api` because `0` sorts before `2`. To reorder, rename.
-
-**States** are `open`, `in-progress`, `in-review`, `completed` and `blocked`, and every level uses the same five.
-
-## Never open a tree file
-
-`Read`, `Grep` and `Glob` are the wrong tools here — **`guard-tree` denies them** on anything inside the tree, and says which hook to run instead. They are the interface: each one names its flags in this table and reports what went wrong on stderr.
-
-| Hook | Does | Use it when |
-|---|---|---|
-| `next-entry` | Returns the first entry of a queue that is not `completed` or `blocked`, in full | starting work — "what's next", "give me the next task" |
-| `get-entry` | Returns one named plan, phase or task, in full | the user names something — "open auth-rework", "show TASK-006" |
-| `list-entries` | Returns one folder's entries in queue order, metadata only | surveying — "what phases are in this plan", "what's blocked" |
-| `set-state` | Moves one entry to a new state and rebuilds its index | work starts, stalls, lands, or goes up for review |
-| `cleanup` | Deletes every `completed` entry, and `blocked` too with `--blocked` | the tree has filled up with finished work |
-| `sync-tree` | Creates what is missing and rebuilds every index | a file was added or renamed by hand; otherwise it runs itself |
-| `guard-tree` | Denies a file tool aimed at the tree | never by hand — the harness fires it |
-
-The last two are **registered in `hooks/hooks.json` and fire on their own**; never invoke them as a step:
-
-| Hook | Event | Matcher | What it does |
-|---|---|---|---|
-| `sync-tree` | `SessionStart` | — | Rebuilds every index. Exit `1` is non-blocking: the session opens with stale indexes and the reason goes to the user. |
-| `guard-tree` | `PreToolUse` | `Read\|Grep\|Glob` | Returns `deny` for a guarded path, nothing otherwise. Only a path the call states outright is checked, so an unscoped `Grep` still runs. |
-
-Run the other four from the plugin root:
-
-```bash
-g3n-skills hook next-entry --in auth-rework --pretty
-g3n-skills hook get-entry --id TASK-006
-g3n-skills hook list-entries --in auth-rework --status blocked
-g3n-skills hook set-state --id TASK-006 --to in-progress
-g3n-skills hook cleanup --blocked --dry-run --pretty
-```
-
-## Flags they share
-
-- **`--project <dir>`** — the folder holding `.g3n.config.json`, default the working directory. The tree root comes from `skills.settings.filetreeRoot` in it.
-- **`--root <dir>`** — the tree folder verbatim, skipping the config. Use it only when there is no config to read.
-- **`--pretty`** — indented JSON. Leave it off when piping.
-- **`--id <name>`** — a plan or phase name, or a task id like `TASK-006`. One name is searched for across the whole tree; two entries answering to it is an error, not a choice to make.
-- **`--in <name>`** — whose entries to list. Omit it for the plans at the root.
-
-Where they deliberately differ:
-
-- `next-entry` and `get-entry` **return exactly one thing**, so nothing found is a failure — exit `1`.
-- `list-entries` and `cleanup` **return a list**, so `[]` is a real answer — exit `0`.
-- `get-entry`, `next-entry` and `list-entries` are read-only; **`set-state`, `cleanup` and `sync-tree` write to disk.** Run `cleanup` with `--dry-run` before running it for real.
-
-## Terms and decisions
-
-Two more things live in the tree, each with its own hooks and its own skill:
-
-- **The vocabulary**, one file at the tree root. `get-entry` and `next-entry` attach a `vocabulary` array naming every term the entry mentions. Use the `/vocabulary` skill to read that array, look a word up, or record one.
-- **A plan's decisions**, in `<plan>/decisions/`. Use the `/decisions` skill to list, read or record them.
-
-## What the hooks will not do
-
-- **A state change is only the `status:` line.** What the transition implies — the reason a task is blocked, the outcome written into the body — is prose, and prose is written afterwards with an ordinary edit to the body of that one file.
-- **Creating a plan, phase or task is not a hook.** Write the `.md` file where the tree expects it, then run `sync-tree`; the index picks it up.
-- **`cleanup` deletes.** A removed plan takes its phases and tasks with it. Confirm with the user before running it without `--dry-run`.
-
-## When it goes wrong
-
-Everything is checked against its schema on the way in, and a failure names the file and the field. Two are worth recognising:
-
-- _`"<name>" is ambiguous`_ — two entries share a name. Rename one; nothing else will work until then.
-- _`is "X" but it was read as "Y"`_ — the `name` or `id` in the frontmatter disagrees with the folder or file holding it. Fix the frontmatter, or rename the file, then `sync-tree`.

package/dist/plugins/task-manager/skills/vocabulary/SKILL.md

@@ -1,42 +0,0 @@
----
-name: vocabulary
-description: Keep one word per concept across sessions, stored in the task-manager tree and reached through hooks. Use when about to name a domain concept in code, a task or a doc, when the user corrects a word, when two words are in use for one thing, or when another skill needs a term looked up or recorded.
-registryDependencies: [task-manager, domain-modeling]
-disable-model-invocation: false
----
-
-Every session starts without the last one's words, so names _drift_: the _phase_ of Monday is the _stage_ of Tuesday, and by Friday the code has both. The vocabulary is the one list that stops it. Each **term** carries a definition and the **avoided words** it replaces.
-
-The hooks come from the `/task-manager` skill. Load it first when `g3n-skills` is not on `PATH`.
-
-The terms live in `vocabulary.md` at the tree root. **Reach them through the hooks only.** `guard-tree` denies a direct read, and a hand edit is overwritten by the next `set-term`.
-
-| Hook | Does | Use it when |
-|---|---|---|
-| `get-term` | Returns one term, found by its name or by an avoided word | about to use a word for a domain concept |
-| `list-terms` | Returns every term, sorted by name | starting work in an unfamiliar area |
-| `set-term` | Adds a term, or replaces its definition and avoided words. **Writes.** | a concept got a name, or a name got sharper |
-| `remove-term` | Deletes one term. **Writes.** | the concept left the project |
-
-Copy each invocation from [`references/usage.md`](references/usage.md).
-
-They share `--project`, `--root` and `--pretty` with the task-manager hooks. `get-term` and `remove-term` exit `1` when nothing answers to the name. `list-terms` prints `[]` for an empty vocabulary.
-
-## Reading an answer
-
-`get-term` reports how it found the term in `matched`:
-
-- **`"term"`** means the word is the right one. Use it as spelled.
-- **`"avoid"`** means the word is a retired synonym. Use the returned `term` instead, in prose and in identifiers alike.
-
-`get-entry` and `next-entry` attach a `vocabulary` array to every plan, phase and task they return. It lists each term the entry mentions, and under `avoided` the retired words the entry still uses. Treat a non-empty `avoided` as a defect in the entry and write the term in whatever you produce from it.
-
-## Recording a term
-
-**Record on the second sighting.** One use of a word is prose. The same concept named twice, or named differently by two people, is a term. A correction from the user is always a term.
-
-- **Definition.** One or two sentences saying what the thing _is_. Leave out how it is built.
-- **`--avoid`.** The synonyms actually seen, comma-separated. `set-term` refuses a word another term already owns, which is how two terms are kept from claiming one meaning.
-- **`set-term` replaces.** Pass the full definition and the full avoid list every time, since flags left out are cleared.
-
-A term whose meaning is still contested is sharpened with the `/domain-modeling` skill first, then stored here.

package/dist/plugins/task-manager/skills/vocabulary/agents/openai.yaml

@@ -1,5 +0,0 @@
-interface:
-  display_name: "Vocabulary"
-  short_description: "One word per concept across sessions, kept in the task-manager tree through hooks"
-policy:
-  allow_implicit_invocation: false

package/dist/plugins/task-manager/skills/vocabulary/references/usage.md

@@ -1,26 +0,0 @@
-# Term hooks — usage
-
-How each hook is called, and what the file they write looks like. This is the disclosed reference for the [`vocabulary`](../SKILL.md) skill.
-
-## Invocations
-
-```bash
-g3n-skills hook get-term --term stage
-g3n-skills hook list-terms --pretty
-g3n-skills hook set-term --term Phase --definition "One step of a plan, holding tasks." --avoid "stage, milestone"
-g3n-skills hook remove-term --term Phase
-```
-
-## The file
-
-`set-term` and `remove-term` rewrite `vocabulary.md` whole, terms sorted by name:
-
-```md
-# Vocabulary
-
-## Phase
-
-One step of a plan, holding tasks.
-
-_Avoid_: stage, milestone
-```

package/dist/plugins/using-hooks/.claude-plugin/plugin.json

@@ -1,7 +0,0 @@
-{
-  "name": "using-hooks",
-  "description": "How to write each Claude Code lifecycle hook.",
-  "version": "0.1.0",
-  "license": "UNLICENSED",
-  "skills": ["./skills/hook-pre-tool-use", "./skills/hook-post-tool-use", "./skills/hook-stop", "./skills/hook-user-prompt-submit"]
-}