vtx-coding-agent 0.1.7__tar.gz → 0.1.9__tar.gz

vtx_coding_agent-0.1.9/.gitignore

@@ -0,0 +1,27 @@
+# Python-generated files
+__pycache__/
+*.py[oc]
+build/
+dist/
+wheels/
+*.egg-info
+
+# Virtual environments
+.venv
+
+# macOS
+.DS_Store
+
+# Exported vtx sessions
+vtx-session-*
+
+# Local editor settings
+.vscode/
+.env
+.pytest_cache/
+.ruff_cache/
+# One-off screenshots
+image.png
+site/node_modules/
+model-merge/
+vscode-vtx/node_modules/

vtx_coding_agent-0.1.9/AGENTS.md

@@ -0,0 +1,46 @@
+# Agent Guidelines
+
+## Code Style
+
+- Don't add trivial docstrings. Only add docstrings when explaining complex functionality.
+- This project uses `uv`. Run `uv run ruff format .` after editing or creating any files.
+- If generating and running a Python script, use `uv run python` instead of `python`.
+
+## Testing
+
+- After making changes, run only the tests relevant to those changes using `uv run python -m pytest path/to/test_file.py`
+- If the user asks for e2e tests then run the vtx-tmux e2e test if available
+- Never run the full test suite unless the user explicitly asks for it. It can take a long time to run and is not always necessary.
+
+## Skills
+
+- Vtx supports registering a skill as a slash command by setting `register_cmd: true` in the SKILL.md frontmatter. If a user asks for a "registered" skill, include this field.
+
+## Committing code
+
+- If the user tells you to commit code, look at all the changes and create multiple commits if needed based on logical groupings
+- Follow commit message conventions: `docs:`, `feat:`, `fix:`, `build:`, etc. for the commit prefix
+
+## Pushing
+
+- If the user asks you to push code, run these first before doing so: `uv run ruff format .`, `uv run ruff check .`, `uvx ty check  .` and `uv run python -m pytest` in parallel (same tool call)
+- Only if these all pass without issues should you push otherwise report the warnings/errors back to user and ask for next steps
+
+## CodeBase Search
+
+Search the codebase using semantic + BM25 hybrid retrieval. PREFER this over grep/rg/Glob for finding code.
+
+Use this tool when you need to:
+- Find where a function, class, or pattern is implemented
+- Understand how a feature or concept works across the codebase
+- Locate code by describing what it does (not just exact strings)
+- Find examples of a pattern or API usage
+- Explore unfamiliar parts of the codebase
+- Identify relevant code for a task without knowing exact names or locations
+- Preferable than grep/rg/Glob for code search because it can understand the meaning and intent behind the query, rather than just matching exact strings. This allows for more flexible and powerful searching, especially in large and complex codebases.
+Advantages over text search: understands synonyms, paraphrases, and intent.
+Returns file paths, line ranges, relevance scores, and matching code.
+
+- For codebase Search use `vortexa -q "you natural query here"` to get relevant code snippets from the codebase. This will help you understand the existing code and avoid duplicating functionality.
+
+- Instead of using grep use rg (ripgrep) for faster and more efficient searching. For example, `rg "def my_function"` to find all occurrences of a function definition.