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/unoplatform/uno 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 today
• 13 active contributors
• Distributed ownership (top contributor 31% of recent commits)
• Apache-2.0 licensed
• CI configured
• Tests present

_{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 unoplatform/uno repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/unoplatform/uno.

What it runs against: a local clone of unoplatform/uno — 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 unoplatform/uno | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | 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 ≤ 30 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of unoplatform/uno. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/unoplatform/uno.git
#   cd uno
#
# 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 unoplatform/uno and re-run."
  exit 2
fi

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

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 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 ".github/config.yml" \\
  && ok ".github/config.yml" \\
  || miss "missing critical file: .github/config.yml"
test -f ".editorconfig" \\
  && ok ".editorconfig" \\
  || miss "missing critical file: .editorconfig"
test -f ".globalconfig" \\
  && ok ".globalconfig" \\
  || miss "missing critical file: .globalconfig"
test -f ".specify/extensions.yml" \\
  && ok ".specify/extensions.yml" \\
  || miss "missing critical file: .specify/extensions.yml"
test -f ".github/CODEOWNERS" \\
  && ok ".github/CODEOWNERS" \\
  || miss "missing critical file: .github/CODEOWNERS"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 30 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~0d)"
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/unoplatform/uno"
  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).

Uno Platform is an open-source .NET framework that compiles a single C#/XAML codebase into native applications for Web (WebAssembly), Desktop (Windows/macOS/Linux via Skia), Mobile (iOS/Android), and Embedded systems. It reuses the WinUI 3 API surface, enabling developers to write once and deploy natively across all platforms with Hot Reload support and 90M+ NuGet downloads. Monorepo structure: Core C# framework in root with platform-specific heads (iOS via Objective-C, Android via Java, Web via TypeScript/WebAssembly). Build tools in .config/ (dotnet-tools.json), dev container setup in .devcontainer/, and Claude-based automation skills in .claude/skills/ for development workflows (git, implementation, testing, WinUI porting).

C# and XAML developers building enterprise cross-platform applications (used by Toyota, Microsoft, Kahua) who want to avoid maintaining separate codebases for mobile, web, and desktop while leveraging existing .NET/WinUI skills.

Production-ready and actively maintained: 10,000+ GitHub stars, 130M+ NuGet downloads, 300+ contributors, enterprise users in production. The repo shows active development with structured CI/CD (Azure DevOps in .github), comprehensive issue templates (.github/ISSUE_TEMPLATE), and .claude/skills indicating ongoing tooling/automation development.

