@g3nomaly/g3n-skills 0.0.0-stage → 0.1.0

package/.claude-plugin/marketplace.json

@@ -0,0 +1,91 @@
+{
+  "name": "g3n",
+  "owner": {
+    "name": "g3ntrovert"
+  },
+  "plugins": [
+    {
+      "name": "agent",
+      "source": "./skills/agent",
+      "description": "Rules every agent session follows: the session bootstrap, its boundaries, and working in worktrees.",
+      "skills": [
+        "./bootstrap",
+        "./worktrees"
+      ]
+    },
+    {
+      "name": "coding",
+      "source": "./skills/coding",
+      "description": "How to write, check and document code, per language.",
+      "skills": [
+        "./code",
+        "./document"
+      ]
+    },
+    {
+      "name": "grilling",
+      "source": "./skills/grilling",
+      "description": "Relentless interviews that stress-test a plan, plus the domain model they feed.",
+      "skills": [
+        "./grilling",
+        "./grill-me",
+        "./grill-with-docs",
+        "./domain-modeling"
+      ]
+    },
+    {
+      "name": "speech",
+      "source": "./skills/speech",
+      "description": "Conventions for how an agent writes — emphasis markup and cutting AI tells.",
+      "skills": [
+        "./emphasise",
+        "./unslop"
+      ]
+    },
+    {
+      "name": "task-manager",
+      "source": "./skills/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.",
+      "skills": [
+        "./task-manager",
+        "./vocabulary",
+        "./decisions"
+      ]
+    },
+    {
+      "name": "using-hooks",
+      "source": "./skills/using-hooks",
+      "description": "How to write each Claude Code lifecycle hook.",
+      "skills": [
+        "./hook-pre-tool-use",
+        "./hook-post-tool-use",
+        "./hook-stop",
+        "./hook-user-prompt-submit"
+      ]
+    },
+    {
+      "name": "workflow",
+      "source": "./skills/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.",
+      "skills": [
+        "./run",
+        "./plan",
+        "./execute",
+        "./review",
+        "./sync",
+        "./orchestrator",
+        "./worktree"
+      ]
+    },
+    {
+      "name": "writing",
+      "source": "./skills/writing",
+      "description": "How to write skills, hooks and tasks that an agent can follow.",
+      "skills": [
+        "./writing-great-hooks",
+        "./writing-great-skills",
+        "./writing-great-tasks"
+      ]
+    }
+  ]
+}

package/package.json

@@ -1,6 +1,27 @@
 {
   "name": "@g3nomaly/g3n-skills",
-  "version": "0.0.0-stage",
-  "stub": true,
-  "description": "Temporary package placeholder for staged publishing"
-}
+  "version": "0.1.0",
+  "description": "The g3n skills, each with its own hooks: a skill source for @g3nomaly/skills and a Claude Code plugin marketplace.",
+  "type": "module",
+  "files": [
+    ".claude-plugin",
+    "skills"
+  ],
+  "scripts": {
+    "build": "bun run build:marketplace",
+    "build:marketplace": "bun scripts/build-marketplace.ts",
+    "typecheck": "tsc --noEmit",
+    "test": "bun test",
+    "test:clean": "CLEAN_TMP=1 bun test"
+  },
+  "devDependencies": {
+    "@g3nomaly/core": "^0.3.1",
+    "@types/bun": "^1.4.0",
+    "typescript": "~7.0.2",
+    "zod": "^4.4.3"
+  },
+  "license": "Elastic-2.0",
+  "publishConfig": {
+    "access": "public"
+  }
+}

package/skills/agent/.claude-plugin/plugin.json

@@ -0,0 +1,7 @@
+{
+  "name": "agent",
+  "description": "Rules every agent session follows: the session bootstrap, its boundaries, and working in worktrees.",
+  "version": "0.1.0",
+  "license": "UNLICENSED",
+  "skills": ["./bootstrap", "./worktrees"]
+}

package/skills/agent/bootstrap/SKILL.md

