WAIT — Single-maintainer risk — review before adopting

• Last commit 2d ago
• 2 active contributors
• Other licensed
• CI configured
• ⚠ Small team — 2 contributors active in recent commits
• ⚠ Single-maintainer risk — top contributor 86% of recent commits
• ⚠ Non-standard license (Other) — review terms
• ⚠ No test directory detected

_{Computed from maintenance signals — commit recency, contributor breadth, bus factor, license, CI, tests}

Everywhere is a context-aware desktop AI assistant built with .NET 10 and Avalonia that perceives and responds to anything on your screen without requiring screenshots. It seamlessly integrates multiple LLMs (via Semantic Kernel patches for Google Gemini, OpenAI, etc.) and MCP tools to provide intelligent, screen-aware responses through a modern cross-platform UI. Multi-platform monorepo with solution files per platform (Everywhere.Windows.slnf, Everywhere.Mac.slnf, Everywhere.Linux.slnf) filtering a single Everywhere.sln; core C# logic in unnamed root projects, UI in Avalonia/XAML, LLM integration via 3rd/semantic-kernel-patch/Connectors.Google with specific implementations for GeminiChatCompletionClient and tool calling. Build tooling in shell/batch/PowerShell scripts at root (GenerateThirdPartyNotices.bat, build-appimage.sh).

Desktop power users and developers who want an always-available AI assistant that understands their current screen context; developers contributing to cross-platform .NET desktop applications using Avalonia; teams integrating multiple LLM providers with tool/MCP support into desktop workflows.

Actively developed and production-ready: the project has significant GitHub recognition (featured on ProductHunt and Trendshift top 15K), multi-platform release workflows (Windows/Mac/Linux CI/CD via GitHub Actions), and a structured release process (CHANGELOG.md, semantic versioning in workflows). Last evidence shows active community (Discord/QQ groups, bilingual docs), suggesting ongoing maintenance beyond initial release.

Moderate risk from custom Semantic Kernel patches in /3rd/semantic-kernel-patch/Connectors.Google — maintaining parallel forks of framework code creates upgrade burden when SK updates. Large C# codebase (2.6MB) is primarily maintained by one author (DearVa). Dependency on multiple LLM providers (Gemini, OpenAI) means service outages or API changes upstream could break features. No visible test directory in file listing suggests potential coverage gaps.

Recent activity includes multi-platform release automation (aur-publish.yml for Linux, macos-release.yml, windows-release.yml), i18n synchronization workflow (sync-i18n.yml suggesting active localization), and stale issue management. Presence of CONTRIBUTING.md, CODE_OF_CONDUCT.md, and SECURITY.md indicates organized community governance. Custom Semantic Kernel Google Gemini connector suggests ongoing LLM provider integration work.

Clone the repository: git clone https://github.com/DearVa/Everywhere.git && cd Everywhere. Open the appropriate solution file for your platform (Everywhere.Windows.sln on Windows, Everywhere.Mac.slnf on macOS, Everywhere.Linux.slnf on Linux) in Visual Studio or JetBrains Rider (.NET 10 required). Restore dependencies: dotnet restore then build with dotnet build. Run the built application from your platform's output directory.

Daily commands: Development: dotnet build followed by dotnet run --project [MainProjectName] (exact project name inferred from sln structure). Production: platform-specific installers are generated by GitHub Actions workflows (aur-publish.yml for AUR, macos-release.yml for macOS, windows-release.yml for Windows using Inno Setup). Local testing: run from build output directory or use dotnet run with appropriate launch profile for your OS.

• src/Everywhere.Abstractions/AI/IModelDefinition.cs — Core abstraction for AI model definitions; all LLM integrations depend on this interface contract
• 3rd/semantic-kernel-patch/Connectors.Google/Services/GoogleAIGeminiChatCompletionService.cs — Custom Gemini LLM connector implementation; essential for understanding how multiple LLM backends are integrated
• docs/StrategyEngine/01-Overview.md — Documents the core StrategyEngine that powers context-aware matching and routing; required reading for contributors
• patches/Everywhere.Patches.Avalonia.Base/Everywhere.Patches.Avalonia.Base.csproj — Custom Avalonia UI framework patches; critical for desktop rendering and UI responsiveness
• Everywhere.sln — Primary solution file orchestrating all projects; entry point for understanding the full build dependency graph
• Directory.Packages.props — Centralized NuGet package versioning; controls all transitive dependencies across the monorepo
• docs/ScreenPicker/01-The-Hacky-Foundation.md — Documents the desktop screen capture and element picking system; foundational for context extraction

Add a new LLM provider (e.g., OpenAI, Claude)

