agenthub-multiagent-mcp 1.53.0 → 1.55.0

package/skills/manifest.json

@@ -1,50 +1,50 @@
-{
-  "version": 1,
-  "skills": {
-    "commands/start-session.md": {
-      "hashes": [
-        "22f4eea1f777318212118f2ffaeb8dbd81f94187bc7060707cdf58540e58ed8a",
-        "60970d3cc8dc9edfc4cf23b7980cc142b5ab50c3c7772034bba5d98b5735e33b"
-      ]
-    },
-    "commands/close-session.md": {
-      "hashes": [
-        "e91230277c34661c943eeb3203845559b2456604f3cd6129f8dc54246f4fce29",
-        "b5acb8f0764eee2aee572178500837a2c0acdb5eecd8e6bca87016bb872e303f",
-        "1d4620849c386a586d15bb6aae3cc8011829e9eb77437bb7f52945fba121fab8"
-      ]
-    },
-    "skills/karpathy-guidelines/SKILL.md": {
-      "hashes": [
-        "6e22cc54cb02a5e98ae42d06d9d7292db0c1b43894831b32879beb0166b2aea7"
-      ]
-    },
-    "skills/deploy-staging/SKILL.md": {
-      "hashes": [
-        "aca1c1a5871921cbc9530c13c17d963b262d2e72c67be5326ae65aa0d58847f4",
-        "7194b1a167f43594c0d55249126a97a265009d8ff6515a0caac6d6277fc78f4a"
-      ]
-    },
-    "skills/deploy-vps-openclaw/SKILL.md": {
-      "hashes": [
-        "1c7042b2714d04168b8d7b2afb519674242f18e7223f600b3c8f873bec640202"
-      ]
-    },
-    "skills/code-brain-hook/SKILL.md": {
-      "hashes": [
-        "f5ceff808f8f540e612c18b8ba1c1f5c771df9f64bf1eb84832279e61b140c30",
-        "abf685d5d6770b34297f74dec42ff657b496a087db3f767296633b5db5bfdd4f"
-      ]
-    },
-    "skills/file-bug/SKILL.md": {
-      "hashes": [
-        "814bd58fa387c074b3fc1195b31e0e32d38402510028d4709579ec1f1ed663f1"
-      ]
-    },
-    "skills/multiagent-brainstorm/SKILL.md": {
-      "hashes": [
-        "b3792bb7e44a5f581172d94c5b145ef6c1420e28426f796a38594250a28f1de1"
-      ]
-    }
-  }
-}
+{
+  "version": 1,
+  "skills": {
+    "commands/start-session.md": {
+      "hashes": [
+        "22f4eea1f777318212118f2ffaeb8dbd81f94187bc7060707cdf58540e58ed8a",
+        "60970d3cc8dc9edfc4cf23b7980cc142b5ab50c3c7772034bba5d98b5735e33b"
+      ]
+    },
+    "commands/close-session.md": {
+      "hashes": [
+        "e91230277c34661c943eeb3203845559b2456604f3cd6129f8dc54246f4fce29",
+        "b5acb8f0764eee2aee572178500837a2c0acdb5eecd8e6bca87016bb872e303f",
+        "1d4620849c386a586d15bb6aae3cc8011829e9eb77437bb7f52945fba121fab8"
+      ]
+    },
+    "skills/karpathy-guidelines/SKILL.md": {
+      "hashes": [
+        "6e22cc54cb02a5e98ae42d06d9d7292db0c1b43894831b32879beb0166b2aea7"
+      ]
+    },
+    "skills/deploy-staging/SKILL.md": {
+      "hashes": [
+        "aca1c1a5871921cbc9530c13c17d963b262d2e72c67be5326ae65aa0d58847f4",
+        "7194b1a167f43594c0d55249126a97a265009d8ff6515a0caac6d6277fc78f4a"
+      ]
+    },
+    "skills/deploy-vps-openclaw/SKILL.md": {
+      "hashes": [
+        "1c7042b2714d04168b8d7b2afb519674242f18e7223f600b3c8f873bec640202"
+      ]
+    },
+    "skills/code-brain-hook/SKILL.md": {
+      "hashes": [
+        "f5ceff808f8f540e612c18b8ba1c1f5c771df9f64bf1eb84832279e61b140c30",
+        "abf685d5d6770b34297f74dec42ff657b496a087db3f767296633b5db5bfdd4f"
+      ]
+    },
+    "skills/file-bug/SKILL.md": {
+      "hashes": [
+        "814bd58fa387c074b3fc1195b31e0e32d38402510028d4709579ec1f1ed663f1"
+      ]
+    },
+    "skills/multiagent-brainstorm/SKILL.md": {
+      "hashes": [
+        "b3792bb7e44a5f581172d94c5b145ef6c1420e28426f796a38594250a28f1de1"
+      ]
+    }
+  }
+}

