chore(deps): bump actions/checkout from 4 to 7

.agents/skills/wireshark-traffic-analysis/SKILL.md

@@ -0,0 +1,118 @@
+---
+name: "wireshark-traffic-analysis"
+description: "Use when analyzing packet captures or live network traffic with Wireshark MCP; choose the right workflow for triage, security hunting, incident response, troubleshooting, or CTF work, then produce evidence-backed findings with exact filters, streams, frames, and next steps."
+---
+
+# Wireshark Traffic Analysis
+
+Use this skill to turn raw packet captures into a disciplined investigation. The goal is not to list packets. The goal is to build a defensible answer from capture-wide context, protocol-level evidence, and clearly labeled inferences.
+
+## When to use
+
+- `pcap` or `pcapng` analysis
+- live traffic review after capture
+- security triage, threat hunting, or incident response
+- network and protocol troubleshooting
+- CTF and forensics-style packet challenges
+- any task where packet evidence matters more than intuition
+
+## Required inputs
+
+- capture path
+- primary goal: `triage`, `security`, `incident-response`, `troubleshoot`, or `ctf`
+- any known scope: suspicious host, port, domain, time window, protocol, or symptom
+
+If the user does not name a goal, default to `triage`.
+
+## Core workflow
+
+1. Open the capture first.
+   - Use `wireshark_open_file` before protocol-specific tools. It activates contextual tools and gives an initial protocol summary.
+2. Build a global picture before drilling down.
+   - Prefer `wireshark_quick_analysis`, `wireshark_stats_protocol_hierarchy`, `wireshark_stats_endpoints`, and `wireshark_stats_conversations`.
+3. Choose one mode and follow its playbook.
+   - Read [references/playbooks.md](references/playbooks.md) and use the matching section.
+4. Confirm interesting leads with packet-level evidence.
+   - Use `wireshark_follow_stream`, `wireshark_get_packet_details`, `wireshark_get_packet_context`, `wireshark_extract_fields`, and `wireshark_search_packets`.
+5. Separate observation from interpretation.
+   - Facts come from tool output.
+   - Inferences must be labeled `confirmed`, `likely`, `possible`, or `unresolved`.
+6. End with next actions.
+   - Suggest exact display filters, stream indexes, frame numbers, fields, or follow-up questions.
+
+## Analysis rules
+
+- Start broad, then narrow.
+- Prefer Wireshark MCP tools over freehand `tshark` syntax.
+- Never guess display filter syntax. Use `wireshark://reference/display-filters`.
+- Use `wireshark://reference/protocol-fields` when you need field names for extraction or filters.
+- Never decode payloads manually when `wireshark_decode_payload` can verify the result.
+- Treat `wireshark_stats_expert_info` as a lead generator, not a final verdict.
+- When a finding depends on context, follow the full stream before concluding.
+- For large captures, paginate instead of treating the first page as representative.
+- If the capture vantage point could distort interpretation, say so explicitly.
+- If evidence is incomplete, say exactly what is missing.
+
+## Statistics notes
+
+- `wireshark_stats_protocol_hierarchy` is for structure, not naive percentage math. A single packet can contribute to multiple protocol rows across layers.
+- `wireshark_stats_endpoints` is the fastest host inventory view. Use it to identify broadcast, multicast, and heavy talkers before drilling into conversations.
+- `wireshark_stats_conversations` is usually the best place to prioritize long-lived, high-volume, or asymmetric exchanges.
+- Stream indexes are tool evidence too. When `wireshark_follow_stream` explains the finding, include the exact stream index in the report.
+
+For official Wireshark behavior notes and source links, see [references/official-wireshark-notes.md](references/official-wireshark-notes.md).
+
+## Evidence standard
+
+For any non-trivial finding, include at least two of the following:
+
+- the tool call that surfaced it
+- exact host, port, protocol, or field names
+- a stream index or frame number
+- a display filter or field extraction query
+- a short explanation of why the signal matters
+
+When a pattern looks suspicious but could still be normal, read [references/evidence-rubric.md](references/evidence-rubric.md) before concluding.
+
+## Professional reporting style
+
+- Write like an analyst, not like a chatty observer.
+- Do not say "weird", "sketchy", or "probably malware" without evidence.
+- Keep severity or impact separate from confidence.
+- State scope, assumptions, and gaps when they materially affect the conclusion.
+- Prefer "observed", "evidence shows", "likely indicates", and "could not verify" over vague language.
+- If the capture alone cannot prove intent, say so directly.
+
+## Output shape
+
+Use the structure in [references/report-template.md](references/report-template.md). Keep reports concise, evidence-backed, and action-oriented.
+
+## Mode selection
+
+Use the matching playbook in [references/playbooks.md](references/playbooks.md):
+
+- `triage`: unknown capture, fast situational awareness
+- `security`: suspicious traffic, exfiltration, credential exposure, malware behavior
+- `incident-response`: reconstruct the timeline, scope, and affected systems
+- `troubleshoot`: retransmissions, latency, resets, failed handshakes, unstable services
+- `ctf`: flags, hidden payloads, staged transfers, encoded streams
+
+## Built-in prompts and references
+
+If the user mainly needs a starting workflow rather than a full investigation, the MCP prompts in this repo can help:
+
+- `traffic_overview`
+- `security_audit`
+- `performance_analysis`
+- `incident_response`
+- `ctf_solve`
+
+Use `wireshark://guide/usage` when you need the repo's built-in MCP workflow reference.
+
+## Common mistakes to avoid
+
+- calling something malicious because it is uncommon
+- calling something benign because it is encrypted
+- over-trusting a single heuristic such as long DNS queries or one retransmission
+- skipping endpoints and conversations, then missing the real top talker
+- reporting a hypothesis as a confirmed root cause

