[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6H8731Q9F2H85TQADH5HGR0":3,"skill-same:01M6H8731Q9F2H85TQADH5HGR0":71},{"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":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":49,"commitSha":50,"skillDirectory":51,"forksCount":14,"repositoryHtmlUrl":52,"repositoryHomepageUrl":6,"ownerHtmlUrl":53,"ownerBlogUrl":54,"ownerDescription":55,"updatedAt":56,"install":57,"resources":70},"01M6H8731Q9F2H85TQADH5HGR0","fix-ci",null,"Fix failing GitHub Actions CI on pull requests fast: read the failed job logs, make the smallest fix, run one cheap local check, push, and let GitHub CI be the judge while it watches in the background. Takes an optional target: a run or job URL\u002FID (fix only that run's failures), a PR number\u002FURL (fix every failing check on it), or nothing (the PRs in the conversation, else the current branch's PR). Handles stacked PRs by fixing the base first and rebasing dependents. Use whenever the user says \"fix ci\", \"ci is failing\", \"checks failed\", \"the build is red\", \"fix the failing PRs\", \"both prs fail ci\", pastes a GitHub Actions run link, or otherwise asks to get red checks green, even without saying \"CI\". Not for writing new CI workflows.","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\u002Fworkflow\u002Ffix-ci\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"fix ci","ci","fix","new","writing","failing","for","number","URL","get","local","green","conversation","ci workflows","only","use","branch","github actions","actions","logs","push","pull","pr","pull requests","workflows","2026-11-10 10:12:30",false,"---\nname: fix-ci\ndescription: >\n  Fix failing GitHub Actions CI on pull requests fast: read the failed job logs, make the smallest\n  fix, run one cheap local check, push, and let GitHub CI be the judge while it watches in the\n  background. Takes an optional target: a run or job URL\u002FID (fix only that run's failures), a PR\n  number\u002FURL (fix every failing check on it), or nothing (the PRs in the conversation, else the\n  current branch's PR). Handles stacked PRs by fixing the base first and rebasing dependents.\n  Use whenever the user says \"fix ci\", \"ci is failing\", \"checks failed\", \"the build is red\",\n  \"fix the failing PRs\", \"both prs fail ci\", pastes a GitHub Actions run link, or otherwise asks\n  to get red checks green, even without saying \"CI\". Not for writing new CI workflows.\n---\n\n# Fix CI\n\nThe user wants red checks turned green with as little waiting as possible. GitHub CI is the\njudge, not the local machine. Every minute spent re-running suites locally is a minute the\nuser waits for something CI is about to do anyway. Speed comes from three habits: diagnose from\nthe logs, make a narrow fix, push quickly.\n\n## 1. Resolve the target\n\nThe argument decides what to fix:\n\n| Given | Scope |\n|---|---|\n| Run URL or ID (`...\u002Factions\u002Fruns\u002F\u003Crun>`) | Only the failed jobs in that run. Find the PR from the run's head branch. |\n| Job URL (`...\u002Fruns\u002F\u003Crun>\u002Fjob\u002F\u003Cjob>`) | Only that one job. |\n| PR number or URL | Every failing check on the PR. |\n| Nothing | The PRs named or discussed earlier in this conversation. If there are none, the current branch's PR. |\n\nNever go through the user's other open PRs. If nothing resolves to a PR, say so and stop.\n\n```bash\ngh run view \u003Crun> --json headBranch,url,jobs      # run -> branch, failed jobs\ngh pr view \u003Cbranch> --json number,headRefName,baseRefName,url\ngh pr checks \u003Cpr> --json name,bucket,link         # bucket=fail -> failing; link holds run\u002Fjob ids\n```\n\n## 2. Diagnose from the logs\n\n```bash\ngh run view --job \u003Cjob-id> --log-failed\n```\n\nRead the failure, then the code it points at. That is usually enough. Before deciding the cause,\ncheck whether the failure is related to the PR's diff (`gh pr diff \u003Cpr> --name-only`).\n\n**Looks flaky?** Signs are a timeout or race in code the PR didn't touch, a network or runner\nerror, or the same test passing on the base branch. If so, rerun once and change no code:\n\n```bash\ngh run rerun \u003Crun> --failed\n```\n\nTell the user it looked flaky and offer to file an issue for it (the `file-issue` skill).\nHardening a flaky test inside this PR is scope creep the reviewer didn't ask for.\n\n**Needs a deny-listed file?** Read the repo's `CLAUDE.md` (and any it links) for files agents may\nnot push, such as `.github\u002F**`, `go.mod`, `go.sum`, `.golangci.yml`. If the only real fix touches\none of them, stop on that PR. Name the file and the change it needs, then carry on with the other\nPRs. Do not work around the deny-list. The user has to make that change themselves.\n\n## 3. Get a checkout\n\nNever switch the branch in the user's main checkout, because they may have work there.\n\n- `git worktree list`: if a worktree already has the PR's branch (e.g. from `\u002Ffleet`), work there\n  and `git pull --ff-only` first.\n- Otherwise create one. Use `tp` if it is on PATH (see the `treepad` skill), else\n  `git worktree add`.\n\n## 4. Fix narrowly\n\nFix only what the targeted checks reported. If you notice anything else (other lint, a smell,\na flaky neighbour), it goes in the final report as one line. Don't edit it.\n\nFollow the repo's own rules from `CLAUDE.md` and `~\u002F.claude\u002Frules\u002Fcomments.md`. A CI fix rarely\nneeds a comment.\n\n## 5. One cheap check, then push\n\nRun the narrowest command that would catch a typo-level mistake. It should take seconds, not\nminutes:\n\n- lint failure: the same linter on the touched package\u002Ffiles\n- unit test failure: that one test, once (`go test .\u002Fpkg -run '^TestName$' -count=1`, or the\n  repo's equivalent)\n- build\u002Ftype failure: build or vet the affected package\n- slow e2e\u002Fintegration failure: compile it (`go vet .\u002Fe2e\u002F...` or `go test -run XXX .\u002Fe2e\u002F...`).\n  Do not run the suite. CI will.\n\nNever run the full suite, never loop a test for stability, never \"make sure\" with repeated runs.\nIf the cheap check fails, fix it and run it again. That is still seconds.\n\nCommit as a new commit, one per PR per round:\n\n```\nFix CI: \u003Cwhat failed, briefly>\n\nCo-Authored-By: \u003Cthe trailer from the session's attribution reminder>\n```\n\nThen `git push` normally. Don't amend: the repo squash-merges, and a plain push keeps what\nreviewers already saw.\n\n## Stacked PRs\n\nIf one target PR's base branch is another target PR's head branch, work bottom-up:\n\n1. Fix and push the base PR.\n2. Rebase the dependent onto the base's new head and push with `--force-with-lease`.\n3. Look at the dependent's failures again. Many were inherited and are now gone. Fix only what\n   is still its own.\n\n## Inline vs subagents\n\nWork inline, one PR after another. Delegating adds start-up latency, and subagents drift: one\nspent 15 minutes looping the e2e suite before pushing. Only fan out when there are 3 or more\nindependent (unstacked) PRs. Give each subagent this skill's rules word for word, especially\n\"one cheap check, never the full suite, push immediately\".\n\n## 6. Report, then watch in the background\n\nReport straight away, one line per PR:\n\n```\n#439: e2e timeout in TestCrossRepoSlice → fixed in abc1234, CI watching\n#440: rebased onto #439, golangci-lint unused param → fixed in def5678, CI watching\n#441: blocked — needs go.mod bump (golang.org\u002Fx\u002Fsync v0.9), deny-listed\n#442: TestPoll flaked (runner timeout) → rerun, no code change\nNoticed, not fixed: #439 internal\u002Fweb has a vet shadow warning\n```\n\nThen start one background watch per pushed PR (Bash with `run_in_background`), and end your turn:\n\n```bash\ngh pr checks \u003Cpr> --watch --interval 30\n```\n\nWhen a watch finishes:\n\n- **Green**: report one line, e.g. `#439: CI green`.\n- **Still red on the targeted checks**: go back to step 2 by yourself, without asking. Allow\n  at most 2 automatic rounds per PR after the first push. After that, stop and report what\n  keeps failing and what you tried. A third identical failure means you are guessing.\n- **Red only on checks outside the target** (e.g. you were given one job): report them and\n  don't fix them.\n","# Fix CI\n\nThe user wants red checks turned green with as little waiting as possible. GitHub CI is the\njudge, not the local machine. Every minute spent re-running suites locally is a minute the\nuser waits for something CI is about to do anyway. Speed comes from three habits: diagnose from\nthe logs, make a narrow fix, push quickly.\n\n## 1. Resolve the target\n\nThe argument decides what to fix:\n\n| Given | Scope |\n|---|---|\n| Run URL or ID (`...\u002Factions\u002Fruns\u002F\u003Crun>`) | Only the failed jobs in that run. Find the PR from the run's head branch. |\n| Job URL (`...\u002Fruns\u002F\u003Crun>\u002Fjob\u002F\u003Cjob>`) | Only that one job. |\n| PR number or URL | Every failing check on the PR. |\n| Nothing | The PRs named or discussed earlier in this conversation. If there are none, the current branch's PR. |\n\nNever go through the user's other open PRs. If nothing resolves to a PR, say so and stop.\n\n```bash\ngh run view \u003Crun> --json headBranch,url,jobs      # run -> branch, failed jobs\ngh pr view \u003Cbranch> --json number,headRefName,baseRefName,url\ngh pr checks \u003Cpr> --json name,bucket,link         # bucket=fail -> failing; link holds run\u002Fjob ids\n```\n\n## 2. Diagnose from the logs\n\n```bash\ngh run view --job \u003Cjob-id> --log-failed\n```\n\nRead the failure, then the code it points at. That is usually enough. Before deciding the cause,\ncheck whether the failure is related to the PR's diff (`gh pr diff \u003Cpr> --name-only`).\n\n**Looks flaky?** Signs are a timeout or race in code the PR didn't touch, a network or runner\nerror, or the same test passing on the base branch. If so, rerun once and change no code:\n\n```bash\ngh run rerun \u003Crun> --failed\n```\n\nTell the user it looked flaky and offer to file an issue for it (the `file-issue` skill).\nHardening a flaky test inside this PR is scope creep the reviewer didn't ask for.\n\n**Needs a deny-listed file?** Read the repo's `CLAUDE.md` (and any it links) for files agents may\nnot push, such as `.github\u002F**`, `go.mod`, `go.sum`, `.golangci.yml`. If the only real fix touches\none of them, stop on that PR. Name the file and the change it needs, then carry on with the other\nPRs. Do not work around the deny-list. The user has to make that change themselves.\n\n## 3. Get a checkout\n\nNever switch the branch in the user's main checkout, because they may have work there.\n\n- `git worktree list`: if a worktree already has the PR's branch (e.g. from `\u002Ffleet`), work there\n  and `git pull --ff-only` first.\n- Otherwise create one. Use `tp` if it is on PATH (see the `treepad` skill), else\n  `git worktree add`.\n\n## 4. Fix narrowly\n\nFix only what the targeted checks reported. If you notice anything else (other lint, a smell,\na flaky neighbour), it goes in the final report as one line. Don't edit it.\n\nFollow the repo's own rules from `CLAUDE.md` and `~\u002F.claude\u002Frules\u002Fcomments.md`. A CI fix rarely\nneeds a comment.\n\n## 5. One cheap check, then push\n\nRun the narrowest command that would catch a typo-level mistake. It should take seconds, not\nminutes:\n\n- lint failure: the same linter on the touched package\u002Ffiles\n- unit test failure: that one test, once (`go test .\u002Fpkg -run '^TestName$' -count=1`, or the\n  repo's equivalent)\n- build\u002Ftype failure: build or vet the affected package\n- slow e2e\u002Fintegration failure: compile it (`go vet .\u002Fe2e\u002F...` or `go test -run XXX .\u002Fe2e\u002F...`).\n  Do not run the suite. CI will.\n\nNever run the full suite, never loop a test for stability, never \"make sure\" with repeated runs.\nIf the cheap check fails, fix it and run it again. That is still seconds.\n\nCommit as a new commit, one per PR per round:\n\n```\nFix CI: \u003Cwhat failed, briefly>\n\nCo-Authored-By: \u003Cthe trailer from the session's attribution reminder>\n```\n\nThen `git push` normally. Don't amend: the repo squash-merges, and a plain push keeps what\nreviewers already saw.\n\n## Stacked PRs\n\nIf one target PR's base branch is another target PR's head branch, work bottom-up:\n\n1. Fix and push the base PR.\n2. Rebase the dependent onto the base's new head and push with `--force-with-lease`.\n3. Look at the dependent's failures again. Many were inherited and are now gone. Fix only what\n   is still its own.\n\n## Inline vs subagents\n\nWork inline, one PR after another. Delegating adds start-up latency, and subagents drift: one\nspent 15 minutes looping the e2e suite before pushing. Only fan out when there are 3 or more\nindependent (unstacked) PRs. Give each subagent this skill's rules word for word, especially\n\"one cheap check, never the full suite, push immediately\".\n\n## 6. Report, then watch in the background\n\nReport straight away, one line per PR:\n\n```\n#439: e2e timeout in TestCrossRepoSlice → fixed in abc1234, CI watching\n#440: rebased onto #439, golangci-lint unused param → fixed in def5678, CI watching\n#441: blocked — needs go.mod bump (golang.org\u002Fx\u002Fsync v0.9), deny-listed\n#442: TestPoll flaked (runner timeout) → rerun, no code change\nNoticed, not fixed: #439 internal\u002Fweb has a vet shadow warning\n```\n\nThen start one background watch per pushed PR (Bash with `run_in_background`), and end your turn:\n\n```bash\ngh pr checks \u003Cpr> --watch --interval 30\n```\n\nWhen a watch finishes:\n\n- **Green**: report one line, e.g. `#439: CI green`.\n- **Still red on the targeted checks**: go back to step 2 by yourself, without asking. Allow\n  at most 2 automatic rounds per PR after the first push. After that, stop and report what\n  keeps failing and what you tried. A third identical failure means you are guessing.\n- **Red only on checks outside the target** (e.g. you were given one job): report them and\n  don't fix them.\n",{"name":5,"description":7},"main","aede9f7bc29a2d9127fa7ce29682c242596c7759","skills\u002Fworkflow\u002Ffix-ci","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":58,"prompt":68,"zipAvailable":69},[59,62,65],{"tool":60,"command":61},"npx","npx skills add O-Marsters-1997\u002Fmy-claude-code --skill fix-ci",{"tool":63,"command":64},"bunx","bunx skills add O-Marsters-1997\u002Fmy-claude-code --skill fix-ci",{"tool":66,"command":67},"pnpm","pnpm dlx skills add O-Marsters-1997\u002Fmy-claude-code --skill fix-ci","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Ffix-ci\u002FSKILL.md",true,[],[72,80,87,113,141,168],{"skillNo":73,"name":74,"nameZh":6,"description":75,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":76,"categories":77,"keywords":78,"publishedAt":79},"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":81,"name":82,"nameZh":6,"description":83,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":84,"categories":85,"keywords":86,"publishedAt":79},"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":88,"name":89,"nameZh":6,"description":90,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":91,"categories":92,"keywords":93,"publishedAt":44},"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",[],[94,95,22,96,97,98,99,100,101,102,103,104,105,106,107,25,108,109,110,111,112],"tickets","to tickets","signatures","github","plan","batch","task","code","manifest","plans","true","ticket","command","repo","feature","run","worktrees","as","cut",{"skillNo":114,"name":115,"nameZh":6,"description":116,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":117,"categories":118,"keywords":124,"publishedAt":44},"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",[119],{"categoryNo":120,"categoryName":121,"taxonomyType":122,"taxonomyTypeDesc":123},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[125,126,22,127,128,129,130,131,132,34,23,133,134,104,135,136,137,107,25,138,139,140,111,106],"to seams","schema","neither","it","but","file","prompt","either","when","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":44},"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,111,108,156,157,133,158,159,160,94,161,162,98,163,164,104,105,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":44},"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,94,184,98,185,186,187,104,166,108,188,189,111],"prd","to prd","say","interviews","codebase","report","line","delivery","spine","state","multi","ask","problem","which"]