[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6H84G4EZ563CCKBM09YAY82":3,"skill-same:01M6H84G4EZ563CCKBM09YAY82":80},{"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":23,"publishedAt":47,"linkOnly":48,"markdownContent":49,"markdownBody":50,"frontMatter":51,"refName":52,"commitSha":53,"skillDirectory":54,"forksCount":14,"repositoryHtmlUrl":55,"repositoryHomepageUrl":6,"ownerHtmlUrl":56,"ownerBlogUrl":57,"ownerDescription":58,"updatedAt":59,"install":60,"resources":73},"01M6H84G4EZ563CCKBM09YAY82","skill-updater",null,"Update an existing skill with new context, patterns, or improvements. Edits the skill at its source repo (not the installed copy) and opens a draft PR for the change. Use when user wants to update a skill, modify a skill, add a pattern to a skill, improve an existing skill, edit a SKILL.md, tweak skill instructions, change skill behaviour, or mentions \"update skill\", \"edit skill\", \"change skill\", \"add to skill\". Also use when invoked programmatically with a skill name, path, and improvement_suggestions[] payload from skill-feedback-collector, with a GitHub issue number, or when \u002Fimplement hands over an issue whose changes are all under `skills\u002F`. Do NOT use for creating new skills from scratch — use skill-creator for that.","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\u002Fskill-updater\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46],"updater","skill updater","existing skill","new","when","skill-creator","source","path","at","number","add","pattern","change","patterns","do","issue","update skill","payload","context","edit","draft pr","improve","update","2026-11-10 10:12:30",false,"---\nname: skill-updater\ndescription: Update an existing skill with new context, patterns, or improvements. Edits the skill at its source repo (not the installed copy) and opens a draft PR for the change. Use when user wants to update a skill, modify a skill, add a pattern to a skill, improve an existing skill, edit a SKILL.md, tweak skill instructions, change skill behaviour, or mentions \"update skill\", \"edit skill\", \"change skill\", \"add to skill\". Also use when invoked programmatically with a skill name, path, and improvement_suggestions[] payload from skill-feedback-collector, with a GitHub issue number, or when \u002Fimplement hands over an issue whose changes are all under `skills\u002F`. Do NOT use for creating new skills from scratch — use skill-creator for that.\n---\n\n# Skill Updater\n\nIn-place updates to an existing skill's SKILL.md. Edits live in the source repo and are shipped as a draft PR — never to the installed copy. Every change is verified before it ships: the old and new skill run the same scenario, and the new one must do better. For creating new skills, use skill-creator instead.\n\n## Programmatic input path\n\nWhen invoked with a GitHub issue number, read the issue (`gh issue view \u003CN>`): \"Where to look\" names the skill, the acceptance criteria are the change, and the scenario in them is the one to rerun. Skip discovery and selection.\n\nWhen invoked with a structured payload — `skill_name`, `skill_path`, and `improvement_suggestions[]` — skip the discovery and selection steps and go straight to applying the suggestions.\n\nEach suggestion in `improvement_suggestions[]` has this shape:\n\n```\n{ priority: \"high\" | \"medium\" | \"low\",\n  category: \"instructions\" | \"tools\" | \"examples\" | \"error_handling\" | \"structure\" | \"references\",\n  suggestion: string,\n  expected_impact: string }\n```\n\nApply suggestions in priority order (high first). Even on the programmatic path, run the preview-and-confirm step before writing.\n\n## Process\n\n### 0. Resolve source repo\n\nRead `~\u002F.claude\u002Fskill-updater.config`. If it exists and is non-empty, use its contents (trimmed) as `\u003Csource-repo>`.\n\nIf missing or empty: ask the user for the absolute path to their skills source repo, validate it is a git repo containing a `skills\u002F` directory, then write the path to `~\u002F.claude\u002Fskill-updater.config`. Report the resolved path in one line so the user can catch a wrong config immediately.\n\n### 1. Identify the target skill\n\nEnumerate `\u003Csource-repo>\u002Fskills\u002F**\u002FSKILL.md` (skills nest, e.g. `skills\u002Fmeta\u002F\u003Cname>\u002F`). Record each skill's name (from frontmatter) and absolute path.\n\n> This skill only edits skills in `\u003Csource-repo>\u002Fskills\u002F`. Plugin skills or `~\u002F.claude\u002Fskills\u002F` entries are out of scope — those require a fork-and-PR workflow against the plugin's upstream repo.\n\nIf the user didn't name a skill, list what was found and ask which to update:\n\n```\n1. clean-comments — \u003Csource-repo>\u002Fskills\u002Fcode\u002Fclean-comments\u002FSKILL.md\n2. tdd — \u003Csource-repo>\u002Fskills\u002Fcode\u002Ftdd\u002FSKILL.md\n```\n\n### 2. Read and understand\n\nRead the target SKILL.md in full. Also read any bundled reference files relevant to the requested change.\n\nBefore editing, tell the user: what the skill currently does (one sentence), which section(s) the change affects, and your proposed edit. Wait for confirmation — the user may have a different mental model than what's written.\n\n### 3. Apply the update\n\nBefore editing, create the worktree for branch `skill-update\u002F\u003Cname>-\u003CYYYYMMDD>` off `origin\u002Fmain` as in [`references\u002Fpr-workflow.md`](references\u002Fpr-workflow.md), and make every edit, commit and push in `\u003Cworktree>`, never in `\u003Csource-repo>`, whose checkout other sessions share. Copy the current skill directory to `\u003Cscratchpad>\u002F\u003Cname>-baseline\u002F` so the old version can be rerun. Write changes to the skill's own SKILL.md (and its `references\u002F`) only. Never edit `~\u002F.claude\u002Fskills\u002F...` or `.agents\u002Fskills\u002F...`.\n\n- **Preserve voice and style.** Don't rewrite sections the user didn't ask to change.\n- **Keep it lean.** If adding content pushes SKILL.md past 100 lines, split into a `references\u002F` file.\n- **Frontmatter hygiene.** Update `description` if the change affects triggers or behaviour — stale descriptions cause misfires.\n- **Remove dead lines.** Delete lines that change nothing about behaviour, not only add new ones.\n- **Explain the why.** New instructions should include reasoning, not just directives.\n- **Imperative form.** Write \"Do X\" not \"You should do X\".\n\n### 4. Verify old vs new\n\nThe scenario is the issue's acceptance criterion, or a case from the skill's `evals\u002Fevals.json` when there is no issue. Run it twice in fresh subagents, one pointed at the baseline copy and one at the edited skill, with the same prompt. Compare the outputs against the criterion.\n\n- New passes and baseline fails: continue.\n- New does not pass: rework the edit once and rerun. If it still fails, reject the change and report why; open no PR.\n- Baseline also passes: the scenario does not test the change; tighten it and rerun, or report that the change is unverified.\n\nAppend the scenario to `\u003Cskill>\u002Fevals\u002Fevals.json` (create it as `{\"skill_name\": \"\u003Cname>\", \"evals\": []}` if absent) as `{\"id\": \u003Cnext>, \"prompt\": ..., \"expected_output\": ...}`, and keep the baseline and new outputs for the PR body.\n\n### 5. Open a draft PR\n\nSee [`references\u002Fpr-workflow.md`](references\u002Fpr-workflow.md) for the full git and gh commands.\n\n1. Stage changed files in `\u003Cworktree>`: the skill's SKILL.md, `evals\u002Fevals.json` and any `references\u002F` additions.\n2. Draft commit message: `chore(skills\u002F\u003Cname>): \u003Cone-line summary>`.\n3. Draft PR body using the template in `references\u002Fpr-workflow.md`.\n4. **Show the commit message and PR body to the user. Wait for confirmation.** Then push and open the draft PR.\n5. Return the PR URL.\n\n### 6. Confirm and report\n\nOutput the edited file path and the PR URL:\n\n```\nUpdated: \u003Cworktree>\u002Fskills\u002F\u003Cname>\u002FSKILL.md\nPR: \u003Curl>\n```\n\nOffer to read back the updated skill so the user can review it in context.\n","# Skill Updater\n\nIn-place updates to an existing skill's SKILL.md. Edits live in the source repo and are shipped as a draft PR — never to the installed copy. Every change is verified before it ships: the old and new skill run the same scenario, and the new one must do better. For creating new skills, use skill-creator instead.\n\n## Programmatic input path\n\nWhen invoked with a GitHub issue number, read the issue (`gh issue view \u003CN>`): \"Where to look\" names the skill, the acceptance criteria are the change, and the scenario in them is the one to rerun. Skip discovery and selection.\n\nWhen invoked with a structured payload — `skill_name`, `skill_path`, and `improvement_suggestions[]` — skip the discovery and selection steps and go straight to applying the suggestions.\n\nEach suggestion in `improvement_suggestions[]` has this shape:\n\n```\n{ priority: \"high\" | \"medium\" | \"low\",\n  category: \"instructions\" | \"tools\" | \"examples\" | \"error_handling\" | \"structure\" | \"references\",\n  suggestion: string,\n  expected_impact: string }\n```\n\nApply suggestions in priority order (high first). Even on the programmatic path, run the preview-and-confirm step before writing.\n\n## Process\n\n### 0. Resolve source repo\n\nRead `~\u002F.claude\u002Fskill-updater.config`. If it exists and is non-empty, use its contents (trimmed) as `\u003Csource-repo>`.\n\nIf missing or empty: ask the user for the absolute path to their skills source repo, validate it is a git repo containing a `skills\u002F` directory, then write the path to `~\u002F.claude\u002Fskill-updater.config`. Report the resolved path in one line so the user can catch a wrong config immediately.\n\n### 1. Identify the target skill\n\nEnumerate `\u003Csource-repo>\u002Fskills\u002F**\u002FSKILL.md` (skills nest, e.g. `skills\u002Fmeta\u002F\u003Cname>\u002F`). Record each skill's name (from frontmatter) and absolute path.\n\n> This skill only edits skills in `\u003Csource-repo>\u002Fskills\u002F`. Plugin skills or `~\u002F.claude\u002Fskills\u002F` entries are out of scope — those require a fork-and-PR workflow against the plugin's upstream repo.\n\nIf the user didn't name a skill, list what was found and ask which to update:\n\n```\n1. clean-comments — \u003Csource-repo>\u002Fskills\u002Fcode\u002Fclean-comments\u002FSKILL.md\n2. tdd — \u003Csource-repo>\u002Fskills\u002Fcode\u002Ftdd\u002FSKILL.md\n```\n\n### 2. Read and understand\n\nRead the target SKILL.md in full. Also read any bundled reference files relevant to the requested change.\n\nBefore editing, tell the user: what the skill currently does (one sentence), which section(s) the change affects, and your proposed edit. Wait for confirmation — the user may have a different mental model than what's written.\n\n### 3. Apply the update\n\nBefore editing, create the worktree for branch `skill-update\u002F\u003Cname>-\u003CYYYYMMDD>` off `origin\u002Fmain` as in [`references\u002Fpr-workflow.md`](references\u002Fpr-workflow.md), and make every edit, commit and push in `\u003Cworktree>`, never in `\u003Csource-repo>`, whose checkout other sessions share. Copy the current skill directory to `\u003Cscratchpad>\u002F\u003Cname>-baseline\u002F` so the old version can be rerun. Write changes to the skill's own SKILL.md (and its `references\u002F`) only. Never edit `~\u002F.claude\u002Fskills\u002F...` or `.agents\u002Fskills\u002F...`.\n\n- **Preserve voice and style.** Don't rewrite sections the user didn't ask to change.\n- **Keep it lean.** If adding content pushes SKILL.md past 100 lines, split into a `references\u002F` file.\n- **Frontmatter hygiene.** Update `description` if the change affects triggers or behaviour — stale descriptions cause misfires.\n- **Remove dead lines.** Delete lines that change nothing about behaviour, not only add new ones.\n- **Explain the why.** New instructions should include reasoning, not just directives.\n- **Imperative form.** Write \"Do X\" not \"You should do X\".\n\n### 4. Verify old vs new\n\nThe scenario is the issue's acceptance criterion, or a case from the skill's `evals\u002Fevals.json` when there is no issue. Run it twice in fresh subagents, one pointed at the baseline copy and one at the edited skill, with the same prompt. Compare the outputs against the criterion.\n\n- New passes and baseline fails: continue.\n- New does not pass: rework the edit once and rerun. If it still fails, reject the change and report why; open no PR.\n- Baseline also passes: the scenario does not test the change; tighten it and rerun, or report that the change is unverified.\n\nAppend the scenario to `\u003Cskill>\u002Fevals\u002Fevals.json` (create it as `{\"skill_name\": \"\u003Cname>\", \"evals\": []}` if absent) as `{\"id\": \u003Cnext>, \"prompt\": ..., \"expected_output\": ...}`, and keep the baseline and new outputs for the PR body.\n\n### 5. Open a draft PR\n\nSee [`references\u002Fpr-workflow.md`](references\u002Fpr-workflow.md) for the full git and gh commands.\n\n1. Stage changed files in `\u003Cworktree>`: the skill's SKILL.md, `evals\u002Fevals.json` and any `references\u002F` additions.\n2. Draft commit message: `chore(skills\u002F\u003Cname>): \u003Cone-line summary>`.\n3. Draft PR body using the template in `references\u002Fpr-workflow.md`.\n4. **Show the commit message and PR body to the user. Wait for confirmation.** Then push and open the draft PR.\n5. Return the PR URL.\n\n### 6. Confirm and report\n\nOutput the edited file path and the PR URL:\n\n```\nUpdated: \u003Cworktree>\u002Fskills\u002F\u003Cname>\u002FSKILL.md\nPR: \u003Curl>\n```\n\nOffer to read back the updated skill so the user can review it in context.\n",{"name":5,"description":7},"main","aede9f7bc29a2d9127fa7ce29682c242596c7759","skills\u002Fmeta\u002Fskill-updater","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":61,"prompt":71,"zipAvailable":72},[62,65,68],{"tool":63,"command":64},"npx","npx skills add O-Marsters-1997\u002Fmy-claude-code --skill skill-updater",{"tool":66,"command":67},"bunx","bunx skills add O-Marsters-1997\u002Fmy-claude-code --skill skill-updater",{"tool":69,"command":70},"pnpm","pnpm dlx skills add O-Marsters-1997\u002Fmy-claude-code --skill skill-updater","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fmeta\u002Fskill-updater\u002FSKILL.md",true,[74],{"path":75,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":78,"sourceHtmlUrl":79},"references\u002Fpr-workflow.md","REFERENCE","参考文档",2389,"https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fmeta\u002Fskill-updater\u002Freferences\u002Fpr-workflow.md",[81,89,96,123,148,175],{"skillNo":82,"name":83,"nameZh":6,"description":84,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":85,"categories":86,"keywords":87,"publishedAt":88},"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":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":88},"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":97,"name":98,"nameZh":6,"description":99,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":100,"categories":101,"keywords":102,"publishedAt":47},"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",[],[103,104,27,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122],"tickets","to tickets","signatures","github","plan","batch","task","code","manifest","plans","true","ticket","command","repo","for","feature","run","worktrees","as","cut",{"skillNo":124,"name":125,"nameZh":6,"description":126,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":127,"categories":128,"keywords":130,"publishedAt":47},"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",[129],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[131,132,27,133,134,135,136,137,138,139,140,28,141,113,142,143,144,116,117,145,146,147,121,115],"to seams","schema","neither","it","but","file","prompt","either","use","writing","interface","repos","block","records","build","can","record",{"skillNo":149,"name":150,"nameZh":6,"description":151,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":152,"categories":153,"keywords":159,"publishedAt":47},"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",[154],{"categoryNo":155,"categoryName":156,"taxonomyType":157,"taxonomyTypeDesc":158},"01JBSEEDCAT000000000000031","产品经理","PROFESSION","适用职业",[160,161,162,121,118,163,164,28,165,166,167,103,168,169,107,170,171,113,114,172,173,174],"to roadmap","roadmap","never","via","features","doc","board","about","next","later","self","now","card","re","ideas",{"skillNo":176,"name":177,"nameZh":6,"description":178,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":179,"categories":180,"keywords":182,"publishedAt":47},"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",[181],{"categoryNo":155,"categoryName":156,"taxonomyType":157,"taxonomyTypeDesc":158},[183,184,185,186,187,188,189,190,103,191,107,192,193,194,113,173,118,195,196,121],"prd","to prd","say","interviews","codebase","report","line","delivery","spine","state","multi","ask","problem","which"]