1. Define model interface by implementing IModelDefinition.cs abstraction with provider-specific settings (src/Everywhere.Abstractions/AI/IModelDefinition.cs)
2. Create a custom ChatCompletionService in 3rd/semantic-kernel-patch/<ProviderName>/ mirroring GoogleAIGeminiChatCompletionService.cs structure (3rd/semantic-kernel-patch/Connectors.Google/Services/GoogleAIGeminiChatCompletionService.cs)
3. Add provider .csproj file to wrap the service and models (3rd/semantic-kernel-patch/Connectors.Google/Connectors.Google.csproj)
4. Register the new provider in the semantic kernel pipeline via patches if needed (patches/Everywhere.Patches.SemanticKernel/Everywhere.Patches.SemanticKernel.csproj)

Add a new context-aware strategy or matching rule

1. Create or edit a YAML/JSON configuration file defining match conditions and preprocessors (docs/StrategyEngine/05-ConfigurationFormat.md)
2. Review the matching system to understand predicate evaluation (docs/StrategyEngine/03-MatchingSystem.md)
3. If custom preprocessing is needed, implement a preprocessor following the documented interface (docs/StrategyEngine/04-Preprocessors.md)

Enhance screen capture and element detection

1. Study current implementation challenges and occlusion handling (docs/ScreenPicker/04-The-Overlay-Occlusion-Problem.md)
2. Review the scoped element detection approach (docs/ScreenPicker/03-Implementation-And-New-Architecture.md)
3. Modify Avalonia native patches if platform-specific window interop is needed (patches/Everywhere.Patches.Avalonia.Native/Everywhere.Patches.Avalonia.Native.csproj)

Fix platform-specific UI rendering or input handling

1. Identify which Avalonia patch is relevant (Base, Controls, Native, or AvaloniaEdit) (patches/Everywhere.Patches.Avalonia.Base/patch_TextLeadingPrefixCharacterEllipsis.cs)
2. Modify the corresponding patch file (e.g., patch_*.cs in the appropriate patch project) (patches/Everywhere.Patches.AvaloniaEdit/patch_TextAreaTextInputMethodClient.cs)
3. Rebuild using the platform-specific solution filter (Everywhere.Windows.slnf)

• .NET 10 / C# — High-performance desktop app with strong async/await and LINQ support for complex context matching; single language for all platforms
• Avalonia UI — Cross-platform (Windows, macOS, Linux) desktop framework with XAML and good performance; custom patches allow fine-grained control over rendering
• Semantic Kernel — Unified abstraction for multiple LLM providers; enables pluggable model backends and tool/MCP integration without rewriting core logic
• Custom assembly weaving & patching — Allows fixing upstream Avalonia/SemanticKernel bugs without forking; tight control over third-party behavior for context capture and UI responsiveness

• Custom MSBuild patches instead of vendored source

  • Why: Reduces repository size and merge conflicts; simplifies upgrades to newer framework versions
  • Consequence: Patches must be maintained when upstream breaks; harder to debug (IL-level changes); fragile across .NET versions

• StrategyEngine configuration-driven (YAML/JSON) instead of

  • Why: undefined
  • Consequence: undefined

1. Custom Semantic Kernel patches: The codebase uses patched versions of SK (3rd/semantic-kernel-patch/) rather than mainline NuGet — dependency upgrades require careful manual patching, not just version bumps. 2) Multi-platform project filtering: Building for wrong platform without the correct .slnf file will include desktop APIs incompatible with other OSes; always use Everywhere.Windows.slnf on Windows, not the root sln directly. 3) LLM API keys: The application requires API keys for Google Gemini and/or OpenAI — local testing needs these configured (likely via appsettings or environment variables, not visible in file list). 4) Avalonia XAML designer: XAML files may not preview correctly in older Visual Studio versions; requires recent Avalonia tooling extension. 5) GitHub Actions secrets: Release workflows (windows-release.yml, etc.) depend on secrets (signing certs, API tokens) not in repo — forking requires reconfiguring these.

