[{"_1":2,"_3":-5,"_4":-5},"loaderData",{"_5":6,"_7":8,"_9":10},"actionData","errors","root",{"_215":216,"_217":218},"routes/_app.x.$handle.$name",{"_95":94,"_31":43,"_104":85,"_26":105,"_13":14,"_106":-5,"_11":107,"_108":109,"_110":111,"_112":113,"_114":115,"_20":-5,"_116":-5,"_117":-5,"_118":24,"_119":120,"_121":57,"_122":-5,"_123":-5,"_124":125},"routes/_app.x.$handle.$name.branch.$branch.version.$version.diff",{"_11":12,"_13":14,"_15":16,"_17":-5,"_18":-5},"project",{"_41":42,"_31":43,"_36":44,"_45":-5,"_46":24,"_47":48,"_49":48,"_50":51,"_52":-5,"_18":53,"_54":55,"_56":57,"_58":-5,"_59":-5,"_60":61,"_62":63,"_64":-5,"_65":-5,"_66":-5,"_67":-5,"_68":69,"_70":69,"_71":72,"_73":72,"_74":72,"_75":69,"_76":69,"_77":78,"_79":80,"_81":82,"_83":24},"version",8,"changes",[19],"aiChatInfo","userId",{"_20":21,"_22":-7,"_23":24,"_25":24,"_26":27,"_28":27},"file",{"_29":30,"_31":32,"_33":20,"_34":35,"_36":37,"_38":14,"_39":40,"_23":24},"previous","deleted",false,"deletedHere","path","skills/triage/SKILL.md","latestPath","fileId","3e18abc8-9dc2-11f1-8943-1607ee4eb77e","name","SKILL.md","fileType","content","---\nname: triage\ndescription: Triage bugs, regressions, flaky behavior, and broken workflows with independent, reproduce-first evidence. Use when asked to triage, debug, diagnose, investigate a failure, reproduce a bug, or identify likely ownership and next steps.\n---\n\n# Triage\n\nUse this skill for evidence-backed triage and disciplined diagnosis: reproduce the failure, minimize the loop, form hypotheses, instrument only what distinguishes them, identify likely ownership and next steps, fix, and regression-test. Quire is the independent evidence collector for this workflow when a fresh reproduction, browser/API/mobile check, or external verification handoff would materially improve confidence.\n\n## When to use Quire during triage\n\nUse the native Quire adapter when you need an independent read-only investigator. Depending on the harness, the adapter is a subagent or a tool named `quire` that launches the same Quire CLI run:\n\n- reproduce a reported bug or flaky workflow;\n- verify a suspected fix against the real app, browser, API, CLI, or mobile surface;\n- gather evidence such as screenshots, recordings, console output, terminal logs, or a concise handoff;\n- check whether a failure is environment/setup-blocked versus a product bug;\n- produce a run id and terminal verdict that another agent can use in an implementation/verification loop.\n\nDo not outsource implementation to Quire. Quire should not edit code. The parent triage agent owns hypotheses, code changes, and regression tests.\n\n## Recommended invocation\n\n1. Build or identify the best reproduction loop you can from the report.\n2. If this harness exposes a native subagent named `quire`, delegate a concise reproduction or verification brief to that subagent and wait for its handoff. If it exposes a native tool named `quire`, invoke that tool with the brief and optional caller-owned URL; the tool starts one run and returns its terminal handoff. The native adapter is mandatory when available.\n3. If no native `quire` adapter is available, use the Quire CLI fallback from https://skills.quire.sh/verify.\n4. Use Quire's result as evidence, not as a substitute for understanding the code path. When communicating the result, surface the synced Quire run link from `webUrl`, `caseUrl`, or `sync.caseUrl` when present, and mention useful report artifacts such as screenshots, recordings, traces, or the handoff markdown when they help the user review the diagnosis. If Quire reports blocked, preserve that honestly and fix the setup or ask for the missing environment.\n\n## Triage brief template\n\n- Failure or regression to reproduce:\n- User-visible symptom:\n- Target URL, command, app, or environment:\n- Steps already tried:\n- Expected behavior:\n- Actual behavior:\n- Evidence to capture:\n- Constraints: read-only investigation; do not edit code.\n\n## CLI fallback\n\nUse CLI fallback only if the native `quire` adapter is unavailable. Prefer detached JSON mode and wait for the terminal handoff:\n\n```bash\nrun_json=$(quire run --detach --json --url \"\" \"\")\nrun_id=$(printf '%s' \"$run_json\" | jq -r '.runId')\nquire wait \"$run_id\" --json\n```\n\nIf the caller provides an existing Quire run id, do not start a new run and do not use `quire status` as the final result:\n\n```bash\nquire wait \"\" --json\n```\n\nFor more CLI details, sandbox recovery, and handoff interpretation, follow https://skills.quire.sh/verify.\n","createdAt",["D",1787359301613],"branchVersion","branchId","58d59cf8-ab3f-4c4c-9d93-4fdae0fde96d","id","4c9a59ba-656d-4c73-856b-e45a9ba4af84","quire-agent-skills",["D",1787359107320],"deletedAt","legacyEnvVars","privacy","public","httpPrivacy","description","Public Quire agent skills","imageUrl","3ee322c5-8742-48e0-86c7-5f3ae129683b","pinnedFileId","ca5158ac-9dc1-11f1-9adb-1607ee4eb77e","pinPreview",true,"pinMigrated","screenshotVersion","likeCount",0,"orgId","f427167a-3263-4778-81d8-f79626323ff5","tursoName","tursoHostname","tursoMeasuredAt","pinned","userPerm","r","valPerm","blobPerm","rw","emailPerm","sqlitePerm","projectPerm","telemetryPerm","user",{"_95":94,"_103":99},"org",{"_95":94,"_96":97,"_98":99,"_18":53,"_100":101,"_102":24},"branch",{"_13":84,"_31":85,"_41":40,"_86":42,"_87":-5,"_88":-5,"_89":-5,"_90":-5,"_91":-5,"_92":43,"_93":94},"isOwned",39,"main","projectId","forkedBranchId","forkedBranchVersion","forkedProjectPrivacy","forkedProjectId","forkedProjectOrgId","projectName","userHandle","kamalnrf","handle","displayName","Kamal","avatar","https://img.clerk.com/eyJ0eXBlIjoicHJveHkiLCJzcmMiOiJodHRwczovL2ltYWdlcy5jbGVyay5kZXYvb2F1dGhfZ2l0aHViL2ltZ18yaVpXT3l1d2hWSFdtWTNoZFIwZ0lFUUhOd2oifQ","tier","pro","canRestrictVals","profileImageUrl","branchName","","adoptOrgId",{"_41":42,"_31":43,"_36":211,"_45":-5,"_46":24,"_47":48,"_49":48,"_50":51,"_52":-5,"_18":53,"_54":55,"_56":57,"_58":-5,"_59":-5,"_60":61,"_62":63,"_64":-5,"_65":-5,"_66":-5,"_67":-5,"_68":69,"_70":69,"_71":72,"_73":72,"_74":72,"_75":69,"_76":69,"_77":212,"_79":213,"_81":214,"_83":24},"tree",[157,164],"files",[157,158,159,160,161,162,163,164],"counts",{"_147":61,"_148":132,"_149":61,"_150":151,"_152":153},"contents",[127,128],"upstreamProject","upstreamBranch","emptyEnvVars","flags",[],"hasHttpFiles","grants","orgs","customDomains",{"_55":126},"skills.quire.sh",{"_41":140,"_31":141,"_29":142,"_131":-5,"_39":40,"_38":143,"_133":57,"_36":144,"_13":61,"_33":145,"_34":-5,"_23":24,"_137":-5,"_26":146},{"_41":129,"_31":130,"_29":55,"_131":-5,"_39":40,"_38":132,"_133":24,"_36":134,"_13":61,"_33":135,"_34":136,"_23":24,"_137":138,"_26":139},"a73eb751-0a9e-4fdd-834c-3f425ceaabe7","main.ts","parentId",1,"latest",["D",1787359107368],"http","export default function () {\n return new Response(\"Quire agent skills are being configured.\", { status: 503 });\n}\n","label","quire-skills",[130],"65f43ebe-a35f-475a-b973-62a0afedb13e","skills","1c8937d4-9dc2-11f1-bcad-1607ee4eb77e",2,["D",1787359245306],"directory",[141],"pulls","branches","forks","envVars",{"_154":61,"_156":61},"connections",{"_154":61,"_155":61},"count","unfilledCount","emptyCount",{"_41":140,"_31":141,"_29":142,"_131":-5,"_39":40,"_38":143,"_133":57,"_36":208,"_13":61,"_33":145,"_34":-5,"_23":24,"_137":-5,"_166":209,"_26":210},{"_41":203,"_31":202,"_29":196,"_131":142,"_39":40,"_38":204,"_133":57,"_36":205,"_13":61,"_33":145,"_34":-5,"_23":24,"_137":-5,"_166":206,"_26":207},{"_41":194,"_31":32,"_29":195,"_131":196,"_39":40,"_38":197,"_133":24,"_36":198,"_13":61,"_33":20,"_34":199,"_23":24,"_137":-5,"_166":200,"_26":201},{"_41":189,"_31":188,"_29":184,"_131":142,"_39":40,"_38":190,"_133":57,"_36":191,"_13":61,"_33":145,"_34":-5,"_23":24,"_137":-5,"_166":192,"_26":193},{"_41":183,"_31":32,"_29":30,"_131":184,"_39":40,"_38":14,"_133":24,"_36":185,"_13":61,"_33":20,"_34":35,"_23":24,"_137":-5,"_166":186,"_26":187},{"_41":178,"_31":177,"_29":171,"_131":142,"_39":40,"_38":179,"_133":57,"_36":180,"_13":61,"_33":145,"_34":-5,"_23":24,"_137":-5,"_166":181,"_26":182},{"_41":169,"_31":32,"_29":170,"_131":171,"_39":40,"_38":172,"_133":24,"_36":173,"_13":61,"_33":20,"_34":174,"_23":24,"_137":-5,"_166":175,"_26":176},{"_41":129,"_31":130,"_29":55,"_131":-5,"_39":40,"_38":132,"_133":24,"_36":165,"_13":61,"_33":135,"_34":136,"_23":24,"_137":138,"_166":167,"_26":168},["D",1787359107368],"children",[],[130],"9e17cb27-0d86-4cc4-add7-9c4ba973dd1f","3dde79a8-9dc2-11f1-a22f-1607ee4eb77e","1d08e0c4-9dc2-11f1-9ffa-1607ee4eb77e",7,["D",1787359301233],"---\nname: verify\ndescription: Verify claims, code changes, bug fixes, workflows, and release readiness with independent evidence. Use when asked to verify, QA, smoke test, prove a fix, reproduce a product issue, or check non-trivial work before completion.\n---\n\n# Verify\n\nUse this skill to prove whether a claim, code change, bug fix, test result, workflow, product issue, or release/readiness assertion is actually correct. Quire is the independent read-only QA, verification, and triage agent for this workflow. Quire does not implement fixes. Quire reports pass, fail, blocked, or partial results honestly with evidence.\n\n## Recommended path\n\nIf your harness exposes a native subagent named `quire`, delegate the verification or reproduction brief to that subagent and wait for its terminal handoff. This is mandatory when available. The skill's job is to recognize that independent evidence is needed; the `quire` subagent's job is to run the Quire CLI, wait patiently, and return the evidence-backed handoff.\n\nUse CLI fallback only when no native `quire` subagent is available. Do not run the Quire CLI directly from the parent session when a native `quire` subagent is available.\n\nIf the caller asks whether the Quire agent/subagent path was used, answer from your actual invocation path. If you used a native `quire` child task/subagent, report that the native Quire subagent path was used even when `quire wait` returns metadata for an older run whose internal harness was `pi`, Codex, or another agent. Treat old run metadata as separate historical context, not as evidence that the current adapter path was not used.\n\nWhen communicating Quire results to the user, produce a compact verification report like a QA test run summary: verdict, checks run, pass/fail/blocked counts when available, known non-regressions, synced Quire run link from `webUrl`, `caseUrl`, or `sync.caseUrl`, report/handoff markdown path or excerpt, and useful artifacts such as screenshots, recordings, traces, console/network output, or other evidence.\n\n## When to use this skill\n\nUse this skill when the user asks to verify, QA, smoke test, validate, prove a fix, check a workflow, reproduce a visible product issue, ask Quire, run Quire, or get a Quire run id/verdict/handoff.\n\nAlso use Quire before declaring non-trivial coding work complete when independent verification would materially increase confidence, especially for UI/workflow changes, bug fixes, failing or flaky tests, auth, security, permissions, billing, data loss, migrations, concurrency, integrations, mobile behavior, or release-readiness work.\n\nDo not use Quire for every tiny task. Usually skip independent verification for purely conversational answers, simple docs/formatting edits, trivial mechanical changes where local checks are enough, or repeated verification of the same unchanged diff. Exception: if the user explicitly asks for Quire or independent verification, use Quire anyway.\n\n## Hard requirement\n\nIf the caller explicitly asks for Quire or independent verification, do not substitute your own direct checks, web fetches, curl commands, tests, browser checks, or manual reasoning and claim that is equivalent. You may do basic preparation, but Quire itself must be invoked.\n\nWhen Quire owns reproduction or verification, avoid duplicating the same checks yourself while it is running. Do not run parallel curl/browser/source-tracing/build checks for the same claim just because Quire is still active. Wait for the handoff, then use your own commands only to implement the fix, handle a Quire-blocked gap, or do a final narrow packaging check the project requires.\n\n## Verification brief template\n\n- Claim/change/bug to verify:\n- Target URL, command, app, route, screen, or environment:\n- Relevant files/paths or PR context:\n- Commands already run:\n- Expected behavior:\n- Known risks or edge cases:\n- Evidence to capture: screenshots, browser console, network, CLI output, mobile state, logs, deterministic checks, or handoff summary.\n- Constraints: read-only verification; do not edit code; production mutation safety.\n\n## CLI fallback\n\nUse CLI fallback only when the native `quire` subagent is unavailable.\n\nFor a new verification or reproduction run, prefer detached JSON mode and wait for the terminal handoff:\n\n```bash\nrun_json=$(quire run --detach --json --url \"\" \"\")\nrun_id=$(printf '%s' \"$run_json\" | jq -r '.runId')\nquire wait \"$run_id\" --json\n```\n\nIf there is no URL, omit `--url` and include target context in the natural-language request.\n\nIf the caller provides an existing Quire run id, do not start a new run and do not use `quire status` as the final result. Wait for and return the handoff with:\n\n```bash\nquire wait \"\" --json\n```\n\nUse `finalHandoff.handoffMarkdown` from `quire wait --json` as the evidence-backed result when present.\n\nThe JSON output includes `webUrl` / `caseUrl` when the run has synced to Quire's web app. Use that link as the shareable evidence URL in user-facing summaries.\n\nTerminal statuses are `completed`, `failed`, `canceled`, and `stale`. Wait patiently: Quire is another agent doing real QA work and can take several minutes. Do not start a duplicate run for the same claim just because the first run is still active.\n\nIf Quire reports `EROFS`, `EACCES`, or another write error under `~/.local/share/quire/runs`, your agent sandbox likely made the default run store read-only. Retry with a temporary run store and reuse the same value for every lifecycle command:\n\n```bash\nquire_runs_dir=$(mktemp -d -t quire-runs-XXXXXX)\nQUIRE_RUNS_DIR=$quire_runs_dir quire run --detach --json --url \"\" \"\"\nQUIRE_RUNS_DIR=$quire_runs_dir quire wait \"\" --json\n```\n\n## Bug-fix loop\n\nFor user-reported bugs on real product surfaces, the ideal loop is:\n\n1. Use Quire to reproduce the symptom and identify the failing surface, request, console/runtime error, command, or workflow boundary.\n2. Wait for Quire's reproduction handoff before doing your own code tracing unless the user explicitly asks you to investigate in parallel or the run is blocked.\n3. Make the smallest code/config/content fix informed by that evidence.\n4. Use Quire again against the fixed local/preview target to verify the original symptom is gone. Treat unrelated warnings or secondary issues as follow-up notes unless they caused the reported bug or block verification.\n\n## Return format\n\n- Native Quire adapter invocation: yes/no/unavailable, with evidence.\n- Verdict: pass, fail, blocked, partial, or setup-blocked.\n- Quire run id.\n- Quire web URL when present.\n- What Quire verified or reproduced, including checks run and pass/fail/blocked counts when available.\n- Key evidence, artifacts, report, screenshots, recordings, traces, or handoff excerpt.\n- Known non-regressions or pre-existing issues, when relevant.\n- Follow-up actions for the implementation agent.\n",[],[141,177,32],"verify","e4a27cb5-bbbc-443a-8f47-2933e524f2a6",4,["D",1787359246143],[163],[141,177],"fa44158f-c5a9-4af7-8999-e88f1305b3cc","1d4296e8-9dc2-11f1-9ffa-1607ee4eb77e",["D",1787359301613],[],[141,188,32],"triage","d8ba9059-b575-4994-9e16-dd28db3ff50d",5,["D",1787359246523],[161],[141,188],"d18c141b-79f4-44e3-bc0d-a6f1d6838f41","24e00084-9dc2-11f1-bc54-1607ee4eb77e","1cd182d2-9dc2-11f1-b21c-1607ee4eb77e",6,["D",1787359259300],"---\nname: quire-setup\ndescription: Set up the current machine and repository so Quire can run focused triage, verification, and investigation work. Use when a user asks to connect or set up Quire, install the current coding-agent integration, create .quire/runbook.md, or prepare Quire for a repository.\n---\n\n# Quire setup\n\nYou are setting up a repository for Quire, a read-only run agent for investigate, verify, and triage work. Quire needs durable project, product, and verification context, not a target catalog or a command script.\n\nThis hosted skill is the sole public end-to-end onboarding entrypoint. Your job is to establish a stable Quire CLI, install only the current coding-agent harness integration in the project, establish account and model readiness, create the smallest useful runbook, verify the CLI-owned managed Quire block in `AGENTS.md`, run doctor and a narrow smoke, and report capability-scoped readiness.\n\n`.quire/runbook.md` is the durable source for what the product does, which workflows matter, how caller-supplied target claims map to environments, which actions are safe, what proves success, and which evidence to capture. It does not own dependencies, secrets, migrations, fixtures, target startup, or process supervision.\n\nThe parent coding agent owns those prerequisites and passes Quire an already-running target through the request, `--url`, or `QUIRE_WEB_URL`. Quire resolves the target claim through the runbook, then uses the product well enough to prove or disprove the claim. It must never guess a port or start, restart, migrate, seed, or supervise the target.\n\nKeep Quire's generic operating mechanics out of the project runbook unless they customize this project's workflow. Do not add boilerplate that merely restates planning, assertion statuses, handoff wording, evidence mechanics, or non-applicable domains.\n\nInspect the repository before asking questions. Ask one focused grouped question for material facts you cannot determine. Complete the runbook from the answers; retain an open question only when the user explicitly says they do not know or want to defer it. Never turn unasked placeholders into permanent policy.\n\n## Definition of done\n\nQuire setup is complete when:\n\n- The current machine has a stable `quire` command on `PATH`. An `npx @quireco/cli@latest` bootstrap alone is not stable readiness because installed adapters invoke `quire` later.\n- The current coding-agent harness is known and only its project-local Quire adapter plus verify/triage skills are installed under the explicit project root using that harness's native conventions. These are intentional, reviewable repository artifacts that the user may commit and share; setup never stages or commits them.\n- Valid, server-verified Quire account auth and a pinned workspace are configured. Every Run requires both.\n- Model access is clear. Use `quire whoami --json` and `modelAccess` from `quire doctor --json` to verify one selected hosted source. Prefer the user's personal ChatGPT subscription when connected; it requires no Quire Credits balance. If it is unavailable and managed inference is enabled, managed Quire Credits require at least $1 available. Follow doctor's exact Personal connections, Credits top-up, login, or retry action.\n- `.quire/runbook.md` exists as durable repo-specific product and verification context, not as a command script or process owner.\n- The runbook has a separate target/environment policy and a capability matrix whose only columns are `Capability`, `Preconditions`, `Safe actions`, `Success oracle`, and `Evidence`.\n- Material unknowns were answered and incorporated. An open question remains only when the user explicitly deferred it or did not know the answer.\n- Test-account readiness was considered only for important documented workflows that require authentication. Missing accounts block only those capabilities; they are not a global setup or doctor failure.\n- `AGENTS.md` contains exactly one current managed Quire block with concise future-agent instructions for using Quire in this repo.\n- `quire doctor` has no setup failures, or remaining failures are reported with the exact user action needed.\n- A narrow setup smoke reaches a terminal status, or the exact blocker is documented. The smoke checks doctor health, runbook readability, and, only when the caller supplies a target, reachability plus one identifying read-only interaction. It is not broad E2E verification.\n- The final reply includes the setup readiness summary defined below.\n\n## End-to-end setup flow\n\nWhen the user asks to \"connect Quire\", \"set up Quire\", or onboard a fresh repo, complete the whole setup flow, not only the runbook.\n\n1. **Establish the project root.** Prefer `git rev-parse --show-toplevel` when inside a Git worktree. Otherwise use the explicit project root already supplied by the caller or harness. Do not infer a user-home scope merely because `.git` is absent. If no project root can be established, ask for it and stop before integration writes.\n2. **Identify the current harness.** Use the active coding-agent environment when it is unambiguous; otherwise ask one focused question. Choose exactly one of `amp`, `claude`, `codex`, `cursor`, `opencode`, or `pi`. The project-local conventions are:\n - Amp: `.amp/plugins/quire.ts` plus `.agents/skills/{verify,triage}/SKILL.md`\n - Claude Code: `.claude/agents/quire.md` plus `.claude/skills/{verify,triage}/SKILL.md`\n - Codex: `.codex/agents/quire.toml` plus `.agents/skills/{verify,triage}/SKILL.md`\n - Cursor: `.cursor/agents/quire.md` plus `.cursor/skills/{verify,triage}/SKILL.md`\n - OpenCode: `.opencode/agents/quire.md` plus `.opencode/skills/{verify,triage}/SKILL.md`\n - Pi: `.pi/extensions/quire.ts` plus `.pi/skills/{verify,triage}/SKILL.md`\n3. **Establish a stable CLI command.** Run `quire --version`. If it is unavailable, do not probe with `npx`: it can populate the npm cache and still would not provide the stable command installed adapters need. Explain the global package and npm-cache writes, then ask explicitly: **May I install `@quireco/cli` globally with `npm install -g @quireco/cli` so this machine has a stable `quire` command?** If the user declines or defers, report this exact blocker: **Stable Quire command deferred; project integration was not installed because its adapter would invoke a nonexistent `quire` command.** Do not present an `npx @quireco/cli@latest`-only machine as ready.\n4. **Obtain consent for every home write.** Ask immediately before each command that can persist or alter home-directory state; do not batch consent or treat consent for one command as authorization for a later one. Disclose the exact configured paths when known, otherwise the narrow categories and defaults below:\n - `npm install -g`: global package location and npm cache.\n - `quire whoami`: may refresh or remove the Quire account-auth file (default `~/.local/share/quire/auth.json`).\n - `quire login`: Quire account-auth file.\n - `quire doctor`: may create the runs root (default `~/.local/share/quire/runs`).\n - `quire run`: durable run artifacts plus run-add-on and hosted-skill caches under the configured Quire data directory.\n - `quire agent install --global`: the selected harness's user-home plugin/agent and skill files.\n\n A setup request authorizes the documented project-local integration and repo guidance, not any of these home writes. Intent inferred from `--global` is not consent. Never pass `--global` unless the user specifically requests global integration and consents immediately before the write.\n\n5. **Install only the selected project integration.** From any location, run `quire agent install --harness --project \"$project_root\" --json`. This deterministic primitive owns the generic root `AGENTS.md` managed block, selected adapter, and verify/triage files. It must not write `.quire/runbook.md`, authenticate, connect a model, stage or commit files, or emit another setup handoff. Review the returned paths, including `AGENTS.md`, and confirm every path is under the project root. Leave the project-local integration and guidance as ordinary reviewable working-tree changes; the user decides whether to commit and share them.\n6. **Check identity and hosted model readiness.** After obtaining consent specifically for `quire whoami`, run `quire whoami --json`. Its `modelAccess` reports the selected hosted source. Personal ChatGPT is preferred and requires no Quire Credits balance; managed Credits are the fallback when enabled and require at least $1 available. One selected source must be ready.\n7. **Handle account auth explicitly.** If account auth is missing or invalid, tell the user every Quire Run requires valid server-verified browser or API-token auth. Obtain separate immediate consent for `quire login`, then run it when interactive browser auth is possible. If browser auth is not possible, ask the user to configure an API token through the normal local environment. Never ask the user to paste secrets into chat.\n8. **Establish hosted model readiness through doctor.** After account auth is ready, disclose that `quire doctor --json` may create the configured runs root, obtain consent for that command, and run it to inspect typed `modelAccess`. If a personal ChatGPT connection is absent or needs reconnection, direct the user to the authenticated Personal connections page at `https://quire.sh/dashboard?settings=connections`; the user completes provider authorization there, and provider credentials never enter the CLI or agent chat. When managed Credits are selected and need funds, direct a team owner or admin to `https://quire.sh/dashboard?settings=billing`. Follow doctor's exact Personal connections, Credits top-up, login, or retry action and rerun doctor after every user-completed change. Do not report setup ready until fresh doctor output reports valid account auth and one selected hosted model source available.\n9. **Inspect before asking.** Read `AGENTS.md`, existing runbooks and docs, package/workspace scripts, deployment configuration, environment examples, important product routes or commands, and trusted tests. Separate facts from assumptions.\n10. **Resolve material unknowns.** Ask one compact grouped question about only the facts that materially change target selection, mutation safety, critical workflows, success oracles, or account/fixture readiness. Update the runbook from the answer. Do not retain an open question unless the user explicitly defers or does not know.\n11. **Handle authenticated workflow readiness only when needed.** Use the decision flow below. Never request or accept a password in agent chat.\n12. **Write project guidance.** The coding agent creates or updates only `.quire/runbook.md` with the template and rules below. Do not manually edit the managed Quire block in `AGENTS.md`; `quire agent install` already created or refreshed it deterministically. Verify that exactly one supported block exists and report a malformed-marker failure from the install rather than attempting repair.\n13. **Verify setup.** After writing the runbook, obtain fresh command-specific consent and rerun `quire doctor --json`. Treat its typed auth and `modelAccess` results as authoritative for the current machine. Do not treat absent test accounts as a global doctor failure. Do not run the smoke until valid account auth and at least one model source are ready. Before the smoke, describe its durable run directory and possible run-add-on/hosted-skill caches, then obtain separate consent specifically for `quire run`. Keep any target URL supplied by the caller as a distinct `target_url` value; do not splice it into shell source or construct a command with `eval`. Start one narrow smoke run:\n\n```bash\nsmoke_request=\"Smoke-test Quire setup for this repository.\nConfirm doctor is healthy and .quire/runbook.md is readable.\nIf the caller supplied a target, resolve the target claim through the runbook, verify reachability, and perform one identifying read-only interaction.\nTreat the target as caller-owned: do not start, restart, migrate, seed, or supervise it. Never guess a port. If it is unreachable, report environment_blocked.\nDo not mutate external data.\"\n\nif [ -n \"${target_url:-}\" ]; then\n quire run --url \"$target_url\" \"$smoke_request\"\nelse\n quire run \"$smoke_request\"\nfi\n```\n\nThe `target_url` value comes from the caller, not from discovery or target startup. The caller may instead set `QUIRE_WEB_URL`. When no target is supplied, omit `--url`; the smoke remains code-only and must not ask Quire to start an app.\n\n14. **Report readiness.** Use the required readiness summary below. Report what remains workflow-blocked or user-deferred without presenting the whole repository as unready.\n\n## Hosted coding-agent environments\n\nThe same `/setup` flow owns onboarding in Codex Cloud, Cursor Cloud Agents, Claude Code Web, Amp-hosted environments, and other remote coding-agent machines. Install the stable CLI inside that environment, keep the selected harness integration project-local, and run the app in the same VM or container when a localhost target is required. Ask the user to add `QUIRE_API_TOKEN` through the platform's secret UI when browser login is unavailable, and verify token presence without printing it. Ask for outbound access to the configured Quire API host when egress is restricted. Do not create API tokens, change cloud-provider settings, or copy secrets through chat; report the exact manual blocker and wait.\n\n## Authenticated workflow decision flow\n\nAsk about target-product test accounts only when an important documented workflow requires authentication.\n\n1. If no important workflow requires authentication, do not ask about test accounts.\n2. If authentication is required, check the available Quire workspace account-management surface for a matching registered account. Account characteristics such as permissions, subscription state, seeded data, and safe mutation boundaries are notes or runtime metadata, not runbook identity fields.\n3. If no matching account is registered, first ask: **Does a reusable account for the target product already exist? Do not send its password or any secret here.**\n4. If it exists, ask the human to register it directly through `quire test-accounts add` when that command is available in their installed CLI, or through `https://quire.sh/w//personalization`. The human then tells the agent to recheck. Do not request, accept, echo, copy, or store the password in agent chat, files, commands, or the runbook.\n5. If it does not exist, explain that creating, inviting, resetting, or seeding a target-product account is separate from registering an existing credential with Quire. The parent coding agent or user owns that target-product provisioning. After an account exists, the human registers it with Quire outside agent chat and asks the agent to recheck.\n6. If the user explicitly defers account work, mark only the affected capability as blocked and record the deferred question. Continue completing all other runbook and setup guidance.\n\n## Runbook file\n\nUse one project-local Markdown runbook:\n\n```md\n# Quire runbook\n\n## Product and verification context\n\nWhat the product does, who uses it, the important workflows, and the domain terms needed to interpret results.\n\nThis runbook is durable product and verification context. It does not own dependencies, secrets, migrations, fixtures, target startup, or process supervision.\n\n## Parent-owned target handoff\n\n- Prerequisites the parent coding agent must prepare before invoking Quire:\n- Readiness signal the parent should confirm:\n- How the parent supplies the target claim and already-running URL:\n\nQuire must not install dependencies, manage secrets, migrate or seed data, create fixtures, guess ports, or start, restart, or supervise the target.\n\n## Target and environment policy\n\n- How to resolve each supported caller target claim, such as local, preview, staging, or production:\n- Precedence for an explicit `--url` or `QUIRE_WEB_URL`:\n- Mutation boundary for each environment:\n- What to do when the claim is ambiguous, conflicts with an explicit URL, or resolves to an unreachable target:\n\nThe parent supplies the target claim. Quire resolves it through this policy. Never guess a URL or port; ask for the missing target or report `environment_blocked`.\n\n## Capability matrix\n\nUse exactly these columns. Add only repo-specific capabilities and delete example rows that do not apply.\n\n| Capability | Preconditions | Safe actions | Success oracle | Evidence |\n| ------------------------------- | ----------------------------------------------------------------------- | ----------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- | ---------------------------------------------------------- |\n| Public product smoke | Parent supplied an already-running target | Open the named surface and exercise the read-only path | The documented expected state is visible with no relevant runtime error | Screenshot plus console or command output |\n| Authenticated critical workflow | Matching reusable account is registered with Quire; safe fixture exists | Sign in through Quire's credential tool and exercise only the named safe path | The workflow reaches its documented expected state without disallowed side effects | Screenshots and relevant network, log, or command evidence |\n| Deterministic repository check | Parent prepared dependencies and required services | Run the named non-mutating check | Command exits successfully and expected assertions run | Captured command output |\n\nDo not add fixed account, permission category, status, or target columns. Account characteristics and target details belong in the notes and policy sections.\n\n## Important workflow notes\n\n- Workflow name, entry point, expected outcome, and safe stopping point:\n- Required account characteristics or fixture state, without credentials:\n- Known failure modes and signals worth inspecting:\n\n## Trusted checks\n\n- Command and when it applies:\n- What a pass proves:\n- Known false positives, flakiness, cost, or side effects:\n\nOnly list checks Quire may run without installing dependencies or changing target state. The parent coding agent owns missing prerequisites.\n\n## Safety, data, and external services\n\n- Prohibited operations and environments:\n- Approved read-only or reversible actions:\n- External-service, rate-limit, billing, privacy, or cleanup constraints:\n- Secret names or credential sources Quire may depend on, without secret values:\n\n## Product references\n\n- Named design, accessibility, performance, reliability, API, CLI, or product references that define the quality bar:\n- Representative surfaces or fixtures to compare:\n\n## Open questions\n\n- Include only questions the user explicitly deferred or could not answer. State which capability each question blocks.\n```\n\nOnly include facts from repository evidence or the caller's answers. Delete template prompts after filling them. Delete empty and non-applicable sections except `Open questions`, which should itself be removed when none remain. Merge duplicate safety rules. Never invent URLs, ports, app IDs, accounts, fixtures, commands, or environment policy.\n\nBefore finishing, confirm that every capability has concrete preconditions, safe actions, a success oracle, and evidence; every supported target claim resolves without guessing; every external mutation has an explicit boundary; and every important authenticated workflow either has a registered reusable account or is explicitly capability-blocked.\n\n## Setup readiness summary\n\nEnd setup with this compact handoff:\n\n```md\n## Quire setup readiness\n\n- Quire command: ``\n- Harness integration: selected harness, project-local scope, and installed paths; or exact blocker\n- Account and model access: ready, not requested, or exact blocker\n- Runbook: ready, with the target/environment policy and capability matrix confirmed\n- Managed AGENTS block: created, refreshed, unchanged, or blocked by an exact malformed-marker condition\n- Target handoff: caller must supply the target claim and an already-running URL through `--url` or `QUIRE_WEB_URL`\n- Authenticated critical workflows: ready, not required, or named capability blocked pending human account action\n- Doctor: ready or exact blocker; absent test accounts are not a global doctor failure\n- Setup smoke: run id, link, verdict, and evidence; or exact reason it was not run\n- User-deferred questions: none, or the explicit deferred items and affected capabilities\n```\n\nDo not claim the repository is fully ready when a required item is blocked. Do not claim the whole setup failed when only one authenticated capability lacks an account.\n\n## Managed AGENTS.md block\n\n`quire agent install` owns one generated block in root `AGENTS.md`, following the same recognizable managed-section pattern used by toolchains such as Vite+. The hosted coding agent must not write it manually. This section documents the CLI-owned contract and canonical content. Keep it short enough to load on every agent turn.\n\nUse these literal, schema-versioned markers:\n\n- Start: ``\n- End: ``\n\nExample:\n\n```md\n\n\n## Quire verification\n\n- Quire runbook: `.quire/runbook.md`\n- Run `quire doctor` before Quire work.\n- The parent coding agent owns dependencies, secrets, migrations, fixtures, and target process lifecycle.\n- Pass Quire an already-running target using `--url` or `QUIRE_WEB_URL`; Quire must not start, restart, migrate, seed, or supervise the target.\n- Resolve the caller's target claim and safety policy through the runbook; never guess a URL or port.\n- If an authenticated check needs an account or fixture that is unavailable, continue unrelated checks and tell the user which account or provisioning action is needed. Never ask for credentials.\n\n\n```\n\n### CLI managed-block update contract\n\n1. Inspect marker count, order, nesting, and schema before editing.\n2. If exactly one complete supported managed block exists, replace that whole block with the current schema while preserving every byte of user-authored content before and after it unchanged.\n3. If no managed marker exists, create root `AGENTS.md` with the block or append the block at the end of the existing file. Do not semantically choose another insertion point.\n4. Preserve unmarked Quire prose as user-authored content; the CLI never guesses whether to move or delete it.\n5. Duplicate, nested, reversed, unmatched, incomplete, malformed, or unsupported-schema markers are invalid. Stop before any integration write, do not append a second block, and report the detected marker condition.\n6. Never edit content outside the markers while refreshing an existing managed block.\n7. Never put secrets, passwords, tokens, private account values, or transient run results in the block.\n8. Running setup twice with the same inputs must preserve content, mode, and mtime.\n9. `schema=1` versions the block format, not the installed CLI version. Future schemas must deliberately migrate recognized older managed blocks.\n\nDo not add target-catalog files or CRUD-style project setup commands. The public onboarding entrypoint is this hosted `/setup` skill. `quire agent install` is the deterministic integration-file and managed-AGENTS primitive; run target context belongs in the prompt, `--url`, `$QUIRE_WEB_URL`, and `.quire/runbook.md`.\n",[],[141,202,32],"quire-setup","5b0b330e-da36-4bc9-b9ec-1ad72f646824",3,["D",1787359245781],[159],[141,202],["D",1787359245306],[158,160,162],[141],["D",1787359107320],{"_95":94,"_103":99},{"_95":94,"_96":97,"_98":99,"_18":53,"_100":101,"_102":24},{"_13":84,"_31":85,"_41":40,"_86":42,"_87":-5,"_88":-5,"_89":-5,"_90":-5,"_91":-5,"_92":43,"_93":94},"ctx",{"_77":-5,"_123":248,"_249":250,"_251":252,"_253":24,"_254":24,"_255":24,"_256":57,"_257":-5,"_258":-7,"_259":-7,"_260":61,"_261":24,"_262":24,"_263":-5,"_264":24,"_265":24,"_266":24,"_267":-5},"ENV",{"_219":220,"_221":222,"_223":85,"_224":225,"_226":227,"_228":229,"_230":231,"_232":233,"_234":235,"_236":237,"_238":239,"_240":241,"_242":243,"_244":245,"_246":247},"REACT_APP_SENTRY_DSN","https://586020d86f05489db63a554690acf1e9@o1398359.ingest.sentry.io/6724499","RENDER_GIT_COMMIT","e87eb04e707cf64e7e532c8e8ec395f209e17f15","RENDER_GIT_BRANCH","POSTHOG_API_TOKEN","phc_nmoyuAkStEZuUp69rYlg1DZgrIt19Gx0Y4Hwf8tGgJP","POSTHOG_API_HOST","https://wart.val.town","WEB_API_TEMPLATE","https://{val}.web.val.run","APP_URL","https://www.val.town","MODULE_URL","https://esm.town","VANITY_WEB_API_TEMPLATE","https://{label}.val.run/","DENOLS_URL","https://lsp.val.town","NODE_ENV","production","CLOUDFLARE_TURNSTILE_SITE_KEY","0x4AAAAAACtaIZJH7s9rBMZ6","GOOGLE_CLIENT_ID","875989696899-jtsqkhlbdv5jrlsk8631p7ipjg3c6o62.apps.googleusercontent.com","STRIPE_PUBLISHABLE_KEY","pk_live_51N2zvWEpZTTLipIkVEwXrUG9AT0yeOOEYxszarZT1jpsZV58Ly6wlg3SltZpHN26CUalOBmUSY7adQRQiSkCZz2500qSXNkf8Y","API_URL","https://api.val.town",[],"preferencesKeybindings","default","preferencesTheme","light","preferencesFixers","preferencesCopilot","preferencesSelectionAi","preferencesCloseBrackets","preferencesChatPanelState","preferencesDprint","preferencesDenofmt","notificationCount","flagDenols","isBusinessOrgMember","businessOrgHandle","isBusinessOrgAdmin","isHigherTownieTier","navCollapsed","currentOrgId"]

Diff · v8