package/skills/skills/code-brain-hook/SKILL.md

@@ -1,61 +1,61 @@
----
-name: code-brain-hook
-description: add-code-brain — opt-in awareness pattern. When the user asks a question about org-wide code or architecture and brain_org_search returns no written knowledge, call brain_code_recall to surface relevant files, symbols, and docs from indexed org repositories before answering.
-license: MIT
----
-
-# Code Brain Hook
-
-The server-side **code brain** clones the configured branch of every registered org repository and indexes the docs + code. The result is queryable via the `brain_code_recall` MCP tool. This skill teaches when and how to use it.
-
-**Trigger conditions** (any one is enough):
-
-- The user asks "how does X work", "where does Y live", "what's the architecture of Z", and the answer should be grounded in actual org code.
-- `brain_org_search` returns zero results for a code- or architecture-shaped query.
-- You're about to suggest an implementation pattern and want to check what already exists in the org first.
-
-**How to use:**
-
-```
-brain_code_recall({
-  query: "payment gateway architecture",
-  k: 5,
-  kinds: ["docs", "symbols"]
-})
-```
-
-Returns a ranked list of `{Result: doc|symbol, RepoID, Path, Kind, TitleOrSymbol, Snippet}`. Use the `Path` to read the actual file (via `Read`) or `intel_code_definition` for deeper symbol info.
-
-**What it is NOT:**
-
-- Not a replacement for `brain_org_search` — that's still the right tool for human-written decisions, conventions, and blockers. Code brain is for code-derived facts.
-- Not a substitute for reading the file. The recall surfaces pointers; the agent reads the source.
-- Not write-capable. Read-only.
-
-**When the code brain is disabled** (operator has explicitly set `AGENTHUB_CODE_BRAIN_ENABLED=false`; default is true), `brain_code_recall` returns `{error: "code_brain_disabled"}`. Treat as a soft signal — fall back to `brain_org_search` and explicit file reads.
-
-## Optional: UserPromptSubmit hook
-
-Operators who want automatic code-aware context can wire a UserPromptSubmit hook that calls `brain_code_recall` on every prompt and prepends top hits. Gated by `AGENTHUB_CODE_HOOK_ENABLED=true`. Off by default — the hook adds latency to every prompt.
-
-Setup (in `~/.claude/settings.json`):
-
-```json
-{
-  "hooks": {
-    "UserPromptSubmit": [
-      {
-        "matcher": ".*",
-        "hooks": [
-          {
-            "type": "command",
-            "command": "agenthub-code-brain-prepend"
-          }
-        ]
-      }
-    ]
-  }
-}
-```
-
-The command reads the prompt from stdin, calls `brain_code_recall` via the MCP server, and writes the augmented prompt back. See `docs/brain-code-recall-mcp.md` for the full reference and example shell wrapper.
+---
+name: code-brain-hook
+description: add-code-brain — opt-in awareness pattern. When the user asks a question about org-wide code or architecture and brain_org_search returns no written knowledge, call brain_code_recall to surface relevant files, symbols, and docs from indexed org repositories before answering.
+license: MIT
+---
+
+# Code Brain Hook
+
+The server-side **code brain** clones the configured branch of every registered org repository and indexes the docs + code. The result is queryable via the `brain_code_recall` MCP tool. This skill teaches when and how to use it.
+
+**Trigger conditions** (any one is enough):
+
+- The user asks "how does X work", "where does Y live", "what's the architecture of Z", and the answer should be grounded in actual org code.
+- `brain_org_search` returns zero results for a code- or architecture-shaped query.
+- You're about to suggest an implementation pattern and want to check what already exists in the org first.
+
+**How to use:**
+
+```
+brain_code_recall({
+  query: "payment gateway architecture",
+  k: 5,
+  kinds: ["docs", "symbols"]
+})
+```
+
+Returns a ranked list of `{Result: doc|symbol, RepoID, Path, Kind, TitleOrSymbol, Snippet}`. Use the `Path` to read the actual file (via `Read`) or `intel_code_definition` for deeper symbol info.
+
+**What it is NOT:**
+
+- Not a replacement for `brain_org_search` — that's still the right tool for human-written decisions, conventions, and blockers. Code brain is for code-derived facts.
+- Not a substitute for reading the file. The recall surfaces pointers; the agent reads the source.
+- Not write-capable. Read-only.
+
+**When the code brain is disabled** (operator has explicitly set `AGENTHUB_CODE_BRAIN_ENABLED=false`; default is true), `brain_code_recall` returns `{error: "code_brain_disabled"}`. Treat as a soft signal — fall back to `brain_org_search` and explicit file reads.
+
+## Optional: UserPromptSubmit hook
+
+Operators who want automatic code-aware context can wire a UserPromptSubmit hook that calls `brain_code_recall` on every prompt and prepends top hits. Gated by `AGENTHUB_CODE_HOOK_ENABLED=true`. Off by default — the hook adds latency to every prompt.
+
+Setup (in `~/.claude/settings.json`):
+
+```json
+{
+  "hooks": {
+    "UserPromptSubmit": [
+      {
+        "matcher": ".*",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "agenthub-code-brain-prepend"
+          }
+        ]
+      }
+    ]
+  }
+}
+```
+
+The command reads the prompt from stdin, calls `brain_code_recall` via the MCP server, and writes the augmented prompt back. See `docs/brain-code-recall-mcp.md` for the full reference and example shell wrapper.