• Semantic Kernel (SK) — Everywhere's entire LLM integration is built on SK abstractions (IChatCompletionService, ToolCall, etc.); understanding SK's plugin/function calling model is essential for adding providers or tools
• Model Context Protocol (MCP) — Everywhere advertises 'MCP tools' integration for extending AI capabilities; MCP is the standard tool-calling protocol for LLM assistants that this project implements
• Context-Aware Screen Perception — Core differentiator of Everywhere vs generic chatbots — the app perceives current screen state without screenshots; implementation details (accessibility APIs, OCR, UI automation) are likely in main codebase
• Solution Filters (.slnf) — Everywhere uses .slnf files (Windows.slnf, Mac.slnf, Linux.slnf) to enable single-codebase multi-platform builds; understanding this VS feature is critical for maintaining platform-specific logic
• XAML Data Binding (Avalonia) — UI is built in Avalonia XAML with reactive data bindings; modifying screens or adding features requires understanding MVVM patterns and Avalonia's binding syntax
• Tool/Function Calling in LLMs — GeminiFunctionToolCall.cs and tool integration are how Everywhere extends LLMs with custom actions (e.g., launch apps, query files); understanding structured tool schemas is essential for new capabilities
• Cross-Platform Desktop .NET (WinForms vs Avalonia vs MAUI) — Project chose Avalonia over WinForms/WPF for cross-platform support; understanding Avalonia's architecture vs other .NET UI frameworks informs design decisions

• microsoft/semantic-kernel — Upstream LLM abstraction framework that Everywhere patches for Google Gemini support; understanding SK patterns is essential for extending provider support
• AvaloniaUI/Avalonia — Cross-platform XAML UI framework powering Everywhere's desktop interface; required for modifying UI or understanding reactive bindings
• anthropics/anthropic-sdk-python — Example of modern LLM SDK design; useful reference if adding Claude/Anthropic provider support alongside existing Gemini/OpenAI
• OpenAI/openai-python — OpenAI SDK patterns and tool calling conventions; relevant since Everywhere already integrates OpenAI via Semantic Kernel
• tauri-apps/tauri — Alternative Rust-based desktop AI assistant framework; useful comparison for understanding tradeoffs of .NET/Avalonia vs Rust/web-based approaches

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 comprehensive tests for StrategyEngine matching system

The docs/StrategyEngine/ directory contains detailed documentation about the matching system (MatchingSystem.md, Preprocessors.md, ConfigurationFormat.md), but there are no visible test files in the repo structure. Given the complexity of the strategy engine with preprocessors and configuration matching, adding unit tests would prevent regressions and serve as executable documentation.

• [ ] Create Tests/ or src/Tests/ directory structure for StrategyEngine tests
• [ ] Add tests for ConfigurationFormat parsing based on docs/StrategyEngine/05-ConfigurationFormat.md
• [ ] Add tests for preprocessor chain execution based on docs/StrategyEngine/04-Preprocessors.md
• [ ] Add tests for the matching algorithm outlined in docs/StrategyEngine/03-MatchingSystem.md
• [ ] Ensure tests cover edge cases like nested configurations and preprocessor failures

Implement cross-platform ScreenPicker integration tests

The docs/ScreenPicker/ directory documents a sophisticated overlay occlusion problem (04-The-Overlay-Occlusion-Problem.md) and architecture across platforms. The repo has separate solution filters (Everywhere.Windows.slnf, Everywhere.Mac.slnf, Everywhere.Linux.slnf) but lacks visible integration tests. Adding platform-specific tests would validate the scoped ElementFromPoint implementation across Windows, macOS, and Linux.

• [ ] Create platform-specific test projects referencing the solution filters
• [ ] Add tests for ElementFromPoint behavior on Windows using the Windows test filter
• [ ] Add tests for overlay occlusion detection and handling on macOS
• [ ] Add tests for Linux X11/Wayland compatibility in ScreenPicker
• [ ] Create shared test utilities for cross-platform validation in docs/ScreenPicker/03-Implementation-And-New-Architecture.md

Add Google Gemini connector tests and documentation

The 3rd/semantic-kernel-patch/Connectors.Google directory contains custom Gemini integration code (GeminiChatCompletionClient.cs, GeminiRequest.cs) but has minimal documentation. Adding tests would validate the custom patch implementation and provide examples for maintainers handling Semantic Kernel integration.

• [ ] Create Tests/Connectors.Google/ test project in 3rd/semantic-kernel-patch/
• [ ] Add unit tests for GeminiChatCompletionClient.cs covering message serialization/deserialization
• [ ] Add tests for GeminiRequest.cs model transformations
• [ ] Add integration tests for GeminiFunctionToolCall.cs and tool calling behavior
• [ ] Update 3rd/semantic-kernel-patch/README.md with testing instructions and rationale for the custom connector

• Add unit tests for GeminiChatCompletionClient.cs and GeminiFunctionToolCall.cs — these critical LLM integration points currently have no visible test coverage; create a new Tests/ folder and add xUnit tests covering success/failure paths for tool calling: medium: Improves reliability of core LLM integration without requiring deep domain knowledge
• Document the custom Semantic Kernel patches (3rd/semantic-kernel-patch/) with a README.md explaining why the Google Gemini connector is forked, what deviations exist from mainline SK, and the upgrade process for SK versions: easy: Reduces friction for future maintainers and contributors; no code changes needed, purely documentation
• Add missing i18n strings to the XAML and C# code for menu/button labels visible in screenshot banner but not in file list — extract to resx/XAML resources for localization matching the sync-i18n.yml workflow: medium: Enables the existing i18n workflow to function; improves multi-language support already attempted via sync-i18n.yml

