Feat/shell integrated resolved

.agents/skills/add-shadcn-component/SKILL.md

@@ -0,0 +1,33 @@
+---
+name: add-shadcn-component
+description: Add a new shadcn/ui component using the project's configured style and path aliases
+disable-model-invocation: true
+---
+
+# Add shadcn/ui Component
+
+Add a new shadcn/ui component to the project. Run from the `frontend/` directory:
+
+```bash
+cd frontend && pnpm dlx shadcn@latest add <component-name>
+```
+
+## Project Configuration
+- **Style**: new-york
+- **Base color**: neutral
+- **Icon library**: lucide
+- **CSS variables**: enabled
+- **RSC**: disabled (not a Next.js project)
+- **Components path**: `src/components/ui/`
+- **Utils path**: `src/lib/utils.ts`
+
+## Path Aliases
+- `@/components` → `src/components`
+- `@/components/ui` → `src/components/ui`
+- `@/lib` → `src/lib`
+- `@/hooks` → `src/hooks`
+
+## After Adding
+- Import using the alias: `import { Button } from '@/components/ui/button'`
+- The component will use Tailwind CSS v4 with CSS variables for theming
+- Customize colors via CSS variables in `src/style.css`, not by hardcoding values

.agents/skills/todo-scanner/SKILL.md

@@ -0,0 +1,105 @@
+---
+name: todo-scanner
+description: "Scans the todos/ folder for *.pending.md files and creates implementation plans from their content using the writing-plans workflow. Use this skill whenever the user mentions checking todos, scanning pending tasks, reviewing todo files, processing pending items, or wants to plan work from markdown todo files. Also triggers on phrases like 'what's pending', 'any todos', 'plan my tasks', or 'work on todos'."
+---
+
+# Todo Scanner
+
+Scan the project's `todos/` directory for markdown files with the `*.pending.md` naming convention, create implementation plans for their content, and mark them as resolved after execution is complete.
+
+**Announce at start:** "Using todo-scanner to check for pending tasks in `todos/`."
+
+## Workflow
+
+### Step 1: Scan for pending files
+
+Search `todos/` (relative to project root) for files matching `*.pending.md`. Use glob or ls:
+
+```bash
+ls todos/*.pending.md 2>/dev/null
+```
+
+**If none found:** Tell the user — "No pending todo files found in `todos/`. Create a file like `todos/my-task.pending.md` to get started." Then stop.
+
+**If `*.resolved.md` files also exist:** Mention how many previous todos have been completed, for context.
+
+### Step 2: Present findings and let user choose
+
+List all `*.pending.md` files with a brief preview (first 3-5 lines) of each. Ask the user which file(s) they want to work on.
+
+If only one pending file exists, show its preview and confirm: "This is the only pending task. Want to plan and work on it?"
+
+### Step 3: Read and analyze the selected todo
+
+Read the full content of the selected `*.pending.md` file. The content may be:
+
+- **Freeform:** Plain text, bullet points, rough notes describing the task
+- **Structured:** Sections with title, description, acceptance criteria, etc.
+
+Either format works. Extract the core task requirements regardless of structure. If the content is ambiguous or underspecified, ask the user for clarification before proceeding to planning.
+
+### Step 4: Create implementation plan
+
+Use the **writing-plans** skill to create a detailed implementation plan based on the todo content.
+
+- Treat the todo content as the spec/requirements input
+- Ensure the output directory exists: `mkdir -p docs/superpowers/plans/`
+- Save the plan to `docs/superpowers/plans/YYYY-MM-DD-<todo-name>.md` (derive `<todo-name>` from the pending filename, e.g., `fix-preset-preview.pending.md` → `fix-preset-preview`)
+- Follow writing-plans conventions (bite-sized tasks, frequent commits). If the project has no test infrastructure yet, adapt TDD steps to manual verification or skip test steps — match the project's current state.
+- In the plan header, note the source: `**Source:** todos/<filename>.pending.md`
+
+**Important:** The plan's final task MUST be a "Mark todo resolved" step that renames the source file (see Step 6). This ensures the rename happens as part of normal plan execution flow.
+
+### Step 5: Execute the plan
+
+After the plan is written, offer execution options per the writing-plans handoff:
+
+1. **Subagent-Driven** (recommended) — dispatch a fresh subagent per task, review between tasks
+2. **Inline Execution** — execute tasks in the current session with checkpoints
+
+### Step 6: Mark as resolved
+
+The plan's final task should contain this step. It runs **only after all implementation tasks are complete:**
+
+1. First, prepend the resolution header to the pending file:
+```markdown
+<!-- Resolved: YYYY-MM-DD | Plan: docs/superpowers/plans/YYYY-MM-DD-<name>.md -->
+```
+2. Then rename:
+```bash
+git mv todos/<name>.pending.md todos/<name>.resolved.md
+```
+(Use `git mv` so the rename is tracked. Fall back to plain `mv` if not in a git repo.)
+
+**Do NOT rename before execution is complete.** The rename is the signal that the work described in the todo has been fully implemented.
+
+**If a plan is abandoned:** Leave the file as `*.pending.md`. It can be picked up again in a future session.
+
+**If `<name>.resolved.md` already exists (collision):** Do NOT use `git mv` — it will fail. Instead:
+1. Append the full content of `todos/<name>.pending.md` (including its resolution header) to the existing `todos/<name>.resolved.md`
+2. Detect git repo membership: run `git rev-parse --is-inside-work-tree`
+3. If inside a git repo:
+   - Run `git rm todos/<name>.pending.md` to remove and stage the deletion
+   - Run `git add todos/<name>.resolved.md` to stage the updated resolved file
+4. If not in a git repo:
+   - Run `rm todos/<name>.pending.md`
+
+This avoids leaving the `*.pending.md` file in place and prevents `git mv` from erroring on an existing target.
+
+## File Naming Convention
+
+| State | Pattern | Example |
+|-------|---------|---------|
+| Pending | `todos/<name>.pending.md` | `todos/fix-preset-preview.pending.md` |
+| Resolved | `todos/<name>.resolved.md` | `todos/fix-preset-preview.resolved.md` |
+
+Names should be kebab-case and descriptive of the task.
+
+## Checklist
+
+- [ ] Scan `todos/` for `*.pending.md` files
+- [ ] Present found files to user for selection
+- [ ] Read and understand the selected todo content
+- [ ] Create implementation plan using writing-plans skill
+- [ ] Execute the plan (subagent-driven or inline)
+- [ ] Rename `*.pending.md` → `*.resolved.md` after full completion