package/skills/skills/file-bug/SKILL.md

@@ -1,75 +1,75 @@
----
-name: file-bug
-description: File a reproducible bug as a first-class AgentHub ticket via the report_bug MCP tool. Use when you hit a defect, a failing test/CI step, or any reproducible misbehavior worth tracking — captures severity, repro steps, environment, and a defect lifecycle.
-license: MIT
----
-
-# File a Bug
-
-AgentHub has a first-class bug workflow (`add-bug-tracking-workflow`). A bug is a
-`type=bug` ticket carrying **severity**, **reproduction steps**, an
-**environment** tag, and a **defect lifecycle** (`bug_state`) that is separate
-from work `status`. Use this skill whenever you find a reproducible defect worth
-tracking — a failing test, a broken endpoint, a CI step that fails, or any
-misbehavior you can describe steps for.
-
-## File it with `report_bug`
-
-Call the `report_bug` MCP tool. `repro_steps` is **required**; severity defaults
-to `sev3` if omitted.
-
-```jsonc
-report_bug({
-  "title": "login returns 500",
-  "repro_steps": "1. POST /login with valid creds\n2. observe 500",
-  "severity": "sev1",        // optional (default sev3)
-  "environment": "prod",     // optional — e.g. "staging", "prod", "v1.12.0"
-  "expected": "200 + session cookie",   // optional → folded into description
-  "actual": "500 Internal Server Error" // optional → folded into description
-})
-```
-
-The tool returns the new bug's `id`/`key`. With no `story_id`/`openspec_change`
-the bug is auto-anchored under the project's reserved **"Bugs"** epic+story — you
-don't need to know the hierarchy. `report_bug` is a **reversible** internal
-action, so active employees (including `qa-triage`) may call it without
-break-glass.
-
-> Requires `agent_register` first (the project binding is read from local state).
-> A `400 repro_steps_required` means you left repro steps empty — always include
-> concrete, numbered steps.
-
-## Write a good bug
-
-- **Title**: one line, specific. "Roadmap PDF export 500s on >50 entries", not "PDF broken".
-- **repro_steps**: numbered, minimal, deterministic. Someone else should be able
-  to follow them and see the same failure.
-- **severity** (impact, distinct from priority):
-
-  | Severity | Meaning |
-  |----------|---------|
-  | `sev1` | Critical — outage, data loss, security |
-  | `sev2` | High — major feature broken, no workaround |
-  | `sev3` | Medium — feature broken, workaround exists (default) |
-  | `sev4` | Low — cosmetic / minor |
-
-- **environment**: where you saw it (`staging`, `prod`, a version/commit).
-- **expected** / **actual**: the delta, when not obvious from repro steps.
-
-## Lifecycle (don't overthink it at filing time)
-
-Filing always starts at `bug_state=unverified`. Triage walks it forward with
-`update_ticket` (`bug_state=...`):
-`unverified → verified → in_progress → fixed → verified_fixed → closed`
-(`wont_fix`/`duplicate` are terminal; `reopened` revives a terminal bug to
-`verified`). Transitions are validated server-side — an illegal jump returns
-`409 invalid_bug_transition`. You usually only set `unverified` (automatic) at
-filing time and leave the rest to triage / the dashboard.
-
-## Other paths (same result)
-
-- **Dashboard**: the Issues page → **Open Bugs** board has a *File a bug* form.
-- **HTTP**: `POST /api/projects/{projectId}/bugs` with `{title, repro_steps, severity?, environment?}`.
-- **Reclassify a task you already created**: `update_ticket(type="bug", severity=..., repro_steps=...)` promotes it (defaults `bug_state=unverified`).
-
-Full reference: the `bug-tracking-guide` doc.
+---
+name: file-bug
+description: File a reproducible bug as a first-class AgentHub ticket via the report_bug MCP tool. Use when you hit a defect, a failing test/CI step, or any reproducible misbehavior worth tracking — captures severity, repro steps, environment, and a defect lifecycle.
+license: MIT
+---
+
+# File a Bug
+
+AgentHub has a first-class bug workflow (`add-bug-tracking-workflow`). A bug is a
+`type=bug` ticket carrying **severity**, **reproduction steps**, an
+**environment** tag, and a **defect lifecycle** (`bug_state`) that is separate
+from work `status`. Use this skill whenever you find a reproducible defect worth
+tracking — a failing test, a broken endpoint, a CI step that fails, or any
+misbehavior you can describe steps for.
+
+## File it with `report_bug`
+
+Call the `report_bug` MCP tool. `repro_steps` is **required**; severity defaults
+to `sev3` if omitted.
+
+```jsonc
+report_bug({
+  "title": "login returns 500",
+  "repro_steps": "1. POST /login with valid creds\n2. observe 500",
+  "severity": "sev1",        // optional (default sev3)
+  "environment": "prod",     // optional — e.g. "staging", "prod", "v1.12.0"
+  "expected": "200 + session cookie",   // optional → folded into description
+  "actual": "500 Internal Server Error" // optional → folded into description
+})
+```
+
+The tool returns the new bug's `id`/`key`. With no `story_id`/`openspec_change`
+the bug is auto-anchored under the project's reserved **"Bugs"** epic+story — you
+don't need to know the hierarchy. `report_bug` is a **reversible** internal
+action, so active employees (including `qa-triage`) may call it without
+break-glass.
+
+> Requires `agent_register` first (the project binding is read from local state).
+> A `400 repro_steps_required` means you left repro steps empty — always include
+> concrete, numbered steps.
+
+## Write a good bug
+
+- **Title**: one line, specific. "Roadmap PDF export 500s on >50 entries", not "PDF broken".
+- **repro_steps**: numbered, minimal, deterministic. Someone else should be able
+  to follow them and see the same failure.
+- **severity** (impact, distinct from priority):
+
+  | Severity | Meaning |
+  |----------|---------|
+  | `sev1` | Critical — outage, data loss, security |
+  | `sev2` | High — major feature broken, no workaround |
+  | `sev3` | Medium — feature broken, workaround exists (default) |
+  | `sev4` | Low — cosmetic / minor |
+
+- **environment**: where you saw it (`staging`, `prod`, a version/commit).
+- **expected** / **actual**: the delta, when not obvious from repro steps.
+
+## Lifecycle (don't overthink it at filing time)
+
+Filing always starts at `bug_state=unverified`. Triage walks it forward with
+`update_ticket` (`bug_state=...`):
+`unverified → verified → in_progress → fixed → verified_fixed → closed`
+(`wont_fix`/`duplicate` are terminal; `reopened` revives a terminal bug to
+`verified`). Transitions are validated server-side — an illegal jump returns
+`409 invalid_bug_transition`. You usually only set `unverified` (automatic) at
+filing time and leave the rest to triage / the dashboard.
+
+## Other paths (same result)
+
+- **Dashboard**: the Issues page → **Open Bugs** board has a *File a bug* form.
+- **HTTP**: `POST /api/projects/{projectId}/bugs` with `{title, repro_steps, severity?, environment?}`.
+- **Reclassify a task you already created**: `update_ticket(type="bug", severity=..., repro_steps=...)` promotes it (defaults `bug_state=unverified`).
+
+Full reference: the `bug-tracking-guide` doc.