gossipcat 0.1.0

package/dist-mcp/default-skills/security-audit.md

@@ -0,0 +1,47 @@
+# Security Audit
+
+> Identify vulnerabilities using a systematic checklist before code ships.
+
+## What You Do
+- Check for OWASP Top 10 vulnerabilities in the code under review
+- Identify Node.js-specific attack surfaces (prototype pollution, path traversal, etc.)
+- Flag insecure defaults, missing validation, and improper secret handling
+- Assign severity (critical/high/medium/low) so findings can be triaged
+- Provide a concrete fix, not just a warning
+
+## Approach
+1. **Injection** — Are inputs sanitized before SQL, shell, or template execution?
+2. **Authentication** — Are tokens validated? Sessions invalidated on logout?
+3. **Authorization** — Is every endpoint checking permissions, not just authentication?
+4. **Secrets** — Are credentials in env vars, not source code or logs?
+5. **Prototype pollution** — Is `JSON.parse` output merged into objects without key filtering?
+6. **Path traversal** — Are file paths resolved and validated against allowed roots?
+7. **Dependency risk** — Are `eval`, `child_process`, or `vm` used with untrusted input?
+8. **Error leakage** — Do error responses expose stack traces or internal details?
+9. **DoS / Resource exhaustion** — Are there payload size limits on all inputs? Connection caps? Rate limiting on endpoints and tool execution? Unbounded queues, maps, or arrays that grow without TTL-based cleanup?
+10. **Backpressure / Flow control** — Can a fast producer overwhelm a slow consumer? Are there timeouts on all async operations? TTL enforcement on messages? What happens when a buffer fills up — does it drop, block, or crash?
+11. **WebSocket / Network** — Origin validation on upgrade requests? Message size limits (maxPayload)? Auth verification on reconnect? Connection rate limiting? Presence/identity spoofing via forged sender IDs?
+12. **Resource cleanup** — Are timers cleared on shutdown? Connections closed? Maps and caches pruned with TTL? What happens to in-flight tasks when a worker disconnects mid-execution?
+
+## Output Format
+```
+## Security Findings
+
+### [critical] <Title>
+- Location: <file>:<line>
+- Risk: <what an attacker can do>
+- Fix: <concrete remediation>
+
+### [high/medium/low] <Title>
+...
+
+## No Issues Found
+[List areas that were checked and found clean]
+```
+
+## Don't
+- Don't report theoretical vulnerabilities with no realistic attack path
+- Don't recommend adding auth middleware if auth already exists elsewhere
+- Don't ignore medium/low findings — note them even if not blocking
+- Don't suggest security through obscurity as a fix
+- Don't skip checking dependencies for known CVEs

package/dist-mcp/default-skills/system-design.md

@@ -0,0 +1,42 @@
+# System Design
+
+> Design systems with clear boundaries, explicit failure modes, and documented trade-offs.
+
+## What You Do
+- Define component responsibilities and the contracts between them
+- Map data flow: where data originates, transforms, and is persisted
+- Identify failure modes and design for graceful degradation
+- Make trade-offs explicit — document what was chosen and what was rejected
+- Validate designs against actual requirements, not hypothetical scale
+
+## Approach
+1. **Requirements** — clarify functional and non-functional requirements before designing
+2. **Components** — name each component, assign one responsibility, define its interface
+3. **Data flow** — trace a request end-to-end from input to output
+4. **Storage** — choose data stores based on access patterns, not familiarity
+5. **Failure modes** — for each component, ask: what happens when this fails?
+6. **Scale** — identify the bottleneck; design for 10x current load, not 1000x
+7. **Trade-offs** — document at least two alternatives and why the chosen approach wins
+
+## Output Format
+```
+## Components
+- <Name>: <responsibility> | interface: <key methods or API>
+
+## Data Flow
+[Numbered steps tracing one key request end-to-end]
+
+## Failure Modes
+- <Component> fails → <system behavior and recovery>
+
+## Trade-offs
+- Chose X over Y because: <reason>
+- Deferred Z because: <reason>
+```
+
+## Don't
+- Don't add components without a clear, single responsibility
+- Don't design for theoretical scale that doesn't match requirements
+- Don't leave failure modes undocumented — silence is not a recovery plan
+- Don't recommend a distributed system when a monolith meets the requirements
+- Don't skip the trade-offs section — it is the most valuable part

package/dist-mcp/default-skills/testing.md

@@ -0,0 +1,38 @@
+# Testing
+
+> Write tests that catch real bugs and serve as living documentation.
+
+## What You Do
+- Design tests that verify behavior, not implementation details
+- Apply the AAA pattern (Arrange, Act, Assert) consistently
+- Choose the right test level: unit, integration, or e2e
+- Identify what is under-tested in existing code
+- Make tests deterministic — no flakiness, no time-dependent assertions
+
+## Approach
+1. **Arrange** — set up state, mocks, and inputs explicitly
+2. **Act** — call exactly one thing under test per test case
+3. **Assert** — verify the outcome, not the internal mechanics
+4. Prefer real implementations over mocks where fast enough
+5. Mock only at boundaries: HTTP, filesystem, time, randomness
+6. Name tests: `it('returns empty array when input is null')` — a sentence describing behavior
+7. One logical assertion per test (multiple `expect` calls for the same outcome is fine)
+
+## What to Test
+- Happy path with representative input
+- Boundary values (empty, zero, max, single item)
+- Error conditions (invalid input, missing deps, network failure)
+- Concurrent or repeated calls if the function has state
+
+## Output Format
+When writing or reviewing tests:
+- List what scenarios are covered
+- Flag any untested code paths
+- Note if mocking strategy is over-reaching (testing mocks, not code)
+
+## Don't
+- Don't test private methods directly — test through the public API
+- Don't assert on implementation details that will change
+- Don't use `setTimeout` or `sleep` in tests — use fake timers
+- Don't write tests that always pass regardless of behavior
+- Don't mock so much that the test no longer touches real code

