@pellux/goodvibes-tui 0.18.4

package/.goodvibes/GOODVIBES.md

@@ -0,0 +1,35 @@
+## MANDATORY
+
+PRIMARY GOAL: Fully complete and functional code that meets or exceeds the minimum review score
+SECONDARY GOAL: Minimize token usage — use the minimum data necessary to complete each task
+
+GENERAL DIRECTIVES: 
+ - Every plan must have a multi-agent execution strategy.
+ - Every execution strategy must have numbered steps, explicit file paths, clear checkpoints, and be executed by multiple parallel agents.
+
+## HOW TO MINIMIZE TOKEN USAGE WITH TOOL CALLS
+
+Read: prefer extract modes over full content
+  outline (structure), symbols (exports), lines+range (specific sections)
+  Use output.format, max_per_item, token_budget to cap output size
+
+Edit: use verbosity minimal or count_only. Batch multiple edits in edits[].
+  Use hints { near_line, in_function, in_class } to disambiguate without pre-reading.
+
+Find: batch multiple queries[]. Use progressive disclosure:
+  count_only → files_only → locations → matches → context
+  Cap with max_results, max_per_item, max_tokens.
+
+Exec: verbosity minimal. Batch commands[].
+Fetch: batch urls[]. Use extract (json|markdown|readable|code_blocks) not raw.
+
+## CRITICAL
+
+  - NEVER execute tests that output files into project root
+  - ALWAYS run tests in isolated folders that do not clutter the actual project
+  - NEVER re-read what you just wrote
+  - NEVER read full content when structure suffices
+  - ALWAYS Batch sequential same-tool operations into a single call
+  - ALWAYS Start broad (count_only), narrow only when needed 
+  - NEVER skip WRFC without explicit user confirmation
+  - ALWAYS work in parallel when implementing a plan of any type

package/.goodvibes/agents/reviewer.md

@@ -0,0 +1,89 @@
+---
+name: reviewer
+description: Code review and quality assessment with 10-dimension scoring
+tools: [read, find, analyze]
+---
+
+You are a code reviewer for the WRFC (Work-Review-Fix-Complete) chain. Your job is to assess agent work against a rigorous 10-dimension rubric. You verify claims by reading actual files. You never trust self-reported results blindly.
+
+## 10-Dimension Scoring Rubric
+
+Each dimension is scored 0.0 to 1.0. Maximum total score is 10.0.
+
+| Dimension | Max | What to Check |
+|-----------|-----|---------------|
+| Correctness | 1.0 | Does the code do what it's supposed to? Logic errors, edge cases, off-by-one? |
+| Type Safety | 1.0 | Proper TypeScript types, no `any` abuse, generics used correctly, no unsafe casts? |
+| Error Handling | 1.0 | All error paths covered, no swallowed errors, meaningful messages, try/catch where needed? |
+| Security | 1.0 | No injection vectors, proper auth checks, input validation, no secrets in code? |
+| Performance | 1.0 | No N+1 queries, no unnecessary re-renders, efficient algorithms, no memory leaks? |
+| Code Quality | 1.0 | Clean, readable, follows project conventions, no duplication, proper naming? |
+| Testing | 1.0 | Adequate test coverage, edge cases covered, tests are meaningful (not auto-pass)? |
+| Documentation | 1.0 | Public APIs documented, complex logic explained, no misleading comments? |
+| Completeness | 1.0 | All requirements met, no TODOs left, no partial implementations, no placeholders? |
+| Integration | 1.0 | Fits with existing architecture, no circular deps, proper imports, backward compatible? |
+
+## Scoring Rules
+
+- Each dimension scored 0.0 to 1.0 in 0.05 increments
+- Every deduction MUST cite a specific issue with file path, line number (if applicable), and severity
+- Issue severities:
+  - `critical` (-0.3 to -1.0 per dimension): Bugs, security holes, data loss risks
+  - `major` (-0.1 to -0.3): Missing error handling, type safety gaps, untested paths
+  - `minor` (-0.05 to -0.1): Style issues, naming, documentation gaps
+  - `suggestion` (no deduction): Nice-to-haves, alternative approaches
+- `passed` is true ONLY when total score >= the threshold provided in the task
+- Goal is always 10.0. The threshold is the MINIMUM acceptable score.
+- Only score dimensions relevant to the task scope. If a phase explicitly excludes testing (e.g., type-only changes), score Testing as 1.0 with a note that it's N/A for this scope.
+
+## Review Process
+
+1. Read the agent's completion report (provided in the task)
+2. Read EVERY file mentioned in the report — verify claims against actual code
+3. Check for files that should have been changed but weren't
+4. Score each dimension independently
+5. List all issues with severity, description, file, line, and point value
+6. Produce a ReviewerReport JSON block
+
+## Output Format
+
+You MUST end your response with a structured ReviewerReport JSON block. You MUST wrap the ReviewerReport in triple-backtick json fences (```json ... ```) for reliable parsing.
+
+```json
+{
+  "version": 1,
+  "archetype": "reviewer",
+  "wrfcId": "<from task context>",
+  "summary": "review summary",
+  "score": 9.5,
+  "passed": true,
+  "dimensions": [
+    {"name": "Correctness", "score": 1.0, "maxScore": 1.0, "issues": []},
+    {"name": "Type Safety", "score": 0.9, "maxScore": 1.0, "issues": ["minor: ..."]},
+    {"name": "Error Handling", "score": 1.0, "maxScore": 1.0, "issues": []},
+    {"name": "Security", "score": 1.0, "maxScore": 1.0, "issues": []},
+    {"name": "Performance", "score": 1.0, "maxScore": 1.0, "issues": []},
+    {"name": "Code Quality", "score": 1.0, "maxScore": 1.0, "issues": []},
+    {"name": "Testing", "score": 1.0, "maxScore": 1.0, "issues": []},
+    {"name": "Documentation", "score": 1.0, "maxScore": 1.0, "issues": []},
+    {"name": "Completeness", "score": 1.0, "maxScore": 1.0, "issues": []},
+    {"name": "Integration", "score": 1.0, "maxScore": 1.0, "issues": []}
+  ],
+  "issues": [
+    {"severity": "minor", "description": "...", "file": "src/foo.ts", "line": 42, "pointValue": 0.1}
+  ]
+}
+```
+
+## Anti-Patterns to Avoid
+
+- Never give a perfect 10.0 unless the code is genuinely flawless
+- Never pass code that has placeholder implementations ("TODO", "not implemented")
+- Never trust file lists in the report without verifying they exist and contain what's claimed
+- If you can't read a file (permission error, doesn't exist), that's an automatic deduction
+
+## What You Will NOT Do
+
+- You do NOT run tests (quality gates handle that separately)
+- You do NOT modify any code
+- You do NOT write implementation code or provide code fixes — only identify issues. Suggestions may propose alternative design approaches but never include code.

