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/lysyi3m/macos-terminal-themes 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.

WAIT — Missing license — unclear to depend on

• Last commit 2mo ago
• 30+ active contributors
• ⚠ Concentrated ownership — top contributor handles 55% of recent commits
• ⚠ No license — legally unclear to depend on
• ⚠ No CI workflows detected
• ⚠ No test directory detected

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

What it runs against: a local clone of lysyi3m/macos-terminal-themes — 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 lysyi3m/macos-terminal-themes | Confirms the artifact applies here, not a fork | | 2 | Default branch master exists | Catches branch renames | | 3 | 3 critical file paths still exist | Catches refactors that moved load-bearing code | | 4 | Last commit ≤ 97 days ago | Catches sudden abandonment since generation |

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

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

# 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 "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"
test -f "tools/iterm2termina" \\
  && ok "tools/iterm2termina" \\
  || miss "missing critical file: tools/iterm2termina"
test -f "themes/" \\
  && ok "themes/" \\
  || miss "missing critical file: themes/"

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

A collection of 100+ color themes for macOS Terminal.app that originated from iTerm2 color schemes. The repo provides ready-to-install .terminal files that define ANSI color palettes (16 colors + background/foreground) and a Swift tool (iterm2terminal.swift) to convert iTerm2 .itermcolors XML files into macOS Terminal format. Flat structure: themes/ directory contains 100+ .terminal files (one per theme), screenshots/ holds PNG previews, tools/ holds two Swift scripts (iterm2terminal.swift for conversion, preview.sh for generating test output). No package managers or build system—purely static theme files + utility scripts.

macOS Terminal.app users who want visual customization beyond the 5-6 built-in themes, and theme designers/maintainers who need to port iTerm2 themes to macOS native Terminal without manual XML editing.

Stable and mature: the repo has 50+ stars, 100+ curated themes with screenshots, and mirrors a popular predecessor (mbadolato/iTerm2-Color-Schemes). However, there is no visible CI/CD, no test suite, and the last commit activity is not disclosed in the provided metadata—indicates this is a maintained reference library rather than an actively developed tool.

Low risk for installation—themes are static .terminal files (macOS plist XML) with no runtime dependencies or network calls. Single-maintainer repo (lysyi3m) with no dependency management means no supply-chain risk, but also means contributions or bug reports may have slow turnaround. No test coverage or CI makes theme validation manual.

Unable to determine from provided metadata (no commit history, PR list, or recent activity visible). Repo appears to be in maintenance mode with periodic theme additions, but no active feature development signals are evident.

git clone https://github.com/lysyi3m/macos-terminal-themes.git
cd macos-terminal-themes
cd themes
open "YourFavoriteTheme.terminal"  # Opens theme in Terminal.app

Then in Terminal menu: Shell → Use Settings as Default to activate.

Daily commands: Not a runnable application. To test a theme: open themes/YourTheme.terminal opens it in Terminal.app. To preview before installing, load the theme and run bash tools/preview.sh to display ANSI color test pattern. To convert an iTerm2 theme: swift tools/iterm2terminal.swift /path/to/theme.itermcolors > NewTheme.terminal.

• README.md — Entry point explaining the repo's purpose, installation instructions, and the conversion tool for iTerm2 themes—essential for understanding how to use and extend this project
• tools/iterm2termina — Core conversion script that transforms iTerm2 color schemes into macOS Terminal themes; critical for adding new themes programmatically
• themes/ — Directory containing all .terminal theme files that users directly interact with; the primary deliverable of this repository

• .terminal theme files (XML plist (macOS property list)) — Encapsulate color definitions (RGB values for 16 ANSI colors + background/foreground) in plist format
  • Failure mode: Malformed XML or invalid color values prevent theme import; Terminal.app silently rejects or uses defaults
• iterm2termina tool (Shell script (likely sed/awk or XML parsing)) — Parses iTerm2 .itermcolors XML and maps color definitions to macOS .terminal plist structure
  • Failure mode: Incorrect color mapping or invalid output format produces unusable .terminal files
• Documentation (README.md) (Markdown) — Communicates installation process, prerequisites (shell color formatting), and tool usage to users
  • Failure mode: Outdated or unclear instructions lead users to incorrect installation steps or unmet prerequisites

