' + escapeHtml(skill.name) + \"

\" +\n \"

\" + escapeHtml(skill.description) + \"

\" +\n \"npx skills add \" + escapeHtml(url) + \"

\"\n );\n })\n .join(\"\");\n const html = [\n \"\",\n \"\",\n \"Quire agent skills\",\n \"\",\n \"

Quire agent skills

\",\n \"

Public skills for setting up, verifying, and triaging software with Quire.

\",\n items,\n \"

Agent Skills Discovery RFC v0.2 index

\",\n \"

\",\n ].join(\"\");\n return bodyResponse(request, html, {\n headers: responseHeaders(\"text/html; charset=utf-8\"),\n });\n}\n\nfunction jsonResponse(\n request: Request,\n value: unknown,\n status: number,\n extraHeaders: Record = {},\n): Response {\n return bodyResponse(request, JSON.stringify(value) + \"\\n\", {\n status,\n headers: responseHeaders(\"application/json; charset=utf-8\", extraHeaders),\n });\n}\n\nfunction bodyResponse(request: Request, body: string, init: ResponseInit): Response {\n return new Response(request.method === \"HEAD\" ? null : body, init);\n}\n\nfunction responseHeaders(contentType: string, extra: Record = {}): HeadersInit {\n return {\n ...corsHeaders,\n \"Cache-Control\": CACHE_CONTROL,\n \"Content-Type\": contentType,\n \"X-Content-Type-Options\": \"nosniff\",\n ...extra,\n };\n}\n\nasync function sha256Digest(value: string): Promise {\n const hash = await crypto.subtle.digest(\"SHA-256\", new TextEncoder().encode(value));\n const hex = Array.from(new Uint8Array(hash))\n .map((byte) => byte.toString(16).padStart(2, \"0\"))\n .join(\"\");\n return \"sha256:\" + hex;\n}\n\nfunction escapeHtml(value: string): string {\n return value.replace(/[&<>\"]/g, (character) => ({\n \"&\": \"&\",\n \"<\": \"<\",\n \">\": \">\",\n '\"': \""\",\n })[character] ?? character);\n}\n","quire-skills","children",[],[172],["D",1787359383021],[],[18],"bec28846-dccf-4500-a769-c97fcc66dfba","SKILL.md","3dde79a8-9dc2-11f1-a22f-1607ee4eb77e","1d08e0c4-9dc2-11f1-9ffa-1607ee4eb77e",38,["D",1787758876321],6,"---\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. Quire performs deep verification: a normal Run can easily exceed five minutes and may take considerably longer, so elapsed time or a short task/client timeout is not evidence of failure. 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 to a terminal status, 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 the returned run metadata describes an older internal harness such as `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, use Quire's terminal handoff substantially intact as the primary body of the response rather than replacing it with a compact summary or excerpt. A short parent-facing header may add the run id, synced Quire run link, verdict, and counts, but retain the handoff's evidence references, blockers, known non-regressions, and next actions so the parent and user receive the context Quire produced.\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, invoke one attached Run and let it continue through the terminal handoff:\n\n```bash\nquire run --url \"\" \"\"\n```\n\nIf there is no URL, omit `--url` and include target context in the natural-language request. Bare attached `quire run` prints the run id, streams progress, and finishes by printing the terminal handoff.\n\nIf the caller provides an existing Quire run id, or the attached output was interrupted after the run id was printed, do not start a new run and do not use `quire status` as the final result. Reattach to the same durable run:\n\n```bash\nquire watch \"\"\n```\n\nUse the synced Quire run URL printed by `quire run` or `quire watch` as the shareable evidence URL when present.\n\nTerminal statuses are `completed`, `failed`, `canceled`, and `stale`. Wait patiently: Quire is another agent doing deep QA work, can easily exceed five minutes, and may take considerably longer. A short task/client timeout or elapsed time is not evidence of failure. Keep the attached invocation running when possible; if it is interrupted, resume the same run with `quire watch \"\"` rather than canceling it or starting a duplicate for the same claim.\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 when reconnecting:\n\n```bash\nquire_runs_dir=$(mktemp -d -t quire-runs-XXXXXX)\nQUIRE_RUNS_DIR=$quire_runs_dir quire run --url \"\" \"\"\n# If the attached output is later interrupted:\nQUIRE_RUNS_DIR=$quire_runs_dir quire watch \"\"\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- Quire terminal handoff substantially intact, including its key evidence, artifacts, screenshots, recordings, traces, blockers, and known non-regressions.\n- Follow-up actions from the handoff for the implementation agent.\n",[],[195,196,186],"skills","verify","e4a27cb5-bbbc-443a-8f47-2933e524f2a6","1c8937d4-9dc2-11f1-bcad-1607ee4eb77e",4,["D",1787359246143],"directory",[168],[195,196],"cdbe6043-c664-4b32-b25e-fc670c2fdf5a","3e18abc8-9dc2-11f1-8943-1607ee4eb77e","1d4296e8-9dc2-11f1-9ffa-1607ee4eb77e",["D",1787758909684],"---\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. Quire performs deep investigation: a normal Run can easily exceed five minutes and may take considerably longer, so a short task/client timeout or elapsed time is not evidence of failure. Wait to a terminal status instead of canceling or duplicating the Run.\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. Return Quire's terminal handoff substantially intact as the primary result rather than replacing it with an excerpt. You may add a short header with the run id, synced Quire run link, verdict, and counts, but preserve its evidence references, blockers, non-regressions, and next actions. 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. Start one attached Run and let it continue through the terminal handoff:\n\n```bash\nquire run --url \"\" \"\"\n```\n\nQuire can easily exceed five minutes and may take considerably longer. A short task/client timeout or elapsed time is not evidence of failure. If the caller provides an existing run id, or the attached output is interrupted after printing the run id, reattach to the same durable run instead of starting over:\n\n```bash\nquire watch \"\"\n```\n\nFor more CLI details, sandbox recovery, and handoff interpretation, follow https://skills.quire.sh/verify.\n",[],[195,211,186],"triage","d8ba9059-b575-4994-9e16-dd28db3ff50d",5,["D",1787359246523],[166],[195,211],"1b61290f-8276-4b3b-bf73-a45aa0c08859","24e00084-9dc2-11f1-bc54-1607ee4eb77e","1cd182d2-9dc2-11f1-b21c-1607ee4eb77e",37,["D",1787758875340],19,"---\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\nSet up Quire end to end: establish a stable CLI, install the current harness integration, establish account and model readiness, create concise project guidance, run doctor, and finish with deterministic readiness plus a concrete optional first-verification suggestion.\n\nThe parent coding agent owns setup and target prerequisites. Quire receives an already-running target through the request, `--url`, or `QUIRE_WEB_URL`; it does not install dependencies, manage secrets, migrate or seed data, create fixtures, guess ports, or start, restart, or supervise the target.\n\n`.quire/runbook.md` is runtime guidance for the Quire Agent. It contains only durable, repository-specific facts that help the Agent recognize and access the target in its Run brief, exercise important workflows safely, recognize success, and choose trusted checks. Generic Quire behavior stays in Quire's own instructions.\n\n## Setup workflow\n\n### 1. Establish the project and harness\n\n1. Use the current Git top-level as the project root. Outside Git, use an explicit caller-provided root; never infer user-home scope.\n2. Identify the active harness as exactly one of `amp`, `claude`, `codex`, `cursor`, `opencode`, or `pi`. Ask only when the environment does not make it clear.\n3. Run `quire --version`. Do not use `npx` as a readiness probe: adapters need a stable `quire` command later.\n4. If the command is missing, explain that `npm install -g @quireco/cli` writes the global package and npm cache, then ask permission for that command. If permission is declined, stop before installing an adapter that cannot run.\n5. Install the selected project integration with:\n\n ```sh\n quire agent install --harness --project \"$project_root\" --json\n ```\n\n Project setup authorizes these repository-local files. Confirm every returned path remains under the project root and do not stage or commit them. The installer supports project-local integration only.\n6. Determine whether the selected harness can load newly written agent definitions in its current process. Use the harness's known capability; do not probe by dispatching a task or starting a Run.\n7. If it cannot hot-load them, record harness activation as `restart required`. Continue the remaining deterministic setup in the current parent session, but do not invoke the Quire adapter, silently fall back to a generic agent, or claim native Quire invocation. After the readiness checks, tell the user to restart or reload the harness and resume from the ready integration. Only a session in which the adapter is active may offer the first verification.\n\nThe installer owns the shared verify and triage skills, the selected harness adapter, and the managed Quire block in root `AGENTS.md`. Do not recreate or manually repair those files. Report malformed managed markers from the installer.\n\n### 2. Establish Quire account and model readiness\n\nEvery Run requires valid Quire account authentication, a pinned workspace, and one available hosted model source.\n\nRun `quire whoami --json` and use its server-verified identity, workspace, and `modelAccess` rather than inferring readiness from local files. This check may refresh stale local Quire auth. Run `quire doctor --json` after account auth is ready; it may create the configured local runs directory. These are expected machine-local setup checks. Never read or print auth files or secret values.\n\n- If account auth is missing or invalid, explain that `quire login` opens interactive authentication and writes local Quire auth, then ask permission immediately before running it.\n- In a remote environment without browser login, ask the user to configure `QUIRE_API_TOKEN` through that environment's secret UI. Never request or print the token; request outbound access to the configured Quire API host when egress is restricted.\n- Prefer a connected personal ChatGPT subscription when selected; it does not require Quire Credits.\n- When personal ChatGPT needs connection or reconnection, direct the user to `https://quire.sh/dashboard?settings=connections`. The user completes provider authorization, then the agent reruns the readiness checks.\n- When managed inference is selected, require its reported readiness and a positive Quire Credits balance. Direct an owner or admin to `https://quire.sh/dashboard?settings=billing` only when fresh CLI output requires a top-up.\n- Follow the exact login, connection, billing, or retry action from fresh `whoami` and doctor output. Do not report readiness from stale output.\n\nQuire account auth, hosted model access, and target-product test accounts are separate concerns.\n\n### 3. Build the project runbook\n\nInspect before asking: read root guidance, the existing runbook when present, product docs, package/workspace scripts, deployment configuration, environment examples, important routes or commands, and trusted tests. Discover only environments the repository actually supports. For each one, determine how the Quire Agent can recognize it from the resolved target, how access works, what data or mutations are safe, and what should happen when access is unavailable. Separate repository facts from assumptions.\n\nAsk concise grouped questions for unknowns that materially change environment recognition, authentication, mutation safety, an important workflow, its success signal, or fixture readiness. Incorporate the answers into the runbook. If the user cannot supply a required fact, report the affected path as not ready rather than guessing or leaving a question in runtime guidance.\n\n### 4. Handle target-product accounts only when needed\n\n1. Consider a target-product account only when an important documented workflow requires authentication.\n2. Prefer a repository-supported disposable bootstrap or seeded-account flow when it matches the selected environment and mutation boundary. Record the access method and required account characteristics, not the incidental account created during setup.\n3. Otherwise, check for a matching Quire-registered account scoped to the exact target origin.\n4. If none exists, ask whether a reusable target account already exists and tell the user not to send its password or any secret.\n5. If it exists, guide the user to register it through the authenticated workspace UI at `https://quire.sh` or, when they prefer the CLI, through the hidden password prompt in `quire test-accounts add`; then recheck. The parent agent never asks for, handles, or echoes the password.\n6. If it does not exist, guide the user through the repository-supported target-product provisioning flow first. Quire does not invent, invite, reset, or seed an undocumented target account.\n7. If account setup is deferred, mark only the affected verification path blocked and continue unrelated setup.\n\nNever place passwords in chat, commands, repository files, the runbook, or public artifacts. Put an exact non-secret account identifier in the runbook only when the caller confirms that the identity is durable and selecting it is required; otherwise document the account characteristics and selection procedure.\n\n### 5. Verify deterministic readiness\n\nConfirm the installer produced exactly one current managed Quire block in root `AGENTS.md`. Do not edit that block manually.\n\nAfter the runbook is ready, rerun `quire doctor --json`. An absent target-product test account is not a global doctor failure; it blocks only paths that require it.\n\nSetup is ready when the stable CLI, selected harness integration, account and model access, runbook, managed AGENTS block, and doctor are ready. Integration files may be ready while the current harness process still requires a restart to activate them; report that session blocker explicitly and do not claim the adapter is usable in the current process. Do not start `quire run` merely to prove setup. A Run uses the selected model source, writes durable local artifacts, may populate hosted-guidance caches, and is nondeterministic; reserve it for a meaningful caller-selected product claim.\n\n### 6. Offer an optional first verification\n\nOffer a first verification only when the harness adapter is active in the current process. If harness activation is `restart required`, end with the restart or reload instruction instead; do not dispatch any substitute agent in the current session.\n\nOtherwise, end with one concrete first-verification suggestion grounded in the runbook and the caller's priorities. Prefer an important product workflow over a synthetic smoke. State the exact claim to verify, the caller-supplied target needed, any account or fixture prerequisite, and the permitted mutation boundary.\n\nWhen the target and prerequisites are ready, ask:\n\n> Quire is ready. A useful first check is: “Verify against .” This is deep verification, can easily exceed five minutes, creates run artifacts, and uses your selected model source. When it completes I will return Quire's terminal handoff substantially intact. Would you like me to run it?\n\nDo not start the Run until the user opts in. If they agree, preserve the suggested scope and every additional caller constraint, let the attached `quire run` continue through its terminal handoff even when it exceeds five minutes, and return the resulting Quire handoff substantially intact. Use only the caller-supplied target; if none is running, ask the caller to start it and provide the URL rather than guessing a target or substituting a code-only smoke.\n\nWhen the suggested workflow or any other important documented workflow requires authentication, state whether a repository-supported bootstrap, assigned fixture, or matching Quire-registered account is ready. If it is missing, include a separate optional account-readiness next step even when the first suggested verification is public. Offer only the relevant choices: register an existing reusable account, provision one outside Quire, choose a public verification path, or defer authenticated verification. Recommend account setup only for important authenticated workflows, never ask for credentials, and keep the missing account scoped to the affected path. Do not call the first verification deferred unless the user explicitly defers it; otherwise report it as awaiting user opt-in.\n\n## Runbook contract\n\nWrite for retrieval, not completeness. Put the highest-frequency target and access procedure first and state each instruction once. Prefer a short runbook; exceed roughly 800 words only when additional durable workflows materially change what a Run should do.\n\nUse this shape, deleting empty or irrelevant sections:\n\n```md\n# Quire runbook\n\nOne sentence of product context.\n\n## Environments and access\n\n### \n\n- How to recognize this environment from the already-resolved target claim or URL.\n- Authentication or bootstrap procedure, including return to the requested path and required account characteristics.\n- Data ownership and permitted mutation boundary.\n- What to report when the target is ambiguous, protected, unreachable, or lacks required access.\n\n## Verification paths\n\n### \n\n- Target and entry point:\n- Preconditions or fixture state:\n- Safe actions and stopping point:\n- Success signal:\n- Decisive evidence:\n\n## Trusted checks\n\n- Command, when it applies, and what a pass proves.\n- Known cost, side effects, flakiness, or false positives.\n\n## Project-specific exceptions\n\n- Only safety, service, or environment constraints that change the default action.\n\n## References\n\n- Only sources that define expected behavior for the paths above.\n```\n\nAuthoring rules:\n\n- Write from the Quire Agent's perspective: its Run brief already contains the resolved target. Keep setup, invocation, target lifecycle, and post-Run evaluation in parent guidance.\n- Ground every environment, route, account, fixture, command, and policy in repository evidence or caller answers. Verify user-facing routes from declarations, tests, or documented navigation. Document access methods and required account characteristics; include a named account and its selector only when the caller confirms that identity is durable.\n- Include each repository-supported environment that materially changes target recognition, authentication, data ownership, mutation safety, or blocker behavior. Do not invent conventional environments such as staging when the repository does not define them.\n- Include only durable workflows the caller identifies as important or repository evidence makes clearly critical. Route existence and the transient setup task do not make a workflow important.\n- Give each path concrete preconditions, safe actions, a stopping point, a success signal, and decisive evidence. Preserve all assertions inside the caller's named scope without adding adjacent checks; one genuinely noticed out-of-scope issue may be one observation for caller triage.\n- Describe product verification paths here and leave Browser, Mobile, Shell, and other runtime availability to each Run's capability context.\n- List commands only for durable target access and trusted project checks. Preserve caller-confirmed commands exactly when repository evidence supports them, and state what each check actually proves from its assertions and execution layer.\n- Preserve repository-specific self-dogfood facts that change what the Quire Agent should inspect or what evidence proves the product behavior. Keep commands that launch Quire and the parent's post-Run evaluation procedure outside the runbook.\n- Keep project exceptions to repository-specific changes in default action. Exclude generic Quire mechanics, setup procedure, implementation architecture, duplicated policy, and verification-path requirements.\n- When replacing an existing runbook, retain only current facts that change target selection, access, workflow execution, proof, or safety; remove obsolete, speculative, empty, and low-frequency background detail.\n- Cite durable product or repository sources that define expected behavior.\n\n## Readiness report\n\nEnd with:\n\n```md\n## Quire setup readiness\n\n- Quire command: ``\n- Harness integration: selected harness, project-local paths, or exact blocker\n- Harness activation: active in this process, or restart/reload required before a Quire task\n- Account and model access: ready or exact next user action\n- Runbook: ready, including target/access and verification paths\n- Managed AGENTS block: created, refreshed, unchanged, or exact malformed-marker blocker\n- Target handoff: how the caller supplies the already-running target\n- Authenticated verification paths: ready, not required, or named blocked paths; for each important blocked path include the required non-secret account characteristics and optional account-readiness next step\n- Doctor: ready or exact blocker\n- First verification: concrete suggested claim, required target and account prerequisites, and whether it is blocked on harness activation, awaiting user opt-in, completed by request, or explicitly deferred; include run id, link, verdict, and decisive evidence only when a Run was actually requested\n- Unresolved required facts: none, or the exact readiness blocker and affected paths\n```\n\nDo not claim full readiness when a required item is blocked. Do not claim the whole setup failed when one authenticated path lacks a target-product account.\n",[],[195,226,186],"quire-setup","5b0b330e-da36-4bc9-b9ec-1ad72f646824",3,["D",1787359245781],[164],[195,226],"65f43ebe-a35f-475a-b973-62a0afedb13e",2,["D",1787359245306],[163,165,167],[195],["D",1787359107320],{"_11":12,"_121":69},{"_11":12,"_116":117,"_68":69,"_30":67,"_118":119,"_120":24},{"_38":107,"_13":16,"_32":35,"_108":71,"_109":-5,"_110":-5,"_111":-5,"_112":-5,"_113":-5,"_114":14,"_115":12},"ctx",{"_53":-5,"_140":274,"_275":276,"_277":278,"_279":24,"_280":24,"_281":24,"_282":84,"_283":-5,"_284":-7,"_285":-7,"_286":26,"_287":24,"_288":24,"_289":-5,"_290":24,"_291":24,"_292":24,"_293":-5},"ENV",{"_245":246,"_247":248,"_249":16,"_250":251,"_252":253,"_254":255,"_256":257,"_258":259,"_260":261,"_262":263,"_264":265,"_266":267,"_268":269,"_270":271,"_272":273},"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"]

History · README.md