/autoskill

name: autoskill
description: Manage personal local Agent Skill files as an installable skill manager. Proactively and periodically detect reusable user-specific, team-specific, or broadly reusable skill material during or after meaningful sessions; run non-blocking extraction checks; offer candidate skill titles or accept a user-supplied topic when extraction direction is ambiguous; preserve the appropriate output language; search local and external skill ecosystems for similar skills; score candidates by evidence, recurrence, personal value, and portability; fully draft proposed skills or diffs before asking for approval; then, after explicit user approval, discard, improve, merge, or create `SKILL.md` folders.

Local Skill File Manager

Purpose

Maintain the user's personal local skill files as a lightweight self-improving memory system. The default goal is not to produce marketplace-ready generic skills; it is to preserve reusable behavior that helps this user, this team, or this workspace in future sessions. A good candidate may encode personal workflow preferences, project conventions, style contracts, tool choices, or review gates that would not be useful to other users, as long as it is reusable for the intended owner and approved.

This skill does not depend on project-specific code, servers, vector stores, databases, or storage layouts. It operates only on ordinary local skill folders:

<skill-root>/
  <skill-name>/
    SKILL.md
    agents/openai.yaml   (optional)
    scripts/             (optional)
    references/          (optional)
    assets/              (optional)

Use this skill to decide when a session contains reusable skill material, find whether a similar skill already exists, then discard, improve, merge, or create a local skill. The model should initiate this check when signals appear; it should not wait for the user to ask. The check must stay lightweight and non-blocking unless the user explicitly asks to focus on skill maintenance.

Related Skill Coordination

This skill owns the lifecycle decision: when to extract, whether to discard, whether to improve or merge, and where to write. Coordinate with nearby skills when they are installed:

• Use `skill-creator` for new skill structure, naming, resource placement, `agents/openai.yaml`, and validation.
• Use `skill-improvement` or equivalent improvement guidance for existing-skill iteration, test prompts, failure analysis, trigger-description tuning, and before/after comparison.
• Use `skill-finder`, `find-skills`, or equivalent discovery tools to search local or external skill ecosystems before creating a duplicate.
• Borrow self-improvement patterns only as decision heuristics: event triage, deduplication, recurrence, priority, value checks, and promotion gates. Do not adopt another skill's storage paths, daemon assumptions, or code structure unless the user asks.
• If those helper skills are unavailable, apply the built-in procedures below. Do not block on missing helper skills.
• Do not let helper skills weaken the extraction boundary: only reusable, user-evidenced capability changes should be saved.

Safety And Consent

Local skills can influence future agent behavior and may include executable scripts. Treat skill edits as durable behavior changes.

• Do not install, import, or enable third-party skills without user consent.
• Do not add surprising capabilities, hidden network access, credential handling, data exfiltration, or destructive commands.
• If a skill adds scripts or tool integrations, make their purpose visible in `SKILL.md`.
• When editing a skill that may be shared with a team, preserve organization policies and ask before changing security-sensitive behavior.
• Treat each candidate as `personal` by default; mark it `team` or `public` only when the evidence supports that broader audience.
• Do not publish, recommend as broadly reusable, or remove personal scope from a user-specific skill without explicit user approval.
• Before the first persistent learning note or skill write in a new local convention, tell the user what path would be written and ask for approval.
• Do not silently modify this `autoskill` manager itself during routine maintenance. Improve it only when the user explicitly asks to improve this skill.

Skill Roots

Before writing anything, identify where local skills live.

• Use an explicit user-provided path first.
• Otherwise check common roots such as `${CODEX_HOME}/skills`, `~/.codex/skills`, `./skills`, `.agents/skills`, and any current workspace skill directory containing `*/SKILL.md`.
• If exactly one plausible root exists, use it.
• If multiple plausible roots exist and the target is ambiguous, ask the user which root to maintain.
• Never reorganize unrelated skill roots or edit skills outside the chosen root.

Trigger Policy

Use a three-layer trigger policy:

1. Silent scan: after each substantive user turn, briefly ask whether the turn contains a reusable personal preference, rule, correction, workflow, failure, or skill-quality issue. 2. Extraction check: when a trigger below fires, classify the experience, assign evidence and value, search for similar skills, and test it against the extraction boundary. 3. Write/update: only edit local skill files after the candidate passes the boundary, the target skill root is clear, and the user approves the exact change.

The model should proactively initiate scans and extraction checks. Do not ask the user "should I check for a skill?" Ask only when the target root is ambiguous, the edit would overwrite uncertain behavior, or the user must approve an external install or sensitive script.

Candidate Lifecycle

Keep the lifecycle separate from any particular storage system: observe a signal, optionally ask the user to choose a candidate title/topic, draft the candidate, de-duplicate by pattern, decide `discard`/`keep_note`/`improve`/`merge`/`create`, show the complete proposed skill or diff, t