Squash Odysseus development history

resources/skills/communication/action-evidence-synthesis/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: action-evidence-synthesis
+description: "Turn messages, meeting notes, and documents into sourced decisions, actions, dependencies, and risks"
+version: 1.0.0
+category: communication
+tags: [messages, meetings, actions, status, evidence]
+status: published
+confidence: 1.0
+source: builtin
+created: "2026-08-30T00:00:00Z"
+---
+
+## When to Use
+
+Use when information is fragmented across messages, meeting notes, transcripts, or documents and the user needs an action list, status summary, feasibility assessment, or executive brief.
+
+Do not use when the source material is unavailable or when the user only wants a verbatim transcript.
+
+## Procedure
+
+1. Identify the requested scope, audience, time window, and decision to support.
+2. Gather the relevant records in full and preserve stable source identifiers, authors, and timestamps.
+3. Extract explicit decisions, commitments, requests, owners, dates, dependencies, blockers, and changed facts.
+4. Reconcile revisions by preferring the newest authoritative record; keep unresolved conflicts visible instead of guessing.
+5. Separate observed facts from inferred owners, dates, urgency, feasibility, or recommendations, and label every inference as tentative.
+6. Produce the requested format with concise source references beside consequential claims and a final list of open questions.
+
+## Pitfalls
+
+- Do not turn discussion or speculation into a confirmed decision.
+- Do not invent owners or deadlines when none were assigned.
+- Do not silently discard older records that explain a changed commitment.
+- Do not send messages, create tasks, or update calendars unless the user separately authorizes those actions.
+
+## Verification
+
+- Every action has a source, status, and explicit or tentative owner and due date.
+- Conflicting values and revisions are resolved or visibly flagged.
+- The output covers decisions, actions, dependencies, risks, and open questions relevant to the request.
+

resources/skills/communication/reviewable-external-draft/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: reviewable-external-draft
+description: "Reconcile source evidence and prepare an accurate external-facing draft without bypassing review"
+version: 1.0.0
+category: communication
+tags: [drafting, email, messages, review, reconciliation]
+status: published
+confidence: 1.0
+source: builtin
+created: "2026-08-30T00:00:00Z"
+---
+
+## When to Use
+
+Use when preparing a client, customer, partner, leadership, or other external-facing update from internal messages or documents.
+
+Do not use this procedure to send immediately unless the user explicitly authorizes the exact recipient and final content.
+
+## Procedure
+
+1. Confirm the audience, communication channel, requested tone, and whether the user asked for a draft or an immediate send.
+2. Gather the relevant source records and identify the latest values, dates, commitments, and unresolved discrepancies.
+3. Resolve recipient identity through the available contact source and avoid inferring internal versus external status from a display name alone.
+4. Draft only claims supported by the collected evidence; qualify uncertainty and omit internal-only detail that the audience should not receive.
+5. Save or present a reviewable draft through the native draft or document capability.
+6. Report the draft identifier or location plus any reconciliation notes that require human review.
+
+## Pitfalls
+
+- Do not send a draft merely because a send-capable tool is available.
+- Do not copy stale figures when a later correction exists.
+- Do not conceal unresolved discrepancies behind polished prose.
+- Do not expose private internal discussion, credentials, or unrelated personal data.
+
+## Verification
+
+- Recipient identity and communication mode match the request.
+- Dates, figures, status, and commitments map to current source evidence.
+- The result remains reviewable unless an explicit send-now instruction authorized delivery.
+

resources/skills/communication/scheduling-coordination/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: scheduling-coordination
+description: "Coordinate availability, confirmations, calendar changes, and participant notifications with read-back verification"
+version: 1.0.0
+category: communication
+tags: [calendar, scheduling, coordination, availability]
+status: published
+confidence: 1.0
+source: builtin
+created: "2026-08-30T00:00:00Z"
+---
+
+## When to Use
+
+Use when arranging or changing a meeting across multiple participants, calendars, time zones, or communication channels.
+
+Do not create or modify an event when the user asked only for available options or a draft invitation.
+
+## Procedure
+
+1. Extract participants, duration, date range, time zones, location constraints, and required attendees.
+2. Resolve participant identities and inspect the relevant availability using declared calendar and contact capabilities.
+3. Compute candidate intervals in one explicit reference time zone and reject conflicts or insufficient travel buffers.
+4. Present or draft a small set of viable options when confirmation is still required.
+5. After authorization or recorded participant confirmation, create or update the event once with stable attendee identifiers.
+6. Read the event back and verify title, start, end, time zone, attendees, location, and conferencing details before drafting notifications.
+
+## Pitfalls
+
+- Do not overwrite or cancel unrelated events to manufacture availability.
+- Do not mix local times without naming the time zone.
+- Do not treat a proposed time as confirmed.
+- Do not create duplicates when an existing event can be updated safely.
+
+## Verification
+
+- The selected interval satisfies duration, availability, and time-zone constraints.
+- The calendar read-back matches the authorized event details.
+- Notifications describe the same confirmed event and remain drafts unless sending was explicitly authorized.
+

resources/skills/communication/support-triage-and-routing/SKILL.md

@@ -0,0 +1,39 @@
+---
+name: support-triage-and-routing
+description: "Prioritize support requests, identify owners, route internally, and prepare safe customer drafts"
+version: 1.0.0
+category: communication
+tags: [support, triage, urgency, routing, drafts]
+status: published
+confidence: 1.0
+source: builtin
+created: "2026-08-30T00:00:00Z"
+---
+
+## When to Use
+
+Use when reviewing a support backlog, identifying urgent incidents, assigning internal ownership, or drafting customer responses.
+
+Do not use when the request is merely to summarize an unrelated inbox or when sender identity cannot be established safely.
+
+## Procedure
+
+1. Read each in-scope request in full and retain its stable message or ticket identifier.
+2. Resolve whether the sender is internal or external and identify the responsible internal team from available contacts and service ownership data.
+3. Classify urgency from impact and time sensitivity: critical for outage, data loss, security exposure, or imminent contractual breach; high for a blocked user without a workaround; medium for degraded service with a workaround; low for non-blocking inquiries.
+4. Record a concise problem statement, evidence, affected scope, workaround, owner, next action, and response deadline.
+5. Route internally only when the user has authorized operational messaging; prepare external responses as reviewable drafts by default.
+6. Re-read created assignments or drafts and produce an escalation summary grouped by urgency.
+
+## Pitfalls
+
+- Do not infer severity from emotional language alone.
+- Do not expose one customer's data in another customer's response.
+- Do not send externally when the task calls for triage or drafting.
+- Do not mark an issue routed without a stable owner or observable routing result.
+
+## Verification
+
+- Every issue has a stable source identifier, urgency rationale, owner, and next action.
+- Critical and high items have explicit response targets and escalation state.
+- External communication is a draft unless the user explicitly authorized sending.