Close agnosticism gaps: non-git VCS fallback + missing-PROJECT.md path

- red-team Phase 0: git is now the shown default, not the only path —
  instructs substituting another VCS (hg/jj/Perforce) or asking the
  caller for the changed set when git isn't present. Also pins a tracker
  path as context, not the review target.
- implement Phase 1.4: mirror /spec's graceful missing-PROJECT.md
  handling — infer test/build commands, confirm with the user, note the
  miss, suggest creating one, instead of undefined behavior.
- Trimmed adjacent prose to stay within the SKILL.md line budget.

Author: one-kash

agents/red-team.md

@@ -56,15 +56,23 @@ on the side of surfacing during the find phase.
 
 ## Phase 0 — Gather the diff
 
-Determine the review scope:
+Determine the review scope. If the task prompt named an explicit target —
+a PR number, branch, or file path — review that.
 
-- Run `git diff @{upstream}...HEAD` (or `git diff main...HEAD` /
+Otherwise obtain the diff from the project's version control. Commands below
+are for git (the common case); if the repo uses another VCS (hg, jj,
+Perforce) or no VCS at all, substitute the equivalent, and if you can't
+determine the changed set, ask the caller for the changed-file list or a
+diff range rather than guessing.
+
+- git: run `git diff @{upstream}...HEAD` (or `git diff main...HEAD` /
   `git diff HEAD~1` if there's no upstream) to get the committed diff.
 - If there are uncommitted changes, or the range diff is empty, also run
   `git diff HEAD` and include the working-tree changes — review often runs
   before the commit.
-- If a tracker path, PR number, branch, or file path was passed in the task
-  prompt, review that target instead.
+
+A tracker or plan path passed in the prompt is **context, not the review
+target** — read it (see below), but review the code diff, not the JSON.
 
 Treat this diff as the review scope. Bugs in **unchanged lines of a touched
 function** are in scope — the change re-exposes or fails to fix them.

skills/implement/SKILL.md

@@ -100,26 +100,26 @@ back summaries, keeping your main context clean for implementation.
 - Research platform-specific handling and conventions
 - Check official documentation for frameworks in use
 - Check changelogs and migration guides for your dependency
-  versions — APIs may behave differently across major/minor
-  releases (e.g., a method that re-runs in v1.0 may only
-  recompose in v1.1)
+  versions — APIs may behave differently across releases
 - Identify relevant specs (RFCs, W3C, language specs)
 - Note platform-specific quirks and edge cases
 
 ### 1.4 Check Project Architecture Patterns
 
-Verify alignment with the project's established architecture.
-Refer to `PROJECT.md` for project-specific patterns.
+Load `PROJECT.md` for build/test/lint commands, architecture rules,
+standards, and blindspots, and verify the change aligns with them. If it's
+absent or only template placeholders (`YOUR_*_HERE`), proceed without it:
+infer the test/build commands from the project (build files, CI config,
+`Makefile`), confirm them with the user before relying on them in Phase 3+,
+note the miss in the tracker, and suggest creating one.
 
 Common patterns to verify:
 
 - **Layered architecture** respected (UI -> Domain -> Data)
 - **Repository/service boundaries** not bypassed
-- **Test double strategy** matches project convention
-  (fakes vs mocks vs stubs)
+- **Test double strategy** matches project convention (fakes/mocks/stubs)
 - **Dependency injection** bindings exist for new dependencies
-- **Type safety** enforced where the project expects it
-  (sealed types, enums, branded types)
+- **Type safety** enforced where expected (sealed types, enums, branded)
 
 ### 1.5 Verify Signatures and Dependencies