[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71E2ERM4HSMQXZST0TBWHTX":3,"skill-same:01M71E2ERM4HSMQXZST0TBWHTX":73},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":44,"commitSha":45,"skillDirectory":46,"forksCount":47,"repositoryHtmlUrl":48,"repositoryHomepageUrl":6,"ownerHtmlUrl":49,"ownerBlogUrl":50,"ownerDescription":51,"updatedAt":52,"install":53,"resources":66},"01M71E2ERM4HSMQXZST0TBWHTX","startwork",null,"Resolve current HQ context and surface useful next work options.","indigoai-us\u002Fhq-core","indigoai-us","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F122242446?v=4","01M71DTQ5NGD10GT1Z7E6XKWC5","HQ","01M71DTQ6BKSYYBNC9RAKT3YDK",94,"MIT","https:\u002F\u002Fgithub.com\u002Findigoai-us\u002Fhq-core\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fstartwork\u002FSKILL.md",[],[5,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"useful","handoff","context","frontmatter","live","git","sync","read","scripts","options","next","work","lock","Bash","prefetch","company","mesh","bind","ls","2026-11-10 10:12:30",false,"---\nname: startwork\ndescription: Resolve current HQ context and surface useful next work options.\nallowed-tools: Read, Grep, Glob, Bash(git:*), Bash(qmd:*), Bash(ls:*), Bash(core\u002Fscripts\u002Fhq-session.sh:*), Bash(hq:*), Bash(bash core\u002Fscripts\u002Fresume-thread-lock.sh:*), Bash(bash core\u002Fscripts\u002Fwork-mesh-live-bind-trusted.sh:*), Bash(bash core\u002Fscripts\u002Fresolve-company.sh:*), Bash, AskUserQuestion, Bash(bash core\u002Fscripts\u002Fread-policy-frontmatter.sh:*), Bash(bash core\u002Fscripts\u002Fhandoff-sync-prefetch.sh:*), Bash(bash core\u002Fscripts\u002Fstartwork-context.sh:*)\n---\n\n# Start Work Session\n\nLightweight session entry point. Resolves context fast, presents smart options, gets you working.\n\n## Fast path: exact company slug (check first)\n\nOne command does the whole company half of this skill:\n\n```bash\nbash core\u002Fscripts\u002Fstartwork-context.sh orient --company \"{co}\" --mode Company\n```\n\nIt does the Work Mesh trusted bind for this session (company and mode, with the company's hard-policy digest), checks that the bind landed, and prints the `\u003Cstartwork-context>` block, including a Board line read from the work mesh cache, plus a `Last thread:` line that only names a thread of `{co}`. It needs the caller's own session id: the harness env, or `--session-id \u003Cid>` when the host does not export one. It never binds through `workspace\u002Fsessions\u002F.current`. Exit 3 means `{co}` is not an exact manifest slug, and nothing was bound. Exit 4 means the bind did not land; stop and report it.\n\n**A. A `\u003Cstartwork-prefetch company=\"{co}\">` block is already in the prompt context** and `{co}` is the first word of the argument. The prompt hook already ran `orient` for `{co}`. It fires only for an exact slug, and only when the remaining args are not a slash command, a bare skill name, a bounded action (§1.0b), or a second company, and never when the session is already bound to a different company (that switch goes through the normal process). Do not run `orient` again.\n\n**B. No prefetch block, the first word looks like a company slug, and §1.0\u002F§1.0b do not apply.** Run `orient` with that word as your first tool call, before §0.5. On exit 3, continue with the normal process below.\n\nAfter A or B, the trusted bind, §0.5, §1 resolution, §1.2, §2.4, Company Mode steps 1–3 and the handoff read are done. Do not run `resolve-company.sh`, `startwork-context.sh resolve` or `block`, `hq-session.sh set company_slug` or `set mode`, or `work-mesh-live-bind-trusted.sh`, and do not read `handoff.json` or the Board cache files. Then:\n\n1. No remaining args → go straight to §3 Present Options in Company mode. Show the block verbatim, its Board line included. Only run Company Mode step 4 when the block's Integrations line reads \"not cached\". Take the Worker route from the block's Workers line and skip the §2.5 policy counts; the digest already surfaced the company's hard rules.\n2. Remaining args → treat them as the focus inside `{co}`: a `{co}` project name continues in Project Mode from step 3, anything else is Task Mode starting at step 2. If they resolve to a project or repo owned by a different company, stop and ask which company the user means.\n3. If the host saved the prompt-hook output to a file and showed only a preview (the policy trigger hook adds the bound company's policies to the same output), read that file once with one tool call. It holds the full block; do not re-run the scripts.\n\nWithout an exact slug, run the normal process below.\n\n## When to Use\n\nBeginning of every session. Replaces ad-hoc orientation.\n\n## Work Mesh Live — trusted bind (do this first)\n\nBefore any other tool call that touches project work, bind the session per\n`.claude\u002Fskills\u002F_shared\u002Fwork-mesh-live-bind.md` (US-011):\n\n```bash\nbash core\u002Fscripts\u002Fwork-mesh-live-bind-trusted.sh \\\n  --company \"{co}\" --project \"{project}\" --task \"{task}\"\n```\n\nOmit `--task` when unknown. This writes `workspace\u002Fsessions\u002F\u003Csid>\u002Fmeta.yaml`\nand reconciles with `observation.trustedContext` (no `--trusted` CLI flag).\n\nWhen a company is resolved, `startwork-context.sh orient` (fast path and\n§1.2) runs this same bind for you. Do not run both.\n\n## Process\n\n### 0.5 Default-company fallback\n\nWhen the argument does not itself select a company, resolve context before entering an unbound path:\n\n```bash\nbash core\u002Fscripts\u002Fresolve-company.sh --prompt \"{the user's full input}\"\n```\n\nUse its company when `source` is `prompt`, `session`, or `device_default`; an existing session company always wins over the device default. `none` (including disabled or `needsChoice` default state) must open the structured company\u002Fpersonal picker, never silently proceed unbound.\n\n### 1. Resolve Argument\n\n**1.0 Slash-command short-circuit (HARD RULE — check FIRST):**\n\nIf the argument contains a slash-command token (whitespace-delimited substring matching `\u002F\u003Cname>` for any `\u003Cname>` that is a valid slash command in `.claude\u002Fcommands\u002F`), abort the normal classification flow and route to that command. Specifically:\n\n- **`\u002Fdeep-plan` token present** → STOP. Do not classify, do not enter Task Mode, do not pick a worker pipeline. Announce: *\"`\u002Fdeep-plan` detected in args — routing to deep-plan skill.\"* Then load `.claude\u002Fskills\u002Fdeep-plan\u002FSKILL.md` and execute it end-to-end with the remaining args (everything after `\u002Fdeep-plan`) as the project description. The deep-plan skill produces `companies\u002F{co}\u002Fprojects\u002F{name}\u002Fprd.json` + board entry and HARD STOPS at `\u002Fhandoff`. Implementation MUST NOT happen in this session.\n- **`\u002Fprd` token present** → route to `.claude\u002Fskills\u002Fprd\u002FSKILL.md` similarly.\n- **Other `\u002Ffoo` tokens** → check `.claude\u002Fcommands\u002Ffoo.md`; if present, route to that command's skill (if any) or invoke the command directly.\n- **Bare skill names count the same.** The Claude desktop app refuses to send a message that starts with a slash command and contains another slash command, so desktop users write `\u002Fstartwork {co} deep-plan {description}`. Treat a whole-word `deep-plan` or `prd` argument token exactly like `\u002Fdeep-plan` or `\u002Fprd`. Other bare words are only routed when they exactly match a hyphenated command name in `.claude\u002Fcommands\u002F` (for example `run-project`); a plain English word such as `plan` or `review` stays task text.\n\nThis rule supersedes the classification table below. The reason it exists: prior failure where `\u002Fstartwork {company} vyg \u002Fdeep-plan apps\u002F...` was treated as free-text task description, causing the agent to enter Claude Code's built-in plan mode and start implementing instead of running the deep-plan questionnaire. Policy: `core\u002Fpolicies\u002Fdeep-plan-skill-routing.md`.\n\n**1.0b Bounded-action short-circuit (HARD RULE — check SECOND, after the slash-command rule, before mode resolution):**\n\nIf the argument names a bounded action owned by a dedicated skill in the table below, abort the normal classification flow, route to that skill with the raw remaining args, and STOP. Do NOT enter Company Mode. Do NOT read `companies\u002Fmanifest.yaml`, do NOT run the qmd\u002Fgrep project scan, do NOT run git, do NOT build the Worker Packet, and do NOT perform §2.4 session metadata, §2.5 policies, §2.6 worker routing, or any background maintenance. The target skill performs its own tenancy-safe company resolution.\n\nBounded-action routing table (closed list — route only on these):\n\n| Argument names… | Route to |\n|---|---|\n| open \u002F read \u002F check \u002F send a DM, \"DM {person}\", inbox, message thread | `\u002Fdm` |\n| meeting notes, transcript, recap, \"what was discussed\" | `\u002Fmeeting-notes` |\n| signals, decisions, risks, commitments, wins | `\u002Fsignals` |\n| action items (read-only \"what are my action items\") | `\u002Fsignals` (company skills may own the mutable tracker) |\n| find \u002F search \u002F \"where is X\" | `\u002Fsearch` |\n| goals, OKRs, key results | `\u002Fgoals` |\n| \"who am I\", session identity, login state | `\u002Fhq-whoami` |\n\n- A company slug appearing as a word inside a bounded action does NOT upgrade the request to Company Mode — the bounded-action route wins. Example: `\u002Fstartwork open my DM on indigo` → route to `\u002Fdm` (the slug is context for the target skill, not a mode selector).\n- Negative example (the documented failure this rule exists for): `\u002Fstartwork open Izzy's latest project DM` → route to `\u002Fdm` and stop. Full company orientation for this request is a scope bug, not thoroughness.\n- Fall-through: if the argument is a bare company\u002Fproject\u002Frepo name, or names orientation itself (\"what's the state of X\", \"pick up X\", \"start on X\", \"what should I work on\"), this rule does not apply — continue to §1.1 Mode resolution.\n\nThis rule exists because a bounded read-only request (\"open Izzy's latest project DM\") was observed expanding into full company orientation, duplicate policy ingestion, a background maintenance agent, and an unrequested session handoff. Runtimes that follow skill text literally (Codex) must find the fast path in the text itself.\n\n**1.1 Mode resolution** (only if no short-circuit fired):\n\nDetermine mode from the user's argument (first match wins):\n\n- **No arg \u002F empty** — Entry-gate mode (ask before loading context — see \"Entry-Gate Mode\" below)\n- **Arg matches company slug** in `companies\u002Fmanifest.yaml` — Company mode\n- **Arg is a company alias or a repo name** — run `bash core\u002Fscripts\u002Fstartwork-context.sh resolve --arg \"{arg}\"`. `via: slug|alias` → Company mode for that company; `via: repo` → Company mode with the repo noted for git state. Exit 3 means no match: continue below. Never grep the manifest by hand to find out which company an argument belongs to.\n- **Arg matches a directory** in `personal\u002Fprojects\u002F` (not `_archive\u002F`) or `companies\u002F*\u002Fprojects\u002F` — Project mode\n- **Arg matches a directory** in `repos\u002Fprivate\u002F` or `repos\u002Fpublic\u002F` — Repo mode\n- **Partial match** — arg is a substring of any company slug, project dir, or repo name. 1 match: use that mode. 2-5 matches: present numbered list, wait for user to pick. >5: ask user to be more specific\n- **Free-text task** — arg is ≥3 words and doesn't match any company\u002Fproject\u002Frepo\u002Fpartial → Task mode\n- **No match** — ask user to clarify\n\n### 1.2 Bind a resolved company before gathering mode context\n\nAs soon as normal mode resolution or the default-company fallback identifies a\ncompany, bind it on this session before running project scans, `qmd`, worker\nselection, or any repository command. Use the one `orient` call from the fast\npath, with the resolved mode (and the project in Project mode). It is the only\nbind call: it does the trusted bind, records the mode, and prints the\ncapability block with the Board line and the last-thread line.\n\n```bash\nbash core\u002Fscripts\u002Fstartwork-context.sh orient --company \"{co}\" --mode \"{Company|Project|Repo|Task|Resume}\" [--project \"{name}\"]\n```\n\nSession metadata writes require the caller’s harness session identity. If the host does not supply it, pass the exact `--session-id` shown by the scope hook; never select a write target from `workspace\u002Fsessions\u002F.current` or the most recent session.\n\nSkip this step when the fast path already ran `orient` for `{co}`.\n\nFor Project or Repo mode, first resolve the project's owning company or the\nrepo's company mapping when it is not already known, then run this bind before\nany Git command or project scan. A bounded-action short-circuit does not enter\nthis flow, and an unresolved or personal-only context has no company to bind.\nWhen a task id becomes available later, §2.4 adds it to the session.\n\n### 2. Gather Context\n\n#### Entry-Gate Mode (no arg)\n\n**Do NOT eager-load context.** A naked `\u002Fstartwork` must ask the user where to go *before* reading the thread file, running the qmd\u002Fgrep project scan, or reading any prd.json. Only the cheap reads in step 1 are permitted before the gate.\n\n1. **Prefetch cross-device state (fail-soft).** Before reading `handoff.json`, pull the session continuity pointer from the personal vault so a `\u002Fhandoff` run on another machine is visible on this one. The workspace tree is otherwise machine-local; only `workspace\u002Fthreads\u002Fhandoff.json` plus the referenced thread file are carved into the personal vault (hq-cloud-sync `computeContinuityPointerPaths`). Without this pull a fresh session on a second device sees stale state.\n\n   ```bash\n   bash core\u002Fscripts\u002Fhandoff-sync-prefetch.sh\n   ```\n\n   The helper is fail-soft: missing-CLI, offline, logged-out, or lock-held hosts return within the timeout and leave the local pointer untouched. Treat its output as advisory — never block the entry gate on its exit status.\n\n   **Cheap peek.** If `workspace\u002Fthreads\u002Fhandoff.json` now exists, read it (small, allowed by context-diet) and extract only the last-session one-liner (its `summary` \u002F `conversation_summary` field) + referenced branch. Do NOT read the thread file it points to yet. If handoff.json is absent, skip — no last-session option.\n\n   Also glob `workspace\u002Fgates\u002Fpending\u002F*.json` (cheap, no file reads yet). If any exist, a paused workflow is waiting on human answers — note the count for the gate below. Spec: `core\u002Fknowledge\u002Fpublic\u002Fhq-core\u002Fworkflow-gates-spec.md`.\n\n2. **Ask the user (AskUserQuestion), one question, then wait.** Present these options:\n   - **Answer waiting workflow questions ({N})** — only if step 1 found pending gates. A paused workflow resumes the moment these are answered, so list this option FIRST.\n   - **Resume last session** — only if step 1 found a handoff; label it with the one-liner (e.g. *\"Resume: {summary}\"*).\n   - **Pick a company \u002F project \u002F repo** — user names the target; you then re-enter this skill in the matching mode (Company \u002F Project \u002F Repo) with that arg.\n   - **Not sure what to work on** — route to `\u002Fstrategize` (strategic prioritization). Announce the handoff and load `.claude\u002Fskills\u002Fstrategize\u002FSKILL.md`. Do not do project discovery here.\n   - **Something else** — free-text; user describes intent → treat as Task mode.\n\n   Do not present numbered markdown for this gate — use the structured picker. This is the whole point of the gate: no `qmd search \"prd.json\"`, no thread-file read, no per-project prd.json reads happen until the user has chosen.\n\n3. **After the pick, load only what that path needs:**\n   - *Resume last session* → before reading the thread file, resolve `thread_id` from `handoff.json.last_thread` and apply the same resume-lock confirmation procedure from `\u002Fresumework` Step 2. Run `bash core\u002Fscripts\u002Fhq-session.sh current` to obtain the session id, then `bash core\u002Fscripts\u002Fresume-thread-lock.sh inspect \"{thread_id}\"`. On `unlocked`, acquire the marker with `bash core\u002Fscripts\u002Fresume-thread-lock.sh acquire \"{thread_id}\" --session-id \"{session_id}\"`. On `locked` or `stale`, use AskUserQuestion with the returned `prompt` and stop on cancel; only after **Re-resume anyway** run `bash core\u002Fscripts\u002Fresume-thread-lock.sh acquire \"{thread_id}\" --replace --expected-generation \"{lock_generation from inspected JSON}\" --session-id \"{session_id}\"`. If replacement exits `4`, re-inspect and ask again because a newer marker replaced the one the user confirmed. Then, and only then, read the thread file handoff.json points to (extract `conversation_summary`, `next_steps`, `git.branch`, `git.current_commit`, `git.dirty`, `files_touched`); run `git log --oneline -3`; if the thread references a `project_dir`, read its most-recent journal file (frontmatter + `## Open threads` only — see Project Mode step 4). Skip the global qmd\u002Fgrep project scan unless the user then asks \"what else is active?\".\n\n   - *Answer waiting workflow questions* → for each pending gate, oldest first: read its JSON (question, options, context, recommended), ask ONE AskUserQuestion per gate (options from the gate file, recommended first, plus a \"Skip this gate\" option), and on an answer run `bash core\u002Fscripts\u002Fworkflow-gate.sh answer {id} \"{choice}\"` (add `--notes` if the user typed free text). Skipped gates stay pending. When done, re-present this entry gate so the user can pick where to work.\n   - *Pick company\u002Fproject\u002Frepo* → proceed via the corresponding mode's Gather Context section with the supplied arg.\n   - *Not sure* → `\u002Fstrategize` owns it from here; stop gathering.\n   - *Something else* → Task Mode gather.\n\nOnce the chosen path has enough context to name the work, name or rename this\nsession with `set_session_title` according to\n`core\u002Fpolicies\u002Fhq-session-title-grammar.md`. When resuming, carry forward the\nuseful work subject from the predecessor summary; otherwise use the resolved\ntarget. Add company, product, or mode when it adds information. Rename again\nonly when the subject changes, and preserve a title the user manually renamed.\nIf the first-turn title hook already named this session for the same subject,\nkeep that title and make no title call.\n\n#### Company Mode (arg = company slug)\n\n1. The `orient` call (fast path or §1.2) already printed the capability block: no network, about 3 KB. It carries the company's repos, knowledge and source folders, the cached list of usable integrations with the flag for each, the five most recently touched projects with local open-story counts, the Board line, the company's workers, and the path of the skill intent index. Do not grep the manifest, run the qmd\u002Fgrep project scan, read `core\u002Fworkers\u002Fregistry.yaml`, or run git over the first manifest repo by hand; the block replaces those reads (HP-12 traced every one of them as a lookup startwork should have answered).\n2. The `Last thread:` line from `orient` is the handoff check, already filtered to this company. Do not read `workspace\u002Fthreads\u002Fhandoff.json` yourself.\n3. Board status comes from the work mesh, never local prd.passes. For each matching project, load the live Board from cache \u002F Desktop live read: `orient` already did the cache read, and the block's `Board (work mesh cache):` line has the queued \u002F in progress \u002F review \u002F done counts and the next queued story for each listed project, from this company's cache only. Do not read the cache files one by one. A project marked `no board` has no cache entry. If the Board block is absent, use local prd only for project description and acceptance; never as live Board columns. The Projects line's open counts are local too.\n   - `queued` = available next work\n   - `in_progress` \u002F `review` = already claimed; do not offer as free next work\n   - `done` = done\n   Summarize the company totals from the Board line.\n4. If the block's Integrations line reads \"not cached\", run `bash core\u002Fscripts\u002Fusable-integrations.sh show --company {co}` once. That is the only network call startwork may make, and it is skipped when the cache is fresh\n5. Git state only for a repo the user named (or the `via: repo` resolution in §1.1): `git -C {repo} branch --show-current` and `git -C {repo} log --oneline -3`\n6. For that same repo, run `bash core\u002Fscripts\u002Fstartwork-context.sh edit-target --repo \"{repo}\"` and show its lines in the orientation block (see \"Edit target\" below).\n#### Project Mode (arg = project name)\n\nBoard status comes from the work mesh, never local prd.passes. If ground\u002Fcheck and the project-view cache both fail, then and only then use local prd for description — still not as live Board columns.\n\n1. Resolve the project dir (`personal\u002Fprojects\u002F{name}` or `companies\u002F{co}\u002Fprojects\u002F{name}`); when the path is under `companies\u002F{co}`, bind that company now. Read `prd.json` only for `name`, `description`, `branchName`, and acceptance text — not story status.\n2. Extract `metadata.repoPath` — identify company by matching against manifest repos if the project path did not identify it (`bash core\u002Fscripts\u002Fstartwork-context.sh resolve --arg \"{repo basename}\"`). Bind the resolved company before continuing.\n2b. Once `{co}` is known, bind and render in one call: `bash core\u002Fscripts\u002Fstartwork-context.sh orient --company \"{co}\" --mode Project --project \"{name}\"` (this is the §1.2 bind; do not run it twice). The block's last line carries the project goal and branch; the rest is the company context from Company Mode step 1. When the fast path already bound `{co}` and only the project is new, run `bash core\u002Fscripts\u002Fstartwork-context.sh block --company \"{co}\" --project \"{name}\"` and record the project with §2.4.\n3. If repoPath exists: `git -C {repoPath} branch --show-current` and `git -C {repoPath} status --short`, then `bash core\u002Fscripts\u002Fstartwork-context.sh edit-target --repo \"{repoPath}\"` for the orientation block's \"Edit target\" lines\n4. If company `{co}` is resolved, load the live Board from cache \u002F Desktop live read (presence is automatic via `hq mesh daemon`). Prefer `~\u002F.hq\u002Fwork-mesh\u002Fcache\u002Fprojects\u002F{companyUid}\u002F{projectId}.json` when present. Do not call deleted `hq mesh session ground|check|watch`.\n   - `queued` = available next work\n   - `in_progress` \u002F `review` = already claimed; do not offer as free next work\n   - `done` = done\n   Include active mesh thread owners\u002Fblockers in the orientation block when available. Session presence is automatic — do not mint cards during orientation.\n5. **Read session journals** (spec: `core\u002Fknowledge\u002Fpublic\u002Fhq-core\u002Fjournal-spec.md`). If `{project_dir}\u002Fjournal\u002F` exists:\n   - `ls -t {project_dir}\u002Fjournal\u002F*.md 2>\u002Fdev\u002Fnull | head -2` — most recent 2 files\n   - For each: read frontmatter (`status`, `summary`) + `## Open threads` section only — skip `## Auto-capture` (reference material, too noisy for orientation)\n   - If most-recent file has `status: active` and mtime > 24h, treat as abandoned (visually flag in orientation block)\n   - Surface in orientation: latest file's `summary` + any unresolved `## Open threads` bullets\n\n#### Task Mode (arg = free-text task description)\n\n1. Resolve company\u002Frepo from cwd or recent handoff context (read `workspace\u002Fthreads\u002Fhandoff.json` if exists)\n   - If a company is found, immediately bind it with the §1.2 call, `bash core\u002Fscripts\u002Fstartwork-context.sh orient --company \"{co}\" --mode Task`, before task classification or company-specific context reads.\n2. Classify task using inline pattern table:\n   - DB\u002Fmigration\u002Fschema\u002Fprisma → `schema_change`\n   - API\u002Fendpoint\u002Froute\u002Fwebhook → `api_development`\n   - Component\u002Fpage\u002FUI\u002Fform\u002FReact → `ui_component`\n   - Backend + frontend indicators combined → `full_stack`\n   - Content\u002Fcopy\u002Fdocs\u002Fmarketing → `content`\n   - Design\u002Fvisual\u002Fbrand → `design`\n   - Deploy\u002FCI\u002Finfra → `ops`\n   - Otherwise → `enhancement`\n3. Map to worker pipeline (same sequences as `\u002Fprd` command Step 5)\n4. If company resolved, check company-specific workers in manifest — prefer over generic\n\n#### Repo Mode (arg = repo directory name)\n\n1. Resolve full path: check `repos\u002Fprivate\u002F{arg}` then `repos\u002Fpublic\u002F{arg}`\n2. Owning company: scan `companies\u002Fmanifest.yaml` for a company whose `repos:` list contains this path, then bind it before repository commands\n3. Git state: `git -C {repoPath} branch --show-current`, `git -C {repoPath} log --oneline -5`, `git -C {repoPath} status --short`\n3b. Edit target: `bash core\u002Fscripts\u002Fstartwork-context.sh edit-target --repo \"{repoPath}\"`. Show its lines in the orientation block. Write and Edit are blocked under `repos\u002F`, so do not create a branch in the main checkout; run the printed `worktree.sh` command before the first edit.\n4. Related projects:\n   - Primary: `qmd search \"{repo-name} prd.json\" --json -n 10` via shell\n   - Fallback: use Grep to find prd.json files referencing this repo\n   - For each match (max 5), read the prd.json and extract `name` + count incomplete stories\n\n### 2.4 Persist Session Metadata\n\nThe `orient` call in §1.2 (or the fast path) already wrote company, mode and,\nin Project mode, the project into the current session's metadata, so\nper-company hooks and other context-aware skills can find them. Do not repeat\nit. Only add what `orient` could not know, in one call when there is anything:\n\n```bash\n# A project or task found after orient ran (one call, both flags when known):\nbash core\u002Fscripts\u002Fwork-mesh-live-bind-trusted.sh \\\n  --company \"{co}\" --project \"{project_name}\" --task \"{task_id}\"\n# Repo mode only:\nbash core\u002Fscripts\u002Fhq-session.sh set repo \"{repo_name}\"\n```\n\nThis file lives at `workspace\u002Fsessions\u002F\u003Csession_id>\u002Fmeta.yaml`. The current\nsession_id is bootstrapped by `.claude\u002Fhooks\u002Fmaster-hook.sh` on the first\nhook event of every session and tracked in `workspace\u002Fsessions\u002F.current`.\n\n**Important:** until `company_slug` is set, the master hook runs no\nper-company hooks (fail-closed for tenant isolation). Setting it from\nstartwork is what activates the per-company harness for the rest of the\nsession.\n\n**Skip if:** no company resolved (resume mode with no company context).\n\n### 2.5 Report Applicable Policies (display-only — no policy re-reads)\n\nPolicy loading is NOT this skill's job. Two mechanisms already inject policies before this step runs:\n\n1. **Company policies**: surfaced automatically when `orient` (§1.2 or the fast path) binds the company — the bind emits the company's hard-enforcement rules (deduped and budgeted) directly into the tool result. Do NOT re-scan `companies\u002F{co}\u002Fpolicies\u002F` frontmatter here; that duplicates the bind emission.\n2. **Repo policies**: if repo context resolved and `{repoPath}\u002F.claude\u002Fpolicies\u002F` exists, collect its files except `example-policy.md`, preserve their order, and split the stable file order into consecutive chunks of at most 40 files. For each chunk, run `bash core\u002Fscripts\u002Fread-policy-frontmatter.sh {file1} {file2} ...` once with each path as a separate argument. Keep each call under 30 KB of output. The first output block belongs to the chunk’s first file argument; each later block belongs to the path named by its preceding `# --- policy-file: \u003Cpath> ---` separator. This is the one scan this step still owns; repo policies are not covered by the company bind.\n3. **Global policies**: injected by the SessionStart\u002FPreToolUse trigger hook (`inject-policy-on-trigger.sh`). No action here.\n\nDisplay in orientation block (counts only — `ls | wc -l` is enough for N\u002FK):\n```\nPolicies: {N} company, {M} repo, {K} global ({H} hard-enforcement)\n```\n\nRules:\n- This step performs no company-policy file reads. The bind emission from `orient` is the company-policy surface\n- Repo policies: frontmatter only; for repo hard-enforcement policies read the `## Rule` section\n- If no company resolved (resume mode with no company context), the count line may omit company\n- Precedence: company > repo > global\n\n### 2.6 Worker Routing & Skill Readiness\n\nAfter policies are known, build a compact Worker Packet for the resolved context.\n\n1. When a company is resolved, the capability block's Workers line is the candidate list; do not re-read `core\u002Fworkers\u002Fregistry.yaml` for it. Read the registry (auto-generated read-only index) only in task mode without a company, or to map an intent onto public workers, and keep only entries relevant to the current company, project, repo, or task intent. Skip any entry whose `path` is not a directory containing `worker.yaml`. If an active company worker is listed but missing, say so in the orientation block — do not invent a raw-script fallback.\n2. If company `{co}` is resolved, include any registry entries whose `company:` field is `{co}` (sourced from `worker.company` in each `worker.yaml`) or whose path starts with `companies\u002F{co}\u002Fworkers\u002F`.\n3. If project mode and `prd.json` story metadata includes declared workers or worker hints, include those first.\n4. If task mode, map the classified intent to a worker route before offering direct execution:\n   - `design`, `ui_component` → design\u002Ffrontend workers\n   - `content` → content workers\n   - `ops`, deploy\u002FCI\u002Finfrastructure → ops\u002Fdeploy workers\n   - `api_development`, `schema_change`, `full_stack`, `enhancement` → implementation workers plus QA\u002Freview workers when available\n5. Do not read every worker.yaml. Read a worker.yaml only when:\n   - it is the selected\u002Frecommended worker, or\n   - you need its skill list to present a concrete option.\n\nDisplay in orientation block:\n```\nWorker route: {primary worker\u002Fskill or \"none matched\"} ({N} candidates)\n```\n\nRules:\n- Worker-backed paths should appear before direct parent-session execution whenever a relevant worker exists.\n- Direct execution remains available, but label it as direct\u002Fno-worker so the user can make an informed choice.\n- If no worker matches, say so and proceed normally.\n- If the selected path needs worker execution, route through `\u002Frun {worker} {skill}` or `\u002Fexecute-task` rather than reimplementing the worker inline.\n\n### 3. Present Options\n\nDisplay a concise orientation block:\n\n```\nSession Start\n--------------\n{Mode: Resume | Company: {slug} | Project: {name}}\n{\u003Cstartwork-context> block, verbatim, whenever a company is resolved}\n\n{If resume: \"Last session: {summary}\" + \"Next steps: {next_steps with status: open}\" + \"Still open from earlier handoffs: {bash core\u002Fscripts\u002Fhandoff-open-steps.sh list --limit 10, excluding this thread}\"; any delegation manifest under workspace\u002Fdelegations\u002F still at status `sent` gets `bash core\u002Fscripts\u002Fhq-delegate-pickup.sh --manifest \u003Cm> --check` and its result shown as verified \u002F waiting \u002F FAILED}\n{If project: \"Goal: {description}\" + \"Branch: {branchName}\"}\n{If repo: \"Repo: {repoPath}\" + \"Company: {slug}\" + \"Branch: {branch}\"}\n{If a repo was resolved (Repo mode, `via: repo`, or a project repoPath): the `edit-target` lines verbatim, so the worktree command is on screen before any work starts}\n{If task: \"Task: {description}\" + \"Intent: {classified_intent}\" + \"Pipeline: {worker count} workers\"}\n\nGit: {branch} @ {short-hash} {\" (dirty)\" if dirty}\nWorker route: {primary worker\u002Fskill or \"none matched\"} ({N} candidates)\n\nActive work:\n  - {project} -- {done}\u002F{total} stories ({remaining} left)\n  ...\n\nBoard (work mesh):\n  - {id} {title} — {status}\n  ...\nWork mesh threads:\n  {active mesh owners\u002Fblockers for the selected company\u002Fproject, or omit if none\u002Funavailable}\n```\n\nThen present numbered options built from context:\n\n- **Entry-gate mode (no arg)**: no orientation block is rendered before the gate — the AskUserQuestion gate (Gather Context → Entry-Gate Mode step 2) *is* the first interaction. Render an orientation block only *after* the user picks \"Resume last session\", using the loaded thread context; then offer next_steps items (up to 3) + \"Pick a project\" + \"Something else\".\n- **Company mode**: worker-recommended next actions + active projects for that company (up to 3) + \"Run a worker\" + \"Something else\"\n- **Project mode**: top 3 **queued** Board stories from work-mesh `stories[]` via `\u002Fexecute-task` + matching worker route + \"Something else\". Skip `in_progress` unless the user already owns that row.\n- **Repo mode**: related projects with incomplete work (up to 3) + \"Open repo (no project)\" + \"Something else\"\n- **Task mode**: proposed worker pipeline phases (up to 5) + \"Run this worker pipeline\" + \"Modify pipeline\" + \"Do it directly (no worker)\" + \"Plan it with \u002Fprd (send \u002Fprd as its own message)\" + \"Something else\"\n\nOutput the numbered list and wait for user input. When an option starts another skill, phrase it as the skill name for the user to send as its own message (for example \"send `\u002Fdeep-plan {co} {description}` as a new message\"). Never suggest a message that chains two slash commands, such as `\u002Fstartwork {co} \u002Fdeep-plan ...`: the desktop app refuses to send it. If the user picks such an option by number, run the skill in this session instead of asking them to type it. After user picks, proceed directly into the work.\n\n## Rules\n\n- NEVER read INDEX.md, agents files, or company knowledge dirs during startup\n- NEVER run exploratory searches to orient — this skill replaces exploration with targeted reads\n- NEVER grep the manifest, list project directories, or read the worker registry by hand when `core\u002Fscripts\u002Fstartwork-context.sh block` can answer; one script call replaces those reads\n- The capability block reads only the bound company. Never render it for a second company in the same session to compare; that is a tenant-isolation bug\n- A bounded single-action request (§1.0b table) routes to its owning skill and never triggers orientation loading, session-metadata writes, policy scans, worker routing, or background maintenance\n- NEVER spawn a background knowledge-pulse (or any maintenance agent) from startup. The pulse is spawned only by the planning skills (`\u002Fbrainstorm`, `\u002Fprd`, `\u002Fdeep-plan`) — interactive startup spawns zero agents\n- Max file reads: handoff.json + 1 thread + manifest + up to 5 prd.json (headers only) + up to 2 journal files per resolved project (frontmatter + Open threads section only — never load Auto-capture)\n- If >5 active projects found, show top 5 by most recent file modification\n- Always verify git branch with `git branch --show-current` before displaying git state\n- Context diet: every read must serve the orientation summary. No speculative loading\n- Naked `\u002Fstartwork` (no arg) MUST hit the entry gate first — ask via AskUserQuestion before reading the thread file or running any project scan. The only pre-gate read allowed is handoff.json itself (one-liner peek)\n- If the user is unsure what to work on, route them to `\u002Fstrategize` rather than doing eager project discovery\n- If handoff.json doesn't exist, skip the \"Resume last session\" option — the gate still asks (pick target \u002F not sure \u002F something else)\n- Use `qmd search` via shell command — if qmd unavailable, fall back to Grep to scan for prd.json files\n- Before specialized work, prefer the relevant worker route surfaced by the Worker Packet\n","# Start Work Session\n\nLightweight session entry point. Resolves context fast, presents smart options, gets you working.\n\n## Fast path: exact company slug (check first)\n\nOne command does the whole company half of this skill:\n\n```bash\nbash core\u002Fscripts\u002Fstartwork-context.sh orient --company \"{co}\" --mode Company\n```\n\nIt does the Work Mesh trusted bind for this session (company and mode, with the company's hard-policy digest), checks that the bind landed, and prints the `\u003Cstartwork-context>` block, including a Board line read from the work mesh cache, plus a `Last thread:` line that only names a thread of `{co}`. It needs the caller's own session id: the harness env, or `--session-id \u003Cid>` when the host does not export one. It never binds through `workspace\u002Fsessions\u002F.current`. Exit 3 means `{co}` is not an exact manifest slug, and nothing was bound. Exit 4 means the bind did not land; stop and report it.\n\n**A. A `\u003Cstartwork-prefetch company=\"{co}\">` block is already in the prompt context** and `{co}` is the first word of the argument. The prompt hook already ran `orient` for `{co}`. It fires only for an exact slug, and only when the remaining args are not a slash command, a bare skill name, a bounded action (§1.0b), or a second company, and never when the session is already bound to a different company (that switch goes through the normal process). Do not run `orient` again.\n\n**B. No prefetch block, the first word looks like a company slug, and §1.0\u002F§1.0b do not apply.** Run `orient` with that word as your first tool call, before §0.5. On exit 3, continue with the normal process below.\n\nAfter A or B, the trusted bind, §0.5, §1 resolution, §1.2, §2.4, Company Mode steps 1–3 and the handoff read are done. Do not run `resolve-company.sh`, `startwork-context.sh resolve` or `block`, `hq-session.sh set company_slug` or `set mode`, or `work-mesh-live-bind-trusted.sh`, and do not read `handoff.json` or the Board cache files. Then:\n\n1. No remaining args → go straight to §3 Present Options in Company mode. Show the block verbatim, its Board line included. Only run Company Mode step 4 when the block's Integrations line reads \"not cached\". Take the Worker route from the block's Workers line and skip the §2.5 policy counts; the digest already surfaced the company's hard rules.\n2. Remaining args → treat them as the focus inside `{co}`: a `{co}` project name continues in Project Mode from step 3, anything else is Task Mode starting at step 2. If they resolve to a project or repo owned by a different company, stop and ask which company the user means.\n3. If the host saved the prompt-hook output to a file and showed only a preview (the policy trigger hook adds the bound company's policies to the same output), read that file once with one tool call. It holds the full block; do not re-run the scripts.\n\nWithout an exact slug, run the normal process below.\n\n## When to Use\n\nBeginning of every session. Replaces ad-hoc orientation.\n\n## Work Mesh Live — trusted bind (do this first)\n\nBefore any other tool call that touches project work, bind the session per\n`.claude\u002Fskills\u002F_shared\u002Fwork-mesh-live-bind.md` (US-011):\n\n```bash\nbash core\u002Fscripts\u002Fwork-mesh-live-bind-trusted.sh \\\n  --company \"{co}\" --project \"{project}\" --task \"{task}\"\n```\n\nOmit `--task` when unknown. This writes `workspace\u002Fsessions\u002F\u003Csid>\u002Fmeta.yaml`\nand reconciles with `observation.trustedContext` (no `--trusted` CLI flag).\n\nWhen a company is resolved, `startwork-context.sh orient` (fast path and\n§1.2) runs this same bind for you. Do not run both.\n\n## Process\n\n### 0.5 Default-company fallback\n\nWhen the argument does not itself select a company, resolve context before entering an unbound path:\n\n```bash\nbash core\u002Fscripts\u002Fresolve-company.sh --prompt \"{the user's full input}\"\n```\n\nUse its company when `source` is `prompt`, `session`, or `device_default`; an existing session company always wins over the device default. `none` (including disabled or `needsChoice` default state) must open the structured company\u002Fpersonal picker, never silently proceed unbound.\n\n### 1. Resolve Argument\n\n**1.0 Slash-command short-circuit (HARD RULE — check FIRST):**\n\nIf the argument contains a slash-command token (whitespace-delimited substring matching `\u002F\u003Cname>` for any `\u003Cname>` that is a valid slash command in `.claude\u002Fcommands\u002F`), abort the normal classification flow and route to that command. Specifically:\n\n- **`\u002Fdeep-plan` token present** → STOP. Do not classify, do not enter Task Mode, do not pick a worker pipeline. Announce: *\"`\u002Fdeep-plan` detected in args — routing to deep-plan skill.\"* Then load `.claude\u002Fskills\u002Fdeep-plan\u002FSKILL.md` and execute it end-to-end with the remaining args (everything after `\u002Fdeep-plan`) as the project description. The deep-plan skill produces `companies\u002F{co}\u002Fprojects\u002F{name}\u002Fprd.json` + board entry and HARD STOPS at `\u002Fhandoff`. Implementation MUST NOT happen in this session.\n- **`\u002Fprd` token present** → route to `.claude\u002Fskills\u002Fprd\u002FSKILL.md` similarly.\n- **Other `\u002Ffoo` tokens** → check `.claude\u002Fcommands\u002Ffoo.md`; if present, route to that command's skill (if any) or invoke the command directly.\n- **Bare skill names count the same.** The Claude desktop app refuses to send a message that starts with a slash command and contains another slash command, so desktop users write `\u002Fstartwork {co} deep-plan {description}`. Treat a whole-word `deep-plan` or `prd` argument token exactly like `\u002Fdeep-plan` or `\u002Fprd`. Other bare words are only routed when they exactly match a hyphenated command name in `.claude\u002Fcommands\u002F` (for example `run-project`); a plain English word such as `plan` or `review` stays task text.\n\nThis rule supersedes the classification table below. The reason it exists: prior failure where `\u002Fstartwork {company} vyg \u002Fdeep-plan apps\u002F...` was treated as free-text task description, causing the agent to enter Claude Code's built-in plan mode and start implementing instead of running the deep-plan questionnaire. Policy: `core\u002Fpolicies\u002Fdeep-plan-skill-routing.md`.\n\n**1.0b Bounded-action short-circuit (HARD RULE — check SECOND, after the slash-command rule, before mode resolution):**\n\nIf the argument names a bounded action owned by a dedicated skill in the table below, abort the normal classification flow, route to that skill with the raw remaining args, and STOP. Do NOT enter Company Mode. Do NOT read `companies\u002Fmanifest.yaml`, do NOT run the qmd\u002Fgrep project scan, do NOT run git, do NOT build the Worker Packet, and do NOT perform §2.4 session metadata, §2.5 policies, §2.6 worker routing, or any background maintenance. The target skill performs its own tenancy-safe company resolution.\n\nBounded-action routing table (closed list — route only on these):\n\n| Argument names… | Route to |\n|---|---|\n| open \u002F read \u002F check \u002F send a DM, \"DM {person}\", inbox, message thread | `\u002Fdm` |\n| meeting notes, transcript, recap, \"what was discussed\" | `\u002Fmeeting-notes` |\n| signals, decisions, risks, commitments, wins | `\u002Fsignals` |\n| action items (read-only \"what are my action items\") | `\u002Fsignals` (company skills may own the mutable tracker) |\n| find \u002F search \u002F \"where is X\" | `\u002Fsearch` |\n| goals, OKRs, key results | `\u002Fgoals` |\n| \"who am I\", session identity, login state | `\u002Fhq-whoami` |\n\n- A company slug appearing as a word inside a bounded action does NOT upgrade the request to Company Mode — the bounded-action route wins. Example: `\u002Fstartwork open my DM on indigo` → route to `\u002Fdm` (the slug is context for the target skill, not a mode selector).\n- Negative example (the documented failure this rule exists for): `\u002Fstartwork open Izzy's latest project DM` → route to `\u002Fdm` and stop. Full company orientation for this request is a scope bug, not thoroughness.\n- Fall-through: if the argument is a bare company\u002Fproject\u002Frepo name, or names orientation itself (\"what's the state of X\", \"pick up X\", \"start on X\", \"what should I work on\"), this rule does not apply — continue to §1.1 Mode resolution.\n\nThis rule exists because a bounded read-only request (\"open Izzy's latest project DM\") was observed expanding into full company orientation, duplicate policy ingestion, a background maintenance agent, and an unrequested session handoff. Runtimes that follow skill text literally (Codex) must find the fast path in the text itself.\n\n**1.1 Mode resolution** (only if no short-circuit fired):\n\nDetermine mode from the user's argument (first match wins):\n\n- **No arg \u002F empty** — Entry-gate mode (ask before loading context — see \"Entry-Gate Mode\" below)\n- **Arg matches company slug** in `companies\u002Fmanifest.yaml` — Company mode\n- **Arg is a company alias or a repo name** — run `bash core\u002Fscripts\u002Fstartwork-context.sh resolve --arg \"{arg}\"`. `via: slug|alias` → Company mode for that company; `via: repo` → Company mode with the repo noted for git state. Exit 3 means no match: continue below. Never grep the manifest by hand to find out which company an argument belongs to.\n- **Arg matches a directory** in `personal\u002Fprojects\u002F` (not `_archive\u002F`) or `companies\u002F*\u002Fprojects\u002F` — Project mode\n- **Arg matches a directory** in `repos\u002Fprivate\u002F` or `repos\u002Fpublic\u002F` — Repo mode\n- **Partial match** — arg is a substring of any company slug, project dir, or repo name. 1 match: use that mode. 2-5 matches: present numbered list, wait for user to pick. >5: ask user to be more specific\n- **Free-text task** — arg is ≥3 words and doesn't match any company\u002Fproject\u002Frepo\u002Fpartial → Task mode\n- **No match** — ask user to clarify\n\n### 1.2 Bind a resolved company before gathering mode context\n\nAs soon as normal mode resolution or the default-company fallback identifies a\ncompany, bind it on this session before running project scans, `qmd`, worker\nselection, or any repository command. Use the one `orient` call from the fast\npath, with the resolved mode (and the project in Project mode). It is the only\nbind call: it does the trusted bind, records the mode, and prints the\ncapability block with the Board line and the last-thread line.\n\n```bash\nbash core\u002Fscripts\u002Fstartwork-context.sh orient --company \"{co}\" --mode \"{Company|Project|Repo|Task|Resume}\" [--project \"{name}\"]\n```\n\nSession metadata writes require the caller’s harness session identity. If the host does not supply it, pass the exact `--session-id` shown by the scope hook; never select a write target from `workspace\u002Fsessions\u002F.current` or the most recent session.\n\nSkip this step when the fast path already ran `orient` for `{co}`.\n\nFor Project or Repo mode, first resolve the project's owning company or the\nrepo's company mapping when it is not already known, then run this bind before\nany Git command or project scan. A bounded-action short-circuit does not enter\nthis flow, and an unresolved or personal-only context has no company to bind.\nWhen a task id becomes available later, §2.4 adds it to the session.\n\n### 2. Gather Context\n\n#### Entry-Gate Mode (no arg)\n\n**Do NOT eager-load context.** A naked `\u002Fstartwork` must ask the user where to go *before* reading the thread file, running the qmd\u002Fgrep project scan, or reading any prd.json. Only the cheap reads in step 1 are permitted before the gate.\n\n1. **Prefetch cross-device state (fail-soft).** Before reading `handoff.json`, pull the session continuity pointer from the personal vault so a `\u002Fhandoff` run on another machine is visible on this one. The workspace tree is otherwise machine-local; only `workspace\u002Fthreads\u002Fhandoff.json` plus the referenced thread file are carved into the personal vault (hq-cloud-sync `computeContinuityPointerPaths`). Without this pull a fresh session on a second device sees stale state.\n\n   ```bash\n   bash core\u002Fscripts\u002Fhandoff-sync-prefetch.sh\n   ```\n\n   The helper is fail-soft: missing-CLI, offline, logged-out, or lock-held hosts return within the timeout and leave the local pointer untouched. Treat its output as advisory — never block the entry gate on its exit status.\n\n   **Cheap peek.** If `workspace\u002Fthreads\u002Fhandoff.json` now exists, read it (small, allowed by context-diet) and extract only the last-session one-liner (its `summary` \u002F `conversation_summary` field) + referenced branch. Do NOT read the thread file it points to yet. If handoff.json is absent, skip — no last-session option.\n\n   Also glob `workspace\u002Fgates\u002Fpending\u002F*.json` (cheap, no file reads yet). If any exist, a paused workflow is waiting on human answers — note the count for the gate below. Spec: `core\u002Fknowledge\u002Fpublic\u002Fhq-core\u002Fworkflow-gates-spec.md`.\n\n2. **Ask the user (AskUserQuestion), one question, then wait.** Present these options:\n   - **Answer waiting workflow questions ({N})** — only if step 1 found pending gates. A paused workflow resumes the moment these are answered, so list this option FIRST.\n   - **Resume last session** — only if step 1 found a handoff; label it with the one-liner (e.g. *\"Resume: {summary}\"*).\n   - **Pick a company \u002F project \u002F repo** — user names the target; you then re-enter this skill in the matching mode (Company \u002F Project \u002F Repo) with that arg.\n   - **Not sure what to work on** — route to `\u002Fstrategize` (strategic prioritization). Announce the handoff and load `.claude\u002Fskills\u002Fstrategize\u002FSKILL.md`. Do not do project discovery here.\n   - **Something else** — free-text; user describes intent → treat as Task mode.\n\n   Do not present numbered markdown for this gate — use the structured picker. This is the whole point of the gate: no `qmd search \"prd.json\"`, no thread-file read, no per-project prd.json reads happen until the user has chosen.\n\n3. **After the pick, load only what that path needs:**\n   - *Resume last session* → before reading the thread file, resolve `thread_id` from `handoff.json.last_thread` and apply the same resume-lock confirmation procedure from `\u002Fresumework` Step 2. Run `bash core\u002Fscripts\u002Fhq-session.sh current` to obtain the session id, then `bash core\u002Fscripts\u002Fresume-thread-lock.sh inspect \"{thread_id}\"`. On `unlocked`, acquire the marker with `bash core\u002Fscripts\u002Fresume-thread-lock.sh acquire \"{thread_id}\" --session-id \"{session_id}\"`. On `locked` or `stale`, use AskUserQuestion with the returned `prompt` and stop on cancel; only after **Re-resume anyway** run `bash core\u002Fscripts\u002Fresume-thread-lock.sh acquire \"{thread_id}\" --replace --expected-generation \"{lock_generation from inspected JSON}\" --session-id \"{session_id}\"`. If replacement exits `4`, re-inspect and ask again because a newer marker replaced the one the user confirmed. Then, and only then, read the thread file handoff.json points to (extract `conversation_summary`, `next_steps`, `git.branch`, `git.current_commit`, `git.dirty`, `files_touched`); run `git log --oneline -3`; if the thread references a `project_dir`, read its most-recent journal file (frontmatter + `## Open threads` only — see Project Mode step 4). Skip the global qmd\u002Fgrep project scan unless the user then asks \"what else is active?\".\n\n   - *Answer waiting workflow questions* → for each pending gate, oldest first: read its JSON (question, options, context, recommended), ask ONE AskUserQuestion per gate (options from the gate file, recommended first, plus a \"Skip this gate\" option), and on an answer run `bash core\u002Fscripts\u002Fworkflow-gate.sh answer {id} \"{choice}\"` (add `--notes` if the user typed free text). Skipped gates stay pending. When done, re-present this entry gate so the user can pick where to work.\n   - *Pick company\u002Fproject\u002Frepo* → proceed via the corresponding mode's Gather Context section with the supplied arg.\n   - *Not sure* → `\u002Fstrategize` owns it from here; stop gathering.\n   - *Something else* → Task Mode gather.\n\nOnce the chosen path has enough context to name the work, name or rename this\nsession with `set_session_title` according to\n`core\u002Fpolicies\u002Fhq-session-title-grammar.md`. When resuming, carry forward the\nuseful work subject from the predecessor summary; otherwise use the resolved\ntarget. Add company, product, or mode when it adds information. Rename again\nonly when the subject changes, and preserve a title the user manually renamed.\nIf the first-turn title hook already named this session for the same subject,\nkeep that title and make no title call.\n\n#### Company Mode (arg = company slug)\n\n1. The `orient` call (fast path or §1.2) already printed the capability block: no network, about 3 KB. It carries the company's repos, knowledge and source folders, the cached list of usable integrations with the flag for each, the five most recently touched projects with local open-story counts, the Board line, the company's workers, and the path of the skill intent index. Do not grep the manifest, run the qmd\u002Fgrep project scan, read `core\u002Fworkers\u002Fregistry.yaml`, or run git over the first manifest repo by hand; the block replaces those reads (HP-12 traced every one of them as a lookup startwork should have answered).\n2. The `Last thread:` line from `orient` is the handoff check, already filtered to this company. Do not read `workspace\u002Fthreads\u002Fhandoff.json` yourself.\n3. Board status comes from the work mesh, never local prd.passes. For each matching project, load the live Board from cache \u002F Desktop live read: `orient` already did the cache read, and the block's `Board (work mesh cache):` line has the queued \u002F in progress \u002F review \u002F done counts and the next queued story for each listed project, from this company's cache only. Do not read the cache files one by one. A project marked `no board` has no cache entry. If the Board block is absent, use local prd only for project description and acceptance; never as live Board columns. The Projects line's open counts are local too.\n   - `queued` = available next work\n   - `in_progress` \u002F `review` = already claimed; do not offer as free next work\n   - `done` = done\n   Summarize the company totals from the Board line.\n4. If the block's Integrations line reads \"not cached\", run `bash core\u002Fscripts\u002Fusable-integrations.sh show --company {co}` once. That is the only network call startwork may make, and it is skipped when the cache is fresh\n5. Git state only for a repo the user named (or the `via: repo` resolution in §1.1): `git -C {repo} branch --show-current` and `git -C {repo} log --oneline -3`\n6. For that same repo, run `bash core\u002Fscripts\u002Fstartwork-context.sh edit-target --repo \"{repo}\"` and show its lines in the orientation block (see \"Edit target\" below).\n#### Project Mode (arg = project name)\n\nBoard status comes from the work mesh, never local prd.passes. If ground\u002Fcheck and the project-view cache both fail, then and only then use local prd for description — still not as live Board columns.\n\n1. Resolve the project dir (`personal\u002Fprojects\u002F{name}` or `companies\u002F{co}\u002Fprojects\u002F{name}`); when the path is under `companies\u002F{co}`, bind that company now. Read `prd.json` only for `name`, `description`, `branchName`, and acceptance text — not story status.\n2. Extract `metadata.repoPath` — identify company by matching against manifest repos if the project path did not identify it (`bash core\u002Fscripts\u002Fstartwork-context.sh resolve --arg \"{repo basename}\"`). Bind the resolved company before continuing.\n2b. Once `{co}` is known, bind and render in one call: `bash core\u002Fscripts\u002Fstartwork-context.sh orient --company \"{co}\" --mode Project --project \"{name}\"` (this is the §1.2 bind; do not run it twice). The block's last line carries the project goal and branch; the rest is the company context from Company Mode step 1. When the fast path already bound `{co}` and only the project is new, run `bash core\u002Fscripts\u002Fstartwork-context.sh block --company \"{co}\" --project \"{name}\"` and record the project with §2.4.\n3. If repoPath exists: `git -C {repoPath} branch --show-current` and `git -C {repoPath} status --short`, then `bash core\u002Fscripts\u002Fstartwork-context.sh edit-target --repo \"{repoPath}\"` for the orientation block's \"Edit target\" lines\n4. If company `{co}` is resolved, load the live Board from cache \u002F Desktop live read (presence is automatic via `hq mesh daemon`). Prefer `~\u002F.hq\u002Fwork-mesh\u002Fcache\u002Fprojects\u002F{companyUid}\u002F{projectId}.json` when present. Do not call deleted `hq mesh session ground|check|watch`.\n   - `queued` = available next work\n   - `in_progress` \u002F `review` = already claimed; do not offer as free next work\n   - `done` = done\n   Include active mesh thread owners\u002Fblockers in the orientation block when available. Session presence is automatic — do not mint cards during orientation.\n5. **Read session journals** (spec: `core\u002Fknowledge\u002Fpublic\u002Fhq-core\u002Fjournal-spec.md`). If `{project_dir}\u002Fjournal\u002F` exists:\n   - `ls -t {project_dir}\u002Fjournal\u002F*.md 2>\u002Fdev\u002Fnull | head -2` — most recent 2 files\n   - For each: read frontmatter (`status`, `summary`) + `## Open threads` section only — skip `## Auto-capture` (reference material, too noisy for orientation)\n   - If most-recent file has `status: active` and mtime > 24h, treat as abandoned (visually flag in orientation block)\n   - Surface in orientation: latest file's `summary` + any unresolved `## Open threads` bullets\n\n#### Task Mode (arg = free-text task description)\n\n1. Resolve company\u002Frepo from cwd or recent handoff context (read `workspace\u002Fthreads\u002Fhandoff.json` if exists)\n   - If a company is found, immediately bind it with the §1.2 call, `bash core\u002Fscripts\u002Fstartwork-context.sh orient --company \"{co}\" --mode Task`, before task classification or company-specific context reads.\n2. Classify task using inline pattern table:\n   - DB\u002Fmigration\u002Fschema\u002Fprisma → `schema_change`\n   - API\u002Fendpoint\u002Froute\u002Fwebhook → `api_development`\n   - Component\u002Fpage\u002FUI\u002Fform\u002FReact → `ui_component`\n   - Backend + frontend indicators combined → `full_stack`\n   - Content\u002Fcopy\u002Fdocs\u002Fmarketing → `content`\n   - Design\u002Fvisual\u002Fbrand → `design`\n   - Deploy\u002FCI\u002Finfra → `ops`\n   - Otherwise → `enhancement`\n3. Map to worker pipeline (same sequences as `\u002Fprd` command Step 5)\n4. If company resolved, check company-specific workers in manifest — prefer over generic\n\n#### Repo Mode (arg = repo directory name)\n\n1. Resolve full path: check `repos\u002Fprivate\u002F{arg}` then `repos\u002Fpublic\u002F{arg}`\n2. Owning company: scan `companies\u002Fmanifest.yaml` for a company whose `repos:` list contains this path, then bind it before repository commands\n3. Git state: `git -C {repoPath} branch --show-current`, `git -C {repoPath} log --oneline -5`, `git -C {repoPath} status --short`\n3b. Edit target: `bash core\u002Fscripts\u002Fstartwork-context.sh edit-target --repo \"{repoPath}\"`. Show its lines in the orientation block. Write and Edit are blocked under `repos\u002F`, so do not create a branch in the main checkout; run the printed `worktree.sh` command before the first edit.\n4. Related projects:\n   - Primary: `qmd search \"{repo-name} prd.json\" --json -n 10` via shell\n   - Fallback: use Grep to find prd.json files referencing this repo\n   - For each match (max 5), read the prd.json and extract `name` + count incomplete stories\n\n### 2.4 Persist Session Metadata\n\nThe `orient` call in §1.2 (or the fast path) already wrote company, mode and,\nin Project mode, the project into the current session's metadata, so\nper-company hooks and other context-aware skills can find them. Do not repeat\nit. Only add what `orient` could not know, in one call when there is anything:\n\n```bash\n# A project or task found after orient ran (one call, both flags when known):\nbash core\u002Fscripts\u002Fwork-mesh-live-bind-trusted.sh \\\n  --company \"{co}\" --project \"{project_name}\" --task \"{task_id}\"\n# Repo mode only:\nbash core\u002Fscripts\u002Fhq-session.sh set repo \"{repo_name}\"\n```\n\nThis file lives at `workspace\u002Fsessions\u002F\u003Csession_id>\u002Fmeta.yaml`. The current\nsession_id is bootstrapped by `.claude\u002Fhooks\u002Fmaster-hook.sh` on the first\nhook event of every session and tracked in `workspace\u002Fsessions\u002F.current`.\n\n**Important:** until `company_slug` is set, the master hook runs no\nper-company hooks (fail-closed for tenant isolation). Setting it from\nstartwork is what activates the per-company harness for the rest of the\nsession.\n\n**Skip if:** no company resolved (resume mode with no company context).\n\n### 2.5 Report Applicable Policies (display-only — no policy re-reads)\n\nPolicy loading is NOT this skill's job. Two mechanisms already inject policies before this step runs:\n\n1. **Company policies**: surfaced automatically when `orient` (§1.2 or the fast path) binds the company — the bind emits the company's hard-enforcement rules (deduped and budgeted) directly into the tool result. Do NOT re-scan `companies\u002F{co}\u002Fpolicies\u002F` frontmatter here; that duplicates the bind emission.\n2. **Repo policies**: if repo context resolved and `{repoPath}\u002F.claude\u002Fpolicies\u002F` exists, collect its files except `example-policy.md`, preserve their order, and split the stable file order into consecutive chunks of at most 40 files. For each chunk, run `bash core\u002Fscripts\u002Fread-policy-frontmatter.sh {file1} {file2} ...` once with each path as a separate argument. Keep each call under 30 KB of output. The first output block belongs to the chunk’s first file argument; each later block belongs to the path named by its preceding `# --- policy-file: \u003Cpath> ---` separator. This is the one scan this step still owns; repo policies are not covered by the company bind.\n3. **Global policies**: injected by the SessionStart\u002FPreToolUse trigger hook (`inject-policy-on-trigger.sh`). No action here.\n\nDisplay in orientation block (counts only — `ls | wc -l` is enough for N\u002FK):\n```\nPolicies: {N} company, {M} repo, {K} global ({H} hard-enforcement)\n```\n\nRules:\n- This step performs no company-policy file reads. The bind emission from `orient` is the company-policy surface\n- Repo policies: frontmatter only; for repo hard-enforcement policies read the `## Rule` section\n- If no company resolved (resume mode with no company context), the count line may omit company\n- Precedence: company > repo > global\n\n### 2.6 Worker Routing & Skill Readiness\n\nAfter policies are known, build a compact Worker Packet for the resolved context.\n\n1. When a company is resolved, the capability block's Workers line is the candidate list; do not re-read `core\u002Fworkers\u002Fregistry.yaml` for it. Read the registry (auto-generated read-only index) only in task mode without a company, or to map an intent onto public workers, and keep only entries relevant to the current company, project, repo, or task intent. Skip any entry whose `path` is not a directory containing `worker.yaml`. If an active company worker is listed but missing, say so in the orientation block — do not invent a raw-script fallback.\n2. If company `{co}` is resolved, include any registry entries whose `company:` field is `{co}` (sourced from `worker.company` in each `worker.yaml`) or whose path starts with `companies\u002F{co}\u002Fworkers\u002F`.\n3. If project mode and `prd.json` story metadata includes declared workers or worker hints, include those first.\n4. If task mode, map the classified intent to a worker route before offering direct execution:\n   - `design`, `ui_component` → design\u002Ffrontend workers\n   - `content` → content workers\n   - `ops`, deploy\u002FCI\u002Finfrastructure → ops\u002Fdeploy workers\n   - `api_development`, `schema_change`, `full_stack`, `enhancement` → implementation workers plus QA\u002Freview workers when available\n5. Do not read every worker.yaml. Read a worker.yaml only when:\n   - it is the selected\u002Frecommended worker, or\n   - you need its skill list to present a concrete option.\n\nDisplay in orientation block:\n```\nWorker route: {primary worker\u002Fskill or \"none matched\"} ({N} candidates)\n```\n\nRules:\n- Worker-backed paths should appear before direct parent-session execution whenever a relevant worker exists.\n- Direct execution remains available, but label it as direct\u002Fno-worker so the user can make an informed choice.\n- If no worker matches, say so and proceed normally.\n- If the selected path needs worker execution, route through `\u002Frun {worker} {skill}` or `\u002Fexecute-task` rather than reimplementing the worker inline.\n\n### 3. Present Options\n\nDisplay a concise orientation block:\n\n```\nSession Start\n--------------\n{Mode: Resume | Company: {slug} | Project: {name}}\n{\u003Cstartwork-context> block, verbatim, whenever a company is resolved}\n\n{If resume: \"Last session: {summary}\" + \"Next steps: {next_steps with status: open}\" + \"Still open from earlier handoffs: {bash core\u002Fscripts\u002Fhandoff-open-steps.sh list --limit 10, excluding this thread}\"; any delegation manifest under workspace\u002Fdelegations\u002F still at status `sent` gets `bash core\u002Fscripts\u002Fhq-delegate-pickup.sh --manifest \u003Cm> --check` and its result shown as verified \u002F waiting \u002F FAILED}\n{If project: \"Goal: {description}\" + \"Branch: {branchName}\"}\n{If repo: \"Repo: {repoPath}\" + \"Company: {slug}\" + \"Branch: {branch}\"}\n{If a repo was resolved (Repo mode, `via: repo`, or a project repoPath): the `edit-target` lines verbatim, so the worktree command is on screen before any work starts}\n{If task: \"Task: {description}\" + \"Intent: {classified_intent}\" + \"Pipeline: {worker count} workers\"}\n\nGit: {branch} @ {short-hash} {\" (dirty)\" if dirty}\nWorker route: {primary worker\u002Fskill or \"none matched\"} ({N} candidates)\n\nActive work:\n  - {project} -- {done}\u002F{total} stories ({remaining} left)\n  ...\n\nBoard (work mesh):\n  - {id} {title} — {status}\n  ...\nWork mesh threads:\n  {active mesh owners\u002Fblockers for the selected company\u002Fproject, or omit if none\u002Funavailable}\n```\n\nThen present numbered options built from context:\n\n- **Entry-gate mode (no arg)**: no orientation block is rendered before the gate — the AskUserQuestion gate (Gather Context → Entry-Gate Mode step 2) *is* the first interaction. Render an orientation block only *after* the user picks \"Resume last session\", using the loaded thread context; then offer next_steps items (up to 3) + \"Pick a project\" + \"Something else\".\n- **Company mode**: worker-recommended next actions + active projects for that company (up to 3) + \"Run a worker\" + \"Something else\"\n- **Project mode**: top 3 **queued** Board stories from work-mesh `stories[]` via `\u002Fexecute-task` + matching worker route + \"Something else\". Skip `in_progress` unless the user already owns that row.\n- **Repo mode**: related projects with incomplete work (up to 3) + \"Open repo (no project)\" + \"Something else\"\n- **Task mode**: proposed worker pipeline phases (up to 5) + \"Run this worker pipeline\" + \"Modify pipeline\" + \"Do it directly (no worker)\" + \"Plan it with \u002Fprd (send \u002Fprd as its own message)\" + \"Something else\"\n\nOutput the numbered list and wait for user input. When an option starts another skill, phrase it as the skill name for the user to send as its own message (for example \"send `\u002Fdeep-plan {co} {description}` as a new message\"). Never suggest a message that chains two slash commands, such as `\u002Fstartwork {co} \u002Fdeep-plan ...`: the desktop app refuses to send it. If the user picks such an option by number, run the skill in this session instead of asking them to type it. After user picks, proceed directly into the work.\n\n## Rules\n\n- NEVER read INDEX.md, agents files, or company knowledge dirs during startup\n- NEVER run exploratory searches to orient — this skill replaces exploration with targeted reads\n- NEVER grep the manifest, list project directories, or read the worker registry by hand when `core\u002Fscripts\u002Fstartwork-context.sh block` can answer; one script call replaces those reads\n- The capability block reads only the bound company. Never render it for a second company in the same session to compare; that is a tenant-isolation bug\n- A bounded single-action request (§1.0b table) routes to its owning skill and never triggers orientation loading, session-metadata writes, policy scans, worker routing, or background maintenance\n- NEVER spawn a background knowledge-pulse (or any maintenance agent) from startup. The pulse is spawned only by the planning skills (`\u002Fbrainstorm`, `\u002Fprd`, `\u002Fdeep-plan`) — interactive startup spawns zero agents\n- Max file reads: handoff.json + 1 thread + manifest + up to 5 prd.json (headers only) + up to 2 journal files per resolved project (frontmatter + Open threads section only — never load Auto-capture)\n- If >5 active projects found, show top 5 by most recent file modification\n- Always verify git branch with `git branch --show-current` before displaying git state\n- Context diet: every read must serve the orientation summary. No speculative loading\n- Naked `\u002Fstartwork` (no arg) MUST hit the entry gate first — ask via AskUserQuestion before reading the thread file or running any project scan. The only pre-gate read allowed is handoff.json itself (one-liner peek)\n- If the user is unsure what to work on, route them to `\u002Fstrategize` rather than doing eager project discovery\n- If handoff.json doesn't exist, skip the \"Resume last session\" option — the gate still asks (pick target \u002F not sure \u002F something else)\n- Use `qmd search` via shell command — if qmd unavailable, fall back to Grep to scan for prd.json files\n- Before specialized work, prefer the relevant worker route surfaced by the Worker Packet\n",{"name":5,"description":7,"allowed-tools":43},"Read, Grep, Glob, Bash(git:*), Bash(qmd:*), Bash(ls:*), Bash(core\u002Fscripts\u002Fhq-session.sh:*), Bash(hq:*), Bash(bash core\u002Fscripts\u002Fresume-thread-lock.sh:*), Bash(bash core\u002Fscripts\u002Fwork-mesh-live-bind-trusted.sh:*), Bash(bash core\u002Fscripts\u002Fresolve-company.sh:*), Bash, AskUserQuestion, Bash(bash core\u002Fscripts\u002Fread-policy-frontmatter.sh:*), Bash(bash core\u002Fscripts\u002Fhandoff-sync-prefetch.sh:*), Bash(bash core\u002Fscripts\u002Fstartwork-context.sh:*)","main","205cf61728a27ef15e9153aa38df5856fc8d82f5",".claude\u002Fskills\u002Fstartwork",18,"https:\u002F\u002Fgithub.com\u002Findigoai-us\u002Fhq-core","https:\u002F\u002Fgithub.com\u002Findigoai-us","https:\u002F\u002Fhqforwork.com\u002F","The AI Context Layer for Teams","2026-11-12 04:18:19",{"source":8,"skillName":5,"commands":54,"prompt":64,"zipAvailable":65},[55,58,61],{"tool":56,"command":57},"npx","npx skills add indigoai-us\u002Fhq-core --skill startwork",{"tool":59,"command":60},"bunx","bunx skills add indigoai-us\u002Fhq-core --skill startwork",{"tool":62,"command":63},"pnpm","pnpm dlx skills add indigoai-us\u002Fhq-core --skill startwork","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Findigoai-us\u002Fhq-core\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fstartwork\u002FSKILL.md",true,[67],{"path":68,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":71,"sourceHtmlUrl":72},"agents\u002Fopenai.yaml","REFERENCE","参考文档",111,"https:\u002F\u002Fgithub.com\u002Findigoai-us\u002Fhq-core\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fstartwork\u002Fagents\u002Fopenai.yaml",[74,94,124,144,155,165],{"skillNo":75,"name":76,"nameZh":6,"description":77,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":78,"categories":79,"keywords":80,"publishedAt":38},"01M71E4MQ04WPK1EVDS7VKJ3E8","social-graphic","Generate 1080x1080 HTML social graphics for HQ update posts.","https:\u002F\u002Fgithub.com\u002Findigoai-us\u002Fhq-core\u002Fblob\u002Fmain\u002Fcore\u002Fworkers\u002Fpublic\u002Fsocial-strategist\u002Fskills\u002Fsocial-graphic\u002FSKILL.md",[],[81,82,32,83,84,85,26,86,87,88,89,90,91,92,93],"social","social graphic","html","edit","write","update","generate","graphics","browser","open","agent-browser","for","posts",{"skillNo":95,"name":91,"nameZh":6,"description":96,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":97,"categories":98,"keywords":107,"publishedAt":38},"01M71E4H33K4P5H5M7ENPTMFSC","Browser automation CLI for AI agents. Use when the user needs to interact with websites, including navigating pages, filling forms, clicking buttons, taking screenshots, extracting data, testing web apps, or automating any browser task. Triggers include requests to \"open a website\", \"fill out a form\", \"click a button\", \"take a screenshot\", \"scrape data from a page\", \"test this web app\", \"login to a site\", \"automate browser actions\", or any task requiring programmatic web interaction.","https:\u002F\u002Fgithub.com\u002Findigoai-us\u002Fhq-core\u002Fblob\u002Fmain\u002Fcore\u002Fworkers\u002Fpublic\u002Fqa-tester\u002Fskills\u002Fagent-browser\u002FSKILL.md",[99,104],{"categoryNo":100,"categoryName":101,"taxonomyType":102,"taxonomyTypeDesc":103},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":105,"categoryName":106,"taxonomyType":102,"taxonomyTypeDesc":103},"01JBSEEDCAT000000000000023","Skill与智能体开发",[108,89,109,110,111,112,32,113,114,115,116,117,90,118,91,119,120,121,122,123],"agent browser","click","ai agents","app","scrape","when","apps","actions","extracting","take a screenshot","testing","programmatic","browser automation","website","cli","interaction",{"skillNo":125,"name":126,"nameZh":6,"description":127,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":128,"categories":129,"keywords":130,"publishedAt":38},"01M71E4FDBD7J8Y45JJ9KMMYGN","work-mesh","Work Mesh Live — automatic presence via hq mesh daemon; context reconcile\u002Forganize; manual session task-status, blocked, and note only.","https:\u002F\u002Fgithub.com\u002Findigoai-us\u002Fhq-core\u002Fblob\u002Fmain\u002Fcore\u002Fskills\u002Fwork-mesh\u002FSKILL.md",[],[131,30,35,32,132,21,133,23,134,135,136,137,138,139,26,140,141,142,143],"work mesh","status","note","presence","automatic","reconcile","only","organize","task","session","manual","daemon","via",{"skillNo":145,"name":146,"nameZh":6,"description":147,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":148,"categories":149,"keywords":150,"publishedAt":38},"01M71E4EGHNAAGWAPV6KGBMQ9W","review","Parity worker review skill (materialization fixture).","https:\u002F\u002Fgithub.com\u002Findigoai-us\u002Fhq-core\u002Fblob\u002Fmain\u002Fcore\u002Fscripts\u002Ftests\u002Ffixtures\u002Fagent-session\u002Fworker-materialization\u002Fparity-worker\u002Fskills\u002Freview\u002FSKILL.md",[],[146,151,152,153,154],"review skill","fixture","parity","worker",{"skillNo":156,"name":157,"nameZh":6,"description":158,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":159,"categories":160,"keywords":161,"publishedAt":38},"01M71E4D1FZDJPDC15DRERKX8Y","run","Run or list HQ workers (parity fixture).","https:\u002F\u002Fgithub.com\u002Findigoai-us\u002Fhq-core\u002Fblob\u002Fmain\u002Fcore\u002Fscripts\u002Ftests\u002Ffixtures\u002Fagent-session\u002Fskills\u002Frun\u002FSKILL.md",[],[157,162,163,153,164,152],"parity fixture","workers","list",{"skillNo":166,"name":20,"nameZh":6,"description":167,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":168,"categories":169,"keywords":170,"publishedAt":38},"01M71E4BF4MV5SEWZJZ4T1QPQW","Preserve session state for a follow-up agent (parity fixture).","https:\u002F\u002Fgithub.com\u002Findigoai-us\u002Fhq-core\u002Fblob\u002Fmain\u002Fcore\u002Fscripts\u002Ftests\u002Ffixtures\u002Fagent-session\u002Fskills\u002Fhandoff\u002FSKILL.md",[],[20,162,171,172,140,173,92,153,174,175,152],"up","preserve","session state","follow-up","state"]