Repo sentinel

Skill hzs0623/repo-sentinel-ai-skill/repo-sentinel

Repo guardrail for Claude Code & OpenAI Codex to validate code edits, refactor, bugfix and project development.

Install

npx -y skills add hzs0623/repo-sentinel-ai-skill --skill repo-sentinel

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

3.1 KB, as published. Nobody here has run it

me: repo-sentinel description: Repo-aware engineering guardrails for AI coding agents such as Claude Code and OpenAI Codex. Use when asked to modify, debug, refactor, review, test, or understand code in a repository, especially unfamiliar repos, bug fixes, CI failures, feature work, dependency upgrades, or tasks that require choosing the right local verification command. Do not use for pure writing tasks with no repository or code impact.

Repo Sentinel

Use this skill to make repository work evidence-driven: inspect first, edit narrowly, and verify with commands that match the project.

Workflow

Probe the repository before editing.
- If this skill folder is available locally, run:
```
python scripts/repo_probe.py .
```
- Use the output to identify package managers, project markers, likely test/lint/build commands, generated directories, and current git state.
- If the script cannot run, manually inspect with rg --files, ls, package manifests, and git status --short.
Establish the work surface.
- State the affected language/package/module before editing.
- Check for existing user changes and do not revert unrelated changes.
- In monorepos, stay inside the affected package unless the request crosses package boundaries.
- Treat generated, vendor, cache, lockfile, build output, and dependency directories as read-only unless the task explicitly requires them.
Trace before changing.
- Search for the feature, error text, symbol, route, test, type, schema, or command involved.
- Read nearby implementation and tests before choosing an approach.
- Prefer existing local patterns over new abstractions.
- For failures, reproduce or inspect the failing command before fixing when feasible.
Choose verification early.
- Select the narrowest meaningful command first: a targeted test, package test, typecheck, lint, or build.
- Prefer commands declared by the repository over invented commands.
- For package scripts, use the detected package manager from lockfiles or packageManager.
- If no test command exists, use a syntax/type/import/build check that exercises the changed files.
Edit with a small blast radius.
- Change only files needed for the request.
- Preserve style, naming, formatting, error handling, and public contracts.
- Add or update tests when behavior changes and a test pattern exists.
- Avoid broad cleanup, dependency swaps, or architectural rewrites unless explicitly requested.
Verify and report evidence.
- Run the chosen verification command after editing.
- If a command fails, separate pre-existing failures from failures caused by the change.
- If verification cannot run, report the exact blocker and the next best check performed.
- Do not claim the change is complete without command evidence or a clear explanation of why verification was impossible.

Final Response Shape

Use this structure when closing the task:

Changed: <1-3 concrete bullets or a short paragraph>
Verified: <exact command(s) run and result>
Remaining risk: <only if non-empty>