ada-windows-file-editing

Edits and verifies code on Windows git-bash/MSYS, handling CRLF patches, path translation, and verification.

Updated Jul 23, 2026
One-click install
npx skills add https://github.com/wubing7755/Ada --skill ada-windows-file-editing-wubing7755
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: ada-windows-file-editing
Source: https://github.com/wubing7755/Ada/tree/main/skills/software-development/ada-windows-file-editing
Command: npx skills add https://github.com/wubing7755/Ada --skill ada-windows-file-editing-wubing7755

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Editing code on Windows through git-bash/MSYS toolchains fails in non-obvious ways: patch tools corrupt CRLF line endings, MSYS silently rewrites POSIX paths passed to native programs like dotnet, case-insensitive filesystems collide runtime and source directories, and verification scripts misread GBK-encoded build output. This Skill captures the operational knowledge to edit and verify Windows code correctly. ## Core Features & Use Cases - CRLF-safe patching: Normalize mixed line endings after V4A/multi-line patches, work around replace_all multi-line match failures, and run Python-based exact replacements that preserve CRLF with per-edit count assertions. - MSYS path and environment handling: Pass Windows-style paths ("C:/tmp/x") to native tools, avoid curl -F absolute-path upload failures, and recover from terminal cwd persisting across calls. - Case-collision and verification pitfalls: Detect runtime-vs-source directory name collisions that expose source via static file serving, decode GBK dotnet output in verification scripts, and follow the hermes-verify script create-run-cleanup loop. - Use Case: After patching a CRLF CSS file, the diff shows the whole file rewritten; apply the normalization one-liner, confirm git diff --stat returns to a sane line count, then run dotnet test and assert on the localized pass/fail counters. ## Quick Start Ask the agent to patch a CRLF file in your Windows repo and verify the change with a build, and it will apply the line-ending, path, and verification rules automatically.

Frequently Asked Questions about ada-windows-file-editing

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I patch CRLF files without corrupting line endings?

After a patch inserts LF lines into a CRLF file, normalize with a Python one-liner that converts all line endings back to CRLF, then confirm git diff --stat returns to a reasonable line count. For multi-line replacements, use single-line anchors or a Python script that joins old/new blocks with \r\n and asserts each replacement count equals one.

Why does replace_all fail with 'Could not find a match' on Windows files?

Multi-line old_string matching is unreliable on CRLF files because fuzzy matching does not normalize line endings. Remove trailing newlines from old_string, match a single unique line instead of a whole block, or use a Python script with explicit \r\n-joined strings.

Why does dotnet write output to the wrong directory from git-bash?

MSYS translates POSIX paths before passing them to native Windows programs, so -o /tmp/x becomes C:\tmp\x and -o /c/tmp/x becomes the nested C:\c\tmp\x. Pass Windows-style paths with forward slashes like "C:/tmp/x", which bypass translation, and ls the result to confirm the actual location.

Why are source files showing up in my media or uploads directory on Windows?

Windows filesystems are case-insensitive, so a runtime directory named media merges with a source directory named Media, potentially exposing source code through static file serving. Rename the runtime directory default (for example media-store), clean up using the source directory's actual casing, and add a regression test asserting the paths differ.

Why does my Python verification script fail on dotnet test output in Chinese Windows?

On Chinese Windows, dotnet and MSBuild output is GBK (cp936) encoded, so decoding as UTF-8 produces mojibake and string assertions misfire. Decode subprocess output with encoding="gbk" and assert on localized counters like "失败: 0" plus the process exit code rather than English phrases.

When should I not use this Windows file-editing skill?

It does not cover .NET build-gate verification, calling PowerShell from bash, browser-based WASM deployment checks, or Hermes configuration operations; those route to dedicated skills. Use it specifically for editing and verifying files through the Windows git-bash/MSYS toolchain.