How do I install the Cgpt Onedrive Git Safety skill?

Run npx skillmds@latest add pvsundar/cgpt-onedrive-git-safety 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 Cgpt Onedrive Git Safety 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 Cgpt Onedrive Git Safety?

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 Cgpt Onedrive Git Safety free to use?

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

Who published Cgpt Onedrive Git Safety?

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

Cgpt Onedrive Git Safety by pvsundar

Name: Cgpt Onedrive Git Safety
Author: pvsundar

Cgpt Onedrive Git Safety

Work safely with Git repositories stored under OneDrive, Google Drive, Dropbox, iCloud Drive, or other synced Windows folders. Use before git status/add/commit/diff/reset/checkout in synced repos, when handling dirty worktrees, no-touch sibling repos, line-ending phantoms, stuck index.lock files, or closeout claims about tests/builds on synced filesystems.

pvsundar Updated Sep 21, 2026

File contents

CGPT OneDrive Git Safety

Use this skill when a repo is inside a cloud-synced folder or when a Git closeout claim must be reliable.

First Checks

Confirm the exact working directory with Get-Location.
Detect synced path indicators: OneDrive -, OneDrive\, Google Drive, Dropbox, iCloud Drive, Box.
Run Git from Windows-native PowerShell in this Codex environment. Treat bash-side Git reports from synced folders as advisory only.
If the user names a sibling folder or repo as no-touch, write down that boundary and do not inspect or modify it unless asked.
If Windows-native Git and another shell disagree, trust the Windows-native report for synced paths.

Dirty Worktree Discipline

Never run git reset --hard, git checkout -- <file>, or equivalent destructive cleanup unless the user explicitly asks.
Do not revert changes you did not make.
If unrelated dirty files exist, ignore them and scope Git operations to the files relevant to the task.
Before staging, review git status --short and the relevant diffs from the Windows-native shell.

Synced Filesystem Risks

Stale status can over-report line-ending changes or under-report staged/deleted files.
.git/index.lock can appear stuck because a prior shell or sync process held a handle.
File content can differ between runtime, working tree, and committed blob if sync interfered.

If any Git state looks contradictory, pause Git mutations and re-check from a fresh Windows-native PowerShell session after the sync layer settles.

Verification Before Closeout Claims

Before saying "tests pass", "build is clean", or "committed state is verified":

Run the relevant tests/builds.
Verify the files in the committed or staged state when a commit is involved:
- git show HEAD:<path> for committed files.
- git diff --cached -- <path> for staged files.
For high-stakes delivery, verify from a clean worktree or temporary worktree rather than only the live edited folder.

If full verification is not feasible, qualify the claim precisely.

On a synced filesystem, a runtime green check is not the same as a committed-state green check. When the claim is about HEAD, inspect the relevant HEAD blobs or run the pipeline from a temporary worktree/archive of that commit before calling it verified.

Line Endings

If Git reports whole-file diffs after a tiny edit, suspect CRLF/LF normalization.
Use cgpt-line-endings-hygiene before rewriting Windows-origin files.
Do not combine line-ending normalization with substantive edits unless the user explicitly asks.

Report Back

When Git safety affected the work, report:

The exact repo path used.
Whether the path is synced.
Which files were intentionally touched.
Any dirty files left untouched.
The verification command(s) actually run.

---name: cgpt-onedrive-git-safetydescription: Work safely with Git repositories stored under OneDrive, Google Drive, Dropbox, iCloud Drive, or other synced Windows folders. Use before git status/add/commit/diff/reset/checkout in synced repos, when handling dirty worktrees, no-touch sibling repos, line-ending phantoms, stuck index.lock files, or closeout claims about tests/builds on synced filesystems.---# CGPT OneDrive Git SafetyUse this skill when a repo is inside a cloud-synced folder or when a Git closeout claim must be reliable.## First Checks1. Confirm the exact working directory with `Get-Location`.2. Detect synced path indicators: `OneDrive -`, `OneDrive\`, `Google Drive`, `Dropbox`, `iCloud Drive`, `Box`.3. Run Git from Windows-native PowerShell in this Codex environment. Treat bash-side Git reports from synced folders as advisory only.4. If the user names a sibling folder or repo as no-touch, write down that boundary and do not inspect or modify it unless asked.5. If Windows-native Git and another shell disagree, trust the Windows-native report for synced paths.## Dirty Worktree Discipline- Never run `git reset --hard`, `git checkout -- <file>`, or equivalent destructive cleanup unless the user explicitly asks.- Do not revert changes you did not make.- If unrelated dirty files exist, ignore them and scope Git operations to the files relevant to the task.- Before staging, review `git status --short` and the relevant diffs from the Windows-native shell.## Synced Filesystem Risks- Stale status can over-report line-ending changes or under-report staged/deleted files.- `.git/index.lock` can appear stuck because a prior shell or sync process held a handle.- File content can differ between runtime, working tree, and committed blob if sync interfered.If any Git state looks contradictory, pause Git mutations and re-check from a fresh Windows-native PowerShell session after the sync layer settles.## Verification Before Closeout ClaimsBefore saying "tests pass", "build is clean", or "committed state is verified":1. Run the relevant tests/builds.2. Verify the files in the committed or staged state when a commit is involved: - `git show HEAD:<path>` for committed files. - `git diff --cached -- <path>` for staged files.3. For high-stakes delivery, verify from a clean worktree or temporary worktree rather than only the live edited folder.If full verification is not feasible, qualify the claim precisely.On a synced filesystem, a runtime green check is not the same as a committed-state green check. When the claim is about `HEAD`, inspect the relevant `HEAD` blobs or run the pipeline from a temporary worktree/archive of that commit before calling it verified.## Line Endings- If Git reports whole-file diffs after a tiny edit, suspect CRLF/LF normalization.- Use `cgpt-line-endings-hygiene` before rewriting Windows-origin files.- Do not combine line-ending normalization with substantive edits unless the user explicitly asks.## Report BackWhen Git safety affected the work, report:- The exact repo path used.- Whether the path is synced.- Which files were intentionally touched.- Any dirty files left untouched.- The verification command(s) actually run.

Frequently asked questions