[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6H84MSFHBM0K1Y568RZP9M8":3,"skill-same:01M6H84MSFHBM0K1Y568RZP9M8":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":40,"linkOnly":41,"markdownContent":42,"markdownBody":43,"frontMatter":44,"refName":45,"commitSha":46,"skillDirectory":47,"forksCount":14,"repositoryHtmlUrl":48,"repositoryHomepageUrl":6,"ownerHtmlUrl":49,"ownerBlogUrl":50,"ownerDescription":51,"updatedAt":52,"install":53,"resources":66},"01M6H84MSFHBM0K1Y568RZP9M8","subagent-creator",null,"Designs a lean Claude Code subagent, or widens one on request. Use when the user wants to create, scope or audit a subagent or custom agent, or asks to give an existing one more tools, turns or access. Grills on whether it earns its place before writing anything. Not for writing skills.","O-Marsters-1997\u002Fmy-claude-code","O-Marsters-1997","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F72571979?v=4","01M6H800V7V9BSXYZKDM0JXTJ2","Olly Marsters","01M6H800ZYDJR42TNRH0E6ZVZ7",0,"MIT","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fmeta\u002Fsubagent-creator\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39],"creator","subagent","subagent creator","use","when","request","custom","Existing","for","more","it","scope","writing","lean","user","access","Tools","writing skills","audit","code","create","2026-11-10 10:12:30",false,"---\nname: subagent-creator\ndescription: >\n  Designs a lean Claude Code subagent, or widens one on request. Use when the user wants to\n  create, scope or audit a subagent or custom agent, or asks to give an existing one more\n  tools, turns or access. Grills on whether it earns its place before writing anything. Not\n  for writing skills.\n---\n\n# Subagent creator\n\nA subagent is a context firewall with a tool budget: worth having when it keeps noise out of\nthe parent, enforces a restriction, or runs independent work in parallel. It is not a persona.\nThis skill grills first and writes the smallest definition that does the job. It never widens\nan agent on its own initiative: scope grows only when the user asks, and only with evidence.\n\nThree modes. Pick from the user's words:\n\n- **create** (default): grill, write, check.\n- **expand `\u003Cname>`**: only when the user asks. Widen the agent by the smallest step.\n- **audit `\u003Cname>|all`**: check existing agents and report what to cut.\n\n## The rules\n\nEach is enforced in the grill, the template, or the step 4 checklist.\n\n1. **Earn it.** A subagent needs one of four reasons: verbose output the parent doesn't need,\n   an enforced tool restriction, self-contained work that returns a summary, or independent\n   parallel work. No reason means it belongs in the main thread, a skill, a hook or a script.\n2. **Code owns control flow.** Fixed steps (lint, push, label, run CI) are scripts or hooks.\n   The agent covers only the open-ended step.\n3. **Smallest box.** An explicit `tools:` allowlist, read-only by default, MCP servers scoped\n   inline, never inherited wholesale. Every visible tool is a decision the agent can get wrong.\n4. **Single writer.** An agent that writes owns its files and runs in `isolation: worktree`.\n   Reviewers, diagnosers and researchers don't write.\n5. **Fresh means blind.** A fresh agent knows only its prompt and the brief. Say what the brief\n   carries. If it really needs the whole conversation, use a fork instead of a custom agent.\n6. **Artifacts, not transcripts.** The agent returns a short, fixed-format result or a file path.\n7. **Bounded.** `maxTurns` is always set. Use a cheaper model only for bounded, checkable work,\n   never for work that must judge its own limits.\n8. **Few hops.** A chain of more than four agent-to-agent handoffs fails. Split by phase, not\n   by domain.\n9. **Enforce, don't ask.** A rule that matters is a hook or a tool restriction, not a sentence\n   in the prompt.\n10. **Ask, don't improvise.** When the agent hits its scope, it stops and returns a\n    `SCOPE_REQUEST`. That request is the only way scope grows.\n\n## Create\n\n### 1. Look before asking\n\nRead the existing agents in `agents\u002F` (if this repo syncs a top-level `agents\u002F` directory) or\n`.claude\u002Fagents\u002F`, plus `~\u002F.claude\u002Fagents\u002F`. Note any that already overlap the request. That is\na fact you look up yourself, never a question for the user.\n\n### 2. Grill\n\nInvoke the `grilling` skill and pass it this agenda. Work the value branch first. If the value\nbranch fails, recommend the alternative and stop: declining to create an agent is a good\noutcome of this skill.\n\n**Value branch**\n- Which of the four reasons applies? Push back on \"it's a specialist\" with no restriction or\n  isolation behind it.\n- Does an existing agent already do 90% of this? If so, widen that agent or branch inside its\n  prompt instead.\n- Is any of this fixed steps that a script or hook could own (rule 2)?\n- Would a skill (reusable knowledge in the parent context) or a fork (needs the conversation)\n  do better?\n\n**Scope branch**\n- The job in one sentence, plus what \"done\" looks like.\n- What the brief hands it, and what it must not assume it knows.\n- The output contract: format, length cap, or the file it writes.\n- Does it write? Default no. If yes, to which files, and confirm worktree isolation.\n- The smallest tool set that finishes the job. For Bash, which commands, and whether a\n  `PreToolUse` hook should hold it to them.\n- Turn budget and model tier.\n- Will it run in parallel with copies of itself? If so, who owns which files?\n\nRecommend the leanest answer on every question. Widening later is cheap through **expand**, so\nstart small. Don't offer extra tools or turns \"just in case\".\n\n### 3. Write\n\nCopy `assets\u002Fagent-template.md` into the agent directory as `\u003Cname>.md` and fill it in. Keep the\nbody under 40 lines. The description says when to delegate *and* when not to, because it is\nwhat the parent reads to decide.\n\n### 4. Check\n\nRead the finished file against this checklist and fix any failure before showing it:\n\n- `tools` is an explicit allowlist: no wildcard, no omission, and nothing the job doesn't use.\n- `maxTurns` is set.\n- Write tools appear only with `isolation: worktree`.\n- Open `Bash` is held by a `PreToolUse` hook, or justified.\n- The body has an `## Output` section with a fixed format or file path.\n- The body tells the agent to reply `SCOPE_REQUEST: \u003Cwhat> — \u003Cwhy>` when blocked.\n- The description says when to delegate and when not to.\n- No template placeholders remain, and the body is under 40 lines.\n\nShow the user the final file and the grill answer behind each field.\n\n## Expand\n\nRun this only when the user asks to widen an agent. Never propose it unprompted, and never\nwiden an agent as a side effect of another task. A `SCOPE_REQUEST` is a report to the user,\nnot permission to act on it.\n\n1. **Get the evidence.** A `SCOPE_REQUEST` the agent returned, a denied tool call, a\n   `maxTurns` cut-off, or a result that was wrong because the agent lacked access. \"It might\n   need it\" is not evidence. Ask for the run, or find it in the transcript.\n2. **Take the smallest step that fixes the observed failure**, trying these in order:\n   - a better brief or preloaded skill (the agent lacked knowledge, not access)\n   - a narrower tool form: one MCP tool instead of a whole server, `Bash` behind a hook\n     allowlist instead of open `Bash`\n   - one more tool\n   - a higher `maxTurns`, in steps of about 50%\n   - write access, which also brings `isolation: worktree` and a named file set\n   - a stronger model\n3. **If the need is wider than the job**, the agent's scope was wrong. Split it into a second\n   agent rather than widening the first.\n4. **Re-run the step 4 checklist**, then commit with a message that names the evidence:\n   `agent(\u003Cname>): allow Bash(go test *) — SCOPE_REQUEST in run on #142`. Git history is the\n   scope ledger, so the agent's prompt stays lean.\n\n## Audit\n\nRead each agent in `agents\u002F` and `.claude\u002Fagents\u002F` and run the step 4 checklist on it. Also\nreport what a checklist can't see: no clear reason to exist under rule 1, overlap with another\nagent, or tools never used in practice. Propose cuts, not additions.\n","# Subagent creator\n\nA subagent is a context firewall with a tool budget: worth having when it keeps noise out of\nthe parent, enforces a restriction, or runs independent work in parallel. It is not a persona.\nThis skill grills first and writes the smallest definition that does the job. It never widens\nan agent on its own initiative: scope grows only when the user asks, and only with evidence.\n\nThree modes. Pick from the user's words:\n\n- **create** (default): grill, write, check.\n- **expand `\u003Cname>`**: only when the user asks. Widen the agent by the smallest step.\n- **audit `\u003Cname>|all`**: check existing agents and report what to cut.\n\n## The rules\n\nEach is enforced in the grill, the template, or the step 4 checklist.\n\n1. **Earn it.** A subagent needs one of four reasons: verbose output the parent doesn't need,\n   an enforced tool restriction, self-contained work that returns a summary, or independent\n   parallel work. No reason means it belongs in the main thread, a skill, a hook or a script.\n2. **Code owns control flow.** Fixed steps (lint, push, label, run CI) are scripts or hooks.\n   The agent covers only the open-ended step.\n3. **Smallest box.** An explicit `tools:` allowlist, read-only by default, MCP servers scoped\n   inline, never inherited wholesale. Every visible tool is a decision the agent can get wrong.\n4. **Single writer.** An agent that writes owns its files and runs in `isolation: worktree`.\n   Reviewers, diagnosers and researchers don't write.\n5. **Fresh means blind.** A fresh agent knows only its prompt and the brief. Say what the brief\n   carries. If it really needs the whole conversation, use a fork instead of a custom agent.\n6. **Artifacts, not transcripts.** The agent returns a short, fixed-format result or a file path.\n7. **Bounded.** `maxTurns` is always set. Use a cheaper model only for bounded, checkable work,\n   never for work that must judge its own limits.\n8. **Few hops.** A chain of more than four agent-to-agent handoffs fails. Split by phase, not\n   by domain.\n9. **Enforce, don't ask.** A rule that matters is a hook or a tool restriction, not a sentence\n   in the prompt.\n10. **Ask, don't improvise.** When the agent hits its scope, it stops and returns a\n    `SCOPE_REQUEST`. That request is the only way scope grows.\n\n## Create\n\n### 1. Look before asking\n\nRead the existing agents in `agents\u002F` (if this repo syncs a top-level `agents\u002F` directory) or\n`.claude\u002Fagents\u002F`, plus `~\u002F.claude\u002Fagents\u002F`. Note any that already overlap the request. That is\na fact you look up yourself, never a question for the user.\n\n### 2. Grill\n\nInvoke the `grilling` skill and pass it this agenda. Work the value branch first. If the value\nbranch fails, recommend the alternative and stop: declining to create an agent is a good\noutcome of this skill.\n\n**Value branch**\n- Which of the four reasons applies? Push back on \"it's a specialist\" with no restriction or\n  isolation behind it.\n- Does an existing agent already do 90% of this? If so, widen that agent or branch inside its\n  prompt instead.\n- Is any of this fixed steps that a script or hook could own (rule 2)?\n- Would a skill (reusable knowledge in the parent context) or a fork (needs the conversation)\n  do better?\n\n**Scope branch**\n- The job in one sentence, plus what \"done\" looks like.\n- What the brief hands it, and what it must not assume it knows.\n- The output contract: format, length cap, or the file it writes.\n- Does it write? Default no. If yes, to which files, and confirm worktree isolation.\n- The smallest tool set that finishes the job. For Bash, which commands, and whether a\n  `PreToolUse` hook should hold it to them.\n- Turn budget and model tier.\n- Will it run in parallel with copies of itself? If so, who owns which files?\n\nRecommend the leanest answer on every question. Widening later is cheap through **expand**, so\nstart small. Don't offer extra tools or turns \"just in case\".\n\n### 3. Write\n\nCopy `assets\u002Fagent-template.md` into the agent directory as `\u003Cname>.md` and fill it in. Keep the\nbody under 40 lines. The description says when to delegate *and* when not to, because it is\nwhat the parent reads to decide.\n\n### 4. Check\n\nRead the finished file against this checklist and fix any failure before showing it:\n\n- `tools` is an explicit allowlist: no wildcard, no omission, and nothing the job doesn't use.\n- `maxTurns` is set.\n- Write tools appear only with `isolation: worktree`.\n- Open `Bash` is held by a `PreToolUse` hook, or justified.\n- The body has an `## Output` section with a fixed format or file path.\n- The body tells the agent to reply `SCOPE_REQUEST: \u003Cwhat> — \u003Cwhy>` when blocked.\n- The description says when to delegate and when not to.\n- No template placeholders remain, and the body is under 40 lines.\n\nShow the user the final file and the grill answer behind each field.\n\n## Expand\n\nRun this only when the user asks to widen an agent. Never propose it unprompted, and never\nwiden an agent as a side effect of another task. A `SCOPE_REQUEST` is a report to the user,\nnot permission to act on it.\n\n1. **Get the evidence.** A `SCOPE_REQUEST` the agent returned, a denied tool call, a\n   `maxTurns` cut-off, or a result that was wrong because the agent lacked access. \"It might\n   need it\" is not evidence. Ask for the run, or find it in the transcript.\n2. **Take the smallest step that fixes the observed failure**, trying these in order:\n   - a better brief or preloaded skill (the agent lacked knowledge, not access)\n   - a narrower tool form: one MCP tool instead of a whole server, `Bash` behind a hook\n     allowlist instead of open `Bash`\n   - one more tool\n   - a higher `maxTurns`, in steps of about 50%\n   - write access, which also brings `isolation: worktree` and a named file set\n   - a stronger model\n3. **If the need is wider than the job**, the agent's scope was wrong. Split it into a second\n   agent rather than widening the first.\n4. **Re-run the step 4 checklist**, then commit with a message that names the evidence:\n   `agent(\u003Cname>): allow Bash(go test *) — SCOPE_REQUEST in run on #142`. Git history is the\n   scope ledger, so the agent's prompt stays lean.\n\n## Audit\n\nRead each agent in `agents\u002F` and `.claude\u002Fagents\u002F` and run the step 4 checklist on it. Also\nreport what a checklist can't see: no clear reason to exist under rule 1, overlap with another\nagent, or tools never used in practice. Propose cuts, not additions.\n",{"name":5,"description":7},"main","aede9f7bc29a2d9127fa7ce29682c242596c7759","skills\u002Fmeta\u002Fsubagent-creator","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997","https:\u002F\u002Fpersonal-portfolio-v2-phi.vercel.app","Go & TypeScript developer building tooling for AI-assisted development: git worktree workflows, Claude Code skills and agent orchestration.","2026-11-11 22:26:34",{"source":8,"skillName":5,"commands":54,"prompt":64,"zipAvailable":65},[55,58,61],{"tool":56,"command":57},"npx","npx skills add O-Marsters-1997\u002Fmy-claude-code --skill subagent-creator",{"tool":59,"command":60},"bunx","bunx skills add O-Marsters-1997\u002Fmy-claude-code --skill subagent-creator",{"tool":62,"command":63},"pnpm","pnpm dlx skills add O-Marsters-1997\u002Fmy-claude-code --skill subagent-creator","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fmeta\u002Fsubagent-creator\u002FSKILL.md",true,[67],{"path":68,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":71,"sourceHtmlUrl":72},"assets\u002Fagent-template.md","ASSET","资产文件",1236,"https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fmeta\u002Fsubagent-creator\u002Fassets\u002Fagent-template.md",[74,82,89,115,141,168],{"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":81},"01M745F5J4Z2W32G4QXESCN5PM","vault-recall","Answer the user's conceptual or technical question using their Obsidian vault as well as general knowledge. Use when the user asks a question (not a task) whose topic appears in the vault MOC digest from session start. Not for task instructions, not mid-task, and not for writing to the vault (that is to-vault).","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fproductivity\u002Fvault-recall\u002FSKILL.md",[],[],"2026-11-11 15:11:14",{"skillNo":83,"name":84,"nameZh":6,"description":85,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":86,"categories":87,"keywords":88,"publishedAt":81},"01M745EW5W0A7K9016Z54A4KG2","ingest","Ingest one external source (an article, course lesson, doc, PDF or URL) into the user's Obsidian vault: save the original to raw\u002F, then build wiki\u002F pages per the vault's § Ingest. Use when the user types \u002Fingest, or says \"ingest this\", \"add this source to my wiki\", \"put this article\u002Flesson in the vault as a wiki page\". Works from any repo. Routing rule: someone else's words go to wiki\u002F (this skill); the user's own learnings and decisions go to notes\u002F (\u002Fto-vault).","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fproductivity\u002Fingest\u002FSKILL.md",[],[],{"skillNo":90,"name":91,"nameZh":6,"description":92,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":93,"categories":94,"keywords":95,"publishedAt":40},"01M6H88J6TYRV9T8RKWW569YM8","to-tickets","Breaks a source into independently-grabbable GitHub tickets. For a code feature the source is the plan (`docs\u002Fplans\u002F\u003Cfeature>.md`, from \u002Fto-plan) and every new or changed symbol lands in exactly one ticket, its signatures copied into the ticket body; a non-code feature is cut from the PRD's slices. Cuts tickets for one feature per run. If a code feature has no approved plan, offers \u002Fto-plan instead of cutting from prose. In a repo that runs command-centre, also emits `[[task]]` blocks into its config; in a plain treepad repo, emits a Batch Manifest instead so the tickets materialise as stacked worktrees.","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fto-tickets\u002FSKILL.md",[],[96,97,98,99,100,101,102,103,38,104,105,106,107,108,109,27,110,111,112,113,114],"tickets","to tickets","new","signatures","github","plan","batch","task","manifest","plans","true","ticket","command","repo","feature","run","worktrees","as","cut",{"skillNo":116,"name":117,"nameZh":6,"description":118,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":119,"categories":120,"keywords":126,"publishedAt":40},"01M6H88E98X9KGGYBGSVDS1E8H","to-seams","Records an agreed-but-unlanded cross-repo interface as a seam: the file a consumer's agent gets pasted into its prompt as ground truth, plus the `[[seam]]` block command-centre reads for the retirement pointer. Use when two repos need to build against an interface neither has landed yet — \"record a seam for X\", \"we agreed on this schema, seam it\", \"add a seam so Y can build against Z's new field\". Halts for approval before writing either file.","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fto-seams\u002FSKILL.md",[121],{"categoryNo":122,"categoryName":123,"taxonomyType":124,"taxonomyTypeDesc":125},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[127,128,98,129,29,130,131,132,133,22,31,23,134,106,135,136,137,109,27,138,139,140,113,108],"to seams","schema","neither","but","file","prompt","either","interface","repos","block","records","build","can","record",{"skillNo":142,"name":143,"nameZh":6,"description":144,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":145,"categories":146,"keywords":152,"publishedAt":40},"01M6H889PSQM2E1ATS2JC10QRV","to-roadmap","Prioritises settled features into a Now \u002F Next \u002F Later kanban board, rendered as a self-contained .\u002Fideas\u002Froadmap.html. Each card is a feature, not a ticket — one card later becomes several tickets via \u002Fto-prd -> \u002Fto-plan -> \u002Fto-tickets. Boards the features in .\u002Fdocs\u002Fapproach.md, or the \"## Accepted ideas\" in .\u002Fideas\u002FCONTEXT.md when there is no approach doc. The approach doc is settled truth: this assigns tiers and reasons about ordering, it never re-litigates what was decided.","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fto-roadmap\u002FSKILL.md",[147],{"categoryNo":148,"categoryName":149,"taxonomyType":150,"taxonomyTypeDesc":151},"01JBSEEDCAT000000000000031","产品经理","PROFESSION","适用职业",[153,154,155,113,110,156,157,23,158,159,160,96,161,162,101,163,164,106,107,165,166,167],"to roadmap","roadmap","never","via","features","doc","board","about","next","later","self","now","card","re","ideas",{"skillNo":169,"name":170,"nameZh":6,"description":171,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":172,"categories":173,"keywords":175,"publishedAt":40},"01M6H885QAK839Q771ZBKBK1KA","to-prd","Turns one feature idea into a PRD built on journeys: a one-line problem, journeys (each ending in an observable state) and delivery slices that say what is usable after each. Interviews, explores the codebase, and saves to docs\u002Fprds\u002F\u003Cfeature>.md. Covers exactly one feature: given a multi-feature source, ask which one. Reads any approach doc or ideate report as priors so it doesn't re-ask what's settled, but needs none. Starts the per-feature spine (\u002Fto-prd -> \u002Fto-plan -> \u002Fto-tickets).","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fto-prd\u002FSKILL.md",[174],{"categoryNo":148,"categoryName":149,"taxonomyType":150,"taxonomyTypeDesc":151},[176,177,178,179,180,181,182,183,96,184,101,185,186,187,106,166,110,188,189,113],"prd","to prd","say","interviews","codebase","report","line","delivery","spine","state","multi","ask","problem","which"]