mirror of
https://github.com/pewdiepie-archdaemon/odysseus.git
synced 2026-09-27 18:42:20 +02:00
Squash Odysseus development history
This commit is contained in:
pewdiepie-archdaemon
@@ -0,0 +1,38 @@
|
||||
---
|
||||
name: artifact-completion
|
||||
description: Create requested artifacts early, iterate from concrete output, and verify final deliverables
|
||||
version: 1.0.0
|
||||
category: agent
|
||||
tags: [artifacts, files, verification, workflow]
|
||||
status: published
|
||||
confidence: 1.0
|
||||
source: builtin
|
||||
owner: ""
|
||||
created: "2026-08-30T00:00:00Z"
|
||||
---
|
||||
|
||||
## When to Use
|
||||
|
||||
Use when the task requires a file, patch, report, document, image, archive, configuration, or other persistent deliverable rather than only a text answer.
|
||||
|
||||
## Procedure
|
||||
|
||||
1. Extract the required deliverable path, format, content constraints, and acceptance criteria.
|
||||
2. Inspect the source material and existing target without delaying the first valid artifact.
|
||||
3. Create a minimal complete version at the required location, then iterate from that concrete output.
|
||||
4. Use the format's native parser, renderer, compiler, or test tool to inspect the artifact.
|
||||
5. Repair specific validation, content, or presentation failures while preserving correct portions.
|
||||
6. Confirm the final path, file type, required content, and usability before reporting completion.
|
||||
|
||||
## Pitfalls
|
||||
|
||||
- Do not spend the full task budget inspecting without creating the requested output.
|
||||
- Do not place the artifact at a convenient path when the task specifies another location.
|
||||
- Do not use a filename extension as proof that the file is valid in that format.
|
||||
- Do not report completion while placeholders, missing sections, parse errors, or failed checks remain.
|
||||
|
||||
## Verification
|
||||
|
||||
- The artifact exists at the required path and opens or parses successfully.
|
||||
- Required sections, fields, labels, or visual elements are present.
|
||||
- Relevant tests, render checks, or validators pass.
|
||||
@@ -0,0 +1,38 @@
|
||||
---
|
||||
name: terminal-recovery
|
||||
description: Recover from failed terminal commands using evidence-driven diagnosis and bounded retries
|
||||
version: 1.0.0
|
||||
category: agent
|
||||
tags: [terminal, shell, debugging, recovery]
|
||||
status: published
|
||||
confidence: 1.0
|
||||
source: builtin
|
||||
owner: ""
|
||||
created: "2026-08-30T00:00:00Z"
|
||||
---
|
||||
|
||||
## When to Use
|
||||
|
||||
Use when a command fails, times out, produces incomplete output, or behaves differently from what the task requires.
|
||||
|
||||
## Procedure
|
||||
|
||||
1. Read the command, exit status, standard output, and standard error before choosing a response.
|
||||
2. Confirm the working directory, relevant files, executable availability, permissions, and environment assumptions with minimal read-only probes.
|
||||
3. Classify the failure as syntax, missing dependency, wrong path, permissions, resource pressure, timeout, service state, or task logic.
|
||||
4. Change one relevant condition and retry the narrowest command that can test the diagnosis.
|
||||
5. For a long-running command, use the returned session identifier to poll or provide input instead of launching duplicates.
|
||||
6. After recovery, run the original acceptance check and inspect the resulting files or service state.
|
||||
|
||||
## Pitfalls
|
||||
|
||||
- Do not rerun an unchanged failing command repeatedly.
|
||||
- Do not install packages or change global configuration before confirming they are missing and necessary.
|
||||
- Do not launch a second server or training job before checking for an existing process and port or device conflicts.
|
||||
- Do not treat partial output or a zero exit status as proof that the requested state was produced.
|
||||
|
||||
## Verification
|
||||
|
||||
- The diagnosed cause is supported by command output or environment state.
|
||||
- The corrected command exits as expected.
|
||||
- The requested artifact, process, or state passes an independent acceptance check.
|
||||
@@ -0,0 +1,38 @@
|
||||
---
|
||||
name: tool-discovery
|
||||
description: Discover the smallest capable tool set and confirm argument schemas before acting
|
||||
version: 1.0.0
|
||||
category: agent
|
||||
tags: [tools, discovery, routing, schemas]
|
||||
status: published
|
||||
confidence: 1.0
|
||||
source: builtin
|
||||
owner: ""
|
||||
created: "2026-08-30T00:00:00Z"
|
||||
---
|
||||
|
||||
## When to Use
|
||||
|
||||
Use when a task requires tools whose names, capabilities, or argument shapes are not already clear. This is especially useful when many tools are available or a previous call failed because the wrong tool or parameters were selected.
|
||||
|
||||
## Procedure
|
||||
|
||||
1. Translate the request into required capabilities such as reading, searching, editing, executing, browsing, or verifying.
|
||||
2. Search the tool index for those capabilities and inspect the returned tool descriptions and schemas.
|
||||
3. Prefer one direct tool over a chain of indirect tools when it can complete the operation and provide evidence.
|
||||
4. Check required parameters, identifiers, path rules, side effects, and approval requirements before calling the tool.
|
||||
5. Make a small read-only probe when the environment or target is uncertain.
|
||||
6. Execute the selected action, inspect the result, and only broaden the tool search if the result shows a concrete capability gap.
|
||||
|
||||
## Pitfalls
|
||||
|
||||
- Do not guess tool names or argument keys from memory when the index or schema is available.
|
||||
- Do not load unrelated tool groups into context.
|
||||
- Do not repeat the same failed call without changing the arguments or strategy.
|
||||
- Do not use a broad shell or browser workaround when a scoped native tool already owns the operation.
|
||||
|
||||
## Verification
|
||||
|
||||
- The chosen tool directly matches the required capability.
|
||||
- Required arguments follow the exposed schema.
|
||||
- The result contains evidence of the requested effect or a specific error that guides the next step.
|
||||
@@ -0,0 +1,38 @@
|
||||
---
|
||||
name: verified-state-change
|
||||
description: Make scoped state changes with target confirmation, minimal mutation, and read-back verification
|
||||
version: 1.0.0
|
||||
category: agent
|
||||
tags: [state, mutation, verification, safety]
|
||||
status: published
|
||||
confidence: 1.0
|
||||
source: builtin
|
||||
owner: ""
|
||||
created: "2026-08-30T00:00:00Z"
|
||||
---
|
||||
|
||||
## When to Use
|
||||
|
||||
Use when creating, editing, deleting, moving, sending, scheduling, or otherwise changing persistent state through an application, API, filesystem, or service.
|
||||
|
||||
## Procedure
|
||||
|
||||
1. Read the current state and identify the target using stable identifiers plus enough content to disambiguate it.
|
||||
2. Preserve fields the user did not ask to change and choose the narrowest supported mutation.
|
||||
3. For destructive or externally visible actions, confirm that the user's instruction authorizes the exact target and effect.
|
||||
4. Perform the mutation once and capture the returned identifier, status, or revision.
|
||||
5. Read the target again through an independent list, fetch, status, or content operation.
|
||||
6. Compare the observed state with the requested outcome and repair only the specific mismatch.
|
||||
|
||||
## Pitfalls
|
||||
|
||||
- Do not infer the target from a stale active item when a stable identifier can be fetched.
|
||||
- Do not report success from an accepted request alone; asynchronous or partial operations may not have completed.
|
||||
- Do not replace an entire object when a field-level update is supported and safer.
|
||||
- Do not silently broaden a mutation to adjacent files, records, accounts, or services.
|
||||
|
||||
## Verification
|
||||
|
||||
- The target identity was confirmed before mutation.
|
||||
- A read-back shows the intended values and preserves unrelated state.
|
||||
- Any external effect has a concrete status, identifier, or observable result.
|
||||
@@ -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.
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -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.
|
||||
@@ -0,0 +1,37 @@
|
||||
---
|
||||
name: developer-docs
|
||||
description: Find, read, and apply authoritative developer documentation during implementation
|
||||
version: 1.0.0
|
||||
category: dev
|
||||
tags: [docs, documentation, api, software-development]
|
||||
status: published
|
||||
confidence: 1.0
|
||||
source: builtin
|
||||
owner: ""
|
||||
created: "2026-08-18T00:00:00Z"
|
||||
---
|
||||
|
||||
## When to Use
|
||||
|
||||
Use when the user asks how a library, framework, API, protocol, CLI, or SDK works, or when implementation depends on version-specific behavior. Prefer this skill over guessing from memory.
|
||||
|
||||
## Procedure
|
||||
|
||||
1. Identify the exact product, package, version, and task. Ask one focused clarification only when the target is genuinely ambiguous.
|
||||
2. Prefer the vendor's or project's primary documentation, source repository, release notes, and API reference. Use a general search only to locate those sources.
|
||||
3. Read the relevant page or reference section, then apply the documented behavior to the user's codebase and active workspace.
|
||||
4. Separate documented facts from inference, and call out version or environment assumptions.
|
||||
5. For code changes, add a focused regression test for the documented contract and run it before reporting completion.
|
||||
|
||||
## Pitfalls
|
||||
|
||||
- Do not present search snippets, stale cached knowledge, or a third-party tutorial as authoritative when primary documentation is available.
|
||||
- Do not silently mix instructions from different major versions.
|
||||
- Do not claim an API or option exists without confirming it in the relevant reference.
|
||||
- Do not use web search for a local project task when the active workspace and local tools can answer it.
|
||||
|
||||
## Verification
|
||||
|
||||
- The cited or retrieved documentation matches the target version.
|
||||
- The implementation or answer distinguishes source-backed facts from inference.
|
||||
- Any code change has a focused test or a concrete verification command.
|
||||
@@ -0,0 +1,40 @@
|
||||
---
|
||||
name: test-driven-development
|
||||
description: Build or fix software with a focused red-green-refactor loop
|
||||
version: 1.0.0
|
||||
category: general
|
||||
tags: [tdd, testing, debugging, red-green-refactor]
|
||||
status: published
|
||||
confidence: 1.0
|
||||
source: builtin
|
||||
owner: ""
|
||||
created: "2026-08-18T00:00:00Z"
|
||||
---
|
||||
|
||||
## When to Use
|
||||
|
||||
Use when implementing a feature, fixing a bug, or changing behavior where a regression test can define the expected result. Prefer this workflow for parser, routing, agent-loop, and UI behavior changes.
|
||||
|
||||
## Procedure
|
||||
|
||||
1. Inspect the relevant code, existing tests, and local conventions before editing.
|
||||
2. Write the smallest regression test that demonstrates the requested behavior or reproduces the bug.
|
||||
3. Run that test and confirm it fails for the expected reason, not because the test setup is broken.
|
||||
4. Make the smallest production change that makes the test pass.
|
||||
5. Run the focused test again, then run the surrounding module suite.
|
||||
6. Review the diff for unrelated changes, brittle assertions, hidden state, and missing error paths.
|
||||
7. Report the tests run and any remaining coverage or environment limits.
|
||||
|
||||
## Pitfalls
|
||||
|
||||
- Do not write a test that only mirrors the implementation; assert the user-visible contract.
|
||||
- Do not weaken an assertion just to make a failing test pass.
|
||||
- Do not skip the focused failing-test step when the behavior is observable in a local test.
|
||||
- Keep network, filesystem, and model calls deterministic with fakes or fixtures unless the integration itself is under test.
|
||||
|
||||
## Verification
|
||||
|
||||
- The new regression test fails before the fix and passes after it.
|
||||
- The relevant focused suite passes.
|
||||
- The broader suite passes or its failure is explained with evidence.
|
||||
- The final diff contains the test and the production change needed for the same behavior.
|
||||
@@ -0,0 +1,38 @@
|
||||
---
|
||||
name: multimodal-evidence
|
||||
description: Extract and verify evidence from images, documents, and video without redundant inspection
|
||||
version: 1.0.1
|
||||
category: media
|
||||
tags: [image, video, document, evidence, ocr]
|
||||
status: published
|
||||
confidence: 1.0
|
||||
source: builtin
|
||||
owner: ""
|
||||
created: "2026-08-30T00:00:00Z"
|
||||
---
|
||||
|
||||
## When to Use
|
||||
|
||||
Use when the answer or requested artifact depends on visual, temporal, tabular, or textual evidence contained in images, documents, or video.
|
||||
|
||||
## Procedure
|
||||
|
||||
1. Identify the evidence required: objects, text, values, ordering, timestamps, labels, or visual relationships.
|
||||
2. Inspect the whole input or a broad representative sample first to establish structure and likely evidence locations.
|
||||
3. Narrow to relevant pages, frames, regions, or time intervals and record observations with their locations.
|
||||
4. Use the format's native parser for exact text and numbers: for example `python-docx` or ZIP/XML inspection for DOCX, `pdftotext` or a PDF library for PDF, spreadsheet readers for XLSX, and OCR only when the source is image-based. Do not search binary office files with plain `grep` or `cat`.
|
||||
5. Resolve conflicts with one targeted reinspection at better scale or a nearby frame rather than repeating the same crop.
|
||||
6. Build the answer or artifact from the evidence ledger and perform a final coverage check against every requested item.
|
||||
|
||||
## Pitfalls
|
||||
|
||||
- Do not infer unseen content from filenames, surrounding text, or a single thumbnail.
|
||||
- Do not repeatedly inspect nearly identical regions without a new hypothesis.
|
||||
- Do not trust OCR blindly for small labels, punctuation, or numeric values.
|
||||
- Do not finalize before checking that every requested item has supporting evidence.
|
||||
|
||||
## Verification
|
||||
|
||||
- Each factual output can be traced to a page, frame, region, or timestamp.
|
||||
- Exact labels and numbers were visually checked after extraction.
|
||||
- The final response or artifact covers all requested evidence categories.
|
||||
@@ -0,0 +1,38 @@
|
||||
---
|
||||
name: web-research-fallback
|
||||
description: Research current web information with source-first search and controlled browser fallback
|
||||
version: 1.0.0
|
||||
category: research
|
||||
tags: [web, search, browser, sources, research]
|
||||
status: published
|
||||
confidence: 1.0
|
||||
source: builtin
|
||||
owner: ""
|
||||
created: "2026-08-30T00:00:00Z"
|
||||
---
|
||||
|
||||
## When to Use
|
||||
|
||||
Use when a task requires current public information, primary sources, multiple pages, or a site that cannot be reliably read from search results alone.
|
||||
|
||||
## Procedure
|
||||
|
||||
1. Define the facts needed and the preferred primary source for each fact.
|
||||
2. Search with a focused query and use result metadata to select likely authoritative pages.
|
||||
3. Open the source directly and extract the relevant passage, date, and URL rather than relying on a search snippet.
|
||||
4. Use the private browser when the page requires interaction, client-side rendering, navigation, or visual inspection.
|
||||
5. If a page fails, try a primary-source alternative or a narrower route before broadening to secondary sources.
|
||||
6. Cross-check unstable or consequential claims and distinguish source-backed facts from inference.
|
||||
|
||||
## Pitfalls
|
||||
|
||||
- Do not treat snippets as evidence for claims not visible on the source page.
|
||||
- Do not browse repeatedly without recording what each page established.
|
||||
- Do not use a secondary summary when an accessible primary source answers the question.
|
||||
- Do not claim freshness without checking publication or update dates.
|
||||
|
||||
## Verification
|
||||
|
||||
- Each important claim maps to a source that directly supports it.
|
||||
- Time-sensitive facts include an observed date or version.
|
||||
- Browser interaction produced the needed page state or a documented fallback was used.
|
||||
Reference in New Issue
Block a user