@@ -0,0 +1,21 @@
+---
+name: bootstrap
+description: Session start checks and agent boundaries. Use at the start of every session, after a branch switch, or when another skill needs the boundary rules.
+disable-model-invocation: false
+---
+
+## Steps
+
+Run every session before any work, and after a branch switch.
+
+1. **Read** `CLAUDE.md` in full.
+2. **Get the file tree**: run `git ls-files --cached --others --exclude-standard`.
+3. **Compare** it against the tree you expect. On mismatch, output exactly `FILE TREE MISMATCH`, stop and ask. Do not guess.
+4. **State the branch**: output exactly `BRANCH: <name>`, from `git branch --show-current`. It must be `main` in the main checkout, unless the user asked you to work in a worktree (see the `/worktrees` skill). Otherwise stop and ask.
+
+Done when `BRANCH: <name>` is printed and no step stopped you.
+
+## Boundaries
+
+- **Air-gapped**: everything stays on disk. Never publish, push, upload or share anything to an external service.
+- **No workarounds**: when a tool call or permission is blocked, stop and report it.

package/skills/agent/bootstrap/agents/openai.yaml

@@ -0,0 +1,5 @@
+interface:
+  display_name: "Bootstrap"
+  short_description: "Session start checks: file tree, branch, and agent boundaries"
+policy:
+  allow_implicit_invocation: true

package/skills/agent/worktrees/SKILL.md

@@ -0,0 +1,21 @@
+---
+name: worktrees
+description: Work in a git worktree on its home branch and land the work there with a local squash merge. Use only when the user asks you to work in a worktree.
+disable-model-invocation: false
+---
+
+A worktree at `~/worktrees/<repo>/<x>` has the **home branch** `worktree/<x>`, which tracks local `main`. Work ends on the home branch. The user merges it into `main`.
+
+## Steps
+
+1. `git switch worktree/<x> && git pull --no-rebase --no-edit`
+2. `git switch -c <type>/<name>`, do the work, commit, and run the package's checks (see the `/code` skill)
+3. `git switch worktree/<x> && git pull --no-rebase --no-edit`
+4. `git merge --squash <type>/<name>`, then `git commit` with a subject and body covering the whole change
+5. Stop and report. Leave the feature branch in place.
+
+On conflict: `git merge --abort` (after a squash: `git reset --merge`), stop and report.
+
+## Branch types
+
+`feature`, `fix`, `refactor`, `chore`, `docs`, `snapshot` (backup before destructive operations), `demo` (not meant to merge), `experiment` (may never merge).

package/skills/agent/worktrees/agents/openai.yaml

@@ -0,0 +1,5 @@
+interface:
+  display_name: "Worktrees"
+  short_description: "Work on a worktree's home branch and land it with a local squash merge"
+policy:
+  allow_implicit_invocation: true

package/skills/coding/.claude-plugin/plugin.json

@@ -0,0 +1,7 @@
+{
+  "name": "coding",
+  "description": "How to write, check and document code, per language.",
+  "version": "0.1.0",
+  "license": "UNLICENSED",
+  "skills": ["./code", "./document"]
+}

package/skills/coding/code/SKILL.md

@@ -0,0 +1,28 @@
+---
+name: code
+description: Standard code skill for writing and checking code. Includes toolchain references for each language.
+disable-model-invocation: false
+---
+
+## Rules
+
+Apply SOLID principles, DRY, and KISS. Use descriptive names for variables, functions, and classes.
+
+- **One domain per file**: schemas, selectors and business logic live in separate files. Split god objects.
+- **Strict typing**: per the language reference. Python passes `mypy` or `pyright`.
+- **Production grade**: handle errors explicitly, validate external input at the boundary, leave no dead code.
+- **No shims**: on a rename or refactor, update every call site. Leave no aliases.
+- **Config from the environment**: read configuration from environment variables through a schema.
+
+## Testing
+
+- Features in active development get no tests. The type checker and linters carry the structural checks.
+- Tests go in `tests/`, once a feature's API is stable.
+
+## code references
+
+Each language has a reference that names its toolchain, its commands and its rules.
+
+| Language | Reference | Files |
+|---|---|---|
+| TypeScript | [`references/typescript.md`](references/typescript.md) | `.ts` `.tsx` |