.agents/skills/wails-feature/SKILL.md

@@ -0,0 +1,45 @@
+---
+name: wails-feature
+description: Guide for adding new Wails-bound features across Go backend and React frontend, following the project's established data flow pattern
+---
+
+# Wails Feature Workflow
+
+When adding a new feature that spans backend and frontend, follow these steps in order:
+
+## 1. Go Models (`models.go`)
+- Add or update structs for any new data types
+- Use `json:"camelCase"` tags matching the frontend conventions
+
+## 2. Go Backend Logic (`app.go`)
+- Add methods to the `App` struct
+- Methods must be exported (capitalized) to be available as Wails bindings
+- Use `a.store` for persistence and `a.executor` for command execution
+- Follow existing patterns: return `(Type, error)` for creates/updates, `error` for deletes
+
+## 3. Regenerate TypeScript Bindings
+Run:
+```bash
+make generate
+```
+This regenerates `frontend/bindings/cmdex/` with updated TypeScript signatures for all exported service methods.
+
+## 4. TypeScript Types (`frontend/src/types.ts`)
+- Add or update interfaces to mirror the Go structs from step 1
+- Keep field names in camelCase matching the JSON tags
+
+## 5. React Components
+- Import the generated binding: `import { MyMethod } from '../../bindings/cmdex/servicename'`
+- If adding a modal, extend the `ModalState` discriminated union in `App.tsx`
+- Add handler functions in `App.tsx` following existing patterns
+- Create or update components in `frontend/src/components/`
+- Use shadcn/ui components from `@/components/ui/` and Lucide icons
+- Add any user-facing strings as i18n keys in `frontend/src/locales/en.json` and use `t('key')`
+
+## Checklist
+- [ ] Go struct added/updated in `models.go`
+- [ ] App method added in `app.go`
+- [ ] Bindings regenerated (`make generate`)
+- [ ] TypeScript interface updated in `types.ts`
+- [ ] React component created/updated
+- [ ] i18n keys added to `locales/en.json`

.opencode/prompts/executor-guideline.md

@@ -0,0 +1,22 @@
+# Executor Agent Guidelines
+
+**Purpose:** Execute commands or tool calls on behalf of another agent and return only the minimum useful result.
+
+## Operating Rules
+
+- Act as the default place for bash commands, tests, builds, formatters, linters, and validation requested by other agents.
+- Execute only what the caller asked for.
+- Never suggest next steps or fixes. The caller decides what to do.
+- Do not try to fix any failure yourself. Just report it.
+- Prefer command flags that reduce output such as `--quiet`, `--short`, `-q`, or `--format json` when they still answer the request.
+- Run the smallest command or tool call that can answer the question before escalating to broader execution.
+- Batch independent commands or tool calls when possible.
+
+## Response Rules
+
+- Never paste full logs or other raw output unless the caller explicitly asks for it.
+- Keep the response compact and omit repetitive success lines, progress output, and ANSI noise.
+- Always report whether execution succeeded.
+- If execution failed, report the exit code, the key failure reason, and the exact files and lines involved when available.
+- For tests or builds, report only the overall result, pass/fail counts, and the relevant errors with exact file and line references when available.
+- If a raw excerpt is necessary, include only the shortest excerpt that supports the summary.

.opencode/prompts/explore-guideline.md

@@ -0,0 +1,26 @@
+# Exploration Guidelines
+
+**Purpose:** Gather enough evidence to answer accurately while minimizing time, tokens, and unnecessary file access.
+
+## Operating Rules
+
+- Start with the smallest search that can answer the question.
+- Prefer `glob`, `grep`, and targeted `read` calls over broad scans.
+- Batch independent searches and reads when possible.
+- Read only the specific files and sections needed to confirm the answer.
+- Ignore noisy or generated directories such as `node_modules`, `dist`, `build`, `.git`, and cache/output folders unless the user explicitly asks about them.
+- Stop exploring once the answer is supported by concrete evidence.
+
+## Efficiency Rules
+
+- Do not read entire large files unless the answer depends on full-file context.
+- Do not scan unrelated directories just to be thorough.
+- Reuse previously gathered evidence instead of repeating searches.
+- Summarize findings clearly with exact file references.
+
+## Safety Rules
+
+- Respect least privilege at all times.
+- Do not attempt to read secrets, credentials, or sensitive config outside the allowed workspace.
+- Do not edit files, run destructive commands, or use network access unless explicitly required.
+- If the requested scope is unclear, ask for the minimum clarification needed.