clear-worktree

name

clear-worktree

description

Safely clear a dirty Inline repo worktree by inspecting uncommitted changes, classifying them as safe to commit, review-needed, blocked, or discard candidates, running focused validation, making scoped commits, and asking before destructive cleanup. Use when the user asks to clear the worktree, clean up WIP, commit what is safe, decide what needs Mo review, or update the repository-specific rules for what can be committed versus blocked.

Clear Worktree

Overview

Clear the worktree by turning coherent local changes into reviewed, scoped commits and surfacing anything that should not be committed automatically. Treat this skill as self-improving: when Mo corrects a classification or adds a cleanup rule, update this SKILL.md in the same turn unless a higher-priority instruction forbids it.

Non-Negotiables

• Never read, print, edit, or delete .env files.
• Never run git reset, git clean, git restore, git checkout --, rm, or equivalent one-way discard/delete actions unless the user explicitly confirmed that exact cleanup.
• Do not stash, switch branches, create worktrees, or use autostash.
• Do not modify existing database migrations. If a migration is involved, follow the repo migration rules and call it out in the final handoff.
• Do not blindly stage everything. Stage only the files or hunks intentionally included in a commit.
• If modifying the project while triaging, add or update .wip first. .wip is ignored and does not need to be cleared from git status.

Workflow

1. Snapshot the tree:

   • Run git status --short.
   • Read .wip if present.
   • Inspect diffs with git diff --stat, targeted git diff -- <file>, and untracked file previews.
   • Check whether files are already tracked with git ls-files when needed.

2. Classify each change:

   • Safe to commit: coherent, scoped, explainable, and low risk; includes matching tests or docs when appropriate.
   • Needs Mo review: product behavior, UX, production runtime, migrations, protocol/API shape, security/privacy/auth/encryption, release/versioning, broad generated output, localization churn, build settings, CI config, or anything with uncertain intent.
   • Blocked: broken or internally inconsistent changes, generated files without source changes, source changes without required generated files, failing focused checks that cannot be fixed safely, or changes whose intent cannot be inferred.
   • Discard candidate: obvious local artifacts, accidental IDE/project metadata, failed experiment leftovers, duplicate generated files, or explicitly unwanted changes. Ask before deleting or restoring them.

3. Validate before committing:

   • Run the narrowest useful checks for the touched area.
   • Prefer package-local scripts from the repo instructions.
   • If checks are too expensive or unavailable, state that explicitly in the commit or final handoff.

4. Commit safe sets:

   • Group files by coherent user-facing or technical change.
   • Use repo commit conventions: lowercase subject, scope when applicable.
   • Prefer scripts/committer "<msg>" <file...> when available.
   • Before committing, verify git diff --cached --name-only.
   • Do not include unrelated WIP just because it is already modified.

5. Resolve the remaining tree:

   • Continue until git status --short is clean or every remaining path has an explicit reason it is blocked, review-needed, or awaiting destructive confirmation.
   • Do not ask about low-risk classification details if the diff provides enough evidence; ask only when continuing would be risky or destructive.

Inline Seed Rules

• .context/*.md investigation or plan files are usually safe to commit as docs when they are intentional, coherent, and not secret-bearing.
• Swift tests-only changes are usually safe to commit after focused inspection and relevant test/build validation.
• A minimal apple/Inline.xcodeproj/xcshareddata/xcodecloud/manifest.json that declares existing app targets is safe to commit after previewing it; broader CI/Xcode Cloud workflow changes still need Mo review.
• Changes to apple/InlineMac/App/main.swift, app launch behavior, entitlements, signing, Xcode project settings, or CI config beyond that manifest need Mo review unless the intent is already explicit.
• Localizable.xcstrings changes need careful review because incidental localization churn is common.
• Generated protobuf files must match source proto/ changes; do not commit generated-only drift.
• New migrations are never casual cleanup. Validate source schema, generated SQL, tests, and disclose every migration touched.

Self-Improvement

When Mo gives feedback such as "that was safe to commit", "block on this next time", "discard these after asking", or "always review this category", update the closest matching rule in this file. Keep additions short, operational, and repo-specific. Re-run the skill validator after editing.