Squash Odysseus development history

resources/skills/agent/artifact-completion/SKILL.md

@@ -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.

resources/skills/agent/terminal-recovery/SKILL.md

@@ -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.

resources/skills/agent/tool-discovery/SKILL.md

@@ -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.

resources/skills/agent/verified-state-change/SKILL.md

@@ -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.