gossipcat 0.3.0 → 0.4.1

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 (15) hide show
  1. package/README.md +1 -1
  2. package/dist-dashboard/assets/{index-BsDB836W.js → index-QHhaJq-5.js} +17 -17
  3. package/dist-dashboard/index.html +1 -1
  4. package/dist-mcp/default-skills/api-design.md +1 -4
  5. package/dist-mcp/default-skills/code-review.md +1 -12
  6. package/dist-mcp/default-skills/debugging.md +1 -14
  7. package/dist-mcp/default-skills/documentation.md +1 -4
  8. package/dist-mcp/default-skills/implementation.md +1 -4
  9. package/dist-mcp/default-skills/research.md +1 -17
  10. package/dist-mcp/default-skills/security-audit.md +1 -14
  11. package/dist-mcp/default-skills/system-design.md +1 -14
  12. package/dist-mcp/default-skills/testing.md +1 -4
  13. package/dist-mcp/default-skills/typescript.md +1 -4
  14. package/dist-mcp/mcp-server.js +2140 -1023
  15. package/package.json +1 -1
package/dist-dashboard/index.html CHANGED
@@ -22,7 +22,7 @@
22
22
  <link rel="icon" type="image/png" href="/dashboard/favicon.png" />
23
23
  <link rel="preconnect" href="https://fonts.googleapis.com" />
24
24
  <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" />
25
- <script type="module" crossorigin src="/dashboard/assets/index-BsDB836W.js"></script>
25
+ <script type="module" crossorigin src="/dashboard/assets/index-QHhaJq-5.js"></script>
26
26
  <link rel="stylesheet" crossorigin href="/dashboard/assets/index-Bf6FBM2K.css">
27
27
  </head>
28
28
  <body>
package/dist-mcp/default-skills/api-design.md CHANGED
@@ -19,10 +19,7 @@
19
19
  7. **Validation** — reject invalid input at the boundary with a 422 and field-level error details
20
20
 
21
21
  ## Output Format
22
- When designing or reviewing an API:
23
- - List each endpoint: `METHOD /path — purpose`
24
- - Flag any inconsistencies with REST conventions
25
- - Note any missing error cases
22
+ Use the FINDING TAG SCHEMA from the system prompt. Do NOT invent skill-specific output formats; they break parsing and cross-review.
26
23
 
27
24
  ## Don't
28
25
  - Don't return 200 for errors — ever
package/dist-mcp/default-skills/code-review.md CHANGED
@@ -19,18 +19,7 @@
19
19
  7. Summarize findings at the top before inline comments
20
20
 
21
21
  ## Output Format
22
- ```
23
- ## Summary
24
- [1-2 sentence overview of the change and overall assessment]
25
-
26
- ## Findings
27
- - [critical] <file>:<line> — <issue and fix>
28
- - [warning] <file>:<line> — <issue and suggestion>
29
- - [style] <file>:<line> — <optional improvement>
30
-
31
- ## Positives
32
- - [what was done well]
33
- ```
22
+ Use the FINDING TAG SCHEMA from the system prompt. Do NOT invent skill-specific output formats; they break parsing and cross-review.
34
23
 
35
24
  ## Don't
36
25
  - Don't nitpick style issues that a linter should catch
package/dist-mcp/default-skills/debugging.md CHANGED
@@ -19,20 +19,7 @@
19
19
  7. **Verify** — run the reproduction again; confirm no regression in related tests
20
20
 
21
21
  ## Output Format
22
- When reporting a debugging session:
23
- ```
24
- ## Root Cause
25
- [One sentence: what was wrong and why]
26
-
27
- ## How It Was Found
28
- [The reproduction steps and the hypothesis that proved correct]
29
-
30
- ## Fix Applied
31
- [File and change summary]
32
-
33
- ## Regression Test Added
34
- [Yes/No and location]
35
- ```
22
+ Use the FINDING TAG SCHEMA from the system prompt. Do NOT invent skill-specific output formats; they break parsing and cross-review.
36
23
 
37
24
  ## Don't
38
25
  - Don't make multiple changes at once — you won't know which one fixed it
package/dist-mcp/default-skills/documentation.md CHANGED
@@ -18,10 +18,7 @@
18
18
  6. **Diagrams** — prefer text-based (Mermaid) over image files so they stay in version control
19
19
 
20
20
  ## Output Format
21
- When writing or auditing documentation:
22
- - List what is documented, what is missing, and what is stale
23
- - Flag public APIs with no docs as **[missing]**
24
- - Flag docs that contradict the code as **[stale]**
21
+ Use the FINDING TAG SCHEMA from the system prompt. Do NOT invent skill-specific output formats; they break parsing and cross-review.
25
22
 
26
23
  ## Don't
