@walwal-harness/cli 7.1.39 → 7.1.41

package/HR-Resource/cdo/SKILL.md

@@ -27,7 +27,15 @@ Before design work, read `.harness/conventions/shared.md`, `.harness/conventions
 
 ## Worker Activity Telemetry
 
-Before launching any fresh worker session, update `.harness/progress.json` with `scripts/harness-progress-set.sh` so dashboards can show the worker as active. Record the worker name, owning CXX, report path, and `status:"running"` under `company_state.workers`, increment `company_state.active_workers`, and set `conductor.current_action` to `spawn:{worker-name}`. After the worker report is accepted, update that worker to `status:"complete"` and decrement `active_workers`. Do not leave `active_workers:0` while a worker session is running.
+When CEO routes this mission to you, set yourself as the live agent on entry so the dashboard shows the handoff: `bash scripts/harness-progress-set.sh . '.current_agent="cdo" | .agent_status="running"'`.
+
+Before launching any fresh worker session, update `.harness/progress.json` with `scripts/harness-progress-set.sh` so dashboards can show the worker as active. Record the worker name, owning CXX, report path, and `status:"running"` under `company_state.workers`, increment `company_state.active_workers`, and set `conductor.current_action` to `spawn:{worker-name}`. After the worker report is accepted, update that worker to `status:"complete"` and decrement `active_workers`. Do not leave `active_workers:0` while a worker session is running. Require every worker report to open with a `## Status` line whose body is `IN_PROGRESS` while the worker runs and `COMPLETE` once the report is final, so the dashboard shows true worker liveness instead of guessing from file timestamps.
+
+On exit, after writing `cdo.md` and handing back to CEO, run `bash scripts/harness-progress-set.sh . '.agent_status="completed"'` so the loop advances and the dashboard reflects the finished step. Do not clear `conductor.state`; only the CEO's Company Loop Termination step ends the loop.
+
+## Operating Mode — Status Briefing & Agenda
+
+When the active goal is operating (perpetual, `mission-state.json` lifecycle `operating`), CEO periodically orders a 현황 보고. In it, confirm — with worker-backed evidence — whether your hired workers' live deliverables still operate correctly toward the goal (for CDO: is the shipped UI/UX/brand still consistent and usable?). If you discover a regression, drift, incident, opportunity, or risk, do not silently fix it or sit on it: raise it as an agenda item so CEO can adjudicate and route the next cycle: `bash scripts/harness-agenda.sh . <goal-rel> raise cdo <kind> "<title>" "<evidence-path>"` (kinds: loss, drift, incident, opportunity, risk, verification-gap). When CEO routes a decided agenda item to you, execute it through hired workers, get CQO verification where behavior must be proven, and report so CEO can close the item.
 
 ## Rule
 

package/HR-Resource/ceo/SKILL.md

@@ -32,6 +32,37 @@ CEO is authorized to approve routine company operations without Owner confirmati
 
 If an operational choice is reversible and uses existing project-local credentials or configuration, CEO decides, records the rationale in `ceo.md`, and continues. Escalate only for new secrets, new spending, legal/business acceptance, unavailable external production access, destructive data action, or a direct conflict with the Owner's stated direction.
 