package/dist-mcp/default-skills/typescript.md

@@ -0,0 +1,32 @@
+# TypeScript
+
+> Apply TypeScript best practices for type safety, readability, and maintainability.
+
+## What You Do
+- Enforce strict typing — no implicit `any`, no type assertions without justification
+- Design interfaces before implementations
+- Catch common TypeScript anti-patterns in review and implementation
+- Prefer type-level correctness over runtime checks where possible
+- Keep files focused: under 300 lines, single responsibility
+
+## Approach
+1. Define types and interfaces at the top of a file or in a dedicated `types.ts`
+2. Use `unknown` instead of `any` when type is genuinely unknown
+3. Prefer `type` aliases for unions/intersections, `interface` for object shapes
+4. Use discriminated unions for state machines and result types
+5. Avoid optional chaining as a substitute for proper null handling
+6. Prefer `readonly` arrays and properties when mutation is not intended
+7. Use `satisfies` operator to validate shape without widening type
+
+## Output Format
+When reviewing or implementing TypeScript code:
+- Flag type issues with severity: **[critical]**, **[warning]**, **[style]**
+- Show the corrected snippet inline
+- Explain the type safety risk briefly (one line)
+
+## Don't
+- Don't use `as` casts to silence errors — fix the types instead
+- Don't use `!` non-null assertions unless you've verified the value is never null
+- Don't create god-object types with 20+ properties — split them
+- Don't use `object`, `Function`, or `{}` as types — be specific
+- Don't ignore TypeScript errors with `@ts-ignore` — use `@ts-expect-error` with a comment if truly needed

package/dist-mcp/default-skills/ui-design.md

@@ -0,0 +1,33 @@
+# UI Design
+
+> Design interfaces that are consistent, accessible, and maintainable.
+
+## What You Do
+- Review and design component hierarchies, layout systems, and interaction patterns
+- Ensure visual consistency: spacing, typography, color usage, alignment
+- Evaluate accessibility: keyboard navigation, screen readers, contrast ratios
+- Identify responsive breakpoints and mobile-first considerations
+- Spot UX anti-patterns: hidden actions, inconsistent feedback, confusing flows
+
+## Approach
+1. Start with the user's goal — what are they trying to accomplish on this screen?
+2. Map the information hierarchy — what's primary, secondary, tertiary?
+3. Check component reuse — is there an existing component that does this?
+4. Verify states: loading, empty, error, overflow, truncation
+5. Test the flow end-to-end — does the user know what happened after each action?
+
+## Review Checklist
+- [ ] Components follow existing design system patterns
+- [ ] Spacing and sizing use consistent scale (not arbitrary pixel values)
+- [ ] Interactive elements have hover, focus, active, and disabled states
+- [ ] Text truncation is handled — no overflow breaking layout
+- [ ] Color is not the only way information is conveyed (accessibility)
+- [ ] Forms have validation feedback, loading states, and error messages
+- [ ] Animations serve a purpose — not decorative noise
+
+## Don't
+- Don't introduce a new color or spacing value without checking the existing system
+- Don't hide critical actions behind menus or hover-only interactions
+- Don't use placeholder text as labels
+- Don't assume desktop-only — check narrow viewports
+- Don't design components that only work with one specific data shape

package/dist-mcp/default-skills/verification.md

@@ -0,0 +1,49 @@
+# Evidence-Based Verification
+
+> Every claim must be backed by quoted code. No exceptions.
+
+## The Rule
+
+Before you cite a file path, line number, function name, method signature, or code pattern — you MUST read the file first using the file_read tool and quote the exact code you're referencing.
+
+## What This Means
+
+**DO:**
+```
+I read `dispatch-pipeline.ts` and found at line 64:
+> const worker = this.workers.get(agentId);
+> if (!worker) throw new Error(`Agent "${agentId}" not found`);
+This throws synchronously, which means...
+```
+
+**DON'T:**
+```
+In dispatch-pipeline.ts, the `dispatch()` method likely validates the agent ID
+and throws if not found (line ~60).
+```
+
+The first example is evidence. The second is a guess dressed as analysis.
+
+## Checklist
+
+Before reporting any finding:
+
+1. Did I read the actual file? (Not from memory, not from training data — file_read this session)
+2. Can I quote the exact code I'm referencing?
+3. Does the line number I'm citing match what I actually read?
+4. Does the function/method name I'm using exist in the file?
+5. If I'm claiming something is missing, did I search for it first?
+
+## When You Can't Read
+
+If a file is inaccessible or tool calls are failing:
+- Say "I could not read this file" — don't guess what's in it
+- Skip findings that depend on reading that file
+- Report the tool failure as a blocker
+
+## Anti-Patterns
+
+- "This likely contains..." → Read it. Don't guess.
+- "Based on the architecture, this probably..." → Read the file. Architecture assumptions are wrong half the time.
+- "Line ~42" → Read the file and give the exact line.
+- Citing tools, methods, or types that you haven't seen in a file_read result → hallucination.