onetool-mcp 1.0.0b1__tar.gz

onetool_mcp-1.0.0b1/.chunkhound.json

@@ -0,0 +1,37 @@
+{
+  "database": {
+    "provider": "duckdb"
+  },
+  "embedding": {
+    "provider": "openai",
+    "model": "text-embedding-3-small",
+    "base_url": "https://openrouter.ai/api/v1"
+  },
+  "indexing": {
+    "include": [
+      "**/*.py",
+      "**/*.md",
+      "**/*.yaml",
+      "**/*.toml",
+      "**/*.json"
+    ],
+    "exclude": [
+      "**/node_modules/**",
+      "**/__pycache__/**",
+      "**/.venv/**",
+      "**/dist/**",
+      "**/build/**",
+      "**/*.egg-info/**",
+      "**/.git/**",
+      "**/.local/**",
+      "**/htmlcov/**",
+      "**/.mypy_cache/**",
+      "**/.pytest_cache/**",
+      "**/.ruff_cache/**"
+    ]
+  },
+  "mcp": {
+    "transport": "stdio"
+  },
+  "debug": false
+}

onetool_mcp-1.0.0b1/.claude/commands/openspec/apply.md

@@ -0,0 +1,23 @@
+---
+name: OpenSpec: Apply
+description: Implement an approved OpenSpec change and keep tasks in sync.
+category: OpenSpec
+tags: [openspec, apply]
+---
+<!-- OPENSPEC:START -->
+**Guardrails**
+- Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required.
+- Keep changes tightly scoped to the requested outcome.
+- Refer to `openspec/AGENTS.md` (located inside the `openspec/` directory—run `ls openspec` or `openspec update` if you don't see it) if you need additional OpenSpec conventions or clarifications.
+
+**Steps**
+Track these steps as TODOs and complete them one by one.
+1. Read `changes/<id>/proposal.md`, `design.md` (if present), and `tasks.md` to confirm scope and acceptance criteria.
+2. Work through tasks sequentially, keeping edits minimal and focused on the requested change.
+3. Confirm completion before updating statuses—make sure every item in `tasks.md` is finished.
+4. Update the checklist after all work is done so each task is marked `- [x]` and reflects reality.
+5. Reference `openspec list` or `openspec show <item>` when additional context is required.
+
+**Reference**
+- Use `openspec show <id> --json --deltas-only` if you need additional context from the proposal while implementing.
+<!-- OPENSPEC:END -->

onetool_mcp-1.0.0b1/.claude/commands/openspec/archive.md

@@ -0,0 +1,27 @@
+---
+name: OpenSpec: Archive
+description: Archive a deployed OpenSpec change and update specs.
+category: OpenSpec
+tags: [openspec, archive]
+---
+<!-- OPENSPEC:START -->
+**Guardrails**
+- Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required.
+- Keep changes tightly scoped to the requested outcome.
+- Refer to `openspec/AGENTS.md` (located inside the `openspec/` directory—run `ls openspec` or `openspec update` if you don't see it) if you need additional OpenSpec conventions or clarifications.
+
+**Steps**
+1. Determine the change ID to archive:
+   - If this prompt already includes a specific change ID (for example inside a `<ChangeId>` block populated by slash-command arguments), use that value after trimming whitespace.
+   - If the conversation references a change loosely (for example by title or summary), run `openspec list` to surface likely IDs, share the relevant candidates, and confirm which one the user intends.
+   - Otherwise, review the conversation, run `openspec list`, and ask the user which change to archive; wait for a confirmed change ID before proceeding.
+   - If you still cannot identify a single change ID, stop and tell the user you cannot archive anything yet.
+2. Validate the change ID by running `openspec list` (or `openspec show <id>`) and stop if the change is missing, already archived, or otherwise not ready to archive.
+3. Run `openspec archive <id> --yes` so the CLI moves the change and applies spec updates without prompts (use `--skip-specs` only for tooling-only work).
+4. Review the command output to confirm the target specs were updated and the change landed in `changes/archive/`.
+5. Validate with `openspec validate --strict` and inspect with `openspec show <id>` if anything looks off.
+
+**Reference**
+- Use `openspec list` to confirm change IDs before archiving.
+- Inspect refreshed specs with `openspec list --specs` and address any validation issues before handing off.
+<!-- OPENSPEC:END -->

onetool_mcp-1.0.0b1/.claude/commands/openspec/proposal.md

@@ -0,0 +1,28 @@
+---
+name: OpenSpec: Proposal
+description: Scaffold a new OpenSpec change and validate strictly.
+category: OpenSpec
+tags: [openspec, change]
+---
+<!-- OPENSPEC:START -->
+**Guardrails**
+- Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required.
+- Keep changes tightly scoped to the requested outcome.
+- Refer to `openspec/AGENTS.md` (located inside the `openspec/` directory—run `ls openspec` or `openspec update` if you don't see it) if you need additional OpenSpec conventions or clarifications.
+- Identify any vague or ambiguous details and ask the necessary follow-up questions before editing files.
+- Do not write any code during the proposal stage. Only create design documents (proposal.md, tasks.md, design.md, and spec deltas). Implementation happens in the apply stage after approval.
+
+**Steps**
+1. Review `openspec/project.md`, run `openspec list` and `openspec list --specs`, and inspect related code or docs (e.g., via `rg`/`ls`) to ground the proposal in current behaviour; note any gaps that require clarification.
+2. Choose a unique verb-led `change-id` and scaffold `proposal.md`, `tasks.md`, and `design.md` (when needed) under `openspec/changes/<id>/`.
+3. Map the change into concrete capabilities or requirements, breaking multi-scope efforts into distinct spec deltas with clear relationships and sequencing.
+4. Capture architectural reasoning in `design.md` when the solution spans multiple systems, introduces new patterns, or demands trade-off discussion before committing to specs.
+5. Draft spec deltas in `changes/<id>/specs/<capability>/spec.md` (one folder per capability) using `## ADDED|MODIFIED|REMOVED Requirements` with at least one `#### Scenario:` per requirement and cross-reference related capabilities when relevant.
+6. Draft `tasks.md` as an ordered list of small, verifiable work items that deliver user-visible progress, include validation (tests, tooling), and highlight dependencies or parallelizable work.
+7. Validate with `openspec validate <id> --strict` and resolve every issue before sharing the proposal.
+
+**Reference**
+- Use `openspec show <id> --json --deltas-only` or `openspec show <spec> --type spec` to inspect details when validation fails.
+- Search existing requirements with `rg -n "Requirement:|Scenario:" openspec/specs` before writing new ones.
+- Explore the codebase with `rg <keyword>`, `ls`, or direct file reads so proposals align with current implementation realities.
+<!-- OPENSPEC:END -->

onetool_mcp-1.0.0b1/.claude/commands/proj/consult.md

@@ -0,0 +1,63 @@
+---
+name: Consult
+description: Interactive consultation mode for research and Q&A. Can save findings on explicit request.
+category: onetool
+tags: [consultation, research, qa, findings]
+---
+
+**Assumptions**
+- Uses openspec (`openspec/project.md` for context)
+- Language agnostic
+
+**Guardrails**
+- This is primarily a READ-ONLY consultation session. You MUST NOT:
+  - Make git commits or push changes
+  - Run commands that modify the system (e.g., `git commit`, `rm`, `mv`, `npm install`)
+  - Modify existing project source code
+- You CAN and SHOULD:
+  - Read files, search code, and explore the codebase
+  - Run read-only commands (e.g., `git log`, `git status`, `git diff`, `ls`, `cat`)
+  - Use web search for up-to-date information
+  - Answer questions thoroughly with code references
+  - Ask clarifying questions to understand user needs
+- **Writing Findings (on explicit request only)**:
+  - When the user explicitly asks to save, write, or document findings (e.g., "save these findings", "write this up", "document what we found"):
+    - Suggest a descriptive filename based on the topic discussed
+    - Write findings to `plan/consult/<name>.md` (create directory if needed)
+    - Unless user specifies a different location
+    - Use a clear heading with date/time and topic
+    - Include key discoveries, code references, and conclusions
+  - Do NOT write findings unless the user explicitly requests it
+- The session continues until the user explicitly ends it (e.g., "end consultation", "done consulting", "exit consult mode").
+
+**Steps**
+1. Begin the consultation:
+   - Acknowledge entering consultation mode.
+   - Briefly explain the read-only constraints.
+   - Ask what the user would like to explore or discuss.
+2. Handle each question:
+   - Listen to the user's question or topic.
+   - Use read-only tools (Read, Glob, Grep, WebSearch, WebFetch, Task with Explore agent) to research.
+   - Provide clear, detailed answers with file references where relevant.
+   - Ask follow-up questions if clarification is needed.
+3. Continue the dialogue:
+   - After answering, check if the user has more questions.
+   - Offer to dive deeper into related topics.
+   - Suggest areas that might be worth exploring.
+4. Save findings (on explicit request):
+   - When user asks to save/document findings:
+     - Suggest a filename: "I'll save this as `plan/consult/<topic>.md` - sound good?"
+     - Create `plan/consult/` directory if it doesn't exist
+     - Write with dated heading and key discoveries
+     - Confirm what was written
+5. End the session:
+   - When the user signals they are done (e.g., "end consultation", "done", "exit"):
+     - Summarize key findings from the session.
+     - Suggest next steps if applicable (e.g., creating a proposal, making changes).
+     - Confirm the session has ended.
+
+**Reference**
+- Use exploration agents (Task with subagent_type=Explore) for open-ended codebase questions.
+- Reference files using markdown link format: `[filename.ts](path/to/file.ts)`.
+- For web research, cite sources in your answers.
+- Cross-reference with `openspec/project.md` for project context when relevant.

onetool_mcp-1.0.0b1/.claude/commands/proj/doc-sync.md

@@ -0,0 +1,165 @@
+---
+name: Doc Sync
+description: Check code and ensure documentation is in sync with implementation.
+category: onetool
+tags: [documentation, sync, review, tools, cli]
+---
+
+## Purpose
+
+Verify that all documentation accurately reflects the current implementation by reviewing CLI commands and tools against their documentation.
+
+## Scope
+- README.md
+- All docs in `/docs`
+- `docs/llms.txt`
+
+**Guardrails**
+- DO NOT make changes without explicit user confirmation
+- DO NOT create commits - this is a review command
+- Present findings clearly in a table format
+- Code is the source of truth - docs should match implementation
+
+---
+
+## Step 1: CLI Documentation Sync
+
+Review each CLI command against its documentation.
+
+### 1.1 onetool
+
+Compare `src/onetool/` implementation with:
+- `docs/reference/cli/onetool.md`
+- README.md CLI section
+- `docs/llms.txt` CLI section
+
+Check for:
+- Command line flags and options match implementation
+- Default values are accurate
+- Environment variables are documented
+- Usage examples work correctly
+
+### 1.2 bench
+
+Compare `src/bench/` implementation with:
+- `docs/reference/cli/bench.md`
+- README.md CLI section (if mentioned)
+- `docs/llms.txt` CLI section
+
+Check for:
+- Command line flags and options match implementation
+- Default values are accurate
+- Environment variables are documented
+- Usage examples work correctly
+
+### 1.3 Other CLIs
+
+Check for any additional CLI entry points in `pyproject.toml` and verify they are documented.
+
+---
+
+## Step 2: Tool Documentation Sync
+
+Review each tool namespace against its documentation.
+
+For each tool in `src/ot_tools/`:
+
+### 2.1 Read the Implementation
+
+- Read the tool source file
+- Note the `namespace` variable
+- List all public functions with their signatures
+- Extract docstrings and parameter descriptions
+- Note default values and required parameters
+
+### 2.2 Compare with Documentation
+
+Compare against:
+- `docs/reference/tools/<namespace>.md`
+- `docs/llms.txt` tool listing
+- README.md (if tool is mentioned in features/capabilities)
+
+Check for:
+- Function names match documentation
+- Parameter names and types match
+- Default values are accurate
+- Docstrings align with documentation descriptions
+- All public functions are documented
+- No documented functions that don't exist in code
+
+### 2.3 Tools to Review
+
+Process each tool file in `src/ot_tools/`:
+
+1. `brave_search.py` → `docs/reference/tools/brave-search.md`
+2. `web_fetch.py` → `docs/reference/tools/web-fetch.md`
+3. `context7.py` → `docs/reference/tools/context7.md`
+4. `code_search.py` → `docs/reference/tools/code-search.md`
+5. `transform.py` → `docs/reference/tools/transform.md`
+6. `db.py` → `docs/reference/tools/database.md`
+7. `package.py` → `docs/reference/tools/package.md`
+8. `ripgrep.py` → `docs/reference/tools/ripgrep.md`
+9. `excel.py` → `docs/reference/tools/excel.md`
+10. `file.py` → `docs/reference/tools/file.md`
+11. `diagram.py` → `docs/reference/tools/diagram.md`
+12. `convert.py` → `docs/reference/tools/convert.md`
+13. `grounding_search.py` → `docs/reference/tools/grounding-search.md`
+14. `internal.py` → `docs/reference/tools/ot.md`
+
+---
+
+## Step 3: Cross-Document Consistency
+
+### 3.1 README.md
+
+Verify README accurately reflects:
+- List of namespaces/tools matches actual tools
+- Feature descriptions match implementation
+- Installation instructions work
+- Quick start examples are accurate
+- Links to docs are valid
+
+### 3.2 docs/llms.txt
+
+Verify `docs/llms.txt` reflects:
+- All namespaces are listed
+- Function names for each namespace are accurate
+- No missing or extra functions
+- Quick invocation examples work
+
+### 3.3 Index Pages
+
+Check that index pages list all relevant items:
+- `docs/reference/tools/index.md` lists all tool docs
+- `docs/reference/cli/index.md` lists all CLI docs
+
+---
+
+## Step 4: Present Findings
+
+After completing all reviews, present a consolidated findings table:
+
+```text
+| # | Area | Doc File | Issue Type | Description | Suggested Fix |
+|---|------|----------|------------|-------------|---------------|
+```
+
+Issue Types:
+- `missing` - Feature/function exists in code but not documented
+- `outdated` - Documentation exists but doesn't match current implementation
+- `incorrect` - Documentation contains wrong information
+- `removed` - Documentation describes something that no longer exists
+- `broken` - Examples or links that don't work
+
+Group findings by:
+1. CLI issues
+2. Tool issues (grouped by namespace)
+3. Cross-document issues
+
+---
+
+## Step 5: Apply Fixes
+
+Present the numbered list and ASK: "Which issues would you like me to fix? (e.g., '1, 3, 5', 'all', 'none')"
+
+Apply only the confirmed fixes, then show a summary of changes made.

onetool_mcp-1.0.0b1/.claude/commands/proj/prime.md

@@ -0,0 +1,8 @@
+---
+name: Prime
+description: Load project context from AGENTS_PRIME.md
+---
+
+Read and present the contents of `AGENTS_PRIME.md` to prime the conversation with project context.
+
+After reading, briefly confirm the context is loaded and ask what the user would like to work on.

onetool_mcp-1.0.0b1/.claude/commands/proj/quick-apply.md

@@ -0,0 +1,183 @@
+---
+name: Quick Apply
+description: Plan and apply small changes across code, tests, specs, docs, and config in one pass.
+category: onetool
+tags: [apply, quick, change, all-in-one]
+---
+
+## Purpose
+
+Streamlined workflow for small-to-medium changes that don't warrant full OpenSpec proposal scaffolding. Combines planning, implementation, spec updates, doc sync, and config migration into a single pass.
+
+**Use this for:**
+- Bug fixes with clear scope
+- Small features or enhancements
+- Refactoring with known boundaries
+- Config migrations
+- Documentation updates with code changes
+
+**Use OpenSpec proposal instead for:**
+- Breaking changes
+- New capabilities spanning multiple systems
+- Architectural decisions needing design review
+- Changes requiring stakeholder approval
+
+---
+
+## Input
+
+This command accepts either:
+1. **Direct instruction** - Describe the change in the conversation
+2. **Markdown file** - Reference a file with change details (e.g., `plan/consult/some-fix.md`)
+
+If input is unclear, ASK the user to clarify before proceeding.
+
+---
+
+## Guardrails
+
+- Keep changes tightly scoped to the requested outcome
+- Favor straightforward, minimal implementations
+- Code is the source of truth - specs and docs follow implementation
+- DO NOT create commits unless explicitly requested
+- Present a plan before making changes
+- ASK before proceeding to each major phase
+
+---
+
+## Step 1: Understand the Change
+
+1. Read any referenced files or instructions
+2. Explore relevant code with `rg` or file reads to understand current state
+3. Identify all affected areas:
+   - Source files to modify
+   - Tests to add/update
+   - Specs to update
+   - Docs to sync
+   - Config to migrate
+
+---
+
+## Step 2: Present the Plan
+
+Show a concise plan:
+
+```text
+## Change: <one-line summary>
+
+### Code Changes
+- [ ] file.py: <what changes>
+
+### Test Changes
+- [ ] test_file.py: <what changes>
+
+### Spec Updates
+- [ ] openspec/specs/<spec>/spec.md: <what changes>
+
+### Doc Updates
+- [ ] docs/<file>.md: <what changes>
+- [ ] README.md: <if affected>
+
+### Config Changes
+- [ ] <config file>: <what changes>
+```
+
+ASK: "Does this plan look correct? Reply 'yes' to proceed or suggest changes."
+
+Wait for confirmation before proceeding.
+
+---
+
+## Step 3: Apply Code Changes
+
+1. Make the code changes as planned
+2. Keep edits minimal and focused
+3. Run linting/type checks if configured
+4. Report any issues encountered
+
+---
+
+## Step 4: Apply Test Changes
+
+1. Add or update tests for the changed behavior
+2. Follow project testing conventions (see `AGENTS.md`)
+3. Ensure tests have proper markers (smoke/unit/integration, component tags)
+4. Run affected tests to verify they pass
+
+Report test results before proceeding.
+
+---
+
+## Step 5: Update Specs
+
+If specs exist for the changed functionality:
+
+1. Locate relevant specs in `openspec/specs/`
+2. Update requirements to match new implementation
+3. Update or add scenarios as needed
+4. Run `openspec validate --strict` if available
+
+Skip this step if no specs are affected.
+
+---
+
+## Step 6: Sync Documentation
+
+Review and update affected docs:
+
+### 6.1 README.md
+- Update if features, usage, or examples changed
+
+### 6.2 docs/ files
+- Update relevant documentation pages
+- Ensure code examples are accurate
+- Update CLI flags or API signatures
+
+### 6.3 docs/llms.txt
+- Update if tool functions or CLI changed
+
+### 6.4 Docstrings
+- Ensure function docstrings match new behavior
+
+---
+
+## Step 7: Config Migration
+
+If config changes are needed:
+
+1. Update default config values
+2. Add migration logic if breaking existing configs
+3. Update config documentation
+4. Test config loading with new values
+
+---
+
+## Step 8: OpenSpec spec check
+
+Verify that any specs in `openspec/specs/` affected by your changes are accurate and complete. Code is the source of truth—specs must match the implementation.
+
+## Step 9: Summary
+
+Present a summary of all changes:
+
+```text
+
+## Summary of Applied Changes
+
+### Code
+- ✅ file.py: <summary>
+
+### Tests
+- ✅ test_file.py: <summary>
+- Test results: X passed
+
+### Specs
+- ✅ spec.md: <summary>
+
+### Docs
+- ✅ README.md: <summary>
+
+### Config
+- ✅ config.yaml: <summary>
+
+```