27
24
  - Don't document what the code already says clearly — no `// increment i by 1`
package/dist-mcp/default-skills/implementation.md CHANGED
@@ -26,10 +26,7 @@
26
26
  - [ ] Function names describe the action, not the mechanism
27
27
 
28
28
  ## Output Format
29
- When reporting implementation work:
30
- - List files created or modified
31
- - Note any assumptions made about requirements
32
- - Flag anything that should be followed up (tech debt, deferred edge cases)
29
+ Use the FINDING TAG SCHEMA from the system prompt. Do NOT invent skill-specific output formats; they break parsing and cross-review.
33
30
 
34
31
  ## Don't
35
32
  - Don't copy-paste large blocks — extract a shared function
package/dist-mcp/default-skills/research.md CHANGED
@@ -18,23 +18,7 @@
18
18
  6. **Recommend next steps** — if further information would change the answer, say what and how to get it
19
19
 
20
20
  ## Output Format
21
- ```
22
- ## Bottom Line
23
- [One paragraph: the answer to the question, stated directly]
24
-
25
- ## Evidence
26
- - [source/type] <finding that supports the conclusion>
27
- - [source/type] <finding that supports the conclusion>
28
-
29
- ## Conflicting Information
30
- - [what contradicts the conclusion and why it was discounted]
31
-
32
- ## Gaps
33
- - [what is unknown and what would resolve it]
34
-
35
- ## Sources
36
- - [URL or citation]
37
- ```
21
+ Use the FINDING TAG SCHEMA from the system prompt. Do NOT invent skill-specific output formats; they break parsing and cross-review.
38
22
 
39
23
  ## Don't
40
24
  - Don't present a conclusion without evidence
package/dist-mcp/default-skills/security-audit.md CHANGED
@@ -24,20 +24,7 @@
24
24
  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?
25
25
 
26
26
  ## Output Format
27
- ```
28
- ## Security Findings
29
-
30
- ### [critical] <Title>
31
- - Location: <file>:<line>
32
- - Risk: <what an attacker can do>
33
- - Fix: <concrete remediation>
34
-
35
- ### [high/medium/low] <Title>
36
- ...
37
-
38
- ## No Issues Found
39
- [List areas that were checked and found clean]
40
- ```
27
+ Use the FINDING TAG SCHEMA from the system prompt. Do NOT invent skill-specific output formats; they break parsing and cross-review.
41
28
 
42
29
  ## Don't
43
30
  - Don't report theoretical vulnerabilities with no realistic attack path
package/dist-mcp/default-skills/system-design.md CHANGED
@@ -19,20 +19,7 @@
19
19
  7. **Trade-offs** — document at least two alternatives and why the chosen approach wins
20
20
 
21
21
  ## Output Format
22
- ```
23
- ## Components
24
- - <Name>: <responsibility> | interface: <key methods or API>
25
-
26
- ## Data Flow
27
- [Numbered steps tracing one key request end-to-end]
28
-
29
- ## Failure Modes
30
- - <Component> fails → <system behavior and recovery>
31
-
32
- ## Trade-offs
33
- - Chose X over Y because: <reason>
34
- - Deferred Z because: <reason>
35
- ```
22
+ Use the FINDING TAG SCHEMA from the system prompt. Do NOT invent skill-specific output formats; they break parsing and cross-review.
36
23
 
37
24
  ## Don't
38
25
  - Don't add components without a clear, single responsibility
package/dist-mcp/default-skills/testing.md CHANGED
@@ -25,10 +25,7 @@
25
25
  - Concurrent or repeated calls if the function has state
26
26
 
27
27
  ## Output Format
28
- When writing or reviewing tests:
29
- - List what scenarios are covered
30
- - Flag any untested code paths
31
- - Note if mocking strategy is over-reaching (testing mocks, not code)
28
+ Use the FINDING TAG SCHEMA from the system prompt. Do NOT invent skill-specific output formats; they break parsing and cross-review.
32
29
 
33
30
  ## Don't
34
31
  - Don't test private methods directly — test through the public API
package/dist-mcp/default-skills/typescript.md CHANGED
@@ -19,10 +19,7 @@
19
19
  7. Use `satisfies` operator to validate shape without widening type
20
20
 
21
21
  ## Output Format
22
- When reviewing or implementing TypeScript code:
23
- - Flag type issues with severity: **[critical]**, **[warning]**, **[style]**
24
- - Show the corrected snippet inline
25
- - Explain the type safety risk briefly (one line)
22
+ Use the FINDING TAG SCHEMA from the system prompt. Do NOT invent skill-specific output formats; they break parsing and cross-review.
26
23
 
27
24
  ## Don't
28
25
  - Don't use `as` casts to silence errors — fix the types instead