[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6GX6H0T4PAPP1HM754G2SRA":3,"skill-same:01M6GX6H0T4PAPP1HM754G2SRA":89},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":22,"publishedAt":29,"linkOnly":30,"markdownContent":31,"markdownBody":32,"frontMatter":33,"refName":34,"commitSha":35,"skillDirectory":36,"forksCount":37,"repositoryHtmlUrl":38,"repositoryHomepageUrl":6,"ownerHtmlUrl":39,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":40,"install":41,"resources":54},"01M6GX6H0T4PAPP1HM754G2SRA","agent-pipeline",null,"Multi-agent pipeline orchestration skill","autopus-ai\u002Fautopus-adk","autopus-ai","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F327805805?v=4","01M6GX6DDW0BA7MCYD3799BYEF","01M6GX6DJ6FKVZVDKSPQTNNPME",109,"MIT","https:\u002F\u002Fgithub.com\u002Fautopus-ai\u002Fautopus-adk\u002Fblob\u002Fmain\u002F.omp\u002Fskills\u002Fagent-pipeline\u002FSKILL.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[23,24,25,26,27,28],"pipeline","agent pipeline","orchestration","multi-agent","omp","multi","2026-11-10 10:12:30",false,"---\nname: agent-pipeline\ndescription: Multi-agent pipeline orchestration skill\ncompatibility: omp\n---\n\n# OMP Native Agent Pipeline\n\nUse for `\u002Fauto go SPEC-ID [--execution-owner omp|orca]`. This entrypoint selects\nwork and context; open only the reference needed for the current step.\n\n| Need | Open |\n|---|---|\n| Phase entry, work, and exit conditions | `references\u002Fphases.md` |\n| Worker ownership and context isolation | `references\u002Fdelegation.md` |\n| Change classification and gate evidence | `references\u002Fgates.md` |\n| Tests, smoke checks, and UX verification | `references\u002Fverification.md` |\n| Review authority and termination | `references\u002Freview.md` |\n| Completion and sync readiness | `references\u002Fcompletion.md` |\n| Configured quality and permissions | `references\u002Fquality-modes.md` |\n\n## Execution Decision\n\nWork in the current session by default. Dispatch only genuinely independent\nslices, a necessary specialist review, or work that needs isolated context.\nFile count and line count do not justify delegation. Keep dependent or\nsame-file work sequential; one migration-numbering lane has one writer.\n\nA verified low-risk compact change contract omits separate planning and test\nscaffold dispatch: implementation still starts with the relevant failing test,\nthen validation and review run. Missing, ambiguous, or escalated authorization\nkeeps the full route. Report the actual `route_phase_set` from `auto pipeline\nrun`, not an imagined phase checklist. Explicit `--solo`, `--team`, and\n`--multi` requests must retain their requested semantics.\n\n## Execution Owner\n\nChoose exactly one DAG owner before any dispatch: `--execution-owner omp|orca`.\nOmission selects `omp`. Reject duplicate, aliased, or conflicting owner flags;\nnever retry a failed explicitly selected owner as another owner.\n\n- Owner `omp`: this session owns progress through native `task` and `todo`,\n  coordinating jobs with `wait`, `read proc:\u002F\u002F`, `write proc:\u002F\u002F\u003Cid>\u002Fkill`, and\n  `write agent:\u002F\u002F\u003Cid>` (OMP 18.3+) or `hub` (older OMP). `--solo` keeps work in\n  this session; `--team` requests a native batch with explicit\n  responsibilities. The two flags conflict.\n- Owner `orca`: only an explicit `--execution-owner orca` selects it. First run\n  and read `orca skills get orchestration --full`; the Orca Run owns the DAG.\n  Do not create a competing OMP task or progress DAG. `--team` and `--solo`\n  conflict with this owner.\n- `--multi` requests risk-tiered provider-diverse evidence, not a second DAG.\n\n`auto pipeline run SPEC-ID --platform omp --execution-owner orca` performs the\nintegrity check and records `pipeline_execution_owner_receipt.v1` before any\nworker session. The body-free `.autopus\u002Fpipeline-state\u002F\u003CSPEC-ID>.execution-owner.json`\nrecords owner, source, identity, and verification status.\n\n## Native Dispatch\n\nBefore dispatch, inspect the tools actually exposed by this runtime. Use their\ncurrent schemas rather than copying static payloads. If the selected topology\nrequires an unavailable tool, report that blocker; never simulate dispatch.\n\nOMP serves this project's 17 Autopus agents from `.omp\u002Fagents\u002F`:\n`annotator`, `architect`, `debugger`, `deep-worker`, `devops`, `executor`,\n`explorer`, `frontend-specialist`, `perf-engineer`, `planner`,\n`reverse-engineer`, `reviewer`, `security-auditor`, `spec-writer`, `tester`,\n`ux-validator`, and `validator`. Select the agent of the role a worker plays:\n\n- `planner`, `architect`, and `spec-writer` plan and design; `executor`,\n  `debugger`, `tester`, and the other implementation roles write code.\n- `explorer` is read-only exploration only. Never give it work that writes.\n- `reverse-engineer` only analyses an existing app or binary into a behaviour\n  specification; never give it implementation work.\n- `reviewer`, `validator`, and `security-auditor` review and verify; keep them\n  off implementation.\n- Omitting the agent runs the bundled `task` agent, the default for work no\n  role fits. Every other bundled agent (`scout`, `security-reviewer`, `sonic`,\n  `designer`, `librarian`) is disabled through `task.disabledAgents`; never\n  select them.\n\nThe agent field names the role; the assignment text still states its scope.\nState the responsibility, scope, and exit condition in the task itself.\n\nBatch independent owned slices together. Native OMP owns isolated worktree\ncreation, integration, and cleanup. Request isolation only if the current\n`task` schema exposes it; do not manually merge or remove its worktrees.\n\nEach worker receives scope, forbidden paths, acceptance criteria, and only its\nneeded context. Request the five-field result contract: `owned_paths`,\n`changed_files`, `verification`, `blockers`, `next_required_step`. Use native\nschema validation where supported; worker assertions are not execution proof.\nRecord actual dispatch count and the native agents used. Follow up with the\nsame revivable worker through `write agent:\u002F\u002F\u003Cid>` (OMP 18.3+) or `hub` (older\nOMP); an isolated worker whose workspace has been released needs a new\nassignment. Only the parent owns `todo`.\n\nA worker that stops at its turn limit returns a partial result; the turn-budget\nrule every assignment carries (`references\u002Fdelegation.md`, Worker hygiene)\nkeeps that rare. Never treat a partial result as a completed phase or feed it to\nthe next phase. Follow up once with a narrowed instruction (finish and write the\nartifact, minimal further exploration), through that follow-up path or as a new\nassignment as above; if that run is partial again, stop and\nhand the phase to the user with what was produced.\n\n## Context and Models\n\nKeep required core\u002FSPEC bodies complete and hash-verified. Ordinary\n`auto workflow context` includes optional architecture only when explicitly\nselected. The managed OMP evidence path independently rebuilds its canonical\nfull context: do not substitute a smaller CLI manifest, alter its signed\nprotocol, or promote an unmeasured compaction result.\n\nGive workers task deltas and retrievable references instead of replaying raw\nprovider\u002Ftool output. Validate paths and hashes; reject missing required\ncontext, traversal, symlinks, stale or wrong-SPEC input before dispatch. Use\nnative context management rather than layering an extra summarization loop.\n\nInherit the current OMP session model and thinking configuration unless an\nexplicit validated role-model profile has written `task.agentModelOverrides`\nfor the native agent being dispatched. That configuration is the only model\nauthority: never pass a guessed model ID, and never pick a cheaper agent to\nfit a larger task.\n\n## Gates and Completion\n\nUse `auto spec gates` for applicability and exact-input evidence reuse.\nSecurity, validation, data-loss, and deterministic-oracle gates remain active;\nUI changes retain accessibility and UX verification. Annotation is opt-in via\n`--annotation` or a direct request, not an automatic extra worker phase.\nHonor explicit project\u002Froute numerical gates; do not invent universal floors.\n\nIntegrate changes before the merged verification run. Keep a verdict and real\nevidence per acceptance criterion. Failed tests or security findings cannot be\noverruled by provider consensus. Re-review only changed\u002Fopen findings; unchanged\ninput is not a reason to repeat discovery. Respect the existing retry limits.\n\nFinish only after the changed path has run, required acceptance is satisfied,\nand blocking findings are closed. Use `references\u002Fcompletion.md` for the sync\nreceipt. Status combines project\u002FSPEC state with the selected owner's native\njob state; external commands must not inspect user-owned OMP session roots or\nclaim they replace native job observations (`read proc:\u002F\u002F` on OMP 18.3+, `hub`\non older OMP).\n","# OMP Native Agent Pipeline\n\nUse for `\u002Fauto go SPEC-ID [--execution-owner omp|orca]`. This entrypoint selects\nwork and context; open only the reference needed for the current step.\n\n| Need | Open |\n|---|---|\n| Phase entry, work, and exit conditions | `references\u002Fphases.md` |\n| Worker ownership and context isolation | `references\u002Fdelegation.md` |\n| Change classification and gate evidence | `references\u002Fgates.md` |\n| Tests, smoke checks, and UX verification | `references\u002Fverification.md` |\n| Review authority and termination | `references\u002Freview.md` |\n| Completion and sync readiness | `references\u002Fcompletion.md` |\n| Configured quality and permissions | `references\u002Fquality-modes.md` |\n\n## Execution Decision\n\nWork in the current session by default. Dispatch only genuinely independent\nslices, a necessary specialist review, or work that needs isolated context.\nFile count and line count do not justify delegation. Keep dependent or\nsame-file work sequential; one migration-numbering lane has one writer.\n\nA verified low-risk compact change contract omits separate planning and test\nscaffold dispatch: implementation still starts with the relevant failing test,\nthen validation and review run. Missing, ambiguous, or escalated authorization\nkeeps the full route. Report the actual `route_phase_set` from `auto pipeline\nrun`, not an imagined phase checklist. Explicit `--solo`, `--team`, and\n`--multi` requests must retain their requested semantics.\n\n## Execution Owner\n\nChoose exactly one DAG owner before any dispatch: `--execution-owner omp|orca`.\nOmission selects `omp`. Reject duplicate, aliased, or conflicting owner flags;\nnever retry a failed explicitly selected owner as another owner.\n\n- Owner `omp`: this session owns progress through native `task` and `todo`,\n  coordinating jobs with `wait`, `read proc:\u002F\u002F`, `write proc:\u002F\u002F\u003Cid>\u002Fkill`, and\n  `write agent:\u002F\u002F\u003Cid>` (OMP 18.3+) or `hub` (older OMP). `--solo` keeps work in\n  this session; `--team` requests a native batch with explicit\n  responsibilities. The two flags conflict.\n- Owner `orca`: only an explicit `--execution-owner orca` selects it. First run\n  and read `orca skills get orchestration --full`; the Orca Run owns the DAG.\n  Do not create a competing OMP task or progress DAG. `--team` and `--solo`\n  conflict with this owner.\n- `--multi` requests risk-tiered provider-diverse evidence, not a second DAG.\n\n`auto pipeline run SPEC-ID --platform omp --execution-owner orca` performs the\nintegrity check and records `pipeline_execution_owner_receipt.v1` before any\nworker session. The body-free `.autopus\u002Fpipeline-state\u002F\u003CSPEC-ID>.execution-owner.json`\nrecords owner, source, identity, and verification status.\n\n## Native Dispatch\n\nBefore dispatch, inspect the tools actually exposed by this runtime. Use their\ncurrent schemas rather than copying static payloads. If the selected topology\nrequires an unavailable tool, report that blocker; never simulate dispatch.\n\nOMP serves this project's 17 Autopus agents from `.omp\u002Fagents\u002F`:\n`annotator`, `architect`, `debugger`, `deep-worker`, `devops`, `executor`,\n`explorer`, `frontend-specialist`, `perf-engineer`, `planner`,\n`reverse-engineer`, `reviewer`, `security-auditor`, `spec-writer`, `tester`,\n`ux-validator`, and `validator`. Select the agent of the role a worker plays:\n\n- `planner`, `architect`, and `spec-writer` plan and design; `executor`,\n  `debugger`, `tester`, and the other implementation roles write code.\n- `explorer` is read-only exploration only. Never give it work that writes.\n- `reverse-engineer` only analyses an existing app or binary into a behaviour\n  specification; never give it implementation work.\n- `reviewer`, `validator`, and `security-auditor` review and verify; keep them\n  off implementation.\n- Omitting the agent runs the bundled `task` agent, the default for work no\n  role fits. Every other bundled agent (`scout`, `security-reviewer`, `sonic`,\n  `designer`, `librarian`) is disabled through `task.disabledAgents`; never\n  select them.\n\nThe agent field names the role; the assignment text still states its scope.\nState the responsibility, scope, and exit condition in the task itself.\n\nBatch independent owned slices together. Native OMP owns isolated worktree\ncreation, integration, and cleanup. Request isolation only if the current\n`task` schema exposes it; do not manually merge or remove its worktrees.\n\nEach worker receives scope, forbidden paths, acceptance criteria, and only its\nneeded context. Request the five-field result contract: `owned_paths`,\n`changed_files`, `verification`, `blockers`, `next_required_step`. Use native\nschema validation where supported; worker assertions are not execution proof.\nRecord actual dispatch count and the native agents used. Follow up with the\nsame revivable worker through `write agent:\u002F\u002F\u003Cid>` (OMP 18.3+) or `hub` (older\nOMP); an isolated worker whose workspace has been released needs a new\nassignment. Only the parent owns `todo`.\n\nA worker that stops at its turn limit returns a partial result; the turn-budget\nrule every assignment carries (`references\u002Fdelegation.md`, Worker hygiene)\nkeeps that rare. Never treat a partial result as a completed phase or feed it to\nthe next phase. Follow up once with a narrowed instruction (finish and write the\nartifact, minimal further exploration), through that follow-up path or as a new\nassignment as above; if that run is partial again, stop and\nhand the phase to the user with what was produced.\n\n## Context and Models\n\nKeep required core\u002FSPEC bodies complete and hash-verified. Ordinary\n`auto workflow context` includes optional architecture only when explicitly\nselected. The managed OMP evidence path independently rebuilds its canonical\nfull context: do not substitute a smaller CLI manifest, alter its signed\nprotocol, or promote an unmeasured compaction result.\n\nGive workers task deltas and retrievable references instead of replaying raw\nprovider\u002Ftool output. Validate paths and hashes; reject missing required\ncontext, traversal, symlinks, stale or wrong-SPEC input before dispatch. Use\nnative context management rather than layering an extra summarization loop.\n\nInherit the current OMP session model and thinking configuration unless an\nexplicit validated role-model profile has written `task.agentModelOverrides`\nfor the native agent being dispatched. That configuration is the only model\nauthority: never pass a guessed model ID, and never pick a cheaper agent to\nfit a larger task.\n\n## Gates and Completion\n\nUse `auto spec gates` for applicability and exact-input evidence reuse.\nSecurity, validation, data-loss, and deterministic-oracle gates remain active;\nUI changes retain accessibility and UX verification. Annotation is opt-in via\n`--annotation` or a direct request, not an automatic extra worker phase.\nHonor explicit project\u002Froute numerical gates; do not invent universal floors.\n\nIntegrate changes before the merged verification run. Keep a verdict and real\nevidence per acceptance criterion. Failed tests or security findings cannot be\noverruled by provider consensus. Re-review only changed\u002Fopen findings; unchanged\ninput is not a reason to repeat discovery. Respect the existing retry limits.\n\nFinish only after the changed path has run, required acceptance is satisfied,\nand blocking findings are closed. Use `references\u002Fcompletion.md` for the sync\nreceipt. Status combines project\u002FSPEC state with the selected owner's native\njob state; external commands must not inspect user-owned OMP session roots or\nclaim they replace native job observations (`read proc:\u002F\u002F` on OMP 18.3+, `hub`\non older OMP).\n",{"name":5,"description":7,"compatibility":27},"main","4f21f3091a165c082859130de920aaeb017efad8",".omp\u002Fskills\u002Fagent-pipeline",73,"https:\u002F\u002Fgithub.com\u002Fautopus-ai\u002Fautopus-adk","https:\u002F\u002Fgithub.com\u002Fautopus-ai","2026-11-13 23:26:03",{"source":8,"skillName":5,"commands":42,"prompt":52,"zipAvailable":53},[43,46,49],{"tool":44,"command":45},"npx","npx skills add autopus-ai\u002Fautopus-adk --skill agent-pipeline",{"tool":47,"command":48},"bunx","bunx skills add autopus-ai\u002Fautopus-adk --skill agent-pipeline",{"tool":50,"command":51},"pnpm","pnpm dlx skills add autopus-ai\u002Fautopus-adk --skill agent-pipeline","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fautopus-ai\u002Fautopus-adk\u002Fblob\u002Fmain\u002F.omp\u002Fskills\u002Fagent-pipeline\u002FSKILL.md",true,[55,61,65,69,73,77,81,85],{"path":56,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":59,"sourceHtmlUrl":60},"references\u002Fcompletion.md","REFERENCE","参考文档",5162,"https:\u002F\u002Fgithub.com\u002Fautopus-ai\u002Fautopus-adk\u002Fblob\u002Fmain\u002F.omp\u002Fskills\u002Fagent-pipeline\u002Freferences\u002Fcompletion.md",{"path":62,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":63,"sourceHtmlUrl":64},"references\u002Fcoordination.md",3600,"https:\u002F\u002Fgithub.com\u002Fautopus-ai\u002Fautopus-adk\u002Fblob\u002Fmain\u002F.omp\u002Fskills\u002Fagent-pipeline\u002Freferences\u002Fcoordination.md",{"path":66,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":67,"sourceHtmlUrl":68},"references\u002Fdelegation.md",11812,"https:\u002F\u002Fgithub.com\u002Fautopus-ai\u002Fautopus-adk\u002Fblob\u002Fmain\u002F.omp\u002Fskills\u002Fagent-pipeline\u002Freferences\u002Fdelegation.md",{"path":70,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":71,"sourceHtmlUrl":72},"references\u002Fgates.md",6481,"https:\u002F\u002Fgithub.com\u002Fautopus-ai\u002Fautopus-adk\u002Fblob\u002Fmain\u002F.omp\u002Fskills\u002Fagent-pipeline\u002Freferences\u002Fgates.md",{"path":74,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":75,"sourceHtmlUrl":76},"references\u002Fphases.md",10392,"https:\u002F\u002Fgithub.com\u002Fautopus-ai\u002Fautopus-adk\u002Fblob\u002Fmain\u002F.omp\u002Fskills\u002Fagent-pipeline\u002Freferences\u002Fphases.md",{"path":78,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":79,"sourceHtmlUrl":80},"references\u002Fquality-modes.md",4338,"https:\u002F\u002Fgithub.com\u002Fautopus-ai\u002Fautopus-adk\u002Fblob\u002Fmain\u002F.omp\u002Fskills\u002Fagent-pipeline\u002Freferences\u002Fquality-modes.md",{"path":82,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":83,"sourceHtmlUrl":84},"references\u002Freview.md",4698,"https:\u002F\u002Fgithub.com\u002Fautopus-ai\u002Fautopus-adk\u002Fblob\u002Fmain\u002F.omp\u002Fskills\u002Fagent-pipeline\u002Freferences\u002Freview.md",{"path":86,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":87,"sourceHtmlUrl":88},"references\u002Fverification.md",11033,"https:\u002F\u002Fgithub.com\u002Fautopus-ai\u002Fautopus-adk\u002Fblob\u002Fmain\u002F.omp\u002Fskills\u002Fagent-pipeline\u002Freferences\u002Fverification.md",[90,96,110,117,126,140],{"skillNo":91,"name":92,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":93,"categories":94,"keywords":95,"publishedAt":29},"01M6GXC22ZCVSKYJXPE5ZE51ZV","auto","https:\u002F\u002Fgithub.com\u002Fautopus-ai\u002Fautopus-adk\u002Fblob\u002Fmain\u002Ftestdata\u002Fupgrade\u002Fv0.50.108\u002F.agents\u002Fskills\u002Fauto\u002FSKILL.md",[],[92],{"skillNo":97,"name":98,"nameZh":6,"description":99,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":100,"categories":101,"keywords":103,"publishedAt":29},"01M6GXBY8KS4F365HYZFCP8MDG","worktree-isolation","Worktree isolation for parallel agent execution in the pipeline","https:\u002F\u002Fgithub.com\u002Fautopus-ai\u002Fautopus-adk\u002Fblob\u002Fmain\u002F.omp\u002Fskills\u002Fworktree-isolation\u002FSKILL.md",[102],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[104,105,106,107,27,108,109,23],"worktree isolation","isolation","worktree","for","parallel","execution",{"skillNo":111,"name":112,"nameZh":6,"description":113,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":114,"categories":115,"keywords":116,"publishedAt":29},"01M6GXBR2JFP9AG6XW059P9508","verification","구현 결과 검증 및 품질 게이트 통과 스킬","https:\u002F\u002Fgithub.com\u002Fautopus-ai\u002Fautopus-adk\u002Fblob\u002Fmain\u002F.omp\u002Fskills\u002Fverification\u002FSKILL.md",[],[112,27],{"skillNo":118,"name":119,"nameZh":6,"description":120,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":121,"categories":122,"keywords":123,"publishedAt":29},"01M6GXBJWVA7CA2Y0QFMC9WMYF","using-autopus","Autopus-ADK 설치 및 활용 가이드 스킬","https:\u002F\u002Fgithub.com\u002Fautopus-ai\u002Fautopus-adk\u002Fblob\u002Fmain\u002F.omp\u002Fskills\u002Fusing-autopus\u002FSKILL.md",[],[124,27,125],"using autopus","adk",{"skillNo":127,"name":128,"nameZh":6,"description":129,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":130,"categories":131,"keywords":135,"publishedAt":29},"01M6GXBFA7F84VAZHW7XA612X5","testing-strategy","통합\u002FE2E\u002F계약 테스트 전략 및 테스트 피라미드","https:\u002F\u002Fgithub.com\u002Fautopus-ai\u002Fautopus-adk\u002Fblob\u002Fmain\u002F.omp\u002Fskills\u002Ftesting-strategy\u002FSKILL.md",[132],{"categoryNo":133,"categoryName":134,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000008","测试与质量",[136,137,138,27,139],"testing","strategy","testing strategy","e2e",{"skillNo":141,"name":142,"nameZh":6,"description":143,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":144,"categories":145,"keywords":146,"publishedAt":29},"01M6GXBB988G8Q86YH7S0K4FWT","tdd","Test-Driven Development 방법론 스킬","https:\u002F\u002Fgithub.com\u002Fautopus-ai\u002Fautopus-adk\u002Fblob\u002Fmain\u002F.omp\u002Fskills\u002Ftdd\u002FSKILL.md",[],[142,147,148,27,149,150],"test-driven","driven","development","test"]