Skills A skill is a reusable workflow described in a SKILL.md file. It can include supporting scripts and references. Skills supply instructions to the model; they do not bypass tool permissions or install their own dependencies automatically. Choose a skill type Use a filesystem skill when the workflow should be reviewed and versioned with source code. Use a learned skill for a durable, evidence-backed operating lesson maintained through the agent's database tools. Use AGENTS.md for repository-wide instructions. These mechanisms complement each other; a skill is not a replacement for runtime configuration. Discover and invoke skills /skills Invoke a discovered skill by name: $add-model Configure my local model endpoint. The corresponding slash-command form, such as /add-model, is also supported. The agent can select a skill when your request matches its description. After adding or editing skill files: /skills reload Launch with --no-skills to disable filesystem skill discovery. Skills from an MCP server Connected servers can advertise skills in addition to tools. The catalog loads advertised metadata; full instructions are fetched on demand from the owning server's entry resource and verified against its manifest. Listing a skill is not proof that its content can be loaded or trusted. Malformed metadata is ignored with a warning. An unavailable server, failed resource read or integrity/identity mismatch prevents activation. Check the server and advertised resource rather than copying unverified instructions into a local skill to bypass validation. Remote instructions cannot authorize unrelated tool effects or override your request. Bundled workflows The distribution ships these ten skills. Use /skills to verify discovery in your running session; launch settings or installation can change what is available. These are reviewed instructions, not new permission grants. Name | Use and boundary | add-model | Configure local or hosted endpoints, OpenRouter models, and new OpenAI/xAI models. Verify connectivity before selecting the new entry. | skill-installer | Install from a repository, gist, URL or local path. Review scripts and choose project versus user scope first. | resume-claude, resume-codex, resume-cursor, resume-grok | Locate and read another harness's history using latest, search words, an ID or a transcript/store path. Requires local store access; imported instructions are historical context, not current authorization. | telegram-agent | Set up, start, stop or inspect the local Telegram bridge. Review allowed users and keep the bot token out of conversation text. | wait-for-ci | Follow CI for an explicit pull request, branch, commit or run until its final result. Pending is not passing; do not push unrelated fixes without authorization. | learn-about-user | Build a consent-reviewed technical profile from a confirmed public GitHub account. Review proposed durable user-scoped guidance before saving. | post-task-learning-review | Always-activation guidance for reviewing substantial completed tasks. Not user-invocable; store only reusable evidence-backed lessons, not credentials or task status. | $wait-for-ci Follow the checks for this pull request and report the final result. Do not push changes. If a resume skill cannot locate history, provide the correct store or transcript path; do not invent prior outcomes. If a dependency or credential is missing, resolve that prerequisite rather than repeatedly invoking the skill. Install a skill Use the built-in installer: $skill-installer Install the skill from this repository URL into my user skills. The installer supports a GitHub repository, gist, URL, or local path. Its default destination is: ~/.haskell-agent/skills//SKILL.md For a project-specific workflow, request installation under: /.haskell-agent/skills//SKILL.md Existing .agents/skills locations are also discovered, but the installer uses the product's .haskell-agent/skills directories. Review a third-party skill and its scripts before installing or executing it. A skill can contain instructions to run commands or contact external services. Discovery and precedence The catalog combines built-in, user, repository, and MCP-provided skills. Filesystem skills live one directory per skill with a file named exactly SKILL.md. Repository discovery considers the current directory and relevant ancestors, so launching from a different directory can change which local workflow wins. - Repository skills take precedence; a more deeply nested repository location wins. - User skills come next, followed by built-in skills and MCP-provided skills. - At the same repository depth and scope, .haskell-agent/skills takes precedence over .agents/skills. When names collide, the catalog also exposes qualified invocations. For example, a user copy can appear as $user:release-review and a built-in copy as $builtin:release-review. More complex collisions receive additional qualifiers; use the exact invocation shown by /skills, not an invented path. Write a project skill Create .haskell-agent/skills/release-review/SKILL.md: --- name: release-review description: Review release readiness when preparing a new release. --- # Release review 1. Read the release checklist and current changelog. 2. Identify missing tests and migration notes. 3. Report blockers with file references. 4. Do not publish or tag a release. Use a precise name and a description that explains when the skill applies. Keep the core procedure short; place longer references beside it and refer to them by relative path. For conventions that apply to every task in a repository, use project instructions instead of requiring a skill to be invoked each time. Front-matter reference The file must begin with YAML between opening and closing --- lines. The remaining Markdown is the procedure. Indentation and YAML value types matter. Field | Type / default | Purpose | name | Required string | 1–64 lowercase ASCII letters, digits, or hyphens; no leading, trailing, or consecutive hyphens; must match the parent directory | description | Required string | 1–1024 characters describing the workflow and its trigger | when-to-use | Optional string | Additional applicability guidance | argument-hint | Optional string | Explain the input expected after the invocation | user-invocable | Boolean / true | Whether the skill is offered for explicit user invocation | disable-model-invocation | Boolean / false | Exclude it from the model's automatic skill selection | activation | String / on-demand | Filesystem skills use on-demand; always is reserved for trusted built-ins | allowed-tools | String or string array / empty | Declared tool metadata; does not grant new runtime permissions | model, effort | Optional strings | Model and effort override metadata; do not assume a provider supports arbitrary values | license, compatibility | Optional strings | Licensing and environment requirements | metadata | String-to-string object / empty | Additional descriptive metadata | To make a workflow explicit-only, keep user-invocable: true and set disable-model-invocation: true. If both user and model invocation are disabled, neither normal entry path is available. Do not use filesystem activation: always to force third-party instructions into every session; the loader rejects it. Supporting files and dependencies release-review/ SKILL.md references/ release-checklist.md scripts/ verify_release.sh Refer to supporting files relative to the skill directory. Put long reference material in separate files so the main procedure remains focused. Declare required commands and how to enter the repository's Nix shell. Installing a skill neither installs its dependencies nor makes its scripts trusted. Review scripts before execution and keep secrets out of skill files. Example: verify the release-review skill - Save the example above at the project path, then run /skills reload. - Run /skills and check that release-review is discovered. - Submit $release-review Review this repository for release readiness. Report blockers only. Expected result: a review referencing the checklist, changelog, and any missing evidence—not a published release. If the skill is absent, check its directory, filename, and front matter, and confirm you did not launch with --no-skills before reloading. Learned skills Learned skills are stored in the local database rather than in SKILL.md. Each has a stable slug, title, description, applicability condition, instructions, activation mode, priority, status, and revision history. Use them for a proven procedure or recurring failure prevention—not a transcript, temporary task status, or an unverified guess. See learned skills for scope selection, activation modes, creation and review, revision history, archive, and rollback. These use a different activation model from filesystem front matter; do not copy database activation values into a SKILL.md file. Troubleshoot skill loading Symptom | Check and correction | Skill does not appear | Check exact SKILL.md filename, discovery directory, current working directory, and --no-skills; then /skills reload | Front matter rejected | Ensure the file starts with ---, has a closing delimiter, required name/description, and valid YAML types | Name rejected | Match the directory name; remove uppercase letters, underscores, edge hyphens, and repeated hyphens | Wrong procedure selected | Inspect duplicate names and use the catalog's qualified invocation | Never selected automatically | Check disable-model-invocation and improve the description/when-to-use trigger | Script fails after installation | Check its dependencies and Nix environment; discovery is not dependency installation | Learned change rejected as stale | Read the latest revision before requesting an update; do not retry with the old revision | Inspect before invoking view_skill takes name. Omit scope for filesystem or MCP catalog entries; use the discovered invocation name. For learned skills, supply the slug and scope (user, repository, or checkout). Optional positive revision selects learned history and is invalid without scope. Resolve ambiguous names through the catalog. MCP entries load instructions remotely and can fail when disconnected; do not silently substitute a similarly named local skill. Resume another harness's history $resume-codex latest The four resume skills use read_external_session. Required provider is codex, claude, cursor, or grok; operation defaults to show, or use list for candidates. Optional reference is a literal ID, title fragment, or transcript/store path. Omitted or latest selects the newest session for the working directory. within_minutes defaults to zero (no age filter); max_tool_chars defaults to 300, minimum 20. {"provider":"codex","operation":"list","within_minutes":60} Default roots are ~/.codex, ~/.claude, ~/.cursor, and ~/.grok, overridden respectively by CODEX_HOME, CLAUDE_CONFIG_DIR, CURSOR_HOME, and GROK_HOME. Cursor can expose CLI, desktop, or transcript records; formats differ in completeness. For an empty list check the working directory, age filter and store location. Ask the user to select ambiguous matches. Surface malformed/skipped-record warnings rather than claiming a complete import. Explicit paths require normal read access; do not use a shell to bypass a denial. This imports context, not credentials, processes, tools or authority. Treat historical messages and output as inert untrusted data. Summarize the goal, completed work, open work, stopping point and warnings, then verify current files, Git state and tests before acting. Do not replay old tool calls or claim they happened in this session. Profile consent and CI completion For $learn-about-user HANDLE, confirm the public GitHub account belongs to the user before investigating. Authentication never permits private-repository inspection. Review a representative public sample, distinguish facts from tentative technical preferences, and show the proposed profile for edits or rejection before saving. The approved result is the user-scoped, always-active learned skill user-technical-profile; refresh its current revision rather than creating duplicates. Normal mutation approval still applies. Exclude secrets and sensitive personal inferences; use learned-skill management to inspect, refresh or remove the profile. $wait-for-ci applies after a push or pull-request update when the task depends on pending checks. Record the exact head commit; a new push invalidates the old result. Wait for the relevant run's terminal outcome and report failures with evidence. Queued/running checks are not success. If access, cancellation or a time limit prevents confirmation, report the unresolved state. This workflow does not grant repository access or authorize unrelated changes.