Uninstall agent skills: separate file deletion from settings restoration

For uninstall agent skills, the first decision is whether one small example can be reviewed by a person. Deleting an agent skill folder leaves a concrete question: what evidence shows that its settings and connections have also been removed? Treat file deletion and settings restoration as separate checks. Start with the installation instructions, list each change they describe, and compare those items against the state you want after removal.

Files: Verify the installed material is absent from the relevant location.
Settings: Compare installation-related edits with a saved baseline or a documented intended state.
Connections: Check separately whether associated access should remain, be disconnected, or be revoked.

This playbook supplies a removal comparison table, not a tested uninstall result. It helps answer “what still needs checking?” without turning an empty folder into evidence about everything else.

The evidence boundary comes before the checklist

Preparation date: 2026-09-10. Tested date: not available. No installation, uninstall execution, configuration comparison, or connection inspection was supplied for this article. The conditions are therefore document-only: a general method without a named application or verified machine state.

The available dated fact establishes when this article was prepared. It does not establish that any skill was removed successfully. Exact search demand for this uninstall question is also unverified.

That limits the receipt we can honestly provide. The artifact below is a reusable inspection record; its outcome cells deliberately remain unverified. It is not a substitute for screenshots, file comparisons, or observed settings from an actual installation.

A removal checklist is a plan for collecting evidence, not evidence that removal succeeded.

Start with what installation asked you to change

The free first action is to read the installation instructions and extract every instruction that adds a file, edits a setting, or establishes a connection.

Record the destination and scope beside each item. Was the instruction for the current project, a user account, or a shared environment? Was it required, optional, or something you skipped?

Use the instructions as a starting inventory, then reconcile them with what is actually present. An instruction describes an intended action. It does not prove that you performed it, that it succeeded, or that the current state still matches it.

For a fictional skill called Draft Basket, an inventory might include a skill directory, a configuration entry, and an optional connection. These are illustrative categories, not observed features of a real product.

For each applicable item, choose an intended outcome: remove, restore, retain, or investigate. “Retain” deserves an explicit reason, especially when another workflow uses the same resource.

The before-and-after table should expose uncertainty

Use this table before changing anything. Replace the placeholders with your own observations and omit categories that the installation did not involve.

Item to inspect	Before removal: capture	Intended state after removal	After removal: record	Evidence status
Skill files	Installed location and relevant contents	Skill-specific material absent	Location inspected and finding	Unverified
Registration or discovery entry, if present	Entry and its scope	Entry removed or disabled as intended	Updated entry or absence	Unverified
Edited configuration	Relevant values and available baseline	Installation-specific edits reversed	Narrow comparison of affected values	Unverified
Added dependency, if applicable	Dependency and known consumers	Removed only if no longer needed	Removal result or retention reason	Unverified
External connection, if applicable	Connection label and permission scope	Retained, disconnected, or revoked by decision	State shown by the relevant controls	Unverified
Generated output, if applicable	Output location and ownership	Kept or deleted by separate decision	Actual disposition	Unverified
Unrelated functionality	Safe check and expected behavior	Required behavior preserved	Observed check result	Unverified

Artifact caption: An unfilled removal comparison table. Each row separates the observed starting state, intended outcome, and evidence collected afterward.

The table avoids a single “uninstalled” checkbox because that label hides scope. A completed file row says something about files. It says nothing by itself about the connection row.

Use verified, unverified, or not applicable consistently. Explain why an item is not applicable; an unchecked item should remain unverified.

Restore the relevant change, not an assumed default

The strongest starting point for restoration is a reliable record from before installation. Compare that baseline with the current configuration and identify the edits attributable to the skill.

Do not treat an old configuration file as an automatic replacement for the current one. Review later changes before restoring anything. The intended outcome is to reverse the relevant installation edits while preserving changes you still need.

Without a baseline, use more careful language. You may be able to document that a named entry is now absent. That is narrower than proving that the entire configuration has returned to its original state.

For an ambiguous setting, record the uncertainty and investigate its purpose before changing it. A matching name alone should not decide ownership.

“The entry is gone” and “the original settings are restored” require different evidence.

Give connections their own decision

For every connection listed in the installation inventory, establish what was authorized and where its state can be inspected. Keep credential values out of the checklist.

Separate the local configuration question from the external access question. Removing a local reference is a different intended action from revoking authorization through the relevant account controls. Verify whichever action your removal plan requires.

If access is shared, document that relationship before revocation. The right outcome may be to remove the skill’s reference while retaining a connection needed elsewhere. Alternatively, the intended outcome may require revocation as well.

This article does not establish which behavior any particular application implements. Its installation and removal instructions, together with observable controls, must supply that detail.

Verify the result against the same inventory

After removal, revisit the recorded locations and settings. Compare the same items you captured beforehand instead of searching only for reassuring signs.

For each row, record what you inspected, what you observed, and whether that observation satisfies the intended outcome. Where the application requires a reload or restart to reflect changes, follow its documented procedure before assessing the visible result.

Then perform the safe check you recorded for unrelated functionality. Keep its scope modest: a successful check supports that particular behavior, not a claim that the whole environment is unaffected.

No failed uninstall was supplied here. The following are possible verification gaps, not reported incidents: inspecting the wrong scope, assuming a hidden entry is deleted, overlooking a shared dependency, or calling restoration complete without a baseline.

Finish with a scoped finding that another person could check.

The final decision belongs in a short receipt

Use this reusable closing record:

• Scope: Skill and environment inspected.
• Baseline: Available evidence, or an explicit absence.
• Files: Observed removal result.
• Settings: Reversed changes and unresolved differences.
• Connections: Confirmed disposition and any retention reason.
• Preservation check: Behavior checked and observed result.
• Decision: Complete for the stated scope, partial, or unverified.

The editorial decision is to keep file removal and restoration separate until evidence supports both. With no execution receipts supplied, this article makes no claim that an uninstall succeeded.

Copy the comparison table and populate its “before removal” column from your installation instructions and current observations.

Related build logs

• The OpenAI–Hugging Face Incident: 7 AI Agent Safety Checks for Beginners
• Choosing Code Agents? Check the Permission, Changes, and Approval Screens

Limits and stop rule. This bounded example cannot establish every tool, data, permission, or maintenance condition. Stop when the input is sensitive, the expected output is unclear, or a person cannot review the result.