Exploring and reporting Git remote configuration may expose credentials embedded in URLs
Source references: 2The Skill explicitly reads `git remote -v` and `.git/config`, then summarizes its findings. Older repositories or automation environments sometimes embed access tokens, usernames, or passwords in remote URLs, but the instructions do not require redacting URL userinfo, tokens, or query parameters before presentation.
If the agent reproduces the remote URL, credentials could enter chat history, logs, or later model context and enable access to the associated hosting account or repository.
The Skill inspects `git remote -v` and `.git/config`, then summarizes its findings to the user. If a remote URL embeds a username, password, access token, or sensitive query parameter and the agent reproduces it verbatim, that credential could enter chat or logs. The source does not require redaction. A user can ask the author to report only the hosting service and repository name and to strip URL userinfo, tokens, and query parameters before display.
Look at the current repo to understand its starting state. Read whatever exists; don't assume:- `git remote -v` and `.git/config`: is this a GitHub repo? Which one?- `AGENTS.md` and `CLAUDE.md` at the repo root: does either exist? Is there already an `## Agent skills` section in either?- `CONTEXT.md` and `CONTEXT-MAP.md` at the repo root- `docs/adr/` and any `src/*/docs/adr/` directories- `docs/agents/`: does this skill's prior output already exist?- `.scratch/`: a sign that a local-markdown issue tracker convention is already in use- Is the `triage` skill installed? (a `triage` skill folder alongside this one, or `triage` in your available skills.) This decides whether Section B runs at all.- Monorepo signals: a `pnpm-workspace.yaml`, a `workspaces` field in `package.json`, or a populated `packages/*` with its own `src/`. These are present only in a genuinely large multi-package repo; their absence means single-context, which is almost every repo.Show 1 other places
### 2. Present findings and askSummarise what's present and what's missing. Then take the sections in order. One section, one answer, then the next.Lead each section with the recommended answer so the user can accept it in a word. Give a one-line explainer only when the choice genuinely branches; skip the section entirely when exploration already settled it (Section B when `triage` isn't installed, Section C when there's no monorepo).