Project agent-environment (instructions/skills) not discovered when session starts in a parent dir or the agent enters a repo via cd/worktree

Summary

When a Claude Code session's working directory is a parent of (or adjacent to) a git repository — rather than the repo itself — the repository's agent operating environment (project instructions and skills) is never discovered or surfaced. If the agent then enters the repo on its own (via cd, git clone, or git worktree add), discovery is still not re-triggered. The agent ends up improvising procedures the repo already documents.

Severity: Medium — silent; degrades output quality and consumes user turns on correction.

What happened

• The session's primary working directory was a parent folder (/home/mwa/src), reported with Is a git repository: false. The actual repository was a subdirectory (/home/mwa/src/Corvus.JsonSchema).
• The agent located and entered the repo itself, then did all work in a git worktree it created at a third path (/home/mwa/src/wt-...).
• As a result it never engaged the repository's established agent environment — .github/copilot-instructions.md plus 22 .github/skills/*/SKILL.md files — until the user explicitly asked, roughly seven turns in.

Root causes (two layers)

1. Context discovery is anchored to the launch cwd and is not re-evaluated when the effective repo root changes. Starting in a non-repo parent meant no project context loaded at all. Subsequent agent actions (cd into the repo, git worktree add to a new path) did not re-trigger discovery. The runtime treated the launch directory as authoritative for the whole session even after the working repo changed.
2. The repo's guidance is in non-Claude-native locations. There is no CLAUDE.md / .claude/; the operating instructions and skills are in GitHub Copilot's .github/ layout (.github/copilot-instructions.md, .github/skills/). Even had the session started inside the repo, the runtime would not have surfaced these the way it auto-ingests CLAUDE.md. So there was no Claude-native fallback, and nothing prompted the agent to read the Copilot files.

Impact

• The agent improvised procedures the repo documents precisely: solution-level build/test commands and filters, an example-regeneration script, the requirement to run the examples, the playground architecture, and — most consequentially — a mandatory pre-commit code-sample-catalog gate. It shipped three commits that each touched docs/ and left the catalog stale, which the project's CI -Check would have failed.
• The user had to repeatedly redirect the agent to documented tooling it should have found on its own.

Suggested improvements

1. Re-run project-context discovery when the effective repo root changes mid-session — when the agent cds into a git repo, clones one, or runs git worktree add. Discovery should not be a one-shot keyed to the launch cwd.
2. When the launch cwd is a parent of (or sibling to) git repos, detect them and either load/prompt for their context or emit a startup signal ("a repository with agent guidance was found below the working directory; you started outside it").
3. Broaden auto-discovery beyond CLAUDE.md / .claude/ to recognize and surface common cross-tool agent-instruction conventions — .github/copilot-instructions.md, .github/skills/, AGENTS.md, .cursorrules — at minimum as a "these exist, read them" nudge rather than silently ignoring them.
4. Model-behavior reinforcement: when entering an unfamiliar repository, proactively search for and read its operating instructions/skills before acting, instead of inferring conventions from the code.

The single highest-leverage fix is (1): recompute project context from the repository the agent actually ends up working in, not just the directory it was launched from.

Environment

• Claude Code session launched from a parent directory; work performed in a self-created git worktree.
• Repository guidance present at .github/copilot-instructions.md and .github/skills/ (no CLAUDE.md).