[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6P6TY42HMXZWBB5TM8J5R7D":3,"skill-same:01M6P6TY42HMXZWBB5TM8J5R7D":66},{"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":17,"publishedAt":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":20,"commitSha":47,"skillDirectory":48,"forksCount":13,"repositoryHtmlUrl":49,"repositoryHomepageUrl":6,"ownerHtmlUrl":50,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":51,"install":52,"resources":65},"01M6P6TY42HMXZWBB5TM8J5R7D","incremental-implementation",null,"Delivers changes incrementally. Use when implementing any feature or change that touches more than one file. Use when you're about to write a large amount of code at once, or when a task feels too big to land in one step.","duc-duy-1612\u002FOnline-Delivery-Systems-Web","duc-duy-1612","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F192231384?v=4","01M6NSDKQQDKVTHZ8DZMZ1VYY6","01M6NSDKW8DDVTQHBT1HBDDJPT",0,"MIT","https:\u002F\u002Fgithub.com\u002Fduc-duy-1612\u002FOnline-Delivery-Systems-Web\u002Fblob\u002Fmain\u002F.agents\u002Fskills_archive\u002Fincremental-implementation\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"incremental implementation","implementation","main","implementing","at","tree","more","re","you","critical","feature","wed","change","community","agent-skills","use","write","license","land","code","2026-11-10 10:12:30",false,"---\nname: incremental-implementation\ndescription: Delivers changes incrementally. Use when implementing any feature or change that touches more than one file. Use when you're about to write a large amount of code at once, or when a task feels too big to land in one step.\nrisk: critical\nsource: https:\u002F\u002Fgithub.com\u002Faddyosmani\u002Fagent-skills\u002Ftree\u002Fmain\u002Fskills\u002Fincremental-implementation\nsource_repo: addyosmani\u002Fagent-skills\nsource_type: community\ndate_added: 2026-07-01\nlicense: MIT\nlicense_source: https:\u002F\u002Fgithub.com\u002Faddyosmani\u002Fagent-skills\u002Fblob\u002Fmain\u002FLICENSE\n---\n\n# Incremental Implementation\n\n## Overview\n\nBuild in thin vertical slices — implement one piece, test it, verify it, then expand. Avoid implementing an entire feature in one pass. Each increment should leave the system in a working, testable state. This is the execution discipline that makes large features manageable.\n\n## When to Use\n\n- Implementing any multi-file change\n- Building a new feature from a task breakdown\n- Refactoring existing code\n- Any time you're tempted to write more than ~100 lines before testing\n\n**When NOT to use:** Single-file, single-function changes where the scope is already minimal.\n\n## The Increment Cycle\n\n```\n┌──────────────────────────────────────┐\n│                                      │\n│   Implement ──→ Test ──→ Verify ──┐  │\n│       ▲                           │  │\n│       └───── Commit ◄─────────────┘  │\n│              │                       │\n│              ▼                       │\n│          Next slice                  │\n│                                      │\n└──────────────────────────────────────┘\n```\n\nFor each slice:\n\n1. **Implement** the smallest complete piece of functionality\n2. **Test** — run the test suite (or write a test if none exists)\n3. **Verify** — confirm the slice works as expected (tests pass, build succeeds, manual check)\n4. **Commit** -- save your progress with a descriptive message (see `git-workflow-and-versioning` for atomic commit guidance)\n5. **Move to the next slice** — carry forward, don't restart\n\n## Slicing Strategies\n\n### Vertical Slices (Preferred)\n\nBuild one complete path through the stack:\n\n```\nSlice 1: Create a task (DB + API + basic UI)\n    → Tests pass, user can create a task via the UI\n\nSlice 2: List tasks (query + API + UI)\n    → Tests pass, user can see their tasks\n\nSlice 3: Edit a task (update + API + UI)\n    → Tests pass, user can modify tasks\n\nSlice 4: Delete a task (delete + API + UI + confirmation)\n    → Tests pass, full CRUD complete\n```\n\nEach slice delivers working end-to-end functionality.\n\n### Contract-First Slicing\n\nWhen backend and frontend need to develop in parallel:\n\n```\nSlice 0: Define the API contract (types, interfaces, OpenAPI spec)\nSlice 1a: Implement backend against the contract + API tests\nSlice 1b: Implement frontend against mock data matching the contract\nSlice 2: Integrate and test end-to-end\n```\n\n### Risk-First Slicing\n\nTackle the riskiest or most uncertain piece first:\n\n```\nSlice 1: Prove the WebSocket connection works (highest risk)\nSlice 2: Build real-time task updates on the proven connection\nSlice 3: Add offline support and reconnection\n```\n\nIf Slice 1 fails, you discover it before investing in Slices 2 and 3.\n\n## Implementation Rules\n\n### Rule 0: Simplicity First\n\nBefore writing any code, ask: \"What is the simplest thing that could work?\"\n\nAfter writing code, review it against these checks:\n- Can this be done in fewer lines?\n- Are these abstractions earning their complexity?\n- Would a staff engineer look at this and say \"why didn't you just...\"?\n- Am I building for hypothetical future requirements, or the current task?\n\n```\nSIMPLICITY CHECK:\n✗ Generic EventBus with middleware pipeline for one notification\n✓ Simple function call\n\n✗ Abstract factory pattern for two similar components\n✓ Two straightforward components with shared utilities\n\n✗ Config-driven form builder for three forms\n✓ Three form components\n```\n\nThree similar lines of code is better than a premature abstraction. Implement the naive, obviously-correct version first. Optimize only after correctness is proven with tests.\n\n### Rule 0.5: Scope Discipline\n\nTouch only what the task requires.\n\nDo NOT:\n- \"Clean up\" code adjacent to your change\n- Refactor imports in files you're not modifying\n- Remove comments you don't fully understand\n- Add features not in the spec because they \"seem useful\"\n- Modernize syntax in files you're only reading\n\nIf you notice something worth improving outside your task scope, note it — don't fix it:\n\n```\nNOTICED BUT NOT TOUCHING:\n- src\u002Futils\u002Fformat.ts has an unused import (unrelated to this task)\n- The auth middleware could use better error messages (separate task)\n→ Want me to create tasks for these?\n```\n\n### Rule 1: One Thing at a Time\n\nEach increment changes one logical thing. Don't mix concerns:\n\n**Bad:** One commit that adds a new component, refactors an existing one, and updates the build config.\n\n**Good:** Three separate commits — one for each change.\n\n### Rule 2: Keep It Compilable\n\nAfter each increment, the project must build and existing tests must pass. Don't leave the codebase in a broken state between slices.\n\n### Rule 3: Feature Flags for Incomplete Features\n\nIf a feature isn't ready for users but you need to merge increments:\n\n```typescript\n\u002F\u002F Feature flag for work-in-progress\nconst ENABLE_TASK_SHARING = process.env.FEATURE_TASK_SHARING === 'true';\n\nif (ENABLE_TASK_SHARING) {\n  \u002F\u002F New sharing UI\n}\n```\n\nThis lets you merge small increments to the main branch without exposing incomplete work.\n\n### Rule 4: Safe Defaults\n\nNew code should default to safe, conservative behavior:\n\n```typescript\n\u002F\u002F Safe: disabled by default, opt-in\nexport function createTask(data: TaskInput, options?: { notify?: boolean }) {\n  const shouldNotify = options?.notify ?? false;\n  \u002F\u002F ...\n}\n```\n\n### Rule 5: Rollback-Friendly\n\nEach increment should be independently revertable:\n\n- Additive changes (new files, new functions) are easy to revert\n- Modifications to existing code should be minimal and focused\n- Database migrations should have corresponding rollback migrations\n- Avoid deleting something in one commit and replacing it in the same commit — separate them\n\n## Working with Agents\n\nWhen directing an agent to implement incrementally:\n\n```\n\"Let's implement Task 3 from the plan.\n\nStart with just the database schema change and the API endpoint.\nDon't touch the UI yet — we'll do that in the next increment.\n\nAfter implementing, run `npm test` and `npm run build` to verify\nnothing is broken.\"\n```\n\nBe explicit about what's in scope and what's NOT in scope for each increment.\n\n## Increment Checklist\n\nAfter each increment, verify:\n\n- [ ] The change does one thing and does it completely\n- [ ] All existing tests still pass (`npm test`)\n- [ ] The build succeeds (`npm run build`)\n- [ ] Type checking passes (`npx tsc --noEmit`)\n- [ ] Linting passes (`npm run lint`)\n- [ ] The new functionality works as expected\n- [ ] The change is committed with a descriptive message\n\n**Note:** Run each verification command after a change that could affect it. After a successful run, don't repeat the same command unless the code has changed since — re-running on unchanged code adds no information.\n\n## Common Rationalizations\n\n| Rationalization | Reality |\n|---|---|\n| \"I'll test it all at the end\" | Bugs compound. A bug in Slice 1 makes Slices 2-5 wrong. Test each slice. |\n| \"It's faster to do it all at once\" | It *feels* faster until something breaks and you can't find which of 500 changed lines caused it. |\n| \"These changes are too small to commit separately\" | Small commits are free. Large commits hide bugs and make rollbacks painful. |\n| \"I'll add the feature flag later\" | If the feature isn't complete, it shouldn't be user-visible. Add the flag now. |\n| \"This refactor is small enough to include\" | Refactors mixed with features make both harder to review and debug. Separate them. |\n| \"Let me run the build command again just to be sure\" | After a successful run, repeating the same command adds nothing unless the code has changed since. Run it again after subsequent edits, not as reassurance. |\n\n## Red Flags\n\n- More than 100 lines of code written without running tests\n- Multiple unrelated changes in a single increment\n- \"Let me just quickly add this too\" scope expansion\n- Skipping the test\u002Fverify step to move faster\n- Build or tests broken between increments\n- Large uncommitted changes accumulating\n- Building abstractions before the third use case demands it\n- Touching files outside the task scope \"while I'm here\"\n- Creating new utility files for one-time operations\n- Running the same build\u002Ftest command twice in a row without any intervening code change\n\n## Verification\n\nAfter completing all increments for a task:\n\n- [ ] Each increment was individually tested and committed\n- [ ] The full test suite passes\n- [ ] The build is clean\n- [ ] The feature works end-to-end as specified\n- [ ] No uncommitted changes remain\n\n## See Also\n\nPer-increment verification is the local check. Before declaring a task done, apply the project-wide Definition of Done as the final gate, the standing bar every increment clears regardless of the task. See `references\u002Fdefinition-of-done.md`.\n\n## Limitations\n\n- Use this skill only when the task clearly matches its upstream source and local project context.\n- Verify commands, generated code, dependencies, credentials, and external service behavior before applying changes.\n- Do not treat examples as a substitute for environment-specific tests, security review, or user approval for destructive or costly actions.\n","# Incremental Implementation\n\n## Overview\n\nBuild in thin vertical slices — implement one piece, test it, verify it, then expand. Avoid implementing an entire feature in one pass. Each increment should leave the system in a working, testable state. This is the execution discipline that makes large features manageable.\n\n## When to Use\n\n- Implementing any multi-file change\n- Building a new feature from a task breakdown\n- Refactoring existing code\n- Any time you're tempted to write more than ~100 lines before testing\n\n**When NOT to use:** Single-file, single-function changes where the scope is already minimal.\n\n## The Increment Cycle\n\n```\n┌──────────────────────────────────────┐\n│                                      │\n│   Implement ──→ Test ──→ Verify ──┐  │\n│       ▲                           │  │\n│       └───── Commit ◄─────────────┘  │\n│              │                       │\n│              ▼                       │\n│          Next slice                  │\n│                                      │\n└──────────────────────────────────────┘\n```\n\nFor each slice:\n\n1. **Implement** the smallest complete piece of functionality\n2. **Test** — run the test suite (or write a test if none exists)\n3. **Verify** — confirm the slice works as expected (tests pass, build succeeds, manual check)\n4. **Commit** -- save your progress with a descriptive message (see `git-workflow-and-versioning` for atomic commit guidance)\n5. **Move to the next slice** — carry forward, don't restart\n\n## Slicing Strategies\n\n### Vertical Slices (Preferred)\n\nBuild one complete path through the stack:\n\n```\nSlice 1: Create a task (DB + API + basic UI)\n    → Tests pass, user can create a task via the UI\n\nSlice 2: List tasks (query + API + UI)\n    → Tests pass, user can see their tasks\n\nSlice 3: Edit a task (update + API + UI)\n    → Tests pass, user can modify tasks\n\nSlice 4: Delete a task (delete + API + UI + confirmation)\n    → Tests pass, full CRUD complete\n```\n\nEach slice delivers working end-to-end functionality.\n\n### Contract-First Slicing\n\nWhen backend and frontend need to develop in parallel:\n\n```\nSlice 0: Define the API contract (types, interfaces, OpenAPI spec)\nSlice 1a: Implement backend against the contract + API tests\nSlice 1b: Implement frontend against mock data matching the contract\nSlice 2: Integrate and test end-to-end\n```\n\n### Risk-First Slicing\n\nTackle the riskiest or most uncertain piece first:\n\n```\nSlice 1: Prove the WebSocket connection works (highest risk)\nSlice 2: Build real-time task updates on the proven connection\nSlice 3: Add offline support and reconnection\n```\n\nIf Slice 1 fails, you discover it before investing in Slices 2 and 3.\n\n## Implementation Rules\n\n### Rule 0: Simplicity First\n\nBefore writing any code, ask: \"What is the simplest thing that could work?\"\n\nAfter writing code, review it against these checks:\n- Can this be done in fewer lines?\n- Are these abstractions earning their complexity?\n- Would a staff engineer look at this and say \"why didn't you just...\"?\n- Am I building for hypothetical future requirements, or the current task?\n\n```\nSIMPLICITY CHECK:\n✗ Generic EventBus with middleware pipeline for one notification\n✓ Simple function call\n\n✗ Abstract factory pattern for two similar components\n✓ Two straightforward components with shared utilities\n\n✗ Config-driven form builder for three forms\n✓ Three form components\n```\n\nThree similar lines of code is better than a premature abstraction. Implement the naive, obviously-correct version first. Optimize only after correctness is proven with tests.\n\n### Rule 0.5: Scope Discipline\n\nTouch only what the task requires.\n\nDo NOT:\n- \"Clean up\" code adjacent to your change\n- Refactor imports in files you're not modifying\n- Remove comments you don't fully understand\n- Add features not in the spec because they \"seem useful\"\n- Modernize syntax in files you're only reading\n\nIf you notice something worth improving outside your task scope, note it — don't fix it:\n\n```\nNOTICED BUT NOT TOUCHING:\n- src\u002Futils\u002Fformat.ts has an unused import (unrelated to this task)\n- The auth middleware could use better error messages (separate task)\n→ Want me to create tasks for these?\n```\n\n### Rule 1: One Thing at a Time\n\nEach increment changes one logical thing. Don't mix concerns:\n\n**Bad:** One commit that adds a new component, refactors an existing one, and updates the build config.\n\n**Good:** Three separate commits — one for each change.\n\n### Rule 2: Keep It Compilable\n\nAfter each increment, the project must build and existing tests must pass. Don't leave the codebase in a broken state between slices.\n\n### Rule 3: Feature Flags for Incomplete Features\n\nIf a feature isn't ready for users but you need to merge increments:\n\n```typescript\n\u002F\u002F Feature flag for work-in-progress\nconst ENABLE_TASK_SHARING = process.env.FEATURE_TASK_SHARING === 'true';\n\nif (ENABLE_TASK_SHARING) {\n  \u002F\u002F New sharing UI\n}\n```\n\nThis lets you merge small increments to the main branch without exposing incomplete work.\n\n### Rule 4: Safe Defaults\n\nNew code should default to safe, conservative behavior:\n\n```typescript\n\u002F\u002F Safe: disabled by default, opt-in\nexport function createTask(data: TaskInput, options?: { notify?: boolean }) {\n  const shouldNotify = options?.notify ?? false;\n  \u002F\u002F ...\n}\n```\n\n### Rule 5: Rollback-Friendly\n\nEach increment should be independently revertable:\n\n- Additive changes (new files, new functions) are easy to revert\n- Modifications to existing code should be minimal and focused\n- Database migrations should have corresponding rollback migrations\n- Avoid deleting something in one commit and replacing it in the same commit — separate them\n\n## Working with Agents\n\nWhen directing an agent to implement incrementally:\n\n```\n\"Let's implement Task 3 from the plan.\n\nStart with just the database schema change and the API endpoint.\nDon't touch the UI yet — we'll do that in the next increment.\n\nAfter implementing, run `npm test` and `npm run build` to verify\nnothing is broken.\"\n```\n\nBe explicit about what's in scope and what's NOT in scope for each increment.\n\n## Increment Checklist\n\nAfter each increment, verify:\n\n- [ ] The change does one thing and does it completely\n- [ ] All existing tests still pass (`npm test`)\n- [ ] The build succeeds (`npm run build`)\n- [ ] Type checking passes (`npx tsc --noEmit`)\n- [ ] Linting passes (`npm run lint`)\n- [ ] The new functionality works as expected\n- [ ] The change is committed with a descriptive message\n\n**Note:** Run each verification command after a change that could affect it. After a successful run, don't repeat the same command unless the code has changed since — re-running on unchanged code adds no information.\n\n## Common Rationalizations\n\n| Rationalization | Reality |\n|---|---|\n| \"I'll test it all at the end\" | Bugs compound. A bug in Slice 1 makes Slices 2-5 wrong. Test each slice. |\n| \"It's faster to do it all at once\" | It *feels* faster until something breaks and you can't find which of 500 changed lines caused it. |\n| \"These changes are too small to commit separately\" | Small commits are free. Large commits hide bugs and make rollbacks painful. |\n| \"I'll add the feature flag later\" | If the feature isn't complete, it shouldn't be user-visible. Add the flag now. |\n| \"This refactor is small enough to include\" | Refactors mixed with features make both harder to review and debug. Separate them. |\n| \"Let me run the build command again just to be sure\" | After a successful run, repeating the same command adds nothing unless the code has changed since. Run it again after subsequent edits, not as reassurance. |\n\n## Red Flags\n\n- More than 100 lines of code written without running tests\n- Multiple unrelated changes in a single increment\n- \"Let me just quickly add this too\" scope expansion\n- Skipping the test\u002Fverify step to move faster\n- Build or tests broken between increments\n- Large uncommitted changes accumulating\n- Building abstractions before the third use case demands it\n- Touching files outside the task scope \"while I'm here\"\n- Creating new utility files for one-time operations\n- Running the same build\u002Ftest command twice in a row without any intervening code change\n\n## Verification\n\nAfter completing all increments for a task:\n\n- [ ] Each increment was individually tested and committed\n- [ ] The full test suite passes\n- [ ] The build is clean\n- [ ] The feature works end-to-end as specified\n- [ ] No uncommitted changes remain\n\n## See Also\n\nPer-increment verification is the local check. Before declaring a task done, apply the project-wide Definition of Done as the final gate, the standing bar every increment clears regardless of the task. See `references\u002Fdefinition-of-done.md`.\n\n## Limitations\n\n- Use this skill only when the task clearly matches its upstream source and local project context.\n- Verify commands, generated code, dependencies, credentials, and external service behavior before applying changes.\n- Do not treat examples as a substitute for environment-specific tests, security review, or user approval for destructive or costly actions.\n",{"name":5,"risk":27,"source":43,"license":14,"date_added":44,"description":7,"source_repo":45,"source_type":31,"license_source":46},"https:\u002F\u002Fgithub.com\u002Faddyosmani\u002Fagent-skills\u002Ftree\u002Fmain\u002Fskills\u002Fincremental-implementation",1782864000000,"addyosmani\u002Fagent-skills","https:\u002F\u002Fgithub.com\u002Faddyosmani\u002Fagent-skills\u002Fblob\u002Fmain\u002FLICENSE","f3312ba749561b6159f477dbfc9313c875d40a56",".agents\u002Fskills_archive\u002Fincremental-implementation","https:\u002F\u002Fgithub.com\u002Fduc-duy-1612\u002FOnline-Delivery-Systems-Web","https:\u002F\u002Fgithub.com\u002Fduc-duy-1612","2026-10-25 23:50:58",{"source":8,"skillName":5,"commands":53,"prompt":63,"zipAvailable":64},[54,57,60],{"tool":55,"command":56},"npx","npx skills add duc-duy-1612\u002FOnline-Delivery-Systems-Web --skill incremental-implementation",{"tool":58,"command":59},"bunx","bunx skills add duc-duy-1612\u002FOnline-Delivery-Systems-Web --skill incremental-implementation",{"tool":61,"command":62},"pnpm","pnpm dlx skills add duc-duy-1612\u002FOnline-Delivery-Systems-Web --skill incremental-implementation","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fduc-duy-1612\u002FOnline-Delivery-Systems-Web\u002Fblob\u002Fmain\u002F.agents\u002Fskills_archive\u002Fincremental-implementation\u002FSKILL.md",true,[],[67,94,118,142,170,193],{"skillNo":68,"name":69,"nameZh":6,"description":70,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":71,"categories":72,"keywords":78,"publishedAt":38},"01M6Q0FA5FZ410Z33Z3TFQ4DBA","zero-trust","Implement zero-trust network architecture. Configure identity-based access, micro-segmentation, and continuous verification. Use when implementing modern security architectures.","https:\u002F\u002Fgithub.com\u002Fduc-duy-1612\u002FOnline-Delivery-Systems-Web\u002Fblob\u002Fmain\u002F.agents\u002Fskills_archive\u002Fzero-trust\u002FSKILL.md",[73],{"categoryNo":74,"categoryName":75,"taxonomyType":76,"taxonomyTypeDesc":77},"01JBSEEDCAT000000000000011","运维与部署","SCENARIO","使用场景",[79,80,81,82,83,84,69,85,86,87,88,89,31,20,90,27,91,92,93,21],"ZeRO","trust","zero trust","architecture","assessment","verification","segmentation","devops-security","access","configure","only","active","scope","scripts","relevant",{"skillNo":95,"name":96,"nameZh":6,"description":97,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":98,"categories":99,"keywords":100,"publishedAt":38},"01M6Q0F1YZJW3KX5FBKEVZ8CV4","zcode-delegate","Delegate coding tasks to the Z.AI ZCode CLI only when the user explicitly requests it, while the orchestrator retains review and landing responsibility.","https:\u002F\u002Fgithub.com\u002Fduc-duy-1612\u002FOnline-Delivery-Systems-Web\u002Fblob\u002Fmain\u002F.agents\u002Fskills_archive\u002Fzcode-delegate\u002FSKILL.md",[],[101,102,103,104,105,106,107,108,109,110,111,112,113,89,114,31,115,116,27,117],"delegate","zcode","zcode delegate","review","cli","orchestration","tasks","run","Bash","model","node","read","orchestrator","files","desktop app","app","agent-orchestration",{"skillNo":119,"name":120,"nameZh":6,"description":121,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":122,"categories":123,"keywords":124,"publishedAt":38},"01M6Q0ETK41VGNMYEXW0T00AJN","youtube-transcript","Fetch YouTube transcripts through DeepAPI or local fallback tooling and save clean text output.","https:\u002F\u002Fgithub.com\u002Fduc-duy-1612\u002FOnline-Delivery-Systems-Web\u002Fblob\u002Fmain\u002F.agents\u002Fskills_archive\u002Fyoutube-transcript\u002FSKILL.md",[],[125,126,127,128,129,130,131,35,132,133,134,135,136,31,20,137,138,139,140,141],"transcript","youtube transcript","youtube","safe","github","codex","research","https","text","fetch","tooling","clean","local","output","deepapi","youtube transcripts","blob",{"skillNo":143,"name":144,"nameZh":6,"description":145,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":146,"categories":147,"keywords":159,"publishedAt":38},"01M6Q0EPPH2PVMDW40017F8WX0","youtube-transcript-skills","Fetch YouTube video transcripts, search videos\u002Fchannels, browse channels, and extract playlists via the getyoutubetranscript.com API - free tier, no card required.","https:\u002F\u002Fgithub.com\u002Fduc-duy-1612\u002FOnline-Delivery-Systems-Web\u002Fblob\u002Fmain\u002F.agents\u002Fskills_archive\u002Fyoutube-transcript-skills\u002FSKILL.md",[148,151,154],{"categoryNo":149,"categoryName":150,"taxonomyType":76,"taxonomyTypeDesc":77},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":152,"categoryName":153,"taxonomyType":76,"taxonomyTypeDesc":77},"01JBSEEDCAT000000000000016","图像与多媒体",{"categoryNo":155,"categoryName":156,"taxonomyType":157,"taxonomyTypeDesc":158},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[125,126,127,160,128,161,129,130,35,162,163,164,165,134,166,31,20,167,168,169],"youtube transcript skills","gemini","search","api","Video","browse","api-integration","free","card","channels",{"skillNo":171,"name":172,"nameZh":6,"description":173,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":174,"categories":175,"keywords":180,"publishedAt":38},"01M6Q0EAB96PX83W5PTE8A0R8D","youtube-notetaker","Turn YouTube talks into local study notes with slides, transcripts, editable annotations, and a markdown-backed viewer.","https:\u002F\u002Fgithub.com\u002Fduc-duy-1612\u002FOnline-Delivery-Systems-Web\u002Fblob\u002Fmain\u002F.agents\u002Fskills_archive\u002Fyoutube-notetaker\u002FSKILL.md",[176,179],{"categoryNo":177,"categoryName":178,"taxonomyType":76,"taxonomyTypeDesc":77},"01JBSEEDCAT000000000000003","演示文稿",{"categoryNo":152,"categoryName":153,"taxonomyType":76,"taxonomyTypeDesc":77},[127,181,182,105,128,183,184,185,37,35,164,186,187,188,189,20,190,137,191,192],"youtube notetaker","notetaker","workflow","official","notes","markdown","slides","annotations","README","study","dair-academy","viewer",{"skillNo":194,"name":195,"nameZh":6,"description":196,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":197,"categories":198,"keywords":200,"publishedAt":38},"01M6Q0E55F0GW5MX48V8HXS8B5","youtube-full","Fetch YouTube transcripts, search videos, browse channels, and extract playlists via TranscriptAPI — no yt-dlp, no Google API key, works from any cloud server.","https:\u002F\u002Fgithub.com\u002Fduc-duy-1612\u002FOnline-Delivery-Systems-Web\u002Fblob\u002Fmain\u002F.agents\u002Fskills_archive\u002Fyoutube-full\u002FSKILL.md",[199],{"categoryNo":149,"categoryName":150,"taxonomyType":76,"taxonomyTypeDesc":77},[201,127,202,203,128,161,162,204,205,163,164,165,134,206,166,31,20,167,207,140],"youtube full","full","google","server","dlp","credits","automatic"]