How do I install the Index365 Delete Project skill?

Run npx skillmds@latest add index365usa/index365-delete-project in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Index365 Delete Project safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Index365 Delete Project?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Index365 Delete Project free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Index365 Delete Project?

index365usa (@index365usa) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Index365 Delete Project by index365usa

Name: Index365 Delete Project
Author: index365usa

Index365 Delete Project

Use when the user wants to remove a project from index365. Triggers: "delete the index365 project for…", "remove yoursite.com from index365", "stop tracking this site", "clean up old projects". Removal archives the project and is reversible with `index365 projects restore`, and it still requires exact-domain confirmation. Use this skill whenever a removal is requested, never call `index365 projects archive` ad hoc.

index365usa Updated Sep 17, 2026

File contents

index365 archive project

Remove an index365 project from the active set by archiving it.

Archiving is reversible. The project moves to archived status, scan history and project-scoped API keys stay available, and index365 projects restore <project-id> reactivates the same project. Archived projects remain listable with index365 projects list --status archived. This is not a hard delete, nothing cascades, and there is no unrecoverable state to warn the user about.

The confirmation gate stays regardless. Archiving the wrong project pulls a live site out of the active set and out of any scheduled work, and the user is the only one who can say which domain they meant.

This is the one index365 command that takes a project id, because the API requires the id paired with the exact domain as a cross-check. Read the id from projects list in this conversation; never reuse one from memory or a prior session.

Iron rule

Never archive a project the user did not name by its exact domain in this conversation. You must read the project first and confirm the exact domain back to the user before archiving.

Workflow

Find it: read before you act.
```
index365 projects list
```
Identify the single project the user means and its project id from the listing. If more than one could match, list the candidates and ask which one. Never guess.
Confirm the exact domain with the user. State what will happen and what is preserved:

"This archives the yoursite.com project. Scan history and project-scoped API keys stay available, and index365 projects restore <project-id> reactivates it. Confirm the domain to proceed." Wait for the user to confirm the exact domain.
Archive with the echo-confirm. The API requires the project's exact domain as --confirm; a mismatch is rejected. The CLI also re-reads the project first.
```
index365 projects archive <project-id> --confirm yoursite.com
```
Report what was archived (domain + project id) and how to undo it: index365 projects restore <project-id>.

Red flags: STOP

The user said "delete all my projects" / "delete everything" / used a wildcard → refuse the bulk form. Archive one project at a time, each with its own confirmation.
You're about to pass --confirm with a domain you inferred rather than read from projects list → STOP, read it first.
You're tempted to skip the confirmation "because the user is in a hurry" → the confirmation is the safety; it stays.
You can't tell which of several projects the user means → ask, don't pick.

Rationalizations (all false)

Excuse	Reality
"It's obviously the only project"	Read `projects list` and confirm anyway. Cheap.
"The user clearly wants all of them gone"	Confirm each domain individually. No bulk archive.
"Archiving is reversible, so I can archive first and ask later"	Reversible is not harmless. The site leaves the active set and any scheduled work until someone notices. Confirm first.
"Echo-confirm is just ceremony"	It's the thing that makes archiving the wrong domain impossible.

---name: index365-delete-projectdescription: Use when the user wants to remove a project from index365. Triggers: "delete the index365 project for…", "remove yoursite.com from index365", "stop tracking this site", "clean up old projects". Removal archives the project and is reversible with `index365 projects restore`, and it still requires exact-domain confirmation. Use this skill whenever a removal is requested, never call `index365 projects archive` ad hoc.---# index365 archive projectRemove an index365 project from the active set by archiving it.**Archiving is reversible.** The project moves to `archived` status, scan history andproject-scoped API keys stay available, and `index365 projects restore <project-id>`reactivates the same project. Archived projects remain listable with`index365 projects list --status archived`. This is not a hard delete, nothingcascades, and there is no unrecoverable state to warn the user about.The confirmation gate stays regardless. Archiving the wrong project pulls a live siteout of the active set and out of any scheduled work, and the user is the only one whocan say which domain they meant.This is the one index365 command that takes a project id, because the API requiresthe id paired with the exact domain as a cross-check. Read the id from`projects list` in this conversation; never reuse one from memory or a prior session.## Iron rule**Never archive a project the user did not name by its exact domain in thisconversation.** You must read the project first and confirm the exact domain back tothe user before archiving.## Workflow1. **Find it: read before you act.** ```bash index365 projects list ``` Identify the single project the user means and its project id from the listing. If more than one could match, list the candidates and ask which one. Never guess.2. **Confirm the exact domain with the user.** State what will happen and what is preserved: > "This archives the `yoursite.com` project. Scan history and project-scoped API > keys stay available, and `index365 projects restore <project-id>` reactivates > it. Confirm the domain to proceed." Wait for the user to confirm the exact domain.3. **Archive with the echo-confirm.** The API requires the project's exact domain as `--confirm`; a mismatch is rejected. The CLI also re-reads the project first. ```bash index365 projects archive <project-id> --confirm yoursite.com ```4. **Report** what was archived (domain + project id) and how to undo it: `index365 projects restore <project-id>`.## Red flags: STOP- The user said "delete all my projects" / "delete everything" / used a wildcard → **refuse the bulk form.** Archive one project at a time, each with its own confirmation.- You're about to pass `--confirm` with a domain you inferred rather than read from `projects list` → STOP, read it first.- You're tempted to skip the confirmation "because the user is in a hurry" → the confirmation is the safety; it stays.- You can't tell which of several projects the user means → ask, don't pick.## Rationalizations (all false)| Excuse | Reality || --- | --- || "It's obviously the only project" | Read `projects list` and confirm anyway. Cheap. || "The user clearly wants all of them gone" | Confirm each domain individually. No bulk archive. || "Archiving is reversible, so I can archive first and ask later" | Reversible is not harmless. The site leaves the active set and any scheduled work until someone notices. Confirm first. || "Echo-confirm is just ceremony" | It's the thing that makes archiving the wrong domain impossible. |

Frequently asked questions