[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DM08F681K2W7WWAC0FT231":3,"skill-same:01M6DM08F681K2W7WWAC0FT231":61},{"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":25,"linkOnly":26,"markdownContent":27,"markdownBody":28,"frontMatter":29,"refName":34,"commitSha":35,"skillDirectory":36,"forksCount":37,"repositoryHtmlUrl":38,"repositoryHomepageUrl":6,"ownerHtmlUrl":39,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":40,"install":41,"resources":54},"01M6DM08F681K2W7WWAC0FT231","fanout-policy",null,"다른 에이전트에게 일을 시킬 때의 규약 — 팬아웃이 맞는 일의 기준(독립성·시간 대비 토큰 비용), 발동 전제조건, 바꾸는 팬아웃의 사용자 확인 게이트, 맡기지 않는 행위 목록, 결과 필터와 대기 규율","Nharu\u002Fcc-cmds","Nharu","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F14357133?v=4","01M6DKV0D72FEBQABDAGSZ021P","nano","01M6DKV0TVG5GV22WQZBNRZ3ZT",3,"MIT","https:\u002F\u002Fgithub.com\u002FNharu\u002Fcc-cmds\u002Fblob\u002Fmaster\u002Fplugins\u002Fcc-cmds\u002Fskills\u002Ffanout-policy\u002FSKILL.md",[],[19,20,21,22,23,24],"policy","fanout","fanout policy","workflow","model","false","2026-11-10 10:12:30",false,"---\nname: fanout-policy\ndescription: 다른 에이전트에게 일을 시킬 때의 규약 — 팬아웃이 맞는 일의 기준(독립성·시간 대비 토큰 비용), 발동 전제조건, 바꾸는 팬아웃의 사용자 확인 게이트, 맡기지 않는 행위 목록, 결과 필터와 대기 규율\nwhen_to_use: 팬아웃·병렬 에이전트·워크플로 사용을 검토할 때와 발동 직전. 도구(`Workflow`·`Agent`·후속 디스패치 도구·스크립트 기동)를 가리지 않는다\ndisable-model-invocation: false\nusage: \"(자동 호출 — 슬래시 커맨드 없음. 다른 에이전트에게 일을 시키기 전에 모델이 열어 그대로 따른다.)\"\noptions: []\nnotes: |\n    슬래시 커맨드 surface 가 없는 model-invoked 정책 스킬이다. 여기 실린 규약은 도구 이름이\n    아니라 「다른 에이전트에게 일을 시키는가」로 발동하며, `Workflow`·`Agent`·후속 디스패치\n    도구·스크립트 기동을 전부 덮는다. 이 스킬은 팬아웃을 대신 발동하지 않는다 — 절차만 싣는다.\n---\n\n# fanout-policy\n\nThe rules for handing work to other agents. **Scope is the act, not the tool\nname**: `Workflow`, `Agent`, any later dispatch tool, and launching a script\nthat starts agents all receive every rule below. Where this file says\n\"workflow agent\" and \"main session\" it means *the spawned agent* and *the\nspawning side* — the same things named after one tool.\n\n## 1. When a fan-out is worth it\n\nFan out when both hold:\n\n1. The pieces are independent of each other — no piece needs another piece's result.\n2. The wall-clock time saved is worth more than the extra tokens spent under the weekly usage limit.\n\nTypical fits are a sweep that must leave no gap, independent adversarial\nverification, and work too large for one context — but they fit because they\npass the two tests above, not because they are on a list. Whatever comes back,\ncheck the evidence behind each agent's result before you rely on it.\n\nThe user has given standing, advance opt-in for fanning out on work that passes\nthis test — it is the user's own request, it does not have to be repeated per\ntask, and CLAUDE.md \u002F memory instructions count as a direct user instruction for\nthis purpose. So when such work arrives and **what the agents are told to do\nchanges nothing**, call the fan-out without asking for approval, even outside a\nskill run. The harness may still refuse the call; that is expected behavior\nrather than a fault — proceed solo when it does.\n\nShort conversations, simple edits, and narrow-scope work do not pass the test.\nHandle those solo.\n\n## 2. Ask first — the self-test, and where solo wins\n\nWhen work looks like it passes that test, check it against the cases below\nbefore firing. Each is a place where the time saved looks real but is not, so\nsolo wins even though the test seemed to pass.\n\n- A request to explain how, why, or what is solo by default — an explanation does not get better by sweeping wide.\n- Solo wins when more than one round of polishing is expected — fanned-out agents cannot be resumed, so refining costs a full re-run.\n- Solo wins when the content is already in this session's context.\n- Solo wins when one target's workload is smaller than the cost of spawning one agent, and bundling targets still leaves a bundle under that cost.\n\n## 3. Activation preconditions\n\nFire only after ALL of these are settled:\n\n- **(a)** The target list is fixed by actual values or by a mechanically enumerable rule (a glob, a command's output). An estimated count or \"probably around here\" is NOT settled.\n- **(b)** One prompt template works for every target. If a sentence is needed for only one target, the set is not uniform.\n- **(c)** The return format is decided.\n- **(d)** What will be done with the results is decided.\n\nIf any one is undecided, scout inline first to settle it — **do not run the\nscouting itself as a fan-out**. For repeating patterns, state a repeat ceiling\nexplicitly. A fan-out launched to sweep without a gap must cover the whole\nsettled target list — **do not trim the list to fit a recommended agent\nceiling**; bundle targets instead.\n\n## 4. The one-line notice before firing\n\nAnnounce in exactly one line, in this order: **scope first**, then whether it\nis read-only or what it writes and where, then the agent-count ceiling. Example:\n\"auth 호출부 23곳 전수 감사, 읽기 전용, 에이전트 23개 이하\". What a human can\njudge in two seconds is the scope and whether it writes — not the number.\n\nFor a fan-out that changes nothing, fire immediately without waiting for an\nanswer. For a fan-out that changes something, pass the confirmation gate in §5\nfirst and give this notice afterwards, right before firing. **The notice is not\nan approval gate** — though it is an interruption opportunity, since the user\ncan skip a running agent. **Never substitute a one-line notice for confirmation\nof something hard to undo.**\n\n## 5. Confirmation gate — fan-outs that change things\n\n- Automatic firing is limited to fan-outs whose assigned work **changes nothing**. A fan-out that tells agents to edit files or mutate state MUST get user confirmation first, in the §4 notice form, regardless of any other condition. **Treat that confirmation as the last place a human sees this.**\n- If the answer is not an approval, do neither the fan-out nor a sequential application.\n- If there is no way to get an answer, or you asked and no answer came, or you have approval but cannot satisfy the conditions below (git repository, separated paths), then **neither ask again nor stop**: run the same fan-out read-only (analysis \u002F proposed diffs) and have the main session apply the results sequentially, with a one-line demotion reason.\n- Even with the user's approval to write, run it only inside a git repository and only when non-overlapping paths have been assigned per agent in advance.\n- **The harness skipping permission prompts does not exempt this gate — a permission prompt that does not appear is not an approval.** This holds even when the harness was started to skip permission checks and sub-agents inherited that.\n- **This rule propagates itself.** The spawning side writes this bullet into the agent prompt verbatim, whatever the tool; the receiving side fires only after confirming that its own prompt contains the sentence \"권한 프롬프트가 뜨지 않는 것은 승인이 아니다\". If it is absent, do not fire.\n\n## 6. Never delegate these\n\nDo NOT hand a fanned-out agent:\n\n- Acts that are hard to undo or that go outward — `git push`, commits, merges, creating or commenting on PRs \u002F issues, `gh auth switch`, deletions, external or MCP writes.\n- File edits that were not instructed.\n- Commands that touch the whole tree — formatters, codemods, `npm install`. (The standing \"install it rather than finding an alternative\" rule does NOT apply to a fanned-out agent.)\n- Edits to configuration, memory, or CLAUDE.md under the Claude Code configuration directory — `${CLAUDE_CONFIG_DIR:-$HOME\u002F.claude}` and every sibling directory sharing that `.claude` name prefix.\n\nDuring a skill run, whatever that skill forbids stays forbidden — **this rule\ndoes not loosen a skill's constraints**. Do not use a fan-out product in place\nof a team member's round product: the moment it is recorded as a ledger row, a\nwitness, or a member contribution it is forbidden. A lead reflecting research\nfindings in its own work (writing documents, designing questions) is not\ncovered by that. The reach of skill clauses aimed at team-round substitution\nends there too, so a read-only research fan-out is not their target — but if\nyou cannot identify what a clause targets, do not apply the exception.\n\nThe prohibitions above bind **this spawning session**. The constraints each\nagent must keep are written self-containedly into the agent prompt template —\n**if you cannot identify the clauses to write, do not fire.** Always write the\nprohibition list above in full and so that it makes sense on its own, and\nduring a skill run include that skill's prohibitions as well.\n\n## 7. Results\n\n- Filter results through `.filter(Boolean)` before using them, and `log()` the number sent against the number returned. Without the filter, a `null` sits in the failed slot and the counts look equal.\n- **If the number of returned results differs from the number of agents sent, do not use it as grounds for deleting, migrating, or removing anything** — a missing result is \"unknown\", not \"absent\".\n- If results come back empty or the run ends early, do not summarize from what is left alone — state what is missing.\n- Worktrees a fan-out creates (`isolation: \"worktree\"`) are separate from a worktree the user asked for (which must be a plain `git worktree`) and are not subject to that rule. But one left behind after an abnormal exit may be the only copy of a change — do not force-remove it; report it, on the same principle as post-merge cleanup (on failure: no force delete, no worktree removal, no stash — report only).\n\n## 8. Waiting while it runs\n\nDo not fire no-op progress checks or polling. Either do other work or yield the\nturn until results arrive on their own — results are delivered automatically.\n(A user asking for status is a command whose output is needed, so it is not\ncovered by this.)\n","# fanout-policy\n\nThe rules for handing work to other agents. **Scope is the act, not the tool\nname**: `Workflow`, `Agent`, any later dispatch tool, and launching a script\nthat starts agents all receive every rule below. Where this file says\n\"workflow agent\" and \"main session\" it means *the spawned agent* and *the\nspawning side* — the same things named after one tool.\n\n## 1. When a fan-out is worth it\n\nFan out when both hold:\n\n1. The pieces are independent of each other — no piece needs another piece's result.\n2. The wall-clock time saved is worth more than the extra tokens spent under the weekly usage limit.\n\nTypical fits are a sweep that must leave no gap, independent adversarial\nverification, and work too large for one context — but they fit because they\npass the two tests above, not because they are on a list. Whatever comes back,\ncheck the evidence behind each agent's result before you rely on it.\n\nThe user has given standing, advance opt-in for fanning out on work that passes\nthis test — it is the user's own request, it does not have to be repeated per\ntask, and CLAUDE.md \u002F memory instructions count as a direct user instruction for\nthis purpose. So when such work arrives and **what the agents are told to do\nchanges nothing**, call the fan-out without asking for approval, even outside a\nskill run. The harness may still refuse the call; that is expected behavior\nrather than a fault — proceed solo when it does.\n\nShort conversations, simple edits, and narrow-scope work do not pass the test.\nHandle those solo.\n\n## 2. Ask first — the self-test, and where solo wins\n\nWhen work looks like it passes that test, check it against the cases below\nbefore firing. Each is a place where the time saved looks real but is not, so\nsolo wins even though the test seemed to pass.\n\n- A request to explain how, why, or what is solo by default — an explanation does not get better by sweeping wide.\n- Solo wins when more than one round of polishing is expected — fanned-out agents cannot be resumed, so refining costs a full re-run.\n- Solo wins when the content is already in this session's context.\n- Solo wins when one target's workload is smaller than the cost of spawning one agent, and bundling targets still leaves a bundle under that cost.\n\n## 3. Activation preconditions\n\nFire only after ALL of these are settled:\n\n- **(a)** The target list is fixed by actual values or by a mechanically enumerable rule (a glob, a command's output). An estimated count or \"probably around here\" is NOT settled.\n- **(b)** One prompt template works for every target. If a sentence is needed for only one target, the set is not uniform.\n- **(c)** The return format is decided.\n- **(d)** What will be done with the results is decided.\n\nIf any one is undecided, scout inline first to settle it — **do not run the\nscouting itself as a fan-out**. For repeating patterns, state a repeat ceiling\nexplicitly. A fan-out launched to sweep without a gap must cover the whole\nsettled target list — **do not trim the list to fit a recommended agent\nceiling**; bundle targets instead.\n\n## 4. The one-line notice before firing\n\nAnnounce in exactly one line, in this order: **scope first**, then whether it\nis read-only or what it writes and where, then the agent-count ceiling. Example:\n\"auth 호출부 23곳 전수 감사, 읽기 전용, 에이전트 23개 이하\". What a human can\njudge in two seconds is the scope and whether it writes — not the number.\n\nFor a fan-out that changes nothing, fire immediately without waiting for an\nanswer. For a fan-out that changes something, pass the confirmation gate in §5\nfirst and give this notice afterwards, right before firing. **The notice is not\nan approval gate** — though it is an interruption opportunity, since the user\ncan skip a running agent. **Never substitute a one-line notice for confirmation\nof something hard to undo.**\n\n## 5. Confirmation gate — fan-outs that change things\n\n- Automatic firing is limited to fan-outs whose assigned work **changes nothing**. A fan-out that tells agents to edit files or mutate state MUST get user confirmation first, in the §4 notice form, regardless of any other condition. **Treat that confirmation as the last place a human sees this.**\n- If the answer is not an approval, do neither the fan-out nor a sequential application.\n- If there is no way to get an answer, or you asked and no answer came, or you have approval but cannot satisfy the conditions below (git repository, separated paths), then **neither ask again nor stop**: run the same fan-out read-only (analysis \u002F proposed diffs) and have the main session apply the results sequentially, with a one-line demotion reason.\n- Even with the user's approval to write, run it only inside a git repository and only when non-overlapping paths have been assigned per agent in advance.\n- **The harness skipping permission prompts does not exempt this gate — a permission prompt that does not appear is not an approval.** This holds even when the harness was started to skip permission checks and sub-agents inherited that.\n- **This rule propagates itself.** The spawning side writes this bullet into the agent prompt verbatim, whatever the tool; the receiving side fires only after confirming that its own prompt contains the sentence \"권한 프롬프트가 뜨지 않는 것은 승인이 아니다\". If it is absent, do not fire.\n\n## 6. Never delegate these\n\nDo NOT hand a fanned-out agent:\n\n- Acts that are hard to undo or that go outward — `git push`, commits, merges, creating or commenting on PRs \u002F issues, `gh auth switch`, deletions, external or MCP writes.\n- File edits that were not instructed.\n- Commands that touch the whole tree — formatters, codemods, `npm install`. (The standing \"install it rather than finding an alternative\" rule does NOT apply to a fanned-out agent.)\n- Edits to configuration, memory, or CLAUDE.md under the Claude Code configuration directory — `${CLAUDE_CONFIG_DIR:-$HOME\u002F.claude}` and every sibling directory sharing that `.claude` name prefix.\n\nDuring a skill run, whatever that skill forbids stays forbidden — **this rule\ndoes not loosen a skill's constraints**. Do not use a fan-out product in place\nof a team member's round product: the moment it is recorded as a ledger row, a\nwitness, or a member contribution it is forbidden. A lead reflecting research\nfindings in its own work (writing documents, designing questions) is not\ncovered by that. The reach of skill clauses aimed at team-round substitution\nends there too, so a read-only research fan-out is not their target — but if\nyou cannot identify what a clause targets, do not apply the exception.\n\nThe prohibitions above bind **this spawning session**. The constraints each\nagent must keep are written self-containedly into the agent prompt template —\n**if you cannot identify the clauses to write, do not fire.** Always write the\nprohibition list above in full and so that it makes sense on its own, and\nduring a skill run include that skill's prohibitions as well.\n\n## 7. Results\n\n- Filter results through `.filter(Boolean)` before using them, and `log()` the number sent against the number returned. Without the filter, a `null` sits in the failed slot and the counts look equal.\n- **If the number of returned results differs from the number of agents sent, do not use it as grounds for deleting, migrating, or removing anything** — a missing result is \"unknown\", not \"absent\".\n- If results come back empty or the run ends early, do not summarize from what is left alone — state what is missing.\n- Worktrees a fan-out creates (`isolation: \"worktree\"`) are separate from a worktree the user asked for (which must be a plain `git worktree`) and are not subject to that rule. But one left behind after an abnormal exit may be the only copy of a change — do not force-remove it; report it, on the same principle as post-merge cleanup (on failure: no force delete, no worktree removal, no stash — report only).\n\n## 8. Waiting while it runs\n\nDo not fire no-op progress checks or polling. Either do other work or yield the\nturn until results arrive on their own — results are delivered automatically.\n(A user asking for status is a command whose output is needed, so it is not\ncovered by this.)\n",{"name":5,"notes":30,"usage":31,"options":32,"description":7,"when_to_use":33,"disable-model-invocation":26},"슬래시 커맨드 surface 가 없는 model-invoked 정책 스킬이다. 여기 실린 규약은 도구 이름이\n아니라 「다른 에이전트에게 일을 시키는가」로 발동하며, `Workflow`·`Agent`·후속 디스패치\n도구·스크립트 기동을 전부 덮는다. 이 스킬은 팬아웃을 대신 발동하지 않는다 — 절차만 싣는다.","(자동 호출 — 슬래시 커맨드 없음. 다른 에이전트에게 일을 시키기 전에 모델이 열어 그대로 따른다.)",[],"팬아웃·병렬 에이전트·워크플로 사용을 검토할 때와 발동 직전. 도구(`Workflow`·`Agent`·후속 디스패치 도구·스크립트 기동)를 가리지 않는다","master","f5e7f5e77d5e8603b1ec0e9247198315c7910461","plugins\u002Fcc-cmds\u002Fskills\u002Ffanout-policy",1,"https:\u002F\u002Fgithub.com\u002FNharu\u002Fcc-cmds","https:\u002F\u002Fgithub.com\u002FNharu","2026-11-12 03:16:50",{"source":8,"skillName":5,"commands":42,"prompt":52,"zipAvailable":53},[43,46,49],{"tool":44,"command":45},"npx","npx skills add Nharu\u002Fcc-cmds --skill fanout-policy",{"tool":47,"command":48},"bunx","bunx skills add Nharu\u002Fcc-cmds --skill fanout-policy",{"tool":50,"command":51},"pnpm","pnpm dlx skills add Nharu\u002Fcc-cmds --skill fanout-policy","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FNharu\u002Fcc-cmds\u002Fblob\u002Fmaster\u002Fplugins\u002Fcc-cmds\u002Fskills\u002Ffanout-policy\u002FSKILL.md",true,[55],{"path":56,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":59,"sourceHtmlUrl":60},"index.json","REFERENCE","参考文档",680,"https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fdatabase\u002Flogging\u002Fsyslog\u002Fverify\u002Findex.json",[62,74,89,96,111,123],{"skillNo":63,"name":64,"nameZh":6,"description":65,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":66,"categories":67,"keywords":68,"publishedAt":25},"01M6DNB8T41Y37D3M9JKHFT7HV","zeroargs","zero-argument command","https:\u002F\u002Fgithub.com\u002FNharu\u002Fcc-cmds\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Freadme-gen\u002Fsimple\u002Fzeroargs\u002FSKILL.md",[],[64,69,70,71,72,73],"when","argument","cc","command","ZeRO",{"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":85,"publishedAt":25},"01M6DNB5TG3T9QMEF3HPKJPER0","review","에이전트 팀을 활용한 다관점 코드 리뷰","https:\u002F\u002Fgithub.com\u002FNharu\u002Fcc-cmds\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Freadme-gen\u002Fpre-yq-skills\u002Freview\u002FSKILL.md",[80],{"categoryNo":81,"categoryName":82,"taxonomyType":83,"taxonomyTypeDesc":84},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[76,86,87,88],"pr","true","diff",{"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":25},"01M6DNAYNZFJR1TATEM9PVHGH2","implement","설계 문서 기반 구현","https:\u002F\u002Fgithub.com\u002FNharu\u002Fcc-cmds\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Freadme-gen\u002Fpre-yq-skills\u002Fimplement\u002FSKILL.md",[],[91,87],{"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":110,"publishedAt":25},"01M6DNAVQF4KERY94V79NVWAZA","design","에이전트 팀을 활용한 기능 설계 토론 진행","https:\u002F\u002Fgithub.com\u002FNharu\u002Fcc-cmds\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Freadme-gen\u002Fpre-yq-skills\u002Fdesign\u002FSKILL.md",[102,105],{"categoryNo":103,"categoryName":104,"taxonomyType":83,"taxonomyTypeDesc":84},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":106,"categoryName":107,"taxonomyType":108,"taxonomyTypeDesc":109},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[98,87],{"skillNo":112,"name":113,"nameZh":6,"description":114,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":115,"categories":116,"keywords":119,"publishedAt":25},"01M6DNASB3J3JQMZD57YBDHZ1A","design-upgrade","팀원 모델 업그레이드 분석","https:\u002F\u002Fgithub.com\u002FNharu\u002Fcc-cmds\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Freadme-gen\u002Fpre-yq-skills\u002Fdesign-upgrade\u002FSKILL.md",[117,118],{"categoryNo":103,"categoryName":104,"taxonomyType":83,"taxonomyTypeDesc":84},{"categoryNo":106,"categoryName":107,"taxonomyType":108,"taxonomyTypeDesc":109},[120,98,121,87,122],"design upgrade","upgrade","haiku",{"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":131,"publishedAt":25},"01M6DNAA53K13C0REE8FDT3QHR","design-review","설계 문서 최종 리뷰","https:\u002F\u002Fgithub.com\u002FNharu\u002Fcc-cmds\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Freadme-gen\u002Fpre-yq-skills\u002Fdesign-review\u002FSKILL.md",[129,130],{"categoryNo":103,"categoryName":104,"taxonomyType":83,"taxonomyTypeDesc":84},{"categoryNo":106,"categoryName":107,"taxonomyType":108,"taxonomyTypeDesc":109},[76,98,132,87],"design review"]