opencode-pair-autonomy 1.0.0

package/vendor/skills/go-fiber-postgres/SKILL.md

@@ -0,0 +1,31 @@
+---
+name: go-fiber-postgres
+description: Build and update Go Fiber services with pgx/PostgreSQL, Redis, MinIO, JWT, validation, and dockerized local-dev patterns used across this workspace.
+---
+
+## Purpose
+Use this skill for Go backend work in this workspace when the service follows the common Fiber + PostgreSQL stack.
+
+## Use When
+- The repo uses `gofiber/fiber`, `pgx`, Redis, MinIO, JWT, or `go-playground/validator`.
+- The task touches handlers, middleware, service layers, repositories, config, or docker-compose local services.
+- You need to match the house style used by `play-action-backend`, `project-zur`, `go-micro`, or related services.
+
+## Working Method
+1. Inspect module layout, env loading, and existing route or service registration before changing structure.
+2. Follow the existing separation between transport, business logic, persistence, and middleware.
+3. Reuse existing request validation, auth, error response, and config patterns instead of introducing new abstractions.
+4. Keep SQL and pgx usage explicit, with predictable context handling and defensive error mapping.
+5. Verify local-dev assumptions against Docker, migrations, and service dependencies before finalizing changes.
+
+## Repo Conventions To Prefer
+- Reuse existing env/config loaders and avoid adding new config systems.
+- Keep handler code thin; move non-trivial logic into services or domain packages when the repo already does that.
+- Preserve current auth and claims handling instead of inventing parallel JWT flows.
+- Match existing database access style, transaction helpers, and migration tooling.
+- Keep object storage and Redis integrations behind the current interfaces when present.
+
+## Guardrails
+- Do not replace Fiber or pgx stack choices unless the user explicitly asks.
+- Do not introduce heavy ORMs when the repo already uses SQL or pgx directly.
+- Do not change public API shapes, auth behavior, or migration history without repo evidence or explicit instruction.

package/vendor/skills/opencode-plugin-dev/SKILL.md

@@ -0,0 +1,31 @@
+---
+name: opencode-plugin-dev
+description: Build and refine OpenCode harness, MCP, plugin, prompt, and agent-tooling code while preserving the repo's existing architecture and conventions.
+---
+
+## Purpose
+Use this skill for work in `oh-my-pair-code`, related OpenCode plugins, and MCP or agent-tooling repositories in this workspace.
+
+## Use When
+- The task touches prompts, tool wiring, plugin install flows, MCP servers, vendor wrappers, or agent coordination.
+- The repo uses TypeScript with `@modelcontextprotocol/sdk`, Zod, CLI wiring, plugin manifests, or prompt assembly.
+- You need to preserve harness behavior while extending skill usage, tool exposure, or automation flows.
+
+## Working Method
+1. Inspect existing prompt layers, install flow, and tool contracts before changing behavior.
+2. Reuse current naming, file placement, and config conventions for plugins, MCP wrappers, and prompts.
+3. Keep changes additive and architecture-preserving unless the user explicitly requests a structural shift.
+4. Verify downstream behavior with targeted checks when touching prompt policy, installer logic, or plugin discovery.
+5. Surface user-visible behavior changes clearly, especially when they affect session restart, tool availability, or external installs.
+
+## Repo Conventions To Prefer
+- Keep prompt policy explicit, concrete, and action-oriented.
+- Prefer dedicated tools over shell when the harness already exposes a safer interface.
+- Preserve non-interactive shell assumptions for installs, git, and automation.
+- Keep MCP schemas and validation tight, with descriptive errors and stable tool names.
+- Avoid hidden magic; make automation behavior legible in code and config.
+
+## Guardrails
+- Do not silently broaden permissions, change security posture, or alter external side effects.
+- Do not add new dependencies when current tooling or plugins already solve the problem.
+- Do not make prompt changes that encourage architecture drift or speculative behavior.

package/vendor/skills/rust-media-desktop/SKILL.md