.agents/skills/wireshark-traffic-analysis/agents/openai.yaml

@@ -0,0 +1,7 @@
+interface:
+  display_name: "Wireshark Traffic Analysis"
+  short_description: "Triage, hunt, and debug packet captures"
+  default_prompt: "Use $wireshark-traffic-analysis to investigate this capture, choose the right workflow, and produce an evidence-backed packet analysis report."
+
+policy:
+  allow_implicit_invocation: true

.agents/skills/wireshark-traffic-analysis/references/evidence-rubric.md

@@ -0,0 +1,165 @@
+# Evidence Rubric
+
+Use this rubric when a pattern looks suspicious but the capture alone may not be enough to prove intent or root cause.
+
+## Contents
+
+- [Confidence labels](#confidence-labels)
+- [Vantage point checks](#vantage-point-checks)
+- [Common signals](#common-signals)
+
+## Confidence labels
+
+Use these labels consistently:
+
+- `confirmed`: directly supported by packet evidence with little ambiguity
+- `likely`: multiple signals support the conclusion, but another explanation is still plausible
+- `possible`: one or two weak indicators exist, but the conclusion is not stable
+- `unresolved`: the capture suggests a question, not an answer
+
+## Vantage point checks
+
+Before concluding, ask:
+
+- Is this capture from the client, server, gateway, mirror port, or only one side of the path?
+- Could packet loss in the capture itself create fake retransmissions or gaps?
+- Are missing packets making application behavior look incomplete?
+- Is TLS decryption unavailable, limiting what can be claimed about payloads?
+
+If vantage point uncertainty affects the conclusion, mention it explicitly.
+
+## Common signals
+
+### DNS tunneling
+
+Treat DNS as suspicious only when several indicators align:
+
+- unusually long query names
+- many unique subdomains under one base domain
+- repetitive TXT or NULL queries
+- regular beacon-like cadence
+- high-entropy labels
+- weak or failed response patterns
+
+Counterexamples:
+
+- CDN hostnames
+- telemetry platforms
+- service discovery
+- anti-malware lookups
+
+Good confirmation tools:
+
+- `wireshark_detect_dns_tunnel`
+- `wireshark_extract_dns_queries`
+- `wireshark_extract_fields` with `dns.qry.name`, `dns.qry.type`, `ip.src`, `ip.dst`
+
+### Port scanning
+
+Treat scanning as stronger when you see:
+
+- one source probing many ports or many hosts
+- many SYN-only attempts with little follow-through
+- short-lived connections with consistent fan-out
+
+Counterexamples:
+
+- vulnerability scanners you already own
+- health checks
+- inventory tooling
+- load balancer probes
+
+Good confirmation tools:
+
+- `wireshark_detect_port_scan`
+- `wireshark_extract_fields` with `ip.src`, `ip.dst`, `tcp.dstport`, `tcp.flags.syn`
+- `wireshark_stats_conversations`
+
+### Credential exposure
+
+Only call credentials exposed when the capture actually contains the secret or credential-bearing field.
+
+Examples:
+
+- `http.authbasic`
+- FTP `PASS`
+- Telnet plaintext login flows
+
+Good confirmation tools:
+
+- `wireshark_extract_credentials`
+- `wireshark_follow_stream`
+- `wireshark_get_packet_details`
+
+### Exfiltration or suspicious data transfer
+
+Treat exfiltration as stronger when you see:
+
+- sustained asymmetric upload volume
+- repetitive uploads to a narrow destination set
+- encoded or staged payloads
+- suspicious destinations plus meaningful payload movement
+
+Counterexamples:
+
+- backups
+- software updates
+- sync clients
+- log shipping
+
+Good confirmation tools:
+
+- `wireshark_stats_conversations`
+- `wireshark_follow_stream`
+- `wireshark_extract_http_requests`
+- `wireshark_export_objects`
+
+### TLS suspicion
+
+TLS alone is not suspicious. Treat it as more interesting when it overlaps with:
+
+- failed or unusual handshakes
+- uncommon SNI targets
+- self-signed or mismatched certificates
+- suspicious destinations found elsewhere in the capture
+
+Counterexamples:
+
+- internal PKI
+- TLS interception
+- test environments
+
+Good confirmation tools:
+
+- `wireshark_extract_tls_handshakes`
+- `wireshark_check_threats`
+- `wireshark_follow_stream`
+
+### TCP health problems
+
+One retransmission rarely proves a network issue. Stronger cases include:
+
+- repeated retransmissions in the same conversation
+- duplicate ACK bursts
+- zero-window events
+- resets aligned with user-visible failures
+
+Counterexamples:
+
+- capture loss
+- transient congestion
+- intentionally closed connections
+
+Good confirmation tools:
+
+- `wireshark_analyze_tcp_health`
+- `wireshark_stats_expert_info`
+- `wireshark_follow_stream`
+
+## Reporting rule
+
+Whenever a claim could be disputed, include:
+
+- the signal
+- the counter-interpretation
+- why your conclusion still holds, or why it remains unresolved

.agents/skills/wireshark-traffic-analysis/references/official-wireshark-notes.md

@@ -0,0 +1,66 @@
+# Official Wireshark Notes
+
+This file distills the official Wireshark and TShark documentation into a few high-value rules for the skill. Use it when a statistic or workflow seems ambiguous.
+
+## Sources
+
+- Wireshark User's Guide: Protocol Hierarchy
+  - <https://www.wireshark.org/docs/wsug_html_chunked/ChStatHierarchy.html>
+- Wireshark User's Guide: Endpoints
+  - <https://www.wireshark.org/docs/wsug_html_chunked/ChStatEndpoints.html>
+- Wireshark User's Guide: Conversations
+  - <https://www.wireshark.org/docs/wsug_html_chunked/ChStatConversations.html>
+- Wireshark User's Guide: Expert Information
+  - <https://www.wireshark.org/docs/wsug_html_chunked/ChAdvExpert.html>
+- Wireshark User's Guide: Display Filters
+  - <https://www.wireshark.org/docs/wsug_html_chunked/ChWorkBuildDisplayFilterSection.html>
+- TShark Manual: `follow` stream syntax
+  - <https://www.wireshark.org/docs/man-pages/tshark.html>
+
+## What to remember
+
+### Protocol hierarchy is structural
+
+The protocol hierarchy view is meant to explain how packets are dissected through the stack. It is great for spotting whether the capture is mostly TCP, DNS, TLS, HTTP, ARP, and so on.
+
+Do not treat the rows as mutually exclusive buckets. A single packet can contribute to multiple rows across layers, so percentages are not a simple pie chart.
+
+### Endpoints answer "who exists"
+
+The endpoints view is the best fast inventory of hosts or addresses present in the capture. It also includes separate tabs by protocol family and may include broadcast or multicast addresses.
+
+Use it early to identify:
+
+- top talkers
+- unexpected hosts
+- broadcast-heavy behavior
+- whether IPv4, IPv6, TCP, or UDP dominate the capture
+
+### Conversations answer "who exchanged meaningful traffic"
+
+The conversations view is better than endpoints when you need to prioritize investigations. Official Wireshark docs note that conversations include fields such as relative start time, duration, bits per second, and a graphable timeline.
+
+Use it to identify:
+
+- long-lived sessions
+- asymmetric uploads or downloads
+- spikes tied to a specific pair
+- the best candidate streams to follow
+
+### Expert Info is triage, not truth
+
+Expert Information is useful because it collects warnings, chats, notes, and errors in one place. It is an accelerator for investigation, not a substitute for it.
+
+Treat it as:
+
+- a fast anomaly shortlist
+- a hint about retransmissions, malformed packets, handshakes, or protocol issues
+- something that still needs confirmation with streams, packet details, or field extraction
+
+### Display filters are exact syntax, not vibes
+
+The official display filter builder documentation is a reminder to stay exact. When you are unsure about operators, field names, or compound expressions, use the MCP reference resource instead of improvising.
+
+### Stream following uses explicit stream selectors
+
+The official `tshark` manual documents `follow` stream selection by protocol and stream index. For TCP, the stream index behavior is zero-based. When reporting or handing off work, include the stream index so another analyst can reproduce the same view quickly.