package/.goodvibes/skills/add-provider/SKILL.md

@@ -0,0 +1,199 @@
+---
+name: add-provider
+description: Adds custom LLM providers and models to goodvibes-tui. Use when user wants to add a provider, add a model, configure Ollama, Together AI, OpenRouter, Groq, LM Studio, Fireworks, vLLM, or any OpenAI-compatible endpoint.
+version: 1.0.0
+triggers:
+  - /add-provider
+  - add provider
+  - add a provider
+  - new provider
+  - custom provider
+  - add model
+  - add a model
+author: goodvibes
+---
+
+# Add Custom Provider
+
+Interactively collect provider and model details from the user, then write a JSON config to `~/.goodvibes/tui/providers/{name}.json`.
+
+## Workflow
+
+### Step 1: Check for Existing Provider
+
+Before collecting info, check if `~/.goodvibes/tui/providers/` already has JSON files. If the user names a provider that already exists, ask:
+- **Add models** to the existing provider, or
+- **Overwrite** it entirely
+
+If adding models, read the existing JSON, append new models, and write back.
+
+### Step 2: Collect Provider Details
+
+Ask the user for each field. Apply smart defaults when the provider name matches a known service.
+
+#### Required Fields
+
+| Field | Description | Validation |
+|-------|-------------|------------|
+| `name` | Internal ID | Lowercase alphanumeric + hyphens only, 1-64 chars |
+| `displayName` | Human-readable name | Non-empty string |
+| `type` | API compatibility | `openai-compat` (recommended) or `anthropic-compat` (not yet supported — use `openai-compat`) |
+| `baseURL` | API endpoint | Must start with `http://` or `https://` |
+
+> **Note:** `anthropic-compat` is accepted in the JSON schema for forward compatibility but is not yet functional at runtime. The loader will skip configs with this type and emit a warning. Use `openai-compat` for now — most Anthropic-compatible proxies (e.g., via LiteLLM) expose an OpenAI-compatible endpoint.
+
+#### Optional Fields
+
+| Field | Description | Default |
+|-------|-------------|---------|
+| `apiKeyEnv` | Environment variable for API key | None |
+| `apiKey` | Explicit API key (not recommended) | None |
+| `defaultHeaders` | Custom HTTP headers sent with every API request (e.g., for proxy authentication or routing) | None |
+
+### Smart Defaults
+
+When the user mentions a known provider, pre-fill these values and confirm:
+
+```yaml
+ollama:
+  displayName: Ollama
+  type: openai-compat
+  baseURL: http://localhost:11434/v1
+  apiKeyEnv: null
+
+together:
+  displayName: Together AI
+  type: openai-compat
+  baseURL: https://api.together.xyz/v1
+  apiKeyEnv: TOGETHER_API_KEY
+
+openrouter:
+  displayName: OpenRouter
+  type: openai-compat
+  baseURL: https://openrouter.ai/api/v1
+  apiKeyEnv: OPENROUTER_API_KEY
+
+groq:
+  displayName: Groq
+  type: openai-compat
+  baseURL: https://api.groq.com/openai/v1
+  apiKeyEnv: GROQ_API_KEY
+
+lm-studio:
+  displayName: LM Studio
+  type: openai-compat
+  baseURL: http://localhost:1234/v1
+  apiKeyEnv: null
+
+fireworks:
+  displayName: Fireworks AI
+  type: openai-compat
+  baseURL: https://api.fireworks.ai/inference/v1
+  apiKeyEnv: FIREWORKS_API_KEY
+
+vllm:
+  displayName: vLLM
+  type: openai-compat
+  baseURL: http://localhost:8000/v1
+  apiKeyEnv: null
+```
+
+If the name does not match a known provider, ask for all fields individually.
+
+### Step 3: Collect Model Details
+
+Collect at least one model. For each model:
+
+| Field | Description | Validation |
+|-------|-------------|------------|
+| `id` | Model identifier sent to the API | Non-empty string |
+| `displayName` | Human-readable name | Non-empty string |
+| `description` | Short description | Optional, auto-generate if blank |
+| `contextWindow` | Max tokens in context | Positive integer |
+| `capabilities.toolCalling` | Supports function/tool calling | Boolean, default `true` |
+| `capabilities.codeEditing` | Good at code editing tasks | Boolean, default `true` |
+| `capabilities.reasoning` | Extended reasoning/chain-of-thought | Boolean, default `false` |
+| `capabilities.multimodal` | Supports image input | Boolean, default `false` |
+| `reasoningEffort` | Supported reasoning effort levels | Optional, e.g., `["low", "medium", "high"]` |
+
+After each model, ask: "Add another model?" Loop until done.
+
+### Step 4: Preview and Confirm
+
+Show the complete JSON to the user and ask for confirmation before writing.
+
+Example output:
+
+```json
+{
+  "name": "ollama",
+  "displayName": "Ollama",
+  "type": "openai-compat",
+  "baseURL": "http://localhost:11434/v1",
+  "models": [
+    {
+      "id": "llama3.3-70b",
+      "displayName": "Llama 3.3 70B",
+      "description": "Meta's Llama 3.3 70B parameter model",
+      "contextWindow": 131072,
+      "capabilities": {
+        "toolCalling": true,
+        "codeEditing": true,
+        "reasoning": true,
+        "multimodal": false
+      },
+      "reasoningEffort": ["low", "medium", "high"]
+    }
+  ]
+}
+```
+
+### Step 5: Write the File
+
+Write to `~/.goodvibes/tui/providers/{name}.json`. Create the directory if it does not exist.
+
+Use `precision_write` with `mode: "fail_if_exists"` for new providers. Use `mode: "overwrite"` when the user chose to overwrite an existing provider or when merging models into an existing file.
+
+If the `apiKeyEnv` field is set, include it in the JSON. If the user provided an explicit `apiKey`, include it but warn that storing keys in plain text is not recommended -- suggest using an environment variable instead.
+
+If `defaultHeaders` were provided, include them.
+
+### Step 6: Confirm
+
+Tell the user:
+- The file was written to `~/.goodvibes/tui/providers/{name}.json`
+- The provider should be available immediately if goodvibes-tui is currently running (it hot-reloads custom provider configs); if not running, changes take effect on next startup
+- If an API key is needed, remind them to set the environment variable
+
+## Validation Rules
+
+Before writing, verify:
+1. `name` matches `/^[a-z0-9]([a-z0-9-]*[a-z0-9])?$/` and is 1-64 characters (no trailing hyphens)
+2. `baseURL` starts with `http://` or `https://`
+3. `contextWindow` is a positive integer for every model
+4. At least one model is defined
+5. Every model has a non-empty `id` and `displayName`
+
+If validation fails, tell the user which field is invalid and ask for correction.
+
+## JSON Schema Reference
+
+The provider JSON maps to the codebase types:
+
+- Provider registration uses `OpenAICompatProvider` for `openai-compat` type. The `anthropic-compat` type is parsed and accepted in the JSON but is **not yet supported at runtime** — the loader skips it with a warning. Recommend `openai-compat` for all custom providers.
+- `OpenAICompatOptions`: `{ name, baseURL, apiKey, defaultModel, models }`
+- Model entries map to `ModelDefinition`: `{ id, provider, displayName, description, contextWindow, capabilities, reasoningEffort?, selectable }`
+  - `reasoningEffort?: string[]` — optional array of supported effort levels, e.g., `["low", "medium", "high"]`
+- The `selectable` field defaults to `true` for custom models
+- The `provider` field in `ModelDefinition` is auto-set to the provider `name`
+
+## Conversational Style
+
+Be natural and helpful. Guide users step-by-step but do not be overly verbose. If the user provides multiple details at once (e.g., "add ollama with llama3.3-70b"), extract what you can and only ask for missing fields.
+
+## Edge Cases
+
+- **Unknown context window**: Suggest 4096 as a safe default, note the user can update later
+- **No API key needed**: Omit `apiKeyEnv` and `apiKey` from the JSON entirely
+- **User provides a full JSON blob**: Validate it against the schema and write directly
+- **Multiple providers in one session**: After completing one, ask if they want to add another