{"owner":"JanDeDobbeleer","repo":"oh-my-posh","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md",".github/copilot-instructions.md"],"files":{"AGENTS.md":"# Agent Instructions\n\nGeneral coding guidelines, commit conventions, and agent workflows for this repository.\n\n## Project Overview\n\nOh My Posh is a cross-shell prompt theme engine written in Go. It renders prompt segments by\nquerying an `Environment` abstraction that wraps all OS/shell interactions.\n\n## Tech Stack\n\n| Layer                     | Technology                    |\n| ------------------------- | ----------------------------- |\n| Core engine               | Go (module root: `src/`)      |\n| Documentation site        | Docusaurus (MDX) - `website/` |\n| Themes                    | JSON - `themes/`              |\n| Config format             | TOML / JSON / YAML            |\n| Package/installer scripts | `packages/`                   |\n| Build scripts             | `build/`                      |\n\n## Key Commands\n\n```bash\n# Go - run from src/\ngo test ./...\ngo test ./segments/... -run TestFoo  # single test\ngolangci-lint run\n\n# Docs - run from website/\nnpm run start    # local dev server\nnpm run build    # validate before opening a docs PR\n```\n\n## Codebase Exploration\n\n**Always explore the actual codebase before planning or writing code.** Do not rely on memory\nor assumptions. Use the file system tools to read relevant files first - the codebase evolves\nand the feature you're asked to add may already exist.\n\n## Repository Layout\n\n```text\nsrc/\n  segments/   # One Go file + one _test.go per segment\n  prompt/     # Core rendering engine\n  runtime/    # OS/shell abstraction layer\nthemes/       # Bundled JSON theme files\nwebsite/      # Docusaurus docs site (MDX pages, sidebar config, JSON schema)\npackages/     # Installer/package manifests\nbuild/        # CI build helpers\n```\n\nKey paths inside `src/`:\n\n| Path                           | Purpose                                               |\n| ------------------------------ | ----------------------------------------------------- |\n| `src/segments/`                | One `.go` + one `_test.go` per segment                |\n| `src/config/segment_types.go`  | Segment type registry (gob + string constants)        |\n| `src/cli/`                     | CLI commands (cmdtree); `root.go` is the entry point  |\n| `src/prompt/engine.go`         | Segment rendering loop                                |\n| `src/cache/`                   | Existing TTL/file/command-path cache infrastructure   |\n| `src/runtime/`                 | `Environment` abstraction + mock                      |\n\n## Segment Development\n\nEvery segment lives in `src/segments/` and implements the `SegmentWriter` interface. Use the\n`Environment` abstraction (`env`) for **all** OS/shell calls - never call OS APIs directly.\n\nAdding a segment requires **five** artifacts - use the `segment-create` skill to scaffold all\nof them automatically:\n\n1. `src/segments/<name>.go` - segment source\n2. `src/segments/<name>_test.go` - unit tests\n3. `website/docs/segments/<name>.mdx` - user-facing docs\n4. Update `website/sidebars.js` and `website/static/schema.json`\n5. Register the type in `src/config/segment_types.go` via `gob.Register(&segments.MySegment{})`\n\nMissing step 5 causes the segment to fail silently at runtime.\n\nSee the `segment-docs` skill for the canonical mapping between Go source constructs and MDX\ndocumentation fields (template properties, type representations, option tables).\n\n## Shell Integration\n\n`oh-my-posh init <shell>` is how users wire oh-my-posh into their shell. It:\n\n1. Writes a shell-specific init script to the cache (source: `src/shell/scripts/omp.<ext>`)\n2. Returns a one-liner for the shell to `eval` - this sources the cached script, which hooks\n   into prompt rendering\n\nThe `src/shell/` package contains per-shell logic (`pwsh.go`, `bash.go`, `zsh.go`, etc.) that\ngenerates the hook commands. The scripts in `src/shell/scripts/` are embedded and templated at\ninit time. When modifying shell behaviour, changes typically span both the `.go` file and the\ncorresponding script.\n\nSupported shells: `bash`, `zsh`, `fish`, `powershell`/`pwsh`, `cmd`, `nu`, `elvish`, `xonsh`.\n\n## CLI Commands\n\nCLI commands use the internal `src/cmdtree` command tree and live in `src/cli/`. To add a new\ncommand:\n\n1. Create `src/cli/<name>.go` with a `var <name>Cmd = &cmdtree.Command{...}`\n2. Register it in `src/cli/root.go` via `RootCmd.AddCommand(<name>Cmd)`\n\n## Caching\n\n`src/cache/` provides the existing caching infrastructure - use it instead of building new\ncache logic. It supports TTL-based key/value storage, file-based persistence, and command-path\ncaching. Do not introduce new cache packages unless `src/cache/` genuinely cannot meet the\nrequirement.\n\n## Comments\n\nApplies to every language in this repository (Go, shell scripts, PowerShell, JavaScript/TypeScript,\nLua, etc.) - not just the primary language of whatever file you're touching.\n\n- Default to no comment. Add one only when the code cannot say it on its own.\n- Never restate what a function/type/variable already makes obvious from its name, signature,\n  and body. A comment that just paraphrases the name is noise - delete it.\n- Only comment the WHY: a hidden constraint, a non-obvious invariant, a workaround for a specific\n  bug, an external requirement, or a caveat that would surprise a reader. If there's nothing like\n  that to say, leave the declaration uncommented - even exported/public ones.\n- When a comment is warranted, keep it to the minimum needed to convey that non-obvious point.\n  Don't pad it with restating context the code already shows.\n- Language-specific skills (e.g. `golang`) may add formatting conventions (complete sentences,\n  doc-comment placement) on top of this rule as a stricter minimum, but must not relax it.\n\n## Go Conventions\n\nFollow the `golang` skill for project-specific Go standards.\n\n## Documentation (website/)\n\n- Follow the `markdown` skill for `.md`/`.mdx` formatting rules.\n- Segment doc pages live in `website/docs/segments/` and use MDX frontmatter with `title`, `sidebar_label`, and `id`.\n\n## PowerShell\n\nPowerShell helper scripts live in `packages/` and `build/`. Follow the `powershell` skill for cmdlet conventions.\n\n## Themes\n\nThemes are plain JSON files in `themes/`. New themes must validate against\n`website/static/schema.json`. Do not introduce breaking schema changes without updating the\nschema file.\n\n## Skills\n\nAgent skills live in `.agents/skills/` - the vendor-neutral Agent Skills location that Copilot,\nCodex, Claude Code, and most other agents discover automatically. Most skills are installed via\nAPM (see [CONTRIBUTING.md](CONTRIBUTING.md)) and gitignored; the repository embeds three of its\nown: `segment-create`, `segment-docs`, and `project-knowledge`.\n\n## Project Knowledge\n\nThe `project-knowledge` skill (`.agents/skills/project-knowledge/`) is the project's durable\nmemory: verified gotchas about the codebase, shells, terminals, and test harnesses. Before working\nin any of those areas, read the matching topic file - it exists to keep you out of known rabbit\nholes.\n\nReading it is half the contract; writing to it is the other half. When a session uncovers\nsomething a future session should know before going down the same rabbit hole - a platform quirk,\na non-obvious root cause, a failed approach worth not retrying - append it (dated, verified) to\nthe matching file in\n`.agents/skills/project-knowledge/references/`. Create a new topic file plus an index row in its\n`SKILL.md` when none fits. Commit the knowledge update together with the change it relates to.\n\n## Pull Request Reviews\n\nWhenever any agent performs or addresses a pull request review, follow this process at all\ntimes, regardless of previous instructions:\n\n1. Stay within the scope of the pull request: only address feedback on changes it introduces.\n2. Investigate every review comment and reach a conclusion: a code fix, a clarification, or a\n   reasoned rejection.\n3. Fold each fix into the commit it belongs to. When the change semantically belongs to a\n   commit the pull request introduces (any commit not yet on main), create a fixup commit\n   (`git commit --fixup <sha>`), squash it (`git rebase --autosquash`), and force-push the\n   pull request branch. This preserves the atomicity of the pull request's commits instead\n   of stacking review-fix commits on top. Rewriting the pull request branch is fine; main\n   history must never be rewritten.\n4. Only when a change does not semantically fit any existing commit in the pull request does\n   it become its own commit on top, following the commit conventions.\n5. Reply to each review comment with the conclusion, referencing the commit that addresses it\n   when there is one.\n6. Resolve each review thread once its answer and/or fix has been provided.\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"}}