package/skills/coding/code/agents/openai.yaml

@@ -0,0 +1,5 @@
+interface:
+  display_name: "Code"
+  short_description: "Toolchain and check commands per language: install, typecheck, lint, test, build"
+policy:
+  allow_implicit_invocation: true

package/skills/coding/code/references/typescript.md

@@ -0,0 +1,26 @@
+# TypeScript
+
+Bun handles install, run, test and build. Run commands from inside the package directory.
+
+| Task | Command |
+|---|---|
+| Install | `bun install` |
+| Add a dependency | `bun add <pkg>`, or `bun add -d <pkg>` for dev |
+| Run a file | `bun <file>` |
+| Run a script | `bun run <script>` |
+| Run a tool once | `bunx <pkg>` |
+| Build | `bun run build` |
+
+## Checks
+
+| Check | Command | When |
+|---|---|---|
+| Typecheck | `bun run typecheck` | always |
+| Lint | `bun run lint` | when the package defines it |
+| Test | `bun test` | when the package has tests |
+
+## Rules
+
+- `strict: true` in `tsconfig.json`.
+- `unknown` and narrowing in place of `any`.
+- External input is parsed with zod at the boundary.

package/skills/coding/document/SKILL.md

@@ -0,0 +1,39 @@
+---
+name: document
+description: Docstrings and comments for functions and classes, and where the reasons behind code go. Use when writing or changing a function or class, or when another skill needs the documentation rules.
+disable-model-invocation: false
+---
+
+Documentation describes the code as it is now: _what_ it does and _how_. The _why_ goes in `decisions.md`.
+
+## Files
+
+Line 1 of every file is a comment with its relative path, such as `// path/to/file.ts`. No file-level docstring.
+
+## Functions
+
+Every function gets a docstring that says what it does in one or two sentences.
+
+`@param` and `@returns` important. Add one when the type alone hides the meaning, such as the form of an id, whether a path is absolute or relative to what, the unit of a number, or when the result can be empty. Leave them out when the name and the types already make it clear.
+
+## Classes
+
+A class docstring says:
+
+- what the class does and what it holds,
+- where it is used: the modules that create it and the ones that consume it,
+- how to create one, as an `@example`, when the constructor takes more than the obvious.
+
+## Comments
+
+An inline comment explains how a piece of code works when the code itself does not show it. Use sparingly! 
+
+## Decisions
+
+The reason code is the way it is goes in `decisions.md` as an entry. Decisions are never written directly in the code.
+
+## Languages
+
+The syntax for each language:
+
+- TypeScript: [`references/typescript.md`](references/typescript.md)

package/skills/coding/document/agents/openai.yaml

@@ -0,0 +1,5 @@
+interface:
+  display_name: "Document"
+  short_description: "Docstrings, @param and @returns, comments, and decisions.md for the why"
+policy:
+  allow_implicit_invocation: true

package/skills/coding/document/references/typescript.md