+## Company Loop Termination
+
+There are exactly two legitimate ways to end the company loop, and each requires an explicit **runtime transition**. Writing `ceo.md` and `mission-state.json` is not enough: the autonomous Stop loop and the dashboard read `progress.json` runtime state (`conductor.state`, `agent_status`, `current_agent`), not your documents. If you finish a report but never fire the transition, the loop stays `running` and the harness keeps prompting you to continue — this is the "is it done or not?" ambiguity. Avoid it by always ending in one of these two states:
+
+1. **COMPLETE** — the mission is genuinely finished: the final Owner report is in `ceo.md`, all required CXX/worker/OPS evidence is collected, and `mission-state.json` is terminal (`complete`/`closed`/`cancelled`/`superseded`) with `active:false`. As the **literal final action of the turn**, run:
+   `bash scripts/harness-company-complete.sh . <reason>`
+2. **BLOCKED on external authority** — the next action genuinely needs authority the harness cannot infer or obtain (new credentials/secrets, payment approval, legal/business acceptance, unavailable production access, destructive data action, or a direct conflict with the Owner's stated direction). Record the exact missing authority and the internally recommended default in `ceo.md`, set `mission-state.json` lifecycle `blocked` with `active:false`, then run:
+   `bash scripts/harness-company-block.sh . "<exact missing authority>"`
+
+`Truly done = final Owner report + terminal mission-state.json + the matching runtime transition fired.` Until one of these two transitions runs, the mission is still in progress: keep routing CXX and worker work autonomously between turns. Never fire the completion transition while real CXX/worker/verification work remains, and never end a turn in the `running` state with no further action queued.
+
+**Completion applies only to FINITE goals.** A perpetual/operating goal (next section) NEVER completes — `harness-company-complete.sh` must not be run for it.
+
+## Operating (Perpetual) Goals — the never-ending company loop
+
+First, **classify the goal**:
+
+- **Finite** goal — "build X", "add Y", "fix Z": has a definite done state. Use the Company Loop Termination above.
+- **Operating (perpetual)** goal — "run/operate/monitor/keep growing X", "지속/영구 운영", "make money continuously", anything that should *never* stop (e.g. "build a trading bot and keep it profitable forever"): it must run as a standing company that cycles indefinitely.
+
+For an operating goal, set `mission-state.json` to `{"lifecycle":"operating","active":true}` (it stays active forever) and **never** call `harness-company-complete.sh`. The only ways an operating goal ends are: the Owner explicitly orders it stopped (then run `harness-company-complete.sh`), or a true external-authority block (then `harness-company-block.sh`).
+
+Run it as an **agenda-driven standing executive loop**. The agenda is the shared meetup file every CXX co-writes at `.harness/documents/{goal}/agenda.json`, managed with `scripts/harness-agenda.sh`. Each operating tick:
+
+1. **Read the agenda** (`scripts/harness-agenda.sh . {goal} list`).
+2. **If there are active items**, you are *forced* to drive them: for every `open` item, decide and record the decision (`scripts/harness-agenda.sh . {goal} decide <id> "<decision>" <owning-cxx>`), then route that CXX to execute through hired workers and CQO-verify; when an item's work is done and verified, close it (`... close <id>`). Do not end the turn with active agenda.
+3. **If the agenda is empty ("보고사항 없음")**, run a **status-briefing round**: require each relevant CXX (COO/CDO/CTO/CQO/OPS) to file a 현황 보고 — confirm that its workers' *live deliverables* still operate correctly toward the goal — and to raise any newly discovered loss/drift/opportunity/risk as a new agenda item (`scripts/harness-agenda.sh . {goal} raise <cxx> <kind> "<title>" "<evidence>"`). This is how the company discovers its own next work.
+4. **If a full briefing round genuinely surfaces nothing**, record the operating heartbeat (`scripts/harness-company-cycle.sh . {goal}`) and end the turn — the hourly wake loop resumes the next cycle. This keeps the company always-on without burning a turn spinning.
+
+The canonical operating cycle for a self-improving system: `OPS monitor → on loss/drift/opportunity, COO researches + backtests a new strategy → CTO applies it safely → CQO verifies → OPS operates and watches → (repeat)`. Losses are not failures to report to the Owner; they are agenda items that trigger the next research→apply→operate cycle autonomously.
+
 ## Lazy Rule Loading
 
 Before routing or accepting CXX work, enforce lazy loading:
@@ -51,8 +82,8 @@ Before routing or accepting CXX work, enforce lazy loading:
    - CTO: architecture, platform, API, account, web/app/backend/frontend wiring.
    - CQO: quality gates, e2e/backtest strategy, regression and archive criteria.
    - OPS: build/service environment monitoring, CQO verification watch, port map checks, launch observation, production watch, and exception monitoring.
-4. Route completed outputs to the next responsible CXX.
-5. Report outcomes, final acceptance requests, and true external-authority blocks to the Owner.
+4. Route completed outputs to the next responsible CXX. Keep `progress.json` `current_agent` honest as you route so the dashboard shows the live handoff: each CXX sets `current_agent` to its own role on entry; set it back with `bash scripts/harness-progress-set.sh . '.current_agent="ceo" | .agent_status="running"'` whenever you resume between CXX steps and before the final report.
+5. Report outcomes, final acceptance requests, and true external-authority blocks to the Owner, then fire the Company Loop Termination transition (complete or blocked).
 
 ## Hard Rules
 

package/HR-Resource/coo/SKILL.md

@@ -37,7 +37,15 @@ During planning, COO must determine whether the active runtime exposes MCP serve
 
 ## Worker Activity Telemetry
 
-Before launching any fresh worker session, update `.harness/progress.json` with `scripts/harness-progress-set.sh` so dashboards can show the worker as active. Record the worker name, owning CXX, report path, and `status:"running"` under `company_state.workers`, increment `company_state.active_workers`, and set `conductor.current_action` to `spawn:{worker-name}`. After the worker report is accepted, update that worker to `status:"complete"` and decrement `active_workers`. Do not leave `active_workers:0` while a worker session is running.
+When CEO routes this mission to you, set yourself as the live agent on entry so the dashboard shows the handoff: `bash scripts/harness-progress-set.sh . '.current_agent="coo" | .agent_status="running"'`.
+
+Before launching any fresh worker session, update `.harness/progress.json` with `scripts/harness-progress-set.sh` so dashboards can show the worker as active. Record the worker name, owning CXX, report path, and `status:"running"` under `company_state.workers`, increment `company_state.active_workers`, and set `conductor.current_action` to `spawn:{worker-name}`. After the worker report is accepted, update that worker to `status:"complete"` and decrement `active_workers`. Do not leave `active_workers:0` while a worker session is running. Require every worker report to open with a `## Status` line whose body is `IN_PROGRESS` while the worker runs and `COMPLETE` once the report is final, so the dashboard shows true worker liveness instead of guessing from file timestamps.
+
+On exit, after writing `coo.md` and handing back to CEO, run `bash scripts/harness-progress-set.sh . '.agent_status="completed"'` so the loop advances and the dashboard reflects the finished step. Do not clear `conductor.state`; only the CEO's Company Loop Termination step ends the loop.
+
+## Operating Mode — Status Briefing & Agenda
+
+When the active goal is operating (perpetual, `mission-state.json` lifecycle `operating`), CEO periodically orders a 현황 보고. In it, confirm — with worker-backed evidence — whether your hired workers' live deliverables still operate correctly toward the goal (for COO: is the current strategy/plan still valid and performing in research/backtest?). If you discover a loss, drift, regression, incident, opportunity, or risk, do not silently fix it or sit on it: raise it as an agenda item so CEO can adjudicate and route the next cycle: `bash scripts/harness-agenda.sh . <goal-rel> raise coo <kind> "<title>" "<evidence-path>"` (kinds: loss, drift, incident, opportunity, risk, verification-gap). When CEO routes a decided agenda item to you, execute it through hired workers, get CQO verification where behavior must be proven, and report so CEO can close the item.
 
 ## Non-Execution Rule
 

package/HR-Resource/cqo/SKILL.md

@@ -26,7 +26,15 @@ Before quality work, read `.harness/conventions/shared.md`, `.harness/convention
 
 ## Worker Activity Telemetry
 
-Before launching any fresh worker session, update `.harness/progress.json` with `scripts/harness-progress-set.sh` so dashboards can show the worker as active. Record the worker name, owning CXX, report path, and `status:"running"` under `company_state.workers`, increment `company_state.active_workers`, and set `conductor.current_action` to `spawn:{worker-name}`. After the worker report is accepted, update that worker to `status:"complete"` and decrement `active_workers`. Do not leave `active_workers:0` while a worker session is running.
+When CEO routes this mission to you, set yourself as the live agent on entry so the dashboard shows the handoff: `bash scripts/harness-progress-set.sh . '.current_agent="cqo" | .agent_status="running"'`.
+
+Before launching any fresh worker session, update `.harness/progress.json` with `scripts/harness-progress-set.sh` so dashboards can show the worker as active. Record the worker name, owning CXX, report path, and `status:"running"` under `company_state.workers`, increment `company_state.active_workers`, and set `conductor.current_action` to `spawn:{worker-name}`. After the worker report is accepted, update that worker to `status:"complete"` and decrement `active_workers`. Do not leave `active_workers:0` while a worker session is running. Require every worker report to open with a `## Status` line whose body is `IN_PROGRESS` while the worker runs and `COMPLETE` once the report is final, so the dashboard shows true worker liveness instead of guessing from file timestamps.
+
+On exit, after writing `cqo.md` and handing back to CEO, run `bash scripts/harness-progress-set.sh . '.agent_status="completed"'` so the loop advances and the dashboard reflects the finished step. Do not clear `conductor.state`; only the CEO's Company Loop Termination step ends the loop.
+
+## Operating Mode — Status Briefing & Agenda
+
+When the active goal is operating (perpetual, `mission-state.json` lifecycle `operating`), CEO periodically orders a 현황 보고. In it, confirm — with evaluator-worker evidence — whether the live system still passes the quality/regression bar toward the goal (for CQO: are regression/e2e/perf/security gates still green on the running system?). If you discover a regression, quality drift, incident, or verification gap, do not silently sit on it: raise it as an agenda item so CEO can adjudicate and route the next cycle: `bash scripts/harness-agenda.sh . <goal-rel> raise cqo <kind> "<title>" "<evidence-path>"` (kinds: loss, drift, incident, opportunity, risk, verification-gap). When CEO routes a decided agenda item to you, run the evaluator/tester workers, issue a verdict, and report so CEO can close the item.
 
 ## Hard Rules
 

package/HR-Resource/cto/SKILL.md

@@ -28,13 +28,21 @@ Before engineering work, read `.harness/conventions/shared.md`, `.harness/conven
 
 ## Worker Activity Telemetry
 
-Before launching any fresh worker session, update `.harness/progress.json` with `scripts/harness-progress-set.sh` so dashboards can show the worker as active. Record the worker name, owning CXX, report path, and `status:"running"` under `company_state.workers`, increment `company_state.active_workers`, and set `conductor.current_action` to `spawn:{worker-name}`. After the worker report is accepted, update that worker to `status:"complete"` and decrement `active_workers`. Do not leave `active_workers:0` while a worker session is running.
+When CEO routes this mission to you, set yourself as the live agent on entry so the dashboard shows the handoff: `bash scripts/harness-progress-set.sh . '.current_agent="cto" | .agent_status="running"'`.
+
+Before launching any fresh worker session, update `.harness/progress.json` with `scripts/harness-progress-set.sh` so dashboards can show the worker as active. Record the worker name, owning CXX, report path, and `status:"running"` under `company_state.workers`, increment `company_state.active_workers`, and set `conductor.current_action` to `spawn:{worker-name}`. After the worker report is accepted, update that worker to `status:"complete"` and decrement `active_workers`. Do not leave `active_workers:0` while a worker session is running. Require every worker report to open with a `## Status` line whose body is `IN_PROGRESS` while the worker runs and `COMPLETE` once the report is final, so the dashboard shows true worker liveness instead of guessing from file timestamps.
+
+On exit, after writing `cto.md` and handing back to CEO, run `bash scripts/harness-progress-set.sh . '.agent_status="completed"'` so the loop advances and the dashboard reflects the finished step. Do not clear `conductor.state`; only the CEO's Company Loop Termination step ends the loop.
+
+## Operating Mode — Status Briefing & Agenda
+
+When the active goal is operating (perpetual, `mission-state.json` lifecycle `operating`), CEO periodically orders a 현황 보고. In it, confirm — with worker-backed evidence — whether your hired workers' live deliverables still operate correctly toward the goal (for CTO: is the running system stable — errors, latency, uptime, resource limits?). If you discover a failure, drift, incident, opportunity, or risk, do not silently fix it or sit on it: raise it as an agenda item so CEO can adjudicate and route the next cycle: `bash scripts/harness-agenda.sh . <goal-rel> raise cto <kind> "<title>" "<evidence-path>"` (kinds: loss, drift, incident, opportunity, risk, verification-gap). When CEO routes a decided agenda item to you, implement it through hired workers, get CQO verification, and report so CEO can close the item.
 
 ## Browser Automation Briefing
 
 Every CTO worker brief that may use Playwright, browser automation, browser-based inspection, E2E, or visual verification must explicitly include this requirement:
 
-> Run Playwright/browser automation with a visible browser. Set `headless: false` in launch/config code, use headed test mode (`--headed`, `PWDEBUG=1`, or equivalent), prefer `channel: 'chrome'` when available, and do not use headless mode unless the Owner has explicitly approved an exception in this mission.
+> Run Playwright/browser automation with a visible browser. Set `headless: false` in launch/config code, use headed test mode (`--headed`, `PWDEBUG=1`, or equivalent), prefer `channel: 'chrome'` when available, and do not use headless mode unless the Owner has explicitly approved an exception in this mission. Pace it middle-fast: `slowMo: 120` (ms) — observable but brisk. Do not use `slowMo: 300`+ (too slow); raise it only if the Owner explicitly asks to slow the demo down.
 
 CTO must not accept worker plans or reports that omit this requirement when browser automation is in scope.
 

package/HR-Resource/ops/SKILL.md

@@ -50,6 +50,16 @@ OPS must actively watch the runtime while CQO evaluator workers test the product
 - CQO cannot issue PASS for a runnable product while OPS reports an open INCIDENT, missing runtime mapping, missing logs required by the mission, or an unmonitored service that is part of the tested scenario.
 - OPS does not wait for the Owner to notice defects. Owner acceptance starts only after CQO evidence and OPS runtime evidence are both clean, or after CEO explicitly reports remaining operational risk.
 
+## Dev-Mode Prompt Inspector
+
+When OPS builds or runs a React/Next.js or static HTML UI in development mode, and screen-level discussion would benefit from selecting visible UI elements and mapping intended REST/API behavior, OPS must use the installed `harness-ops-prompt-inspector` skill.
+
+- Use Prompt Inspector only for development builds or verification environments. Do not inject it into production builds or production service environments.
+- Install it from the project-local skill path under `.claude/skills/harness-ops-prompt-inspector/` or `.codex/skills/harness-ops-prompt-inspector/`; do not download it at mission runtime.
+- Run its installer against the target app path before or during the dev-mode run so the toolbar is available in the browser for UI/API binding notes.
+- Record the install result, target app path, dev server URL, and generated API discovery evidence in OPS environment evidence.
+- If the project is not React/Next.js, static HTML, or the build is not development mode, report Prompt Inspector as not applicable instead of forcing installation.
+
 ## Post-Launch Watch
 
 After service launch, OPS continues the same monitoring duty against `runtime.production.services[]`.
@@ -82,13 +92,21 @@ After service launch, OPS continues the same monitoring duty against `runtime.pr
 
 ## Worker Activity Telemetry
 
-Before launching any fresh worker session, update `.harness/progress.json` with `scripts/harness-progress-set.sh` so dashboards can show the worker as active. Record the worker name, owning CXX, report path, and `status:"running"` under `company_state.workers`, increment `company_state.active_workers`, and set `conductor.current_action` to `spawn:{worker-name}`. After the worker report is accepted, update that worker to `status:"complete"` and decrement `active_workers`. Do not leave `active_workers:0` while a worker session is running.
+When CEO routes this mission to you, set yourself as the live agent on entry so the dashboard shows the handoff: `bash scripts/harness-progress-set.sh . '.current_agent="ops" | .agent_status="running"'`.
+
+Before launching any fresh worker session, update `.harness/progress.json` with `scripts/harness-progress-set.sh` so dashboards can show the worker as active. Record the worker name, owning CXX, report path, and `status:"running"` under `company_state.workers`, increment `company_state.active_workers`, and set `conductor.current_action` to `spawn:{worker-name}`. After the worker report is accepted, update that worker to `status:"complete"` and decrement `active_workers`. Do not leave `active_workers:0` while a worker session is running. Require every worker report to open with a `## Status` line whose body is `IN_PROGRESS` while the worker runs and `COMPLETE` once the report is final, so the dashboard shows true worker liveness instead of guessing from file timestamps.
+
+On exit, after writing `ops.md` and handing back to CEO, run `bash scripts/harness-progress-set.sh . '.agent_status="completed"'` so the loop advances and the dashboard reflects the finished step. Do not clear `conductor.state`; only the CEO's Company Loop Termination step ends the loop.
+
+## Operating Mode — Status Briefing & Agenda
+
+When the active goal is operating (perpetual, `mission-state.json` lifecycle `operating`), OPS is the primary monitor of the never-ending loop. On every CEO 현황 보고, report — with monitoring evidence (logs, health, ports, metrics, P&L or domain KPIs) — whether the live system still operates correctly toward the goal. Any loss, drawdown, drift, incident, degraded health, or opportunity MUST become an agenda item so CEO can adjudicate and route the next research→apply→operate cycle: `bash scripts/harness-agenda.sh . <goal-rel> raise ops <kind> "<title>" "<evidence-path>"` (kinds: loss, drift, incident, opportunity, risk, verification-gap). OPS does not fix systems itself — it surfaces the agenda and supplies evidence; CTO owns the fix, COO owns new-strategy research, CQO owns verification. A clean monitoring round with nothing to raise is itself a valid briefing result.
 
 ## Browser Automation Briefing
 
 Every OPS worker brief that may use Playwright, browser automation, browser-based monitoring, E2E, or visual/runtime verification must explicitly include this requirement:
 
-> Run Playwright/browser automation with a visible browser. Set `headless: false` in launch/config code, use headed test mode (`--headed`, `PWDEBUG=1`, or equivalent), prefer `channel: 'chrome'` when available, and do not use headless mode unless the Owner has explicitly approved an exception in this mission.
+> Run Playwright/browser automation with a visible browser. Set `headless: false` in launch/config code, use headed test mode (`--headed`, `PWDEBUG=1`, or equivalent), prefer `channel: 'chrome'` when available, and do not use headless mode unless the Owner has explicitly approved an exception in this mission. Pace it middle-fast: `slowMo: 120` (ms) — observable but brisk. Do not use `slowMo: 300`+ (too slow); raise it only if the Owner explicitly asks to slow the demo down.
 
 OPS must not accept worker plans or reports that omit this requirement when browser automation is in scope.
 

package/HR-Resource/ops-prompt-inspector/SKILL.md

@@ -0,0 +1,105 @@
+---
+name: harness-ops-prompt-inspector
+description: "OPS-only dev-mode visual API binding for React/Next.js or static HTML UI elements and REST endpoints."
+permissionMode: bypassPermissions
+---
+
+# OPS Prompt Inspector
+
+OPS-only visual tool for binding UI elements to REST APIs in React/Next.js or static HTML projects during development builds.
+
+Use this skill only when OPS is responsible for a dev-mode build/run or verification environment where screen-level communication would be improved by an on-page inspector. Do not install it into production builds.
+
+## Quick Setup
+
+**Recommended: Use the installation agent for seamless setup:**
+
+```
+Task(
+  subagent_type="harness-ops-prompt-inspector:installer",
+  prompt="Install PromptInspector to <project_path>",
+  permissionMode="bypassPermissions"
+)
+```
+
+**Or run manually:**
+
+```bash
+bash scripts/install.sh <project_path>
+```
+
+This automatically:
+1. Detects project type (Next.js App/Pages Router or static `index.html`)
+2. Copies component to `components/PromptInspector.tsx`, or static script to `public/prompt-inspector-static.js`
+3. Injects into root layout or `index.html` (dev mode only)
+4. Discovers all APIs in the project
+
+## Workflow
+
+```
+1. Setup     → Run setup.py (auto-injects component)
+2. Discover  → Run discover_apis.py (find all APIs)
+3. Bind      → Select elements, configure API connections
+4. Export    → Copy markdown spec for implementation
+```
+
+## Step 1: Discover APIs
+
+```bash
+python3 scripts/discover_apis.py <project_path>
+```
+
+Finds:
+- Backend: Express, FastAPI, NestJS, Next.js API routes
+- Frontend: axios, fetch, ky, SWR, React Query
+
+## Step 2: Visual Binding
+
+After setup, toolbar appears at bottom-right in dev mode:
+
+1. **Select Element** → Click any UI element
+2. **Choose Action** → Comment Only / Connect API
+3. **Configure** (for API):
+   - Select API from discovered list
+   - Trigger: Mount, PageLoad, Click, Submit, Blur, Change
+   - OnSuccess: toast/popup/redirect + message
+   - OnError: Multiple cases with optional error codes
+4. **Export** → Copies markdown specification
+
+## Output Format
+
+```markdown
+# Route: /users
+
+## 1. POST /api/users
+- Selector: `button.submit-btn`
+- Trigger: onClick
+- OnSuccess: toast ("User created")
+- OnError #1: [ERR_DUPLICATE] toast ("Already exists")
+- OnError #2: toast ("Unknown error")
+
+## 2. Comment
+- Selector: `#header`
+- Comment: Needs redesign
+```
+
+## Manual Setup (if auto fails)
+
+1. For React/Next.js, copy `assets/PromptInspector.tsx` to project's `components/`
+
+2. Add to root layout:
+```tsx
+import { PromptInspector } from '@/components/PromptInspector';
+
+// Inside layout, before </body>:
+{process.env.NODE_ENV === 'development' && <PromptInspector />}
+```
+
+3. For static HTML, copy `assets/prompt-inspector-static.js` to `public/` and add before `</body>`:
+```html
+<script src="/public/prompt-inspector-static.js" data-harness-ops-prompt-inspector></script>
+```
+
+## Handler Templates
+
+See [references/handler-templates.md](references/handler-templates.md) for code generation patterns.

package/HR-Resource/ops-prompt-inspector/agents/installation-agent.json

@@ -0,0 +1,7 @@
+{
+  "name": "prompt-inspector-installer",
+  "description": "Installs PromptInspector component with auto-update check. Handles file copying and layout injection without requiring individual permission prompts.",
+  "permissionMode": "bypassPermissions",
+  "tools": ["Read", "Write", "Edit", "Bash", "Glob"],
+  "prompt": "You are the Prompt Inspector installation agent. Your job is to:\n\n1. Run the setup script: `python3 scripts/setup.py <project_path> --force`\n2. Run the API discovery: `python3 scripts/discover_apis.py <project_path>`\n3. Report installation results to the user\n\nExecute these steps without asking for additional permissions."
+}