npm - gossipcat - Versions diffs - 0.1.0 - Mend

gossipcat 0.1.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (30) hide show

package/LICENSE +21 -0
package/README.md +720 -0
package/dist-dashboard/assets/banner.png +0 -0
package/dist-dashboard/assets/gossip-mini.png +0 -0
package/dist-dashboard/assets/gossipcat.png +0 -0
package/dist-dashboard/assets/index-BvqFkH-m.css +1 -0
package/dist-dashboard/assets/index-Dsv-K6u_.js +65 -0
package/dist-dashboard/favicon.png +0 -0
package/dist-dashboard/index.html +31 -0
package/dist-mcp/default-rules/gossipcat-rules.md +135 -0
package/dist-mcp/default-skills/api-design.md +32 -0
package/dist-mcp/default-skills/catalog.json +101 -0
package/dist-mcp/default-skills/ci-cd.md +32 -0
package/dist-mcp/default-skills/code-review.md +40 -0
package/dist-mcp/default-skills/debugging.md +42 -0
package/dist-mcp/default-skills/documentation.md +31 -0
package/dist-mcp/default-skills/frontend.md +32 -0
package/dist-mcp/default-skills/implementation.md +39 -0
package/dist-mcp/default-skills/infrastructure.md +32 -0
package/dist-mcp/default-skills/memory-retrieval.md +43 -0
package/dist-mcp/default-skills/research.md +44 -0
package/dist-mcp/default-skills/security-audit.md +47 -0
package/dist-mcp/default-skills/system-design.md +42 -0
package/dist-mcp/default-skills/testing.md +38 -0
package/dist-mcp/default-skills/typescript.md +32 -0
package/dist-mcp/default-skills/ui-design.md +33 -0
package/dist-mcp/default-skills/verification.md +49 -0
package/dist-mcp/mcp-server.js +40878 -0
package/package.json +50 -0
package/scripts/postinstall.js +63 -0

package/dist-dashboard/favicon.png ADDED Viewed

Binary file

package/dist-dashboard/index.html ADDED Viewed

@@ -0,0 +1,31 @@
+<!DOCTYPE html>
+<html lang="en">
+<head>
+  <meta charset="UTF-8" />
+  <meta name="viewport" content="width=device-width, initial-scale=1.0" />
+  <title>Gossipcat — Multi-Agent AI Orchestration Dashboard</title>
+  <meta name="description" content="Monitor and orchestrate your AI agent team. Real-time consensus reviews, performance signals, agent memory, and live task tracking — all in one place." />
+  <meta name="keywords" content="AI agents, multi-agent orchestration, LLM, Claude, Gemini, code review, consensus, gossipcat" />
+  <meta name="author" content="Gossipcat" />
+  <meta name="robots" content="noindex, nofollow" />
+  <!-- Open Graph -->
+  <meta property="og:type" content="website" />
+  <meta property="og:title" content="Gossipcat — Multi-Agent AI Orchestration Dashboard" />
+  <meta property="og:description" content="Monitor and orchestrate your AI agent team. Real-time consensus reviews, performance signals, agent memory, and live task tracking." />
+  <meta property="og:image" content="/dashboard/assets/gossip-mini.png" />
+  <!-- Theme -->
+  <meta name="theme-color" content="#8b5cf6" />
+  <meta name="color-scheme" content="dark" />
+  <link rel="icon" type="image/png" href="/dashboard/favicon.png" />
+  <link rel="preconnect" href="https://fonts.googleapis.com" />
+  <link href="https://fonts.googleapis.com/css2?family=Inter:wght@400;500;600;700&family=JetBrains+Mono:wght@400;500;600;700&display=swap" rel="stylesheet" />
+  <script type="module" crossorigin src="/dashboard/assets/index-Dsv-K6u_.js"></script>
+  <link rel="stylesheet" crossorigin href="/dashboard/assets/index-BvqFkH-m.css">
+</head>
+<body>
+  <div id="root"></div>
+</body>
+</html>

package/dist-mcp/default-rules/gossipcat-rules.md ADDED Viewed

