If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/GlitchEnzo/NuGetForUnity shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across the board

• Last commit 3w ago
• 22+ active contributors
• MIT licensed
• CI configured
• Tests present
• ⚠ Concentrated ownership — top contributor handles 52% of recent commits

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live GlitchEnzo/NuGetForUnity repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/GlitchEnzo/NuGetForUnity.

What it runs against: a local clone of GlitchEnzo/NuGetForUnity — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in GlitchEnzo/NuGetForUnity | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 50 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of GlitchEnzo/NuGetForUnity. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/GlitchEnzo/NuGetForUnity.git
#   cd NuGetForUnity
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of GlitchEnzo/NuGetForUnity and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "GlitchEnzo/NuGetForUnity(\\.git)?\\b" \\
  && ok "origin remote is GlitchEnzo/NuGetForUnity" \\
  || miss "origin remote is not GlitchEnzo/NuGetForUnity (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "src/NuGetForUnity.Cli/Program.cs" \\
  && ok "src/NuGetForUnity.Cli/Program.cs" \\
  || miss "missing critical file: src/NuGetForUnity.Cli/Program.cs"
test -f "src/NuGetForUnity.Packager/Assets/NuGet/Editor/NugetForUnity.dll" \\
  && ok "src/NuGetForUnity.Packager/Assets/NuGet/Editor/NugetForUnity.dll" \\
  || miss "missing critical file: src/NuGetForUnity.Packager/Assets/NuGet/Editor/NugetForUnity.dll"
test -f "src/NuGetForUnity.Cli/NugetAssemblyLoadContext.cs" \\
  && ok "src/NuGetForUnity.Cli/NugetAssemblyLoadContext.cs" \\
  || miss "missing critical file: src/NuGetForUnity.Cli/NugetAssemblyLoadContext.cs"
test -f "src/NuGetForUnity.Cli/Fakes" \\
  && ok "src/NuGetForUnity.Cli/Fakes" \\
  || miss "missing critical file: src/NuGetForUnity.Cli/Fakes"
test -f ".github/workflows/main.yml" \\
  && ok ".github/workflows/main.yml" \\
  || miss "missing critical file: .github/workflows/main.yml"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 50 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~20d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/GlitchEnzo/NuGetForUnity"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

NuGetForUnity is a standalone NuGet client package manager built entirely in C# to run inside the Unity Editor, allowing developers to discover, install, update, and manage .NET dependencies directly from a visual UI without leaving Unity. It implements the full NuGet protocol (package search, semantic versioning, dependency resolution) and also provides tools to author and publish custom .nuspec packages, bridging the gap between Unity's native package system and the broader .NET ecosystem. Standard C# project structure: main plugin code in src/NuGetForUnity/, CLI test harness in src/NuGetForUnity.Cli/ with Fakes for Unity API mocking (AssetDatabase.cs, PlayerSettings.cs, etc.), shared build config in src/Directory.Build.props, and GitHub Actions workflows in .github/workflows/. The Fakes pattern allows offline/headless testing without requiring a running Unity Editor.

Unity game and application developers who need to integrate third-party .NET libraries (like logging frameworks, serialization libraries, or utility packages) into their projects, and C# package authors who want to distribute their work via NuGet but need a frictionless distribution mechanism for Unity users.

Production-ready with active maintenance: v4.5.0 published on OpenUPM registry, CI/CD pipelines in .github/workflows/ (activation.yml, main.yml), comprehensive test suites in src/NuGetForUnity.Cli.Tests/, and documented installation paths (git, .unitypackage, OpenUPM). The codebase is stable enough for real-world use, though single-maintainer (GlitchEnzo) creates long-term risk.