The codebase shows moderate security posture with several areas of concern. Primary risks stem from custom build-time code modification (assembly weaving), third-party patches without clear verification mechanisms, and LLM/external service integration. The project lacks visible dependency lock files and detailed security documentation for the patching system. No critical vulnerabilities were identified in the file structure itself, but security practices around build pipelines, third-party code, and AI integration should be strengthened with comprehensive audit logs, verification mechanisms, and security policies.

• Medium · Third-party patch code without clear verification — 3rd/semantic-kernel-patch/. The codebase includes third-party patched code in the 3rd/semantic-kernel-patch directory. These patches appear to modify critical components like Google Gemini connectors. Without clear documentation of verification mechanisms, patch signatures, or integrity checks, there's a risk of supply chain attacks or unvetted code execution. Fix: Implement code review procedures for all third-party patches, maintain detailed changelogs with justifications, use cryptographic signatures for patch verification, and consider vendoring dependencies instead of applying patches when possible.
• Medium · Build task patcher with assembly weaving capabilities — patches/Everywhere.BuildTask.Patcher/WeaveAssembliesTask.cs. The project includes custom build tasks (WeaveAssembliesTask.cs) that modify assemblies at compile time. Assembly weaving can bypass normal security boundaries and should be carefully audited. The patcher also includes file replacement logic that could introduce security risks if paths are not properly validated. Fix: Audit the assembly weaving logic to ensure it doesn't introduce security vulnerabilities, validate all file paths, implement logging of all modifications, and consider using only approved .NET reflection techniques.
• Low · Multiple platform-specific build workflows — .github/workflows/. The presence of multiple release workflows (windows-release.yml, macos-release.yml, linux-release.yml) without visible inspection of their contents creates a potential risk. Build systems are critical attack vectors for supply chain compromises. Fix: Ensure all CI/CD workflows use pinned action versions, implement approval gates for releases, use OIDC token authentication where available, enable artifact signing/attestation, and regularly audit workflow permissions.
• Low · LLM and MCP tool integration security — Entire application (inferred from README). As a context-aware AI assistant that integrates multiple LLMs and MCP tools, there's inherent risk of prompt injection attacks, insecure data handling when processing user context, and potential exposure of sensitive information to external LLM services. Fix: Implement prompt injection filtering, sanitize all user inputs before sending to LLMs, encrypt sensitive data at rest and in transit, implement audit logging for all LLM interactions, use API key rotation, and clearly document data retention policies.

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

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

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/DearVa/Everywhere 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.

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

What it runs against: a local clone of DearVa/Everywhere — 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 DearVa/Everywhere | Confirms the artifact applies here, not a fork | | 2 | License is still Other | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 32 days ago | Catches sudden abandonment since generation |

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

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

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

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

# 4. Critical files exist
test -f "src/Everywhere.Abstractions/AI/IModelDefinition.cs" \\
  && ok "src/Everywhere.Abstractions/AI/IModelDefinition.cs" \\
  || miss "missing critical file: src/Everywhere.Abstractions/AI/IModelDefinition.cs"
test -f "3rd/semantic-kernel-patch/Connectors.Google/Services/GoogleAIGeminiChatCompletionService.cs" \\
  && ok "3rd/semantic-kernel-patch/Connectors.Google/Services/GoogleAIGeminiChatCompletionService.cs" \\
  || miss "missing critical file: 3rd/semantic-kernel-patch/Connectors.Google/Services/GoogleAIGeminiChatCompletionService.cs"
test -f "docs/StrategyEngine/01-Overview.md" \\
  && ok "docs/StrategyEngine/01-Overview.md" \\
  || miss "missing critical file: docs/StrategyEngine/01-Overview.md"
test -f "patches/Everywhere.Patches.Avalonia.Base/Everywhere.Patches.Avalonia.Base.csproj" \\
  && ok "patches/Everywhere.Patches.Avalonia.Base/Everywhere.Patches.Avalonia.Base.csproj" \\
  || miss "missing critical file: patches/Everywhere.Patches.Avalonia.Base/Everywhere.Patches.Avalonia.Base.csproj"
test -f "Everywhere.sln" \\
  && ok "Everywhere.sln" \\
  || miss "missing critical file: Everywhere.sln"

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

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