@@ -0,0 +1,135 @@
+# Gossipcat — Multi-Agent Orchestration
+The orchestrator role and dispatch rule (with exceptions) is loaded dynamically via `gossip_status()` — see the "## Your Role" section in its output. This file covers team setup, dispatch flows, consensus workflow, and memory.
+## Team Setup
+When the user asks to set up agents, review code with multiple agents, or build with a team, use the gossipcat MCP tools.
+### Creating agents
+Use `gossip_setup` with an agents array. Each agent can be:
+- **type: "native"** — Creates a Claude Code subagent (.claude/agents/*.md) that ALSO connects to the gossipcat relay. Works both as a native Agent() and via gossip_dispatch(). Supports consensus cross-review.
+- **type: "custom"** — Any provider (anthropic, openai, google, local). Only accessible via gossip_dispatch().
+**Native agent requirements:** Native agents need TWO files to work fully:
+1. `.gossip/config.json` entry — with explicit `skills` array and `"native": true`
+2. `.claude/agents/<id>.md` — with frontmatter (name, model, description, tools) and prompt
+`gossip_setup` creates both automatically. Mid-session agent changes require `/mcp` reconnect.
+### Dispatching work
+**Single-agent tasks** (default):
+```
+gossip_run(agent_id: "<id>", task: "Implement X")
+```
+`gossip_run` is the preferred dispatch. Do NOT use raw Agent() for gossipcat tasks.
+**Active polling — do NOT wait passively for notifications:**
+After dispatching background native agents, wait ~60-90 seconds, then actively check their status:
+1. Call `gossip_progress(task_ids: [...])` to see live completion state
+2. If complete, read the output file directly (path returned in Agent() response as `output_file`)
+3. Then call `gossip_relay(task_id, result)` immediately
+Do NOT sit idle waiting for task-notification events — the notification system can lag 5-10 minutes. Always poll proactively after a short wait.
+**Write modes:** `gossip_run(agent_id, task, write_mode: "scoped", scope: "./src")`
+**Parallel:** `gossip_dispatch(mode:"parallel", tasks) → gossip_collect(task_ids)`
+**Plan → Execute:** `gossip_plan(task) → gossip_dispatch(mode:"parallel", tasks) → gossip_collect(ids)`
+**Available agents and dispatch decision rules** are loaded dynamically from `gossip_status()` — call it for the live team roster, performance scores, and the multi-agent vs single-agent decision table. Do not duplicate that content here.
+## Consensus Workflow — The Complete Flow
+### Step 1: Dispatch
+```
+gossip_dispatch(mode: "consensus", tasks: [
+  { agent_id: "<reviewer>", task: "Review X for security" },
+  { agent_id: "<researcher>", task: "Review X for architecture" },
+  { agent_id: "<tester>", task: "Review X for test coverage" },
+])
+```
+### Step 2: Execute native agents, then relay results
+`gossip_relay(task_id: "<id>", result: "<agent output>")`
+### Step 3: Collect with cross-review
+`gossip_collect(task_ids, consensus: true, timeout_ms: 300000)`
+Returns: CONFIRMED, DISPUTED, UNIQUE, UNVERIFIED, NEW tagged findings.
+### Step 4: Verify and record signals IMMEDIATELY
+For EACH finding, read the actual code. Record signals AS YOU VERIFY:
+```
+gossip_signals(signals: [
+  { signal: "unique_confirmed", agent_id: "reviewer", finding: "XSS in template", finding_id: "<consensus_id>:reviewer:f1" },
+  { signal: "hallucination_caught", agent_id: "reviewer", finding: "Claimed X but code shows Y", finding_id: "<consensus_id>:reviewer:f2", evidence: "code at file.ts:42 shows Y not X" },
+  { signal: "agreement", agent_id: "reviewer", counterpart_id: "researcher", finding: "Both found it", finding_id: "<consensus_id>:reviewer:f3" },
+])
+```
+**CRITICAL:** Record `hallucination_caught` IMMEDIATELY when a finding is wrong. Don't batch — record inline as you verify. This keeps agent scores accurate.
+### Step 5: Verify ALL UNVERIFIED findings.
+UNVERIFIED does not mean "skip." It means the cross-reviewer couldn't check it — YOU can.
+For each UNVERIFIED finding: grep/read the cited code or identifiers, then record the signal.
+Do NOT present raw consensus results with unverified findings to the user.
+### Step 6: Fix confirmed issues (only after all signals recorded).
+⛔ **CHECKPOINT — do not proceed to fixes until signals are recorded.**
+If you find yourself writing code or editing files before calling `gossip_signals`, STOP.
+Signal recording is not optional cleanup — it is part of the verification step, not after it.
+The correct order is always: verify finding → record signal → next finding → ... → then fix.
+## Performance Signals & Agent Scores
+Call `gossip_scores()` to see: accuracy (0-1), uniqueness (0-1), dispatchWeight (0.5-1.5).
+- High-accuracy agents → solo tasks, primary reviewers
+- High-uniqueness, low-accuracy → always use in consensus, never solo
+- Check scores periodically to track improvement
+## Memory System
+Memory persists across sessions automatically:
+- `.gossip/agents/<id>/memory/knowledge/*.md` — cognitive summaries
+- `.gossip/agents/_project/memory/knowledge/` — shared cross-agent context
+- `.gossip/next-session.md` — session continuity priorities
+**Call `gossip_session_save()` before ending your session.** Without it, the next session starts cold.
+## Dashboard
+Use `gossip_status()` for URL and key. Tabs: Overview, Agents, Consensus, Skills, Memory.
+## Subagent Override (IMPORTANT)
+When ANY skill or workflow (including subagent-driven-development, executing-plans, or
+any custom skill) instructs you to dispatch work via the Agent() tool, use `gossip_run`
+instead. This ensures tasks appear in the dashboard, agent memory is written, and
+performance signals are recorded.
+**Flow:** `gossip_run(agent_id, task)` → returns Agent() instructions for native agents →
+execute the Agent() → `gossip_relay(task_id, result)` to close the loop.
+**Exception:** `gossip_dispatch(mode:"consensus")` already handles its own native Agent() calls —
+don't double-wrap those.
+**Why:** Raw Agent() bypasses the gossipcat pipeline. Tasks won't appear in the activity
+feed, no memory is written, no signals recorded. The agent effectively works off-grid.
+## Native Agent Relay Rule
+When dispatching native agents: gossip_dispatch → Agent() → gossip_relay. Never skip the relay call.
+## Permissions
+Auto-allow writes: `{ "permissions": { "allow": ["Edit", "Write", "Bash(npm *)"] } }`
+## Sandbox Enforcement
+`write_mode: "scoped"` and `write_mode: "worktree"` are **advisory** at the Claude Code harness layer. The Edit/Write tools accept absolute paths anywhere on the filesystem and do not enforce containment. Until that ships, gossipcat adds soft enforcement via two mitigations:
+1. **Prompt sanitization** — task descriptions for scoped/worktree dispatches are rewritten to use relative project paths before being handed to the Agent tool. Removes the most common accidental escape vector (the orchestrator embedding absolute paths out of habit).
+2. **Post-task path audit** — after the agent reports done, `gossip_relay` runs `git status --porcelain` and compares the modified files against the declared scope. Violations are recorded as `boundary_escape` entries in `.gossip/boundary-escapes.jsonl` and emit a `disagreement` signal with `category: "trust_boundaries"`.
+Configure via `sandboxEnforcement` in `.gossip/config.json`: `"off"` (skip both), `"warn"` (default — sanitize and audit, accept results with a warning), `"block"` (sanitize, audit, and refuse to record results that escape the boundary — task is marked failed).
+Both mitigations are best-effort. A determined or compromised agent can still bypass them by shelling out or reconstructing absolute paths inside its own logic. The durable fix is a Claude Code harness change that enforces the boundary at the Edit/Write tool layer.

package/dist-mcp/default-skills/api-design.md ADDED Viewed

@@ -0,0 +1,32 @@
+# API Design
+> Design REST APIs that are consistent, predictable, and easy to consume.
+## What You Do
+- Apply REST conventions correctly: resources, HTTP verbs, status codes
+- Design error responses that tell clients what went wrong and how to recover
+- Define pagination, filtering, and versioning before the first endpoint ships
+- Keep the API surface minimal — add fields when needed, removal is a breaking change
+- Think from the client perspective: would a new developer understand this without docs?
+## Approach
+1. **Resources** — use nouns, not verbs: `/users`, not `/getUsers`
+2. **HTTP verbs** — GET (read), POST (create), PUT (full replace), PATCH (partial update), DELETE
+3. **Status codes** — 200 (ok), 201 (created), 204 (no content), 400 (bad request), 401 (unauth), 403 (forbidden), 404 (not found), 409 (conflict), 422 (validation), 429 (rate limited), 500 (server error)
+4. **Error shape** — always return `{ error: { code: string, message: string, details?: unknown } }`
+5. **Pagination** — cursor-based for large/live datasets; offset for simple admin UIs
+6. **Versioning** — URL prefix (`/v1/`) for major versions; additive changes are non-breaking
+7. **Validation** — reject invalid input at the boundary with a 422 and field-level error details
+## Output Format
+When designing or reviewing an API:
+- List each endpoint: `METHOD /path — purpose`
+- Flag any inconsistencies with REST conventions
+- Note any missing error cases
+## Don't
+- Don't return 200 for errors — ever
+- Don't use query params for actions (use POST with a body)
+- Don't expose internal IDs, database types, or implementation details in responses
+- Don't add breaking changes to existing endpoints — add a new version
+- Don't return unbounded arrays — always paginate lists

package/dist-mcp/default-skills/catalog.json ADDED Viewed

@@ -0,0 +1,101 @@
+{
+  "version": 1,
+  "skills": [
+    {
+      "name": "security_audit",
+      "description": "OWASP Top 10, injection, auth, secrets, path traversal, error leakage, DoS, resource exhaustion",
+      "keywords": ["security", "vulnerability", "injection", "auth", "owasp", "secrets", "dos", "rate-limit"],
+      "categories": ["review", "security"]
+    },
+    {
+      "name": "dos_resilience",
+      "description": "DoS vectors, rate limiting, resource exhaustion, backpressure, payload limits, connection caps",
+      "keywords": ["dos", "rate-limit", "resource", "exhaustion", "websocket", "payload", "memory", "connection"],
+      "categories": ["review", "security"]
+    },
+    {
+      "name": "code_review",
+      "description": "Bug finding, edge cases, naming, structure, error handling",
+      "keywords": ["review", "bugs", "quality", "patterns", "logic"],
+      "categories": ["review"]
+    },
+    {
+      "name": "testing",
+      "description": "AAA pattern, unit/integration/e2e, mocking, deterministic tests, behavior-focused",
+      "keywords": ["test", "unit", "integration", "e2e", "mock", "coverage"],
+      "categories": ["implementation", "testing"]
+    },
+    {
+      "name": "typescript",
+      "description": "Strict typing, interface-first, discriminated unions, readonly, type safety",
+      "keywords": ["typescript", "types", "generics", "interfaces", "strict"],
+      "categories": ["implementation"]
+    },
+    {
+      "name": "implementation",
+      "description": "TDD, small functions, error handling, test coverage, <300 line files",
+      "keywords": ["implement", "build", "feature", "tdd", "code"],
+      "categories": ["implementation"]
+    },
+    {
+      "name": "debugging",
+      "description": "Reproduce, isolate, hypothesize, test, fix, verify with regression tests",
+      "keywords": ["debug", "bug", "error", "trace", "root-cause", "reproduce"],
+      "categories": ["investigation"]
+    },
+    {
+      "name": "research",
+      "description": "Source prioritization, triangulation, conflicting info, gaps analysis, BLUF answers",
+      "keywords": ["research", "docs", "compare", "analyze", "summarize"],
+      "categories": ["investigation"]
+    },
+    {
+      "name": "documentation",
+      "description": "API docs, guides, ADRs, README, changelog, stale doc detection",
+      "keywords": ["docs", "readme", "changelog", "adr", "guide"],
+      "categories": ["documentation"]
+    },
+    {
+      "name": "api_design",
+      "description": "REST conventions, HTTP verbs, status codes, error shapes, pagination, versioning",
+      "keywords": ["api", "rest", "endpoint", "http", "pagination", "versioning"],
+      "categories": ["design"]
+    },
+    {
+      "name": "system_design",
+      "description": "Components, data flow, failure modes, trade-offs, scale, graceful degradation",
+      "keywords": ["architecture", "design", "scale", "components", "trade-offs"],
+      "categories": ["design"]
+    },
+    {
+      "name": "verification",
+      "description": "Evidence-based analysis, quote exact code, read before cite, no hallucination",
+      "keywords": ["verify", "evidence", "quote", "cite", "audit"],
+      "categories": ["review"]
+    },
+    {
+      "name": "ui_design",
+      "description": "Component hierarchy, layout systems, accessibility, responsive design, visual consistency",
+      "keywords": ["ui", "ux", "design", "accessibility", "responsive", "layout", "components"],
+      "categories": ["design"]
+    },
+    {
+      "name": "frontend",
+      "description": "React/Vue/Svelte components, state management, rendering optimization, client-side routing",
+      "keywords": ["frontend", "react", "components", "hooks", "rendering", "css", "tailwind"],
+      "categories": ["implementation"]
+    },
+    {
+      "name": "ci_cd",
+      "description": "Build pipelines, GitHub Actions, caching, deployment strategies, secret management",
+      "keywords": ["ci", "cd", "pipeline", "deploy", "github-actions", "docker", "build"],
+      "categories": ["infrastructure"]
+    },
+    {
+      "name": "infrastructure",
+      "description": "IaC, containers, networking, monitoring, alerting, scaling, disaster recovery",
+      "keywords": ["infra", "terraform", "kubernetes", "docker", "monitoring", "cloud", "networking"],
+      "categories": ["infrastructure"]
+    }
+  ]
+}

package/dist-mcp/default-skills/ci-cd.md ADDED Viewed

@@ -0,0 +1,32 @@
+# CI/CD
+> Design and maintain pipelines that are fast, reliable, and secure.
+## What You Do
+- Configure build, test, and deploy pipelines (GitHub Actions, GitLab CI, etc.)
+- Optimize pipeline speed: caching, parallelism, conditional steps
+- Manage environment variables, secrets, and deployment credentials
+- Set up staging, preview, and production environments
+- Monitor deployment health and rollback strategies
+## Approach
+1. Every push should trigger lint + typecheck + tests — no exceptions
+2. Cache dependencies and build artifacts aggressively
+3. Run expensive steps (e2e, security scans) only on PR and main branch
+4. Deploy with zero-downtime strategies (rolling, blue-green, canary)
+5. Every secret is injected at runtime — never committed, never logged
+## Review Checklist
+- [ ] Pipeline runs in under 5 minutes for the common case
+- [ ] Secrets are in the CI provider's vault — not in env files or code
+- [ ] Failed steps produce actionable error messages, not just exit codes
+- [ ] Build artifacts are deterministic — same input produces same output
+- [ ] Rollback is a single action, not a multi-step manual process
+- [ ] Branch protection rules enforce CI pass before merge
+## Don't
+- Don't allow deploys that skip tests
+- Don't use `latest` tags for base images — pin versions
+- Don't store secrets in pipeline config files
+- Don't make pipelines that only the author understands — document non-obvious steps
+- Don't run the entire test suite on every commit if you can scope by changed files

package/dist-mcp/default-skills/code-review.md ADDED Viewed

@@ -0,0 +1,40 @@
+# Code Review
+> Perform thorough, opinionated code reviews with clear severity levels and actionable feedback.
+## What You Do
+- Identify bugs, logic errors, and security issues before they reach production
+- Enforce consistency with the existing codebase style and patterns
+- Flag code that is correct but will be hard to maintain
+- Praise what is done well — reviews should be balanced
+- Prioritize findings so the author knows what must change vs. what is optional
+## Approach
+1. Read the full diff before commenting on any single line
+2. Check correctness first: does it do what it claims?
+3. Check edge cases: null, empty, concurrent, large input
+4. Check error handling: are errors surfaced or silently swallowed?
+5. Check test coverage: are the new paths tested?
+6. Check naming and structure: will this make sense in 6 months?
+7. Summarize findings at the top before inline comments
+## Output Format
+```
+## Summary
+[1-2 sentence overview of the change and overall assessment]
+## Findings
+- [critical] <file>:<line> — <issue and fix>
+- [warning]  <file>:<line> — <issue and suggestion>
+- [style]    <file>:<line> — <optional improvement>
+## Positives
+- [what was done well]
+```
+## Don't
+- Don't nitpick style issues that a linter should catch
+- Don't leave vague comments like "this could be better" — say how
+- Don't approve PRs with unresolved critical findings
+- Don't comment on every line — group related issues
+- Don't skip reading the tests

package/dist-mcp/default-skills/debugging.md ADDED Viewed

@@ -0,0 +1,42 @@
+# Debugging
+> Systematically find and fix bugs without guessing.
+## What You Do
+- Follow a repeatable process: reproduce → isolate → hypothesize → test → fix → verify
+- Form one hypothesis at a time and test it before moving to the next
+- Distinguish between symptoms and root causes
+- Document findings so the bug cannot silently recur
+- Add a regression test after every fix
+## Approach
+1. **Reproduce** — get a minimal, consistent reproduction; if it's flaky, find the trigger
+2. **Isolate** — bisect to the smallest unit that shows the failure (binary search the call stack)
+3. **Read the error** — read the full stack trace; the actual error is often not the first line
+4. **Hypothesize** — form one specific, falsifiable hypothesis about the cause
+5. **Test** — add a failing test or log that confirms/refutes the hypothesis
+6. **Fix** — change the smallest amount of code that resolves the root cause
+7. **Verify** — run the reproduction again; confirm no regression in related tests
+## Output Format
+When reporting a debugging session:
+```
+## Root Cause
+[One sentence: what was wrong and why]
+## How It Was Found
+[The reproduction steps and the hypothesis that proved correct]
+## Fix Applied
+[File and change summary]
+## Regression Test Added
+[Yes/No and location]
+```
+## Don't
+- Don't make multiple changes at once — you won't know which one fixed it
+- Don't trust logs that could be stale or cached — add fresh instrumentation
+- Don't fix the symptom when the root cause is elsewhere
+- Don't skip the regression test — the bug will return
+- Don't assume the bug is in the code you just changed

package/dist-mcp/default-skills/documentation.md ADDED Viewed

@@ -0,0 +1,31 @@
+# Documentation
+> Write documentation that answers real questions without duplicating the code.
+## What You Do
+- Document the why, not the what — code shows what; docs explain intent
+- Write for the next developer, not the current one
+- Keep docs close to the code so they rot at the same rate
+- Flag when existing docs are wrong or stale
+- Distinguish between API docs, guides, and architecture decision records (ADRs)
+## Approach
+1. **Public API** — every exported function needs a JSDoc comment: purpose, params, return, throws
+2. **Non-obvious logic** — add an inline comment when the code is correct but the reason isn't obvious
+3. **Architecture** — write an ADR when a significant technical decision is made
+4. **README** — cover: what this is, how to install, how to run, how to test
+5. **Changelogs** — use conventional commits so changelogs can be generated automatically
+6. **Diagrams** — prefer text-based (Mermaid) over image files so they stay in version control
+## Output Format
+When writing or auditing documentation:
+- List what is documented, what is missing, and what is stale
+- Flag public APIs with no docs as **[missing]**
+- Flag docs that contradict the code as **[stale]**
+## Don't
+- Don't document what the code already says clearly — no `// increment i by 1`
+- Don't write a guide for something that should be a better API
+- Don't let README setup steps drift from the actual process — test them
+- Don't add `TODO:` comments without a ticket or a date — they become permanent
+- Don't document internal implementation details as public API

package/dist-mcp/default-skills/frontend.md ADDED Viewed

@@ -0,0 +1,32 @@
+# Frontend
+> Build frontend code that is performant, accessible, and maintainable.
+## What You Do
+- Implement UI components with correct state management and lifecycle
+- Structure component trees for reuse and testability
+- Handle client-side routing, data fetching, and caching
+- Optimize rendering: avoid unnecessary re-renders, lazy load where appropriate
+- Write component tests that test behavior, not implementation details
+## Approach
+1. Define the component's props/interface before writing JSX/HTML
+2. Separate data fetching from presentation — container vs. display components
+3. Use controlled components for forms, uncontrolled only when performance demands it
+4. Handle all async states: idle, loading, success, error
+5. Test user interactions, not internal state changes
+## Review Checklist
+- [ ] Components accept props with clear types — no `any`
+- [ ] Side effects are in `useEffect` (or equivalent) with proper cleanup
+- [ ] Lists have stable, unique keys — not array indices
+- [ ] Event handlers don't create new closures on every render unnecessarily
+- [ ] CSS/styles follow the project's approach (modules, Tailwind, styled-components)
+- [ ] Bundle impact considered — no heavy library for a simple task
+## Don't
+- Don't put business logic in components — extract to hooks or utilities
+- Don't fetch data in deeply nested children — lift to the nearest boundary
+- Don't use `dangerouslySetInnerHTML` without sanitization
+- Don't ignore the existing component library and rebuild from scratch
+- Don't inline styles for things that should be in the design system

package/dist-mcp/default-skills/implementation.md ADDED Viewed

@@ -0,0 +1,39 @@
+# Implementation
+> Write clean, correct, testable code on the first attempt.
+## What You Do
+- Implement features with clarity and correctness as the primary goals
+- Write tests before or alongside implementation (TDD preferred)
+- Keep functions small, named for what they do, not how they do it
+- Handle errors explicitly — don't let failures silently propagate
+- Respect the existing codebase conventions before inventing new ones
+## Approach
+1. Understand the requirement fully before writing a line of code
+2. Define the interface (types, function signatures) before the body
+3. Write the happy path first, then error cases
+4. Add tests that cover: normal input, edge cases, error conditions
+5. Check file length — if over 300 lines, split responsibilities
+6. Read the diff before marking done: would you approve this in a review?
+## Before Submitting Checklist
+- [ ] All new paths have tests
+- [ ] No `console.log` or debug artifacts left in
+- [ ] Error messages are human-readable, not internal noise
+- [ ] No code is commented out — delete it
+- [ ] Imports are used — no dead imports
+- [ ] Function names describe the action, not the mechanism
+## Output Format
+When reporting implementation work:
+- List files created or modified
+- Note any assumptions made about requirements
+- Flag anything that should be followed up (tech debt, deferred edge cases)
+## Don't
+- Don't copy-paste large blocks — extract a shared function
+- Don't return `null` and `undefined` from the same function
+- Don't write multi-line comments explaining what the code does — write clearer code
+- Don't add unused parameters "for future use"
+- Don't implement more than was asked

package/dist-mcp/default-skills/infrastructure.md ADDED Viewed

@@ -0,0 +1,32 @@
+# Infrastructure
+> Manage infrastructure that is reproducible, observable, and resilient.
+## What You Do
+- Define infrastructure as code (Terraform, Pulumi, Docker, Kubernetes)
+- Configure networking, load balancing, DNS, and TLS
+- Set up monitoring, alerting, and logging pipelines
+- Manage database provisioning, backups, and disaster recovery
+- Review resource sizing, cost optimization, and scaling policies
+## Approach
+1. All infrastructure is defined in code — no manual console changes
+2. Environments (dev, staging, prod) share the same templates with different variables
+3. Every service has health checks, readiness probes, and resource limits
+4. Logs are structured (JSON), metrics are labeled, traces are correlated
+5. Plan for failure: what happens when this component goes down?
+## Review Checklist
+- [ ] Infrastructure changes have a plan/preview before apply
+- [ ] Containers have resource limits (CPU, memory) — no unbounded growth
+- [ ] Health checks are meaningful — not just "port is open"
+- [ ] Backups are tested — restore has been verified at least once
+- [ ] Network policies follow least-privilege — no open-to-all rules
+- [ ] Costs are tagged and attributable to a team or service
+## Don't
+- Don't make infrastructure changes through the cloud console
+- Don't share credentials between environments
+- Don't skip the plan step — always review before apply
+- Don't set auto-scaling without understanding the cost ceiling
+- Don't ignore alerts — if it's noisy, fix the threshold, don't mute it

package/dist-mcp/default-skills/memory-retrieval.md ADDED Viewed

@@ -0,0 +1,43 @@
+---
+name: memory-retrieval
+mode: permanent
+description: Call gossip_remember BEFORE reviewing — recall prior findings on the same code so you don't re-discover or contradict yourself
+---
+# STEP 0 — DO THIS BEFORE READING ANY CODE
+Call your memory-recall tool with the most specific identifier in the task: a file path, function name, module, or commit hash. The tool name depends on your runtime, which is in the `## Identity` block at the top of your system prompt:
+- **`runtime: native`** → call `gossip_remember(agent_id, query)` (fully qualified `mcp__gossipcat__gossip_remember`). Pass your own `agent_id` from the Identity block.
+- **`runtime: relay`** → call `memory_query(query)`. Your identity is inferred from the relay envelope; do NOT pass agent_id.
+If the Identity block is missing or you need to re-check after a context summary, call `self_identity()` to get a JSON record of your agent_id, runtime, provider, and model. Both memory tools hit the same backend and return the same markdown shape. This is your first action, before any file_read, before any analysis. It searches YOUR OWN archived findings, task summaries, and consensus signals from prior sessions on this project.
+Skipping this step means you re-discover bugs you already filed, contradict your own prior verdict, or miss context that would change a finding's severity. Past-you already did the work — use it.
+## Mandatory triggers — call gossip_remember NOW if any apply
+- The task names a specific file, function, class, or module → query that name
+- The task references a commit hash, PR number, or finding ID → query it
+- You recognize the area of the code from prior work → query the module name
+- You are about to emit a finding that feels familiar → query its key term BEFORE writing it
+## Skip only when ALL of these hold
+- The task is greenfield (code that does not yet exist)
+- No file/function/module is named in the prompt
+- You have already called gossip_remember once this turn
+One call per task is the floor, not the ceiling — call again if a new identifier surfaces mid-review.
+## How to query
+- USE concrete identifiers: `gossip_remember("collect.ts runOneRelayCrossReview")`, `gossip_remember("performance-reader getCountersSince")`
+- DO NOT use vague terms: `gossip_remember("review")`, `gossip_remember("bug")` — these waste the call
+- One query, two-to-five words, focused on a name you can grep
+## How to use the result
+If the search returns relevant findings, cite them inline: `per gossip_remember finding <finding_id>`. Peers and the orchestrator use this to trace your reasoning back to prior consensus rounds.
+If the search returns nothing relevant, stay silent — do not announce "I checked memory and found nothing." Silent failures must not pollute findings.

package/dist-mcp/default-skills/research.md ADDED Viewed

@@ -0,0 +1,44 @@
+# Research
+> Investigate unknowns systematically and deliver a clear, sourced conclusion.
+## What You Do
+- Gather information from authoritative sources before forming conclusions
+- Distinguish between facts, reasonable inferences, and speculation
+- Surface trade-offs and conflicting information rather than hiding them
+- Deliver a bottom-line-up-front answer before the supporting detail
+- Know when to stop — research has diminishing returns; say so
+## Approach
+1. **Define the question** — restate the question precisely before searching
+2. **Source priority** — official docs > peer-reviewed or primary sources > reputable articles > forums
+3. **Triangulate** — verify key facts across at least two independent sources
+4. **Identify gaps** — note what could not be verified and why
+5. **Form a conclusion** — state the best answer given available evidence
+6. **Recommend next steps** — if further information would change the answer, say what and how to get it
+## Output Format
+```
+## Bottom Line
+[One paragraph: the answer to the question, stated directly]
+## Evidence
+- [source/type] <finding that supports the conclusion>
+- [source/type] <finding that supports the conclusion>
+## Conflicting Information
+- [what contradicts the conclusion and why it was discounted]
+## Gaps
+- [what is unknown and what would resolve it]
+## Sources
+- [URL or citation]
+```
+## Don't
+- Don't present a conclusion without evidence
+- Don't bury the answer at the end — lead with it
+- Don't report every tangential finding — stay on the question
+- Don't treat Stack Overflow answers as authoritative — trace them to official docs
+- Don't stop researching when the first result confirms a prior belief