Moderate risk: heavily dependent on NuGet.org APIs and .nupkg format stability (external dependencies), relatively small community (compared to Unity's native Package Manager), and maintenance burden rests primarily on one individual. Breaking changes could occur if NuGet protocol evolves or Unity's editor APIs shift, though the Fakes/ abstraction layer (src/NuGetForUnity.Cli/Fakes/) mitigates some Unity API coupling.

Active development indicated by presence of CONTRIBUTING.md, .pre-commit-config.yaml for code quality, GitHub Actions CI pipeline, and multiple documented features (assembly version validation, nuspec editor, package update detection). The plugin-dev-readme.md suggests ongoing plugin architecture maintenance.

Clone the repo: git clone https://github.com/GlitchEnzo/NuGetForUnity.git. Open src/NuGetForUnity.sln in Visual Studio or Rider. The package is designed for integration into Unity projects via git dependency (add to Packages/manifest.json) or OpenUPM: openupm add com.github-glitchenzo.nugetforunity. For local testing, restore NuGet dependencies and run tests via dotnet test src/NuGetForUnity.Cli.Tests/NuGetForUnity.Cli.Tests.csproj.

Daily commands: This is a Unity Editor plugin, not a standalone application. To develop: (1) Open the repository folder in Unity 2018.4+, (2) Build the solution: dotnet build src/NuGetForUnity.sln, (3) Run tests: dotnet test src/NuGetForUnity.Cli.Tests/NuGetForUnity.Cli.Tests.csproj. The plugin activates via menu item in Editor (see docs/screenshots/menu_item.png). No local server needed—it connects directly to nuget.org.

• src/NuGetForUnity.Cli/Program.cs — Entry point for the CLI tool that enables NuGet package management outside the Unity Editor; understanding command routing is essential for extending functionality.
• src/NuGetForUnity.Packager/Assets/NuGet/Editor/NugetForUnity.dll — Core Unity Editor plugin DLL containing the primary package manager UI and logic; the main artifact that contributors interact with.
• src/NuGetForUnity.Cli/NugetAssemblyLoadContext.cs — Manages assembly loading and isolation for the CLI environment; critical for understanding how dependencies are resolved outside Unity.
• src/NuGetForUnity.Cli/Fakes — Fake implementations of Unity APIs (AssetDatabase, Debug, PlayerSettings, etc.) that allow core logic to run without the Unity runtime; essential for understanding architecture.
• .github/workflows/main.yml — CI/CD pipeline defining build, test, and release processes; every contributor must understand how changes are validated and deployed.
• src/NuGetForUnity.Packager/Assets/NuGet.config — NuGet configuration file specifying package sources and settings for the packager project; controls where packages are resolved from.

Add a new CLI command

1. Define the command method signature in the CLI module, handling arguments and options (src/NuGetForUnity.Cli/Program.cs)
2. Implement the command logic using the abstracted NuGet APIs and fake Unity layer (src/NuGetForUnity.Cli/NugetAssemblyLoadContext.cs)
3. Add integration tests for the new command with sample packages and scenarios (src/NuGetForUnity.Cli.Tests/CliRestoreTests.cs)
4. Update plugin-dev-readme.md or contributing guidelines with usage examples (plugin-dev-readme.md)

Add support for a new Unity platform or API level

1. Create a new fake implementation file for the platform-specific API in the Fakes folder (src/NuGetForUnity.Cli/Fakes/BuildTarget.cs)
2. Implement the fake to match Unity's API surface for the target platform (src/NuGetForUnity.Cli/Fakes/PlayerSettings.cs)
3. Register the new fake in the AssemblyLoadContext to wire it into the package resolution pipeline (src/NuGetForUnity.Cli/NugetAssemblyLoadContext.cs)
4. Add test cases for platform-specific assembly filtering and compatibility checks (src/NuGetForUnity.Cli.Tests/CliRestoreTests.cs)

Extend the package manager UI with a new tab or feature

1. Update the NugetForUnity.dll plugin binary by modifying source files and rebuilding via NuGetForUnity.CreateDll (src/NuGetForUnity.CreateDll/NuGetForUnity.CreateDll.csproj)
2. Place the new UI component code in the plugin source directory (compiled into the DLL) (src/NuGetForUnity.Packager/Assets/NuGet/Editor)
3. Rebuild the DLL artifact using the CreateDll project (src/NuGetForUnity.CreateDll/NuGetForUnity.CreateDll.csproj)
4. Export the updated package via the Export.cs tool (src/NuGetForUnity.Packager/Assets/Export.cs)

Update package sources or NuGet configuration

1. Edit the NuGet.config file to add, remove, or modify package feed URLs (src/NuGetForUnity.Packager/Assets/NuGet.config)
2. Ensure the CLI tool respects the configuration by reviewing NugetAssemblyLoadContext (src/NuGetForUnity.Cli/NugetAssemblyLoadContext.cs)
3. Run CLI integration tests to verify feeds are correctly resolved (src/NuGetForUnity.Cli.Tests/CliRestoreTests.cs)
4. Commit changes and verify CI passes in the main workflow (.github/workflows/main.yml)

• C# / .NET Framework — Core language matches Unity Editor scripting environment and allows code reuse across Editor plugin and CLI tool.
• NuGet.org API — Official NuGet package source; enables consuming the entire NuGet ecosystem without reimplementing package resolution.
• Fake/Mock Unity APIs — Decouples package management logic from Unity Editor runtime, allowing the same code to run in CLI and CI environments without the editor.
• AssemblyLoadContext (ALC) — Provides isolated assembly loading for the CLI tool, preventing version conflicts between the tool's dependencies and user packages.
• GitHub Actions CI/CD — Native to the GitHub repository; automates builds, tests, and release workflows across multiple Unity versions and platforms.

• Fake/mock Unity APIs instead of linking real Unity assemblies
  • Why: Enables CLI and build-server usage without purchasing or activating Unity Editor licenses.
  • Consequence: undefined

(1) The Fakes abstraction layer in src/NuGetForUnity.Cli/Fakes/ must be kept in sync with actual Unity APIs—version mismatches can hide real Editor compatibility issues. (2) NuGet.org rate limiting or API changes could break package discovery silently; no fallback mirror is documented. (3) The plugin modifies Unity's asset pipeline and serialization (JsonUtility.cs, ISerializationCallbackReceiver.cs) which can conflict with other editor tools or newer Unity versions. (4) Assembly version validation (see docs/screenshots/assembly-version-validation-setting.png) adds complexity around .NET Framework version targeting—careless changes here break binary compatibility. (5) No explicit dependency management for the CLI tool itself (src/NuGetForUnity.Cli) beyond Directory.Build.props.

• Semantic Versioning (SemVer) — NuGetForUnity's core dependency resolution and update detection logic relies on parsing and comparing semantic versions (major.minor.patch); understanding SemVer ranges, prerelease tags, and compatibility rules is essential for package management logic
• NuGet Package Format (.nupkg, .nuspec) — The plugin reads, parses, and publishes .nupkg files (ZIP archives) and .nuspec metadata files; knowledge of this format is mandatory for features like the nuspec editor and package publishing
• Dependency Graph Resolution — NuGetForUnity must recursively resolve package dependencies, handle version conflicts, and ensure transitive dependencies are installed—a non-trivial algorithm that prevents circular references and satisfies constraints
• Abstract Fakes Pattern for Testing — The Fakes/ directory implements mocks of Unity Editor APIs without requiring a running Editor; this is a sophisticated testing pattern that enables fast CI pipelines and offline development
• REST API Client Design — The plugin communicates with nuget.org's HTTP API to search packages, fetch metadata, and download .nupkg files; understanding REST conventions, HTTP status codes, and API pagination is needed for protocol updates
• MSBuild and .csproj Format — Directory.Build.props centralizes compiler flags and NuGet package references; modifying build outputs, target frameworks, or package version constraints requires understanding MSBuild property evaluation order
• Unity Editor GUI Integration (EditorGUILayout) — The plugin renders UI windows, panels, and dialogs using Unity's Editor GUI APIs; the Editor-specific code is tightly coupled to EditorGUILayout, SerializedObject, and AssetDatabase

• openupm/openupm-cli — Complementary CLI tool for the OpenUPM registry that distributes NuGetForUnity; shares package management philosophy but targets OpenUPM's curated ecosystem instead of raw NuGet.org
• NuGet/NuGet.Client — Official NuGet client source code; NuGetForUnity reimplements key parts (protocol, versioning, dependency resolution) targeting Unity instead of Visual Studio
• Unity-Technologies/upm-package-manager — Unity's native package manager; NuGetForUnity bridges the gap, allowing NuGet packages to work inside Unity's UPM ecosystem
• keijiro/NugetImporter — Alternative older NuGet importer for Unity; NuGetForUnity supersedes this with better UI, semantic versioning support, and active maintenance
• GlitchEnzo/NuGetForUnity-Issues — Official issue tracker and roadmap for this project (implied by CONTRIBUTING.md)

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add integration tests for NuGetForUnity.Cli restore functionality with real NuGet sources

The repo has src/NuGetForUnity.Cli.Tests/CliRestoreTests.cs but it appears to be a test file without comprehensive coverage. The CLI tool needs robust testing against real NuGet.org sources and custom feeds to catch regressions in package resolution, dependency handling, and framework targeting before releases.

• [ ] Expand src/NuGetForUnity.Cli.Tests/CliRestoreTests.cs with test cases for: standard NuGet.org packages, packages with transitive dependencies, and different target frameworks
• [ ] Add test fixtures in src/NuGetForUnity.Cli.Tests/ for mock .nupkg files and nuspec metadata
• [ ] Create a GitHub Actions workflow step in .github/workflows/main.yml to run these tests against staging NuGet sources
• [ ] Document test execution in plugin-dev-readme.md for contributors

Add Unity version compatibility matrix testing in CI/CD

The package targets Unity 2018.4+ (per package.json), but there's no visible CI workflow testing against multiple Unity versions. This is critical for a package manager tool that must work across many Unity editor versions to avoid breaking user workflows.

• [ ] Create a new GitHub Actions workflow (e.g., .github/workflows/unity-version-matrix.yml) that tests against Unity 2018.4 LTS, 2020.3 LTS, 2021.3 LTS, and latest (2022+)
• [ ] Leverage the existing .github/actions/checkout and .github/actions/create-dll actions to build and test across versions
• [ ] Document supported Unity versions and test results in README.md under a new 'Compatibility' section
• [ ] Add any version-specific conditional compilation flags needed in src/Directory.Build.props

Create comprehensive documentation for the Fakes subsystem used in CLI

The src/NuGetForUnity.Cli/Fakes/ directory contains 20+ fake implementations of Unity APIs (AssetDatabase, BuildTarget, EditorUtility, etc.), but there's no explanation of why this pattern exists, how to maintain it, or how to add new fakes when Unity APIs change. This is a maintenance burden for future contributors.

• [ ] Create src/NuGetForUnity.Cli/FAKES_README.md explaining the Fakes pattern, why it's necessary (decoupling CLI from Unity Editor), and the mapping between fake and real classes
• [ ] Add inline code comments to 3-5 representative fake files (e.g., Fakes/AssetDatabase.cs, Fakes/BuildTarget.cs) showing the pattern and common pitfalls
• [ ] Document in CONTRIBUTING.md the checklist for adding a new fake when Unity APIs are used in shared code
• [ ] Link the new Fakes documentation from plugin-dev-readme.md under 'Architecture' section

• Add missing unit tests for NuspecEditor functionality (docs show a nuspec_editor.png feature but no corresponding test coverage visible in src/NuGetForUnity.Cli.Tests/). Create CliNuspecEditorTests.cs to validate .nuspec file parsing and generation.: medium
• Expand Fakes mock coverage: currently missing EditorSceneManager.cs, SerializationUtility.cs, and other Editor APIs that may be used deeper in the plugin. This improves test isolation and CI reliability.: medium
• Add integration test for the full package update flow (CliRestoreTests.cs only covers restore/install): create a test scenario that detects package upgrades, validates version constraints, and prevents downgrades as shown in docs/screenshots/updates_showdowngrades.png.: hard

The NuGetForUnity project demonstrates reasonable security hygiene with GitHub Actions integration, MIT licensing transparency, and organized code structure. However, as a package manager distributing third-party code, it requires careful attention to supply chain security. Key improvements include: (1) implementing a responsible disclosure policy (SECURITY.md), (2) adding package signature verification mechanisms, (3) auditing and documenting dependency management practices, (4) securing GitHub Actions workflows, and (5) hardening dynamic assembly loading. The project would benefit from automated security scanning in CI/CD pipelines and regular security audits of the package management mechanisms.

• Medium · Potential Dependency Vulnerability in NuGet Package Manager — src/NuGetForUnity.Cli, src/NuGetForUnity.Packager. The NuGetForUnity project downloads and manages NuGet packages from external sources. As a package manager, it inherits the risk of malicious or vulnerable packages being installed. The project itself acts as a distribution mechanism for third-party code without explicit validation mechanisms visible in the file structure. Fix: Implement package signature verification, maintain a whitelist of trusted sources, implement security scanning for downloaded packages, and document security best practices for users in CONTRIBUTING.md and README.md.
• Medium · Missing Security Policy Documentation — Repository root. The repository lacks a SECURITY.md file documenting how security vulnerabilities should be reported. This is a best practice for open-source projects and helps create a responsible disclosure process. Fix: Create a SECURITY.md file with instructions for reporting vulnerabilities privately, expected response times, and security contact information.
• Low · Pre-commit Configuration Present — .pre-commit-config.yaml. While the .pre-commit-config.yaml file is a good security practice, it should be reviewed to ensure all hooks are from trusted sources and properly configured to catch security issues. Fix: Review and audit the pre-commit hooks configuration to ensure it includes security-focused checks (e.g., secret scanning, dependency auditing). Ensure all hooks use verified versions from official repositories.
• Low · GitHub Actions Workflow Security — .github/actions/checkout/action.yml, .github/actions/create-dll/action.yml. Custom GitHub Actions are defined in .github/actions/ (checkout, create-dll). These custom actions should be reviewed for secure implementation to prevent workflow injection or privilege escalation attacks. Fix: Review custom GitHub Actions for security best practices: pin action versions, use least privilege, validate inputs, avoid storing secrets in workflows. Consider using official GitHub Actions instead of custom implementations where possible.
• Low · Dependency Management Visibility — src/Directory.Build.props, src/NuGetForUnity.Cli/NuGetForUnity.Cli.csproj, src/NuGetForUnity.CreateDll/NuGetForUnity.CreateDll.csproj. The project uses Directory.Build.props and .csproj files for dependency management. Without access to the actual NuGet dependency declarations, there's a risk of outdated or vulnerable .NET dependencies. Fix: Regularly audit NuGet dependencies using tools like 'dotnet list package --vulnerable' or 'OWASP Dependency-Check'. Configure dependabot for automated dependency updates. Document minimum required versions for critical dependencies.
• Low · Assembly Loading Context Security — src/NuGetForUnity.Cli/NugetAssemblyLoadContext.cs, src/NuGetForUnity.Cli/Fakes/AssemblyLoader.cs. The presence of NugetAssemblyLoadContext.cs and custom assembly loading logic (AssemblyLoader.cs fake) suggests dynamic assembly loading. This can be a security risk if not properly validated. Fix: Ensure assembly loading validates source paths, uses strong naming when available, and implements proper sandboxing. Document the assembly loading strategy and its security implications in plugin-dev-readme.md.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.