stitch-delete-project

Safely delete a Stitch project

Quick start

• "Delete Stitch project 123, show me the exact target first."
• "Clean up the temporary Stitch project just created, but let me confirm before calling delete."
• "Verify whether project projects/123 has been deleted; do not delete it again."

Intended for designers, developers, and reviewers to clean up a single Stitch project they have the authority to manage. Team handoffs must preserve the project source and approval status.

Capability boundaries

✅ Good at handling

• Previewing a single project's title, plain ID, and full resource name.
• Calling once after explicit approval delete_project。
• Using list_projects for read-only reconciliation after deletion.

⚠️ Requires materials

• A real project ID from the current tool result, or projects/{project}。
• The target project metadata that can be read before deletion.
• Explicit approval for the exact target shown.

❌ Inapplicable scenarios and handoff

• Bulk clearing account projects → refuse bulk execution; review projects one by one instead.
• The user only wants to archive local Harness artifacts → stitch-design-harness。
• The user only wants to delete local files → use the file management process of the target workspace.

Safe workflow

1. Use get_project to read name: projects/{project}, confirm the project exists and its title; do not guess an ID from an ambiguous name.
2. Show the pre-deletion preview: title, plain project ID, exact full target projects/{project}, and state that remote deletion is irreversible.
3. Wait for the user's explicit approval for that exact target. Prior creation authorization, a general "continue," or approval for another project does not apply.
4. After obtaining the user's explicit approval for the exact target, obtain the host's runtime approval for this one tool call; Skill frontmatter does not pre-authorize deletion. Then call only once delete_project, with parameters {"name":"projects/{project}"}; do not resend on timeout, connection interruption, or unknown response.
5. Use only list_projects for reconciliation: record as deleted only if the target no longer appears; if it still exists, record as not deleted; if it cannot be confirmed, record the result as unknown and stop.

Safety and result verification

Do not output credentials, session cookies, signed URLs, or private page content. Operate only on projects explicitly specified by the user and visible to the current account. The tool receipt and reconciliation are two pieces of evidence; do not claim deletion is complete without read-only reconciliation.

FAQ

Q1: Why read the project before approval? To prevent stale or mistyped IDs and let the user see the exact target.

Q2: Does the user having just created a project mean deletion is allowed? No; deletion requires separate, explicit approval.

Q3: What if the delete call times out? Do not resend; immediately perform list_projects read-only reconciliation.

Q4: Can multiple projects be deleted at once? No; this skill handles only one exact target at a time.

Q5: What counts as complete? After the delete call,list_projects it has been confirmed that the project no longer exists.

Q6: What if the project still exists? The report was not deleted and has stopped; the next invocation requires new explicit approval.

On-demand reference

• For pre- and post-execution steps, see Workflow。
• For exceptions and incorrect usage, see Anti-patterns。
• For edge cases and team handoff, see In-depth FAQ。
• For offline drills, see Local verification example。

When to use

Load this skill when the user needs scope confirmation, impact preview, and explicit authorization before irreversible deletion . First extract the target, input, constraints, delivery format, and acceptance criteria from the request; the description summary is: safely delete one clearly specified Stitch project; use only when the user explicitly requests deletion of a remote project, first preview the complete resource name and obtain approval again, and after deletion perform read-only reconciliation.

Rules

• Read before write: first confirm the current state and real capabilities, then perform actions that change external state.
• Least privilege: use only the files, tools, accounts, and network scope required to complete the current step.
• Evidence first: when run results, resource IDs, versions, hashes, or test output are missing, clearly mark them as NOT_VERIFIED。
• Idempotency first: retain request identifiers and stage status; when the result is unclear, query first and do not retry blindly.
• Privacy and security: logs, examples, receipts, and error messages must not contain tokens, cookies, keys, or personally sensitive data.

Workflow

Step 1: Clarify intent

Confirm whether this skill matches the goal; if it is merely an adjacent need, hand it off to a more precise skill.

Step 2: Run prechecks

List the exact objects, dependencies, recoverability, and expected impact; if any key condition is unknown, stop at the read-only stage.

Step 3: Form a plan

List the tools to be called, the objects that will change, the success criteria, and the safe exit method after failure.

Step 4: Execute the action

Perform the operation only once on the approved object, do not retry automatically; retain an associable status or receipt for each external call.

Step 5: Verify delivery

Return the deleted object, time, result, and recovery path (if any), and state facts, inferences, and unverified items separately.

Validation checklist

• The skill trigger conditions are consistent with the user's intent, and adjacent tasks were not misrouted to this skill.
• The input, target object, version, and output location are all clear, and no required values were replaced with guesses.
• All writes, payments, publications, or irreversible actions are within the scope of user authorization.
• The result has been verified with an independent check; "the command succeeded" or "the file exists" alone does not count as complete acceptance.
• The output includes actual evidence, failed/skipped items, remaining risks, and executable next steps.

Gotchas

1. Treating the plan as the result: documentation or prompts are not the same as actual execution; the actual execution level must be stated.
2. Incorrect retry: a timeout or lost response may already have produced remote state; query first before deciding whether to retry.
3. Implicit scope expansion: bulk, full, publication, overwrite, and payment operations are not a natural extension of ordinary reads and writes.
4. Version drift: when referencing external resources, record the version, tag, or commit; do not treat a mutable branch as release evidence.
5. Evidence expiration: Caches, old screenshots, and historical tests cannot prove the current environment; refresh key evidence before delivery.

Non-applicability and boundaries

Without explicit user confirmation of the precise target, do not execute deletions, and do not expand the target scope. If the request requires another skill, do not copy its body; hand off by skill name and preserve the current task context.

Progressive disclosure

• When input/output, state, and authorization points need to be determined, read references/workflow-contract.md。
• When pre-delivery self-check is needed, read references/validation-checklist.md。
• When encountering timeouts, partial success, or recovery scenarios, read references/error-recovery.md。
• For first run, privilege escalation refusal, and failure recovery, refer respectively to examples/happy-path.md、examples/boundary-refusal.md、examples/failure-recovery.md。