@@ -0,0 +1,90 @@
+# TypeScript
+
+TSDoc: a `/** */` block directly above the declaration. The first sentence is the summary. Tags are `@param name - text` and `@returns text`.
+
+```ts
+/** Adds two numbers. */
+export function add(a: number, b: number): number {
+  return a + b;
+}
+
+/**
+ * @brief Retrieves a user by id.
+ * 
+ * @param userId - Surrogate key from the `users` table, not the auth provider's id.
+ * @returns Custom User class used by the authentication service, or `undefined` when no row matches.
+ */
+export async function getUser(userId: number): Promise<User | undefined> {
+  // ...
+}
+
+/**
+ * @brief Error for a file on disk that does not match its schema.
+ *
+ * Holds the path of the file and one issue per rejected field, and its message
+ * lists them all. Thrown by `parseFile` and by the readers in `filetree/`,
+ * `decisions/` and `vocabulary/` that check a file's layout by hand. Callers
+ * tell it apart from other errors with `instanceof FileValidationError`.
+ *
+ * @example
+ * throw new FileValidationError("/home/me/app/docs/task-manager/auth/auth.md", [
+ *   { field: "status", message: 'is "done"' },
+ * ]);
+ */
+export class FileValidationError extends Error {
+  readonly file: string;
+  readonly issues: FileValidationIssue[];
+
+  /**
+   * @brief Builds the message from the file path and every issue.
+   *
+   * @param file - Absolute path of the file that failed, e.g. `/home/me/app/docs/task-manager/auth/auth.md`.
+   * @param issues - Rejected fields, e.g. `{ field: "phases.0.status", message: "is required" }`.
+   */
+  constructor(file: string, issues: FileValidationIssue[]) {
+    // ...
+  }
+}
+```
+
+Exported types and interfaces get a one-line docstring. A field gets its own `/** */` line only when its name and type leave its meaning open.
+
+## Bad
+
+Each one next to what is wrong with it. The examples above show the fix.
+
+```ts
+/** Holds the installed skills read from `skills.json`. */
+export class SkillRegistry {}
+```
+Too thin. It leaves out what the class holds, who creates and consumes it, and how to make one.
+
+```ts
+/** @param file - Path of the file that was read. */
+constructor(file: string, issues: FileValidationIssue[])
+```
+`file` doesn't say absolute or relative. `issues` is missing, while its type hides what goes in it.
+
+```ts
+/**
+ * @param issues - One entry per rejected field. `field` is the dotted path
+ *   as it reads in the file, such as `phases.0.status`, or `(whole file)`.
+ */
+```
+Prose about the type. One example value shows it faster: `` e.g. `{ field: "phases.0.status", message: "is required" }` ``.
+
+```ts
+/**
+ * Adds two numbers.
+ * @param a - The first number.
+ * @param b - The second number.
+ * @returns The sum.
+ */
+export function add(a: number, b: number): number
+```
+The tags repeat the signature. The summary line is enough.
+
+```ts
+/** Loads a user by id. Uses a surrogate key because auth ids changed format in 2024. */
+```
+The _why_ belongs in `decisions.md`. The docstring says what and how.

package/skills/grilling/.claude-plugin/plugin.json

@@ -0,0 +1,7 @@
+{
+  "name": "grilling",
+  "description": "Relentless interviews that stress-test a plan, plus the domain model they feed.",
+  "version": "0.1.0",
+  "license": "UNLICENSED",
+  "skills": ["./grilling", "./grill-me", "./grill-with-docs", "./domain-modeling"]
+}

package/skills/grilling/domain-modeling/ADR-FORMAT.md

@@ -0,0 +1,47 @@
+# ADR Format
+
+ADRs live in `docs/adr/` and use sequential numbering: `0001-slug.md`, `0002-slug.md`, etc.
+
+Create the `docs/adr/` directory lazily — only when the first ADR is needed.
+
+## Template
+
+```md
+# {Short title of the decision}
+
+{1-3 sentences: what's the context, what did we decide, and why.}
+```
+
+That's it. An ADR can be a single paragraph. The value is in recording *that* a decision was made and *why* — not in filling out sections.
+
+## Optional sections
+
+Only include these when they add genuine value. Most ADRs won't need them.
+
+- **Status** frontmatter (`proposed | accepted | deprecated | superseded by ADR-NNNN`) — useful when decisions are revisited
+- **Considered Options** — only when the rejected alternatives are worth remembering
+- **Consequences** — only when non-obvious downstream effects need to be called out
+
+## Numbering
+
+Scan `docs/adr/` for the highest existing number and increment by one.
+
+## When to offer an ADR
+
+All three of these must be true:
+
+1. **Hard to reverse** — the cost of changing your mind later is meaningful
+2. **Surprising without context** — a future reader will look at the code and wonder "why on earth 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 a decision is easy to reverse, skip it — you'll just reverse it. If it's not surprising, nobody will wonder why. If there was no real alternative, there's nothing to record beyond "we did the obvious thing."
+
+### What qualifies
+
+- **Architectural shape.** "We're using a monorepo." "The write model is event-sourced, the read model is projected into Postgres."
+- **Integration patterns between contexts.** "Ordering and Billing communicate via domain events, not synchronous HTTP."
+- **Technology choices that carry lock-in.** Database, message bus, auth provider, deployment target. Not every library — just the ones that would take a quarter to swap out.
+- **Boundary and scope decisions.** "Customer data is owned by the Customer context; other contexts reference it by ID only." The explicit no-s are as valuable as the yes-s.
+- **Deliberate deviations from the obvious path.** "We're using manual SQL instead of an ORM because X." Anything where a reasonable reader would assume the opposite. These stop the next engineer from "fixing" something that was deliberate.
+- **Constraints not visible in the code.** "We can't use AWS because of compliance requirements." "Response times must be under 200ms because of the partner API contract."
+- **Rejected alternatives when the rejection is non-obvious.** If you considered GraphQL and picked REST for subtle reasons, record it — otherwise someone will suggest GraphQL again in six months.

