GO — Healthy across all four use cases

• Last commit 2mo ago
• 13 active contributors
• MIT licensed
• CI configured
• Tests present
• ⚠ Single-maintainer risk — top contributor 87% of recent commits

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

DevToys is a cross-platform desktop application (built in C# with ~1.6M lines) that bundles 30+ small, single-purpose developer utilities—JSON/YAML converters, Base64/JWT/GZip encoders, hash generators, color blindness simulators, regex testers, and markdown previews. It uses Smart Detection to automatically recommend the right tool based on clipboard contents, eliminating the need to visit untrusted online converters. Monolithic desktop application structured by feature domains rather than layers. Core tools live in feature-specific folders (e.g., tools for encoding/decoding, converters, generators), with shared UI infrastructure in the main assembly. Assets/font/ contains custom icon font (DevToys-Tools-Icons.ttf) for tool UI. .nuke/ directory indicates NUKE build orchestration (parameters.json, build.schema.json). Extension system is pluggable via external packages.

Full-stack and backend developers who frequently need quick encoding/decoding, format conversion, and data transformation tasks; also appealing to security-conscious developers wanting offline, local-only processing without relying on web services.

Actively maintained and production-ready. DevToys 2.0 launched with 30 default tools, has strong localization support via Crowdin with 10+ languages, maintained CI/CD pipelines (.github/workflows/ci.yml), and established governance (CONTRIBUTING.md, CODE-OF-CONDUCT.md). Repository shows consistent activity and professional polish (Microsoft Store listing with high ratings as of May 2024).

Standard open source risks apply.

Active development on tool expansion and localization. The repository actively uses GitHub Issues (advanced labeler configured in .github/workflows/issue_labeler.yml) and PRs for feature/bug tracking. Crowdin integration shows ongoing internationalization efforts. Recent work likely focuses on bug fixes, extension ecosystem maturation, and platform-specific stability (Windows, Linux, macOS via separate DevToysMac project).

Clone: git clone https://github.com/DevToys-app/DevToys.git && cd DevToys. Build: nuke build (using NUKE from .nuke directory). Alternatively, check .github/workflows/ci.yml for exact CI build steps (likely involves dotnet restore && dotnet build). See CONTRIBUTING.md for detailed local setup.

Daily commands: From NUKE: nuke build then nuke run (inferred). Direct .NET: dotnet build src/DevToys.sln then launch compiled executable. Development: open .vscode/launch.json for debugging configurations (pre-configured launch tasks visible). Requires .NET 6+ (inferred from modern C# codebase).

• .github/workflows/ci.yml: Defines the full CI/CD pipeline; essential for understanding build requirements and testing strategy
• .nuke/parameters.json: NUKE build configuration; reveals build targets, dependencies, and compilation parameters
• assets/font/DevToys-Tools-Icons.ttf: Custom icon font embedded in the app; modifying tool icons requires regenerating this asset
• CONTRIBUTING.md: Contributor guidelines; mandatory reading before submitting PRs or starting feature work
• .vscode/launch.json: Debugging configuration; shows how to run and debug the app locally in VS Code
• src/DevToys.sln: Main solution file (inferred); contains all project references and build structure

To add a new tool: create a new folder under the tools domain (e.g., src/DevToys.Tools/Converters/JsonYamlConverter), implement IDevToysTool interface (pattern visible in naming), register in the extension manifest. To update UI icons: edit assets/font/DevToys-Tools-Icons.sfd in FontForge, rebuild TTF. To fix bugs: start in the tool's domain folder, then check shared utilities in src/DevToys.Core/. For localization: contribute to Crowdin project (link in README).

No obvious critical gotchas from file list, but: (1) Custom icon font asset (DevToys-Tools-Icons.ttf) requires FontForge to rebuild if modifying icons—contributors must have FontForge installed or tools won't display updated icons. (2) NUKE build system (unfamiliar to some) replaces traditional .csproj-only builds; check .nuke/build.schema.json for supported targets. (3) Extension system compatibility depends on exact plugin interface contract—breaking changes in src/DevToys.Core interfaces can silently break third-party extensions. (4) Localization via Crowdin is external; translations must be sync'd back before release.

• Plugin/Extension Architecture — DevToys' core value is extensibility—contributors must understand how tools are discovered, loaded, and composed at runtime to add new tools or extend existing ones
• Smart Detection (Clipboard-Based Tool Selection) — The app's killer feature automatically recommends tools based on clipboard content; understanding the detection heuristics and priority order is essential for adding new tools that integrate properly
• NUKE Build Orchestration — The build system is C#-based, not traditional MSBuild; contributors must know NUKE syntax to add build targets, run tests, or modify the CI pipeline
• Icon Font Generation (FontForge / SFD Format) — Tool icons are embedded as a custom TTF font built from an SFD source file; modifying or adding icons requires understanding font compilation and asset embedding
• Cross-Platform UI Abstraction (WinUI 3 + Platform-Specific Variants) — DevToys runs on Windows, Linux, and macOS with different underlying UI frameworks; contributors fixing UI bugs must understand platform-specific layouts and API differences
• Localization via Crowdin Integration — The project uses Crowdin for translations with automated sync; contributors must understand the localization workflow and avoid hardcoding user-facing strings
• Data Transformation Pipeline Patterns (Encode/Decode Chains) — Many tools (Base64 → GZip, JWT decode → JSON format) chain transformations; understanding immutable data flow and composition patterns prevents bugs in tool combinations

• ObuchiYuki/DevToysMac — Official macOS port of DevToys; maintains feature parity and shares the same tool definitions and architecture
• jqlang/jq — Complement for DevToys' JSON processing tools; jq is the industry standard for JSON querying and can be integrated into the app
• stedolan/jq — De facto standard JSON query language; many developers using DevToys also use jq for piped workflows
• cli/cli — GitHub CLI; relevant for developers who combine DevToys data processing with git/GitHub workflows (e.g., decoding JWTs in GitHub Actions)
• microsoft/WindowsAppSDK — Underlying framework for DevToys Windows UI (WinUI 3); understanding WinUI patterns is critical for contributing UI features

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 GitHub Action workflow for cross-platform builds (Windows, macOS, Linux)

The repo has .github/workflows/ci.yml but the file structure shows assets for MacOS, Windows-Linux logos suggesting multi-platform support. The current CI workflow likely lacks platform-specific build matrix testing. New contributors could enhance .github/workflows/ci.yml to include separate build jobs for each platform with artifact verification, ensuring the app builds correctly on all three major OS targets before release.

• [ ] Review current .github/workflows/ci.yml to identify gaps in platform coverage
• [ ] Add matrix strategy for Windows, macOS, and Linux builds
• [ ] Include platform-specific dependencies and build commands
• [ ] Add artifact generation and verification steps for each platform
• [ ] Test locally using act (GitHub Actions local runner) before opening PR

Create comprehensive icon/asset validation tests for DevToys-Tools-Icons

The assets/font directory contains a custom TTF icon font (DevToys-Tools-Icons.ttf) and 30+ SVG tool icons referenced in the README. There's no visible test suite validating that all referenced tool icons exist, are properly formatted, or that the TTF font includes all required glyphs. A new contributor could add tests to validate icon asset completeness and consistency.

• [ ] Create tests directory under assets/font or in root test suite
• [ ] Add test to enumerate all tool icons mentioned in README (30 tools) and verify corresponding .svg files exist
• [ ] Validate TTF font file integrity and confirm all icon glyphs are embedded
• [ ] Add test to check SVG file format compliance and optimize recommendations
• [ ] Integrate tests into .github/workflows/ci.yml to run on PRs

Add missing documentation for tool API/Plugin architecture in CONTRIBUTING.md

The repo has 30 default tools but CONTRIBUTING.md likely lacks specific guidance on how to add new tools/extensions. The EXTENSIONS-TERM-AND-CONDITIONS.md exists, suggesting an extension system exists but isn't documented for contributors. A new contributor could document the tool/plugin creation workflow with examples.

• [ ] Review CONTRIBUTING.md to identify missing tool development sections
• [ ] Document the tool interface/contract required for creating new tools
• [ ] Add step-by-step example: creating a simple new tool (e.g., a basic text case converter)
• [ ] Reference how EXTENSIONS-TERM-AND-CONDITIONS.md applies to custom tools
• [ ] Include pointers to existing tool implementations for reference patterns
• [ ] Add this documentation section to CONTRIBUTING.md with code examples

• Add unit tests for the JSON <> YAML converter tool: The codebase shows 1.6M C# but test coverage is unknown; start by creating a test project (XUnit or NUnit) under tests/DevToys.Tools.Converters.Tests/ with property-based tests for edge cases (empty JSON, special characters, nested structures).
• Improve README documentation for the extension API: The repo mentions 'develop your own' extensions and references EXTENSIONS-TERM-AND-CONDITIONS.md, but no detailed extension tutorial exists in the docs; create a step-by-step guide in /docs/EXTENSION_DEVELOPMENT.md with a minimal working example tool (e.g., ROT13 encoder).
• Add keyboard shortcuts documentation: While .vscode/tasks.json exists for development, there is no visible shortcuts.md or in-app help for common keyboard bindings; catalog existing shortcuts and create a user-facing reference doc or contribute to the help system in the UI.

DevToys demonstrates a reasonable security awareness with a documented security policy and responsible disclosure guidelines. However, the security posture is hindered by: (1) incomplete security documentation, (2) inability to assess dependencies due to missing manifests, and (3) limited visibility into actual source code implementation. The project appears to be well-structured with security documentation in place (SECURITY.md, CODE-OF-CONDUCT.md, PRIVACY-POLICY.md), but comprehensive SAST and dependency scanning are needed for a complete security assessment. The 72/100 score reflects good foundational practices with room for complete documentation and automated security tooling integration.

• Medium · Incomplete Security Policy Documentation — SECURITY.md. The SECURITY.md file appears to be incomplete. The 'Coordinated Disclosure Process' section is cut off mid-sentence, potentially leaving stakeholders uncertain about the full vulnerability handling procedure. Fix: Complete the Security Policy documentation with full details of the coordinated disclosure timeline, patch release process, and communication plan.
• Low · Email Address Partially Obfuscated in Security Policy — SECURITY.md. The security contact email uses 'support[at]velersoftware.com' obfuscation, which may reduce discoverability of the proper security reporting channel. While obfuscation can prevent automated scraping, it may discourage legitimate reporters. Fix: Consider using a dedicated security contact email (e.g., security@velersoftware.com) with proper SPF/DKIM/DMARC configuration instead of obfuscation. Alternatively, prioritize GitHub Security Advisories as the primary reporting channel.
• Low · Missing Dependency Manifest Analysis — Repository Root. No dependency/package files (package.json, requirements.txt, .csproj, etc.) were provided for static analysis. Cannot assess for known vulnerable dependencies, outdated libraries, or insecure transitive dependencies. Fix: Provide dependency manifests for comprehensive vulnerability scanning using tools like OWASP Dependency-Check, Snyk, or GitHub Dependabot.
• Low · Limited Code Source Inspection — Source Code Directory. Only file structure and configuration files were provided. Actual source code (C#, JavaScript, etc.) was not available for analysis of injection vulnerabilities, insecure cryptography, hardcoded credentials, or unsafe data handling patterns. Fix: Perform SAST (Static Application Security Testing) using tools like SonarQube, Checkmarx, or Semgrep against the full codebase. Ensure CI/CD pipeline includes automated security scanning.

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

What it runs against: a local clone of DevToys-app/DevToys — 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 DevToys-app/DevToys | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | Last commit ≤ 103 days ago | Catches sudden abandonment since generation |

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "DevToys-app/DevToys(\\.git)?\\b" \\
  && ok "origin remote is DevToys-app/DevToys" \\
  || miss "origin remote is not DevToys-app/DevToys (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 main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

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