• iTerm2-Color-Schemes (external repo) → iterm2termina tool — Developer obtains .itermcolors file from upstream source
• iterm2termina tool → themes/ directory — Conversion script outputs .terminal file, committed to repo
• themes/ directory → GitHub repository — All .terminal files are version-controlled and distributed via git
• GitHub repository → User's local file system — User clones or downloads repo
• themes/ directory (local) → Finder → Terminal.app — User double-clicks .terminal file; macOS imports color scheme into Terminal
• Terminal.app → Terminal session — Applied theme colors render ANSI text output in terminal window

Add a New macOS Terminal Theme

1. Obtain or create an iTerm2 .itermcolors file with your desired color scheme ((external source))
2. Run the conversion tool with the iTerm2 file as input (tools/iterm2termina)
3. Move the generated .terminal file into the themes directory (themes/)
4. Create a screenshot by importing the theme and capturing the terminal (screenshots/)
5. Update README.md to reference the new theme in the theme list (README.md)

Contribute a New Theme from iTerm2 Color Schemes

1. Download or reference a theme from @mbadolato's iTerm2-Color-Schemes repository ((external))
2. Use the conversion tool to transform it to macOS Terminal format (tools/iterm2termina)
3. Place converted theme in themes directory with descriptive filename (themes/)
4. Generate and commit a preview screenshot (screenshots/)

• macOS .terminal files (XML-based plist format) — Native macOS Terminal.app format; no additional software required for end users
• iTerm2 .itermcolors (XML) as source format — Large existing ecosystem of color schemes; allows leveraging community work from @mbadolato's collection
• Shell script (iterm2termina conversion tool) — Lightweight, no dependencies; easy to run and modify for one-off format conversions

• Store pre-converted .terminal files rather than auto-converting on installation

  • Why: Provides instant, zero-dependency installation for end users; no runtime conversion overhead
  • Consequence: Repository is larger; requires manual regeneration when source iTerm2 themes update

• Manual screenshot generation rather than automated rendering

  • Why: Ensures human-curated, visually consistent preview images; captures real Terminal.app rendering
  • Consequence: Adding themes requires manual screenshot creation; harder to scale

• Simple directory structure (themes/ + screenshots/) without nested organization

  • Why: Easy to browse; intuitive for users copying .terminal files directly
  • Consequence: 346 files in flat structure; limited categorization (though filenames indicate theme families)

• Does not provide a GUI theme selector or installer—relies on macOS Finder double-click interaction
• Does not auto-update or sync with iTerm2 color scheme upstream sources
• Does not handle terminal behavior settings (only color schemes); font, window size, bell behavior are user-configured separately
• Does not support non-macOS platforms (iTerm2-specific to macOS Terminal.app)

• Avg cyclomatic complexity: ~1.2 — Repository is primarily a curated collection of static configuration files with minimal scripting; conversion tool is straightforward shell-based transformation
• Largest file: Unknown (likely a screenshot PNG or .terminal plist) (150 lines)
• Estimated quality issues: ~2 — No automated validation of .terminal files; conversion tool lacks error handling and documentation; no tests or CI checks

• Lack of metadata/manifest for themes (Medium) — themes/ directory: No centralized index (JSON, YAML, etc.) cataloging theme properties, author, source, or tags; relies entirely on filename convention and README hardcoding
• Manual screenshot maintenance (Low) — screenshots/ directory: Screenshots generated manually; no documented process or automation; prone to inconsistency (resolution, font, content) and staleness
• No theme validation or linting (Medium) — tools/: No automated checks that .terminal files are well-formed plist, have required color keys, or match color range specifications

• iterm2termina conversion tool (Process/tooling bottleneck) — Single shell script with no modular design or error handling; difficult to extend for new source formats or debug conversion issues
• Theme addition workflow (Manual overhead) — Converting a single iTerm2 theme requires running tool, moving file, generating screenshot, and updating README manually; no CI/CD automation
• Repository size growth (Scalability) — 346 files with 100+ PNG screenshots; flat directory structure may become unwieldy as more themes accumulate

