{"owner":"saulpw","repo":"visidata","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md","CLAUDE.md"],"skills":{"AGENTS.md":"# Repository Guidelines\n\n## Start Here (Progressive Disclosure)\n- Read `CLAUDE.md` first for the primary contributor workflow and architecture context.\n- Use focused deep dives only when needed:\n  - `dev/STYLE.md` for coding patterns and API conventions.\n  - `dev/GIT.md` for commit and branch practices.\n  - `dev/DOCS.md` for documentation syntax and style.\n  - `dev/PERFORMANCE.md` for profiling and optimization work.\n- Human gate is required: all AI-assisted code must be reviewed, approved, and tested by a human before merge or PR.\n\n## Project Structure\n- `visidata/`: main package (`features/`, `loaders/`, `apps/`, `themes/`).\n- `tests/`: functional replay tests (`.vd/.vdj/.vdx`) and `tests/golden/` outputs.\n- `visidata/tests/`: Python unit tests.\n- `docs/` and `dev/`: user and developer documentation.\n\n## Build, Test, and Development Commands\n- `python3 -m pip install .`: install local package.\n- `python3 -m pip install \".[test]\"`: install optional test dependencies.\n- `vd --version`: startup sanity check.\n- `pytest -sv visidata/tests/`: run unit tests.\n- `dev/test.sh -j 4`: run functional cmdlog tests and compare `tests/golden/`.\n- `vd . --batch`: quick load smoke test.\n\n## Coding and Command Conventions\n- Follow `dev/STYLE.md` for naming, quoting, decorators, and sheet/column patterns.\n- Use the canonical command pattern shown in `CLAUDE.md`:\n  - `BaseSheet.addCommand('', 'command-name', 'code', 'help text')`\n- For class placement decisions and exceptions, defer to `dev/STYLE.md`.\n\n## Testing Guidelines\n- Update `tests/*.vd*` for workflow-visible behavior changes.\n- Update `visidata/tests/` for isolated Python logic.\n- Before PR: run `pytest -sv visidata/tests/` and `dev/test.sh -j 4`.\n\n## Commit & Pull Request Guidelines\n- Base PRs on `develop` (not `stable`).\n- Follow existing short, imperative subjects; optional scope prefixes like `[test]`, `[docs]`, `[vdsql]`.\n- Keep commits focused and include tests/docs for behavior changes.\n- PRs should include problem, approach, risks, and linked issues; add screenshots/gifs and reproducible `.vd` scripts for UI changes.\n- Follow CAA and copyright assignment requirements in `CONTRIBUTING.md`.\n","CLAUDE.md":"# VisiData Development Guide\n\nQuick reference for VisiData development. For detailed coding patterns, conventions, and best practices, see **[dev/STYLE.md](dev/STYLE.md)**.\n\n`CLAUDE.md` and `AGENTS.md` are complementary: use this file for primary contributor workflow and architecture context, and use `AGENTS.md` for concise agent-oriented repository guidance.\n\n## Important Note About AI Usage\n\nVisiData (created in 2016) is 99% written by humans and is NOT a vibe-coded AI project.  This file is meant to allow AI-assisted development of features and bugfixes.  **All code must be reviewed and approved and tested by a human before being merged into the codebase or submitted as a PR.**\n\n## Repository Structure\n\n```\nvisidata/\n├── visidata/              # Main package\n│   ├── *.py              # Core modules (sheet.py, column.py, etc.)\n│   ├── features/         # Auto-loaded feature plugins\n│   ├── loaders/          # File format loaders\n│   ├── apps/             # Standalone applications\n│   └── experimental/     # Experimental features (load/install with 'import visidata.experimental.foo')\n├── tests/                # Test files\n├── docs/                 # Documentation\n└── dev/                  # Development utilities and docs\n```\n\n## Features Directory (`visidata/features/`)\n\n- All `.py` files in this directory are **automatically imported** when VisiData starts\n- Each feature file should be self-contained\n- Features extend VisiData functionality without modifying core files\n\n## Quick Reference\n\n### Core Classes\n- `BaseSheet` - Minimal sheet functionality\n- `Sheet` / `TableSheet` - Sheet with columns and rows (most common)\n- `Column` - Column definition with getter/setter\n\n### Adding Commands\n```python\nBaseSheet.addCommand('', 'command-name', 'code', 'help text')\n```\n\n### Adding to Global Namespace\n```python\nvd.addGlobals(MyClass=MyClass)  # Use keyword args, not dict\n```\n\n### Adding Menu Items\n```python\nvd.addMenuItems('''\n    Menu > Submenu > Item Name > command-name\n''')\n```\n\n### Example Feature Structure\n```python\nfrom visidata import vd, Sheet, Column\n\n# rowdef: description of what a row represents\nclass MySheet(Sheet):\n    rowtype = 'items'\n    columns = [\n        Column('name', getter=lambda c,r: r.attribute),\n    ]\n\n    def reload(self):\n        self.rows = [...]\n\nBaseSheet.addCommand('', 'my-command', 'code', 'help')\nvd.addGlobals(MySheet=MySheet)\n```\n\n## Development Workflow\n\n1. Add `.py` file to `visidata/features/`\n2. Run `vd` and test interactively\n3. Iterate and refine\n4. Document with docstrings and comments\n\n## Make Targets\n\n- `make test` — run all tests\n- `make help` — list all targets\n\n## Documentation\n\nFor comprehensive development documentation, see the `dev/` directory:\n\n### [dev/STYLE.md](dev/STYLE.md) - Coding Style and Patterns\nUse this when writing code, creating features, or defining sheets and columns.\n- Naming conventions (camelCaps, under_score, etc.)\n- Feature file structure and patterns\n- Sheet and Column class patterns\n- Command and menu integration\n- API decorators\n- Best practices and examples\n\n### [dev/GIT.md](dev/GIT.md) - Version Control Practices\nUse this when making commits or preparing pull requests.\n- Commit message format and conventions\n- Issue tracking in code\n- Branch and merge workflow\n- Patch-safe commit marking\n\n### [dev/DOCS.md](dev/DOCS.md) - Documentation Writing\nUse this when writing user-facing documentation, help text, or in-app guides.\n- VisiData's markdown syntax\n- Display attribute syntax (colors, clickable links)\n- Option and command reference format\n- Technical writing guidelines\n\n### [dev/PERFORMANCE.md](dev/PERFORMANCE.md) - Performance Analysis\nUse this when investigating or optimizing performance issues.\n- Finding reproducible performance issues\n- Profiling techniques and tools\n- Analyzing profiling results\n- Optimization workflow\n\n### [dev/OPTIONS.md](dev/OPTIONS.md) - Options System\nUse this when working with options, adding new options, or understanding how configuration resolves.\n- Resolution chain (instance → class → global → default)\n- How sheets and paths participate in options\n- Setting and reading options at different levels\n\n## Updating Documentation\n\nWhen making **user-facing changes** (new commands, changed behavior, new options, new/changed loaders, UI changes), check [docs/README.md](docs/README.md) to identify which documentation files need to be updated.\n"},"files":{"AGENTS.md":"# Repository Guidelines\n\n## Start Here (Progressive Disclosure)\n- Read `CLAUDE.md` first for the primary contributor workflow and architecture context.\n- Use focused deep dives only when needed:\n  - `dev/STYLE.md` for coding patterns and API conventions.\n  - `dev/GIT.md` for commit and branch practices.\n  - `dev/DOCS.md` for documentation syntax and style.\n  - `dev/PERFORMANCE.md` for profiling and optimization work.\n- Human gate is required: all AI-assisted code must be reviewed, approved, and tested by a human before merge or PR.\n\n## Project Structure\n- `visidata/`: main package (`features/`, `loaders/`, `apps/`, `themes/`).\n- `tests/`: functional replay tests (`.vd/.vdj/.vdx`) and `tests/golden/` outputs.\n- `visidata/tests/`: Python unit tests.\n- `docs/` and `dev/`: user and developer documentation.\n\n## Build, Test, and Development Commands\n- `python3 -m pip install .`: install local package.\n- `python3 -m pip install \".[test]\"`: install optional test dependencies.\n- `vd --version`: startup sanity check.\n- `pytest -sv visidata/tests/`: run unit tests.\n- `dev/test.sh -j 4`: run functional cmdlog tests and compare `tests/golden/`.\n- `vd . --batch`: quick load smoke test.\n\n## Coding and Command Conventions\n- Follow `dev/STYLE.md` for naming, quoting, decorators, and sheet/column patterns.\n- Use the canonical command pattern shown in `CLAUDE.md`:\n  - `BaseSheet.addCommand('', 'command-name', 'code', 'help text')`\n- For class placement decisions and exceptions, defer to `dev/STYLE.md`.\n\n## Testing Guidelines\n- Update `tests/*.vd*` for workflow-visible behavior changes.\n- Update `visidata/tests/` for isolated Python logic.\n- Before PR: run `pytest -sv visidata/tests/` and `dev/test.sh -j 4`.\n\n## Commit & Pull Request Guidelines\n- Base PRs on `develop` (not `stable`).\n- Follow existing short, imperative subjects; optional scope prefixes like `[test]`, `[docs]`, `[vdsql]`.\n- Keep commits focused and include tests/docs for behavior changes.\n- PRs should include problem, approach, risks, and linked issues; add screenshots/gifs and reproducible `.vd` scripts for UI changes.\n- Follow CAA and copyright assignment requirements in `CONTRIBUTING.md`.\n","CLAUDE.md":"# VisiData Development Guide\n\nQuick reference for VisiData development. For detailed coding patterns, conventions, and best practices, see **[dev/STYLE.md](dev/STYLE.md)**.\n\n`CLAUDE.md` and `AGENTS.md` are complementary: use this file for primary contributor workflow and architecture context, and use `AGENTS.md` for concise agent-oriented repository guidance.\n\n## Important Note About AI Usage\n\nVisiData (created in 2016) is 99% written by humans and is NOT a vibe-coded AI project.  This file is meant to allow AI-assisted development of features and bugfixes.  **All code must be reviewed and approved and tested by a human before being merged into the codebase or submitted as a PR.**\n\n## Repository Structure\n\n```\nvisidata/\n├── visidata/              # Main package\n│   ├── *.py              # Core modules (sheet.py, column.py, etc.)\n│   ├── features/         # Auto-loaded feature plugins\n│   ├── loaders/          # File format loaders\n│   ├── apps/             # Standalone applications\n│   └── experimental/     # Experimental features (load/install with 'import visidata.experimental.foo')\n├── tests/                # Test files\n├── docs/                 # Documentation\n└── dev/                  # Development utilities and docs\n```\n\n## Features Directory (`visidata/features/`)\n\n- All `.py` files in this directory are **automatically imported** when VisiData starts\n- Each feature file should be self-contained\n- Features extend VisiData functionality without modifying core files\n\n## Quick Reference\n\n### Core Classes\n- `BaseSheet` - Minimal sheet functionality\n- `Sheet` / `TableSheet` - Sheet with columns and rows (most common)\n- `Column` - Column definition with getter/setter\n\n### Adding Commands\n```python\nBaseSheet.addCommand('', 'command-name', 'code', 'help text')\n```\n\n### Adding to Global Namespace\n```python\nvd.addGlobals(MyClass=MyClass)  # Use keyword args, not dict\n```\n\n### Adding Menu Items\n```python\nvd.addMenuItems('''\n    Menu > Submenu > Item Name > command-name\n''')\n```\n\n### Example Feature Structure\n```python\nfrom visidata import vd, Sheet, Column\n\n# rowdef: description of what a row represents\nclass MySheet(Sheet):\n    rowtype = 'items'\n    columns = [\n        Column('name', getter=lambda c,r: r.attribute),\n    ]\n\n    def reload(self):\n        self.rows = [...]\n\nBaseSheet.addCommand('', 'my-command', 'code', 'help')\nvd.addGlobals(MySheet=MySheet)\n```\n\n## Development Workflow\n\n1. Add `.py` file to `visidata/features/`\n2. Run `vd` and test interactively\n3. Iterate and refine\n4. Document with docstrings and comments\n\n## Make Targets\n\n- `make test` — run all tests\n- `make help` — list all targets\n\n## Documentation\n\nFor comprehensive development documentation, see the `dev/` directory:\n\n### [dev/STYLE.md](dev/STYLE.md) - Coding Style and Patterns\nUse this when writing code, creating features, or defining sheets and columns.\n- Naming conventions (camelCaps, under_score, etc.)\n- Feature file structure and patterns\n- Sheet and Column class patterns\n- Command and menu integration\n- API decorators\n- Best practices and examples\n\n### [dev/GIT.md](dev/GIT.md) - Version Control Practices\nUse this when making commits or preparing pull requests.\n- Commit message format and conventions\n- Issue tracking in code\n- Branch and merge workflow\n- Patch-safe commit marking\n\n### [dev/DOCS.md](dev/DOCS.md) - Documentation Writing\nUse this when writing user-facing documentation, help text, or in-app guides.\n- VisiData's markdown syntax\n- Display attribute syntax (colors, clickable links)\n- Option and command reference format\n- Technical writing guidelines\n\n### [dev/PERFORMANCE.md](dev/PERFORMANCE.md) - Performance Analysis\nUse this when investigating or optimizing performance issues.\n- Finding reproducible performance issues\n- Profiling techniques and tools\n- Analyzing profiling results\n- Optimization workflow\n\n### [dev/OPTIONS.md](dev/OPTIONS.md) - Options System\nUse this when working with options, adding new options, or understanding how configuration resolves.\n- Resolution chain (instance → class → global → default)\n- How sheets and paths participate in options\n- Setting and reading options at different levels\n\n## Updating Documentation\n\nWhen making **user-facing changes** (new commands, changed behavior, new options, new/changed loaders, UI changes), check [docs/README.md](docs/README.md) to identify which documentation files need to be updated.\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","title":"AGENTS.md","content":"# Repository Guidelines\n\n## Start Here (Progressive Disclosure)\n- Read `CLAUDE.md` first for the primary contributor workflow and architecture context.\n- Use focused deep dives only when needed:\n  - `dev/STYLE.md` for coding patterns and API conventions.\n  - `dev/GIT.md` for commit and branch practices.\n  - `dev/DOCS.md` for documentation syntax and style.\n  - `dev/PERFORMANCE.md` for profiling and optimization work.\n- Human gate is required: all AI-assisted code must be reviewed, approved, and tested by a human before merge or PR.\n\n## Project Structure\n- `visidata/`: main package (`features/`, `loaders/`, `apps/`, `themes/`).\n- `tests/`: functional replay tests (`.vd/.vdj/.vdx`) and `tests/golden/` outputs.\n- `visidata/tests/`: Python unit tests.\n- `docs/` and `dev/`: user and developer documentation.\n\n## Build, Test, and Development Commands\n- `python3 -m pip install .`: install local package.\n- `python3 -m pip install \".[test]\"`: install optional test dependencies.\n- `vd --version`: startup sanity check.\n- `pytest -sv visidata/tests/`: run unit tests.\n- `dev/test.sh -j 4`: run functional cmdlog tests and compare `tests/golden/`.\n- `vd . --batch`: quick load smoke test.\n\n## Coding and Command Conventions\n- Follow `dev/STYLE.md` for naming, quoting, decorators, and sheet/column patterns.\n- Use the canonical command pattern shown in `CLAUDE.md`:\n  - `BaseSheet.addCommand('', 'command-name', 'code', 'help text')`\n- For class placement decisions and exceptions, defer to `dev/STYLE.md`.\n\n## Testing Guidelines\n- Update `tests/*.vd*` for workflow-visible behavior changes.\n- Update `visidata/tests/` for isolated Python logic.\n- Before PR: run `pytest -sv visidata/tests/` and `dev/test.sh -j 4`.\n\n## Commit & Pull Request Guidelines\n- Base PRs on `develop` (not `stable`).\n- Follow existing short, imperative subjects; optional scope prefixes like `[test]`, `[docs]`, `[vdsql]`.\n- Keep commits focused and include tests/docs for behavior changes.\n- PRs should include problem, approach, risks, and linked issues; add screenshots/gifs and reproducible `.vd` scripts for UI changes.\n- Follow CAA and copyright assignment requirements in `CONTRIBUTING.md`.\n","category":"root","tokens":544},{"name":"CLAUDE.md","path":"CLAUDE.md","title":"CLAUDE.md","content":"# VisiData Development Guide\n\nQuick reference for VisiData development. For detailed coding patterns, conventions, and best practices, see **[dev/STYLE.md](dev/STYLE.md)**.\n\n`CLAUDE.md` and `AGENTS.md` are complementary: use this file for primary contributor workflow and architecture context, and use `AGENTS.md` for concise agent-oriented repository guidance.\n\n## Important Note About AI Usage\n\nVisiData (created in 2016) is 99% written by humans and is NOT a vibe-coded AI project.  This file is meant to allow AI-assisted development of features and bugfixes.  **All code must be reviewed and approved and tested by a human before being merged into the codebase or submitted as a PR.**\n\n## Repository Structure\n\n```\nvisidata/\n├── visidata/              # Main package\n│   ├── *.py              # Core modules (sheet.py, column.py, etc.)\n│   ├── features/         # Auto-loaded feature plugins\n│   ├── loaders/          # File format loaders\n│   ├── apps/             # Standalone applications\n│   └── experimental/     # Experimental features (load/install with 'import visidata.experimental.foo')\n├── tests/                # Test files\n├── docs/                 # Documentation\n└── dev/                  # Development utilities and docs\n```\n\n## Features Directory (`visidata/features/`)\n\n- All `.py` files in this directory are **automatically imported** when VisiData starts\n- Each feature file should be self-contained\n- Features extend VisiData functionality without modifying core files\n\n## Quick Reference\n\n### Core Classes\n- `BaseSheet` - Minimal sheet functionality\n- `Sheet` / `TableSheet` - Sheet with columns and rows (most common)\n- `Column` - Column definition with getter/setter\n\n### Adding Commands\n```python\nBaseSheet.addCommand('', 'command-name', 'code', 'help text')\n```\n\n### Adding to Global Namespace\n```python\nvd.addGlobals(MyClass=MyClass)  # Use keyword args, not dict\n```\n\n### Adding Menu Items\n```python\nvd.addMenuItems('''\n    Menu > Submenu > Item Name > command-name\n''')\n```\n\n### Example Feature Structure\n```python\nfrom visidata import vd, Sheet, Column\n\n# rowdef: description of what a row represents\nclass MySheet(Sheet):\n    rowtype = 'items'\n    columns = [\n        Column('name', getter=lambda c,r: r.attribute),\n    ]\n\n    def reload(self):\n        self.rows = [...]\n\nBaseSheet.addCommand('', 'my-command', 'code', 'help')\nvd.addGlobals(MySheet=MySheet)\n```\n\n## Development Workflow\n\n1. Add `.py` file to `visidata/features/`\n2. Run `vd` and test interactively\n3. Iterate and refine\n4. Document with docstrings and comments\n\n## Make Targets\n\n- `make test` — run all tests\n- `make help` — list all targets\n\n## Documentation\n\nFor comprehensive development documentation, see the `dev/` directory:\n\n### [dev/STYLE.md](dev/STYLE.md) - Coding Style and Patterns\nUse this when writing code, creating features, or defining sheets and columns.\n- Naming conventions (camelCaps, under_score, etc.)\n- Feature file structure and patterns\n- Sheet and Column class patterns\n- Command and menu integration\n- API decorators\n- Best practices and examples\n\n### [dev/GIT.md](dev/GIT.md) - Version Control Practices\nUse this when making commits or preparing pull requests.\n- Commit message format and conventions\n- Issue tracking in code\n- Branch and merge workflow\n- Patch-safe commit marking\n\n### [dev/DOCS.md](dev/DOCS.md) - Documentation Writing\nUse this when writing user-facing documentation, help text, or in-app guides.\n- VisiData's markdown syntax\n- Display attribute syntax (colors, clickable links)\n- Option and command reference format\n- Technical writing guidelines\n\n### [dev/PERFORMANCE.md](dev/PERFORMANCE.md) - Performance Analysis\nUse this when investigating or optimizing performance issues.\n- Finding reproducible performance issues\n- Profiling techniques and tools\n- Analyzing profiling results\n- Optimization workflow\n\n### [dev/OPTIONS.md](dev/OPTIONS.md) - Options System\nUse this when working with options, adding new options, or understanding how configuration resolves.\n- Resolution chain (instance → class → global → default)\n- How sheets and paths participate in options\n- Setting and reading options at different levels\n\n## Updating Documentation\n\nWhen making **user-facing changes** (new commands, changed behavior, new options, new/changed loaders, UI changes), check [docs/README.md](docs/README.md) to identify which documentation files need to be updated.\n","category":"root","tokens":1103}]}