[kartheekp-ms]

Summary

Running dotnet-package-skills from a project subdirectory currently uses that subdirectory's .agents/skills folder. This change resolves the default destination from an ancestor Git or solution directory instead.

• Select the nearest ancestor containing a .git directory/file or a .sln/.slnx file (case-insensitive solution extensions), then use its .agents/skills folder. Fall back to the invocation directory when no marker exists.
• Share this resolution across install, list, and uninstall, including manifest lookup, interactive flows, and dry runs.
• Preserve explicit --destination paths: relative paths remain invocation-relative, even when explicitly set to .agents/skills.
• Keep source discovery, package-reference scope, and relative source/cache path resolution unchanged.
• Update destination help and README documentation. Existing subdirectory installations are not migrated automatically.

SDK directory-selection behavior

The resolver matches the directory-selection behavior of the .NET SDK's GetDirectoryToCreateToolManifest:

1. Start at the invocation directory and walk upward, stopping before the filesystem root.
2. At each directory, check for a .git directory first, then enumerate .sln/.slnx files, then check for a .git file. Return the first matching directory.
3. If no directory matches, use the invocation directory.

PR build succeeded

[Copilot]

🟡 Changes recommended

Stale cleanup can delete skills still required by sibling projects because implicit ancestor-destination discovery compares a shared manifest against only the invoking project's references.

2 open issues

• Guard stale operations on implicitly discovered shared destinations · New
• Explain unreadable ancestor errors during destination discovery · New

What changed in this PR

This PR makes dotnet-package-skills use a shared default skills folder under the nearest Git or solution ancestor when invoked from a project subdirectory.

Changes:

• Add nearest-marker discovery, with invocation-directory fallback and explicit destination overrides.
• Apply consistent destination and manifest resolution across install, list, and uninstall without changing source/cache path resolution.
• Add resolver and CLI coverage, and document the new default behavior.

File	Description
dotnet-package-skills/​tests/​DestinationLocatorTests.cs	Tests markers, precedence, fallback, and explicit paths.
dotnet-package-skills/​tests/​DestinationCommandLineTests.cs	Tests shared destinations, manifests, and command behavior.
dotnet-package-skills/​src/​Program.cs	Wires destination discovery into commands and updates help.
dotnet-package-skills/​src/​Infrastructure/​DestinationLocator.cs	Implements ancestor-marker destination resolution.
dotnet-package-skills/​README.md	Documents discovery, overrides, and existing-installation handling.

_{Review effort: Max}

[Copilot]

🟡 Changes recommended

Successful install and uninstall --stale runs with both --source and --destination omitted are untested, leaving invocation-local destination handling unprotected against regressions.

1 open issue

• Test default install and stale uninstall in the invocation directory · New

2 resolved since last review

• Guard stale operations on implicitly discovered shared destinations
• Explain unreadable ancestor errors during destination discovery

_{Review effort: Max}

[Copilot]

🔵 Needs a closer look

The guard’s allowed path lacks CLI test coverage, so a regression could reject the primary repository-root install and stale-uninstall workflows without failing tests.

No open issues 🎉

1 resolved since last review

• Test default install and stale uninstall in the invocation directory

_{Review effort: Max}

[Copilot]

🔵 Needs a closer look

Human assessment is needed to weigh unpublished documentation findings about destination-wide uninstall behavior and misleading guidance for inspecting tracked installations.

No open issues 🎉

_{Review effort: Max}