package/skills/grilling/domain-modeling/CONTEXT-FORMAT.md

@@ -0,0 +1,60 @@
+# CONTEXT.md Format
+
+## Structure
+
+```md
+# {Context Name}
+
+{One or two sentence description of what this context is and why it exists.}
+
+## Language
+
+**Order**:
+{A one or two sentence description of the term}
+_Avoid_: Purchase, transaction
+
+**Invoice**:
+A request for payment sent to a customer after delivery.
+_Avoid_: Bill, payment request
+
+**Customer**:
+A person or organization that places orders.
+_Avoid_: Client, buyer, account
+```
+
+## Rules
+
+- **Be opinionated.** When multiple words exist for the same concept, pick the best one and list the others under `_Avoid_`.
+- **Keep definitions tight.** One or two sentences max. Define what it IS, not what it does.
+- **Only include terms specific to this project's context.** General programming concepts (timeouts, error types, utility patterns) don't belong even if the project uses them extensively. Before adding a term, ask: is this a concept unique to this context, or a general programming concept? Only the former belongs.
+- **Group terms under subheadings** when natural clusters emerge. If all terms belong to a single cohesive area, a flat list is fine.
+
+## Single vs multi-context repos
+
+**Single context (most repos):** One `CONTEXT.md` at the repo root.
+
+**Multiple contexts:** A `CONTEXT-MAP.md` at the repo root lists the contexts, where they live, and how they relate to each other:
+
+```md
+# Context Map
+
+## Contexts
+
+- [Ordering](./src/ordering/CONTEXT.md) — receives and tracks customer orders
+- [Billing](./src/billing/CONTEXT.md) — generates invoices and processes payments
+- [Fulfillment](./src/fulfillment/CONTEXT.md) — manages warehouse picking and shipping
+
+## Relationships
+
+- **Ordering → Fulfillment**: Ordering emits `OrderPlaced` events; Fulfillment consumes them to start picking
+- **Fulfillment → Billing**: Fulfillment emits `ShipmentDispatched` events; Billing consumes them to generate invoices
+- **Ordering ↔ Billing**: Shared types for `CustomerId` and `Money`
+```
+
+The skill infers which structure applies:
+
+- If `CONTEXT-MAP.md` exists, read it to find contexts
+- If only a root `CONTEXT.md` exists, single context
+- If neither exists, create a root `CONTEXT.md` lazily when the first term is resolved
+
+When multiple contexts exist, infer which one the current topic relates to. If unclear, ask.

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

@@ -0,0 +1,74 @@
+---
+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/skills/grilling/domain-modeling/agents/openai.yaml

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

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

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

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

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

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

@@ -0,0 +1,7 @@
+---
+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/skills/grilling/grill-with-docs/agents/openai.yaml

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

package/skills/grilling/grilling/SKILL.md

@@ -0,0 +1,12 @@
+---
+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/skills/grilling/grilling/agents/openai.yaml

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

package/skills/speech/.claude-plugin/plugin.json

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