gossipcat 0.4.19 → 0.4.21

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.
@@ -22,8 +22,8 @@
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-oIF838yl.js"></script>
26
- <link rel="stylesheet" crossorigin href="/dashboard/assets/index-DmoFYGg1.css">
25
+ <script type="module" crossorigin src="/dashboard/assets/index-aXAMEMbl.js"></script>
26
+ <link rel="stylesheet" crossorigin href="/dashboard/assets/index-Ci46EANB.css">
27
27
  </head>
28
28
  <body>
29
29
  <div id="root"></div>
@@ -10,20 +10,21 @@
10
10
  - Prioritize findings so the author knows what must change vs. what is optional
11
11
 
12
12
  ## Approach
13
- 1. Read the full diff before commenting on any single line
13
+ 1. Read the full diff before emitting any finding
14
14
  2. Check correctness first: does it do what it claims?
15
15
  3. Check edge cases: null, empty, concurrent, large input
16
16
  4. Check error handling: are errors surfaced or silently swallowed?
17
17
  5. Check test coverage: are the new paths tested?
18
18
  6. Check naming and structure: will this make sense in 6 months?
19
- 7. Summarize findings at the top before inline comments
19
+ 7. Order findings critical low within your response — every finding still ships as one `<agent_finding>` tag, never as a Markdown heading, `**F1 —**` numbering, or top-of-output summary prose
20
20
 
21
21
  ## Output Format
22
- Use the FINDING TAG SCHEMA from the system prompt. Do NOT invent skill-specific output formats; they break parsing and cross-review.
22
+ Use the FINDING TAG SCHEMA from the system prompt. Do NOT invent skill-specific output formats; they break parsing and cross-review. The natural shape of a "code review" is prose with bullets and a summary — resist that shape; the parser only sees `<agent_finding>` tags.
23
23
 
24
24
  ## Don't
25
25
  - Don't nitpick style issues that a linter should catch
26
- - Don't leave vague comments like "this could be better" — say how
26
+ - Don't write vague findings like "this could be better" — say how
27
27
  - Don't approve PRs with unresolved critical findings
28
- - Don't comment on every line — group related issues
28
+ - Don't emit a finding for every line — group related issues into one tag
29
29
  - Don't skip reading the tests
30
+ - Don't open or close your response with summary prose; the orchestrator synthesises across agents