{"owner":"JanDeDobbeleer","repo":"oh-my-posh","hasSkills":true,"totalSkillsCount":35,"totalTokensCount":18368,"categories":["subagent-persona","anthropic-skill","copilot-instructions","root-instruction","plugin-manifest"],"hasMcp":false,"mcpConfig":null,"found":[".agents/agents/code-reviewer.agent.md",".agents/agents/issue-analyzer.agent.md",".agents/agents/pr-reviewer.agent.md",".agents/skills/code-changes/SKILL.md",".agents/skills/conventional-commit/SKILL.md",".agents/skills/golang/SKILL.md",".agents/skills/project-knowledge/SKILL.md",".agents/skills/project-knowledge/references/bash.md",".agents/skills/project-knowledge/references/cmd-clink.md",".agents/skills/project-knowledge/references/codebase.md",".agents/skills/project-knowledge/references/fish.md",".agents/skills/project-knowledge/references/pwsh.md",".agents/skills/project-knowledge/references/release.md",".agents/skills/project-knowledge/references/testing.md",".agents/skills/project-knowledge/references/zsh.md",".agents/skills/segment-create/SKILL.md",".agents/skills/segment-docs/SKILL.md",".github/copilot-instructions.md","AGENTS.md","packages/msix/README.md","website/static/skill.md","website/static/skills/ohmyposh/SKILL.md","website/static/skills/ohmyposh/configuration.md","website/static/skills/ohmyposh/installation/linux.md","website/static/skills/ohmyposh/installation/macos.md","website/static/skills/ohmyposh/installation/windows.md","website/static/skills/ohmyposh/shell/bash.md","website/static/skills/ohmyposh/shell/cmd.md","website/static/skills/ohmyposh/shell/elvish.md","website/static/skills/ohmyposh/shell/fish.md","website/static/skills/ohmyposh/shell/nu.md","website/static/skills/ohmyposh/shell/powershell.md","website/static/skills/ohmyposh/shell/xonsh.md","website/static/skills/ohmyposh/shell/yash.md","website/static/skills/ohmyposh/shell/zsh.md"],"skills":{".agents/agents/code-reviewer.agent.md":"---\nname: code-reviewer\ndescription: >\n Reviews a diff, a set of files, or an inline snippet for alignment with the repository's\n language skills, clean-code rules, and architecture principles, returning findings only.\n Orchestrating agents such as pr-reviewer and issue-analyzer invoke it through the agent tool; a\n user can also say \"check this against our conventions\", \"review these files for clean code\", or\n \"does this snippet follow the Go skill\".\ntools: [\"read\", \"search\", \"execute\"]\n---\n\nYou are a senior contributor to this project performing a focused code review. Your job is to judge\nwhether a diff, a set of files, or an inline snippet aligns with this repository's embedded skills\nand architecture principles. You do not judge correctness, test coverage, documentation\ncompleteness, or commit messages - the caller that invoked you owns those. You never edit, commit,\nor push; every result of this review goes into your response.\n\n## Input you expect\n\nThe caller passes, in its request:\n\n- What to review: a git ref range (`main...HEAD`, `FETCH_HEAD`), a pull request number, a list of\n file paths, or an inline snippet or proposal in fenced code blocks.\n- One sentence of intent: what the change is trying to do.\n- An optional focus list: dimensions to weight, such as \"Go concurrency\" or \"PowerShell error\n handling\".\n\nWhen the request lacks the artifact or the intent, ask for the missing part in one line and stop.\n\nMaterialise each input read-only, and nothing else:\n\n- Ref range: `git diff `.\n- Pull request number: `gh pr diff ` plus `git fetch origin pull//head` and\n `git show FETCH_HEAD:` for files you need beyond the diff.\n- File paths: read them directly.\n- Snippet: read the surrounding code in the repository location it would land in, so you judge it\n in context rather than in isolation.\n\n## Loading the rubric\n\nLoad these before reading the code, matched to the file types involved:\n\n- The AGENTS.md non-negotiables, always.\n- `golang` skill for every `.go` file.\n- The AGENTS.md \"Docs\" rules for every `.md`/`.mdx` file; add `segment-docs` when the file sits\n under `website/docs/segments/`.\n- The matching `project-knowledge` topic file for the touched area, when one exists.\n\nSearch for call sites and similar existing implementations, so you can judge consistency with the\nrest of the codebase instead of reviewing the change in isolation.\n\n## What you check\n\n### Skill alignment\n\nGo: `else` after a return, deep nesting, uppercase error strings, an OS or shell call\nmade outside the `Environment` abstraction, new cache logic instead of reusing `src/cache/`, and the\ngolang skill's test structure rules (table-driven tests, behavior over patch-shape assertions).\nMarkdown: heading levels (no H1, no skipped levels), fenced code blocks with a language tag,\n120-character lines, and required frontmatter.\n\n### Clean code\n\nIntention-revealing names, small single-purpose functions, guard clauses instead of nested\nconditionals, no dead code, no duplication, and comments that explain only the WHY per the\nAGENTS.md rule. That rule applies to every language in the repository, not only a file's primary\nlanguage.\n\n### Architecture and SOLID\n\nSingle responsibility, extension through existing\nabstractions rather than modification of unrelated code, interfaces honoured as contracts, narrow\ninterfaces over fat ones, dependency on `Environment` rather than concrete OS calls, the Law of\nDemeter, primitive obsession, Object Calisthenics, and hot-path cost in I/O and allocations per\nrender.\n\n### Consistency\n\nConfirm the change follows the pattern of the nearest existing implementation, and name the file\nyou compared against. A new segment option that skips a validation step every other option\nperforms, or a new CLI command that skips the registration pattern every other command follows, is\na finding even when the code works.\n\n## What you do not check\n\nState these explicitly in your response, so the caller keeps ownership of them:\n\n- Correctness of logic - whether the change does what it claims.\n- Test coverage - whether tests exist or are adequate.\n- Documentation and registration completeness - whether docs, schema, or sidebar entries ship with\n the change.\n- Commit messages.\n- Anything outside the artifact you were given.\n\n## Output format\n\nStructure your response exactly as follows, so the caller can merge it mechanically:\n\n- **Findings**: one bullet per finding, in the form `path:line, severity, problem, rule source,\n fix`. Severity is one of `blocking`, `should fix`, `minor`. Rule source names the skill and\n section, or the checklist item. Order by severity. For an inline snippet, use `snippet:line`\n instead of a file path. When you find nothing, this section contains exactly `No findings.`\n- **Compared against**: the existing files you used as the consistency baseline.\n- **Not assessed**: what you could not judge and why - a snippet with no surrounding code, a file\n type with no matching skill, a dimension the caller excluded from its focus list.\n\nDo not add a verdict, praise, a summary of the change, or a style nit that a formatter or linter\nalready enforces, unless it also violates a skill rule.\n\n## Hard constraints\n\n- Read-only: never edit a file, commit, push, check out a branch, or write to GitHub.\n- Verify every finding by reading the code yourself; never infer one from a description or from a\n bot comment you have not checked.\n- Cite the rule for every finding, or drop the finding.\n- All output goes in your response, nowhere else.\n",".agents/agents/issue-analyzer.agent.md":"---\nname: issue-analyzer\ndescription: >\n Investigates a GitHub issue and reports the analysis in the conversation only. Reads the issue,\n reproduces the reported behavior when possible, and traces the root cause in the code. Never\n posts to the issue, edits it, or changes labels. Use when someone says \"analyze issue #N\",\n \"investigate this issue\", \"look into #N\", \"triage #N\", or \"research issue\", or asks for a\n deep-dive on a bug report or feature request. Always invoke this agent rather than doing the\n analysis inline.\ntools: [\"read\", \"search\", \"execute\", \"agent\"]\n---\n\nYou are a senior contributor to this project. Your job is to investigate a GitHub issue and report\na structured analysis in your response to the conversation. You never touch the issue itself, and\nyou never edit a repository file; your output is the analysis, not a change.\n\n## Hard constraints\n\n- Never run `gh issue comment`, `gh issue edit`, `gh issue close`, or any command that changes\n labels, assignees, or state.\n- `gh` and `git` are read-only here: view, list, log, blame, diff, show. No write, no push, no\n branch creation.\n- The full analysis goes in the conversation response and nowhere else. Do not draft a comment\n file, open a pull request, or stage a change.\n- Edit no repository file. A proposed fix belongs in the response as a snippet, not in a\n working-tree edit.\n- Do not guess about behavior you cannot verify from the code. If something is ambiguous, say so\n in the open questions.\n- `code-reviewer` is the only agent you invoke, and only on the proposal, never on the issue\n itself.\n\n## Workflow\n\n### Step 1: Precondition checks\n\nBefore doing anything else, confirm both of these and stop with a clear message if either fails:\n\n- `git rev-parse --is-inside-work-tree` confirms you are inside the oh-my-posh repository.\n- `gh auth status` confirms the GitHub CLI can read issues and comments.\n\n### Step 2: Fetch the issue\n\n```shell\ngh issue view {number} --json number,title,body,labels,comments,author,createdAt,state\n```\n\nFollow every linked issue, pull request, and discussion mentioned in the body or comments with the\nsame command (or `gh pr view` for a pull request), so the analysis accounts for prior context.\nRead the title, body, and comments carefully. Pay attention to:\n\n- What the reporter says is happening, versus what they expect instead.\n- Their platform: OS, shell, terminal, and tool version, if mentioned.\n- Any config fragments or theme snippets they pasted.\n- Labels already applied, which hint at the affected area.\n\n### Step 3: Identify the affected codebase area\n\nUse the table below as a starting point for which area of the codebase is likely involved:\n\n| Issue topic | Where to look |\n| -------------------- | -------------------------------------------------------- |\n| A specific segment | `src/segments/.go` + `src/segments/_test.go` |\n| Shell integration | `src/shell/` and `src/shell/scripts/` |\n| Rendering / styling | `src/prompt/engine.go`, `src/color/` |\n| Theme / config | `src/config/`, `themes/` |\n| CLI command | `src/cli/` |\n| Caching | `src/cache/` |\n| Templates | `src/template/` |\n\nSearch for the symbols, function names, struct definitions, and call sites mentioned in the\nissue, instead of reading whole directories to find them. Trace the data flow and pin down the\nexact files and line numbers before opening anything for detailed reading.\n\nBefore investigating an area with known history (shell integration, terminal or pty behavior, WSL\ntest harnesses, caching, segments, streaming, the serve daemon), read the matching topic file from\nthe `project-knowledge` skill. It records verified gotchas so you do not repeat a known dead end.\n\n### Step 4: Investigate like the code-changes triage path\n\nFollow step 1 of the `code-changes` skill for the deep investigation:\n\n1. Reproduce the reported behavior. When reproduction needs an environment you lack (OS, shell,\n font, hardware), say so and reason from the code instead, flagged as such.\n2. Locate the root cause in the code, not in the issue text. Reports frequently describe symptoms\n and guess wrong about causes.\n3. Assess blast radius: who else is affected, and since which release or commit, using `git log`\n and `git blame` on the affected file to find the change that introduced the defect.\n\n### Step 5: Synthesize findings\n\nCombine the fetched context, the codebase reading, and the triage steps into the report described\nin \"Report format\" below. Be specific: cite actual file paths and line numbers. A finding like\n\"this could be related to X\" is not useful and does not belong in the report.\n\n## Design the proposal, then have it reviewed\n\nWhenever the analysis proposes a change, sketches an architecture, or includes a code snippet,\nprepare it like a change that will actually be reviewed, even though you will never submit it:\n\n1. Load the rules for every file type the proposal touches: the `golang` skill for `.go` files,\n the AGENTS.md \"Docs\" rules for `.md`/`.mdx` files, and both `segment-create` and\n `segment-docs` when the proposal involves a new segment.\n2. When the proposal contains a code snippet or a structural design (a new type, a new\n abstraction, a new package, or a cross-module change), invoke `code-reviewer` through the\n `agent` tool with the proposal text verbatim in fenced code blocks, the target file paths, and\n one sentence of intent. Fold its findings into the proposal before reporting: revise the\n snippet, or list the finding under open questions with your reason when you disagree. Skip the\n invocation for a trivial fix (a one-line change, a constant, a typo) and say so in the report.\n\nAny Go snippet must conform to the golang skill: no `else`, early returns instead, lowercase error strings,\nthe `Environment` abstraction for every OS or shell call, and `src/cache/` reused rather than a\nnew cache package. Every language follows the AGENTS.md comment rule: comment only the WHY, never\nrestate what the code already shows. State in the proposal which skill or checklist rule shaped\neach notable decision, so the maintainer sees the reasoning, not just the result.\n\n## Report format\n\nStructure the response in this order:\n\n1. One-sentence headline naming the finding.\n2. **Reproduction status**: confirmed, could not reproduce (with evidence), or not reproducible in\n this environment (with the specific reason).\n3. **Root cause**, with `file:line` references.\n4. **Affected files and functions**, as a concrete list, not a general area.\n5. **Proposed change**: scope, code snippets that follow the language skills above, the tests to\n add in the existing `_test.go` file, and the docs to touch. Note whether `code-reviewer`\n reviewed the snippet, or that the review was skipped and why.\n6. **Out of scope**: what the change deliberately leaves alone.\n7. **Effort**: small, medium, or large.\n8. **Open questions**: anything still ambiguous.\n9. **Suggested reply to the reporter**: draft text the maintainer can paste as-is, written for the\n reporter rather than a fellow contributor. Skip internal file paths unless the reporter would\n find them useful.\n",".agents/agents/pr-reviewer.agent.md":"---\nname: pr-reviewer\ndescription: >\n Reviews an existing pull request for correctness and for alignment with the\n repository's embedded skills and architecture principles. Reports findings\n in the conversation only; never posts reviews or comments. Use when someone\n says \"review PR #N\", \"review this pull request\", \"check #N against our\n conventions\", \"does PR #N follow the Go skill\", or \"code review for #N\". Always\n invoke this agent rather than reviewing inline.\ntools: [\"read\", \"search\", \"execute\", \"agent\"]\n---\n\nYou are a senior contributor to this project performing a pull request review. Your job is to\nverify a pull request against the repository's own conventions and report what you find. You never\nchange the pull request or the repository; every result of this review goes into your response.\n\n## Preconditions\n\nBefore doing anything else, confirm the environment:\n\n- `git rev-parse --is-inside-work-tree` - stop and tell the user what is missing if this fails.\n- `gh auth status` - stop and tell the user what is missing if this fails.\n\n## Fetching the pull request\n\nEverything here is read-only.\n\n- `gh pr view {number} --json number,title,body,baseRefName,headRefName,commits,files,labels,reviews,comments`\n- `gh pr diff {number}`\n\nTo read changed files at the PR head: run `gh pr checkout {number}` when the working tree is\nclean, otherwise leave the working tree alone and run `git fetch origin pull/{number}/head` plus\n`git show FETCH_HEAD:{path}` for each file you need. Checking out the branch is the only change\nyou make to the working tree.\n\nExisting review comments, bot or human, are leads, not verdicts. Verify each one against the code\nbefore repeating it as your own finding.\n\n## Loading the rubric\n\nLoad these before reading the diff:\n\n- `conventional-commit` skill against every commit message in the PR.\n- The matching `project-knowledge` topic file for the touched area (shell scripts, cache,\n segments, terminal).\n\nSearch for call sites and similar existing implementations so you can judge whether the change is\nconsistent with the rest of the codebase.\n\nConvention and architecture review is delegated to `code-reviewer`. Its rubric (skill alignment,\nclean code, architecture, SOLID) lives with that agent, not in this profile.\n\n## Review dimensions\n\nCheck each dimension below and record concrete evidence, not impressions.\n\n### Correctness\n\nRead the code path itself, not the PR description, and confirm:\n\n- Logic does what the diff claims.\n- Error handling covers the failure modes the change introduces.\n- Nil and zero-value handling is correct.\n- Concurrency is safe: no new data races or missing synchronization.\n- Platform differences (Windows/Unix) are handled where the change touches OS or shell behavior.\n- No regression in behavior the PR does not intend to change.\n\n### Conventions and architecture (delegated)\n\nInvoke `code-reviewer` through the `agent` tool with the pull request number (or the `FETCH_HEAD`\nrange), the PR's intent in one sentence taken from the title and body, and the touched areas as\nfocus. Wait for its findings. Verify any `blocking` finding against the code yourself before\npromoting it into the report. Merge the rest as returned, keeping their rule sources.\n\n### Tests\n\nConfirm the change is covered by behavior tests in the sibling `_test.go` file. Flag tests that\nassert implementation details or duplicate declared data instead of behavior. Flag missing tests\nfor new branches the diff introduces.\n\n### Documentation and registration\n\nConfirm user-visible changes ship docs in the same PR. A new segment needs every item in the\n`segment-create` skill's checklist. Confirm `themes/schema.json` is updated for config changes.\n\n### Commits\n\nCheck conventional commit type and scope, one logical unit per commit, and that `BREAKING CHANGE`\nappears only for user-facing config behavior.\n\n## Verification you run yourself\n\nRun what is feasible given the changed files and quote the decisive output line for any failure:\n\n- From `src/`: `go build ./...`, `go test .//...`,\n `golangci-lint run .//...`.\n- `npx markdownlint-cli2 ` for each changed Markdown file.\n\n## Scope\n\nReview only what the pull request introduces. A pre-existing problem on an untouched line is out\nof scope; add a one-line note only when the PR makes that problem worse.\n\n## Report format\n\nStructure your response exactly as follows:\n\n- **Verdict**: one line, either \"ready to merge\" or \"changes needed\", with the count of blocking\n findings.\n- **Findings**: ordered by severity (blocking, should fix, minor). One bullet per finding, in the\n form `path:line, severity, problem, rule source (skill and section, or checklist item), fix`.\n Merge in the findings `code-reviewer` returned, per \"Conventions and architecture\" above.\n- **Verified**: the commands you ran and their result.\n- **Existing review threads**: which ones you confirmed valid or invalid, and why.\n- **Out of scope**: pre-existing issues you noticed but did not evaluate.\n- **Not assessed**: whatever `code-reviewer` reported under its own `## Not assessed`, so gaps in\n the delegated review stay visible.\n\nDo not include praise, a summary of what the PR does beyond one sentence, or style nits that a\nformatter or linter already enforces, unless they also violate a skill rule.\n\n## Hard constraints\n\n- Never run `gh pr review`, `gh pr comment`, `gh pr edit`, `gh pr merge`, or any other command that\n writes to GitHub. `gh` and `git` are read-only here, apart from fetching and checking out the\n branch.\n- Never resolve review threads.\n- Never commit, push, or edit any file in the repository.\n- All output goes in your conversation response, nowhere else.\n- Do not guess. When the code is ambiguous, say what evidence is missing.\n- Do not restate a bot reviewer's comment as your own finding without verifying it against the\n code first.\n- `code-reviewer` is the only agent you invoke, and only once per review, unless it asked for\n missing input.\n",".agents/skills/code-changes/SKILL.md":"---\nname: code-changes\ndescription: >\n Workflow for any task that ends in code changes: issue analysis or triage, pull request review comments, features,\n bug fixes, refactors. Invoke at the start of such a task, before reading or writing code.\n---\n\n# Code changes\n\n## 1. Analyze, then stop\n\n- Read the code, not only the issue, review comment, or stack trace: reports and bot reviewers are often wrong. Fetch\n context with `gh issue view --comments` or `gh pr view --comments`.\n- Reproduce the problem when possible; say so when you cannot.\n- Look for what already exists before designing anything: a helper, a similar module, a pattern another feature uses,\n a CLI to call instead of reimplementing it. Prefer the smallest change that reuses existing code, and the change that\n removes code over the one that adds it. Deprecated logic gets removed, not maintained.\n- Report the root cause with file references, the proposed change and its scope, what stays out of scope, and open\n questions.\n- **Stop and wait for a go.** Skip the stop only when the request already asks for the implementation (\"fix it\",\n \"do it\"). A go for analysis is not a go for implementation, and a new diagnosis after a failed verification needs a\n new go.\n\nFor triage only (\"look at #n\"), the report is the deliverable: add the blast radius and a suggested reply to the issue.\n\n## 2. Plan\n\n- Load the language and format skills for every file you will touch before writing any code, and follow them from the\n first line. A rule read at review time turns a violation into rework.\n- When replacing working code, list what the old code does (defaults, key bindings, error messages) and keep all of it.\n Dropping any of it needs a go first.\n- For a judgment call you cannot make with confidence (unclear root cause, security, irreversible change), ask the\n strongest available model that one question, then continue.\n\n## 3. Implement\n\n- Do standard work yourself. Delegate only independent tasks that can run in parallel (one worktree each) or\n mechanical batches for a cheaper model.\n- A delegation carries the decided approach, the files, the binding skill rules, the verification commands, the\n non-goals, and the instruction to stop and report anything the spec does not cover.\n- Never delegate analysis, final verification, commits, or pushes.\n\n## 4. Review the diff\n\nReview every diff as an external pull request, your own included:\n\n- Everything asked for, nothing more. Replace overbuilt solutions with simpler ones.\n- Consistency with the surrounding code beats a new pattern.\n- Cut tests that assert implementation details, copy data declared elsewhere in the diff, duplicate another test, or\n would still pass with the bug present.\n- Delete comments that restate the code.\n\n## 5. Verify\n\n- Build, tests, formatters, and linters pass with zero findings. Never weaken a gate or delete a test to get there.\n- Prove it works: run the real flow the way the user reaches it (the built binary, a cold start) and record the actual\n output.\n- Update documentation in the same change as the behavior it describes.\n- After two failed verification rounds on the same task, stop and report instead of trying a third time.\n\n## 6. Deliver\n\n- Commit only when the user asks for it. Push or open a pull request only when asked; push a rewritten branch with\n `--force-with-lease`.\n- Write messages with the `conventional-commit` skill. One logical change per commit; stage files explicitly.\n- Fold a fix to a commit that is not on the default branch into that commit: `git commit --fixup `, then\n `git rebase --autosquash`. That includes lint, test, and CI fallout. Never stack \"fix\" commits on top.\n- Report the outcome first: what changed and why, the verification evidence, what is left for the user, and anything\n removed.\n\n## Pull request review comments\n\n1. Fetch every unresolved thread and validate each against the code. Treat bot comments as leads, not verdicts.\n2. Valid: fix it as a fixup into the commit that introduced the code, autosquash, verify, and force-push the pull\n request branch.\n3. Invalid: do not change code to appease it. Reply with the evidence. When the misreading exposes confusing code,\n clarify the code and say so.\n4. Reply to every thread with the conclusion and the commit that addresses it, then resolve the thread.\n",".agents/skills/conventional-commit/SKILL.md":"---\nname: conventional-commit\ndescription: >\n Rules for writing Conventional Commits messages in this project. MUST be invoked every time a\n commit is created.\ntriggers:\n - on_commit\n---\n\n# Conventional commit\n\n`.commitlintrc.yml` is the source of truth: use only the types it allows. Beyond the\nspecification:\n\n- Keep the header (`type(scope): description`) at 72 characters or fewer.\n- Write the description in the imperative, without a trailing period: `add`, `fix`, `bump`. Never\n copy past tense from the request (`added`, `fixed`, `bumped`).\n- Use the affected area as the scope (`segment`, `cache`, `config`); omit it for cross-cutting\n changes.\n- A change that removes, renames, or alters behavior callers depend on carries both `!` after the\n type or scope and a `BREAKING CHANGE:` footer. Never one without the other.\n- Use the body for why, not what, wrapped at 72 characters.\n- Review `git diff --cached` and stage files explicitly; never `git add -A`.\n\n```text\nfeat(segment)!: rename template property StartTime to Start\n\nBREAKING CHANGE: template strings using .StartTime must be updated to .Start\n```\n",".agents/skills/golang/SKILL.md":"---\nname: golang\ndescription: >\n Go conventions for this project that differ from common Go practice. Apply when writing,\n reviewing, or refactoring any Go source or test file.\ntriggers:\n - on_commit\n---\n\n# Go conventions\n\nStandard idiomatic Go applies. These are the rules that differ or that agents keep breaking.\n\n## Code\n\n- Never use `else`, in tests too. Return early, `continue`, `break`, or use a `switch`.\n- Comments explain a why the code cannot express: a hidden constraint, a workaround, a surprising\n invariant. No doc comments that restate a name or signature, exported symbols included.\n- Use named fields in every struct literal, never positional ones: fixing fieldalignment findings\n reorders struct fields.\n- Keep lines under 180 characters (`lll`).\n- When a standard library package collides with an existing import, alias it `lib`, for\n example `libtime`.\n- Start error strings lowercase, without trailing punctuation.\n- Ask before adding a dependency.\n\n## Tests\n\n- Assert with `testify` (`assert`, `require`).\n- Write table-driven tests: one behavior is one test function with a table. Per-case fixtures,\n mock returns, and expected errors are table fields, not reasons for a new function. Extend an\n existing table instead of adding a function. Split when the API under test or the setup and\n assertion flow differs, and for no other reason.\n- Test behavior, not the patch. Name the behavior a test proves, then ask:\n 1. Could the original bug still occur while this test passes?\n 2. Could a correct refactor make it fail?\n\n If either answer is yes, redesign or drop the test. Never assert on source text, embedded\n scripts, or statement order; assert on text when the emitted text is itself the contract\n (generated shell code, escaping, serialization). When the behavior cannot be exercised, say so\n instead of adding a proxy test.\n- A test that mutates package-level state saves the original value and restores it with\n `t.Cleanup`, never a hardcoded value.\n\n## Before committing\n\nRun from the module root and fix every finding:\n\n```bash\nmodernize -fix ./...\nfieldalignment ./...\ngolangci-lint run\n```\n\n- Never run `fieldalignment -fix`: it drops the comments of the fields it reorders. Reorder by\n hand.\n- Commit the `modernize` rewrites with the change that triggered them.\n- After touching a `_windows.go`, `_unix.go`, `_darwin.go`, `_linux.go`, or `//go:build` file,\n also run `go build ./...`, `golangci-lint run`, `modernize ./...`, and `fieldalignment ./...`\n with `GOOS` set to another platform. The host toolchain skips other platforms' files, so their\n errors otherwise surface in CI.\n- `dupl` on near-identical tests: merge them into one table. Reserve `//nolint:dupl`, with a reason,\n for tests that must stay separate. `goconst`: extract a string literal used three or more\n times into a constant.\n",".agents/skills/project-knowledge/SKILL.md":"---\nname: project-knowledge\ndescription: >\n Verified, actionable gotchas for oh-my-posh. Read the matching topic file BEFORE changing shell integration\n scripts (pwsh, zsh, bash, fish, cmd/Clink, nu, elvish, xonsh), terminal or pty behavior, WSL or e2e shell tests,\n Go internals (cache, segments, streaming, serve daemon, template rendering, output sanitization), or release, CI,\n build, and packaging workflows.\n---\n\n# Project Knowledge\n\nNon-obvious constraints, platform quirks, traps, and failed approaches. Read only the files the task touches; any\nshell-script edit also needs `testing`. Entries are point-in-time: verify against the code and fix drift.\n\n| Topic | Read when |\n| ------------------------------------ | ----------------------------------------------------------------------------- |\n| [codebase](references/codebase.md) | Go internals: templates, sanitization, segments, cache, streaming, serve |\n| [release](references/release.md) | `release.yml`, signing, packaging, CI gates, `-race`, rebasing on Windows |\n| [testing](references/testing.md) | Any shell-script edit; e2e/pty harnesses, WSL, ConPTY, Windows Terminal, nu |\n| [zsh](references/zsh.md) | `omp.zsh`, zle widgets, coproc, zsh-vi-mode |\n| [pwsh](references/pwsh.md) | `omp.ps1`, PSReadLine, runspaces, engine events, pwsh perf |\n| [fish](references/fish.md) | `omp.fish`, fish jobs, fifos, key bindings |\n| [bash](references/bash.md) | `omp.bash`, PROMPT_COMMAND, readline, ble.sh |\n| [cmd-clink](references/cmd-clink.md) | `omp.lua`, Clink, Windows pipe lifecycles |\n\n## Write-back\n\n- Append only verified entries that change what an agent does, phrased \"do X / don't do Y, because Z\", to the\n matching file (new file plus index row only when none fits). No narratives or history.\n- Update or delete a stale entry instead of stacking a correction. Date it only when staleness matters.\n- Commit knowledge updates with the change they relate to.\n",".agents/skills/project-knowledge/references/bash.md":"# bash\n\nVerified on bash 5.2 (2026-07).\n\n- Never run the `exec` builtin from PROMPT_COMMAND, not even `exec {fd}nul` in the command, or the child's stderr corrupts the display.\n- Windows has no SIGPIPE: stdin EOF is the daemon's only exit signal. Clink's pipes are `_O_NOINHERIT`, so cmd's\n death closes the daemon's stdin.\n- Test with `luac -p` plus a Lua harness that stubs the Clink API (`winget install DEVCOM.Lua`,\n `chrisant996.Clink`). Clink cannot run headless, so live smoke tests stay manual.\n",".agents/skills/project-knowledge/references/codebase.md":"# Codebase\n\n## Template markup trust boundary\n\n- Print-action output is chevron-escaped (`escapePrintActions`); only `template.Markup` values keep `<...>`\n anchors. Keep attacker-controlled data (VCS refs, API responses, folder names) in plain strings. `RawMarkup` is for\n user config only, `EscapeMarkup` for data, `JoinMarkup` for composition.\n- Segment fields built from option strings that carry anchors (icons, `branch_icon`, `folder_separator_icon`,\n `status_formats`) must be `template.Markup`, or the anchors render as literal text.\n- Keep `template.Markup` a named string, never a struct: text/template treats every struct as true (breaks\n `{{ if .BranchStatus }}` guards in shipped themes) and `eq` cannot compare it to a string.\n- Untrusted templates (`RenderUntrusted`, path segment) escape Markup results too. The path segment escapes folder\n names with `template.EscapeSource` on every branch of `replaceMappedLocations`; a new early return needs its own\n escape.\n- New func-map entries: output not derived from input (`readFile`, `cmd`, `b64dec`, `env`) goes in `noPromote`;\n attacker-chosen counts (`repeat`, `seq`, `until`, `rand*`) go in `dangerousFuncs` (trusted templates only). For a\n hot function, add a typed case to `markupAwareTyped` first.\n- Never bypass `formats.EscapeSequences` in `terminal.write`'s `isHyperlink` branch: bash `@P` re-interprets a\n backslash in the OSC 8 URI.\n- `src/prompt/golden_test.go` renders every shipped theme byte-exact. A golden diff after a markup change means a\n theme relied on the old, insecure behavior: inspect it, then `go test ./prompt/... -run TestGoldenThemes -update`.\n\n## Terminal output sanitization\n\n- `prompt.Engine.write` bypasses `terminal.write`'s per-rune control filter. Sanitize attacker-influenceable strings\n written in one shot (console title, OSC payloads) with `terminal.stripControlRunes`; `trimAnsi` misses ESC-less\n input (bare BEL) and CSI `! p`, APC, SOS, ST.\n- Don't extend `terminal.AnsiRegex`'s final-byte class (`!`, `_`, `X`, `\\` omitted on purpose) as a sanitization fix;\n strip control runes instead.\n\n## Segments and cache\n\n- Treat `mem.SwapMemory()` errors as returning a nil stat: gopsutil can fail reading `/proc/vmstat` on Android/Termux,\n so fall back to `VirtualMemoryStat.SwapTotal` and `SwapFree` instead of dereferencing the result.\n- Segment writers gob-encode only exported fields; `segments.Base.env/options` are unexported. On cache restore,\n overlay restored data onto the writer from `MapSegmentWithWriter`; never replace the writer.\n- `runtime/cmd.RunWithEnv` trims whitespace from the whole output, so a trailing empty field is lost. End records\n with a non-whitespace delimiter or sentinel and validate before assigning parsed state.\n- A blank prompt means a panic outside segment `Execute` and the streaming producer (both recover). A poisoned\n cache entry replays its failure every prompt until its TTL ends.\n- Caches persist only with the hidden `--save-cache` flag (print/stream); relocate with `OMP_CACHE_DIR`.\n- Logs are buffered and print only via `oh-my-posh debug` (grep `restored segment from cache`, `setting entry`);\n `POSH_TRACE=1` and stderr show nothing for print commands.\n- Windows: a fresh memory-mapped cache file logs a harmless `store.go:init EOF` on first read.\n\n## Streaming and serve daemon\n\n- `\"streaming\": ` also becomes every segment's pending timeout, overriding segment `timeout`.\n- `stream` emits the transient prompt as a `\\x1e`-prefixed NUL-terminated record (initial, and again once all\n segments resolve). Serve records are `\\x1f\\0`; a wait-mode request always yields exactly 2, even on\n segment panic (`renderComplete`), because Clink blocks on that count.\n- A timed-out segment keeps running after its cycle. On any path that can run then, publish through the\n `renderCache` captured at the top of `Execute`, never the global `template.Cache` (serve resets it per cycle,\n tests reassign it). `restoreCache`/`restoreData` still read the global (open race, 2026-09).\n- Don't gate `Execute`'s cache-hit early return on streaming: placeholders never show cached data, so skipping the\n cache only adds live probes that can time out.\n- Never touch `segment.writer` of a segment the cycle still has pending; pending segments render via\n `Segment.RenderPlaceholder` (config only). Don't add a `Pending` flag to `config.Segment`.\n- The event channel in `prompt/streaming.go` is sized `2*segments+1` so plain sends never block or drop; don't add\n `select`/`default`. The producer's `recover` must log a stack: a silent recover once hid a stuck-segment bug.\n- `prompt/streaming_writer_test.go`'s fake writer writes fields late on purpose, as race bait. `-race` only runs in\n CI ([release](release.md)).\n- Serve: process-lifetime initializers (`if X != nil return`) pin first-render state. Reset per render\n (`template.ResetCache()` in `startRenderCycle`); never nil a global that abandoned goroutines may still read.\n- Don't memoize the config in serve: the per-render gob decode gives each cycle its own segment graph, isolated from\n abandoned-cycle goroutines.\n- Daemon tests must vary per-request context (cwd, status) across cycles to catch one-shot state.\n- `config.Get` prefers the session gob cache over `POSH_THEME`.\n- Timing races: `oh-my-posh debug` timings are cold-process. Sweep the `streaming` value against a scripted serve\n session (JSON line + env blob on stdin) and count cycles whose last record still holds the placeholder.\n\n## Rendering and statusline\n\n- `template.Init` resets the parsed-template cache: calling it per benchmark iteration measures cold parse.\n- Stale website previews: a set `OMP_BIN` overrides the auto-rebuilt `src/bin` in `ensure-artifacts.mjs`.\n- Unix `terminal-dimensions` runs `stty size` on stdin, which is not a TTY under Claude Code's statusline. A valid\n `COLUMNS` fallback must clear the `stty` error, or `prompt.Engine.canWriteRightBlock` rejects right-aligned blocks.\n",".agents/skills/project-knowledge/references/fish.md":"# fish\n\nVerified on fish 4.1.2 (2026-07 to 2026-09).\n\n## Jobs, fifos, and lifecycle\n\n- fish does not fork a backgrounded function; it blocks the shell. Run readers as an external process:\n `fish --no-config -c $script args &`.\n- `jobs --last --pid` prints a \"Process\" header plus one pid per pipeline stage: filter with\n `string match --regex '^\\d+$'` and treat the result as a list.\n- Guard zero pids before `kill -0`: `kill -0 0` signals your own process group and always succeeds.\n- A fifo write with no reader blocks forever; liveness-check the reader before every write.\n- The serve daemon opens its request fifo O_RDWR, so it never sees EOF and a SIGKILLed fish orphans it. Teardown\n must go through the `fish_exit` handler.\n- `--on-signal SIGUSR1` handlers fire between commands in non-interactive scripts.\n- The streaming transient prompt lives in a tempfile (`$_omp_streaming_tempfile.transient`), not a variable,\n because `_omp_cleanup_stream` runs before the transient repaint.\n\n## Key bindings\n\n- `commandline --is-valid`: 0 valid, 1 erroneous, 2 incomplete. An empty buffer also returns 1, so check the buffer\n is non-empty before treating 1 as an error. A trailing backslash returns 0 (not a continuation).\n- A parse error from `commandline --function execute` inside a binding is attributed to the binding's file and\n function (#7862). Rethrow through a pristine parser instead:\n `commandline --current-buffer | string collect | $fish_bin --no-execute` (keeps the buffer and `$status`).\n- fish 4.x rejects command substitutions in command position (`(status fish-path) --no-execute`); assign to a\n variable (`set fish_bin (status fish-path)`) first.\n",".agents/skills/project-knowledge/references/pwsh.md":"# PowerShell (pwsh)\n\n## Engine events and runspaces (pwsh 7, 2026-07)\n\n- `Register-EngineEvent -Action` (e.g. `PowerShell.OnIdle`): `-MessageData` arrives as `$null`, and\n `.GetNewClosure()` captures are lost when the scriptblock is created in a module function. Pass state through a\n `$global:` variable (`$global:_ompStreamingState` in `omp.ps1`).\n- PSReadLine raises `PowerShell.OnIdle` every ~300-450ms, only while the input buffer is empty. Anything the user\n can trigger sooner (transient prompt on a fast Enter) must also drain synchronously at its call site.\n- PSEvents raised from a non-engine thread (e.g. `Register-ObjectEvent DataAdded` fed by a background runspace)\n can crash the host (`InvalidPipelineStateException`). Consume records only on the engine thread.\n- `Register-ObjectEvent` actions may or may not fire during a busy-wait. Never share a consume cursor between an\n event action and a synchronous waiter: give the waiter a private cursor and make the action idempotent.\n\n## PSReadLine prompt redraws (PSReadLine 2.4.5 / 2.3.6, 2026-09)\n\n- `InvokePrompt()` blanks `ExtraPromptLineCount + 1` rows before it calls the prompt function; a count set during\n that call only affects the next redraw. Padding the transient prompt cannot fix under-erasure.\n- `ExtraPromptLineCount` must count screen rows, including wrapping. The engine computes `terminal.CursorRow` and\n prefixes pwsh prompts with `ESC]7777;BEL`, which `Set-PoshExtraPromptLineCount` strips. Don't measure the\n prompt in PowerShell (`Measure-Object -Line` ignores wrapping and skips empty elements).\n- Overcounting is as bad: it erases the previous output line, or at the screen top `InvokePrompt` returns before\n calling the prompt (`newY < 0`), leaving `$script:TransientPrompt` set so the next primary renders as transient.\n Zero-width sequences such as the rprompt's `ESC 7`/`ESC 8` count 0 cells.\n- Match escape-prefixed strings with `-match '^\\u001b...'`, not `StartsWith`: culture-aware `StartsWith` ignores\n ESC, so `\"abc\".StartsWith(\"$([char]27)a\")` is `True`.\n- Redraw bugs only show when a line wraps; reproduce with the e2e `harness.MultiLine` overlay.\n\n## Exit lifecycle\n\n- pwsh cannot exit while a `[powershell]::Create()` pipeline thread runs (foreground threads). A reader blocked in\n `ReadByte()` on a child that exits only on stdin EOF deadlocks `exit` (#7643).\n- Module `OnRemove` never runs on a normal `exit`. Tear down a daemon in a `Register-EngineEvent PowerShell.Exiting`\n handler: write `quit`, close the child's stdin (the guaranteed EOF), kill after a short `WaitForExit`.\n\n## Performance (ARM64 Windows 11, 2026-07)\n\n- Process creation floor is ~70ms; any omp spawn costs ~100-130ms. For `omp.ps1` perf, count spawns per Enter\n first; cmdlet and module overhead is negligible.\n- `&` saves only ~10-17ms over the Process API and, under a CP437/1252 console, mangles UTF-8 output unless\n `[Console]::OutputEncoding = UTF8` is set once at init.\n- `Start-Sleep -Milliseconds 1` sleeps a ~15.6ms timer tick. Don't sleep-poll; signal a `ManualResetEventSlim`.\n\n## Testing\n\n- `New-Event -SourceIdentifier PowerShell.OnIdle` runs the real OnIdle action deterministically; its side effects can\n short-circuit later prompt calls.\n- Set module-scope flags from a test: `& (Get-Module oh-my-posh-core) { $script:X = $true }`.\n- Serve is gated to pwsh 6+ outside ConstrainedLanguage; pwsh 5.1 and ConstrainedLanguage keep the legacy path.\n- Exit-deadlock repro: `Start-Process pwsh -File test.ps1` + `WaitForExit(timeout)`; `findstr x` with redirected\n stdio stands in for a daemon.\n",".agents/skills/project-knowledge/references/release.md":"# Release, CI, and git\n\n## Release (`.github/workflows/release.yml`)\n\n- Releases are immutable: the workflow creates a draft and publishes last. Every asset must be in the draft before the\n publish step.\n\n## CI\n\n- `go test -race` does not work on the windows/arm64 dev machine or its WSL (no C compiler, no sudo). CI's\n `Race Detector` step (`code.yml`, ubuntu) is the only race gate.\n\n## Git on Windows\n\n- With `core.autocrlf=true`, `git rebase --autosquash` can stop on a plain `pick` with \"Your local changes would be\n overwritten\" and no real conflict (line-ending renormalization). Set `core.autocrlf false` for the rebase and\n restore it after; don't try to resolve a phantom conflict.\n",".agents/skills/project-knowledge/references/testing.md":"# Testing shells and terminals\n\n## Script edits\n\n- `src/shell/scripts/` is embedded at build time: rebuild the binary after every script edit, then inspect what\n users source with `oh-my-posh init --print`.\n- A script function is dead code unless `src/shell/.go` emits its activation line for the enabled feature.\n\n## e2e harness (`e2e/`, see `e2e/README.md`)\n\n- PSReadLine on a raw Unix pty floods `CSI 6n` and wedges without a reply (ConPTY answers it on Windows); the\n harness answers from the vt10x cursor (`harness/session.go`).\n- nu autoloads `$nu.vendor-autoload-dirs` after `--config`, so a real omp install clobbers the test prompt. Point\n `XDG_DATA_HOME` at an empty dir.\n- go-pty's Windows `Cmd` resolves bare names relative to `Cmd.Dir`; pass absolute binary paths.\n- On Windows, `bash` on PATH is System32's WSL launcher; `harness.LookupShellBinary` derives Git Bash from\n `git.exe`.\n\n## WSL\n\n- Run e2e from a Windows worktree: cross-compile (`GOOS=linux GOARCH=arm64 go build`), then in WSL\n `cd /mnt/c/.../e2e && OMP_E2E_BINARY=/mnt/c/.../oh-my-posh go test .`. If the distro's Go is too old for e2e's\n `go.mod`, unpack a go.dev tarball into `~/go-sdk`.\n- WSL `/tmp` is wiped between `wsl.exe` invocations: keep a test in one `wsl -e` call or stage under `$HOME`.\n- From Git Bash, prefix `MSYS_NO_PATHCONV=1` so `/mnt/c/...` arguments reach wsl.exe unmangled.\n\n## Getting a pty\n\n- `zsh -i` under plain `wsl -e` hangs (no foreground pty). Use `wsl -e script -qec 'zsh -i' /dev/null` for a real pty\n with job control, run backgrounded with output to a file, and poll a done-marker.\n- For keystrokes use `zmodload zsh/zpty`: `zpty omp zsh -i`, `zpty -w -n omp $'\\x03'` (real SIGINT), assert via\n state files, drain with `zpty -r`. `script(1)` does not work inside zpty.\n- `script(1)` quirks: bash prompt bytes are not relayed (probe `${PS1@P}` in-session); fish discards piped\n typeahead (assert via files written by event handlers); zsh works.\n- vi-mode probes must be mode-aware: after a normal-mode accept the next line starts in normal mode, so prefix `i`.\n A stray self-inserted `i` shows up as `last_status=127`.\n- To hold a render open, point an `http` segment with a large `http_timeout` at a silent local TCP listener; kill\n the listener to trigger the async update. There is no shell-command segment.\n\n## Protocol streams\n\n- One `bufio.Scanner` per pipe, ever; a second scanner loses buffered data.\n- Never treat wall-clock silence as \"records done\": cold-cache CI runs exceed any fixed gap. Wait for a record that\n proves the assertion (the cycle's transient record comes last) and keep a timeout only as a hang bound. Reproduce\n with `go clean -cache && go test -count=1 ./...`.\n\n## Windows Terminal and ConPTY\n\n- \"[process exited with code 0]\" at shell exit is Windows Terminal's own teardown message, never omp output.\n- Panes opened via `wt.exe ` never auto-close under `closeOnExit=automatic`; profile tabs do.\n- A headless conhost (Windows 11 build 26300) reports cursor 0,0, a blank buffer, and drops pty input: assert state,\n not row placement.\n- pywinpty's ConPTY EOF lags process death by ~5s (harness artifact, not a hang).\n- SendKeys into Windows Terminal drops keystrokes while the user works; a \"hung\" test may never have got `exit`.\n- `Set-Content -NoNewline` joins piped lines into one and corrupts scripts; write byte-exact files with Git Bash\n redirection.\n",".agents/skills/project-knowledge/references/zsh.md":"# zsh\n\n## zle\n\n- Every new editor invocation starts in keymap `main`; a `vicmd` selection does not carry into the next line.\n- `$?` after the transient prompt's `zle .send-break` is 1, native Ctrl+C gives 130 (TODO in `_omp_zle-line-init`).\n Don't fix one path without the other.\n- Ubuntu's `/etc/zsh/zshrc` defines a `zle-line-init`; never assume the widget slot is empty.\n- zsh-vi-mode always wraps omp's `zle-line-init` (it initializes lazily at first `precmd`), and our\n `.recursive-edit` swallows the session, so `_omp_zle-line-init` must call `zvm_zle-line-init` up front (guarded on\n `$+functions[zvm_zle-line-init]` and `ZVM_INIT_DONE`). Keep that call (#5992).\n- Keep `local rawfunc=` at the top of `_omp_zle-line-init`: `zvm_reset_prompt` resolves `$rawfunc` by dynamic\n scoping and would otherwise re-enter our widget.\n- Debug widget re-entry by logging `${funcstack[*]}` inside the widget.\n\n## Quoting\n\n- Quote every parameter expansion used as a command argument if its value can contain `[`, `?`, `*` or `#`. Under a\n user's `setopt GLOB_SUBST` it becomes a glob, and `BAD_PATTERN` aborts the widget (`$zle_bracketed_paste[1]` is\n `\\e[?2004h`, #7816).\n\n## coproc, fds, and signals\n\n- An interactive zsh with MONITOR prints `[n] pid` at coproc spawn; neither `disown` nor `2>/dev/null` stops it.\n `setopt localoptions no_monitor` does, and the child then inherits SIGINT/SIGQUIT ignored.\n- Duplicate coproc fds to session fds (`exec {out}<&p {in}>&p`) so they survive a later `coproc`; `disown %+` keeps\n the daemon out of `jobs` and the job-count segment.\n- A redirection-only `exec` applies every listed redirection permanently: `exec {fd}<&p 2>/dev/null` silences the\n session's stderr (#7653). Scope it: `{ exec ... } 2>/dev/null`.\n- Writing to a dead coproc raises SIGPIPE, which kills a non-interactive zsh. Guard writes with a `kill -0 $pid`\n check plus `setopt localoptions localtraps; trap '' PIPE`.\n- Never `kill -0` a possibly-zero pid: `kill -0 0` signals your own process group and always succeeds.\n- zsh 5.9 `read -r -u $fd -d $'\\0' -t N` ignores `-t` and blocks forever on a silent fd, so the serve path hangs\n in a non-interactive `zsh script.zsh`; test it in an interactive session.\n- Tear down in `zshexit_functions`; closing the fds (or the shell dying, even by SIGKILL) EOFs the daemon's stdin.\n",".agents/skills/segment-create/SKILL.md":"---\nname: segment-create\ndescription: >\n Checklist for adding a new Oh My Posh segment. Use when asked to add or create a new segment:\n lists every file to touch, the existing segment to copy, and how to verify.\n---\n\n## Template\n\nCopy `src/segments/taskwarrior.go` and `src/segments/taskwarrior_test.go`: two options, a\n`Template()`/`Enabled()` pair, and every shell call going through the mocked environment.\n\n- Embed `Base` first in the struct; its exported fields are the template properties.\n- Declare options as `options.Option` constants; read them with `s.options.String(...)`,\n `s.options.Bool(...)`, `s.options.KeyValueMap(...)` and so on, passing the default there.\n- Reach the OS, shell, files and network only through `s.env` so tests can mock it.\n- Override `Activation()` only for a cheap precondition such as a project file (see\n `src/segments/dvc.go`); `Base` defaults to always active.\n- Tests are table-driven: a `mock.Environment` from `src/runtime/mock`, options as an\n `options.Map`, then `Init(props, env)` and assertions on `Enabled()` and the exported fields.\n\n## Checklist\n\nKeep every list sorted alphabetically.\n\n1. `src/segments/.go` and `src/segments/_test.go`.\n1. `src/config/segment_types.go`: add the constant ` SegmentType = \"\"`.\n1. `src/config/segment_registry.go`: add `gob.Register(&segments.{})` to `init()` and\n `: func() SegmentWriter { return &segments.{} }` to `Segments`. A missing map\n entry fails silently at runtime: the segment never renders.\n1. `themes/schema.json`: add `` to `definitions.segment.properties.type.enum` and an\n `if`/`then` block to `definitions.segment.allOf` declaring every option. Copy the\n `taskwarrior` block; its `unevaluatedProperties: false` rejects undeclared options.\n1. `website/docs/segments//.mdx`, where category is one of agents, cli, cloud,\n health, languages, music, scm, system or web. Follow the `segment-docs` skill, and keep a\n `## What` paragraph: the segment catalog plugin reads it.\n1. `website/sidebars.js`: add `\"segments//\"` to that category's `items`.\n1. `website/segment_data.json`: add sample data under ``, shaped like the `taskwarrior` entry.\n1. `website/plugins/segments/registry.json`: generated. The first `go test ./config/...` run\n rewrites it and fails; rerun to confirm, then keep the file.\n1. Credentials needed? Add the doc id to `AUTH_TIERS` in `website/plugins/segments/data.js`.\n\n## Verify\n\nFrom `src/`:\n\n```shell\ngo test ./segments/... -run Test\ngo test ./config/...\n```\n\nRun `npm run build` in `website/` only when docs changed.\n",".agents/skills/segment-docs/SKILL.md":"---\nname: segment-docs\ndescription: >\n Reference mapping between Oh My Posh Go segment source code and MDX documentation.\n Use when creating, updating, or auditing segment documentation, or when reading\n segment Go code and needing to understand how code constructs map to user-facing\n options, template properties, and type representations in docs.\n---\n\n# Segment Documentation Reference\n\n## Go-to-Documentation Type Mapping\n\nWhen reading a segment's Go source to document its options, determine the type from the\n`Provider` method used to read the option value:\n\n| Go method call | Documentation type |\n| -------------- | :----------------: |\n| `options.Bool(option, default)` | `boolean` |\n| `options.String(option, default)` | `string` |\n| `options.StringArray(option, default)` | `[]string` |\n| `options.Int(option, default)` | `int` |\n| `options.Float64(option, default)` | `float64` |\n| `options.KeyValueMap(option, default)` | `map[string]string` |\n| `options.Color(option, default)` | `string` |\n| `options.Template(option, default, ctx)` | `string` |\n| `options.Any(option, default)` | `any` |\n\n## Extracting Options from Go Source\n\nOptions are declared as `options.Option` string constants in the segment's `const` block:\n\n```go\nconst (\n BranchIcon options.Option = \"branch_icon\" // option name used in config\n NativeStatus options.Option = \"native_status\"\n)\n```\n\nThe **option name** is the string literal value (e.g., `\"branch_icon\"`).\n\nThe **type** and **default value** come from the getter call in `Enabled()` or `init`-like methods:\n\n```go\ns.icon = s.options.String(BranchIcon, \"\\uE0A0\")\n// ^^^^^^ → string type, \"\\uE0A0\" → default\n```\n\n### Shared options\n\nThe following options are defined in `src/segments/options/map.go` and available to all\nsegments without appearing in a segment-specific `const` block:\n\n| Option name | Type | Default |\n| ----------- | ---- | ------- |\n| `always_enabled` | `boolean` | `false` |\n| `display_default` | `boolean` | `true` |\n| `display_error` | `boolean` | `true` |\n| `http_timeout` | `int` | `20` |\n| `cache_duration` | `int` | varies |\n| `access_token` | `string` | `\"\"` |\n| `refresh_token` | `string` | `\"\"` |\n| `version_url_template` | `string` | `\"\"` |\n| `files` | `[]string` | varies |\n\n## Extracting Template Properties from Go Source\n\nTemplate properties are values available inside the segment's `template` string.\n\n**Rules for what becomes a template property:**\n\n- **Exported struct fields** (capitalized) on the segment struct → `.FieldName`\n- **Unexported fields** are not accessible in templates\n- **Nested struct fields** use dot notation: a field `Working ScmStatus` exposes\n `.Working.Modified`, `.Working.Added`, etc.\n- **Zero-argument methods** with a single return value → `.MethodName`\n- **Document fields that are assigned** in `Enabled()` or its callees,\n not every inherited field from embedded structs is populated by every segment\n\nThe default template comes from the `Template()` method:\n\n```go\nfunc (s *MySegment) Template() string {\n return \" {{ .FieldName }} \"\n}\n```\n\n### Nested struct subsection convention\n\nWhen a property's type is itself a struct, add an `#### TypeName` subsection within\nthe Properties table section listing its exported fields. Example:\n\n```mdx\n#### Status\n\n| Name | Type | Description |\n| ---- | ---- | ----------- |\n| `.Modified` | `int` | Number of modified files |\n| `.Added` | `int` | Number of added files |\n| `.Deleted` | `int` | Number of deleted files |\n| `.Untracked` | `int` | Number of untracked files |\n| `.Changed` | `boolean` | Whether any changes exist |\n```\n\n## Key Source Files for Inherited Fields\n\nWhen a segment embeds a base struct, its inherited fields may also be template properties.\nCheck these files to discover what fields are available:\n\n| File | What it defines |\n| ---- | --------------- |\n| `src/segments/options/map.go` | `Provider` interface method signatures; shared `Option` constants |\n| `src/segments/base.go` | `Base` struct embedded by all segments; provides `options`, `env` |\n| `src/segments/scm.go` | `ScmStatus` type with working/staging status fields (git, mercurial, etc.) |\n| `src/segments/language.go` | `Version` type and language base fields (Python, Node, Go, etc.) |\n",".github/copilot-instructions.md":"# GitHub Copilot Instructions\n\nAll agent guidance for this repository lives in [AGENTS.md](../AGENTS.md): project overview,\nkey commands, architecture orientation, coding and commit conventions, skills, and the\nproject-knowledge workflow. Follow it in full.\n","AGENTS.md":"# Agent Instructions\n\nOh My Posh is a cross-shell prompt theme engine written in Go, with the module root in `src/`. Rendering runs on every\nshell prompt, so it is a hot path: no extra process spawns, network calls, or file reads per render without\n`src/cache`.\n\n## Non-negotiables\n\nCorrections in past sessions keep landing on these. Check each one before you report a change as done.\n\n1. **Reuse before building.** Find how the codebase already solves the problem before designing anything: a similar\n segment, an `Environment` method, `src/cache`, or a CLI call behind an option like other segments use. Never add a\n dependency without asking. Remove deprecated logic instead of maintaining it.\n2. **Go through `runtime.Environment`** (`s.env` in segments) for every OS, shell, file, and command call, so tests can\n mock it. Check its methods before reaching for `os`, `os/exec`, or `path/filepath`.\n3. **Tests prove behavior, not the patch.** A test must fail when the behavior breaks and survive a correct refactor.\n Write them table-driven; the `golang` skill has the rules.\n4. **No `else`.** Use guard clauses, early returns, or a `switch`. The Stop hook blocks new `else` branches.\n5. **Comments explain a why the code cannot.** Never restate a name or signature, exported symbols included, in any\n language. Default to no comment.\n6. **Log with `src/log`:** `log.Error(err)` where the error occurs, and `defer log.Trace(time.Now(), args...)` in\n functions worth tracing. Do not format errors yourself.\n7. **Commit only when asked, push only when asked.** Fold every fix to a commit that is not on `main` into that commit\n with `git commit --fixup ` and `git rebase --autosquash`, lint and CI fallout included. Never rewrite `main`.\n\n## Repository map\n\n| Path | Purpose |\n| ----------------------------- | ---------------------------------------------------------------------------- |\n| `src/segments/` | One `.go` and one `_test.go` per segment |\n| `src/config/` | Segment registry; an unregistered segment fails silently at runtime |\n| `src/prompt/` | Rendering engine |\n| `src/runtime/` | `Environment` abstraction and its mock |\n| `src/cache/` | TTL, file, and command-path caching; do not build another cache |\n| `src/cli/` | CLI commands on `src/cmdtree`, registered in `root.go` |\n| `src/shell/` | `oh-my-posh init `; `scripts/` are embedded, so rebuild after editing |\n| `themes/` | Bundled themes, validated against `themes/schema.json` |\n| `website/` | Docusaurus docs; segment pages live in `website/docs/segments//` |\n\nA shell integration change usually spans `src/shell/.go` and its script in `src/shell/scripts/`.\n\n## Commands\n\n```bash\n# from src/\ngo test ./...\ngolangci-lint run\n\n# from website/\nnpm run build # before a docs pull request\n```\n\nThe Stop hook (`.agents/hooks/main.go`) formats the changed files, runs `modernize`, `fieldalignment`, `golangci-lint`,\n`go test`, `markdownlint`, and the `else` check, and builds, lints, and analyzes platform-specific code for the other\noperating systems. Fix what it reports; never run `fieldalignment -fix`. `.claude/settings.json` and\n`.github/hooks/quality.json` both wire it, so change them together.\n\n## Docs\n\nDocs pages have no H1, because the front-matter `title` renders as the heading; use only H2 and H3. Wrap lines at 120\ncharacters. Use the `segment-create` skill for a new segment and `segment-docs` for its documentation.\n\n## Project knowledge\n\nBefore touching shell scripts, terminal or pty behavior, WSL-based testing, engine internals, or release and CI work,\nread the matching file in the `project-knowledge` skill. When a session uncovers a verified, actionable gotcha, append\nit to that file and commit it with the related change.\n\n## Pull request reviews\n\nValidate every comment against the code. Fold each fix into the commit that introduced the code with a fixup and\n`git rebase --autosquash`, then force-push the pull request branch with `--force-with-lease`. Reply to every thread\nwith the conclusion and the commit, then resolve it.\n","packages/msix/README.md":"# MSIX Package\n\n## Prerequisites\n\n- [Windows SDK] (provides `makeappx.exe` and `signtool.exe`)\n\n## Build the package\n\nThis guide assumes and advises the use of PowerShell as your shell environment for this purpose.\n\nPlace the executable to package at `./dist/oh-my-posh.exe`, or use `-Copy` to take it from\nthe repository's `dist` folder.\n\n```powershell\n./build.ps1 -Architecture x64 -Version \"1.3.37\"\n```\n\nThe package is created at `out/install-x64.msix`, along with an App Installer\nfile at `out/install-x64.appinstaller`. The App Installer configuration is also\nembedded in the MSIX, so installing the MSIX enables automatic updates on\nsupported Windows versions.\n\n## Install the package\n\n```powershell\nAdd-AppxPackage -Path ./out/install-x64.msix\n```\n\n[Windows SDK]: https://developer.microsoft.com/en-us/windows/downloads/windows-sdk/\n","website/static/skill.md":"---\nname: oh-my-posh\ndescription: Install, configure, or troubleshoot Oh My Posh/ohmyposh: shell init, themes, segments, Nerd Font icons, and prompt setup on PowerShell, zsh, bash, or fish.\n---\n\n# Oh My Posh\n\n> Oh My Posh is a cross-shell, cross-platform prompt theme engine for Windows, macOS, and Linux.\n> It renders beautifully themed prompts with Git status, language versions, cloud context,\n> and more — 120 segments in all.\n\nFull skill (folder-based, with per-OS and per-shell guides):\n[/skills/ohmyposh/SKILL.md](/skills/ohmyposh/SKILL.md)\n\n## Quick links\n\n- [Installation — Windows](/skills/ohmyposh/installation/windows.md)\n- [Installation — macOS](/skills/ohmyposh/installation/macos.md)\n- [Installation — Linux](/skills/ohmyposh/installation/linux.md)\n- [Shell setup — PowerShell](/skills/ohmyposh/shell/powershell.md)\n- [Shell setup — Bash](/skills/ohmyposh/shell/bash.md)\n- [Shell setup — Zsh](/skills/ohmyposh/shell/zsh.md)\n- [Shell setup — Fish](/skills/ohmyposh/shell/fish.md)\n- [Shell setup — Nu](/skills/ohmyposh/shell/nu.md)\n- [Shell setup — Cmd](/skills/ohmyposh/shell/cmd.md)\n- [Shell setup — Elvish](/skills/ohmyposh/shell/elvish.md)\n- [Shell setup — Xonsh](/skills/ohmyposh/shell/xonsh.md)\n- [Configuration & themes](/skills/ohmyposh/configuration.md)\n","website/static/skills/ohmyposh/SKILL.md":"---\nname: oh-my-posh\ndescription: \"Install, configure, or troubleshoot Oh My Posh/ohmyposh: shell init, themes, segments, Nerd Font icons, and prompt setup on PowerShell, zsh, bash, or fish.\"\n---\n\n# Oh My Posh\n\n> Oh My Posh is a cross-shell, cross-platform prompt theme engine. It displays Git status,\n> language versions, cloud context, system metrics and more in a beautifully themed\n> terminal prompt — 120 segments in all.\n\n## How to use this skill\n\n1. **Identify the user's OS** → follow the matching installation guide:\n - [Windows installation](/skills/ohmyposh/installation/windows.md)\n - [macOS installation](/skills/ohmyposh/installation/macos.md)\n - [Linux installation](/skills/ohmyposh/installation/linux.md)\n\n2. **Identify the user's shell** → follow the matching shell setup guide:\n - [PowerShell](/skills/ohmyposh/shell/powershell.md)\n - [Bash](/skills/ohmyposh/shell/bash.md)\n - [Zsh](/skills/ohmyposh/shell/zsh.md)\n - [Fish](/skills/ohmyposh/shell/fish.md)\n - [Nu / Nushell](/skills/ohmyposh/shell/nu.md)\n - [Cmd (via Clink)](/skills/ohmyposh/shell/cmd.md)\n - [Elvish](/skills/ohmyposh/shell/elvish.md)\n - [Xonsh](/skills/ohmyposh/shell/xonsh.md)\n - [Yash](/skills/ohmyposh/shell/yash.md)\n\n3. **Install a Nerd Font** — required for icons and glyphs:\n\n ```bash\n oh-my-posh font install meslo\n ```\n\n `oh-my-posh font list` prints every installable font. Recommended: **Meslo LGM NF**.\n Set it in the terminal emulator's font settings after installing.\n\n4. **Customize the prompt** → see [configuration](/skills/ohmyposh/configuration.md)\n\n## Detect the current shell\n\nIf the user is unsure which shell they are using (requires oh-my-posh to be installed first):\n\n```bash\noh-my-posh get shell\n```\n\n## Troubleshooting\n\n- **Icons show as boxes** — install a Nerd Font and set it in the terminal emulator.\n- **`oh-my-posh` not found after install** — restart the terminal or add the install path to `$PATH`.\n- **Slow prompt** -- enable async rendering by setting `\"async\": true` at the top level of your config.\n\nFull documentation: \nFAQ: \n","website/static/skills/ohmyposh/configuration.md":"# Oh My Posh — Configuration & Customization\n\n## Apply a theme\n\nPass `--config` to the init command with a theme name, local path, or remote URL.\n\n**By theme name** (no extension needed):\n\n```powershell\n# PowerShell\noh-my-posh init pwsh --config 'jandedobbeleer' | Invoke-Expression\n```\n\n```bash\n# Bash / Zsh\neval \"$(oh-my-posh init bash --config jandedobbeleer)\"\n```\n\n**By local file path:**\n\n```powershell\n# PowerShell\noh-my-posh init pwsh --config 'C:\\Users\\\\.mytheme.omp.json' | Invoke-Expression\n```\n\n```bash\n# Bash / Zsh\neval \"$(oh-my-posh init bash --config ~/.mytheme.omp.json)\"\n```\n\n**By remote URL:**\n\n```powershell\noh-my-posh init pwsh --config 'https://raw.githubusercontent.com/JanDeDobbeleer/oh-my-posh/main/themes/jandedobbeleer.omp.json' | Invoke-Expression\n```\n\n> Using a remote URL adds a network dependency. Oh My Posh caches remote configs using ETags,\n> but latency still applies on cache misses. For reliable offline use, copy the theme to a\n> local file and use a local path instead.\n\n## Browse available themes\n\nView all bundled themes online: \n\n> There is no terminal command to preview all available themes. Direct users to the website above.\n\n## Debug the current theme\n\nTo render your active prompt in debug mode (shows segment timing and values):\n\n```bash\noh-my-posh debug\n```\n\n## Export a theme for editing\n\n```bash\noh-my-posh config export --config jandedobbeleer --output ~/.mytheme.omp.json\n```\n\nThen set `--config ~/.mytheme.omp.json` in your init line and edit the file to taste.\n\n## WSL tip\n\nInside WSL you can share a theme stored in your Windows home folder:\n\n```bash\neval \"$(oh-my-posh init bash --config /mnt/c/Users//mytheme.omp.json)\"\n```\n\n## Live reload during editing\n\nEnable live reload so prompt changes appear without restarting the shell:\n\n```bash\noh-my-posh enable reload\n```\n\nDisable:\n\n```bash\noh-my-posh disable reload\n```\n\nPreview every configured prompt without restarting:\n\n```bash\noh-my-posh print preview\n```\n\nForce-render all segments regardless of context:\n\n```bash\noh-my-posh print preview --force\n```\n\n## Validate a config or segment via MCP\n\nWhen creating or editing a segment manually, use the oh-my-posh MCP server to validate the\nconfig or a segment snippet for schema errors. Agents can call:\n\n```bash\ncurl -X POST https://ohmyposh.dev/api/mcp \\\n -H \"Content-Type: application/json\" \\\n -d '{\n \"jsonrpc\": \"2.0\",\n \"method\": \"tools/call\",\n \"params\": {\n \"name\": \"validate_config\",\n \"arguments\": {\"content\": \"\", \"format\": \"auto\"}\n },\n \"id\": 1\n }'\n```\n\nOr use `validate_segment` to check a single segment snippet instead of an entire config.\n\n## Configuration reference\n\n- Full schema: \n- Docs: \n- Segments: \n","website/static/skills/ohmyposh/installation/linux.md":"# Oh My Posh — Linux Installation\n\n> **Prerequisites:** `curl`, `unzip`, `realpath`, and `dirname` must be available.\n> Make sure `curl` and the client certificate store are up to date.\n\n## Install\n\n```bash\ncurl -s https://ohmyposh.dev/install.sh | bash -s\n```\n\nBy default this installs to `~/bin` or `~/.local/bin` (whichever exists), or to the directory\nof any existing `oh-my-posh` binary. To install to a custom location:\n\n```bash\ncurl -s https://ohmyposh.dev/install.sh | bash -s -- -d ~/bin\n```\n\n## Update\n\nRe-run the install script — it replaces the existing binary in-place.\n\n## After installing\n\nRestart the terminal (or open a new window) so `oh-my-posh` is on `$PATH`, then proceed to the\n[shell setup guide](/skills/ohmyposh/SKILL.md).\n","website/static/skills/ohmyposh/installation/macos.md":"# Oh My Posh — macOS Installation\n\n> **Note:** The standard macOS Terminal only supports 256 colors. Use [iTerm2](https://iterm2.com)\n> or another modern terminal for full ANSI color and icon support.\n\n## Install\n\n**Recommended (Homebrew):**\n\n```bash\nbrew install jandedobbeleer/oh-my-posh/oh-my-posh\n```\n\n**MacPorts** (community-maintained):\n\n```bash\nsudo port selfupdate\nsudo port install oh-my-posh\n```\n\n## Update\n\n```bash\nbrew upgrade oh-my-posh\n```\n\n## After installing\n\nRestart the terminal (or open a new window) so `oh-my-posh` is on `$PATH`, then proceed to the\n[shell setup guide](/skills/ohmyposh/SKILL.md).\n","website/static/skills/ohmyposh/installation/windows.md":"# Oh My Posh — Windows Installation\n\n## Install\n\n**Recommended (winget):**\n\n```powershell\nwinget install JanDeDobbeleer.OhMyPosh --source winget\n```\n\n**Manual (PowerShell):**\n\n```powershell\nSet-ExecutionPolicy Bypass -Scope Process -Force; Invoke-Expression ((New-Object System.Net.WebClient).DownloadString('https://ohmyposh.dev/install.ps1'))\n```\n\n**Chocolatey:**\n\n```powershell\nchoco install oh-my-posh\n```\n\n## Update\n\n```powershell\nwinget upgrade JanDeDobbeleer.OhMyPosh --source winget\n```\n\n## After installing\n\nRestart the terminal (or open a new window) so `oh-my-posh` is on `$PATH`, then proceed to the\n[shell setup guide](/skills/ohmyposh/SKILL.md).\n\n> **Tip:** When using Oh My Posh inside WSL, follow the\n> [Linux installation](/skills/ohmyposh/installation/linux.md) guide inside WSL instead.\n","website/static/skills/ohmyposh/shell/bash.md":"# Oh My Posh — Bash Setup\n\n## Configure\n\nAdd this as the **last line** of `~/.bashrc` (or `~/.profile` / `~/.bash_profile` depending on\nyour environment):\n\n```bash\neval \"$(oh-my-posh init bash)\"\n```\n\nReload:\n\n```bash\nexec bash\n```\n\nOr, if using `~/.profile`:\n\n```bash\n. ~/.profile\n```\n\n## Next step\n\n→ [Customize your prompt](/skills/ohmyposh/configuration.md)\n","website/static/skills/ohmyposh/shell/cmd.md":"# Oh My Posh — Cmd Setup (via Clink)\n\nCmd does not support custom prompts natively. [Clink](https://chrisant996.github.io/clink/)\nadds that capability and also enhances Cmd with readline-style editing.\n\n## Prerequisites\n\nInstall Clink and enable autostart. Find the Clink scripts directory:\n\n```bash\nclink info\n```\n\n## Configure\n\nCreate a file called `oh-my-posh.lua` in the Clink scripts directory:\n\n```lua\nload(io.popen('oh-my-posh init cmd'):read(\"*a\"))()\n```\n\nRestart Cmd to apply.\n\n> **Tip:** Clink has built-in support for Oh My Posh. You can also set the prompt with:\n>\n> ```bash\n> clink config prompt use oh-my-posh\n> ```\n\n## Next step\n\n→ [Customize your prompt](/skills/ohmyposh/configuration.md)\n","website/static/skills/ohmyposh/shell/elvish.md":"# Oh My Posh — Elvish Setup\n\n## Configure\n\nAdd this as the **last line** of `~/.elvish/rc.elv`:\n\n```bash\neval (oh-my-posh init elvish)\n```\n\nReload:\n\n```bash\nexec elvish\n```\n\n## Next step\n\n→ [Customize your prompt](/skills/ohmyposh/configuration.md)\n","website/static/skills/ohmyposh/shell/fish.md":"# Oh My Posh — Fish Setup\n\n> **Requires Fish 4.1.0 or later.** Older versions have issues and do not support\n> transient prompt.\n\n## Configure\n\nAdd this as the **last line** of `~/.config/fish/config.fish`:\n\n```bash\noh-my-posh init fish | source\n```\n\nReload:\n\n```bash\nexec fish\n```\n\n## Next step\n\n→ [Customize your prompt](/skills/ohmyposh/configuration.md)\n","website/static/skills/ohmyposh/shell/nu.md":"# Oh My Posh — Nu / Nushell Setup\n\n> **Requires Nushell v0.104.0 or later.**\n\n## Configure\n\nAdd this as the **last line** of the Nushell config file (path: `$nu.config-path`):\n\n```bash\noh-my-posh init nu\n```\n\nRestart Nushell to apply.\n\n## Next step\n\n→ [Customize your prompt](/skills/ohmyposh/configuration.md)\n","website/static/skills/ohmyposh/shell/powershell.md":"# Oh My Posh — PowerShell Setup\n\n## Configure\n\nEdit your PowerShell profile. Find its path:\n\n```powershell\n$PROFILE\n```\n\nOpen it (create it if it doesn't exist):\n\n```powershell\nnotepad $PROFILE\n# or: New-Item -Path $PROFILE -Type File -Force\n```\n\nAdd this as the **last line**:\n\n```powershell\noh-my-posh init pwsh | Invoke-Expression\n```\n\nReload the profile:\n\n```powershell\n. $PROFILE\n```\n\n## Troubleshooting\n\n**Execution policy blocks scripts:**\n\n```powershell\nSet-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope LocalMachine\n```\n\nOr use the `--eval` flag (slightly slower startup):\n\n```powershell\noh-my-posh init pwsh --eval | Invoke-Expression\n```\n\n## Next step\n\n→ [Customize your prompt](/skills/ohmyposh/configuration.md)\n","website/static/skills/ohmyposh/shell/xonsh.md":"# Oh My Posh — Xonsh Setup\n\n## Configure\n\nAdd this as the **last line** of `~/.xonshrc`:\n\n```bash\nexecx($(oh-my-posh init xonsh))\n```\n\nReload:\n\n```bash\nexec xonsh\n```\n\n## Next step\n\n→ [Customize your prompt](/skills/ohmyposh/configuration.md)\n","website/static/skills/ohmyposh/shell/yash.md":"# Oh My Posh — Yash Setup\n\n## Configure\n\nAdd this as the **last line** of `~/.yashrc`:\n\n```bash\neval \"$(oh-my-posh init yash)\"\n```\n\nReload:\n\n```bash\nexec yash\n```\n\n## Notes\n\n- Requires a yash version that supports `$PROMPT_COMMAND` (>= 2.39) and `$POST_PROMPT_COMMAND`\n (>= 2.52) for full functionality; oh-my-posh hooks into both to time commands and draw the prompt.\n- The prompt is rendered through `YASH_PS1` (and `YASH_PS1R` for the right prompt), which take\n precedence over `PS1`/`PS2` in yash.\n- Right prompt support is native via `YASH_PS1R`.\n- Transient prompt and tooltips are not supported in yash.\n\n## Next step\n\n→ [Customize your prompt](/skills/ohmyposh/configuration.md)\n","website/static/skills/ohmyposh/shell/zsh.md":"# Oh My Posh — Zsh Setup\n\n## Configure\n\nAdd this as the **last line** of `~/.zshrc`:\n\n```bash\neval \"$(oh-my-posh init zsh)\"\n```\n\nReload:\n\n```bash\nexec zsh\n```\n\n## macOS Terminal workaround\n\nThe standard macOS Terminal has issues with ANSI characters. To skip Oh My Posh there while\nkeeping it in iTerm2 and other modern terminals:\n\n```bash\nif [ \"$TERM_PROGRAM\" != \"Apple_Terminal\" ]; then\n eval \"$(oh-my-posh init zsh)\"\nfi\n```\n\n## Next step\n\n→ [Customize your prompt](/skills/ohmyposh/configuration.md)\n"},"files":{".agents/agents/code-reviewer.agent.md":"---\nname: code-reviewer\ndescription: >\n Reviews a diff, a set of files, or an inline snippet for alignment with the repository's\n language skills, clean-code rules, and architecture principles, returning findings only.\n Orchestrating agents such as pr-reviewer and issue-analyzer invoke it through the agent tool; a\n user can also say \"check this against our conventions\", \"review these files for clean code\", or\n \"does this snippet follow the Go skill\".\ntools: [\"read\", \"search\", \"execute\"]\n---\n\nYou are a senior contributor to this project performing a focused code review. Your job is to judge\nwhether a diff, a set of files, or an inline snippet aligns with this repository's embedded skills\nand architecture principles. You do not judge correctness, test coverage, documentation\ncompleteness, or commit messages - the caller that invoked you owns those. You never edit, commit,\nor push; every result of this review goes into your response.\n\n## Input you expect\n\nThe caller passes, in its request:\n\n- What to review: a git ref range (`main...HEAD`, `FETCH_HEAD`), a pull request number, a list of\n file paths, or an inline snippet or proposal in fenced code blocks.\n- One sentence of intent: what the change is trying to do.\n- An optional focus list: dimensions to weight, such as \"Go concurrency\" or \"PowerShell error\n handling\".\n\nWhen the request lacks the artifact or the intent, ask for the missing part in one line and stop.\n\nMaterialise each input read-only, and nothing else:\n\n- Ref range: `git diff `.\n- Pull request number: `gh pr diff ` plus `git fetch origin pull//head` and\n `git show FETCH_HEAD:` for files you need beyond the diff.\n- File paths: read them directly.\n- Snippet: read the surrounding code in the repository location it would land in, so you judge it\n in context rather than in isolation.\n\n## Loading the rubric\n\nLoad these before reading the code, matched to the file types involved:\n\n- The AGENTS.md non-negotiables, always.\n- `golang` skill for every `.go` file.\n- The AGENTS.md \"Docs\" rules for every `.md`/`.mdx` file; add `segment-docs` when the file sits\n under `website/docs/segments/`.\n- The matching `project-knowledge` topic file for the touched area, when one exists.\n\nSearch for call sites and similar existing implementations, so you can judge consistency with the\nrest of the codebase instead of reviewing the change in isolation.\n\n## What you check\n\n### Skill alignment\n\nGo: `else` after a return, deep nesting, uppercase error strings, an OS or shell call\nmade outside the `Environment` abstraction, new cache logic instead of reusing `src/cache/`, and the\ngolang skill's test structure rules (table-driven tests, behavior over patch-shape assertions).\nMarkdown: heading levels (no H1, no skipped levels), fenced code blocks with a language tag,\n120-character lines, and required frontmatter.\n\n### Clean code\n\nIntention-revealing names, small single-purpose functions, guard clauses instead of nested\nconditionals, no dead code, no duplication, and comments that explain only the WHY per the\nAGENTS.md rule. That rule applies to every language in the repository, not only a file's primary\nlanguage.\n\n### Architecture and SOLID\n\nSingle responsibility, extension through existing\nabstractions rather than modification of unrelated code, interfaces honoured as contracts, narrow\ninterfaces over fat ones, dependency on `Environment` rather than concrete OS calls, the Law of\nDemeter, primitive obsession, Object Calisthenics, and hot-path cost in I/O and allocations per\nrender.\n\n### Consistency\n\nConfirm the change follows the pattern of the nearest existing implementation, and name the file\nyou compared against. A new segment option that skips a validation step every other option\nperforms, or a new CLI command that skips the registration pattern every other command follows, is\na finding even when the code works.\n\n## What you do not check\n\nState these explicitly in your response, so the caller keeps ownership of them:\n\n- Correctness of logic - whether the change does what it claims.\n- Test coverage - whether tests exist or are adequate.\n- Documentation and registration completeness - whether docs, schema, or sidebar entries ship with\n the change.\n- Commit messages.\n- Anything outside the artifact you were given.\n\n## Output format\n\nStructure your response exactly as follows, so the caller can merge it mechanically:\n\n- **Findings**: one bullet per finding, in the form `path:line, severity, problem, rule source,\n fix`. Severity is one of `blocking`, `should fix`, `minor`. Rule source names the skill and\n section, or the checklist item. Order by severity. For an inline snippet, use `snippet:line`\n instead of a file path. When you find nothing, this section contains exactly `No findings.`\n- **Compared against**: the existing files you used as the consistency baseline.\n- **Not assessed**: what you could not judge and why - a snippet with no surrounding code, a file\n type with no matching skill, a dimension the caller excluded from its focus list.\n\nDo not add a verdict, praise, a summary of the change, or a style nit that a formatter or linter\nalready enforces, unless it also violates a skill rule.\n\n## Hard constraints\n\n- Read-only: never edit a file, commit, push, check out a branch, or write to GitHub.\n- Verify every finding by reading the code yourself; never infer one from a description or from a\n bot comment you have not checked.\n- Cite the rule for every finding, or drop the finding.\n- All output goes in your response, nowhere else.\n",".agents/agents/issue-analyzer.agent.md":"---\nname: issue-analyzer\ndescription: >\n Investigates a GitHub issue and reports the analysis in the conversation only. Reads the issue,\n reproduces the reported behavior when possible, and traces the root cause in the code. Never\n posts to the issue, edits it, or changes labels. Use when someone says \"analyze issue #N\",\n \"investigate this issue\", \"look into #N\", \"triage #N\", or \"research issue\", or asks for a\n deep-dive on a bug report or feature request. Always invoke this agent rather than doing the\n analysis inline.\ntools: [\"read\", \"search\", \"execute\", \"agent\"]\n---\n\nYou are a senior contributor to this project. Your job is to investigate a GitHub issue and report\na structured analysis in your response to the conversation. You never touch the issue itself, and\nyou never edit a repository file; your output is the analysis, not a change.\n\n## Hard constraints\n\n- Never run `gh issue comment`, `gh issue edit`, `gh issue close`, or any command that changes\n labels, assignees, or state.\n- `gh` and `git` are read-only here: view, list, log, blame, diff, show. No write, no push, no\n branch creation.\n- The full analysis goes in the conversation response and nowhere else. Do not draft a comment\n file, open a pull request, or stage a change.\n- Edit no repository file. A proposed fix belongs in the response as a snippet, not in a\n working-tree edit.\n- Do not guess about behavior you cannot verify from the code. If something is ambiguous, say so\n in the open questions.\n- `code-reviewer` is the only agent you invoke, and only on the proposal, never on the issue\n itself.\n\n## Workflow\n\n### Step 1: Precondition checks\n\nBefore doing anything else, confirm both of these and stop with a clear message if either fails:\n\n- `git rev-parse --is-inside-work-tree` confirms you are inside the oh-my-posh repository.\n- `gh auth status` confirms the GitHub CLI can read issues and comments.\n\n### Step 2: Fetch the issue\n\n```shell\ngh issue view {number} --json number,title,body,labels,comments,author,createdAt,state\n```\n\nFollow every linked issue, pull request, and discussion mentioned in the body or comments with the\nsame command (or `gh pr view` for a pull request), so the analysis accounts for prior context.\nRead the title, body, and comments carefully. Pay attention to:\n\n- What the reporter says is happening, versus what they expect instead.\n- Their platform: OS, shell, terminal, and tool version, if mentioned.\n- Any config fragments or theme snippets they pasted.\n- Labels already applied, which hint at the affected area.\n\n### Step 3: Identify the affected codebase area\n\nUse the table below as a starting point for which area of the codebase is likely involved:\n\n| Issue topic | Where to look |\n| -------------------- | -------------------------------------------------------- |\n| A specific segment | `src/segments/.go` + `src/segments/_test.go` |\n| Shell integration | `src/shell/` and `src/shell/scripts/` |\n| Rendering / styling | `src/prompt/engine.go`, `src/color/` |\n| Theme / config | `src/config/`, `themes/` |\n| CLI command | `src/cli/` |\n| Caching | `src/cache/` |\n| Templates | `src/template/` |\n\nSearch for the symbols, function names, struct definitions, and call sites mentioned in the\nissue, instead of reading whole directories to find them. Trace the data flow and pin down the\nexact files and line numbers before opening anything for detailed reading.\n\nBefore investigating an area with known history (shell integration, terminal or pty behavior, WSL\ntest harnesses, caching, segments, streaming, the serve daemon), read the matching topic file from\nthe `project-knowledge` skill. It records verified gotchas so you do not repeat a known dead end.\n\n### Step 4: Investigate like the code-changes triage path\n\nFollow step 1 of the `code-changes` skill for the deep investigation:\n\n1. Reproduce the reported behavior. When reproduction needs an environment you lack (OS, shell,\n font, hardware), say so and reason from the code instead, flagged as such.\n2. Locate the root cause in the code, not in the issue text. Reports frequently describe symptoms\n and guess wrong about causes.\n3. Assess blast radius: who else is affected, and since which release or commit, using `git log`\n and `git blame` on the affected file to find the change that introduced the defect.\n\n### Step 5: Synthesize findings\n\nCombine the fetched context, the codebase reading, and the triage steps into the report described\nin \"Report format\" below. Be specific: cite actual file paths and line numbers. A finding like\n\"this could be related to X\" is not useful and does not belong in the report.\n\n## Design the proposal, then have it reviewed\n\nWhenever the analysis proposes a change, sketches an architecture, or includes a code snippet,\nprepare it like a change that will actually be reviewed, even though you will never submit it:\n\n1. Load the rules for every file type the proposal touches: the `golang` skill for `.go` files,\n the AGENTS.md \"Docs\" rules for `.md`/`.mdx` files, and both `segment-create` and\n `segment-docs` when the proposal involves a new segment.\n2. When the proposal contains a code snippet or a structural design (a new type, a new\n abstraction, a new package, or a cross-module change), invoke `code-reviewer` through the\n `agent` tool with the proposal text verbatim in fenced code blocks, the target file paths, and\n one sentence of intent. Fold its findings into the proposal before reporting: revise the\n snippet, or list the finding under open questions with your reason when you disagree. Skip the\n invocation for a trivial fix (a one-line change, a constant, a typo) and say so in the report.\n\nAny Go snippet must conform to the golang skill: no `else`, early returns instead, lowercase error strings,\nthe `Environment` abstraction for every OS or shell call, and `src/cache/` reused rather than a\nnew cache package. Every language follows the AGENTS.md comment rule: comment only the WHY, never\nrestate what the code already shows. State in the proposal which skill or checklist rule shaped\neach notable decision, so the maintainer sees the reasoning, not just the result.\n\n## Report format\n\nStructure the response in this order:\n\n1. One-sentence headline naming the finding.\n2. **Reproduction status**: confirmed, could not reproduce (with evidence), or not reproducible in\n this environment (with the specific reason).\n3. **Root cause**, with `file:line` references.\n4. **Affected files and functions**, as a concrete list, not a general area.\n5. **Proposed change**: scope, code snippets that follow the language skills above, the tests to\n add in the existing `_test.go` file, and the docs to touch. Note whether `code-reviewer`\n reviewed the snippet, or that the review was skipped and why.\n6. **Out of scope**: what the change deliberately leaves alone.\n7. **Effort**: small, medium, or large.\n8. **Open questions**: anything still ambiguous.\n9. **Suggested reply to the reporter**: draft text the maintainer can paste as-is, written for the\n reporter rather than a fellow contributor. Skip internal file paths unless the reporter would\n find them useful.\n",".agents/agents/pr-reviewer.agent.md":"---\nname: pr-reviewer\ndescription: >\n Reviews an existing pull request for correctness and for alignment with the\n repository's embedded skills and architecture principles. Reports findings\n in the conversation only; never posts reviews or comments. Use when someone\n says \"review PR #N\", \"review this pull request\", \"check #N against our\n conventions\", \"does PR #N follow the Go skill\", or \"code review for #N\". Always\n invoke this agent rather than reviewing inline.\ntools: [\"read\", \"search\", \"execute\", \"agent\"]\n---\n\nYou are a senior contributor to this project performing a pull request review. Your job is to\nverify a pull request against the repository's own conventions and report what you find. You never\nchange the pull request or the repository; every result of this review goes into your response.\n\n## Preconditions\n\nBefore doing anything else, confirm the environment:\n\n- `git rev-parse --is-inside-work-tree` - stop and tell the user what is missing if this fails.\n- `gh auth status` - stop and tell the user what is missing if this fails.\n\n## Fetching the pull request\n\nEverything here is read-only.\n\n- `gh pr view {number} --json number,title,body,baseRefName,headRefName,commits,files,labels,reviews,comments`\n- `gh pr diff {number}`\n\nTo read changed files at the PR head: run `gh pr checkout {number}` when the working tree is\nclean, otherwise leave the working tree alone and run `git fetch origin pull/{number}/head` plus\n`git show FETCH_HEAD:{path}` for each file you need. Checking out the branch is the only change\nyou make to the working tree.\n\nExisting review comments, bot or human, are leads, not verdicts. Verify each one against the code\nbefore repeating it as your own finding.\n\n## Loading the rubric\n\nLoad these before reading the diff:\n\n- `conventional-commit` skill against every commit message in the PR.\n- The matching `project-knowledge` topic file for the touched area (shell scripts, cache,\n segments, terminal).\n\nSearch for call sites and similar existing implementations so you can judge whether the change is\nconsistent with the rest of the codebase.\n\nConvention and architecture review is delegated to `code-reviewer`. Its rubric (skill alignment,\nclean code, architecture, SOLID) lives with that agent, not in this profile.\n\n## Review dimensions\n\nCheck each dimension below and record concrete evidence, not impressions.\n\n### Correctness\n\nRead the code path itself, not the PR description, and confirm:\n\n- Logic does what the diff claims.\n- Error handling covers the failure modes the change introduces.\n- Nil and zero-value handling is correct.\n- Concurrency is safe: no new data races or missing synchronization.\n- Platform differences (Windows/Unix) are handled where the change touches OS or shell behavior.\n- No regression in behavior the PR does not intend to change.\n\n### Conventions and architecture (delegated)\n\nInvoke `code-reviewer` through the `agent` tool with the pull request number (or the `FETCH_HEAD`\nrange), the PR's intent in one sentence taken from the title and body, and the touched areas as\nfocus. Wait for its findings. Verify any `blocking` finding against the code yourself before\npromoting it into the report. Merge the rest as returned, keeping their rule sources.\n\n### Tests\n\nConfirm the change is covered by behavior tests in the sibling `_test.go` file. Flag tests that\nassert implementation details or duplicate declared data instead of behavior. Flag missing tests\nfor new branches the diff introduces.\n\n### Documentation and registration\n\nConfirm user-visible changes ship docs in the same PR. A new segment needs every item in the\n`segment-create` skill's checklist. Confirm `themes/schema.json` is updated for config changes.\n\n### Commits\n\nCheck conventional commit type and scope, one logical unit per commit, and that `BREAKING CHANGE`\nappears only for user-facing config behavior.\n\n## Verification you run yourself\n\nRun what is feasible given the changed files and quote the decisive output line for any failure:\n\n- From `src/`: `go build ./...`, `go test .//...`,\n `golangci-lint run .//...`.\n- `npx markdownlint-cli2 ` for each changed Markdown file.\n\n## Scope\n\nReview only what the pull request introduces. A pre-existing problem on an untouched line is out\nof scope; add a one-line note only when the PR makes that problem worse.\n\n## Report format\n\nStructure your response exactly as follows:\n\n- **Verdict**: one line, either \"ready to merge\" or \"changes needed\", with the count of blocking\n findings.\n- **Findings**: ordered by severity (blocking, should fix, minor). One bullet per finding, in the\n form `path:line, severity, problem, rule source (skill and section, or checklist item), fix`.\n Merge in the findings `code-reviewer` returned, per \"Conventions and architecture\" above.\n- **Verified**: the commands you ran and their result.\n- **Existing review threads**: which ones you confirmed valid or invalid, and why.\n- **Out of scope**: pre-existing issues you noticed but did not evaluate.\n- **Not assessed**: whatever `code-reviewer` reported under its own `## Not assessed`, so gaps in\n the delegated review stay visible.\n\nDo not include praise, a summary of what the PR does beyond one sentence, or style nits that a\nformatter or linter already enforces, unless they also violate a skill rule.\n\n## Hard constraints\n\n- Never run `gh pr review`, `gh pr comment`, `gh pr edit`, `gh pr merge`, or any other command that\n writes to GitHub. `gh` and `git` are read-only here, apart from fetching and checking out the\n branch.\n- Never resolve review threads.\n- Never commit, push, or edit any file in the repository.\n- All output goes in your conversation response, nowhere else.\n- Do not guess. When the code is ambiguous, say what evidence is missing.\n- Do not restate a bot reviewer's comment as your own finding without verifying it against the\n code first.\n- `code-reviewer` is the only agent you invoke, and only once per review, unless it asked for\n missing input.\n",".agents/skills/code-changes/SKILL.md":"---\nname: code-changes\ndescription: >\n Workflow for any task that ends in code changes: issue analysis or triage, pull request review comments, features,\n bug fixes, refactors. Invoke at the start of such a task, before reading or writing code.\n---\n\n# Code changes\n\n## 1. Analyze, then stop\n\n- Read the code, not only the issue, review comment, or stack trace: reports and bot reviewers are often wrong. Fetch\n context with `gh issue view --comments` or `gh pr view --comments`.\n- Reproduce the problem when possible; say so when you cannot.\n- Look for what already exists before designing anything: a helper, a similar module, a pattern another feature uses,\n a CLI to call instead of reimplementing it. Prefer the smallest change that reuses existing code, and the change that\n removes code over the one that adds it. Deprecated logic gets removed, not maintained.\n- Report the root cause with file references, the proposed change and its scope, what stays out of scope, and open\n questions.\n- **Stop and wait for a go.** Skip the stop only when the request already asks for the implementation (\"fix it\",\n \"do it\"). A go for analysis is not a go for implementation, and a new diagnosis after a failed verification needs a\n new go.\n\nFor triage only (\"look at #n\"), the report is the deliverable: add the blast radius and a suggested reply to the issue.\n\n## 2. Plan\n\n- Load the language and format skills for every file you will touch before writing any code, and follow them from the\n first line. A rule read at review time turns a violation into rework.\n- When replacing working code, list what the old code does (defaults, key bindings, error messages) and keep all of it.\n Dropping any of it needs a go first.\n- For a judgment call you cannot make with confidence (unclear root cause, security, irreversible change), ask the\n strongest available model that one question, then continue.\n\n## 3. Implement\n\n- Do standard work yourself. Delegate only independent tasks that can run in parallel (one worktree each) or\n mechanical batches for a cheaper model.\n- A delegation carries the decided approach, the files, the binding skill rules, the verification commands, the\n non-goals, and the instruction to stop and report anything the spec does not cover.\n- Never delegate analysis, final verification, commits, or pushes.\n\n## 4. Review the diff\n\nReview every diff as an external pull request, your own included:\n\n- Everything asked for, nothing more. Replace overbuilt solutions with simpler ones.\n- Consistency with the surrounding code beats a new pattern.\n- Cut tests that assert implementation details, copy data declared elsewhere in the diff, duplicate another test, or\n would still pass with the bug present.\n- Delete comments that restate the code.\n\n## 5. Verify\n\n- Build, tests, formatters, and linters pass with zero findings. Never weaken a gate or delete a test to get there.\n- Prove it works: run the real flow the way the user reaches it (the built binary, a cold start) and record the actual\n output.\n- Update documentation in the same change as the behavior it describes.\n- After two failed verification rounds on the same task, stop and report instead of trying a third time.\n\n## 6. Deliver\n\n- Commit only when the user asks for it. Push or open a pull request only when asked; push a rewritten branch with\n `--force-with-lease`.\n- Write messages with the `conventional-commit` skill. One logical change per commit; stage files explicitly.\n- Fold a fix to a commit that is not on the default branch into that commit: `git commit --fixup `, then\n `git rebase --autosquash`. That includes lint, test, and CI fallout. Never stack \"fix\" commits on top.\n- Report the outcome first: what changed and why, the verification evidence, what is left for the user, and anything\n removed.\n\n## Pull request review comments\n\n1. Fetch every unresolved thread and validate each against the code. Treat bot comments as leads, not verdicts.\n2. Valid: fix it as a fixup into the commit that introduced the code, autosquash, verify, and force-push the pull\n request branch.\n3. Invalid: do not change code to appease it. Reply with the evidence. When the misreading exposes confusing code,\n clarify the code and say so.\n4. Reply to every thread with the conclusion and the commit that addresses it, then resolve the thread.\n",".agents/skills/conventional-commit/SKILL.md":"---\nname: conventional-commit\ndescription: >\n Rules for writing Conventional Commits messages in this project. MUST be invoked every time a\n commit is created.\ntriggers:\n - on_commit\n---\n\n# Conventional commit\n\n`.commitlintrc.yml` is the source of truth: use only the types it allows. Beyond the\nspecification:\n\n- Keep the header (`type(scope): description`) at 72 characters or fewer.\n- Write the description in the imperative, without a trailing period: `add`, `fix`, `bump`. Never\n copy past tense from the request (`added`, `fixed`, `bumped`).\n- Use the affected area as the scope (`segment`, `cache`, `config`); omit it for cross-cutting\n changes.\n- A change that removes, renames, or alters behavior callers depend on carries both `!` after the\n type or scope and a `BREAKING CHANGE:` footer. Never one without the other.\n- Use the body for why, not what, wrapped at 72 characters.\n- Review `git diff --cached` and stage files explicitly; never `git add -A`.\n\n```text\nfeat(segment)!: rename template property StartTime to Start\n\nBREAKING CHANGE: template strings using .StartTime must be updated to .Start\n```\n",".agents/skills/golang/SKILL.md":"---\nname: golang\ndescription: >\n Go conventions for this project that differ from common Go practice. Apply when writing,\n reviewing, or refactoring any Go source or test file.\ntriggers:\n - on_commit\n---\n\n# Go conventions\n\nStandard idiomatic Go applies. These are the rules that differ or that agents keep breaking.\n\n## Code\n\n- Never use `else`, in tests too. Return early, `continue`, `break`, or use a `switch`.\n- Comments explain a why the code cannot express: a hidden constraint, a workaround, a surprising\n invariant. No doc comments that restate a name or signature, exported symbols included.\n- Use named fields in every struct literal, never positional ones: fixing fieldalignment findings\n reorders struct fields.\n- Keep lines under 180 characters (`lll`).\n- When a standard library package collides with an existing import, alias it `lib`, for\n example `libtime`.\n- Start error strings lowercase, without trailing punctuation.\n- Ask before adding a dependency.\n\n## Tests\n\n- Assert with `testify` (`assert`, `require`).\n- Write table-driven tests: one behavior is one test function with a table. Per-case fixtures,\n mock returns, and expected errors are table fields, not reasons for a new function. Extend an\n existing table instead of adding a function. Split when the API under test or the setup and\n assertion flow differs, and for no other reason.\n- Test behavior, not the patch. Name the behavior a test proves, then ask:\n 1. Could the original bug still occur while this test passes?\n 2. Could a correct refactor make it fail?\n\n If either answer is yes, redesign or drop the test. Never assert on source text, embedded\n scripts, or statement order; assert on text when the emitted text is itself the contract\n (generated shell code, escaping, serialization). When the behavior cannot be exercised, say so\n instead of adding a proxy test.\n- A test that mutates package-level state saves the original value and restores it with\n `t.Cleanup`, never a hardcoded value.\n\n## Before committing\n\nRun from the module root and fix every finding:\n\n```bash\nmodernize -fix ./...\nfieldalignment ./...\ngolangci-lint run\n```\n\n- Never run `fieldalignment -fix`: it drops the comments of the fields it reorders. Reorder by\n hand.\n- Commit the `modernize` rewrites with the change that triggered them.\n- After touching a `_windows.go`, `_unix.go`, `_darwin.go`, `_linux.go`, or `//go:build` file,\n also run `go build ./...`, `golangci-lint run`, `modernize ./...`, and `fieldalignment ./...`\n with `GOOS` set to another platform. The host toolchain skips other platforms' files, so their\n errors otherwise surface in CI.\n- `dupl` on near-identical tests: merge them into one table. Reserve `//nolint:dupl`, with a reason,\n for tests that must stay separate. `goconst`: extract a string literal used three or more\n times into a constant.\n",".agents/skills/project-knowledge/SKILL.md":"---\nname: project-knowledge\ndescription: >\n Verified, actionable gotchas for oh-my-posh. Read the matching topic file BEFORE changing shell integration\n scripts (pwsh, zsh, bash, fish, cmd/Clink, nu, elvish, xonsh), terminal or pty behavior, WSL or e2e shell tests,\n Go internals (cache, segments, streaming, serve daemon, template rendering, output sanitization), or release, CI,\n build, and packaging workflows.\n---\n\n# Project Knowledge\n\nNon-obvious constraints, platform quirks, traps, and failed approaches. Read only the files the task touches; any\nshell-script edit also needs `testing`. Entries are point-in-time: verify against the code and fix drift.\n\n| Topic | Read when |\n| ------------------------------------ | ----------------------------------------------------------------------------- |\n| [codebase](references/codebase.md) | Go internals: templates, sanitization, segments, cache, streaming, serve |\n| [release](references/release.md) | `release.yml`, signing, packaging, CI gates, `-race`, rebasing on Windows |\n| [testing](references/testing.md) | Any shell-script edit; e2e/pty harnesses, WSL, ConPTY, Windows Terminal, nu |\n| [zsh](references/zsh.md) | `omp.zsh`, zle widgets, coproc, zsh-vi-mode |\n| [pwsh](references/pwsh.md) | `omp.ps1`, PSReadLine, runspaces, engine events, pwsh perf |\n| [fish](references/fish.md) | `omp.fish`, fish jobs, fifos, key bindings |\n| [bash](references/bash.md) | `omp.bash`, PROMPT_COMMAND, readline, ble.sh |\n| [cmd-clink](references/cmd-clink.md) | `omp.lua`, Clink, Windows pipe lifecycles |\n\n## Write-back\n\n- Append only verified entries that change what an agent does, phrased \"do X / don't do Y, because Z\", to the\n matching file (new file plus index row only when none fits). No narratives or history.\n- Update or delete a stale entry instead of stacking a correction. Date it only when staleness matters.\n- Commit knowledge updates with the change they relate to.\n",".agents/skills/project-knowledge/references/bash.md":"# bash\n\nVerified on bash 5.2 (2026-07).\n\n- Never run the `exec` builtin from PROMPT_COMMAND, not even `exec {fd}nul` in the command, or the child's stderr corrupts the display.\n- Windows has no SIGPIPE: stdin EOF is the daemon's only exit signal. Clink's pipes are `_O_NOINHERIT`, so cmd's\n death closes the daemon's stdin.\n- Test with `luac -p` plus a Lua harness that stubs the Clink API (`winget install DEVCOM.Lua`,\n `chrisant996.Clink`). Clink cannot run headless, so live smoke tests stay manual.\n",".agents/skills/project-knowledge/references/codebase.md":"# Codebase\n\n## Template markup trust boundary\n\n- Print-action output is chevron-escaped (`escapePrintActions`); only `template.Markup` values keep `<...>`\n anchors. Keep attacker-controlled data (VCS refs, API responses, folder names) in plain strings. `RawMarkup` is for\n user config only, `EscapeMarkup` for data, `JoinMarkup` for composition.\n- Segment fields built from option strings that carry anchors (icons, `branch_icon`, `folder_separator_icon`,\n `status_formats`) must be `template.Markup`, or the anchors render as literal text.\n- Keep `template.Markup` a named string, never a struct: text/template treats every struct as true (breaks\n `{{ if .BranchStatus }}` guards in shipped themes) and `eq` cannot compare it to a string.\n- Untrusted templates (`RenderUntrusted`, path segment) escape Markup results too. The path segment escapes folder\n names with `template.EscapeSource` on every branch of `replaceMappedLocations`; a new early return needs its own\n escape.\n- New func-map entries: output not derived from input (`readFile`, `cmd`, `b64dec`, `env`) goes in `noPromote`;\n attacker-chosen counts (`repeat`, `seq`, `until`, `rand*`) go in `dangerousFuncs` (trusted templates only). For a\n hot function, add a typed case to `markupAwareTyped` first.\n- Never bypass `formats.EscapeSequences` in `terminal.write`'s `isHyperlink` branch: bash `@P` re-interprets a\n backslash in the OSC 8 URI.\n- `src/prompt/golden_test.go` renders every shipped theme byte-exact. A golden diff after a markup change means a\n theme relied on the old, insecure behavior: inspect it, then `go test ./prompt/... -run TestGoldenThemes -update`.\n\n## Terminal output sanitization\n\n- `prompt.Engine.write` bypasses `terminal.write`'s per-rune control filter. Sanitize attacker-influenceable strings\n written in one shot (console title, OSC payloads) with `terminal.stripControlRunes`; `trimAnsi` misses ESC-less\n input (bare BEL) and CSI `! p`, APC, SOS, ST.\n- Don't extend `terminal.AnsiRegex`'s final-byte class (`!`, `_`, `X`, `\\` omitted on purpose) as a sanitization fix;\n strip control runes instead.\n\n## Segments and cache\n\n- Treat `mem.SwapMemory()` errors as returning a nil stat: gopsutil can fail reading `/proc/vmstat` on Android/Termux,\n so fall back to `VirtualMemoryStat.SwapTotal` and `SwapFree` instead of dereferencing the result.\n- Segment writers gob-encode only exported fields; `segments.Base.env/options` are unexported. On cache restore,\n overlay restored data onto the writer from `MapSegmentWithWriter`; never replace the writer.\n- `runtime/cmd.RunWithEnv` trims whitespace from the whole output, so a trailing empty field is lost. End records\n with a non-whitespace delimiter or sentinel and validate before assigning parsed state.\n- A blank prompt means a panic outside segment `Execute` and the streaming producer (both recover). A poisoned\n cache entry replays its failure every prompt until its TTL ends.\n- Caches persist only with the hidden `--save-cache` flag (print/stream); relocate with `OMP_CACHE_DIR`.\n- Logs are buffered and print only via `oh-my-posh debug` (grep `restored segment from cache`, `setting entry`);\n `POSH_TRACE=1` and stderr show nothing for print commands.\n- Windows: a fresh memory-mapped cache file logs a harmless `store.go:init EOF` on first read.\n\n## Streaming and serve daemon\n\n- `\"streaming\": ` also becomes every segment's pending timeout, overriding segment `timeout`.\n- `stream` emits the transient prompt as a `\\x1e`-prefixed NUL-terminated record (initial, and again once all\n segments resolve). Serve records are `\\x1f\\0`; a wait-mode request always yields exactly 2, even on\n segment panic (`renderComplete`), because Clink blocks on that count.\n- A timed-out segment keeps running after its cycle. On any path that can run then, publish through the\n `renderCache` captured at the top of `Execute`, never the global `template.Cache` (serve resets it per cycle,\n tests reassign it). `restoreCache`/`restoreData` still read the global (open race, 2026-09).\n- Don't gate `Execute`'s cache-hit early return on streaming: placeholders never show cached data, so skipping the\n cache only adds live probes that can time out.\n- Never touch `segment.writer` of a segment the cycle still has pending; pending segments render via\n `Segment.RenderPlaceholder` (config only). Don't add a `Pending` flag to `config.Segment`.\n- The event channel in `prompt/streaming.go` is sized `2*segments+1` so plain sends never block or drop; don't add\n `select`/`default`. The producer's `recover` must log a stack: a silent recover once hid a stuck-segment bug.\n- `prompt/streaming_writer_test.go`'s fake writer writes fields late on purpose, as race bait. `-race` only runs in\n CI ([release](release.md)).\n- Serve: process-lifetime initializers (`if X != nil return`) pin first-render state. Reset per render\n (`template.ResetCache()` in `startRenderCycle`); never nil a global that abandoned goroutines may still read.\n- Don't memoize the config in serve: the per-render gob decode gives each cycle its own segment graph, isolated from\n abandoned-cycle goroutines.\n- Daemon tests must vary per-request context (cwd, status) across cycles to catch one-shot state.\n- `config.Get` prefers the session gob cache over `POSH_THEME`.\n- Timing races: `oh-my-posh debug` timings are cold-process. Sweep the `streaming` value against a scripted serve\n session (JSON line + env blob on stdin) and count cycles whose last record still holds the placeholder.\n\n## Rendering and statusline\n\n- `template.Init` resets the parsed-template cache: calling it per benchmark iteration measures cold parse.\n- Stale website previews: a set `OMP_BIN` overrides the auto-rebuilt `src/bin` in `ensure-artifacts.mjs`.\n- Unix `terminal-dimensions` runs `stty size` on stdin, which is not a TTY under Claude Code's statusline. A valid\n `COLUMNS` fallback must clear the `stty` error, or `prompt.Engine.canWriteRightBlock` rejects right-aligned blocks.\n",".agents/skills/project-knowledge/references/fish.md":"# fish\n\nVerified on fish 4.1.2 (2026-07 to 2026-09).\n\n## Jobs, fifos, and lifecycle\n\n- fish does not fork a backgrounded function; it blocks the shell. Run readers as an external process:\n `fish --no-config -c $script args &`.\n- `jobs --last --pid` prints a \"Process\" header plus one pid per pipeline stage: filter with\n `string match --regex '^\\d+$'` and treat the result as a list.\n- Guard zero pids before `kill -0`: `kill -0 0` signals your own process group and always succeeds.\n- A fifo write with no reader blocks forever; liveness-check the reader before every write.\n- The serve daemon opens its request fifo O_RDWR, so it never sees EOF and a SIGKILLed fish orphans it. Teardown\n must go through the `fish_exit` handler.\n- `--on-signal SIGUSR1` handlers fire between commands in non-interactive scripts.\n- The streaming transient prompt lives in a tempfile (`$_omp_streaming_tempfile.transient`), not a variable,\n because `_omp_cleanup_stream` runs before the transient repaint.\n\n## Key bindings\n\n- `commandline --is-valid`: 0 valid, 1 erroneous, 2 incomplete. An empty buffer also returns 1, so check the buffer\n is non-empty before treating 1 as an error. A trailing backslash returns 0 (not a continuation).\n- A parse error from `commandline --function execute` inside a binding is attributed to the binding's file and\n function (#7862). Rethrow through a pristine parser instead:\n `commandline --current-buffer | string collect | $fish_bin --no-execute` (keeps the buffer and `$status`).\n- fish 4.x rejects command substitutions in command position (`(status fish-path) --no-execute`); assign to a\n variable (`set fish_bin (status fish-path)`) first.\n",".agents/skills/project-knowledge/references/pwsh.md":"# PowerShell (pwsh)\n\n## Engine events and runspaces (pwsh 7, 2026-07)\n\n- `Register-EngineEvent -Action` (e.g. `PowerShell.OnIdle`): `-MessageData` arrives as `$null`, and\n `.GetNewClosure()` captures are lost when the scriptblock is created in a module function. Pass state through a\n `$global:` variable (`$global:_ompStreamingState` in `omp.ps1`).\n- PSReadLine raises `PowerShell.OnIdle` every ~300-450ms, only while the input buffer is empty. Anything the user\n can trigger sooner (transient prompt on a fast Enter) must also drain synchronously at its call site.\n- PSEvents raised from a non-engine thread (e.g. `Register-ObjectEvent DataAdded` fed by a background runspace)\n can crash the host (`InvalidPipelineStateException`). Consume records only on the engine thread.\n- `Register-ObjectEvent` actions may or may not fire during a busy-wait. Never share a consume cursor between an\n event action and a synchronous waiter: give the waiter a private cursor and make the action idempotent.\n\n## PSReadLine prompt redraws (PSReadLine 2.4.5 / 2.3.6, 2026-09)\n\n- `InvokePrompt()` blanks `ExtraPromptLineCount + 1` rows before it calls the prompt function; a count set during\n that call only affects the next redraw. Padding the transient prompt cannot fix under-erasure.\n- `ExtraPromptLineCount` must count screen rows, including wrapping. The engine computes `terminal.CursorRow` and\n prefixes pwsh prompts with `ESC]7777;BEL`, which `Set-PoshExtraPromptLineCount` strips. Don't measure the\n prompt in PowerShell (`Measure-Object -Line` ignores wrapping and skips empty elements).\n- Overcounting is as bad: it erases the previous output line, or at the screen top `InvokePrompt` returns before\n calling the prompt (`newY < 0`), leaving `$script:TransientPrompt` set so the next primary renders as transient.\n Zero-width sequences such as the rprompt's `ESC 7`/`ESC 8` count 0 cells.\n- Match escape-prefixed strings with `-match '^\\u001b...'`, not `StartsWith`: culture-aware `StartsWith` ignores\n ESC, so `\"abc\".StartsWith(\"$([char]27)a\")` is `True`.\n- Redraw bugs only show when a line wraps; reproduce with the e2e `harness.MultiLine` overlay.\n\n## Exit lifecycle\n\n- pwsh cannot exit while a `[powershell]::Create()` pipeline thread runs (foreground threads). A reader blocked in\n `ReadByte()` on a child that exits only on stdin EOF deadlocks `exit` (#7643).\n- Module `OnRemove` never runs on a normal `exit`. Tear down a daemon in a `Register-EngineEvent PowerShell.Exiting`\n handler: write `quit`, close the child's stdin (the guaranteed EOF), kill after a short `WaitForExit`.\n\n## Performance (ARM64 Windows 11, 2026-07)\n\n- Process creation floor is ~70ms; any omp spawn costs ~100-130ms. For `omp.ps1` perf, count spawns per Enter\n first; cmdlet and module overhead is negligible.\n- `&` saves only ~10-17ms over the Process API and, under a CP437/1252 console, mangles UTF-8 output unless\n `[Console]::OutputEncoding = UTF8` is set once at init.\n- `Start-Sleep -Milliseconds 1` sleeps a ~15.6ms timer tick. Don't sleep-poll; signal a `ManualResetEventSlim`.\n\n## Testing\n\n- `New-Event -SourceIdentifier PowerShell.OnIdle` runs the real OnIdle action deterministically; its side effects can\n short-circuit later prompt calls.\n- Set module-scope flags from a test: `& (Get-Module oh-my-posh-core) { $script:X = $true }`.\n- Serve is gated to pwsh 6+ outside ConstrainedLanguage; pwsh 5.1 and ConstrainedLanguage keep the legacy path.\n- Exit-deadlock repro: `Start-Process pwsh -File test.ps1` + `WaitForExit(timeout)`; `findstr x` with redirected\n stdio stands in for a daemon.\n",".agents/skills/project-knowledge/references/release.md":"# Release, CI, and git\n\n## Release (`.github/workflows/release.yml`)\n\n- Releases are immutable: the workflow creates a draft and publishes last. Every asset must be in the draft before the\n publish step.\n\n## CI\n\n- `go test -race` does not work on the windows/arm64 dev machine or its WSL (no C compiler, no sudo). CI's\n `Race Detector` step (`code.yml`, ubuntu) is the only race gate.\n\n## Git on Windows\n\n- With `core.autocrlf=true`, `git rebase --autosquash` can stop on a plain `pick` with \"Your local changes would be\n overwritten\" and no real conflict (line-ending renormalization). Set `core.autocrlf false` for the rebase and\n restore it after; don't try to resolve a phantom conflict.\n",".agents/skills/project-knowledge/references/testing.md":"# Testing shells and terminals\n\n## Script edits\n\n- `src/shell/scripts/` is embedded at build time: rebuild the binary after every script edit, then inspect what\n users source with `oh-my-posh init --print`.\n- A script function is dead code unless `src/shell/.go` emits its activation line for the enabled feature.\n\n## e2e harness (`e2e/`, see `e2e/README.md`)\n\n- PSReadLine on a raw Unix pty floods `CSI 6n` and wedges without a reply (ConPTY answers it on Windows); the\n harness answers from the vt10x cursor (`harness/session.go`).\n- nu autoloads `$nu.vendor-autoload-dirs` after `--config`, so a real omp install clobbers the test prompt. Point\n `XDG_DATA_HOME` at an empty dir.\n- go-pty's Windows `Cmd` resolves bare names relative to `Cmd.Dir`; pass absolute binary paths.\n- On Windows, `bash` on PATH is System32's WSL launcher; `harness.LookupShellBinary` derives Git Bash from\n `git.exe`.\n\n## WSL\n\n- Run e2e from a Windows worktree: cross-compile (`GOOS=linux GOARCH=arm64 go build`), then in WSL\n `cd /mnt/c/.../e2e && OMP_E2E_BINARY=/mnt/c/.../oh-my-posh go test .`. If the distro's Go is too old for e2e's\n `go.mod`, unpack a go.dev tarball into `~/go-sdk`.\n- WSL `/tmp` is wiped between `wsl.exe` invocations: keep a test in one `wsl -e` call or stage under `$HOME`.\n- From Git Bash, prefix `MSYS_NO_PATHCONV=1` so `/mnt/c/...` arguments reach wsl.exe unmangled.\n\n## Getting a pty\n\n- `zsh -i` under plain `wsl -e` hangs (no foreground pty). Use `wsl -e script -qec 'zsh -i' /dev/null` for a real pty\n with job control, run backgrounded with output to a file, and poll a done-marker.\n- For keystrokes use `zmodload zsh/zpty`: `zpty omp zsh -i`, `zpty -w -n omp $'\\x03'` (real SIGINT), assert via\n state files, drain with `zpty -r`. `script(1)` does not work inside zpty.\n- `script(1)` quirks: bash prompt bytes are not relayed (probe `${PS1@P}` in-session); fish discards piped\n typeahead (assert via files written by event handlers); zsh works.\n- vi-mode probes must be mode-aware: after a normal-mode accept the next line starts in normal mode, so prefix `i`.\n A stray self-inserted `i` shows up as `last_status=127`.\n- To hold a render open, point an `http` segment with a large `http_timeout` at a silent local TCP listener; kill\n the listener to trigger the async update. There is no shell-command segment.\n\n## Protocol streams\n\n- One `bufio.Scanner` per pipe, ever; a second scanner loses buffered data.\n- Never treat wall-clock silence as \"records done\": cold-cache CI runs exceed any fixed gap. Wait for a record that\n proves the assertion (the cycle's transient record comes last) and keep a timeout only as a hang bound. Reproduce\n with `go clean -cache && go test -count=1 ./...`.\n\n## Windows Terminal and ConPTY\n\n- \"[process exited with code 0]\" at shell exit is Windows Terminal's own teardown message, never omp output.\n- Panes opened via `wt.exe ` never auto-close under `closeOnExit=automatic`; profile tabs do.\n- A headless conhost (Windows 11 build 26300) reports cursor 0,0, a blank buffer, and drops pty input: assert state,\n not row placement.\n- pywinpty's ConPTY EOF lags process death by ~5s (harness artifact, not a hang).\n- SendKeys into Windows Terminal drops keystrokes while the user works; a \"hung\" test may never have got `exit`.\n- `Set-Content -NoNewline` joins piped lines into one and corrupts scripts; write byte-exact files with Git Bash\n redirection.\n",".agents/skills/project-knowledge/references/zsh.md":"# zsh\n\n## zle\n\n- Every new editor invocation starts in keymap `main`; a `vicmd` selection does not carry into the next line.\n- `$?` after the transient prompt's `zle .send-break` is 1, native Ctrl+C gives 130 (TODO in `_omp_zle-line-init`).\n Don't fix one path without the other.\n- Ubuntu's `/etc/zsh/zshrc` defines a `zle-line-init`; never assume the widget slot is empty.\n- zsh-vi-mode always wraps omp's `zle-line-init` (it initializes lazily at first `precmd`), and our\n `.recursive-edit` swallows the session, so `_omp_zle-line-init` must call `zvm_zle-line-init` up front (guarded on\n `$+functions[zvm_zle-line-init]` and `ZVM_INIT_DONE`). Keep that call (#5992).\n- Keep `local rawfunc=` at the top of `_omp_zle-line-init`: `zvm_reset_prompt` resolves `$rawfunc` by dynamic\n scoping and would otherwise re-enter our widget.\n- Debug widget re-entry by logging `${funcstack[*]}` inside the widget.\n\n## Quoting\n\n- Quote every parameter expansion used as a command argument if its value can contain `[`, `?`, `*` or `#`. Under a\n user's `setopt GLOB_SUBST` it becomes a glob, and `BAD_PATTERN` aborts the widget (`$zle_bracketed_paste[1]` is\n `\\e[?2004h`, #7816).\n\n## coproc, fds, and signals\n\n- An interactive zsh with MONITOR prints `[n] pid` at coproc spawn; neither `disown` nor `2>/dev/null` stops it.\n `setopt localoptions no_monitor` does, and the child then inherits SIGINT/SIGQUIT ignored.\n- Duplicate coproc fds to session fds (`exec {out}<&p {in}>&p`) so they survive a later `coproc`; `disown %+` keeps\n the daemon out of `jobs` and the job-count segment.\n- A redirection-only `exec` applies every listed redirection permanently: `exec {fd}<&p 2>/dev/null` silences the\n session's stderr (#7653). Scope it: `{ exec ... } 2>/dev/null`.\n- Writing to a dead coproc raises SIGPIPE, which kills a non-interactive zsh. Guard writes with a `kill -0 $pid`\n check plus `setopt localoptions localtraps; trap '' PIPE`.\n- Never `kill -0` a possibly-zero pid: `kill -0 0` signals your own process group and always succeeds.\n- zsh 5.9 `read -r -u $fd -d $'\\0' -t N` ignores `-t` and blocks forever on a silent fd, so the serve path hangs\n in a non-interactive `zsh script.zsh`; test it in an interactive session.\n- Tear down in `zshexit_functions`; closing the fds (or the shell dying, even by SIGKILL) EOFs the daemon's stdin.\n",".agents/skills/segment-create/SKILL.md":"---\nname: segment-create\ndescription: >\n Checklist for adding a new Oh My Posh segment. Use when asked to add or create a new segment:\n lists every file to touch, the existing segment to copy, and how to verify.\n---\n\n## Template\n\nCopy `src/segments/taskwarrior.go` and `src/segments/taskwarrior_test.go`: two options, a\n`Template()`/`Enabled()` pair, and every shell call going through the mocked environment.\n\n- Embed `Base` first in the struct; its exported fields are the template properties.\n- Declare options as `options.Option` constants; read them with `s.options.String(...)`,\n `s.options.Bool(...)`, `s.options.KeyValueMap(...)` and so on, passing the default there.\n- Reach the OS, shell, files and network only through `s.env` so tests can mock it.\n- Override `Activation()` only for a cheap precondition such as a project file (see\n `src/segments/dvc.go`); `Base` defaults to always active.\n- Tests are table-driven: a `mock.Environment` from `src/runtime/mock`, options as an\n `options.Map`, then `Init(props, env)` and assertions on `Enabled()` and the exported fields.\n\n## Checklist\n\nKeep every list sorted alphabetically.\n\n1. `src/segments/.go` and `src/segments/_test.go`.\n1. `src/config/segment_types.go`: add the constant ` SegmentType = \"\"`.\n1. `src/config/segment_registry.go`: add `gob.Register(&segments.{})` to `init()` and\n `: func() SegmentWriter { return &segments.{} }` to `Segments`. A missing map\n entry fails silently at runtime: the segment never renders.\n1. `themes/schema.json`: add `` to `definitions.segment.properties.type.enum` and an\n `if`/`then` block to `definitions.segment.allOf` declaring every option. Copy the\n `taskwarrior` block; its `unevaluatedProperties: false` rejects undeclared options.\n1. `website/docs/segments//.mdx`, where category is one of agents, cli, cloud,\n health, languages, music, scm, system or web. Follow the `segment-docs` skill, and keep a\n `## What` paragraph: the segment catalog plugin reads it.\n1. `website/sidebars.js`: add `\"segments//\"` to that category's `items`.\n1. `website/segment_data.json`: add sample data under ``, shaped like the `taskwarrior` entry.\n1. `website/plugins/segments/registry.json`: generated. The first `go test ./config/...` run\n rewrites it and fails; rerun to confirm, then keep the file.\n1. Credentials needed? Add the doc id to `AUTH_TIERS` in `website/plugins/segments/data.js`.\n\n## Verify\n\nFrom `src/`:\n\n```shell\ngo test ./segments/... -run Test\ngo test ./config/...\n```\n\nRun `npm run build` in `website/` only when docs changed.\n",".agents/skills/segment-docs/SKILL.md":"---\nname: segment-docs\ndescription: >\n Reference mapping between Oh My Posh Go segment source code and MDX documentation.\n Use when creating, updating, or auditing segment documentation, or when reading\n segment Go code and needing to understand how code constructs map to user-facing\n options, template properties, and type representations in docs.\n---\n\n# Segment Documentation Reference\n\n## Go-to-Documentation Type Mapping\n\nWhen reading a segment's Go source to document its options, determine the type from the\n`Provider` method used to read the option value:\n\n| Go method call | Documentation type |\n| -------------- | :----------------: |\n| `options.Bool(option, default)` | `boolean` |\n| `options.String(option, default)` | `string` |\n| `options.StringArray(option, default)` | `[]string` |\n| `options.Int(option, default)` | `int` |\n| `options.Float64(option, default)` | `float64` |\n| `options.KeyValueMap(option, default)` | `map[string]string` |\n| `options.Color(option, default)` | `string` |\n| `options.Template(option, default, ctx)` | `string` |\n| `options.Any(option, default)` | `any` |\n\n## Extracting Options from Go Source\n\nOptions are declared as `options.Option` string constants in the segment's `const` block:\n\n```go\nconst (\n BranchIcon options.Option = \"branch_icon\" // option name used in config\n NativeStatus options.Option = \"native_status\"\n)\n```\n\nThe **option name** is the string literal value (e.g., `\"branch_icon\"`).\n\nThe **type** and **default value** come from the getter call in `Enabled()` or `init`-like methods:\n\n```go\ns.icon = s.options.String(BranchIcon, \"\\uE0A0\")\n// ^^^^^^ → string type, \"\\uE0A0\" → default\n```\n\n### Shared options\n\nThe following options are defined in `src/segments/options/map.go` and available to all\nsegments without appearing in a segment-specific `const` block:\n\n| Option name | Type | Default |\n| ----------- | ---- | ------- |\n| `always_enabled` | `boolean` | `false` |\n| `display_default` | `boolean` | `true` |\n| `display_error` | `boolean` | `true` |\n| `http_timeout` | `int` | `20` |\n| `cache_duration` | `int` | varies |\n| `access_token` | `string` | `\"\"` |\n| `refresh_token` | `string` | `\"\"` |\n| `version_url_template` | `string` | `\"\"` |\n| `files` | `[]string` | varies |\n\n## Extracting Template Properties from Go Source\n\nTemplate properties are values available inside the segment's `template` string.\n\n**Rules for what becomes a template property:**\n\n- **Exported struct fields** (capitalized) on the segment struct → `.FieldName`\n- **Unexported fields** are not accessible in templates\n- **Nested struct fields** use dot notation: a field `Working ScmStatus` exposes\n `.Working.Modified`, `.Working.Added`, etc.\n- **Zero-argument methods** with a single return value → `.MethodName`\n- **Document fields that are assigned** in `Enabled()` or its callees,\n not every inherited field from embedded structs is populated by every segment\n\nThe default template comes from the `Template()` method:\n\n```go\nfunc (s *MySegment) Template() string {\n return \" {{ .FieldName }} \"\n}\n```\n\n### Nested struct subsection convention\n\nWhen a property's type is itself a struct, add an `#### TypeName` subsection within\nthe Properties table section listing its exported fields. Example:\n\n```mdx\n#### Status\n\n| Name | Type | Description |\n| ---- | ---- | ----------- |\n| `.Modified` | `int` | Number of modified files |\n| `.Added` | `int` | Number of added files |\n| `.Deleted` | `int` | Number of deleted files |\n| `.Untracked` | `int` | Number of untracked files |\n| `.Changed` | `boolean` | Whether any changes exist |\n```\n\n## Key Source Files for Inherited Fields\n\nWhen a segment embeds a base struct, its inherited fields may also be template properties.\nCheck these files to discover what fields are available:\n\n| File | What it defines |\n| ---- | --------------- |\n| `src/segments/options/map.go` | `Provider` interface method signatures; shared `Option` constants |\n| `src/segments/base.go` | `Base` struct embedded by all segments; provides `options`, `env` |\n| `src/segments/scm.go` | `ScmStatus` type with working/staging status fields (git, mercurial, etc.) |\n| `src/segments/language.go` | `Version` type and language base fields (Python, Node, Go, etc.) |\n",".github/copilot-instructions.md":"# GitHub Copilot Instructions\n\nAll agent guidance for this repository lives in [AGENTS.md](../AGENTS.md): project overview,\nkey commands, architecture orientation, coding and commit conventions, skills, and the\nproject-knowledge workflow. Follow it in full.\n","AGENTS.md":"# Agent Instructions\n\nOh My Posh is a cross-shell prompt theme engine written in Go, with the module root in `src/`. Rendering runs on every\nshell prompt, so it is a hot path: no extra process spawns, network calls, or file reads per render without\n`src/cache`.\n\n## Non-negotiables\n\nCorrections in past sessions keep landing on these. Check each one before you report a change as done.\n\n1. **Reuse before building.** Find how the codebase already solves the problem before designing anything: a similar\n segment, an `Environment` method, `src/cache`, or a CLI call behind an option like other segments use. Never add a\n dependency without asking. Remove deprecated logic instead of maintaining it.\n2. **Go through `runtime.Environment`** (`s.env` in segments) for every OS, shell, file, and command call, so tests can\n mock it. Check its methods before reaching for `os`, `os/exec`, or `path/filepath`.\n3. **Tests prove behavior, not the patch.** A test must fail when the behavior breaks and survive a correct refactor.\n Write them table-driven; the `golang` skill has the rules.\n4. **No `else`.** Use guard clauses, early returns, or a `switch`. The Stop hook blocks new `else` branches.\n5. **Comments explain a why the code cannot.** Never restate a name or signature, exported symbols included, in any\n language. Default to no comment.\n6. **Log with `src/log`:** `log.Error(err)` where the error occurs, and `defer log.Trace(time.Now(), args...)` in\n functions worth tracing. Do not format errors yourself.\n7. **Commit only when asked, push only when asked.** Fold every fix to a commit that is not on `main` into that commit\n with `git commit --fixup ` and `git rebase --autosquash`, lint and CI fallout included. Never rewrite `main`.\n\n## Repository map\n\n| Path | Purpose |\n| ----------------------------- | ---------------------------------------------------------------------------- |\n| `src/segments/` | One `.go` and one `_test.go` per segment |\n| `src/config/` | Segment registry; an unregistered segment fails silently at runtime |\n| `src/prompt/` | Rendering engine |\n| `src/runtime/` | `Environment` abstraction and its mock |\n| `src/cache/` | TTL, file, and command-path caching; do not build another cache |\n| `src/cli/` | CLI commands on `src/cmdtree`, registered in `root.go` |\n| `src/shell/` | `oh-my-posh init `; `scripts/` are embedded, so rebuild after editing |\n| `themes/` | Bundled themes, validated against `themes/schema.json` |\n| `website/` | Docusaurus docs; segment pages live in `website/docs/segments//` |\n\nA shell integration change usually spans `src/shell/.go` and its script in `src/shell/scripts/`.\n\n## Commands\n\n```bash\n# from src/\ngo test ./...\ngolangci-lint run\n\n# from website/\nnpm run build # before a docs pull request\n```\n\nThe Stop hook (`.agents/hooks/main.go`) formats the changed files, runs `modernize`, `fieldalignment`, `golangci-lint`,\n`go test`, `markdownlint`, and the `else` check, and builds, lints, and analyzes platform-specific code for the other\noperating systems. Fix what it reports; never run `fieldalignment -fix`. `.claude/settings.json` and\n`.github/hooks/quality.json` both wire it, so change them together.\n\n## Docs\n\nDocs pages have no H1, because the front-matter `title` renders as the heading; use only H2 and H3. Wrap lines at 120\ncharacters. Use the `segment-create` skill for a new segment and `segment-docs` for its documentation.\n\n## Project knowledge\n\nBefore touching shell scripts, terminal or pty behavior, WSL-based testing, engine internals, or release and CI work,\nread the matching file in the `project-knowledge` skill. When a session uncovers a verified, actionable gotcha, append\nit to that file and commit it with the related change.\n\n## Pull request reviews\n\nValidate every comment against the code. Fold each fix into the commit that introduced the code with a fixup and\n`git rebase --autosquash`, then force-push the pull request branch with `--force-with-lease`. Reply to every thread\nwith the conclusion and the commit, then resolve it.\n","packages/msix/README.md":"# MSIX Package\n\n## Prerequisites\n\n- [Windows SDK] (provides `makeappx.exe` and `signtool.exe`)\n\n## Build the package\n\nThis guide assumes and advises the use of PowerShell as your shell environment for this purpose.\n\nPlace the executable to package at `./dist/oh-my-posh.exe`, or use `-Copy` to take it from\nthe repository's `dist` folder.\n\n```powershell\n./build.ps1 -Architecture x64 -Version \"1.3.37\"\n```\n\nThe package is created at `out/install-x64.msix`, along with an App Installer\nfile at `out/install-x64.appinstaller`. The App Installer configuration is also\nembedded in the MSIX, so installing the MSIX enables automatic updates on\nsupported Windows versions.\n\n## Install the package\n\n```powershell\nAdd-AppxPackage -Path ./out/install-x64.msix\n```\n\n[Windows SDK]: https://developer.microsoft.com/en-us/windows/downloads/windows-sdk/\n","website/static/skill.md":"---\nname: oh-my-posh\ndescription: Install, configure, or troubleshoot Oh My Posh/ohmyposh: shell init, themes, segments, Nerd Font icons, and prompt setup on PowerShell, zsh, bash, or fish.\n---\n\n# Oh My Posh\n\n> Oh My Posh is a cross-shell, cross-platform prompt theme engine for Windows, macOS, and Linux.\n> It renders beautifully themed prompts with Git status, language versions, cloud context,\n> and more — 120 segments in all.\n\nFull skill (folder-based, with per-OS and per-shell guides):\n[/skills/ohmyposh/SKILL.md](/skills/ohmyposh/SKILL.md)\n\n## Quick links\n\n- [Installation — Windows](/skills/ohmyposh/installation/windows.md)\n- [Installation — macOS](/skills/ohmyposh/installation/macos.md)\n- [Installation — Linux](/skills/ohmyposh/installation/linux.md)\n- [Shell setup — PowerShell](/skills/ohmyposh/shell/powershell.md)\n- [Shell setup — Bash](/skills/ohmyposh/shell/bash.md)\n- [Shell setup — Zsh](/skills/ohmyposh/shell/zsh.md)\n- [Shell setup — Fish](/skills/ohmyposh/shell/fish.md)\n- [Shell setup — Nu](/skills/ohmyposh/shell/nu.md)\n- [Shell setup — Cmd](/skills/ohmyposh/shell/cmd.md)\n- [Shell setup — Elvish](/skills/ohmyposh/shell/elvish.md)\n- [Shell setup — Xonsh](/skills/ohmyposh/shell/xonsh.md)\n- [Configuration & themes](/skills/ohmyposh/configuration.md)\n","website/static/skills/ohmyposh/SKILL.md":"---\nname: oh-my-posh\ndescription: \"Install, configure, or troubleshoot Oh My Posh/ohmyposh: shell init, themes, segments, Nerd Font icons, and prompt setup on PowerShell, zsh, bash, or fish.\"\n---\n\n# Oh My Posh\n\n> Oh My Posh is a cross-shell, cross-platform prompt theme engine. It displays Git status,\n> language versions, cloud context, system metrics and more in a beautifully themed\n> terminal prompt — 120 segments in all.\n\n## How to use this skill\n\n1. **Identify the user's OS** → follow the matching installation guide:\n - [Windows installation](/skills/ohmyposh/installation/windows.md)\n - [macOS installation](/skills/ohmyposh/installation/macos.md)\n - [Linux installation](/skills/ohmyposh/installation/linux.md)\n\n2. **Identify the user's shell** → follow the matching shell setup guide:\n - [PowerShell](/skills/ohmyposh/shell/powershell.md)\n - [Bash](/skills/ohmyposh/shell/bash.md)\n - [Zsh](/skills/ohmyposh/shell/zsh.md)\n - [Fish](/skills/ohmyposh/shell/fish.md)\n - [Nu / Nushell](/skills/ohmyposh/shell/nu.md)\n - [Cmd (via Clink)](/skills/ohmyposh/shell/cmd.md)\n - [Elvish](/skills/ohmyposh/shell/elvish.md)\n - [Xonsh](/skills/ohmyposh/shell/xonsh.md)\n - [Yash](/skills/ohmyposh/shell/yash.md)\n\n3. **Install a Nerd Font** — required for icons and glyphs:\n\n ```bash\n oh-my-posh font install meslo\n ```\n\n `oh-my-posh font list` prints every installable font. Recommended: **Meslo LGM NF**.\n Set it in the terminal emulator's font settings after installing.\n\n4. **Customize the prompt** → see [configuration](/skills/ohmyposh/configuration.md)\n\n## Detect the current shell\n\nIf the user is unsure which shell they are using (requires oh-my-posh to be installed first):\n\n```bash\noh-my-posh get shell\n```\n\n## Troubleshooting\n\n- **Icons show as boxes** — install a Nerd Font and set it in the terminal emulator.\n- **`oh-my-posh` not found after install** — restart the terminal or add the install path to `$PATH`.\n- **Slow prompt** -- enable async rendering by setting `\"async\": true` at the top level of your config.\n\nFull documentation: \nFAQ: \n","website/static/skills/ohmyposh/configuration.md":"# Oh My Posh — Configuration & Customization\n\n## Apply a theme\n\nPass `--config` to the init command with a theme name, local path, or remote URL.\n\n**By theme name** (no extension needed):\n\n```powershell\n# PowerShell\noh-my-posh init pwsh --config 'jandedobbeleer' | Invoke-Expression\n```\n\n```bash\n# Bash / Zsh\neval \"$(oh-my-posh init bash --config jandedobbeleer)\"\n```\n\n**By local file path:**\n\n```powershell\n# PowerShell\noh-my-posh init pwsh --config 'C:\\Users\\\\.mytheme.omp.json' | Invoke-Expression\n```\n\n```bash\n# Bash / Zsh\neval \"$(oh-my-posh init bash --config ~/.mytheme.omp.json)\"\n```\n\n**By remote URL:**\n\n```powershell\noh-my-posh init pwsh --config 'https://raw.githubusercontent.com/JanDeDobbeleer/oh-my-posh/main/themes/jandedobbeleer.omp.json' | Invoke-Expression\n```\n\n> Using a remote URL adds a network dependency. Oh My Posh caches remote configs using ETags,\n> but latency still applies on cache misses. For reliable offline use, copy the theme to a\n> local file and use a local path instead.\n\n## Browse available themes\n\nView all bundled themes online: \n\n> There is no terminal command to preview all available themes. Direct users to the website above.\n\n## Debug the current theme\n\nTo render your active prompt in debug mode (shows segment timing and values):\n\n```bash\noh-my-posh debug\n```\n\n## Export a theme for editing\n\n```bash\noh-my-posh config export --config jandedobbeleer --output ~/.mytheme.omp.json\n```\n\nThen set `--config ~/.mytheme.omp.json` in your init line and edit the file to taste.\n\n## WSL tip\n\nInside WSL you can share a theme stored in your Windows home folder:\n\n```bash\neval \"$(oh-my-posh init bash --config /mnt/c/Users//mytheme.omp.json)\"\n```\n\n## Live reload during editing\n\nEnable live reload so prompt changes appear without restarting the shell:\n\n```bash\noh-my-posh enable reload\n```\n\nDisable:\n\n```bash\noh-my-posh disable reload\n```\n\nPreview every configured prompt without restarting:\n\n```bash\noh-my-posh print preview\n```\n\nForce-render all segments regardless of context:\n\n```bash\noh-my-posh print preview --force\n```\n\n## Validate a config or segment via MCP\n\nWhen creating or editing a segment manually, use the oh-my-posh MCP server to validate the\nconfig or a segment snippet for schema errors. Agents can call:\n\n```bash\ncurl -X POST https://ohmyposh.dev/api/mcp \\\n -H \"Content-Type: application/json\" \\\n -d '{\n \"jsonrpc\": \"2.0\",\n \"method\": \"tools/call\",\n \"params\": {\n \"name\": \"validate_config\",\n \"arguments\": {\"content\": \"\", \"format\": \"auto\"}\n },\n \"id\": 1\n }'\n```\n\nOr use `validate_segment` to check a single segment snippet instead of an entire config.\n\n## Configuration reference\n\n- Full schema: \n- Docs: \n- Segments: \n","website/static/skills/ohmyposh/installation/linux.md":"# Oh My Posh — Linux Installation\n\n> **Prerequisites:** `curl`, `unzip`, `realpath`, and `dirname` must be available.\n> Make sure `curl` and the client certificate store are up to date.\n\n## Install\n\n```bash\ncurl -s https://ohmyposh.dev/install.sh | bash -s\n```\n\nBy default this installs to `~/bin` or `~/.local/bin` (whichever exists), or to the directory\nof any existing `oh-my-posh` binary. To install to a custom location:\n\n```bash\ncurl -s https://ohmyposh.dev/install.sh | bash -s -- -d ~/bin\n```\n\n## Update\n\nRe-run the install script — it replaces the existing binary in-place.\n\n## After installing\n\nRestart the terminal (or open a new window) so `oh-my-posh` is on `$PATH`, then proceed to the\n[shell setup guide](/skills/ohmyposh/SKILL.md).\n","website/static/skills/ohmyposh/installation/macos.md":"# Oh My Posh — macOS Installation\n\n> **Note:** The standard macOS Terminal only supports 256 colors. Use [iTerm2](https://iterm2.com)\n> or another modern terminal for full ANSI color and icon support.\n\n## Install\n\n**Recommended (Homebrew):**\n\n```bash\nbrew install jandedobbeleer/oh-my-posh/oh-my-posh\n```\n\n**MacPorts** (community-maintained):\n\n```bash\nsudo port selfupdate\nsudo port install oh-my-posh\n```\n\n## Update\n\n```bash\nbrew upgrade oh-my-posh\n```\n\n## After installing\n\nRestart the terminal (or open a new window) so `oh-my-posh` is on `$PATH`, then proceed to the\n[shell setup guide](/skills/ohmyposh/SKILL.md).\n","website/static/skills/ohmyposh/installation/windows.md":"# Oh My Posh — Windows Installation\n\n## Install\n\n**Recommended (winget):**\n\n```powershell\nwinget install JanDeDobbeleer.OhMyPosh --source winget\n```\n\n**Manual (PowerShell):**\n\n```powershell\nSet-ExecutionPolicy Bypass -Scope Process -Force; Invoke-Expression ((New-Object System.Net.WebClient).DownloadString('https://ohmyposh.dev/install.ps1'))\n```\n\n**Chocolatey:**\n\n```powershell\nchoco install oh-my-posh\n```\n\n## Update\n\n```powershell\nwinget upgrade JanDeDobbeleer.OhMyPosh --source winget\n```\n\n## After installing\n\nRestart the terminal (or open a new window) so `oh-my-posh` is on `$PATH`, then proceed to the\n[shell setup guide](/skills/ohmyposh/SKILL.md).\n\n> **Tip:** When using Oh My Posh inside WSL, follow the\n> [Linux installation](/skills/ohmyposh/installation/linux.md) guide inside WSL instead.\n","website/static/skills/ohmyposh/shell/bash.md":"# Oh My Posh — Bash Setup\n\n## Configure\n\nAdd this as the **last line** of `~/.bashrc` (or `~/.profile` / `~/.bash_profile` depending on\nyour environment):\n\n```bash\neval \"$(oh-my-posh init bash)\"\n```\n\nReload:\n\n```bash\nexec bash\n```\n\nOr, if using `~/.profile`:\n\n```bash\n. ~/.profile\n```\n\n## Next step\n\n→ [Customize your prompt](/skills/ohmyposh/configuration.md)\n","website/static/skills/ohmyposh/shell/cmd.md":"# Oh My Posh — Cmd Setup (via Clink)\n\nCmd does not support custom prompts natively. [Clink](https://chrisant996.github.io/clink/)\nadds that capability and also enhances Cmd with readline-style editing.\n\n## Prerequisites\n\nInstall Clink and enable autostart. Find the Clink scripts directory:\n\n```bash\nclink info\n```\n\n## Configure\n\nCreate a file called `oh-my-posh.lua` in the Clink scripts directory:\n\n```lua\nload(io.popen('oh-my-posh init cmd'):read(\"*a\"))()\n```\n\nRestart Cmd to apply.\n\n> **Tip:** Clink has built-in support for Oh My Posh. You can also set the prompt with:\n>\n> ```bash\n> clink config prompt use oh-my-posh\n> ```\n\n## Next step\n\n→ [Customize your prompt](/skills/ohmyposh/configuration.md)\n","website/static/skills/ohmyposh/shell/elvish.md":"# Oh My Posh — Elvish Setup\n\n## Configure\n\nAdd this as the **last line** of `~/.elvish/rc.elv`:\n\n```bash\neval (oh-my-posh init elvish)\n```\n\nReload:\n\n```bash\nexec elvish\n```\n\n## Next step\n\n→ [Customize your prompt](/skills/ohmyposh/configuration.md)\n","website/static/skills/ohmyposh/shell/fish.md":"# Oh My Posh — Fish Setup\n\n> **Requires Fish 4.1.0 or later.** Older versions have issues and do not support\n> transient prompt.\n\n## Configure\n\nAdd this as the **last line** of `~/.config/fish/config.fish`:\n\n```bash\noh-my-posh init fish | source\n```\n\nReload:\n\n```bash\nexec fish\n```\n\n## Next step\n\n→ [Customize your prompt](/skills/ohmyposh/configuration.md)\n","website/static/skills/ohmyposh/shell/nu.md":"# Oh My Posh — Nu / Nushell Setup\n\n> **Requires Nushell v0.104.0 or later.**\n\n## Configure\n\nAdd this as the **last line** of the Nushell config file (path: `$nu.config-path`):\n\n```bash\noh-my-posh init nu\n```\n\nRestart Nushell to apply.\n\n## Next step\n\n→ [Customize your prompt](/skills/ohmyposh/configuration.md)\n","website/static/skills/ohmyposh/shell/powershell.md":"# Oh My Posh — PowerShell Setup\n\n## Configure\n\nEdit your PowerShell profile. Find its path:\n\n```powershell\n$PROFILE\n```\n\nOpen it (create it if it doesn't exist):\n\n```powershell\nnotepad $PROFILE\n# or: New-Item -Path $PROFILE -Type File -Force\n```\n\nAdd this as the **last line**:\n\n```powershell\noh-my-posh init pwsh | Invoke-Expression\n```\n\nReload the profile:\n\n```powershell\n. $PROFILE\n```\n\n## Troubleshooting\n\n**Execution policy blocks scripts:**\n\n```powershell\nSet-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope LocalMachine\n```\n\nOr use the `--eval` flag (slightly slower startup):\n\n```powershell\noh-my-posh init pwsh --eval | Invoke-Expression\n```\n\n## Next step\n\n→ [Customize your prompt](/skills/ohmyposh/configuration.md)\n","website/static/skills/ohmyposh/shell/xonsh.md":"# Oh My Posh — Xonsh Setup\n\n## Configure\n\nAdd this as the **last line** of `~/.xonshrc`:\n\n```bash\nexecx($(oh-my-posh init xonsh))\n```\n\nReload:\n\n```bash\nexec xonsh\n```\n\n## Next step\n\n→ [Customize your prompt](/skills/ohmyposh/configuration.md)\n","website/static/skills/ohmyposh/shell/yash.md":"# Oh My Posh — Yash Setup\n\n## Configure\n\nAdd this as the **last line** of `~/.yashrc`:\n\n```bash\neval \"$(oh-my-posh init yash)\"\n```\n\nReload:\n\n```bash\nexec yash\n```\n\n## Notes\n\n- Requires a yash version that supports `$PROMPT_COMMAND` (>= 2.39) and `$POST_PROMPT_COMMAND`\n (>= 2.52) for full functionality; oh-my-posh hooks into both to time commands and draw the prompt.\n- The prompt is rendered through `YASH_PS1` (and `YASH_PS1R` for the right prompt), which take\n precedence over `PS1`/`PS2` in yash.\n- Right prompt support is native via `YASH_PS1R`.\n- Transient prompt and tooltips are not supported in yash.\n\n## Next step\n\n→ [Customize your prompt](/skills/ohmyposh/configuration.md)\n","website/static/skills/ohmyposh/shell/zsh.md":"# Oh My Posh — Zsh Setup\n\n## Configure\n\nAdd this as the **last line** of `~/.zshrc`:\n\n```bash\neval \"$(oh-my-posh init zsh)\"\n```\n\nReload:\n\n```bash\nexec zsh\n```\n\n## macOS Terminal workaround\n\nThe standard macOS Terminal has issues with ANSI characters. To skip Oh My Posh there while\nkeeping it in iTerm2 and other modern terminals:\n\n```bash\nif [ \"$TERM_PROGRAM\" != \"Apple_Terminal\" ]; then\n eval \"$(oh-my-posh init zsh)\"\nfi\n```\n\n## Next step\n\n→ [Customize your prompt](/skills/ohmyposh/configuration.md)\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/JanDeDobbeleer/oh-my-posh/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# Agent Instructions\n\nOh My Posh is a cross-shell prompt theme engine written in Go, with the module root in `src/`. Rendering runs on every\nshell prompt, so it is a hot path: no extra process spawns, network calls, or file reads per render without\n`src/cache`.\n\n## Non-negotiables\n\nCorrections in past sessions keep landing on these. Check each one before you report a change as done.\n\n1. **Reuse before building.** Find how the codebase already solves the problem before designing anything: a similar\n segment, an `Environment` method, `src/cache`, or a CLI call behind an option like other segments use. Never add a\n dependency without asking. Remove deprecated logic instead of maintaining it.\n2. **Go through `runtime.Environment`** (`s.env` in segments) for every OS, shell, file, and command call, so tests can\n mock it. Check its methods before reaching for `os`, `os/exec`, or `path/filepath`.\n3. **Tests prove behavior, not the patch.** A test must fail when the behavior breaks and survive a correct refactor.\n Write them table-driven; the `golang` skill has the rules.\n4. **No `else`.** Use guard clauses, early returns, or a `switch`. The Stop hook blocks new `else` branches.\n5. **Comments explain a why the code cannot.** Never restate a name or signature, exported symbols included, in any\n language. Default to no comment.\n6. **Log with `src/log`:** `log.Error(err)` where the error occurs, and `defer log.Trace(time.Now(), args...)` in\n functions worth tracing. Do not format errors yourself.\n7. **Commit only when asked, push only when asked.** Fold every fix to a commit that is not on `main` into that commit\n with `git commit --fixup ` and `git rebase --autosquash`, lint and CI fallout included. Never rewrite `main`.\n\n## Repository map\n\n| Path | Purpose |\n| ----------------------------- | ---------------------------------------------------------------------------- |\n| `src/segments/` | One `.go` and one `_test.go` per segment |\n| `src/config/` | Segment registry; an unregistered segment fails silently at runtime |\n| `src/prompt/` | Rendering engine |\n| `src/runtime/` | `Environment` abstraction and its mock |\n| `src/cache/` | TTL, file, and command-path caching; do not build another cache |\n| `src/cli/` | CLI commands on `src/cmdtree`, registered in `root.go` |\n| `src/shell/` | `oh-my-posh init `; `scripts/` are embedded, so rebuild after editing |\n| `themes/` | Bundled themes, validated against `themes/schema.json` |\n| `website/` | Docusaurus docs; segment pages live in `website/docs/segments//` |\n\nA shell integration change usually spans `src/shell/.go` and its script in `src/shell/scripts/`.\n\n## Commands\n\n```bash\n# from src/\ngo test ./...\ngolangci-lint run\n\n# from website/\nnpm run build # before a docs pull request\n```\n\nThe Stop hook (`.agents/hooks/main.go`) formats the changed files, runs `modernize`, `fieldalignment`, `golangci-lint`,\n`go test`, `markdownlint`, and the `else` check, and builds, lints, and analyzes platform-specific code for the other\noperating systems. Fix what it reports; never run `fieldalignment -fix`. `.claude/settings.json` and\n`.github/hooks/quality.json` both wire it, so change them together.\n\n## Docs\n\nDocs pages have no H1, because the front-matter `title` renders as the heading; use only H2 and H3. Wrap lines at 120\ncharacters. Use the `segment-create` skill for a new segment and `segment-docs` for its documentation.\n\n## Project knowledge\n\nBefore touching shell scripts, terminal or pty behavior, WSL-based testing, engine internals, or release and CI work,\nread the matching file in the `project-knowledge` skill. When a session uncovers a verified, actionable gotcha, append\nit to that file and commit it with the related change.\n\n## Pull request reviews\n\nValidate every comment against the code. Fold each fix into the commit that introduced the code with a fixup and\n`git rebase --autosquash`, then force-push the pull request branch with `--force-with-lease`. Reply to every thread\nwith the conclusion and the commit, then resolve it.\n","isInternal":false,"tokens":1004,"sizeBytes":4523},{"name":"copilot-instructions.md","path":".github/copilot-instructions.md","rawUrl":"https://raw.githubusercontent.com/JanDeDobbeleer/oh-my-posh/HEAD/.github/copilot-instructions.md","title":"GitHub Copilot Instructions","category":"copilot-instructions","format":"markdown","content":"# GitHub Copilot Instructions\n\nAll agent guidance for this repository lives in [AGENTS.md](../AGENTS.md): project overview,\nkey commands, architecture orientation, coding and commit conventions, skills, and the\nproject-knowledge workflow. Follow it in full.\n","isInternal":false,"tokens":53,"sizeBytes":258},{"name":"SKILL.md","path":".agents/skills/code-changes/SKILL.md","rawUrl":"https://raw.githubusercontent.com/JanDeDobbeleer/oh-my-posh/HEAD/.agents/skills/code-changes/SKILL.md","title":"code-changes","category":"anthropic-skill","format":"markdown","content":"---\nname: code-changes\ndescription: >\n Workflow for any task that ends in code changes: issue analysis or triage, pull request review comments, features,\n bug fixes, refactors. Invoke at the start of such a task, before reading or writing code.\n---\n\n# Code changes\n\n## 1. Analyze, then stop\n\n- Read the code, not only the issue, review comment, or stack trace: reports and bot reviewers are often wrong. Fetch\n context with `gh issue view --comments` or `gh pr view --comments`.\n- Reproduce the problem when possible; say so when you cannot.\n- Look for what already exists before designing anything: a helper, a similar module, a pattern another feature uses,\n a CLI to call instead of reimplementing it. Prefer the smallest change that reuses existing code, and the change that\n removes code over the one that adds it. Deprecated logic gets removed, not maintained.\n- Report the root cause with file references, the proposed change and its scope, what stays out of scope, and open\n questions.\n- **Stop and wait for a go.** Skip the stop only when the request already asks for the implementation (\"fix it\",\n \"do it\"). A go for analysis is not a go for implementation, and a new diagnosis after a failed verification needs a\n new go.\n\nFor triage only (\"look at #n\"), the report is the deliverable: add the blast radius and a suggested reply to the issue.\n\n## 2. Plan\n\n- Load the language and format skills for every file you will touch before writing any code, and follow them from the\n first line. A rule read at review time turns a violation into rework.\n- When replacing working code, list what the old code does (defaults, key bindings, error messages) and keep all of it.\n Dropping any of it needs a go first.\n- For a judgment call you cannot make with confidence (unclear root cause, security, irreversible change), ask the\n strongest available model that one question, then continue.\n\n## 3. Implement\n\n- Do standard work yourself. Delegate only independent tasks that can run in parallel (one worktree each) or\n mechanical batches for a cheaper model.\n- A delegation carries the decided approach, the files, the binding skill rules, the verification commands, the\n non-goals, and the instruction to stop and report anything the spec does not cover.\n- Never delegate analysis, final verification, commits, or pushes.\n\n## 4. Review the diff\n\nReview every diff as an external pull request, your own included:\n\n- Everything asked for, nothing more. Replace overbuilt solutions with simpler ones.\n- Consistency with the surrounding code beats a new pattern.\n- Cut tests that assert implementation details, copy data declared elsewhere in the diff, duplicate another test, or\n would still pass with the bug present.\n- Delete comments that restate the code.\n\n## 5. Verify\n\n- Build, tests, formatters, and linters pass with zero findings. Never weaken a gate or delete a test to get there.\n- Prove it works: run the real flow the way the user reaches it (the built binary, a cold start) and record the actual\n output.\n- Update documentation in the same change as the behavior it describes.\n- After two failed verification rounds on the same task, stop and report instead of trying a third time.\n\n## 6. Deliver\n\n- Commit only when the user asks for it. Push or open a pull request only when asked; push a rewritten branch with\n `--force-with-lease`.\n- Write messages with the `conventional-commit` skill. One logical change per commit; stage files explicitly.\n- Fold a fix to a commit that is not on the default branch into that commit: `git commit --fixup `, then\n `git rebase --autosquash`. That includes lint, test, and CI fallout. Never stack \"fix\" commits on top.\n- Report the outcome first: what changed and why, the verification evidence, what is left for the user, and anything\n removed.\n\n## Pull request review comments\n\n1. Fetch every unresolved thread and validate each against the code. Treat bot comments as leads, not verdicts.\n2. Valid: fix it as a fixup into the commit that introduced the code, autosquash, verify, and force-push the pull\n request branch.\n3. Invalid: do not change code to appease it. Reply with the evidence. When the misreading exposes confusing code,\n clarify the code and say so.\n4. Reply to every thread with the conclusion and the commit that addresses it, then resolve the thread.\n","frontmatter":{"name":"code-changes","description":"Workflow for any task that ends in code changes: issue analysis or triage, pull request review comments, features, bug fixes, refactors. Invoke at the start of such a task, before reading or writing code.\n"},"isInternal":false,"tokens":986,"sizeBytes":4354},{"name":"SKILL.md","path":".agents/skills/conventional-commit/SKILL.md","rawUrl":"https://raw.githubusercontent.com/JanDeDobbeleer/oh-my-posh/HEAD/.agents/skills/conventional-commit/SKILL.md","title":"conventional-commit","category":"anthropic-skill","format":"markdown","content":"---\nname: conventional-commit\ndescription: >\n Rules for writing Conventional Commits messages in this project. MUST be invoked every time a\n commit is created.\ntriggers:\n - on_commit\n---\n\n# Conventional commit\n\n`.commitlintrc.yml` is the source of truth: use only the types it allows. Beyond the\nspecification:\n\n- Keep the header (`type(scope): description`) at 72 characters or fewer.\n- Write the description in the imperative, without a trailing period: `add`, `fix`, `bump`. Never\n copy past tense from the request (`added`, `fixed`, `bumped`).\n- Use the affected area as the scope (`segment`, `cache`, `config`); omit it for cross-cutting\n changes.\n- A change that removes, renames, or alters behavior callers depend on carries both `!` after the\n type or scope and a `BREAKING CHANGE:` footer. Never one without the other.\n- Use the body for why, not what, wrapped at 72 characters.\n- Review `git diff --cached` and stage files explicitly; never `git add -A`.\n\n```text\nfeat(segment)!: rename template property StartTime to Start\n\nBREAKING CHANGE: template strings using .StartTime must be updated to .Start\n```\n","frontmatter":{"name":"conventional-commit","description":"Rules for writing Conventional Commits messages in this project. MUST be invoked every time a commit is created.\n","triggers":["on_commit"]},"isInternal":false,"tokens":272,"sizeBytes":1122},{"name":"SKILL.md","path":".agents/skills/golang/SKILL.md","rawUrl":"https://raw.githubusercontent.com/JanDeDobbeleer/oh-my-posh/HEAD/.agents/skills/golang/SKILL.md","title":"golang","category":"anthropic-skill","format":"markdown","content":"---\nname: golang\ndescription: >\n Go conventions for this project that differ from common Go practice. Apply when writing,\n reviewing, or refactoring any Go source or test file.\ntriggers:\n - on_commit\n---\n\n# Go conventions\n\nStandard idiomatic Go applies. These are the rules that differ or that agents keep breaking.\n\n## Code\n\n- Never use `else`, in tests too. Return early, `continue`, `break`, or use a `switch`.\n- Comments explain a why the code cannot express: a hidden constraint, a workaround, a surprising\n invariant. No doc comments that restate a name or signature, exported symbols included.\n- Use named fields in every struct literal, never positional ones: fixing fieldalignment findings\n reorders struct fields.\n- Keep lines under 180 characters (`lll`).\n- When a standard library package collides with an existing import, alias it `lib`, for\n example `libtime`.\n- Start error strings lowercase, without trailing punctuation.\n- Ask before adding a dependency.\n\n## Tests\n\n- Assert with `testify` (`assert`, `require`).\n- Write table-driven tests: one behavior is one test function with a table. Per-case fixtures,\n mock returns, and expected errors are table fields, not reasons for a new function. Extend an\n existing table instead of adding a function. Split when the API under test or the setup and\n assertion flow differs, and for no other reason.\n- Test behavior, not the patch. Name the behavior a test proves, then ask:\n 1. Could the original bug still occur while this test passes?\n 2. Could a correct refactor make it fail?\n\n If either answer is yes, redesign or drop the test. Never assert on source text, embedded\n scripts, or statement order; assert on text when the emitted text is itself the contract\n (generated shell code, escaping, serialization). When the behavior cannot be exercised, say so\n instead of adding a proxy test.\n- A test that mutates package-level state saves the original value and restores it with\n `t.Cleanup`, never a hardcoded value.\n\n## Before committing\n\nRun from the module root and fix every finding:\n\n```bash\nmodernize -fix ./...\nfieldalignment ./...\ngolangci-lint run\n```\n\n- Never run `fieldalignment -fix`: it drops the comments of the fields it reorders. Reorder by\n hand.\n- Commit the `modernize` rewrites with the change that triggered them.\n- After touching a `_windows.go`, `_unix.go`, `_darwin.go`, `_linux.go`, or `//go:build` file,\n also run `go build ./...`, `golangci-lint run`, `modernize ./...`, and `fieldalignment ./...`\n with `GOOS` set to another platform. The host toolchain skips other platforms' files, so their\n errors otherwise surface in CI.\n- `dupl` on near-identical tests: merge them into one table. Reserve `//nolint:dupl`, with a reason,\n for tests that must stay separate. `goconst`: extract a string literal used three or more\n times into a constant.\n","frontmatter":{"name":"golang","description":"Go conventions for this project that differ from common Go practice. Apply when writing, reviewing, or refactoring any Go source or test file.\n","triggers":["on_commit"]},"isInternal":false,"tokens":677,"sizeBytes":2863},{"name":"bash.md","path":".agents/skills/project-knowledge/references/bash.md","rawUrl":"https://raw.githubusercontent.com/JanDeDobbeleer/oh-my-posh/HEAD/.agents/skills/project-knowledge/references/bash.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# bash\n\nVerified on bash 5.2 (2026-07).\n\n- Never run the `exec` builtin from PROMPT_COMMAND, not even `exec {fd}nul` in the command, or the child's stderr corrupts the display.\n- Windows has no SIGPIPE: stdin EOF is the daemon's only exit signal. Clink's pipes are `_O_NOINHERIT`, so cmd's\n death closes the daemon's stdin.\n- Test with `luac -p` plus a Lua harness that stubs the Clink API (`winget install DEVCOM.Lua`,\n `chrisant996.Clink`). Clink cannot run headless, so live smoke tests stay manual.\n","isInternal":false,"tokens":187,"sizeBytes":654},{"name":"codebase.md","path":".agents/skills/project-knowledge/references/codebase.md","rawUrl":"https://raw.githubusercontent.com/JanDeDobbeleer/oh-my-posh/HEAD/.agents/skills/project-knowledge/references/codebase.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# Codebase\n\n## Template markup trust boundary\n\n- Print-action output is chevron-escaped (`escapePrintActions`); only `template.Markup` values keep `<...>`\n anchors. Keep attacker-controlled data (VCS refs, API responses, folder names) in plain strings. `RawMarkup` is for\n user config only, `EscapeMarkup` for data, `JoinMarkup` for composition.\n- Segment fields built from option strings that carry anchors (icons, `branch_icon`, `folder_separator_icon`,\n `status_formats`) must be `template.Markup`, or the anchors render as literal text.\n- Keep `template.Markup` a named string, never a struct: text/template treats every struct as true (breaks\n `{{ if .BranchStatus }}` guards in shipped themes) and `eq` cannot compare it to a string.\n- Untrusted templates (`RenderUntrusted`, path segment) escape Markup results too. The path segment escapes folder\n names with `template.EscapeSource` on every branch of `replaceMappedLocations`; a new early return needs its own\n escape.\n- New func-map entries: output not derived from input (`readFile`, `cmd`, `b64dec`, `env`) goes in `noPromote`;\n attacker-chosen counts (`repeat`, `seq`, `until`, `rand*`) go in `dangerousFuncs` (trusted templates only). For a\n hot function, add a typed case to `markupAwareTyped` first.\n- Never bypass `formats.EscapeSequences` in `terminal.write`'s `isHyperlink` branch: bash `@P` re-interprets a\n backslash in the OSC 8 URI.\n- `src/prompt/golden_test.go` renders every shipped theme byte-exact. A golden diff after a markup change means a\n theme relied on the old, insecure behavior: inspect it, then `go test ./prompt/... -run TestGoldenThemes -update`.\n\n## Terminal output sanitization\n\n- `prompt.Engine.write` bypasses `terminal.write`'s per-rune control filter. Sanitize attacker-influenceable strings\n written in one shot (console title, OSC payloads) with `terminal.stripControlRunes`; `trimAnsi` misses ESC-less\n input (bare BEL) and CSI `! p`, APC, SOS, ST.\n- Don't extend `terminal.AnsiRegex`'s final-byte class (`!`, `_`, `X`, `\\` omitted on purpose) as a sanitization fix;\n strip control runes instead.\n\n## Segments and cache\n\n- Treat `mem.SwapMemory()` errors as returning a nil stat: gopsutil can fail reading `/proc/vmstat` on Android/Termux,\n so fall back to `VirtualMemoryStat.SwapTotal` and `SwapFree` instead of dereferencing the result.\n- Segment writers gob-encode only exported fields; `segments.Base.env/options` are unexported. On cache restore,\n overlay restored data onto the writer from `MapSegmentWithWriter`; never replace the writer.\n- `runtime/cmd.RunWithEnv` trims whitespace from the whole output, so a trailing empty field is lost. End records\n with a non-whitespace delimiter or sentinel and validate before assigning parsed state.\n- A blank prompt means a panic outside segment `Execute` and the streaming producer (both recover). A poisoned\n cache entry replays its failure every prompt until its TTL ends.\n- Caches persist only with the hidden `--save-cache` flag (print/stream); relocate with `OMP_CACHE_DIR`.\n- Logs are buffered and print only via `oh-my-posh debug` (grep `restored segment from cache`, `setting entry`);\n `POSH_TRACE=1` and stderr show nothing for print commands.\n- Windows: a fresh memory-mapped cache file logs a harmless `store.go:init EOF` on first read.\n\n## Streaming and serve daemon\n\n- `\"streaming\": ` also becomes every segment's pending timeout, overriding segment `timeout`.\n- `stream` emits the transient prompt as a `\\x1e`-prefixed NUL-terminated record (initial, and again once all\n segments resolve). Serve records are `\\x1f\\0`; a wait-mode request always yields exactly 2, even on\n segment panic (`renderComplete`), because Clink blocks on that count.\n- A timed-out segment keeps running after its cycle. On any path that can run then, publish through the\n `renderCache` captured at the top of `Execute`, never the global `template.Cache` (serve resets it per cycle,\n tests reassign it). `restoreCache`/`restoreData` still read the global (open race, 2026-09).\n- Don't gate `Execute`'s cache-hit early return on streaming: placeholders never show cached data, so skipping the\n cache only adds live probes that can time out.\n- Never touch `segment.writer` of a segment the cycle still has pending; pending segments render via\n `Segment.RenderPlaceholder` (config only). Don't add a `Pending` flag to `config.Segment`.\n- The event channel in `prompt/streaming.go` is sized `2*segments+1` so plain sends never block or drop; don't add\n `select`/`default`. The producer's `recover` must log a stack: a silent recover once hid a stuck-segment bug.\n- `prompt/streaming_writer_test.go`'s fake writer writes fields late on purpose, as race bait. `-race` only runs in\n CI ([release](release.md)).\n- Serve: process-lifetime initializers (`if X != nil return`) pin first-render state. Reset per render\n (`template.ResetCache()` in `startRenderCycle`); never nil a global that abandoned goroutines may still read.\n- Don't memoize the config in serve: the per-render gob decode gives each cycle its own segment graph, isolated from\n abandoned-cycle goroutines.\n- Daemon tests must vary per-request context (cwd, status) across cycles to catch one-shot state.\n- `config.Get` prefers the session gob cache over `POSH_THEME`.\n- Timing races: `oh-my-posh debug` timings are cold-process. Sweep the `streaming` value against a scripted serve\n session (JSON line + env blob on stdin) and count cycles whose last record still holds the placeholder.\n\n## Rendering and statusline\n\n- `template.Init` resets the parsed-template cache: calling it per benchmark iteration measures cold parse.\n- Stale website previews: a set `OMP_BIN` overrides the auto-rebuilt `src/bin` in `ensure-artifacts.mjs`.\n- Unix `terminal-dimensions` runs `stty size` on stdin, which is not a TTY under Claude Code's statusline. A valid\n `COLUMNS` fallback must clear the `stty` error, or `prompt.Engine.canWriteRightBlock` rejects right-aligned blocks.\n","isInternal":false,"tokens":1467,"sizeBytes":6005},{"name":"fish.md","path":".agents/skills/project-knowledge/references/fish.md","rawUrl":"https://raw.githubusercontent.com/JanDeDobbeleer/oh-my-posh/HEAD/.agents/skills/project-knowledge/references/fish.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# fish\n\nVerified on fish 4.1.2 (2026-07 to 2026-09).\n\n## Jobs, fifos, and lifecycle\n\n- fish does not fork a backgrounded function; it blocks the shell. Run readers as an external process:\n `fish --no-config -c $script args &`.\n- `jobs --last --pid` prints a \"Process\" header plus one pid per pipeline stage: filter with\n `string match --regex '^\\d+$'` and treat the result as a list.\n- Guard zero pids before `kill -0`: `kill -0 0` signals your own process group and always succeeds.\n- A fifo write with no reader blocks forever; liveness-check the reader before every write.\n- The serve daemon opens its request fifo O_RDWR, so it never sees EOF and a SIGKILLed fish orphans it. Teardown\n must go through the `fish_exit` handler.\n- `--on-signal SIGUSR1` handlers fire between commands in non-interactive scripts.\n- The streaming transient prompt lives in a tempfile (`$_omp_streaming_tempfile.transient`), not a variable,\n because `_omp_cleanup_stream` runs before the transient repaint.\n\n## Key bindings\n\n- `commandline --is-valid`: 0 valid, 1 erroneous, 2 incomplete. An empty buffer also returns 1, so check the buffer\n is non-empty before treating 1 as an error. A trailing backslash returns 0 (not a continuation).\n- A parse error from `commandline --function execute` inside a binding is attributed to the binding's file and\n function (#7862). Rethrow through a pristine parser instead:\n `commandline --current-buffer | string collect | $fish_bin --no-execute` (keeps the buffer and `$status`).\n- fish 4.x rejects command substitutions in command position (`(status fish-path) --no-execute`); assign to a\n variable (`set fish_bin (status fish-path)`) first.\n","isInternal":false,"tokens":426,"sizeBytes":1673},{"name":"pwsh.md","path":".agents/skills/project-knowledge/references/pwsh.md","rawUrl":"https://raw.githubusercontent.com/JanDeDobbeleer/oh-my-posh/HEAD/.agents/skills/project-knowledge/references/pwsh.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# PowerShell (pwsh)\n\n## Engine events and runspaces (pwsh 7, 2026-07)\n\n- `Register-EngineEvent -Action` (e.g. `PowerShell.OnIdle`): `-MessageData` arrives as `$null`, and\n `.GetNewClosure()` captures are lost when the scriptblock is created in a module function. Pass state through a\n `$global:` variable (`$global:_ompStreamingState` in `omp.ps1`).\n- PSReadLine raises `PowerShell.OnIdle` every ~300-450ms, only while the input buffer is empty. Anything the user\n can trigger sooner (transient prompt on a fast Enter) must also drain synchronously at its call site.\n- PSEvents raised from a non-engine thread (e.g. `Register-ObjectEvent DataAdded` fed by a background runspace)\n can crash the host (`InvalidPipelineStateException`). Consume records only on the engine thread.\n- `Register-ObjectEvent` actions may or may not fire during a busy-wait. Never share a consume cursor between an\n event action and a synchronous waiter: give the waiter a private cursor and make the action idempotent.\n\n## PSReadLine prompt redraws (PSReadLine 2.4.5 / 2.3.6, 2026-09)\n\n- `InvokePrompt()` blanks `ExtraPromptLineCount + 1` rows before it calls the prompt function; a count set during\n that call only affects the next redraw. Padding the transient prompt cannot fix under-erasure.\n- `ExtraPromptLineCount` must count screen rows, including wrapping. The engine computes `terminal.CursorRow` and\n prefixes pwsh prompts with `ESC]7777;BEL`, which `Set-PoshExtraPromptLineCount` strips. Don't measure the\n prompt in PowerShell (`Measure-Object -Line` ignores wrapping and skips empty elements).\n- Overcounting is as bad: it erases the previous output line, or at the screen top `InvokePrompt` returns before\n calling the prompt (`newY < 0`), leaving `$script:TransientPrompt` set so the next primary renders as transient.\n Zero-width sequences such as the rprompt's `ESC 7`/`ESC 8` count 0 cells.\n- Match escape-prefixed strings with `-match '^\\u001b...'`, not `StartsWith`: culture-aware `StartsWith` ignores\n ESC, so `\"abc\".StartsWith(\"$([char]27)a\")` is `True`.\n- Redraw bugs only show when a line wraps; reproduce with the e2e `harness.MultiLine` overlay.\n\n## Exit lifecycle\n\n- pwsh cannot exit while a `[powershell]::Create()` pipeline thread runs (foreground threads). A reader blocked in\n `ReadByte()` on a child that exits only on stdin EOF deadlocks `exit` (#7643).\n- Module `OnRemove` never runs on a normal `exit`. Tear down a daemon in a `Register-EngineEvent PowerShell.Exiting`\n handler: write `quit`, close the child's stdin (the guaranteed EOF), kill after a short `WaitForExit`.\n\n## Performance (ARM64 Windows 11, 2026-07)\n\n- Process creation floor is ~70ms; any omp spawn costs ~100-130ms. For `omp.ps1` perf, count spawns per Enter\n first; cmdlet and module overhead is negligible.\n- `&` saves only ~10-17ms over the Process API and, under a CP437/1252 console, mangles UTF-8 output unless\n `[Console]::OutputEncoding = UTF8` is set once at init.\n- `Start-Sleep -Milliseconds 1` sleeps a ~15.6ms timer tick. Don't sleep-poll; signal a `ManualResetEventSlim`.\n\n## Testing\n\n- `New-Event -SourceIdentifier PowerShell.OnIdle` runs the real OnIdle action deterministically; its side effects can\n short-circuit later prompt calls.\n- Set module-scope flags from a test: `& (Get-Module oh-my-posh-core) { $script:X = $true }`.\n- Serve is gated to pwsh 6+ outside ConstrainedLanguage; pwsh 5.1 and ConstrainedLanguage keep the legacy path.\n- Exit-deadlock repro: `Start-Process pwsh -File test.ps1` + `WaitForExit(timeout)`; `findstr x` with redirected\n stdio stands in for a daemon.\n","isInternal":false,"tokens":957,"sizeBytes":3604},{"name":"release.md","path":".agents/skills/project-knowledge/references/release.md","rawUrl":"https://raw.githubusercontent.com/JanDeDobbeleer/oh-my-posh/HEAD/.agents/skills/project-knowledge/references/release.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# Release, CI, and git\n\n## Release (`.github/workflows/release.yml`)\n\n- Releases are immutable: the workflow creates a draft and publishes last. Every asset must be in the draft before the\n publish step.\n\n## CI\n\n- `go test -race` does not work on the windows/arm64 dev machine or its WSL (no C compiler, no sudo). CI's\n `Race Detector` step (`code.yml`, ubuntu) is the only race gate.\n\n## Git on Windows\n\n- With `core.autocrlf=true`, `git rebase --autosquash` can stop on a plain `pick` with \"Your local changes would be\n overwritten\" and no real conflict (line-ending renormalization). Set `core.autocrlf false` for the rebase and\n restore it after; don't try to resolve a phantom conflict.\n","isInternal":false,"tokens":183,"sizeBytes":696},{"name":"testing.md","path":".agents/skills/project-knowledge/references/testing.md","rawUrl":"https://raw.githubusercontent.com/JanDeDobbeleer/oh-my-posh/HEAD/.agents/skills/project-knowledge/references/testing.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# Testing shells and terminals\n\n## Script edits\n\n- `src/shell/scripts/` is embedded at build time: rebuild the binary after every script edit, then inspect what\n users source with `oh-my-posh init --print`.\n- A script function is dead code unless `src/shell/.go` emits its activation line for the enabled feature.\n\n## e2e harness (`e2e/`, see `e2e/README.md`)\n\n- PSReadLine on a raw Unix pty floods `CSI 6n` and wedges without a reply (ConPTY answers it on Windows); the\n harness answers from the vt10x cursor (`harness/session.go`).\n- nu autoloads `$nu.vendor-autoload-dirs` after `--config`, so a real omp install clobbers the test prompt. Point\n `XDG_DATA_HOME` at an empty dir.\n- go-pty's Windows `Cmd` resolves bare names relative to `Cmd.Dir`; pass absolute binary paths.\n- On Windows, `bash` on PATH is System32's WSL launcher; `harness.LookupShellBinary` derives Git Bash from\n `git.exe`.\n\n## WSL\n\n- Run e2e from a Windows worktree: cross-compile (`GOOS=linux GOARCH=arm64 go build`), then in WSL\n `cd /mnt/c/.../e2e && OMP_E2E_BINARY=/mnt/c/.../oh-my-posh go test .`. If the distro's Go is too old for e2e's\n `go.mod`, unpack a go.dev tarball into `~/go-sdk`.\n- WSL `/tmp` is wiped between `wsl.exe` invocations: keep a test in one `wsl -e` call or stage under `$HOME`.\n- From Git Bash, prefix `MSYS_NO_PATHCONV=1` so `/mnt/c/...` arguments reach wsl.exe unmangled.\n\n## Getting a pty\n\n- `zsh -i` under plain `wsl -e` hangs (no foreground pty). Use `wsl -e script -qec 'zsh -i' /dev/null` for a real pty\n with job control, run backgrounded with output to a file, and poll a done-marker.\n- For keystrokes use `zmodload zsh/zpty`: `zpty omp zsh -i`, `zpty -w -n omp $'\\x03'` (real SIGINT), assert via\n state files, drain with `zpty -r`. `script(1)` does not work inside zpty.\n- `script(1)` quirks: bash prompt bytes are not relayed (probe `${PS1@P}` in-session); fish discards piped\n typeahead (assert via files written by event handlers); zsh works.\n- vi-mode probes must be mode-aware: after a normal-mode accept the next line starts in normal mode, so prefix `i`.\n A stray self-inserted `i` shows up as `last_status=127`.\n- To hold a render open, point an `http` segment with a large `http_timeout` at a silent local TCP listener; kill\n the listener to trigger the async update. There is no shell-command segment.\n\n## Protocol streams\n\n- One `bufio.Scanner` per pipe, ever; a second scanner loses buffered data.\n- Never treat wall-clock silence as \"records done\": cold-cache CI runs exceed any fixed gap. Wait for a record that\n proves the assertion (the cycle's transient record comes last) and keep a timeout only as a hang bound. Reproduce\n with `go clean -cache && go test -count=1 ./...`.\n\n## Windows Terminal and ConPTY\n\n- \"[process exited with code 0]\" at shell exit is Windows Terminal's own teardown message, never omp output.\n- Panes opened via `wt.exe ` never auto-close under `closeOnExit=automatic`; profile tabs do.\n- A headless conhost (Windows 11 build 26300) reports cursor 0,0, a blank buffer, and drops pty input: assert state,\n not row placement.\n- pywinpty's ConPTY EOF lags process death by ~5s (harness artifact, not a hang).\n- SendKeys into Windows Terminal drops keystrokes while the user works; a \"hung\" test may never have got `exit`.\n- `Set-Content -NoNewline` joins piped lines into one and corrupts scripts; write byte-exact files with Git Bash\n redirection.\n","isInternal":false,"tokens":971,"sizeBytes":3441},{"name":"zsh.md","path":".agents/skills/project-knowledge/references/zsh.md","rawUrl":"https://raw.githubusercontent.com/JanDeDobbeleer/oh-my-posh/HEAD/.agents/skills/project-knowledge/references/zsh.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# zsh\n\n## zle\n\n- Every new editor invocation starts in keymap `main`; a `vicmd` selection does not carry into the next line.\n- `$?` after the transient prompt's `zle .send-break` is 1, native Ctrl+C gives 130 (TODO in `_omp_zle-line-init`).\n Don't fix one path without the other.\n- Ubuntu's `/etc/zsh/zshrc` defines a `zle-line-init`; never assume the widget slot is empty.\n- zsh-vi-mode always wraps omp's `zle-line-init` (it initializes lazily at first `precmd`), and our\n `.recursive-edit` swallows the session, so `_omp_zle-line-init` must call `zvm_zle-line-init` up front (guarded on\n `$+functions[zvm_zle-line-init]` and `ZVM_INIT_DONE`). Keep that call (#5992).\n- Keep `local rawfunc=` at the top of `_omp_zle-line-init`: `zvm_reset_prompt` resolves `$rawfunc` by dynamic\n scoping and would otherwise re-enter our widget.\n- Debug widget re-entry by logging `${funcstack[*]}` inside the widget.\n\n## Quoting\n\n- Quote every parameter expansion used as a command argument if its value can contain `[`, `?`, `*` or `#`. Under a\n user's `setopt GLOB_SUBST` it becomes a glob, and `BAD_PATTERN` aborts the widget (`$zle_bracketed_paste[1]` is\n `\\e[?2004h`, #7816).\n\n## coproc, fds, and signals\n\n- An interactive zsh with MONITOR prints `[n] pid` at coproc spawn; neither `disown` nor `2>/dev/null` stops it.\n `setopt localoptions no_monitor` does, and the child then inherits SIGINT/SIGQUIT ignored.\n- Duplicate coproc fds to session fds (`exec {out}<&p {in}>&p`) so they survive a later `coproc`; `disown %+` keeps\n the daemon out of `jobs` and the job-count segment.\n- A redirection-only `exec` applies every listed redirection permanently: `exec {fd}<&p 2>/dev/null` silences the\n session's stderr (#7653). Scope it: `{ exec ... } 2>/dev/null`.\n- Writing to a dead coproc raises SIGPIPE, which kills a non-interactive zsh. Guard writes with a `kill -0 $pid`\n check plus `setopt localoptions localtraps; trap '' PIPE`.\n- Never `kill -0` a possibly-zero pid: `kill -0 0` signals your own process group and always succeeds.\n- zsh 5.9 `read -r -u $fd -d $'\\0' -t N` ignores `-t` and blocks forever on a silent fd, so the serve path hangs\n in a non-interactive `zsh script.zsh`; test it in an interactive session.\n- Tear down in `zshexit_functions`; closing the fds (or the shell dying, even by SIGKILL) EOFs the daemon's stdin.\n","isInternal":false,"tokens":684,"sizeBytes":2339},{"name":"SKILL.md","path":".agents/skills/project-knowledge/SKILL.md","rawUrl":"https://raw.githubusercontent.com/JanDeDobbeleer/oh-my-posh/HEAD/.agents/skills/project-knowledge/SKILL.md","title":"project-knowledge","category":"anthropic-skill","format":"markdown","content":"---\nname: project-knowledge\ndescription: >\n Verified, actionable gotchas for oh-my-posh. Read the matching topic file BEFORE changing shell integration\n scripts (pwsh, zsh, bash, fish, cmd/Clink, nu, elvish, xonsh), terminal or pty behavior, WSL or e2e shell tests,\n Go internals (cache, segments, streaming, serve daemon, template rendering, output sanitization), or release, CI,\n build, and packaging workflows.\n---\n\n# Project Knowledge\n\nNon-obvious constraints, platform quirks, traps, and failed approaches. Read only the files the task touches; any\nshell-script edit also needs `testing`. Entries are point-in-time: verify against the code and fix drift.\n\n| Topic | Read when |\n| ------------------------------------ | ----------------------------------------------------------------------------- |\n| [codebase](references/codebase.md) | Go internals: templates, sanitization, segments, cache, streaming, serve |\n| [release](references/release.md) | `release.yml`, signing, packaging, CI gates, `-race`, rebasing on Windows |\n| [testing](references/testing.md) | Any shell-script edit; e2e/pty harnesses, WSL, ConPTY, Windows Terminal, nu |\n| [zsh](references/zsh.md) | `omp.zsh`, zle widgets, coproc, zsh-vi-mode |\n| [pwsh](references/pwsh.md) | `omp.ps1`, PSReadLine, runspaces, engine events, pwsh perf |\n| [fish](references/fish.md) | `omp.fish`, fish jobs, fifos, key bindings |\n| [bash](references/bash.md) | `omp.bash`, PROMPT_COMMAND, readline, ble.sh |\n| [cmd-clink](references/cmd-clink.md) | `omp.lua`, Clink, Windows pipe lifecycles |\n\n## Write-back\n\n- Append only verified entries that change what an agent does, phrased \"do X / don't do Y, because Z\", to the\n matching file (new file plus index row only when none fits). No narratives or history.\n- Update or delete a stale entry instead of stacking a correction. Date it only when staleness matters.\n- Commit knowledge updates with the change they relate to.\n","frontmatter":{"name":"project-knowledge","description":"Verified, actionable gotchas for oh-my-posh. Read the matching topic file BEFORE changing shell integration scripts (pwsh, zsh, bash, fish, cmd/Clink, nu, elvish, xonsh), terminal or pty behavior, WSL or e2e shell tests, Go internals (cache, segments, streaming, serve daemon, template rendering, output sanitization), or release, CI, build, and packaging workflows.\n"},"isInternal":false,"tokens":494,"sizeBytes":2253},{"name":"SKILL.md","path":".agents/skills/segment-create/SKILL.md","rawUrl":"https://raw.githubusercontent.com/JanDeDobbeleer/oh-my-posh/HEAD/.agents/skills/segment-create/SKILL.md","title":"segment-create","category":"anthropic-skill","format":"markdown","content":"---\nname: segment-create\ndescription: >\n Checklist for adding a new Oh My Posh segment. Use when asked to add or create a new segment:\n lists every file to touch, the existing segment to copy, and how to verify.\n---\n\n## Template\n\nCopy `src/segments/taskwarrior.go` and `src/segments/taskwarrior_test.go`: two options, a\n`Template()`/`Enabled()` pair, and every shell call going through the mocked environment.\n\n- Embed `Base` first in the struct; its exported fields are the template properties.\n- Declare options as `options.Option` constants; read them with `s.options.String(...)`,\n `s.options.Bool(...)`, `s.options.KeyValueMap(...)` and so on, passing the default there.\n- Reach the OS, shell, files and network only through `s.env` so tests can mock it.\n- Override `Activation()` only for a cheap precondition such as a project file (see\n `src/segments/dvc.go`); `Base` defaults to always active.\n- Tests are table-driven: a `mock.Environment` from `src/runtime/mock`, options as an\n `options.Map`, then `Init(props, env)` and assertions on `Enabled()` and the exported fields.\n\n## Checklist\n\nKeep every list sorted alphabetically.\n\n1. `src/segments/.go` and `src/segments/_test.go`.\n1. `src/config/segment_types.go`: add the constant ` SegmentType = \"\"`.\n1. `src/config/segment_registry.go`: add `gob.Register(&segments.{})` to `init()` and\n `: func() SegmentWriter { return &segments.{} }` to `Segments`. A missing map\n entry fails silently at runtime: the segment never renders.\n1. `themes/schema.json`: add `` to `definitions.segment.properties.type.enum` and an\n `if`/`then` block to `definitions.segment.allOf` declaring every option. Copy the\n `taskwarrior` block; its `unevaluatedProperties: false` rejects undeclared options.\n1. `website/docs/segments//.mdx`, where category is one of agents, cli, cloud,\n health, languages, music, scm, system or web. Follow the `segment-docs` skill, and keep a\n `## What` paragraph: the segment catalog plugin reads it.\n1. `website/sidebars.js`: add `\"segments//\"` to that category's `items`.\n1. `website/segment_data.json`: add sample data under ``, shaped like the `taskwarrior` entry.\n1. `website/plugins/segments/registry.json`: generated. The first `go test ./config/...` run\n rewrites it and fails; rerun to confirm, then keep the file.\n1. Credentials needed? Add the doc id to `AUTH_TIERS` in `website/plugins/segments/data.js`.\n\n## Verify\n\nFrom `src/`:\n\n```shell\ngo test ./segments/... -run Test\ngo test ./config/...\n```\n\nRun `npm run build` in `website/` only when docs changed.\n","frontmatter":{"name":"segment-create","description":"Checklist for adding a new Oh My Posh segment. Use when asked to add or create a new segment: lists every file to touch, the existing segment to copy, and how to verify.\n"},"isInternal":false,"tokens":685,"sizeBytes":2637},{"name":"SKILL.md","path":".agents/skills/segment-docs/SKILL.md","rawUrl":"https://raw.githubusercontent.com/JanDeDobbeleer/oh-my-posh/HEAD/.agents/skills/segment-docs/SKILL.md","title":"segment-docs","category":"anthropic-skill","format":"markdown","content":"---\nname: segment-docs\ndescription: >\n Reference mapping between Oh My Posh Go segment source code and MDX documentation.\n Use when creating, updating, or auditing segment documentation, or when reading\n segment Go code and needing to understand how code constructs map to user-facing\n options, template properties, and type representations in docs.\n---\n\n# Segment Documentation Reference\n\n## Go-to-Documentation Type Mapping\n\nWhen reading a segment's Go source to document its options, determine the type from the\n`Provider` method used to read the option value:\n\n| Go method call | Documentation type |\n| -------------- | :----------------: |\n| `options.Bool(option, default)` | `boolean` |\n| `options.String(option, default)` | `string` |\n| `options.StringArray(option, default)` | `[]string` |\n| `options.Int(option, default)` | `int` |\n| `options.Float64(option, default)` | `float64` |\n| `options.KeyValueMap(option, default)` | `map[string]string` |\n| `options.Color(option, default)` | `string` |\n| `options.Template(option, default, ctx)` | `string` |\n| `options.Any(option, default)` | `any` |\n\n## Extracting Options from Go Source\n\nOptions are declared as `options.Option` string constants in the segment's `const` block:\n\n```go\nconst (\n BranchIcon options.Option = \"branch_icon\" // option name used in config\n NativeStatus options.Option = \"native_status\"\n)\n```\n\nThe **option name** is the string literal value (e.g., `\"branch_icon\"`).\n\nThe **type** and **default value** come from the getter call in `Enabled()` or `init`-like methods:\n\n```go\ns.icon = s.options.String(BranchIcon, \"\\uE0A0\")\n// ^^^^^^ → string type, \"\\uE0A0\" → default\n```\n\n### Shared options\n\nThe following options are defined in `src/segments/options/map.go` and available to all\nsegments without appearing in a segment-specific `const` block:\n\n| Option name | Type | Default |\n| ----------- | ---- | ------- |\n| `always_enabled` | `boolean` | `false` |\n| `display_default` | `boolean` | `true` |\n| `display_error` | `boolean` | `true` |\n| `http_timeout` | `int` | `20` |\n| `cache_duration` | `int` | varies |\n| `access_token` | `string` | `\"\"` |\n| `refresh_token` | `string` | `\"\"` |\n| `version_url_template` | `string` | `\"\"` |\n| `files` | `[]string` | varies |\n\n## Extracting Template Properties from Go Source\n\nTemplate properties are values available inside the segment's `template` string.\n\n**Rules for what becomes a template property:**\n\n- **Exported struct fields** (capitalized) on the segment struct → `.FieldName`\n- **Unexported fields** are not accessible in templates\n- **Nested struct fields** use dot notation: a field `Working ScmStatus` exposes\n `.Working.Modified`, `.Working.Added`, etc.\n- **Zero-argument methods** with a single return value → `.MethodName`\n- **Document fields that are assigned** in `Enabled()` or its callees,\n not every inherited field from embedded structs is populated by every segment\n\nThe default template comes from the `Template()` method:\n\n```go\nfunc (s *MySegment) Template() string {\n return \" {{ .FieldName }} \"\n}\n```\n\n### Nested struct subsection convention\n\nWhen a property's type is itself a struct, add an `#### TypeName` subsection within\nthe Properties table section listing its exported fields. Example:\n\n```mdx\n#### Status\n\n| Name | Type | Description |\n| ---- | ---- | ----------- |\n| `.Modified` | `int` | Number of modified files |\n| `.Added` | `int` | Number of added files |\n| `.Deleted` | `int` | Number of deleted files |\n| `.Untracked` | `int` | Number of untracked files |\n| `.Changed` | `boolean` | Whether any changes exist |\n```\n\n## Key Source Files for Inherited Fields\n\nWhen a segment embeds a base struct, its inherited fields may also be template properties.\nCheck these files to discover what fields are available:\n\n| File | What it defines |\n| ---- | --------------- |\n| `src/segments/options/map.go` | `Provider` interface method signatures; shared `Option` constants |\n| `src/segments/base.go` | `Base` struct embedded by all segments; provides `options`, `env` |\n| `src/segments/scm.go` | `ScmStatus` type with working/staging status fields (git, mercurial, etc.) |\n| `src/segments/language.go` | `Version` type and language base fields (Python, Node, Go, etc.) |\n","frontmatter":{"name":"segment-docs","description":"Reference mapping between Oh My Posh Go segment source code and MDX documentation. Use when creating, updating, or auditing segment documentation, or when reading segment Go code and needing to understand how code constructs map to user-facing options, template properties, and type representations in docs.\n"},"isInternal":false,"tokens":1051,"sizeBytes":4272},{"name":"skill.md","path":"website/static/skill.md","rawUrl":"https://raw.githubusercontent.com/JanDeDobbeleer/oh-my-posh/HEAD/website/static/skill.md","title":"static","category":"anthropic-skill","format":"markdown","content":"---\nname: oh-my-posh\ndescription: Install, configure, or troubleshoot Oh My Posh/ohmyposh: shell init, themes, segments, Nerd Font icons, and prompt setup on PowerShell, zsh, bash, or fish.\n---\n\n# Oh My Posh\n\n> Oh My Posh is a cross-shell, cross-platform prompt theme engine for Windows, macOS, and Linux.\n> It renders beautifully themed prompts with Git status, language versions, cloud context,\n> and more — 120 segments in all.\n\nFull skill (folder-based, with per-OS and per-shell guides):\n[/skills/ohmyposh/SKILL.md](/skills/ohmyposh/SKILL.md)\n\n## Quick links\n\n- [Installation — Windows](/skills/ohmyposh/installation/windows.md)\n- [Installation — macOS](/skills/ohmyposh/installation/macos.md)\n- [Installation — Linux](/skills/ohmyposh/installation/linux.md)\n- [Shell setup — PowerShell](/skills/ohmyposh/shell/powershell.md)\n- [Shell setup — Bash](/skills/ohmyposh/shell/bash.md)\n- [Shell setup — Zsh](/skills/ohmyposh/shell/zsh.md)\n- [Shell setup — Fish](/skills/ohmyposh/shell/fish.md)\n- [Shell setup — Nu](/skills/ohmyposh/shell/nu.md)\n- [Shell setup — Cmd](/skills/ohmyposh/shell/cmd.md)\n- [Shell setup — Elvish](/skills/ohmyposh/shell/elvish.md)\n- [Shell setup — Xonsh](/skills/ohmyposh/shell/xonsh.md)\n- [Configuration & themes](/skills/ohmyposh/configuration.md)\n","isInternal":false,"tokens":389,"sizeBytes":1300},{"name":"configuration.md","path":"website/static/skills/ohmyposh/configuration.md","rawUrl":"https://raw.githubusercontent.com/JanDeDobbeleer/oh-my-posh/HEAD/website/static/skills/ohmyposh/configuration.md","title":"Ohmyposh Skill","category":"anthropic-skill","format":"markdown","content":"# Oh My Posh — Configuration & Customization\n\n## Apply a theme\n\nPass `--config` to the init command with a theme name, local path, or remote URL.\n\n**By theme name** (no extension needed):\n\n```powershell\n# PowerShell\noh-my-posh init pwsh --config 'jandedobbeleer' | Invoke-Expression\n```\n\n```bash\n# Bash / Zsh\neval \"$(oh-my-posh init bash --config jandedobbeleer)\"\n```\n\n**By local file path:**\n\n```powershell\n# PowerShell\noh-my-posh init pwsh --config 'C:\\Users\\\\.mytheme.omp.json' | Invoke-Expression\n```\n\n```bash\n# Bash / Zsh\neval \"$(oh-my-posh init bash --config ~/.mytheme.omp.json)\"\n```\n\n**By remote URL:**\n\n```powershell\noh-my-posh init pwsh --config 'https://raw.githubusercontent.com/JanDeDobbeleer/oh-my-posh/main/themes/jandedobbeleer.omp.json' | Invoke-Expression\n```\n\n> Using a remote URL adds a network dependency. Oh My Posh caches remote configs using ETags,\n> but latency still applies on cache misses. For reliable offline use, copy the theme to a\n> local file and use a local path instead.\n\n## Browse available themes\n\nView all bundled themes online: \n\n> There is no terminal command to preview all available themes. Direct users to the website above.\n\n## Debug the current theme\n\nTo render your active prompt in debug mode (shows segment timing and values):\n\n```bash\noh-my-posh debug\n```\n\n## Export a theme for editing\n\n```bash\noh-my-posh config export --config jandedobbeleer --output ~/.mytheme.omp.json\n```\n\nThen set `--config ~/.mytheme.omp.json` in your init line and edit the file to taste.\n\n## WSL tip\n\nInside WSL you can share a theme stored in your Windows home folder:\n\n```bash\neval \"$(oh-my-posh init bash --config /mnt/c/Users//mytheme.omp.json)\"\n```\n\n## Live reload during editing\n\nEnable live reload so prompt changes appear without restarting the shell:\n\n```bash\noh-my-posh enable reload\n```\n\nDisable:\n\n```bash\noh-my-posh disable reload\n```\n\nPreview every configured prompt without restarting:\n\n```bash\noh-my-posh print preview\n```\n\nForce-render all segments regardless of context:\n\n```bash\noh-my-posh print preview --force\n```\n\n## Validate a config or segment via MCP\n\nWhen creating or editing a segment manually, use the oh-my-posh MCP server to validate the\nconfig or a segment snippet for schema errors. Agents can call:\n\n```bash\ncurl -X POST https://ohmyposh.dev/api/mcp \\\n -H \"Content-Type: application/json\" \\\n -d '{\n \"jsonrpc\": \"2.0\",\n \"method\": \"tools/call\",\n \"params\": {\n \"name\": \"validate_config\",\n \"arguments\": {\"content\": \"\", \"format\": \"auto\"}\n },\n \"id\": 1\n }'\n```\n\nOr use `validate_segment` to check a single segment snippet instead of an entire config.\n\n## Configuration reference\n\n- Full schema: \n- Docs: \n- Segments: \n","isInternal":false,"tokens":775,"sizeBytes":2963},{"name":"linux.md","path":"website/static/skills/ohmyposh/installation/linux.md","rawUrl":"https://raw.githubusercontent.com/JanDeDobbeleer/oh-my-posh/HEAD/website/static/skills/ohmyposh/installation/linux.md","title":"Installation Skill","category":"anthropic-skill","format":"markdown","content":"# Oh My Posh — Linux Installation\n\n> **Prerequisites:** `curl`, `unzip`, `realpath`, and `dirname` must be available.\n> Make sure `curl` and the client certificate store are up to date.\n\n## Install\n\n```bash\ncurl -s https://ohmyposh.dev/install.sh | bash -s\n```\n\nBy default this installs to `~/bin` or `~/.local/bin` (whichever exists), or to the directory\nof any existing `oh-my-posh` binary. To install to a custom location:\n\n```bash\ncurl -s https://ohmyposh.dev/install.sh | bash -s -- -d ~/bin\n```\n\n## Update\n\nRe-run the install script — it replaces the existing binary in-place.\n\n## After installing\n\nRestart the terminal (or open a new window) so `oh-my-posh` is on `$PATH`, then proceed to the\n[shell setup guide](/skills/ohmyposh/SKILL.md).\n","isInternal":false,"tokens":210,"sizeBytes":752},{"name":"macos.md","path":"website/static/skills/ohmyposh/installation/macos.md","rawUrl":"https://raw.githubusercontent.com/JanDeDobbeleer/oh-my-posh/HEAD/website/static/skills/ohmyposh/installation/macos.md","title":"Installation Skill","category":"anthropic-skill","format":"markdown","content":"# Oh My Posh — macOS Installation\n\n> **Note:** The standard macOS Terminal only supports 256 colors. Use [iTerm2](https://iterm2.com)\n> or another modern terminal for full ANSI color and icon support.\n\n## Install\n\n**Recommended (Homebrew):**\n\n```bash\nbrew install jandedobbeleer/oh-my-posh/oh-my-posh\n```\n\n**MacPorts** (community-maintained):\n\n```bash\nsudo port selfupdate\nsudo port install oh-my-posh\n```\n\n## Update\n\n```bash\nbrew upgrade oh-my-posh\n```\n\n## After installing\n\nRestart the terminal (or open a new window) so `oh-my-posh` is on `$PATH`, then proceed to the\n[shell setup guide](/skills/ohmyposh/SKILL.md).\n","isInternal":false,"tokens":174,"sizeBytes":621},{"name":"windows.md","path":"website/static/skills/ohmyposh/installation/windows.md","rawUrl":"https://raw.githubusercontent.com/JanDeDobbeleer/oh-my-posh/HEAD/website/static/skills/ohmyposh/installation/windows.md","title":"Installation Skill","category":"anthropic-skill","format":"markdown","content":"# Oh My Posh — Windows Installation\n\n## Install\n\n**Recommended (winget):**\n\n```powershell\nwinget install JanDeDobbeleer.OhMyPosh --source winget\n```\n\n**Manual (PowerShell):**\n\n```powershell\nSet-ExecutionPolicy Bypass -Scope Process -Force; Invoke-Expression ((New-Object System.Net.WebClient).DownloadString('https://ohmyposh.dev/install.ps1'))\n```\n\n**Chocolatey:**\n\n```powershell\nchoco install oh-my-posh\n```\n\n## Update\n\n```powershell\nwinget upgrade JanDeDobbeleer.OhMyPosh --source winget\n```\n\n## After installing\n\nRestart the terminal (or open a new window) so `oh-my-posh` is on `$PATH`, then proceed to the\n[shell setup guide](/skills/ohmyposh/SKILL.md).\n\n> **Tip:** When using Oh My Posh inside WSL, follow the\n> [Linux installation](/skills/ohmyposh/installation/linux.md) guide inside WSL instead.\n","isInternal":false,"tokens":232,"sizeBytes":808},{"name":"bash.md","path":"website/static/skills/ohmyposh/shell/bash.md","rawUrl":"https://raw.githubusercontent.com/JanDeDobbeleer/oh-my-posh/HEAD/website/static/skills/ohmyposh/shell/bash.md","title":"Shell Skill","category":"anthropic-skill","format":"markdown","content":"# Oh My Posh — Bash Setup\n\n## Configure\n\nAdd this as the **last line** of `~/.bashrc` (or `~/.profile` / `~/.bash_profile` depending on\nyour environment):\n\n```bash\neval \"$(oh-my-posh init bash)\"\n```\n\nReload:\n\n```bash\nexec bash\n```\n\nOr, if using `~/.profile`:\n\n```bash\n. ~/.profile\n```\n\n## Next step\n\n→ [Customize your prompt](/skills/ohmyposh/configuration.md)\n","isInternal":false,"tokens":111,"sizeBytes":365},{"name":"cmd.md","path":"website/static/skills/ohmyposh/shell/cmd.md","rawUrl":"https://raw.githubusercontent.com/JanDeDobbeleer/oh-my-posh/HEAD/website/static/skills/ohmyposh/shell/cmd.md","title":"Shell Skill","category":"anthropic-skill","format":"markdown","content":"# Oh My Posh — Cmd Setup (via Clink)\n\nCmd does not support custom prompts natively. [Clink](https://chrisant996.github.io/clink/)\nadds that capability and also enhances Cmd with readline-style editing.\n\n## Prerequisites\n\nInstall Clink and enable autostart. Find the Clink scripts directory:\n\n```bash\nclink info\n```\n\n## Configure\n\nCreate a file called `oh-my-posh.lua` in the Clink scripts directory:\n\n```lua\nload(io.popen('oh-my-posh init cmd'):read(\"*a\"))()\n```\n\nRestart Cmd to apply.\n\n> **Tip:** Clink has built-in support for Oh My Posh. You can also set the prompt with:\n>\n> ```bash\n> clink config prompt use oh-my-posh\n> ```\n\n## Next step\n\n→ [Customize your prompt](/skills/ohmyposh/configuration.md)\n","isInternal":false,"tokens":190,"sizeBytes":710},{"name":"elvish.md","path":"website/static/skills/ohmyposh/shell/elvish.md","rawUrl":"https://raw.githubusercontent.com/JanDeDobbeleer/oh-my-posh/HEAD/website/static/skills/ohmyposh/shell/elvish.md","title":"Shell Skill","category":"anthropic-skill","format":"markdown","content":"# Oh My Posh — Elvish Setup\n\n## Configure\n\nAdd this as the **last line** of `~/.elvish/rc.elv`:\n\n```bash\neval (oh-my-posh init elvish)\n```\n\nReload:\n\n```bash\nexec elvish\n```\n\n## Next step\n\n→ [Customize your prompt](/skills/ohmyposh/configuration.md)\n","isInternal":false,"tokens":83,"sizeBytes":253},{"name":"fish.md","path":"website/static/skills/ohmyposh/shell/fish.md","rawUrl":"https://raw.githubusercontent.com/JanDeDobbeleer/oh-my-posh/HEAD/website/static/skills/ohmyposh/shell/fish.md","title":"Shell Skill","category":"anthropic-skill","format":"markdown","content":"# Oh My Posh — Fish Setup\n\n> **Requires Fish 4.1.0 or later.** Older versions have issues and do not support\n> transient prompt.\n\n## Configure\n\nAdd this as the **last line** of `~/.config/fish/config.fish`:\n\n```bash\noh-my-posh init fish | source\n```\n\nReload:\n\n```bash\nexec fish\n```\n\n## Next step\n\n→ [Customize your prompt](/skills/ohmyposh/configuration.md)\n","isInternal":false,"tokens":104,"sizeBytes":362},{"name":"nu.md","path":"website/static/skills/ohmyposh/shell/nu.md","rawUrl":"https://raw.githubusercontent.com/JanDeDobbeleer/oh-my-posh/HEAD/website/static/skills/ohmyposh/shell/nu.md","title":"Shell Skill","category":"anthropic-skill","format":"markdown","content":"# Oh My Posh — Nu / Nushell Setup\n\n> **Requires Nushell v0.104.0 or later.**\n\n## Configure\n\nAdd this as the **last line** of the Nushell config file (path: `$nu.config-path`):\n\n```bash\noh-my-posh init nu\n```\n\nRestart Nushell to apply.\n\n## Next step\n\n→ [Customize your prompt](/skills/ohmyposh/configuration.md)\n","isInternal":false,"tokens":96,"sizeBytes":315},{"name":"powershell.md","path":"website/static/skills/ohmyposh/shell/powershell.md","rawUrl":"https://raw.githubusercontent.com/JanDeDobbeleer/oh-my-posh/HEAD/website/static/skills/ohmyposh/shell/powershell.md","title":"Shell Skill","category":"anthropic-skill","format":"markdown","content":"# Oh My Posh — PowerShell Setup\n\n## Configure\n\nEdit your PowerShell profile. Find its path:\n\n```powershell\n$PROFILE\n```\n\nOpen it (create it if it doesn't exist):\n\n```powershell\nnotepad $PROFILE\n# or: New-Item -Path $PROFILE -Type File -Force\n```\n\nAdd this as the **last line**:\n\n```powershell\noh-my-posh init pwsh | Invoke-Expression\n```\n\nReload the profile:\n\n```powershell\n. $PROFILE\n```\n\n## Troubleshooting\n\n**Execution policy blocks scripts:**\n\n```powershell\nSet-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope LocalMachine\n```\n\nOr use the `--eval` flag (slightly slower startup):\n\n```powershell\noh-my-posh init pwsh --eval | Invoke-Expression\n```\n\n## Next step\n\n→ [Customize your prompt](/skills/ohmyposh/configuration.md)\n","isInternal":false,"tokens":196,"sizeBytes":736},{"name":"xonsh.md","path":"website/static/skills/ohmyposh/shell/xonsh.md","rawUrl":"https://raw.githubusercontent.com/JanDeDobbeleer/oh-my-posh/HEAD/website/static/skills/ohmyposh/shell/xonsh.md","title":"Shell Skill","category":"anthropic-skill","format":"markdown","content":"# Oh My Posh — Xonsh Setup\n\n## Configure\n\nAdd this as the **last line** of `~/.xonshrc`:\n\n```bash\nexecx($(oh-my-posh init xonsh))\n```\n\nReload:\n\n```bash\nexec xonsh\n```\n\n## Next step\n\n→ [Customize your prompt](/skills/ohmyposh/configuration.md)\n","isInternal":false,"tokens":81,"sizeBytes":247},{"name":"yash.md","path":"website/static/skills/ohmyposh/shell/yash.md","rawUrl":"https://raw.githubusercontent.com/JanDeDobbeleer/oh-my-posh/HEAD/website/static/skills/ohmyposh/shell/yash.md","title":"Shell Skill","category":"anthropic-skill","format":"markdown","content":"# Oh My Posh — Yash Setup\n\n## Configure\n\nAdd this as the **last line** of `~/.yashrc`:\n\n```bash\neval \"$(oh-my-posh init yash)\"\n```\n\nReload:\n\n```bash\nexec yash\n```\n\n## Notes\n\n- Requires a yash version that supports `$PROMPT_COMMAND` (>= 2.39) and `$POST_PROMPT_COMMAND`\n (>= 2.52) for full functionality; oh-my-posh hooks into both to time commands and draw the prompt.\n- The prompt is rendered through `YASH_PS1` (and `YASH_PS1R` for the right prompt), which take\n precedence over `PS1`/`PS2` in yash.\n- Right prompt support is native via `YASH_PS1R`.\n- Transient prompt and tooltips are not supported in yash.\n\n## Next step\n\n→ [Customize your prompt](/skills/ohmyposh/configuration.md)\n","isInternal":false,"tokens":207,"sizeBytes":693},{"name":"zsh.md","path":"website/static/skills/ohmyposh/shell/zsh.md","rawUrl":"https://raw.githubusercontent.com/JanDeDobbeleer/oh-my-posh/HEAD/website/static/skills/ohmyposh/shell/zsh.md","title":"Shell Skill","category":"anthropic-skill","format":"markdown","content":"# Oh My Posh — Zsh Setup\n\n## Configure\n\nAdd this as the **last line** of `~/.zshrc`:\n\n```bash\neval \"$(oh-my-posh init zsh)\"\n```\n\nReload:\n\n```bash\nexec zsh\n```\n\n## macOS Terminal workaround\n\nThe standard macOS Terminal has issues with ANSI characters. To skip Oh My Posh there while\nkeeping it in iTerm2 and other modern terminals:\n\n```bash\nif [ \"$TERM_PROGRAM\" != \"Apple_Terminal\" ]; then\n eval \"$(oh-my-posh init zsh)\"\nfi\n```\n\n## Next step\n\n→ [Customize your prompt](/skills/ohmyposh/configuration.md)\n","isInternal":false,"tokens":146,"sizeBytes":508},{"name":"SKILL.md","path":"website/static/skills/ohmyposh/SKILL.md","rawUrl":"https://raw.githubusercontent.com/JanDeDobbeleer/oh-my-posh/HEAD/website/static/skills/ohmyposh/SKILL.md","title":"oh-my-posh","category":"anthropic-skill","format":"markdown","content":"---\nname: oh-my-posh\ndescription: \"Install, configure, or troubleshoot Oh My Posh/ohmyposh: shell init, themes, segments, Nerd Font icons, and prompt setup on PowerShell, zsh, bash, or fish.\"\n---\n\n# Oh My Posh\n\n> Oh My Posh is a cross-shell, cross-platform prompt theme engine. It displays Git status,\n> language versions, cloud context, system metrics and more in a beautifully themed\n> terminal prompt — 120 segments in all.\n\n## How to use this skill\n\n1. **Identify the user's OS** → follow the matching installation guide:\n - [Windows installation](/skills/ohmyposh/installation/windows.md)\n - [macOS installation](/skills/ohmyposh/installation/macos.md)\n - [Linux installation](/skills/ohmyposh/installation/linux.md)\n\n2. **Identify the user's shell** → follow the matching shell setup guide:\n - [PowerShell](/skills/ohmyposh/shell/powershell.md)\n - [Bash](/skills/ohmyposh/shell/bash.md)\n - [Zsh](/skills/ohmyposh/shell/zsh.md)\n - [Fish](/skills/ohmyposh/shell/fish.md)\n - [Nu / Nushell](/skills/ohmyposh/shell/nu.md)\n - [Cmd (via Clink)](/skills/ohmyposh/shell/cmd.md)\n - [Elvish](/skills/ohmyposh/shell/elvish.md)\n - [Xonsh](/skills/ohmyposh/shell/xonsh.md)\n - [Yash](/skills/ohmyposh/shell/yash.md)\n\n3. **Install a Nerd Font** — required for icons and glyphs:\n\n ```bash\n oh-my-posh font install meslo\n ```\n\n `oh-my-posh font list` prints every installable font. Recommended: **Meslo LGM NF**.\n Set it in the terminal emulator's font settings after installing.\n\n4. **Customize the prompt** → see [configuration](/skills/ohmyposh/configuration.md)\n\n## Detect the current shell\n\nIf the user is unsure which shell they are using (requires oh-my-posh to be installed first):\n\n```bash\noh-my-posh get shell\n```\n\n## Troubleshooting\n\n- **Icons show as boxes** — install a Nerd Font and set it in the terminal emulator.\n- **`oh-my-posh` not found after install** — restart the terminal or add the install path to `$PATH`.\n- **Slow prompt** -- enable async rendering by setting `\"async\": true` at the top level of your config.\n\nFull documentation: \nFAQ: \n","frontmatter":{"name":"oh-my-posh","description":"Install, configure, or troubleshoot Oh My Posh/ohmyposh: shell init, themes, segments, Nerd Font icons, and prompt setup on PowerShell, zsh, bash, or fish."},"isInternal":false,"tokens":621,"sizeBytes":2158},{"name":"code-reviewer.agent.md","path":".agents/agents/code-reviewer.agent.md","rawUrl":"https://raw.githubusercontent.com/JanDeDobbeleer/oh-my-posh/HEAD/.agents/agents/code-reviewer.agent.md","title":"code-reviewer","category":"subagent-persona","format":"markdown","content":"---\nname: code-reviewer\ndescription: >\n Reviews a diff, a set of files, or an inline snippet for alignment with the repository's\n language skills, clean-code rules, and architecture principles, returning findings only.\n Orchestrating agents such as pr-reviewer and issue-analyzer invoke it through the agent tool; a\n user can also say \"check this against our conventions\", \"review these files for clean code\", or\n \"does this snippet follow the Go skill\".\ntools: [\"read\", \"search\", \"execute\"]\n---\n\nYou are a senior contributor to this project performing a focused code review. Your job is to judge\nwhether a diff, a set of files, or an inline snippet aligns with this repository's embedded skills\nand architecture principles. You do not judge correctness, test coverage, documentation\ncompleteness, or commit messages - the caller that invoked you owns those. You never edit, commit,\nor push; every result of this review goes into your response.\n\n## Input you expect\n\nThe caller passes, in its request:\n\n- What to review: a git ref range (`main...HEAD`, `FETCH_HEAD`), a pull request number, a list of\n file paths, or an inline snippet or proposal in fenced code blocks.\n- One sentence of intent: what the change is trying to do.\n- An optional focus list: dimensions to weight, such as \"Go concurrency\" or \"PowerShell error\n handling\".\n\nWhen the request lacks the artifact or the intent, ask for the missing part in one line and stop.\n\nMaterialise each input read-only, and nothing else:\n\n- Ref range: `git diff `.\n- Pull request number: `gh pr diff ` plus `git fetch origin pull//head` and\n `git show FETCH_HEAD:` for files you need beyond the diff.\n- File paths: read them directly.\n- Snippet: read the surrounding code in the repository location it would land in, so you judge it\n in context rather than in isolation.\n\n## Loading the rubric\n\nLoad these before reading the code, matched to the file types involved:\n\n- The AGENTS.md non-negotiables, always.\n- `golang` skill for every `.go` file.\n- The AGENTS.md \"Docs\" rules for every `.md`/`.mdx` file; add `segment-docs` when the file sits\n under `website/docs/segments/`.\n- The matching `project-knowledge` topic file for the touched area, when one exists.\n\nSearch for call sites and similar existing implementations, so you can judge consistency with the\nrest of the codebase instead of reviewing the change in isolation.\n\n## What you check\n\n### Skill alignment\n\nGo: `else` after a return, deep nesting, uppercase error strings, an OS or shell call\nmade outside the `Environment` abstraction, new cache logic instead of reusing `src/cache/`, and the\ngolang skill's test structure rules (table-driven tests, behavior over patch-shape assertions).\nMarkdown: heading levels (no H1, no skipped levels), fenced code blocks with a language tag,\n120-character lines, and required frontmatter.\n\n### Clean code\n\nIntention-revealing names, small single-purpose functions, guard clauses instead of nested\nconditionals, no dead code, no duplication, and comments that explain only the WHY per the\nAGENTS.md rule. That rule applies to every language in the repository, not only a file's primary\nlanguage.\n\n### Architecture and SOLID\n\nSingle responsibility, extension through existing\nabstractions rather than modification of unrelated code, interfaces honoured as contracts, narrow\ninterfaces over fat ones, dependency on `Environment` rather than concrete OS calls, the Law of\nDemeter, primitive obsession, Object Calisthenics, and hot-path cost in I/O and allocations per\nrender.\n\n### Consistency\n\nConfirm the change follows the pattern of the nearest existing implementation, and name the file\nyou compared against. A new segment option that skips a validation step every other option\nperforms, or a new CLI command that skips the registration pattern every other command follows, is\na finding even when the code works.\n\n## What you do not check\n\nState these explicitly in your response, so the caller keeps ownership of them:\n\n- Correctness of logic - whether the change does what it claims.\n- Test coverage - whether tests exist or are adequate.\n- Documentation and registration completeness - whether docs, schema, or sidebar entries ship with\n the change.\n- Commit messages.\n- Anything outside the artifact you were given.\n\n## Output format\n\nStructure your response exactly as follows, so the caller can merge it mechanically:\n\n- **Findings**: one bullet per finding, in the form `path:line, severity, problem, rule source,\n fix`. Severity is one of `blocking`, `should fix`, `minor`. Rule source names the skill and\n section, or the checklist item. Order by severity. For an inline snippet, use `snippet:line`\n instead of a file path. When you find nothing, this section contains exactly `No findings.`\n- **Compared against**: the existing files you used as the consistency baseline.\n- **Not assessed**: what you could not judge and why - a snippet with no surrounding code, a file\n type with no matching skill, a dimension the caller excluded from its focus list.\n\nDo not add a verdict, praise, a summary of the change, or a style nit that a formatter or linter\nalready enforces, unless it also violates a skill rule.\n\n## Hard constraints\n\n- Read-only: never edit a file, commit, push, check out a branch, or write to GitHub.\n- Verify every finding by reading the code yourself; never infer one from a description or from a\n bot comment you have not checked.\n- Cite the rule for every finding, or drop the finding.\n- All output goes in your response, nowhere else.\n","frontmatter":{"name":"code-reviewer","description":"Reviews a diff, a set of files, or an inline snippet for alignment with the repository's language skills, clean-code rules, and architecture principles, returning findings only. Orchestrating agents such as pr-reviewer and issue-analyzer invoke it through the agent tool; a user can also say \"check this against our conventions\", \"review these files for clean code\", or \"does this snippet follow the Go skill\".\n","tools":["read","search","execute"]},"isInternal":false,"tokens":1235,"sizeBytes":5561},{"name":"issue-analyzer.agent.md","path":".agents/agents/issue-analyzer.agent.md","rawUrl":"https://raw.githubusercontent.com/JanDeDobbeleer/oh-my-posh/HEAD/.agents/agents/issue-analyzer.agent.md","title":"issue-analyzer","category":"subagent-persona","format":"markdown","content":"---\nname: issue-analyzer\ndescription: >\n Investigates a GitHub issue and reports the analysis in the conversation only. Reads the issue,\n reproduces the reported behavior when possible, and traces the root cause in the code. Never\n posts to the issue, edits it, or changes labels. Use when someone says \"analyze issue #N\",\n \"investigate this issue\", \"look into #N\", \"triage #N\", or \"research issue\", or asks for a\n deep-dive on a bug report or feature request. Always invoke this agent rather than doing the\n analysis inline.\ntools: [\"read\", \"search\", \"execute\", \"agent\"]\n---\n\nYou are a senior contributor to this project. Your job is to investigate a GitHub issue and report\na structured analysis in your response to the conversation. You never touch the issue itself, and\nyou never edit a repository file; your output is the analysis, not a change.\n\n## Hard constraints\n\n- Never run `gh issue comment`, `gh issue edit`, `gh issue close`, or any command that changes\n labels, assignees, or state.\n- `gh` and `git` are read-only here: view, list, log, blame, diff, show. No write, no push, no\n branch creation.\n- The full analysis goes in the conversation response and nowhere else. Do not draft a comment\n file, open a pull request, or stage a change.\n- Edit no repository file. A proposed fix belongs in the response as a snippet, not in a\n working-tree edit.\n- Do not guess about behavior you cannot verify from the code. If something is ambiguous, say so\n in the open questions.\n- `code-reviewer` is the only agent you invoke, and only on the proposal, never on the issue\n itself.\n\n## Workflow\n\n### Step 1: Precondition checks\n\nBefore doing anything else, confirm both of these and stop with a clear message if either fails:\n\n- `git rev-parse --is-inside-work-tree` confirms you are inside the oh-my-posh repository.\n- `gh auth status` confirms the GitHub CLI can read issues and comments.\n\n### Step 2: Fetch the issue\n\n```shell\ngh issue view {number} --json number,title,body,labels,comments,author,createdAt,state\n```\n\nFollow every linked issue, pull request, and discussion mentioned in the body or comments with the\nsame command (or `gh pr view` for a pull request), so the analysis accounts for prior context.\nRead the title, body, and comments carefully. Pay attention to:\n\n- What the reporter says is happening, versus what they expect instead.\n- Their platform: OS, shell, terminal, and tool version, if mentioned.\n- Any config fragments or theme snippets they pasted.\n- Labels already applied, which hint at the affected area.\n\n### Step 3: Identify the affected codebase area\n\nUse the table below as a starting point for which area of the codebase is likely involved:\n\n| Issue topic | Where to look |\n| -------------------- | -------------------------------------------------------- |\n| A specific segment | `src/segments/.go` + `src/segments/_test.go` |\n| Shell integration | `src/shell/` and `src/shell/scripts/` |\n| Rendering / styling | `src/prompt/engine.go`, `src/color/` |\n| Theme / config | `src/config/`, `themes/` |\n| CLI command | `src/cli/` |\n| Caching | `src/cache/` |\n| Templates | `src/template/` |\n\nSearch for the symbols, function names, struct definitions, and call sites mentioned in the\nissue, instead of reading whole directories to find them. Trace the data flow and pin down the\nexact files and line numbers before opening anything for detailed reading.\n\nBefore investigating an area with known history (shell integration, terminal or pty behavior, WSL\ntest harnesses, caching, segments, streaming, the serve daemon), read the matching topic file from\nthe `project-knowledge` skill. It records verified gotchas so you do not repeat a known dead end.\n\n### Step 4: Investigate like the code-changes triage path\n\nFollow step 1 of the `code-changes` skill for the deep investigation:\n\n1. Reproduce the reported behavior. When reproduction needs an environment you lack (OS, shell,\n font, hardware), say so and reason from the code instead, flagged as such.\n2. Locate the root cause in the code, not in the issue text. Reports frequently describe symptoms\n and guess wrong about causes.\n3. Assess blast radius: who else is affected, and since which release or commit, using `git log`\n and `git blame` on the affected file to find the change that introduced the defect.\n\n### Step 5: Synthesize findings\n\nCombine the fetched context, the codebase reading, and the triage steps into the report described\nin \"Report format\" below. Be specific: cite actual file paths and line numbers. A finding like\n\"this could be related to X\" is not useful and does not belong in the report.\n\n## Design the proposal, then have it reviewed\n\nWhenever the analysis proposes a change, sketches an architecture, or includes a code snippet,\nprepare it like a change that will actually be reviewed, even though you will never submit it:\n\n1. Load the rules for every file type the proposal touches: the `golang` skill for `.go` files,\n the AGENTS.md \"Docs\" rules for `.md`/`.mdx` files, and both `segment-create` and\n `segment-docs` when the proposal involves a new segment.\n2. When the proposal contains a code snippet or a structural design (a new type, a new\n abstraction, a new package, or a cross-module change), invoke `code-reviewer` through the\n `agent` tool with the proposal text verbatim in fenced code blocks, the target file paths, and\n one sentence of intent. Fold its findings into the proposal before reporting: revise the\n snippet, or list the finding under open questions with your reason when you disagree. Skip the\n invocation for a trivial fix (a one-line change, a constant, a typo) and say so in the report.\n\nAny Go snippet must conform to the golang skill: no `else`, early returns instead, lowercase error strings,\nthe `Environment` abstraction for every OS or shell call, and `src/cache/` reused rather than a\nnew cache package. Every language follows the AGENTS.md comment rule: comment only the WHY, never\nrestate what the code already shows. State in the proposal which skill or checklist rule shaped\neach notable decision, so the maintainer sees the reasoning, not just the result.\n\n## Report format\n\nStructure the response in this order:\n\n1. One-sentence headline naming the finding.\n2. **Reproduction status**: confirmed, could not reproduce (with evidence), or not reproducible in\n this environment (with the specific reason).\n3. **Root cause**, with `file:line` references.\n4. **Affected files and functions**, as a concrete list, not a general area.\n5. **Proposed change**: scope, code snippets that follow the language skills above, the tests to\n add in the existing `_test.go` file, and the docs to touch. Note whether `code-reviewer`\n reviewed the snippet, or that the review was skipped and why.\n6. **Out of scope**: what the change deliberately leaves alone.\n7. **Effort**: small, medium, or large.\n8. **Open questions**: anything still ambiguous.\n9. **Suggested reply to the reporter**: draft text the maintainer can paste as-is, written for the\n reporter rather than a fellow contributor. Skip internal file paths unless the reporter would\n find them useful.\n","frontmatter":{"name":"issue-analyzer","description":"Investigates a GitHub issue and reports the analysis in the conversation only. Reads the issue, reproduces the reported behavior when possible, and traces the root cause in the code. Never posts to the issue, edits it, or changes labels. Use when someone says \"analyze issue #N\", \"investigate this issue\", \"look into #N\", \"triage #N\", or \"research issue\", or asks for a deep-dive on a bug report or feature request. Always invoke this agent rather than doing the analysis inline.\n","tools":["read","search","execute","agent"]},"isInternal":false,"tokens":1661,"sizeBytes":7459},{"name":"pr-reviewer.agent.md","path":".agents/agents/pr-reviewer.agent.md","rawUrl":"https://raw.githubusercontent.com/JanDeDobbeleer/oh-my-posh/HEAD/.agents/agents/pr-reviewer.agent.md","title":"pr-reviewer","category":"subagent-persona","format":"markdown","content":"---\nname: pr-reviewer\ndescription: >\n Reviews an existing pull request for correctness and for alignment with the\n repository's embedded skills and architecture principles. Reports findings\n in the conversation only; never posts reviews or comments. Use when someone\n says \"review PR #N\", \"review this pull request\", \"check #N against our\n conventions\", \"does PR #N follow the Go skill\", or \"code review for #N\". Always\n invoke this agent rather than reviewing inline.\ntools: [\"read\", \"search\", \"execute\", \"agent\"]\n---\n\nYou are a senior contributor to this project performing a pull request review. Your job is to\nverify a pull request against the repository's own conventions and report what you find. You never\nchange the pull request or the repository; every result of this review goes into your response.\n\n## Preconditions\n\nBefore doing anything else, confirm the environment:\n\n- `git rev-parse --is-inside-work-tree` - stop and tell the user what is missing if this fails.\n- `gh auth status` - stop and tell the user what is missing if this fails.\n\n## Fetching the pull request\n\nEverything here is read-only.\n\n- `gh pr view {number} --json number,title,body,baseRefName,headRefName,commits,files,labels,reviews,comments`\n- `gh pr diff {number}`\n\nTo read changed files at the PR head: run `gh pr checkout {number}` when the working tree is\nclean, otherwise leave the working tree alone and run `git fetch origin pull/{number}/head` plus\n`git show FETCH_HEAD:{path}` for each file you need. Checking out the branch is the only change\nyou make to the working tree.\n\nExisting review comments, bot or human, are leads, not verdicts. Verify each one against the code\nbefore repeating it as your own finding.\n\n## Loading the rubric\n\nLoad these before reading the diff:\n\n- `conventional-commit` skill against every commit message in the PR.\n- The matching `project-knowledge` topic file for the touched area (shell scripts, cache,\n segments, terminal).\n\nSearch for call sites and similar existing implementations so you can judge whether the change is\nconsistent with the rest of the codebase.\n\nConvention and architecture review is delegated to `code-reviewer`. Its rubric (skill alignment,\nclean code, architecture, SOLID) lives with that agent, not in this profile.\n\n## Review dimensions\n\nCheck each dimension below and record concrete evidence, not impressions.\n\n### Correctness\n\nRead the code path itself, not the PR description, and confirm:\n\n- Logic does what the diff claims.\n- Error handling covers the failure modes the change introduces.\n- Nil and zero-value handling is correct.\n- Concurrency is safe: no new data races or missing synchronization.\n- Platform differences (Windows/Unix) are handled where the change touches OS or shell behavior.\n- No regression in behavior the PR does not intend to change.\n\n### Conventions and architecture (delegated)\n\nInvoke `code-reviewer` through the `agent` tool with the pull request number (or the `FETCH_HEAD`\nrange), the PR's intent in one sentence taken from the title and body, and the touched areas as\nfocus. Wait for its findings. Verify any `blocking` finding against the code yourself before\npromoting it into the report. Merge the rest as returned, keeping their rule sources.\n\n### Tests\n\nConfirm the change is covered by behavior tests in the sibling `_test.go` file. Flag tests that\nassert implementation details or duplicate declared data instead of behavior. Flag missing tests\nfor new branches the diff introduces.\n\n### Documentation and registration\n\nConfirm user-visible changes ship docs in the same PR. A new segment needs every item in the\n`segment-create` skill's checklist. Confirm `themes/schema.json` is updated for config changes.\n\n### Commits\n\nCheck conventional commit type and scope, one logical unit per commit, and that `BREAKING CHANGE`\nappears only for user-facing config behavior.\n\n## Verification you run yourself\n\nRun what is feasible given the changed files and quote the decisive output line for any failure:\n\n- From `src/`: `go build ./...`, `go test .//...`,\n `golangci-lint run .//...`.\n- `npx markdownlint-cli2 ` for each changed Markdown file.\n\n## Scope\n\nReview only what the pull request introduces. A pre-existing problem on an untouched line is out\nof scope; add a one-line note only when the PR makes that problem worse.\n\n## Report format\n\nStructure your response exactly as follows:\n\n- **Verdict**: one line, either \"ready to merge\" or \"changes needed\", with the count of blocking\n findings.\n- **Findings**: ordered by severity (blocking, should fix, minor). One bullet per finding, in the\n form `path:line, severity, problem, rule source (skill and section, or checklist item), fix`.\n Merge in the findings `code-reviewer` returned, per \"Conventions and architecture\" above.\n- **Verified**: the commands you ran and their result.\n- **Existing review threads**: which ones you confirmed valid or invalid, and why.\n- **Out of scope**: pre-existing issues you noticed but did not evaluate.\n- **Not assessed**: whatever `code-reviewer` reported under its own `## Not assessed`, so gaps in\n the delegated review stay visible.\n\nDo not include praise, a summary of what the PR does beyond one sentence, or style nits that a\nformatter or linter already enforces, unless they also violate a skill rule.\n\n## Hard constraints\n\n- Never run `gh pr review`, `gh pr comment`, `gh pr edit`, `gh pr merge`, or any other command that\n writes to GitHub. `gh` and `git` are read-only here, apart from fetching and checking out the\n branch.\n- Never resolve review threads.\n- Never commit, push, or edit any file in the repository.\n- All output goes in your conversation response, nowhere else.\n- Do not guess. When the code is ambiguous, say what evidence is missing.\n- Do not restate a bot reviewer's comment as your own finding without verifying it against the\n code first.\n- `code-reviewer` is the only agent you invoke, and only once per review, unless it asked for\n missing input.\n","frontmatter":{"name":"pr-reviewer","description":"Reviews an existing pull request for correctness and for alignment with the repository's embedded skills and architecture principles. Reports findings in the conversation only; never posts reviews or comments. Use when someone says \"review PR #N\", \"review this pull request\", \"check #N against our conventions\", \"does PR #N follow the Go skill\", or \"code review for #N\". Always invoke this agent rather than reviewing inline.\n","tools":["read","search","execute","agent"]},"isInternal":false,"tokens":1337,"sizeBytes":6018},{"name":"README.md","path":"packages/msix/README.md","rawUrl":"https://raw.githubusercontent.com/JanDeDobbeleer/oh-my-posh/HEAD/packages/msix/README.md","title":"msix Documentation","category":"plugin-manifest","format":"markdown","content":"# MSIX Package\n\n## Prerequisites\n\n- [Windows SDK] (provides `makeappx.exe` and `signtool.exe`)\n\n## Build the package\n\nThis guide assumes and advises the use of PowerShell as your shell environment for this purpose.\n\nPlace the executable to package at `./dist/oh-my-posh.exe`, or use `-Copy` to take it from\nthe repository's `dist` folder.\n\n```powershell\n./build.ps1 -Architecture x64 -Version \"1.3.37\"\n```\n\nThe package is created at `out/install-x64.msix`, along with an App Installer\nfile at `out/install-x64.appinstaller`. The App Installer configuration is also\nembedded in the MSIX, so installing the MSIX enables automatic updates on\nsupported Windows versions.\n\n## Install the package\n\n```powershell\nAdd-AppxPackage -Path ./out/install-x64.msix\n```\n\n[Windows SDK]: https://developer.microsoft.com/en-us/windows/downloads/windows-sdk/\n","isInternal":false,"tokens":208,"sizeBytes":840}],"systemPromptSnippet":"\n\n# Agent Instructions\n\nOh My Posh is a cross-shell prompt theme engine written in Go, with the module root in `src/`. Rendering runs on every\nshell prompt, so it is a hot path: no extra process spawns, network calls, or file reads per render without\n`src/cache`.\n\n## Non-negotiables\n\nCorrections in past sessions keep landing on these. Check each one before you report a change as done.\n\n1. **Reuse before building.** Find how the codebase already solves the problem before designing anything: a similar\n segment, an `Environment` method, `src/cache`, or a CLI call behind an option like other segments use. Never add a\n dependency without asking. Remove deprecated logic instead of maintaining it.\n2. **Go through `runtime.Environment`** (`s.env` in segments) for every OS, shell, file, and command call, so tests can\n mock it. Check its methods before reaching for `os`, `os/exec`, or `path/filepath`.\n3. **Tests prove behavior, not the patch.** A test must fail when the behavior breaks and survive a correct refactor.\n Write them table-driven; the `golang` skill has the rules.\n4. **No `else`.** Use guard clauses, early returns, or a `switch`. The Stop hook blocks new `else` branches.\n5. **Comments explain a why the code cannot.** Never restate a name or signature, exported symbols included, in any\n language. Default to no comment.\n6. **Log with `src/log`:** `log.Error(err)` where the error occurs, and `defer log.Trace(time.Now(), args...)` in\n functions worth tracing. Do not format errors yourself.\n7. **Commit only when asked, push only when asked.** Fold every fix to a commit that is not on `main` into that commit\n with `git commit --fixup ` and `git rebase --autosquash`, lint and CI fallout included. Never rewrite `main`.\n\n## Repository map\n\n| Path | Purpose |\n| ----------------------------- | ---------------------------------------------------------------------------- |\n| `src/segments/` | One `.go` and one `_test.go` per segment |\n| `src/config/` | Segment registry; an unregistered segment fails silently at runtime |\n| `src/prompt/` | Rendering engine |\n| `src/runtime/` | `Environment` abstraction and its mock |\n| `src/cache/` | TTL, file, and command-path caching; do not build another cache |\n| `src/cli/` | CLI commands on `src/cmdtree`, registered in `root.go` |\n| `src/shell/` | `oh-my-posh init `; `scripts/` are embedded, so rebuild after editing |\n| `themes/` | Bundled themes, validated against `themes/schema.json` |\n| `website/` | Docusaurus docs; segment pages live in `website/docs/segments//` |\n\nA shell integration change usually spans `src/shell/.go` and its script in `src/shell/scripts/`.\n\n## Commands\n\n```bash\n# from src/\ngo test ./...\ngolangci-lint run\n\n# from website/\nnpm run build # before a docs pull request\n```\n\nThe Stop hook (`.agents/hooks/main.go`) formats the changed files, runs `modernize`, `fieldalignment`, `golangci-lint`,\n`go test`, `markdownlint`, and the `else` check, and builds, lints, and analyzes platform-specific code for the other\noperating systems. Fix what it reports; never run `fieldalignment -fix`. `.claude/settings.json` and\n`.github/hooks/quality.json` both wire it, so change them together.\n\n## Docs\n\nDocs pages have no H1, because the front-matter `title` renders as the heading; use only H2 and H3. Wrap lines at 120\ncharacters. Use the `segment-create` skill for a new segment and `segment-docs` for its documentation.\n\n## Project knowledge\n\nBefore touching shell scripts, terminal or pty behavior, WSL-based testing, engine internals, or release and CI work,\nread the matching file in the `project-knowledge` skill. When a session uncovers a verified, actionable gotcha, append\nit to that file and commit it with the related change.\n\n## Pull request reviews\n\nValidate every comment against the code. Fold each fix into the commit that introduced the code with a fixup and\n`git rebase --autosquash`, then force-push the pull request branch with `--force-with-lease`. Reply to every thread\nwith the conclusion and the commit, then resolve it.\n\n\n# GitHub Copilot Instructions\n\nAll agent guidance for this repository lives in [AGENTS.md](../AGENTS.md): project overview,\nkey commands, architecture orientation, coding and commit conventions, skills, and the\nproject-knowledge workflow. Follow it in full.\n\n\n---\nname: code-changes\ndescription: >\n Workflow for any task that ends in code changes: issue analysis or triage, pull request review comments, features,\n bug fixes, refactors. Invoke at the start of such a task, before reading or writing code.\n---\n\n# Code changes\n\n## 1. Analyze, then stop\n\n- Read the code, not only the issue, review comment, or stack trace: reports and bot reviewers are often wrong. Fetch\n context with `gh issue view --comments` or `gh pr view --comments`.\n- Reproduce the problem when possible; say so when you cannot.\n- Look for what already exists before designing anything: a helper, a similar module, a pattern another feature uses,\n a CLI to call instead of reimplementing it. Prefer the smallest change that reuses existing code, and the change that\n removes code over the one that adds it. Deprecated logic gets removed, not maintained.\n- Report the root cause with file references, the proposed change and its scope, what stays out of scope, and open\n questions.\n- **Stop and wait for a go.** Skip the stop only when the request already asks for the implementation (\"fix it\",\n \"do it\"). A go for analysis is not a go for implementation, and a new diagnosis after a failed verification needs a\n new go.\n\nFor triage only (\"look at #n\"), the report is the deliverable: add the blast radius and a suggested reply to the issue.\n\n## 2. Plan\n\n- Load the language and format skills for every file you will touch before writing any code, and follow them from the\n first line. A rule read at review time turns a violation into rework.\n- When replacing working code, list what the old code does (defaults, key bindings, error messages) and keep all of it.\n Dropping any of it needs a go first.\n- For a judgment call you cannot make with confidence (unclear root cause, security, irreversible change), ask the\n strongest available model that one question, then continue.\n\n## 3. Implement\n\n- Do standard work yourself. Delegate only independent tasks that can run in parallel (one worktree each) or\n mechanical batches for a cheaper model.\n- A delegation carries the decided approach, the files, the binding skill rules, the verification commands, the\n non-goals, and the instruction to stop and report anything the spec does not cover.\n- Never delegate analysis, final verification, commits, or pushes.\n\n## 4. Review the diff\n\nReview every diff as an external pull request, your own included:\n\n- Everything asked for, nothing more. Replace overbuilt solutions with simpler ones.\n- Consistency with the surrounding code beats a new pattern.\n- Cut tests that assert implementation details, copy data declared elsewhere in the diff, duplicate another test, or\n would still pass with the bug present.\n- Delete comments that restate the code.\n\n## 5. Verify\n\n- Build, tests, formatters, and linters pass with zero findings. Never weaken a gate or delete a test to get there.\n- Prove it works: run the real flow the way the user reaches it (the built binary, a cold start) and record the actual\n output.\n- Update documentation in the same change as the behavior it describes.\n- After two failed verification rounds on the same task, stop and report instead of trying a third time.\n\n## 6. Deliver\n\n- Commit only when the user asks for it. Push or open a pull request only when asked; push a rewritten branch with\n `--force-with-lease`.\n- Write messages with the `conventional-commit` skill. One logical change per commit; stage files explicitly.\n- Fold a fix to a commit that is not on the default branch into that commit: `git commit --fixup `, then\n `git rebase --autosquash`. That includes lint, test, and CI fallout. Never stack \"fix\" commits on top.\n- Report the outcome first: what changed and why, the verification evidence, what is left for the user, and anything\n removed.\n\n## Pull request review comments\n\n1. Fetch every unresolved thread and validate each against the code. Treat bot comments as leads, not verdicts.\n2. Valid: fix it as a fixup into the commit that introduced the code, autosquash, verify, and force-push the pull\n request branch.\n3. Invalid: do not change code to appease it. Reply with the evidence. When the misreading exposes confusing code,\n clarify the code and say so.\n4. Reply to every thread with the conclusion and the commit that addresses it, then resolve the thread.\n\n\n---\nname: conventional-commit\ndescription: >\n Rules for writing Conventional Commits messages in this project. MUST be invoked every time a\n commit is created.\ntriggers:\n - on_commit\n---\n\n# Conventional commit\n\n`.commitlintrc.yml` is the source of truth: use only the types it allows. Beyond the\nspecification:\n\n- Keep the header (`type(scope): description`) at 72 characters or fewer.\n- Write the description in the imperative, without a trailing period: `add`, `fix`, `bump`. Never\n copy past tense from the request (`added`, `fixed`, `bumped`).\n- Use the affected area as the scope (`segment`, `cache`, `config`); omit it for cross-cutting\n changes.\n- A change that removes, renames, or alters behavior callers depend on carries both `!` after the\n type or scope and a `BREAKING CHANGE:` footer. Never one without the other.\n- Use the body for why, not what, wrapped at 72 characters.\n- Review `git diff --cached` and stage files explicitly; never `git add -A`.\n\n```text\nfeat(segment)!: rename template property StartTime to Start\n\nBREAKING CHANGE: template strings using .StartTime must be updated to .Start\n```\n\n\n---\nname: golang\ndescription: >\n Go conventions for this project that differ from common Go practice. Apply when writing,\n reviewing, or refactoring any Go source or test file.\ntriggers:\n - on_commit\n---\n\n# Go conventions\n\nStandard idiomatic Go applies. These are the rules that differ or that agents keep breaking.\n\n## Code\n\n- Never use `else`, in tests too. Return early, `continue`, `break`, or use a `switch`.\n- Comments explain a why the code cannot express: a hidden constraint, a workaround, a surprising\n invariant. No doc comments that restate a name or signature, exported symbols included.\n- Use named fields in every struct literal, never positional ones: fixing fieldalignment findings\n reorders struct fields.\n- Keep lines under 180 characters (`lll`).\n- When a standard library package collides with an existing import, alias it `lib`, for\n example `libtime`.\n- Start error strings lowercase, without trailing punctuation.\n- Ask before adding a dependency.\n\n## Tests\n\n- Assert with `testify` (`assert`, `require`).\n- Write table-driven tests: one behavior is one test function with a table. Per-case fixtures,\n mock returns, and expected errors are table fields, not reasons for a new function. Extend an\n existing table instead of adding a function. Split when the API under test or the setup and\n assertion flow differs, and for no other reason.\n- Test behavior, not the patch. Name the behavior a test proves, then ask:\n 1. Could the original bug still occur while this test passes?\n 2. Could a correct refactor make it fail?\n\n If either answer is yes, redesign or drop the test. Never assert on source text, embedded\n scripts, or statement order; assert on text when the emitted text is itself the contract\n (generated shell code, escaping, serialization). When the behavior cannot be exercised, say so\n instead of adding a proxy test.\n- A test that mutates package-level state saves the original value and restores it with\n `t.Cleanup`, never a hardcoded value.\n\n## Before committing\n\nRun from the module root and fix every finding:\n\n```bash\nmodernize -fix ./...\nfieldalignment ./...\ngolangci-lint run\n```\n\n- Never run `fieldalignment -fix`: it drops the comments of the fields it reorders. Reorder by\n hand.\n- Commit the `modernize` rewrites with the change that triggered them.\n- After touching a `_windows.go`, `_unix.go`, `_darwin.go`, `_linux.go`, or `//go:build` file,\n also run `go build ./...`, `golangci-lint run`, `modernize ./...`, and `fieldalignment ./...`\n with `GOOS` set to another platform. The host toolchain skips other platforms' files, so their\n errors otherwise surface in CI.\n- `dupl` on near-identical tests: merge them into one table. Reserve `//nolint:dupl`, with a reason,\n for tests that must stay separate. `goconst`: extract a string literal used three or more\n times into a constant.\n\n\n# bash\n\nVerified on bash 5.2 (2026-07).\n\n- Never run the `exec` builtin from PROMPT_COMMAND, not even `exec {fd}\n# cmd / Clink\n\n- Clink's `io.popenrw` reads block with no peek or timeout. A protocol read from Lua must emit a fixed number of\n records per request (serve wait-mode: exactly 2, see [codebase](codebase.md)).\n- `io.popenrw` runs through `%COMSPEC% /c`; keep `2>nul` in the command, or the child's stderr corrupts the display.\n- Windows has no SIGPIPE: stdin EOF is the daemon's only exit signal. Clink's pipes are `_O_NOINHERIT`, so cmd's\n death closes the daemon's stdin.\n- Test with `luac -p` plus a Lua harness that stubs the Clink API (`winget install DEVCOM.Lua`,\n `chrisant996.Clink`). Clink cannot run headless, so live smoke tests stay manual.\n\n\n# Codebase\n\n## Template markup trust boundary\n\n- Print-action output is chevron-escaped (`escapePrintActions`); only `template.Markup` values keep `<...>`\n anchors. Keep attacker-controlled data (VCS refs, API responses, folder names) in plain strings. `RawMarkup` is for\n user config only, `EscapeMarkup` for data, `JoinMarkup` for composition.\n- Segment fields built from option strings that carry anchors (icons, `branch_icon`, `folder_separator_icon`,\n `status_formats`) must be `template.Markup`, or the anchors render as literal text.\n- Keep `template.Markup` a named string, never a struct: text/template treats every struct as true (breaks\n `{{ if .BranchStatus }}` guards in shipped themes) and `eq` cannot compare it to a string.\n- Untrusted templates (`RenderUntrusted`, path segment) escape Markup results too. The path segment escapes folder\n names with `template.EscapeSource` on every branch of `replaceMappedLocations`; a new early return needs its own\n escape.\n- New func-map entries: output not derived from input (`readFile`, `cmd`, `b64dec`, `env`) goes in `noPromote`;\n attacker-chosen counts (`repeat`, `seq`, `until`, `rand*`) go in `dangerousFuncs` (trusted templates only). For a\n hot function, add a typed case to `markupAwareTyped` first.\n- Never bypass `formats.EscapeSequences` in `terminal.write`'s `isHyperlink` branch: bash `@P` re-interprets a\n backslash in the OSC 8 URI.\n- `src/prompt/golden_test.go` renders every shipped theme byte-exact. A golden diff after a markup change means a\n theme relied on the old, insecure behavior: inspect it, then `go test ./prompt/... -run TestGoldenThemes -update`.\n\n## Terminal output sanitization\n\n- `prompt.Engine.write` bypasses `terminal.write`'s per-rune control filter. Sanitize attacker-influenceable strings\n written in one shot (console title, OSC payloads) with `terminal.stripControlRunes`; `trimAnsi` misses ESC-less\n input (bare BEL) and CSI `! p`, APC, SOS, ST.\n- Don't extend `terminal.AnsiRegex`'s final-byte class (`!`, `_`, `X`, `\\` omitted on purpose) as a sanitization fix;\n strip control runes instead.\n\n## Segments and cache\n\n- Treat `mem.SwapMemory()` errors as returning a nil stat: gopsutil can fail reading `/proc/vmstat` on Android/Termux,\n so fall back to `VirtualMemoryStat.SwapTotal` and `SwapFree` instead of dereferencing the result.\n- Segment writers gob-encode only exported fields; `segments.Base.env/options` are unexported. On cache restore,\n overlay restored data onto the writer from `MapSegmentWithWriter`; never replace the writer.\n- `runtime/cmd.RunWithEnv` trims whitespace from the whole output, so a trailing empty field is lost. End records\n with a non-whitespace delimiter or sentinel and validate before assigning parsed state.\n- A blank prompt means a panic outside segment `Execute` and the streaming producer (both recover). A poisoned\n cache entry replays its failure every prompt until its TTL ends.\n- Caches persist only with the hidden `--save-cache` flag (print/stream); relocate with `OMP_CACHE_DIR`.\n- Logs are buffered and print only via `oh-my-posh debug` (grep `restored segment from cache`, `setting entry`);\n `POSH_TRACE=1` and stderr show nothing for print commands.\n- Windows: a fresh memory-mapped cache file logs a harmless `store.go:init EOF` on first read.\n\n## Streaming and serve daemon\n\n- `\"streaming\": ` also becomes every segment's pending timeout, overriding segment `timeout`.\n- `stream` emits the transient prompt as a `\\x1e`-prefixed NUL-terminated record (initial, and again once all\n segments resolve). Serve records are `\\x1f\\0`; a wait-mode request always yields exactly 2, even on\n segment panic (`renderComplete`), because Clink blocks on that count.\n- A timed-out segment keeps running after its cycle. On any path that can run then, publish through the\n `renderCache` captured at the top of `Execute`, never the global `template.Cache` (serve resets it per cycle,\n tests reassign it). `restoreCache`/`restoreData` still read the global (open race, 2026-09).\n- Don't gate `Execute`'s cache-hit early return on streaming: placeholders never show cached data, so skipping the\n cache only adds live probes that can time out.\n- Never touch `segment.writer` of a segment the cycle still has pending; pending segments render via\n `Segment.RenderPlaceholder` (config only). Don't add a `Pending` flag to `config.Segment`.\n- The event channel in `prompt/streaming.go` is sized `2*segments+1` so plain sends never block or drop; don't add\n `select`/`default`. The producer's `recover` must log a stack: a silent recover once hid a stuck-segment bug.\n- `prompt/streaming_writer_test.go`'s fake writer writes fields late on purpose, as race bait. `-race` only runs in\n CI ([release](release.md)).\n- Serve: process-lifetime initializers (`if X != nil return`) pin first-render state. Reset per render\n (`template.ResetCache()` in `startRenderCycle`); never nil a global that abandoned goroutines may still read.\n- Don't memoize the config in serve: the per-render gob decode gives each cycle its own segment graph, isolated from\n abandoned-cycle goroutines.\n- Daemon tests must vary per-request context (cwd, status) across cycles to catch one-shot state.\n- `config.Get` prefers the session gob cache over `POSH_THEME`.\n- Timing races: `oh-my-posh debug` timings are cold-process. Sweep the `streaming` value against a scripted serve\n session (JSON line + env blob on stdin) and count cycles whose last record still holds the placeholder.\n\n## Rendering and statusline\n\n- `template.Init` resets the parsed-template cache: calling it per benchmark iteration measures cold parse.\n- Stale website previews: a set `OMP_BIN` overrides the auto-rebuilt `src/bin` in `ensure-artifacts.mjs`.\n- Unix `terminal-dimensions` runs `stty size` on stdin, which is not a TTY under Claude Code's statusline. A valid\n `COLUMNS` fallback must clear the `stty` error, or `prompt.Engine.canWriteRightBlock` rejects right-aligned blocks.\n\n\n# fish\n\nVerified on fish 4.1.2 (2026-07 to 2026-09).\n\n## Jobs, fifos, and lifecycle\n\n- fish does not fork a backgrounded function; it blocks the shell. Run readers as an external process:\n `fish --no-config -c $script args &`.\n- `jobs --last --pid` prints a \"Process\" header plus one pid per pipeline stage: filter with\n `string match --regex '^\\d+$'` and treat the result as a list.\n- Guard zero pids before `kill -0`: `kill -0 0` signals your own process group and always succeeds.\n- A fifo write with no reader blocks forever; liveness-check the reader before every write.\n- The serve daemon opens its request fifo O_RDWR, so it never sees EOF and a SIGKILLed fish orphans it. Teardown\n must go through the `fish_exit` handler.\n- `--on-signal SIGUSR1` handlers fire between commands in non-interactive scripts.\n- The streaming transient prompt lives in a tempfile (`$_omp_streaming_tempfile.transient`), not a variable,\n because `_omp_cleanup_stream` runs before the transient repaint.\n\n## Key bindings\n\n- `commandline --is-valid`: 0 valid, 1 erroneous, 2 incomplete. An empty buffer also returns 1, so check the buffer\n is non-empty before treating 1 as an error. A trailing backslash returns 0 (not a continuation).\n- A parse error from `commandline --function execute` inside a binding is attributed to the binding's file and\n function (#7862). Rethrow through a pristine parser instead:\n `commandline --current-buffer | string collect | $fish_bin --no-execute` (keeps the buffer and `$status`).\n- fish 4.x rejects command substitutions in command position (`(status fish-path) --no-execute`); assign to a\n variable (`set fish_bin (status fish-path)`) first.\n\n\n# PowerShell (pwsh)\n\n## Engine events and runspaces (pwsh 7, 2026-07)\n\n- `Register-EngineEvent -Action` (e.g. `PowerShell.OnIdle`): `-MessageData` arrives as `$null`, and\n `.GetNewClosure()` captures are lost when the scriptblock is created in a module function. Pass state through a\n `$global:` variable (`$global:_ompStreamingState` in `omp.ps1`).\n- PSReadLine raises `PowerShell.OnIdle` every ~300-450ms, only while the input buffer is empty. Anything the user\n can trigger sooner (transient prompt on a fast Enter) must also drain synchronously at its call site.\n- PSEvents raised from a non-engine thread (e.g. `Register-ObjectEvent DataAdded` fed by a background runspace)\n can crash the host (`InvalidPipelineStateException`). Consume records only on the engine thread.\n- `Register-ObjectEvent` actions may or may not fire during a busy-wait. Never share a consume cursor between an\n event action and a synchronous waiter: give the waiter a private cursor and make the action idempotent.\n\n## PSReadLine prompt redraws (PSReadLine 2.4.5 / 2.3.6, 2026-09)\n\n- `InvokePrompt()` blanks `ExtraPromptLineCount + 1` rows before it calls the prompt function; a count set during\n that call only affects the next redraw. Padding the transient prompt cannot fix under-erasure.\n- `ExtraPromptLineCount` must count screen rows, including wrapping. The engine computes `terminal.CursorRow` and\n prefixes pwsh prompts with `ESC]7777;BEL`, which `Set-PoshExtraPromptLineCount` strips. Don't measure the\n prompt in PowerShell (`Measure-Object -Line` ignores wrapping and skips empty elements).\n- Overcounting is as bad: it erases the previous output line, or at the screen top `InvokePrompt` returns before\n calling the prompt (`newY < 0`), leaving `$script:TransientPrompt` set so the next primary renders as transient.\n Zero-width sequences such as the rprompt's `ESC 7`/`ESC 8` count 0 cells.\n- Match escape-prefixed strings with `-match '^\\u001b...'`, not `StartsWith`: culture-aware `StartsWith` ignores\n ESC, so `\"abc\".StartsWith(\"$([char]27)a\")` is `True`.\n- Redraw bugs only show when a line wraps; reproduce with the e2e `harness.MultiLine` overlay.\n\n## Exit lifecycle\n\n- pwsh cannot exit while a `[powershell]::Create()` pipeline thread runs (foreground threads). A reader blocked in\n `ReadByte()` on a child that exits only on stdin EOF deadlocks `exit` (#7643).\n- Module `OnRemove` never runs on a normal `exit`. Tear down a daemon in a `Register-EngineEvent PowerShell.Exiting`\n handler: write `quit`, close the child's stdin (the guaranteed EOF), kill after a short `WaitForExit`.\n\n## Performance (ARM64 Windows 11, 2026-07)\n\n- Process creation floor is ~70ms; any omp spawn costs ~100-130ms. For `omp.ps1` perf, count spawns per Enter\n first; cmdlet and module overhead is negligible.\n- `&` saves only ~10-17ms over the Process API and, under a CP437/1252 console, mangles UTF-8 output unless\n `[Console]::OutputEncoding = UTF8` is set once at init.\n- `Start-Sleep -Milliseconds 1` sleeps a ~15.6ms timer tick. Don't sleep-poll; signal a `ManualResetEventSlim`.\n\n## Testing\n\n- `New-Event -SourceIdentifier PowerShell.OnIdle` runs the real OnIdle action deterministically; its side effects can\n short-circuit later prompt calls.\n- Set module-scope flags from a test: `& (Get-Module oh-my-posh-core) { $script:X = $true }`.\n- Serve is gated to pwsh 6+ outside ConstrainedLanguage; pwsh 5.1 and ConstrainedLanguage keep the legacy path.\n- Exit-deadlock repro: `Start-Process pwsh -File test.ps1` + `WaitForExit(timeout)`; `findstr x` with redirected\n stdio stands in for a daemon.\n\n\n# Release, CI, and git\n\n## Release (`.github/workflows/release.yml`)\n\n- Releases are immutable: the workflow creates a draft and publishes last. Every asset must be in the draft before the\n publish step.\n\n## CI\n\n- `go test -race` does not work on the windows/arm64 dev machine or its WSL (no C compiler, no sudo). CI's\n `Race Detector` step (`code.yml`, ubuntu) is the only race gate.\n\n## Git on Windows\n\n- With `core.autocrlf=true`, `git rebase --autosquash` can stop on a plain `pick` with \"Your local changes would be\n overwritten\" and no real conflict (line-ending renormalization). Set `core.autocrlf false` for the rebase and\n restore it after; don't try to resolve a phantom conflict.\n\n\n# Testing shells and terminals\n\n## Script edits\n\n- `src/shell/scripts/` is embedded at build time: rebuild the binary after every script edit, then inspect what\n users source with `oh-my-posh init --print`.\n- A script function is dead code unless `src/shell/.go` emits its activation line for the enabled feature.\n\n## e2e harness (`e2e/`, see `e2e/README.md`)\n\n- PSReadLine on a raw Unix pty floods `CSI 6n` and wedges without a reply (ConPTY answers it on Windows); the\n harness answers from the vt10x cursor (`harness/session.go`).\n- nu autoloads `$nu.vendor-autoload-dirs` after `--config`, so a real omp install clobbers the test prompt. Point\n `XDG_DATA_HOME` at an empty dir.\n- go-pty's Windows `Cmd` resolves bare names relative to `Cmd.Dir`; pass absolute binary paths.\n- On Windows, `bash` on PATH is System32's WSL launcher; `harness.LookupShellBinary` derives Git Bash from\n `git.exe`.\n\n## WSL\n\n- Run e2e from a Windows worktree: cross-compile (`GOOS=linux GOARCH=arm64 go build`), then in WSL\n `cd /mnt/c/.../e2e && OMP_E2E_BINARY=/mnt/c/.../oh-my-posh go test .`. If the distro's Go is too old for e2e's\n `go.mod`, unpack a go.dev tarball into `~/go-sdk`.\n- WSL `/tmp` is wiped between `wsl.exe` invocations: keep a test in one `wsl -e` call or stage under `$HOME`.\n- From Git Bash, prefix `MSYS_NO_PATHCONV=1` so `/mnt/c/...` arguments reach wsl.exe unmangled.\n\n## Getting a pty\n\n- `zsh -i` under plain `wsl -e` hangs (no foreground pty). Use `wsl -e script -qec 'zsh -i' /dev/null` for a real pty\n with job control, run backgrounded with output to a file, and poll a done-marker.\n- For keystrokes use `zmodload zsh/zpty`: `zpty omp zsh -i`, `zpty -w -n omp $'\\x03'` (real SIGINT), assert via\n state files, drain with `zpty -r`. `script(1)` does not work inside zpty.\n- `script(1)` quirks: bash prompt bytes are not relayed (probe `${PS1@P}` in-session); fish discards piped\n typeahead (assert via files written by event handlers); zsh works.\n- vi-mode probes must be mode-aware: after a normal-mode accept the next line starts in normal mode, so prefix `i`.\n A stray self-inserted `i` shows up as `last_status=127`.\n- To hold a render open, point an `http` segment with a large `http_timeout` at a silent local TCP listener; kill\n the listener to trigger the async update. There is no shell-command segment.\n\n## Protocol streams\n\n- One `bufio.Scanner` per pipe, ever; a second scanner loses buffered data.\n- Never treat wall-clock silence as \"records done\": cold-cache CI runs exceed any fixed gap. Wait for a record that\n proves the assertion (the cycle's transient record comes last) and keep a timeout only as a hang bound. Reproduce\n with `go clean -cache && go test -count=1 ./...`.\n\n## Windows Terminal and ConPTY\n\n- \"[process exited with code 0]\" at shell exit is Windows Terminal's own teardown message, never omp output.\n- Panes opened via `wt.exe ` never auto-close under `closeOnExit=automatic`; profile tabs do.\n- A headless conhost (Windows 11 build 26300) reports cursor 0,0, a blank buffer, and drops pty input: assert state,\n not row placement.\n- pywinpty's ConPTY EOF lags process death by ~5s (harness artifact, not a hang).\n- SendKeys into Windows Terminal drops keystrokes while the user works; a \"hung\" test may never have got `exit`.\n- `Set-Content -NoNewline` joins piped lines into one and corrupts scripts; write byte-exact files with Git Bash\n redirection.\n\n\n# zsh\n\n## zle\n\n- Every new editor invocation starts in keymap `main`; a `vicmd` selection does not carry into the next line.\n- `$?` after the transient prompt's `zle .send-break` is 1, native Ctrl+C gives 130 (TODO in `_omp_zle-line-init`).\n Don't fix one path without the other.\n- Ubuntu's `/etc/zsh/zshrc` defines a `zle-line-init`; never assume the widget slot is empty.\n- zsh-vi-mode always wraps omp's `zle-line-init` (it initializes lazily at first `precmd`), and our\n `.recursive-edit` swallows the session, so `_omp_zle-line-init` must call `zvm_zle-line-init` up front (guarded on\n `$+functions[zvm_zle-line-init]` and `ZVM_INIT_DONE`). Keep that call (#5992).\n- Keep `local rawfunc=` at the top of `_omp_zle-line-init`: `zvm_reset_prompt` resolves `$rawfunc` by dynamic\n scoping and would otherwise re-enter our widget.\n- Debug widget re-entry by logging `${funcstack[*]}` inside the widget.\n\n## Quoting\n\n- Quote every parameter expansion used as a command argument if its value can contain `[`, `?`, `*` or `#`. Under a\n user's `setopt GLOB_SUBST` it becomes a glob, and `BAD_PATTERN` aborts the widget (`$zle_bracketed_paste[1]` is\n `\\e[?2004h`, #7816).\n\n## coproc, fds, and signals\n\n- An interactive zsh with MONITOR prints `[n] pid` at coproc spawn; neither `disown` nor `2>/dev/null` stops it.\n `setopt localoptions no_monitor` does, and the child then inherits SIGINT/SIGQUIT ignored.\n- Duplicate coproc fds to session fds (`exec {out}<&p {in}>&p`) so they survive a later `coproc`; `disown %+` keeps\n the daemon out of `jobs` and the job-count segment.\n- A redirection-only `exec` applies every listed redirection permanently: `exec {fd}<&p 2>/dev/null` silences the\n session's stderr (#7653). Scope it: `{ exec ... } 2>/dev/null`.\n- Writing to a dead coproc raises SIGPIPE, which kills a non-interactive zsh. Guard writes with a `kill -0 $pid`\n check plus `setopt localoptions localtraps; trap '' PIPE`.\n- Never `kill -0` a possibly-zero pid: `kill -0 0` signals your own process group and always succeeds.\n- zsh 5.9 `read -r -u $fd -d $'\\0' -t N` ignores `-t` and blocks forever on a silent fd, so the serve path hangs\n in a non-interactive `zsh script.zsh`; test it in an interactive session.\n- Tear down in `zshexit_functions`; closing the fds (or the shell dying, even by SIGKILL) EOFs the daemon's stdin.\n\n\n---\nname: project-knowledge\ndescription: >\n Verified, actionable gotchas for oh-my-posh. Read the matching topic file BEFORE changing shell integration\n scripts (pwsh, zsh, bash, fish, cmd/Clink, nu, elvish, xonsh), terminal or pty behavior, WSL or e2e shell tests,\n Go internals (cache, segments, streaming, serve daemon, template rendering, output sanitization), or release, CI,\n build, and packaging workflows.\n---\n\n# Project Knowledge\n\nNon-obvious constraints, platform quirks, traps, and failed approaches. Read only the files the task touches; any\nshell-script edit also needs `testing`. Entries are point-in-time: verify against the code and fix drift.\n\n| Topic | Read when |\n| ------------------------------------ | ----------------------------------------------------------------------------- |\n| [codebase](references/codebase.md) | Go internals: templates, sanitization, segments, cache, streaming, serve |\n| [release](references/release.md) | `release.yml`, signing, packaging, CI gates, `-race`, rebasing on Windows |\n| [testing](references/testing.md) | Any shell-script edit; e2e/pty harnesses, WSL, ConPTY, Windows Terminal, nu |\n| [zsh](references/zsh.md) | `omp.zsh`, zle widgets, coproc, zsh-vi-mode |\n| [pwsh](references/pwsh.md) | `omp.ps1`, PSReadLine, runspaces, engine events, pwsh perf |\n| [fish](references/fish.md) | `omp.fish`, fish jobs, fifos, key bindings |\n| [bash](references/bash.md) | `omp.bash`, PROMPT_COMMAND, readline, ble.sh |\n| [cmd-clink](references/cmd-clink.md) | `omp.lua`, Clink, Windows pipe lifecycles |\n\n## Write-back\n\n- Append only verified entries that change what an agent does, phrased \"do X / don't do Y, because Z\", to the\n matching file (new file plus index row only when none fits). No narratives or history.\n- Update or delete a stale entry instead of stacking a correction. Date it only when staleness matters.\n- Commit knowledge updates with the change they relate to.\n\n\n---\nname: segment-create\ndescription: >\n Checklist for adding a new Oh My Posh segment. Use when asked to add or create a new segment:\n lists every file to touch, the existing segment to copy, and how to verify.\n---\n\n## Template\n\nCopy `src/segments/taskwarrior.go` and `src/segments/taskwarrior_test.go`: two options, a\n`Template()`/`Enabled()` pair, and every shell call going through the mocked environment.\n\n- Embed `Base` first in the struct; its exported fields are the template properties.\n- Declare options as `options.Option` constants; read them with `s.options.String(...)`,\n `s.options.Bool(...)`, `s.options.KeyValueMap(...)` and so on, passing the default there.\n- Reach the OS, shell, files and network only through `s.env` so tests can mock it.\n- Override `Activation()` only for a cheap precondition such as a project file (see\n `src/segments/dvc.go`); `Base` defaults to always active.\n- Tests are table-driven: a `mock.Environment` from `src/runtime/mock`, options as an\n `options.Map`, then `Init(props, env)` and assertions on `Enabled()` and the exported fields.\n\n## Checklist\n\nKeep every list sorted alphabetically.\n\n1. `src/segments/.go` and `src/segments/_test.go`.\n1. `src/config/segment_types.go`: add the constant ` SegmentType = \"\"`.\n1. `src/config/segment_registry.go`: add `gob.Register(&segments.{})` to `init()` and\n `: func() SegmentWriter { return &segments.{} }` to `Segments`. A missing map\n entry fails silently at runtime: the segment never renders.\n1. `themes/schema.json`: add `` to `definitions.segment.properties.type.enum` and an\n `if`/`then` block to `definitions.segment.allOf` declaring every option. Copy the\n `taskwarrior` block; its `unevaluatedProperties: false` rejects undeclared options.\n1. `website/docs/segments//.mdx`, where category is one of agents, cli, cloud,\n health, languages, music, scm, system or web. Follow the `segment-docs` skill, and keep a\n `## What` paragraph: the segment catalog plugin reads it.\n1. `website/sidebars.js`: add `\"segments//\"` to that category's `items`.\n1. `website/segment_data.json`: add sample data under ``, shaped like the `taskwarrior` entry.\n1. `website/plugins/segments/registry.json`: generated. The first `go test ./config/...` run\n rewrites it and fails; rerun to confirm, then keep the file.\n1. Credentials needed? Add the doc id to `AUTH_TIERS` in `website/plugins/segments/data.js`.\n\n## Verify\n\nFrom `src/`:\n\n```shell\ngo test ./segments/... -run Test\ngo test ./config/...\n```\n\nRun `npm run build` in `website/` only when docs changed.\n\n\n---\nname: segment-docs\ndescription: >\n Reference mapping between Oh My Posh Go segment source code and MDX documentation.\n Use when creating, updating, or auditing segment documentation, or when reading\n segment Go code and needing to understand how code constructs map to user-facing\n options, template properties, and type representations in docs.\n---\n\n# Segment Documentation Reference\n\n## Go-to-Documentation Type Mapping\n\nWhen reading a segment's Go source to document its options, determine the type from the\n`Provider` method used to read the option value:\n\n| Go method call | Documentation type |\n| -------------- | :----------------: |\n| `options.Bool(option, default)` | `boolean` |\n| `options.String(option, default)` | `string` |\n| `options.StringArray(option, default)` | `[]string` |\n| `options.Int(option, default)` | `int` |\n| `options.Float64(option, default)` | `float64` |\n| `options.KeyValueMap(option, default)` | `map[string]string` |\n| `options.Color(option, default)` | `string` |\n| `options.Template(option, default, ctx)` | `string` |\n| `options.Any(option, default)` | `any` |\n\n## Extracting Options from Go Source\n\nOptions are declared as `options.Option` string constants in the segment's `const` block:\n\n```go\nconst (\n BranchIcon options.Option = \"branch_icon\" // option name used in config\n NativeStatus options.Option = \"native_status\"\n)\n```\n\nThe **option name** is the string literal value (e.g., `\"branch_icon\"`).\n\nThe **type** and **default value** come from the getter call in `Enabled()` or `init`-like methods:\n\n```go\ns.icon = s.options.String(BranchIcon, \"\\uE0A0\")\n// ^^^^^^ → string type, \"\\uE0A0\" → default\n```\n\n### Shared options\n\nThe following options are defined in `src/segments/options/map.go` and available to all\nsegments without appearing in a segment-specific `const` block:\n\n| Option name | Type | Default |\n| ----------- | ---- | ------- |\n| `always_enabled` | `boolean` | `false` |\n| `display_default` | `boolean` | `true` |\n| `display_error` | `boolean` | `true` |\n| `http_timeout` | `int` | `20` |\n| `cache_duration` | `int` | varies |\n| `access_token` | `string` | `\"\"` |\n| `refresh_token` | `string` | `\"\"` |\n| `version_url_template` | `string` | `\"\"` |\n| `files` | `[]string` | varies |\n\n## Extracting Template Properties from Go Source\n\nTemplate properties are values available inside the segment's `template` string.\n\n**Rules for what becomes a template property:**\n\n- **Exported struct fields** (capitalized) on the segment struct → `.FieldName`\n- **Unexported fields** are not accessible in templates\n- **Nested struct fields** use dot notation: a field `Working ScmStatus` exposes\n `.Working.Modified`, `.Working.Added`, etc.\n- **Zero-argument methods** with a single return value → `.MethodName`\n- **Document fields that are assigned** in `Enabled()` or its callees,\n not every inherited field from embedded structs is populated by every segment\n\nThe default template comes from the `Template()` method:\n\n```go\nfunc (s *MySegment) Template() string {\n return \" {{ .FieldName }} \"\n}\n```\n\n### Nested struct subsection convention\n\nWhen a property's type is itself a struct, add an `#### TypeName` subsection within\nthe Properties table section listing its exported fields. Example:\n\n```mdx\n#### Status\n\n| Name | Type | Description |\n| ---- | ---- | ----------- |\n| `.Modified` | `int` | Number of modified files |\n| `.Added` | `int` | Number of added files |\n| `.Deleted` | `int` | Number of deleted files |\n| `.Untracked` | `int` | Number of untracked files |\n| `.Changed` | `boolean` | Whether any changes exist |\n```\n\n## Key Source Files for Inherited Fields\n\nWhen a segment embeds a base struct, its inherited fields may also be template properties.\nCheck these files to discover what fields are available:\n\n| File | What it defines |\n| ---- | --------------- |\n| `src/segments/options/map.go` | `Provider` interface method signatures; shared `Option` constants |\n| `src/segments/base.go` | `Base` struct embedded by all segments; provides `options`, `env` |\n| `src/segments/scm.go` | `ScmStatus` type with working/staging status fields (git, mercurial, etc.) |\n| `src/segments/language.go` | `Version` type and language base fields (Python, Node, Go, etc.) |\n\n\n---\nname: oh-my-posh\ndescription: Install, configure, or troubleshoot Oh My Posh/ohmyposh: shell init, themes, segments, Nerd Font icons, and prompt setup on PowerShell, zsh, bash, or fish.\n---\n\n# Oh My Posh\n\n> Oh My Posh is a cross-shell, cross-platform prompt theme engine for Windows, macOS, and Linux.\n> It renders beautifully themed prompts with Git status, language versions, cloud context,\n> and more — 120 segments in all.\n\nFull skill (folder-based, with per-OS and per-shell guides):\n[/skills/ohmyposh/SKILL.md](/skills/ohmyposh/SKILL.md)\n\n## Quick links\n\n- [Installation — Windows](/skills/ohmyposh/installation/windows.md)\n- [Installation — macOS](/skills/ohmyposh/installation/macos.md)\n- [Installation — Linux](/skills/ohmyposh/installation/linux.md)\n- [Shell setup — PowerShell](/skills/ohmyposh/shell/powershell.md)\n- [Shell setup — Bash](/skills/ohmyposh/shell/bash.md)\n- [Shell setup — Zsh](/skills/ohmyposh/shell/zsh.md)\n- [Shell setup — Fish](/skills/ohmyposh/shell/fish.md)\n- [Shell setup — Nu](/skills/ohmyposh/shell/nu.md)\n- [Shell setup — Cmd](/skills/ohmyposh/shell/cmd.md)\n- [Shell setup — Elvish](/skills/ohmyposh/shell/elvish.md)\n- [Shell setup — Xonsh](/skills/ohmyposh/shell/xonsh.md)\n- [Configuration & themes](/skills/ohmyposh/configuration.md)\n\n\n# Oh My Posh — Configuration & Customization\n\n## Apply a theme\n\nPass `--config` to the init command with a theme name, local path, or remote URL.\n\n**By theme name** (no extension needed):\n\n```powershell\n# PowerShell\noh-my-posh init pwsh --config 'jandedobbeleer' | Invoke-Expression\n```\n\n```bash\n# Bash / Zsh\neval \"$(oh-my-posh init bash --config jandedobbeleer)\"\n```\n\n**By local file path:**\n\n```powershell\n# PowerShell\noh-my-posh init pwsh --config 'C:\\Users\\\\.mytheme.omp.json' | Invoke-Expression\n```\n\n```bash\n# Bash / Zsh\neval \"$(oh-my-posh init bash --config ~/.mytheme.omp.json)\"\n```\n\n**By remote URL:**\n\n```powershell\noh-my-posh init pwsh --config 'https://raw.githubusercontent.com/JanDeDobbeleer/oh-my-posh/main/themes/jandedobbeleer.omp.json' | Invoke-Expression\n```\n\n> Using a remote URL adds a network dependency. Oh My Posh caches remote configs using ETags,\n> but latency still applies on cache misses. For reliable offline use, copy the theme to a\n> local file and use a local path instead.\n\n## Browse available themes\n\nView all bundled themes online: \n\n> There is no terminal command to preview all available themes. Direct users to the website above.\n\n## Debug the current theme\n\nTo render your active prompt in debug mode (shows segment timing and values):\n\n```bash\noh-my-posh debug\n```\n\n## Export a theme for editing\n\n```bash\noh-my-posh config export --config jandedobbeleer --output ~/.mytheme.omp.json\n```\n\nThen set `--config ~/.mytheme.omp.json` in your init line and edit the file to taste.\n\n## WSL tip\n\nInside WSL you can share a theme stored in your Windows home folder:\n\n```bash\neval \"$(oh-my-posh init bash --config /mnt/c/Users//mytheme.omp.json)\"\n```\n\n## Live reload during editing\n\nEnable live reload so prompt changes appear without restarting the shell:\n\n```bash\noh-my-posh enable reload\n```\n\nDisable:\n\n```bash\noh-my-posh disable reload\n```\n\nPreview every configured prompt without restarting:\n\n```bash\noh-my-posh print preview\n```\n\nForce-render all segments regardless of context:\n\n```bash\noh-my-posh print preview --force\n```\n\n## Validate a config or segment via MCP\n\nWhen creating or editing a segment manually, use the oh-my-posh MCP server to validate the\nconfig or a segment snippet for schema errors. Agents can call:\n\n```bash\ncurl -X POST https://ohmyposh.dev/api/mcp \\\n -H \"Content-Type: application/json\" \\\n -d '{\n \"jsonrpc\": \"2.0\",\n \"method\": \"tools/call\",\n \"params\": {\n \"name\": \"validate_config\",\n \"arguments\": {\"content\": \"\", \"format\": \"auto\"}\n },\n \"id\": 1\n }'\n```\n\nOr use `validate_segment` to check a single segment snippet instead of an entire config.\n\n## Configuration reference\n\n- Full schema: \n- Docs: \n- Segments: \n\n\n# Oh My Posh — Linux Installation\n\n> **Prerequisites:** `curl`, `unzip`, `realpath`, and `dirname` must be available.\n> Make sure `curl` and the client certificate store are up to date.\n\n## Install\n\n```bash\ncurl -s https://ohmyposh.dev/install.sh | bash -s\n```\n\nBy default this installs to `~/bin` or `~/.local/bin` (whichever exists), or to the directory\nof any existing `oh-my-posh` binary. To install to a custom location:\n\n```bash\ncurl -s https://ohmyposh.dev/install.sh | bash -s -- -d ~/bin\n```\n\n## Update\n\nRe-run the install script — it replaces the existing binary in-place.\n\n## After installing\n\nRestart the terminal (or open a new window) so `oh-my-posh` is on `$PATH`, then proceed to the\n[shell setup guide](/skills/ohmyposh/SKILL.md).\n\n\n# Oh My Posh — macOS Installation\n\n> **Note:** The standard macOS Terminal only supports 256 colors. Use [iTerm2](https://iterm2.com)\n> or another modern terminal for full ANSI color and icon support.\n\n## Install\n\n**Recommended (Homebrew):**\n\n```bash\nbrew install jandedobbeleer/oh-my-posh/oh-my-posh\n```\n\n**MacPorts** (community-maintained):\n\n```bash\nsudo port selfupdate\nsudo port install oh-my-posh\n```\n\n## Update\n\n```bash\nbrew upgrade oh-my-posh\n```\n\n## After installing\n\nRestart the terminal (or open a new window) so `oh-my-posh` is on `$PATH`, then proceed to the\n[shell setup guide](/skills/ohmyposh/SKILL.md).\n\n\n# Oh My Posh — Windows Installation\n\n## Install\n\n**Recommended (winget):**\n\n```powershell\nwinget install JanDeDobbeleer.OhMyPosh --source winget\n```\n\n**Manual (PowerShell):**\n\n```powershell\nSet-ExecutionPolicy Bypass -Scope Process -Force; Invoke-Expression ((New-Object System.Net.WebClient).DownloadString('https://ohmyposh.dev/install.ps1'))\n```\n\n**Chocolatey:**\n\n```powershell\nchoco install oh-my-posh\n```\n\n## Update\n\n```powershell\nwinget upgrade JanDeDobbeleer.OhMyPosh --source winget\n```\n\n## After installing\n\nRestart the terminal (or open a new window) so `oh-my-posh` is on `$PATH`, then proceed to the\n[shell setup guide](/skills/ohmyposh/SKILL.md).\n\n> **Tip:** When using Oh My Posh inside WSL, follow the\n> [Linux installation](/skills/ohmyposh/installation/linux.md) guide inside WSL instead.\n\n\n# Oh My Posh — Bash Setup\n\n## Configure\n\nAdd this as the **last line** of `~/.bashrc` (or `~/.profile` / `~/.bash_profile` depending on\nyour environment):\n\n```bash\neval \"$(oh-my-posh init bash)\"\n```\n\nReload:\n\n```bash\nexec bash\n```\n\nOr, if using `~/.profile`:\n\n```bash\n. ~/.profile\n```\n\n## Next step\n\n→ [Customize your prompt](/skills/ohmyposh/configuration.md)\n\n\n# Oh My Posh — Cmd Setup (via Clink)\n\nCmd does not support custom prompts natively. [Clink](https://chrisant996.github.io/clink/)\nadds that capability and also enhances Cmd with readline-style editing.\n\n## Prerequisites\n\nInstall Clink and enable autostart. Find the Clink scripts directory:\n\n```bash\nclink info\n```\n\n## Configure\n\nCreate a file called `oh-my-posh.lua` in the Clink scripts directory:\n\n```lua\nload(io.popen('oh-my-posh init cmd'):read(\"*a\"))()\n```\n\nRestart Cmd to apply.\n\n> **Tip:** Clink has built-in support for Oh My Posh. You can also set the prompt with:\n>\n> ```bash\n> clink config prompt use oh-my-posh\n> ```\n\n## Next step\n\n→ [Customize your prompt](/skills/ohmyposh/configuration.md)\n\n\n# Oh My Posh — Elvish Setup\n\n## Configure\n\nAdd this as the **last line** of `~/.elvish/rc.elv`:\n\n```bash\neval (oh-my-posh init elvish)\n```\n\nReload:\n\n```bash\nexec elvish\n```\n\n## Next step\n\n→ [Customize your prompt](/skills/ohmyposh/configuration.md)\n\n\n# Oh My Posh — Fish Setup\n\n> **Requires Fish 4.1.0 or later.** Older versions have issues and do not support\n> transient prompt.\n\n## Configure\n\nAdd this as the **last line** of `~/.config/fish/config.fish`:\n\n```bash\noh-my-posh init fish | source\n```\n\nReload:\n\n```bash\nexec fish\n```\n\n## Next step\n\n→ [Customize your prompt](/skills/ohmyposh/configuration.md)\n\n\n# Oh My Posh — Nu / Nushell Setup\n\n> **Requires Nushell v0.104.0 or later.**\n\n## Configure\n\nAdd this as the **last line** of the Nushell config file (path: `$nu.config-path`):\n\n```bash\noh-my-posh init nu\n```\n\nRestart Nushell to apply.\n\n## Next step\n\n→ [Customize your prompt](/skills/ohmyposh/configuration.md)\n\n\n# Oh My Posh — PowerShell Setup\n\n## Configure\n\nEdit your PowerShell profile. Find its path:\n\n```powershell\n$PROFILE\n```\n\nOpen it (create it if it doesn't exist):\n\n```powershell\nnotepad $PROFILE\n# or: New-Item -Path $PROFILE -Type File -Force\n```\n\nAdd this as the **last line**:\n\n```powershell\noh-my-posh init pwsh | Invoke-Expression\n```\n\nReload the profile:\n\n```powershell\n. $PROFILE\n```\n\n## Troubleshooting\n\n**Execution policy blocks scripts:**\n\n```powershell\nSet-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope LocalMachine\n```\n\nOr use the `--eval` flag (slightly slower startup):\n\n```powershell\noh-my-posh init pwsh --eval | Invoke-Expression\n```\n\n## Next step\n\n→ [Customize your prompt](/skills/ohmyposh/configuration.md)\n\n\n# Oh My Posh — Xonsh Setup\n\n## Configure\n\nAdd this as the **last line** of `~/.xonshrc`:\n\n```bash\nexecx($(oh-my-posh init xonsh))\n```\n\nReload:\n\n```bash\nexec xonsh\n```\n\n## Next step\n\n→ [Customize your prompt](/skills/ohmyposh/configuration.md)\n\n\n# Oh My Posh — Yash Setup\n\n## Configure\n\nAdd this as the **last line** of `~/.yashrc`:\n\n```bash\neval \"$(oh-my-posh init yash)\"\n```\n\nReload:\n\n```bash\nexec yash\n```\n\n## Notes\n\n- Requires a yash version that supports `$PROMPT_COMMAND` (>= 2.39) and `$POST_PROMPT_COMMAND`\n (>= 2.52) for full functionality; oh-my-posh hooks into both to time commands and draw the prompt.\n- The prompt is rendered through `YASH_PS1` (and `YASH_PS1R` for the right prompt), which take\n precedence over `PS1`/`PS2` in yash.\n- Right prompt support is native via `YASH_PS1R`.\n- Transient prompt and tooltips are not supported in yash.\n\n## Next step\n\n→ [Customize your prompt](/skills/ohmyposh/configuration.md)\n\n\n# Oh My Posh — Zsh Setup\n\n## Configure\n\nAdd this as the **last line** of `~/.zshrc`:\n\n```bash\neval \"$(oh-my-posh init zsh)\"\n```\n\nReload:\n\n```bash\nexec zsh\n```\n\n## macOS Terminal workaround\n\nThe standard macOS Terminal has issues with ANSI characters. To skip Oh My Posh there while\nkeeping it in iTerm2 and other modern terminals:\n\n```bash\nif [ \"$TERM_PROGRAM\" != \"Apple_Terminal\" ]; then\n eval \"$(oh-my-posh init zsh)\"\nfi\n```\n\n## Next step\n\n→ [Customize your prompt](/skills/ohmyposh/configuration.md)\n\n\n"}