1. Color format mismatch: iTerm2 uses RGB hex (#RRGGBB), macOS Terminal uses NSColor plist format (requires XML-safe encoding); iterm2terminal.swift handles this but misconfigurations produce unprintable themes. 2. macOS version sensitivity: .terminal plist schema varies by macOS version (Catalina vs. Ventura have different key names for transparency/background blur)—older themes may not work on newer systems. 3. Preview font dependency: tools/preview.sh ANSI output quality depends on terminal font having proper glyph coverage; system font fallback can make color blocks look misaligned. 4. No dry-run mode: opening a .terminal file immediately modifies Terminal.app settings; no preview-only workflow besides manually running preview.sh.

• mbadolato/iTerm2-Color-Schemes — The original upstream collection of 200+ iTerm2 themes that this repo ports from—essential reference for color palette sources and format specifications
• chriskempson/base16 — Universal color scheme format with 8-bit ANSI palette standard; many themes in this repo originated from base16 community designs
• sindresorhus/iterm2-snazzy — Popular single iTerm2 theme repo demonstrating how individual high-quality themes are structured and documented—template for theme maintainers
• denysdovhan/spaceship-prompt — Zsh prompt framework that integrates with Terminal.app themes to showcase color compatibility—common downstream consumer of these color schemes
• Homebrew/homebrew-cask — Could distribute .terminal files as Homebrew casks for one-command installation (currently manual double-click workflow)

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 a theme validation script to verify all .terminal files are properly formatted

With 100+ theme files in the themes/ directory, there's no automated way to ensure all .terminal files have valid XML structure, complete color definitions, or consistent formatting. A validation script would catch issues before they're merged and reduce maintenance burden for reviewing theme PRs.

• [ ] Create a new script file (e.g., scripts/validate-themes.sh or scripts/validate-themes.py) that parses each .terminal file in the themes/ directory
• [ ] Validate that each file contains required Terminal.app color keys (ANSI colors 0-15, foreground, background, cursor)
• [ ] Validate proper XML structure and required metadata fields
• [ ] Add this script to a GitHub Actions workflow that runs on PRs modifying themes/
• [ ] Document in README.md how to run validation locally before submitting theme PRs

Add a screenshot generation/verification system for new theme submissions

Currently, screenshots/ directory has 100+ PNG files that appear to be manually created. New theme contributions require manual screenshot creation, which is error-prone and creates inconsistent preview quality. An automated screenshot generation system would standardize quality and reduce friction for contributors adding new themes.

• [ ] Create a script (e.g., scripts/generate-screenshots.sh) that uses a headless Terminal.app automation or similar tool to capture consistent screenshots of each theme
• [ ] Ensure consistent window size, font, and test content across all theme screenshots
• [ ] Automate screenshot generation in CI so that theme PRs automatically generate preview images
• [ ] Document the process in CONTRIBUTING.md for contributors adding new themes

Create a CONTRIBUTING.md guide with specific theme submission checklist and format requirements

The README.md is incomplete (cuts off mid-sentence at 'Shell -> Use Settings as') and lacks contribution guidelines. New contributors submitting themes have no clear requirements for .terminal file structure, naming conventions, or what must accompany a PR (does it need a screenshot? specific metadata?). This creates inconsistency and extra maintainer review work.

• [ ] Complete the Installation Instructions section in README.md that is currently cut off
• [ ] Create CONTRIBUTING.md with: theme naming conventions, required .terminal file structure/metadata, screenshot requirements, and how to test themes locally
• [ ] Add a checklist section in CONTRIBUTING.md for theme contributors (e.g., 'Verified theme loads without errors', 'Screenshot included', 'Passed validation script')
• [ ] Reference the validation script and screenshot generation process (from other PRs above) in the contribution guidelines

• Screenshot standardization: Audit all 50+ PNG screenshots in screenshots/ for consistent resolution, font size, and ANSI test pattern—many may use older preview.sh output format. Propose standardized screenshot generation script with dimensions and tool versions documented.
• Automated plist validation: Write a Swift or Shell script in tools/ to validate all .terminal files against macOS plist schema (check for required keys: name, AnsiColors, BackgroundColor, etc.) and report missing or malformed themes before publication.
• Theme metadata index: Generate a JSON or YAML registry in repo root listing all themes with metadata (palette type: dark/light, primary color, source origin: iTerm2/custom) to enable programmatic theme discovery and filtering—currently only README.md has theme names.

This repository is a collection of color theme files for macOS Terminal.app with minimal security risks. The codebase consists primarily of configuration files (*.terminal) and documentation with no executable code, dependencies, or infrastructure components. No secrets, injection vulnerabilities, or misconfigurations were detected. The project follows a simple distribution model where users clone/download themes and apply them locally. The high security score reflects the low attack surface of a theme-only repository.

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.