[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6H87HKZ9KTF1BA3FSSETNK9":3,"skill-same:01M6H87HKZ9KTF1BA3FSSETNK9":81},{"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},"01M6H87HKZ9KTF1BA3FSSETNK9","implement",null,"Implement a ticket or spec end to end. Invoke ONLY when the user types \u002Fimplement, or a dispatch prompt explicitly says to run implement for a named issue. Never invoke it on your own initiative, for ad hoc coding requests, or because a task looks like implementation work.","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\u002Fimplement\u002FSKILL.md",[],[5,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39],"when","spec","invoke","for","requests","types","it","ad","ticket","end","task","issue","implementation","dispatch","only","never","user","prompt","work","coding","run","2026-11-10 10:12:30",false,"---\nname: implement\ndescription: \"Implement a ticket or spec end to end. Invoke ONLY when the user types \u002Fimplement, or a dispatch prompt explicitly says to run implement for a named issue. Never invoke it on your own initiative, for ad hoc coding requests, or because a task looks like implementation work.\"\n---\n\nIf you were not explicitly told to run implement, stop and say so instead of continuing.\n\nIf you are not the `implementation` agent, delegate the entire job to that agent in the assigned\nworktree. Include the original ticket\u002Fspec, base, size, brief, files, scratch\u002Freport path and fleet\nresult contract verbatim; do not implement or review in the parent. If the agent cannot be found or\nlaunched, report `blocked` (`reviewed=no` for fleet) rather than silently doing the work yourself.\nThe agent loads this skill and follows the worker instructions below; this delegation does not\nrepeat inside it. Wait for its result and preserve the fleet one-line output unchanged.\n\nImplement the work described by the user in the spec or tickets.\n\nFor a large or multi-part ticket, split it into smaller \u002Fimplement runs by logical slice, or\ncheckpoint with \u002Fcompact between major phases (after planning, after test-writing, before the\nfinal review). A single long session re-sends its whole growing history on every turn, so cost\ncompounds with session length far faster than with the same work split into smaller ones.\n\nRun test suites expected to take over about 30 seconds in the background, end the turn and\nwait for the completion notification. Never poll with sleep or Monitor loops: each poll re-sends\nthe whole session.\n\nBefore editing unfamiliar code in a repo with a `.codegraph\u002F` index, make `codegraph_explore`\n(load it via ToolSearch if deferred) your first lookup, before any grep or search. Pass the\nsymbols or files the ticket names or you expect to touch; the result is verbatim source, so don't\n`cat`, `sed -n` or `Read` what it already returned. `Read` only files you are about to edit or\nthat it didn't surface. If a fleet brief is named, start from it. For research broader than one\nquery, use a cheap exploration subagent (e.g. Explore) and take its distilled summary rather than\ngrepping and reading extensively yourself in this session.\n\nIf a merge or rebase stops on a conflict, trace each side to its intent from the diffs (read\ncommit messages for the conflicting files only if intent is still unclear), keep both intents or\nname what was dropped, invent no new behaviour, and run typecheck and the scoped tests before\ncontinuing. Never abort to dodge a real conflict; abort only if the base is wrong.\n\nLoad the standards skill for each language this change touches before editing a file in\nit, and follow it as written. Existing code that breaks the standard is not licence to\nmatch it.\n\n`~\u002F.claude\u002Frules\u002Fcomments.md` is the authority on comments. It outranks a standards\nskill's own comment guidance.\n\nIf every change the issue asks for is under `skills\u002F`, load `skill-updater` with the issue number\nfor its baseline-versus-new verification and draft PR, then independently review the PR's final\ndiff with `code-review` at the required level before reporting `reviewed=yes`. Apply and push\nwarranted findings to that branch and repeat review if the fix materially changes the diff. If\nthe updater or independent review cannot finish, return `blocked` with `reviewed=no` for fleet.\nThis route does not bypass the review gate merely because the updater opened a PR.\n\nLoad `tdd` where possible, at pre-agreed seams.\n\nSignatures in the ticket's `## Signatures` section are frozen: write them exactly as given and\nnever change one to make the work fit.\nIf a frozen signature can't be kept, take the contract-change path and stop:\n\n1. Create the `contract-change` label if missing (check `gh label list` first; `--force` would\n   recolour an existing one).\n2. File an issue labelled `contract-change`, `status:backlog` and the ticket's feature\n   label (the user approves it by moving it to ready), naming the signature, why it can't be kept, and the proposed new one. The user resolves it by\n   updating the plan and the `## Signatures` of every affected ticket, then closing it.\n3. Add `- Blocked by #\u003Cnew issue>` to this ticket's `## Blocked by` section and set it back to\n   `status:backlog`.\n4. Open a draft PR with the work so far, leaving the signature untouched, and stop.\n\n`\u002Ffleet reconcile` moves the ticket back to ready once the `contract-change` issue is closed.\n\nA ticket carrying `size:xs`, or a dispatch prompt saying `Size: xs`, is a small fix: keep the\ndiff to what the ticket asks, with no adjacent refactors. Skip `tdd` unless the fix changes\nobservable behaviour, and then add one regression test. Skip code-simplifier. Review with\n\u002Fcode-review low instead of medium. Both levels require an independent reviewer.\n\nGiven several issues at once (a fleet bundle), work them in the order given, one commit per\nissue whose message ends `Closes #\u003CN>`, and one PR for the whole bundle. Run the review passes\nonce, over the whole bundle.\n\nRun typechecking regularly, single test files regularly, and the full test suite once at the end.\nFor the regular checks, run the narrowest command that proves the point (a single test file\nor package, e.g. `go test .\u002Fpath -run TestName`) rather than the project's full test\u002Flint\nrunner (e.g. `just test`, `just lint`) — save that for the one full-suite pass at the end.\n\nIf the repo has `.claude\u002Ffleet.toml`, the final pass before pushing runs every command in its\n`[checks] pre_push` list, in order, and fixes failures before pushing. Run only the listed\ncommands; anything not listed is left to CI. Without the file, behave as above.\n\nDon't invoke code-simplifier after each individual edit. Load `code-simplifier` once near the end\nof the change, right before code-review.\n\nBefore committing or reporting a reviewed result, follow `references\u002Freview-gate.md` for the\nindependent review and failure path.\n\nWhen a fleet dispatch prompt names a `Base:`, the work belongs on the ticket branch\n`issue-\u003CN>\u002F\u003Cshort-title>`: `\u003CN>` the issue number, `\u003Cshort-title>` a kebab-case slug of the\nissue title, a few words (`issue-142\u002Fstuck-scrape-run`). Dispatch normally creates it; if the\ncurrent branch is anything else, create it with `tp new \u003Cbranch> --base \u003CBase> --current` (see\n`treepad`) and work in that worktree. Never `git switch -c` or `checkout -b` in the current\ncheckout: other sessions may share it, and moving its HEAD changes files under them.\n\nCommit your work to the current branch.\n\nFinish by raising a PR for review. Its base is `Base:` when a fleet dispatch prompt names one; ad hoc runs use the repo's default base.\n","If you were not explicitly told to run implement, stop and say so instead of continuing.\n\nIf you are not the `implementation` agent, delegate the entire job to that agent in the assigned\nworktree. Include the original ticket\u002Fspec, base, size, brief, files, scratch\u002Freport path and fleet\nresult contract verbatim; do not implement or review in the parent. If the agent cannot be found or\nlaunched, report `blocked` (`reviewed=no` for fleet) rather than silently doing the work yourself.\nThe agent loads this skill and follows the worker instructions below; this delegation does not\nrepeat inside it. Wait for its result and preserve the fleet one-line output unchanged.\n\nImplement the work described by the user in the spec or tickets.\n\nFor a large or multi-part ticket, split it into smaller \u002Fimplement runs by logical slice, or\ncheckpoint with \u002Fcompact between major phases (after planning, after test-writing, before the\nfinal review). A single long session re-sends its whole growing history on every turn, so cost\ncompounds with session length far faster than with the same work split into smaller ones.\n\nRun test suites expected to take over about 30 seconds in the background, end the turn and\nwait for the completion notification. Never poll with sleep or Monitor loops: each poll re-sends\nthe whole session.\n\nBefore editing unfamiliar code in a repo with a `.codegraph\u002F` index, make `codegraph_explore`\n(load it via ToolSearch if deferred) your first lookup, before any grep or search. Pass the\nsymbols or files the ticket names or you expect to touch; the result is verbatim source, so don't\n`cat`, `sed -n` or `Read` what it already returned. `Read` only files you are about to edit or\nthat it didn't surface. If a fleet brief is named, start from it. For research broader than one\nquery, use a cheap exploration subagent (e.g. Explore) and take its distilled summary rather than\ngrepping and reading extensively yourself in this session.\n\nIf a merge or rebase stops on a conflict, trace each side to its intent from the diffs (read\ncommit messages for the conflicting files only if intent is still unclear), keep both intents or\nname what was dropped, invent no new behaviour, and run typecheck and the scoped tests before\ncontinuing. Never abort to dodge a real conflict; abort only if the base is wrong.\n\nLoad the standards skill for each language this change touches before editing a file in\nit, and follow it as written. Existing code that breaks the standard is not licence to\nmatch it.\n\n`~\u002F.claude\u002Frules\u002Fcomments.md` is the authority on comments. It outranks a standards\nskill's own comment guidance.\n\nIf every change the issue asks for is under `skills\u002F`, load `skill-updater` with the issue number\nfor its baseline-versus-new verification and draft PR, then independently review the PR's final\ndiff with `code-review` at the required level before reporting `reviewed=yes`. Apply and push\nwarranted findings to that branch and repeat review if the fix materially changes the diff. If\nthe updater or independent review cannot finish, return `blocked` with `reviewed=no` for fleet.\nThis route does not bypass the review gate merely because the updater opened a PR.\n\nLoad `tdd` where possible, at pre-agreed seams.\n\nSignatures in the ticket's `## Signatures` section are frozen: write them exactly as given and\nnever change one to make the work fit.\nIf a frozen signature can't be kept, take the contract-change path and stop:\n\n1. Create the `contract-change` label if missing (check `gh label list` first; `--force` would\n   recolour an existing one).\n2. File an issue labelled `contract-change`, `status:backlog` and the ticket's feature\n   label (the user approves it by moving it to ready), naming the signature, why it can't be kept, and the proposed new one. The user resolves it by\n   updating the plan and the `## Signatures` of every affected ticket, then closing it.\n3. Add `- Blocked by #\u003Cnew issue>` to this ticket's `## Blocked by` section and set it back to\n   `status:backlog`.\n4. Open a draft PR with the work so far, leaving the signature untouched, and stop.\n\n`\u002Ffleet reconcile` moves the ticket back to ready once the `contract-change` issue is closed.\n\nA ticket carrying `size:xs`, or a dispatch prompt saying `Size: xs`, is a small fix: keep the\ndiff to what the ticket asks, with no adjacent refactors. Skip `tdd` unless the fix changes\nobservable behaviour, and then add one regression test. Skip code-simplifier. Review with\n\u002Fcode-review low instead of medium. Both levels require an independent reviewer.\n\nGiven several issues at once (a fleet bundle), work them in the order given, one commit per\nissue whose message ends `Closes #\u003CN>`, and one PR for the whole bundle. Run the review passes\nonce, over the whole bundle.\n\nRun typechecking regularly, single test files regularly, and the full test suite once at the end.\nFor the regular checks, run the narrowest command that proves the point (a single test file\nor package, e.g. `go test .\u002Fpath -run TestName`) rather than the project's full test\u002Flint\nrunner (e.g. `just test`, `just lint`) — save that for the one full-suite pass at the end.\n\nIf the repo has `.claude\u002Ffleet.toml`, the final pass before pushing runs every command in its\n`[checks] pre_push` list, in order, and fixes failures before pushing. Run only the listed\ncommands; anything not listed is left to CI. Without the file, behave as above.\n\nDon't invoke code-simplifier after each individual edit. Load `code-simplifier` once near the end\nof the change, right before code-review.\n\nBefore committing or reporting a reviewed result, follow `references\u002Freview-gate.md` for the\nindependent review and failure path.\n\nWhen a fleet dispatch prompt names a `Base:`, the work belongs on the ticket branch\n`issue-\u003CN>\u002F\u003Cshort-title>`: `\u003CN>` the issue number, `\u003Cshort-title>` a kebab-case slug of the\nissue title, a few words (`issue-142\u002Fstuck-scrape-run`). Dispatch normally creates it; if the\ncurrent branch is anything else, create it with `tp new \u003Cbranch> --base \u003CBase> --current` (see\n`treepad`) and work in that worktree. Never `git switch -c` or `checkout -b` in the current\ncheckout: other sessions may share it, and moving its HEAD changes files under them.\n\nCommit your work to the current branch.\n\nFinish by raising a PR for review. Its base is `Base:` when a fleet dispatch prompt names one; ad hoc runs use the repo's default base.\n",{"name":5,"description":7},"main","aede9f7bc29a2d9127fa7ce29682c242596c7759","skills\u002Fworkflow\u002Fimplement","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 implement",{"tool":59,"command":60},"bunx","bunx skills add O-Marsters-1997\u002Fmy-claude-code --skill implement",{"tool":62,"command":63},"pnpm","pnpm dlx skills add O-Marsters-1997\u002Fmy-claude-code --skill implement","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fimplement\u002FSKILL.md",true,[67,73,77],{"path":68,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":71,"sourceHtmlUrl":72},"agents\u002Fopenai.yaml","REFERENCE","参考文档",139,"https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fimplement\u002Fagents\u002Fopenai.yaml",{"path":74,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":75,"sourceHtmlUrl":76},"evals\u002Fevals.json",566,"https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fimplement\u002Fevals\u002Fevals.json",{"path":78,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":79,"sourceHtmlUrl":80},"references\u002Freview-gate.md",845,"https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fimplement\u002Freferences\u002Freview-gate.md",[82,90,97,121,148,174],{"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":89},"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":91,"name":92,"nameZh":6,"description":93,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":94,"categories":95,"keywords":96,"publishedAt":89},"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":98,"name":99,"nameZh":6,"description":100,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":101,"categories":102,"keywords":103,"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",[],[104,105,106,107,108,109,110,29,111,112,113,114,27,115,116,22,117,39,118,119,120],"tickets","to tickets","new","signatures","github","plan","batch","code","manifest","plans","true","command","repo","feature","worktrees","as","cut",{"skillNo":122,"name":123,"nameZh":6,"description":124,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":125,"categories":126,"keywords":132,"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",[127],{"categoryNo":128,"categoryName":129,"taxonomyType":130,"taxonomyTypeDesc":131},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[133,134,106,135,25,136,137,36,138,139,140,19,141,114,142,143,144,116,22,145,146,147,119,115],"to seams","schema","neither","but","file","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":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",[154],{"categoryNo":155,"categoryName":156,"taxonomyType":157,"taxonomyTypeDesc":158},"01JBSEEDCAT000000000000031","产品经理","PROFESSION","适用职业",[160,161,34,119,117,162,163,19,164,165,166,104,167,168,109,169,170,114,27,171,172,173],"to roadmap","roadmap","via","features","doc","board","about","next","later","self","now","card","re","ideas",{"skillNo":175,"name":176,"nameZh":6,"description":177,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":178,"categories":179,"keywords":181,"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",[180],{"categoryNo":155,"categoryName":156,"taxonomyType":157,"taxonomyTypeDesc":158},[182,183,184,185,186,187,188,189,104,190,109,191,192,193,114,172,117,194,195,119],"prd","to prd","say","interviews","codebase","report","line","delivery","spine","state","multi","ask","problem","which"]