@@ -0,0 +1,30 @@
+---
+name: rust-media-desktop
+description: Build and debug Rust desktop or media apps that use Tokio, Tauri, Slint, async pipelines, and workspace-based crate organization common in this workspace.
+---
+
+## Purpose
+Use this skill for Rust desktop, torrent, playback, or media-pipeline work across the workspace.
+
+## Use When
+- The repo uses Rust workspaces, Tokio, Tauri, Slint, async streaming, or media-processing crates.
+- The task involves desktop UX, async orchestration, file IO, playback state, or cross-crate boundaries.
+- You need to keep consistency with repos like `turp`, `rqbit`, or `ffmpeg-VideoPlayer-Rust_Slint`.
+
+## Working Method
+1. Inspect crate boundaries, feature flags, async runtime assumptions, and UI integration points first.
+2. Preserve existing ownership, error propagation, and tracing patterns.
+3. Keep UI state transitions explicit and resistant to background task races.
+4. Prefer small, composable changes across crates instead of collapsing responsibilities into one module.
+5. Verify platform-specific or media-specific behavior carefully when touching IO, playback, or concurrency.
+
+## Repo Conventions To Prefer
+- Reuse `anyhow`, `thiserror`, `tracing`, and current async primitives when already present.
+- Keep background work cancelable and surface progress or failure states to the UI cleanly.
+- Preserve workspace organization and crate responsibilities.
+- Match existing command, event, and state-management patterns in desktop apps.
+
+## Guardrails
+- Do not replace runtime, UI toolkit, or media pipeline choices without explicit instruction.
+- Do not hide concurrency risks behind broad locks or ad hoc global state.
+- Do not trade correctness for terse code in playback, streaming, or filesystem flows.

package/vendor/skills/vue-vite-ui/SKILL.md

@@ -0,0 +1,31 @@
+---
+name: vue-vite-ui
+description: Implement Vue 3 + Vite interfaces with Pinia, Vue Router, i18n, UnoCSS or Tailwind, and admin-style UX patterns common in this workspace.
+---
+
+## Purpose
+Use this skill for frontend work in the Vue projects across this workspace.
+
+## Use When
+- The repo uses Vue 3, Vite, Pinia, Vue Router, VueUse, Vuelidate, UnoCSS, or Tailwind.
+- The task involves app screens, dashboard flows, forms, navigation, localization, or reusable UI patterns.
+- You need to preserve the established architecture used by `dating-frontend`, `project-zur-panel-front`, or `turp-frontend`.
+
+## Working Method
+1. Inspect route structure, store layout, composables, and styling system before making UI changes.
+2. Extend existing components and utilities before creating one-off patterns.
+3. Preserve form behavior, validation, loading states, and localization hooks already present in the repo.
+4. Keep responsive behavior intentional on desktop and mobile; avoid flattening hierarchy when layouts collapse.
+5. Validate copy length, wrapping, and action-group behavior for multilingual interfaces.
+
+## Repo Conventions To Prefer
+- Reuse existing Pinia stores, route guards, and composables.
+- Match the active utility styling system instead of mixing new CSS approaches.
+- Prefer semantic page sections, strong spacing rhythm, and predictable interaction states.
+- Respect existing icon, notification, modal, and table patterns when available.
+- Keep async UI states explicit: idle, loading, success, error, empty.
+
+## Guardrails
+- Do not introduce a new design system when the repo already has one.
+- Do not bypass localization for new user-facing strings.
+- Do not add heavyweight dependencies for simple UI tasks when the current stack already covers them.

package/vendor/skills/web-agent-browser/SKILL.md

