github.com/JanDeDobbeleer/oh-my-posh (link)

# Agent Instructions

General coding guidelines, commit conventions, and agent workflows for this repository.

## Project Overview

Oh My Posh is a cross-shell prompt theme engine written in Go. It renders prompt segments by
querying an `Environment` abstraction that wraps all OS/shell interactions.

## Tech Stack

| Layer                     | Technology                    |
| ------------------------- | ----------------------------- |
| Core engine               | Go (module root: `src/`)      |
| Documen

{
  "mcpServers": {
    "oh-my-posh-validator": {
      "url": "https://ohmyposh.dev/api/mcp",
      "description": "Validates oh-my-posh configurations and segments against the JSON schema",
      "tools": ["validate_config", "validate_segment"]
    }
  }
}

{
  "name": "oh-my-posh-validator",
  "description": "MCP server for validating oh-my-posh theme configurations against the official JSON schema. Supports JSON, YAML, and TOML formats with detailed error reporting.",
  "version": "1.0.0",
  "author": {
    "name": "Jan De Dobbeleer",
    "url": "https://github.com/JanDeDobbeleer"
  },
  "homepage": "https://ohmyposh.dev",
  "repository": {
    "type": "git",
    "url": "https://github.com/JanDeDobbeleer/oh-my-posh"
  },
  "license": "MIT",
  "transport": {

---
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.
---

# Segment Documentation Reference

## Go-to-Documentation Type Mapping

When reading a segment's Go source to document its options, determine the type fr

---
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.
---

# Oh My Posh

> Oh My Posh is a cross-shell, cross-platform prompt theme engine for Windows, macOS, and Linux.
> It renders beautifully themed prompts with Git status, language versions, cloud context,
> and more — 118 segments in all.

Full skill (folder-based, with per-OS and per-shell guides):
[/skills/ohmyposh

---
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."
---

# Oh My Posh

> Oh My Posh is a cross-shell, cross-platform prompt theme engine. It displays Git status,
> language versions, cloud context, system metrics and more in a beautifully themed
> terminal prompt — 118 segments in all.

## How to use this skill

1. **Identify the user's OS** → follow the matching in

---
name: segment-create
description: >
  Full scaffolding workflow for creating a new Oh My Posh segment. Invoke when
  asked to add a new segment: generates the Go source, registers the type,
  creates documentation, updates the sidebar and JSON schema.
---

# Segment scaffolding instructions

Goal

- Given user inputs (segment id, Go type name, title, category, description,
  properties, template), generate all required code and docs to add a new
  segment end-to-end, following repo conventions.

Inputs

---
name: project-knowledge
description: >
  Accumulated project memory: verified gotchas and prior findings for oh-my-posh work. Consult
  BEFORE touching shell integration scripts (zsh, pwsh, fish, bash, cmd/Clink), terminal or pty
  behavior, WSL-based shell testing, or internals (cache, segments, streaming, serve daemon).
  Read only the topic files relevant to the task at hand.
---

# Project Knowledge

A modular memory of hard-won, verified facts about this codebase and its runtime environments.
Every

---
name: golang
description: >
  Go coding standards and conventions for this project. Apply when writing,
  reviewing, or refactoring any Go source file.
triggers:
  - on_commit
---

# Go Development Instructions

Follow idiomatic Go practices and community standards when writing Go code.
These instructions are based on [Effective Go](https://go.dev/doc/effective_go),
[Go Code Review Comments](https://go.dev/wiki/CodeReviewComments),
and [Google's Go Style Guide](https://google.github.io/styleguide/go/).

---
name: markdown
description: >
  Markdown formatting rules for this project. Apply when writing or editing
  any .md or .mdx file, including documentation and website content.
---

# Markdown Content Rules

The following markdown content rules are enforced in the validators:

1. Headings: Use appropriate heading levels (H2, H3, etc.) to structure your content.
  Do not use an H1 heading, as this will be generated based on the title.
2. Lists: Use bullet points or numbered lists for lists. Ensure proper
 

---
name: powershell
description: >
  PowerShell cmdlet conventions for this project. Apply when writing or
  reviewing any .ps1 or module file.
---

# PowerShell Cmdlet Development Guidelines

## Naming Conventions

- **Verb-Noun Format:**
  - Use approved PowerShell verbs (Get-Verb)
  - Use singular nouns
  - PascalCase for both verb and noun
  - Avoid special characters and spaces

- **Parameter Names:**
  - Use PascalCase
  - Choose clear, descriptive names
  - Use singular form unless always multiple
 

---
name: conventional-commit
description: >
  Workflow for generating conventional commit messages following the Conventional Commits
  specification. MUST be invoked every time a commit is created. Guides construction of
  standardized commit messages with correct type, scope, description, body, and footer.
triggers:
  - on_commit
---

# Conventional Commit

## Commit Message Structure

```text
<type>(<scope>): <description>

[optional body]

[optional footer(s)]
```

### Types

| Type       | When to use

---
name: ast-grep
description: Guide for writing ast-grep rules to perform structural code search and analysis. Use when users need to search codebases using Abstract Syntax Tree (AST) patterns, find specific code structures, or perform complex code queries that go beyond simple text search. This skill should be used when users ask to search for code patterns, find specific language constructs, or locate code with particular structural characteristics.
---

# ast-grep Code Search

## Overview

This skill h

---
name: code-changes
description: >
  Orchestration workflow for any task that ends in code changes: issue analysis, pull request review, feature
  implementation, bug fixes, refactors, or fleshing out an idea. MUST be invoked at the start of such a task, before
  reading or writing any code. Defines how to analyze first, gate on user approval, plan, pick the right executor model,
  delegate and supervise subagents, verify, and deliver.
---

# Code Changes

The workflow for going from an issue, pull reque

---
name: writing-clearly-and-concisely
description:
  Apply whenever writing content a human will read — emails, documents, reports, documentation, messages, UI copy,
  commit messages, explanations, or any other prose. Applies Strunk's timeless rules for clearer, stronger, more
  professional writing.
---

# Writing Clearly and Concisely

## Overview

Write with clarity and force. This skill covers what to do (Strunk) and what not to do (AI patterns).

## When to Use This Skill

Use this skill whenever 

# Oh My Posh

> Oh My Posh is the most customizable and fastest prompt theme engine for any shell. It renders
> beautifully themed terminal prompts displaying Git status, language versions, cloud context,
> system metrics and more — 118 segments in all — on Windows, macOS, and Linux.

## Docs

- [Docs hub](/docs/) — Getting started landing page, linking to installation and shell setup
- [Windows Installation](/docs/installation/windows) — winget, chocolatey, or manual install
- [macOS Installation](

# GitHub Copilot Instructions

All agent guidance for this repository lives in [AGENTS.md](../AGENTS.md): project overview,
key commands, architecture orientation, coding and commit conventions, skills, and the
project-knowledge workflow. Follow it in full.