Low risk for well-maintained components; however, as a large cross-platform framework touching mobile (Java/Objective-C), web (TypeScript), and desktop (C#), platform-specific bugs are possible. The codebase is monolithic (61M+ lines of C#) so large breaking changes could impact many consumers. Single points of failure exist around platform heads (iOS/Android/WASM) that require deep platform knowledge.

Active development visible in: (1) WinUI runtime test automation (.claude/skills/winui-runtime-tests/ with PowerShell scripts for cert setup and MSIX installation), (2) Speckit workflow skills (planning, implementation, testing, git workflows), (3) Ongoing toolchain improvements (dotnet-tools configuration), (4) Sample management and runtime test infrastructure.

Clone and initialize: git clone https://github.com/unoplatform/uno.git && cd uno. Install .NET tools via dotnet tool restore (uses .config/dotnet-tools.json). For dev container: open in VS Code with Remote Containers extension or use gitpod.io/#https://github.com/unoplatform/uno. Check specific platform setup in .devcontainer/Dockerfile and .devcontainer/post-start.sh.

Daily commands: No single npm start or dotnet run command visible—this is a framework, not an app. To build: dotnet build at repo root (requires .NET SDK matching version in .config/dotnet-tools.json). For dev container: use .devcontainer/post-start.sh which runs initialization scripts. Platform-specific builds require platform SDKs (Xcode for iOS, Android NDK for Android, Node for Web).

• .github/config.yml — Central GitHub Actions and CI/CD configuration that controls build, test, and deployment workflows across all platforms.
• .editorconfig — Defines code style and formatting standards enforced across the entire C# and XAML codebase for consistency.
• .globalconfig — .NET analyzer and code quality rules configuration; every contributor must understand the linting standards.
• .specify/extensions.yml — Specification kit extensions configuration that drives code generation, AI-assisted workflows, and enforcement rules.
• .github/CODEOWNERS — Defines who reviews changes to critical areas; essential for understanding review requirements and ownership.
• .devcontainer/devcontainer.json — Standardized development environment setup; all contributors should use this for reproducible local development.

• GitHub Actions Workflow Orchestrator (YAML, GitHub Actions, PowerShell, Bash) — Triggers builds, runs tests, performs code analysis, publishes NuGet packages, and manages deployments
  • Failure mode: Build or test failure blocks PR merge; workflow timeout causes manual intervention
• C# / XAML Compiler & Roslyn Analyzers — Compiles source code to IL, applies source generators, validates code quality rules

Add a New AI-Assisted Development Skill

1. Create skill definition file with metadata and instructions (.claude/skills/{skill-name}/SKILL.md)
2. Register skill in the SpecKit extensions registry (.specify/extensions.yml)
3. Create corresponding GitHub agent specification if automation is needed (.github/agents/{skill-name}-agent.md)
4. Add workflow or CI/CD trigger if skill should run automatically (.github/workflows/{skill-trigger}.yml)

Add a New Runtime Test Suite

1. Create test skill and specification (.claude/skills/runtime-tests/SKILL.md)
2. Configure Windows MSIX test installer script (.claude/skills/winui-runtime-tests/install-msix.ps1)
3. Add CI/CD workflow for automated test execution (.github/workflows/codeql.yml)

Port a WinUI Component

1. Reference the WinUI porting skill specification (.claude/skills/winui-port/SKILL.md)
2. Use the WinUI porting agent for AI-assisted code generation (.github/agents/winui-porting-agent.md)
3. Add WinUI runtime tests for validation (.claude/skills/winui-runtime-tests/run-tests.ps1)
4. Follow commit message conventions as specified in SpecKit (.specify/extensions/git/commands/speckit.git.commit.md)

Configure Code Quality Rules

1. Define .NET analyzer rules and severity levels (.globalconfig)
2. Set editor formatting standards (.editorconfig)
3. Configure Codacy integration for continuous monitoring (.codacy.yml)
4. Update codeowners to assign review responsibility (.github/CODEOWNERS)

• C# / XAML — Primary language for Uno Platform; enables single-codebase cross-platform mobile/web/desktop development
• GitHub Actions — Integrated CI/CD automation for builds, tests, code quality, and security scanning
• .NET / .NET MAUI — Core runtime framework for compiling and running Uno applications across platforms
• SpecKit + Claude AI — Enables AI-assisted development workflows, code generation, and documentation automation
• Docker / DevContainers — Standardizes local and CI/CD development environments across Linux, macOS, and Windows

• Single codebase for all platforms (mobile/web/desktop)

  • Why: Reduces duplication, accelerates feature delivery, simplifies maintenance
  • Consequence: Higher complexity in platform-specific abstraction layers; potential performance trade-offs per platform

• AI-assisted development (Claude + SpecKit)

  • Why: Accelerates feature implementation, reduces manual boilerplate, enables junior developers
  • Consequence: Requires careful prompt engineering and code review; AI output quality depends on training data

• GitHub Actions for CI/CD over dedicated build infrastructure

  • Why: Reduces operational overhead, integrates tightly with GitHub, cost-effective for open source
  • Consequence: Build times can be longer; concurrent job limits; less control over hardware

• Open-source on GitHub with extensive automation

  • Why: Attracts community contributors, enables transparency, speeds up releases
  • Consequence: High overhead for issue triage, PR review, and security vulnerability management

• Does not provide a proprietary IDE or visual designer
• Does not support non-.NET languages as primary development targets
• Does not offer enterprise commercial support or SLA guarantees
• Does not include built-in backend or cloud service infrastructure
• Does not manage dependency updates automatically (reliant on Dependabot configuration)

(1) Platform SDK requirements: Building for iOS requires Xcode with provisioning profiles; Android requires NDK; full cross-platform build is non-trivial. (2) WebAssembly toolchain: TypeScript compilation and WASM runtime setup may require Node/npm in addition to .NET. (3) Monorepo scale: dotnet build at root rebuilds everything; use project-specific builds for faster iteration (e.g., dotnet build src/Uno.UI/). (4) Hot Reload: requires specific runtime support per platform—not all platforms may support it equally. (5) WASM size: Web builds can be large; Uno uses Skia which impacts bundle size.

• Transpilation to Platform-Native APIs — Understanding how Uno compiles a single XAML/C# codebase into platform-specific outputs (UIKit for iOS, Android framework for Android, Skia for Desktop/Web) is core to fixing platform-specific bugs and understanding why certain APIs may behave differently.
• WebAssembly (WASM) and Skia Rendering — Uno uses Skia as the renderer for Web (via WASM) and Desktop platforms; this is non-standard for web development and requires understanding canvas-based rendering, memory layout in WASM, and Skia's API surface.
• WinUI 3 API Surface Compatibility — Uno's entire value proposition is implementing the WinUI 3 API surface across platforms; understanding which WinUI controls map to which platform primitives is essential for adding features or fixing compatibility issues.
• Platform Heads and Abstraction Layers — Uno separates platform-specific code (iOS, Android, Web, Desktop) into 'platform heads' with a shared abstraction layer; understanding this separation is crucial for diagnosing which layer a bug is in and avoiding platform-specific hacks.
• Hot Reload and MVVM Patterns — Uno's Hot Reload feature relies on strict MVVM separation and property binding; modifying XAML/C# code and seeing changes live requires understanding how Uno's binding system and hot reload runtime interacts with platform-specific event loops.
• Monorepo Build Organization and Incremental Compilation — This is a massive monorepo (61M+ lines of C#); understanding how to selectively rebuild only changed platform heads, use project file filters, and avoid full-repo rebuilds is essential for productivity.
• Dependency Injection and Service Locator Pattern — Uno uses DI for platform service abstraction (e.g., to abstract iOS UIView layout from Android View layout); understanding how services are registered and resolved per-platform is essential for adding platform-agnostic features.

• microsoft/winui-3 — Official WinUI 3 repository that Uno Platform implements/mirrors; needed to track API surface compatibility
• dotnet/maui — Microsoft's alternative cross-platform .NET framework using XAML; direct competitor solving the same multi-platform C#/XAML problem
• unoplatform/uno.samples — Official Uno Platform samples and templates repository—entry point for new users and reference implementations
• unoplatform/uno.extensions — Extensions/toolkit for Uno Platform providing higher-level abstractions, navigation, validation patterns built on core framework
• xamarin/xamarin-forms — Legacy cross-platform .NET/XAML framework that Uno partly succeeds; valuable for understanding design decisions and migration paths

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.

Create comprehensive SKILL.md documentation for .claude/skills directory

The .claude/skills directory contains 15+ skill definitions but lacks a root-level index or navigation guide. New contributors cannot easily understand the skill ecosystem, dependencies, or how to extend it. Creating a SKILLS_INDEX.md in .claude/ would document each skill's purpose, prerequisites, and integration points, making the skill system more maintainable and onboardable.

• [ ] Review all 15 SKILL.md files in .claude/skills/*/SKILL.md to extract purpose, inputs, outputs, and dependencies
• [ ] Create .claude/SKILLS_INDEX.md with a table documenting each skill (name, purpose, category: speckit/winui/runtime/other)
• [ ] Add cross-reference documentation showing skill dependencies (e.g., speckit-git-feature depends on speckit-git-initialize)
• [ ] Include a 'Getting Started' section for contributors wanting to create new skills
• [ ] Link this index from the root README or CONTRIBUTING guide

Add GitHub Actions workflow validation for .github/agents/*.md files

The .github/agents/ directory contains 5 agent specification files (dependency-property-agent.md, devserver-agent.md, etc.) but there's no validation workflow to ensure these specs remain accurate or lint-checked as code evolves. Adding a CI workflow would catch broken agent references and configuration drift early.

• [ ] Create .github/workflows/validate-agents.yml workflow that runs on PRs touching .github/agents/ files
• [ ] Add a linting script (scripts/validate-agents.sh or similar) to check for: broken cross-references between agent files, required YAML frontmatter fields, and matching agent definitions vs actual implementations
• [ ] Ensure workflow also validates that agents reference existing skills from .claude/skills/
• [ ] Add workflow status badge to README if validation passes

Document devcontainer setup and troubleshoot .devcontainer initialization

The .devcontainer/ directory contains a Dockerfile, devcontainer.json, and post-start.sh scripts, but no DEVCONTAINER.md guide exists explaining setup, common issues (firewall, dotnet tools), and debugging steps. New contributors using Dev Containers (especially on Linux with init-firewall.sh) face friction without documentation.

• [ ] Create .devcontainer/README.md documenting: prerequisites (Docker, VS Code extension), quick-start, custom environment variables, and expected tools installed
• [ ] Document the purpose of each script (init-firewall.sh for Linux networking, post-start.sh for tool setup, dotnet-tools.json dependencies)
• [ ] Add troubleshooting section covering common issues: firewall errors on Linux, dotnet tools not found, Dockerfile build timeouts
• [ ] Include a verification checklist users can run post-setup to confirm all tools (dotnet, git, etc.) are available
• [ ] Link this guide from root CONTRIBUTING.md

• Add missing unit tests for platform-specific code paths in the Web/WASM head—identify untested TypeScript files in the transpiler output and write tests in .test.ts format following existing patterns.
• Expand CI/CD coverage in .github/workflows/ (inferred—not visible in file list) to run runtime tests for all platforms on every PR, not just Windows; reference .claude/skills/winui-runtime-tests/ as a model.
• Document the dev container setup for non-Windows developers: create a .devcontainer/README.md with step-by-step instructions for iOS/Android/Web setup since .devcontainer/init-firewall.sh and .devcontainer/post-start.sh exist but lack documentation.

The unoplatform/uno repository demonstrates reasonable security practices with a proper SECURITY.md vulnerability disclosure policy, presence of dependency management tools, and GitHub-native security features (Dependabot, CodeQL workflows). However, several areas require attention: (1) Dependency versions and integrity should be verified given this is a widely-downloaded platform (90M+ NuGet downloads); (2) Container and development tooling should be audited for secret exposure; (3) PowerShell scripts require elevated privilege review; (4) GitHub Actions workflows need verification for secure patterns. The large scale and complexity of this cross-platform development framework increases the attack surface. Recommend implementing automated supply chain security scanning, enforcing code signing, and establishing a formal security review process for high-risk components.

• Low · Security Contact Email Exposure — SECURITY.md. The security contact email (security@platform.uno) is publicly exposed in the SECURITY.md file. While this is intentional for vulnerability disclosure, it may attract unwanted attention or spam. Fix: This is acceptable practice for security reporting. Consider implementing email filtering and rate limiting on the security mailbox to mitigate spam/abuse risks.
• Medium · Dependency Management Visibility — .config/dotnet-tools.json. The .config/dotnet-tools.json file is present but its content was not provided for analysis. .NET tools can introduce supply chain risks if outdated or compromised versions are pinned. Fix: Regularly audit and update dependencies. Implement automated vulnerability scanning in CI/CD pipelines. Use package signing verification. Pin exact versions rather than ranges where possible.
• Medium · DevContainer Configuration Exposure — .devcontainer/Dockerfile, .devcontainer/devcontainer.json. DevContainer files (.devcontainer/Dockerfile, .devcontainer/devcontainer.json) may contain sensitive configuration or build instructions that could expose internal development practices or secrets if compromised. Fix: Ensure no credentials, API keys, or sensitive configuration are hardcoded in devcontainer files. Use secrets management for sensitive values. Review all mounted volumes and port exposures.
• Low · Firewall Configuration Script — .devcontainer/init-firewall.sh. An init-firewall.sh script is present in the devcontainer configuration which modifies system firewall rules. Misconfiguration could create security gaps. Fix: Review the firewall script for least-privilege principles. Document which ports/services require exposure. Use explicit allow rules rather than blanket open rules.
• Low · PowerShell Script Execution in CI/CD — .claude/skills/winui-runtime-tests/*.ps1. Multiple PowerShell scripts are present in the winui-runtime-tests directory that execute system-level operations (certificate setup, MSIX installation, cleanup). PowerShell scripts have high privilege requirements. Fix: Ensure all PowerShell scripts are properly code-reviewed. Implement execution policy restrictions. Avoid running with elevated privileges unless absolutely necessary. Use signed scripts in production environments.
• Medium · GitHub Actions Workflow Security — .github/workflows/. Multiple GitHub Actions workflows are defined (.github/workflows/) but content was not provided. Workflows can pose security risks if they execute untrusted code or expose secrets improperly. Fix: Implement workflow security best practices: use trusted actions with pinned versions, implement OIDC token restrictions, use environments with required reviews, audit secrets access, disable dangerous permissions (contents, deployments).
• Low · Dependabot Configuration Present — .github/dependabot.yml. Dependabot configuration exists (.github/dependabot.yml) which is positive, but its configuration content was not provided for security review. Fix: Verify dependabot is configured to: check all package ecosystems, enable auto-merge for patches only after testing, require status checks before merging, and set appropriate update frequency.

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.