@@ -0,0 +1,140 @@
+---
+name: web-agent-browser
+description: Browser automation with web-agent-mcp. Covers session management, iframe-based auth flows (Apple Developer, Google), 2FA handling, and reliable interaction patterns for complex web applications.
+---
+
+## Purpose
+Use this skill for browser automation tasks using `web-agent-mcp`. Covers the proven patterns for interacting with embedded iframes, auth flows, 2FA prompts, and dynamic SPAs.
+
+## Use When
+- The task involves web-agent-mcp tool usage (`session_create`, `act_fill`, `observe_screenshot`, etc.)
+- The target page uses iframe-based auth (Apple Developer, Google, etc.)
+- The task involves login, form submission, or multi-step auth flows
+- 2FA / verification code input is needed
+
+---
+
+## Session Lifecycle
+
+```
+1. session_create → get session_id
+2. page_navigate (url, wait_until="networkidle")
+3. observe_screenshot → understand page state
+4. interact (act_fill / act_click / runtime_evaluate_js)
+5. session_close when done
+```
+
+Always take a screenshot before interacting. Never guess the page state.
+
+---
+
+## Iframe Handling
+
+### Option A — frame_selector parameter (preferred for same-origin or Playwright-accessible iframes)
+```
+act_fill:
+  selector: "input#account_name_text_field"
+  frame_selector: "iframe#aid-auth-widget-iFrame"
+  value: "user@example.com"
+```
+Works for iframes Playwright can access via `frameLocator()`.
+
+### Option B — JavaScript contentDocument injection (fallback for same-session cross-origin iframes)
+Use when `frame_selector` times out. Apple Developer's login iframe (`idmsa.apple.com`) is accessible via `contentDocument` in the same browser session:
+
+```javascript
+// Fill email in Apple iframe
+const iframe = document.querySelector('iframe#aid-auth-widget-iFrame');
+const emailInput = iframe.contentDocument.querySelector('#account_name_text_field');
+emailInput.focus();
+emailInput.value = 'user@example.com';
+emailInput.dispatchEvent(new Event('input', { bubbles: true }));
+emailInput.dispatchEvent(new Event('change', { bubbles: true }));
+```
+
+```javascript
+// Click Continue / Sign In button
+const iframe = document.querySelector('iframe#aid-auth-widget-iFrame');
+const btn = iframe.contentDocument.querySelector('#sign-in');
+btn.click();
+```
+
+```javascript
+// Wait and check state
+await new Promise(r => setTimeout(r, 3000));
+const iframe = document.querySelector('iframe#aid-auth-widget-iFrame');
+const passwordField = iframe.contentDocument.querySelector('#password_text_field');
+JSON.stringify({
+  passwordVisible: passwordField ? getComputedStyle(passwordField).display !== 'none' : false,
+  bodyText: iframe.contentDocument.body.innerText.substring(0, 500)
+});
+```
+
+---
+
+## Apple Developer Portal Login
+
+**URL:** `https://developer.apple.com/account`
+
+**Login flow:**
+1. `page_navigate` → `https://developer.apple.com/account`
+2. `observe_screenshot` — verify login form visible
+3. Fill email via JavaScript injection (Option B above) into `#account_name_text_field`
+4. Click `#sign-in` (Continue button)
+5. Wait 3s, take screenshot — password field should appear
+6. Fill password via JavaScript into `#password_text_field`
+7. Click `#sign-in` (Sign In button)
+8. Wait 5s, take screenshot — check for 2FA prompt
+
+**Iframe selector:** `iframe#aid-auth-widget-iFrame`
+**Email field:** `#account_name_text_field`
+**Password field:** `#password_text_field`
+**Action button:** `#sign-in` (used for both Continue and Sign In)
+
+### 2FA Handling
+After sign-in, Apple shows phone number selection for SMS code:
+1. `observe_screenshot` to see the 2FA options
+2. Ask the user which phone number to use if multiple options shown
+3. Click the desired phone option
+4. Wait for user to provide the 6-digit code
+5. Use `act_enter_code` or `runtime_evaluate_js` to fill the code fields
+6. Submit
+
+---
+
+## General Patterns
+
+### Detecting page state after navigation
+```javascript
+// Check current URL and key elements
+JSON.stringify({
+  url: window.location.href,
+  title: document.title,
+  hasError: !!document.querySelector('.error, [role="alert"], .alert-error'),
+  errorText: document.querySelector('.error, [role="alert"]')?.textContent?.trim()
+});
+```
+
+### React/Vue input filling (when plain value= doesn't work)
+```javascript
+const input = document.querySelector('input#myField');
+const nativeInputValueSetter = Object.getOwnPropertyDescriptor(HTMLInputElement.prototype, 'value').set;
+nativeInputValueSetter.call(input, 'new value');
+input.dispatchEvent(new Event('input', { bubbles: true }));
+input.dispatchEvent(new Event('change', { bubbles: true }));
+```
+
+### Checking for login success (Google pattern)
+```javascript
+document.querySelector('a[href*="SignOutOptions"], [aria-label*="Google Account"], [data-ogsr-up]')?.getAttribute('aria-label') || 'not logged in';
+```
+
+---
+
+## Guardrails
+- Always `observe_screenshot` before each major action to confirm page state.
+- After clicking Submit/Continue, wait 3-5 seconds before checking result.
+- If `frame_selector` times out, switch to JavaScript `contentDocument` injection.
+- Never store credentials in artifacts or history — use them directly in JS expressions.
+- If 2FA code is needed, always ask the user and wait — do not attempt to bypass.
+- Use `session_close` after completing the task to release the Chrome profile lock.