[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M7DF28S0ZPYAACAGVWH4H61K":3,"skill-same:01M7DF28S0ZPYAACAGVWH4H61K":45},{"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":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":24,"commitSha":25,"skillDirectory":26,"forksCount":27,"repositoryHtmlUrl":28,"repositoryHomepageUrl":6,"ownerHtmlUrl":29,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":30,"install":31,"resources":44},"01M7DF28S0ZPYAACAGVWH4H61K","feature-development",null,"Implement and verify a requested change to software behavior, including its tests and evidence. Use when the requirement is clear and the user asks to build or change behavior; use refactoring when behavior must stay the same and prototyping for throwaway experiments.","andersonmrodrigues\u002Fpaved","andersonmrodrigues","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F13907380?v=4","01M7DEV3FP2VMQZ3FP2FP1TK1C","Anderson Rodrigues","01M7DEV3GC2QAQBW4FMNT98H48",1,"MIT","https:\u002F\u002Fgithub.com\u002Fandersonmrodrigues\u002Fpaved\u002Fblob\u002Fmain\u002Fplugins\u002Fclaude\u002Fpaved\u002Fskills\u002Ffeature-development\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: feature-development\ndescription: >-\n  Implement and verify a requested change to software behavior, including its tests and evidence. Use when the requirement is clear and the user asks to build or change behavior; use refactoring when behavior must stay the same and prototyping for throwaway experiments.\n---\n\n\u003C!-- Generated by Paved plugin paved@2.29.0 from core.development.feature-development@0.8.0; edit Paved Core instead. -->\n# Feature development\n\n## When to use\n\nIn the `planning` and `implementation` phases of the feature workflow, and for any other\nchange that adds or alters behavior. For restructuring without behavior change use\n`refactoring`; for throwaway exploration use `prototyping`.\n\n## Required context\n\nNone beyond the code. Useful when present: the feature map entry for the area, the\narchitecture context (boundaries), the rules in scope and the verification profile, to\nknow which checks exist before promising any.\n\n## Preconditions\n\n- The requirement can be written as observable claims (\"given X, the system does Y\").\n  If it cannot, ask; do not fill gaps in a requirement with guesses.\n- The affected code and the pattern to follow are known. If not, activate\n  `context-discovery` first.\n\n## Procedure\n\n1. **Understand the requirement.** Write it as claims, including the edge cases the\n   requirement implies (empty input, missing data, limits, failure of a dependency).\n   List what is out of scope.\n2. **Locate the affected code** through the feature map or by following the entry point\n   of the behavior. Name every file you expect to change.\n   For technology-specific code, read the relevant knowledge under the selected\n   adapter in the pinned Core runtime; use the project's adapter selection, and do not\n   apply guidance from an unselected technology.\n3. **Plan the proof.** Pick a profile check for each claim; plan artifacts and gaps now.\n   Consider optional `mutation` checks for high-risk behavior or suite evaluation. They\n   support only `test-effectiveness` claims about selected injected changes, never\n   production behavior or non-regression.\n4. **Choose the working capacity.** Use the lightest available model that can handle\n   each bounded task reliably. Reserve stronger models for ambiguous requirements,\n   architecture choices, difficult debugging, security-sensitive reasoning and final\n   synthesis. Use cheaper, faster models for mechanical edits, narrow research, test\n   drafting and independent checks when their output is easy to verify. Model names and\n   capabilities vary by host; inspect its available choices instead of assuming a fixed\n   catalog, and do not spend tokens asking a model to repeat context another session\n   already has.\n5. **Delegate only independent work.** Split work when tasks have clear inputs and\n   outputs, can proceed without editing the same files or waiting on each other, and the\n   expected time saved exceeds the cost of starting and coordinating sessions. Give each\n   session a narrow brief with relevant context, expected result and constraints. Use\n   separate sessions for parallel research, isolated test work or independent review;\n   keep shared-state edits and tightly coupled reasoning in one session. Limit concurrent\n   sessions to what the host and task can usefully support.\n   When delegation will save time, register a machine-readable graph with\n   `paved delegation plan --run \u003Cid> --file \u003Cgraph.yaml> --json`, bound to the approved\n   plan digest. Include task dependencies, exact read\u002Fwrite paths, output contracts and\n   model policy. Keep concurrent write scopes disjoint. Use\n   `paved delegation ready --run \u003Cid> --json` to see what can start. Show the complete\n   graph to the user and obtain explicit approval before `paved delegation approve\n   --run \u003Cid> --approve --json`; approval is tied to the immutable graph digest.\n   Start work only after approval. Paved validates\n   and records the graph; the active host owns native agent\u002Fsession creation and work.\n   Use Claude Code's native subagents when available. In Codex, use native collaboration\n   tools when available and account for delegated agents inheriting the parent model and\n   execution environment when the host offers no per-task routing. Inspect the host's\n   actual model and reasoning controls; map `economy`, `balanced` and `frontier` to its\n   lightest suitable options rather than assuming a fixed model catalog. Keep stronger\n   capacity for ambiguity, architecture, difficult debugging and security-sensitive\n   tasks. Treat requested reasoning effort as guidance if the host cannot honor it.\n   Ask `paved delegation capabilities --host \u003Cclaude-code|codex>` for host guidance.\n   Claude Code subagents support per-invocation model and effort selection; prefer\n   isolated worktrees for parallel edits. Codex routing and isolation depend on the\n   active host configuration. Host permissions remain authoritative. Start with\n   `--isolation shared-workspace` or `--isolation isolated-worktree`; shared-workspace\n   writers are serialized. Record the actual host\u002Fmodel\u002Feffort with\n   `paved delegation start`; after the host\n   reports completion, save a concise result under\n   `.paved\u002Fgenerated\u002Fdelegation-results\u002F\u003Crun-id>\u002F` and use `paved delegation finish`\n   with the result path, outcome, each changed path via repeated `--changed-path`, and\n   available usage. Paved checks reported paths against exact write scopes; paths from\n   isolated worktrees remain host-reported and require primary-agent diff inspection.\n   For an interrupted session, verify it has stopped before\n   `paved delegation recover --run \u003Cid> --task \u003Cid> --confirmed-stopped --note \u003Creason>`.\n   Recovery preserves the attempt and makes it retryable. Usage is host-reported, not\n   independently verified. Never store prompts, credentials or raw session ids. Keep\n   short, tightly dependent or shared-file tasks in the primary session when startup\n   and coordination cost exceeds the likely time saved.\n6. **Integrate centrally.** The primary agent owns the approved plan, resolves conflicts, and checks delegated changes against the plan and repository. It remains responsible for tests, verification, evidence and completion. A delegated result is input, not proof: inspect its diff and rerun affected checks. Do not bypass approvals or change scope without updating the plan.\n7. **Choose the smallest complete solution.** Check whether the behavior is needed as stated, then look for a project helper or pattern, platform feature, or installed dependency before adding code or dependencies. Avoid unrequested options, abstractions and future flexibility. Keep the diff readable; finish affected callers, tests and fixtures. Never reduce trust-boundary validation, data-loss handling, error handling, security, accessibility or explicit requirements. For a deliberate shortcut with a known limit, add `shortcut: \u003Climit>; revisit when \u003Ccondition>` in a source comment; `paved gardener debt` lists tracked markers without writing files. Remove the marker when resolved.\n8. **Test clear behavior before implementing it.** For a behavior claim with a known\n   result, write and run the lowest-level test first; confirm its intended failure before\n   making the smallest passing change. If behavior is unresolved, prototype or ask first;\n   refactors pin existing behavior with characterization tests.\n9. **Implement in small steps** that mirror the chosen sibling: naming, structure, error\n   handling, logging, configuration. The diff contains only what the claims need.\n10. **Complete the tests for every relevant level.** Hand tests to the skill for each\n   level:\n   `unit-testing` for logic, `integration-testing` for boundaries with real\n   collaborators, `e2e-testing` when the claim is a user-visible flow.\n11. **Run the fast checks** after each meaningful step and fix failures before going on.\n12. **Clean up** imports, parameters, files and flags the change left unused.\n13. **Self-review** the diff with `core.repository.diff` and confirm with `core.repository.status` that no unintended file changed.\n14. **Verify and record** every required check, then hand over to the `verification` phase.\n\nFor a Paved workflow, keep the durable plan at\n`.paved\u002Fdocuments\u002Fplans\u002F\u003Crun-id>.md`. Put a behavior contract in\n`.paved\u002Fdocuments\u002Fspecs\u002F\u003Crun-id>.md` when the requirement needs one, and a task breakdown\nin `.paved\u002Fdocuments\u002Ftasks\u002F\u003Crun-id>.md` when it helps execute the plan. Use the same\nworkflow run id in related filenames and follow `core.instructions.workflows` for review.\n\n## Tools\n\n`core.repository.diff` for self-review; `core.repository.status` for unintended files. Build and test\ncommands come from the Tools named by Checks in the verification profile.\n\n## Rules\n\n`core.architecture.follow-existing-patterns` and\n`core.architecture.respect-declared-boundaries` shape steps 2 and 4.\n`core.security.no-secrets-in-source` covers test data and examples as well as code.\n`core.quality.evidence-before-completion` governs step 9.\n\n## Verification\n\nRequired: `unit`. Recommended when the profile has them: `build` and `static-analysis`\n(they validate, but prove no behavior), `integration` for changed boundaries, `e2e` for\nchanged user flows.\n\n## Evidence\n\nA check result for every claim, the diff, and a gap for each claim without an\navailable check.\n\n## Completion criteria\n\n- Every claim has a passed check or a supporting artifact, or is an explained gap.\n- The diff touches only files named in step 2, or the plan was updated to say why.\n- No new static-analysis warnings in the changed files.\n\n## Failure modes\n\n| Failure | Signal | Response |\n|---|---|---|\n| Scope creep | Diff touches files unrelated to the claims | Revert the unrelated parts |\n| New pattern by accident | Code differs in style from its siblings | Rewrite to match, or record why not |\n| Proof chosen after the fact | Claims appear only after implementation | Re-plan the claims; confirm the tests assert them |\n| Requirement grows during work | New claims appear mid-implementation | Stop and confirm them with a human |\n\n## References\n\nNone.\n\n\n## Paved integration\n\nUse the project-local Paved contract as the source of truth. Discover state with `node \"${CLAUDE_PLUGIN_ROOT}\u002Fscripts\u002Fpaved.mjs\" status --json`, load only relevant `.paved\u002Fproject\u002F` context, and invoke verification with `node \"${CLAUDE_PLUGIN_ROOT}\u002Fscripts\u002Fpaved.mjs\" verify --json`. Always run it from the repository being worked on, never from the plugin directory. Do not edit generated integration files or bypass Paved lifecycle and ownership checks.\n","\u003C!-- Generated by Paved plugin paved@2.29.0 from core.development.feature-development@0.8.0; edit Paved Core instead. -->\n# Feature development\n\n## When to use\n\nIn the `planning` and `implementation` phases of the feature workflow, and for any other\nchange that adds or alters behavior. For restructuring without behavior change use\n`refactoring`; for throwaway exploration use `prototyping`.\n\n## Required context\n\nNone beyond the code. Useful when present: the feature map entry for the area, the\narchitecture context (boundaries), the rules in scope and the verification profile, to\nknow which checks exist before promising any.\n\n## Preconditions\n\n- The requirement can be written as observable claims (\"given X, the system does Y\").\n  If it cannot, ask; do not fill gaps in a requirement with guesses.\n- The affected code and the pattern to follow are known. If not, activate\n  `context-discovery` first.\n\n## Procedure\n\n1. **Understand the requirement.** Write it as claims, including the edge cases the\n   requirement implies (empty input, missing data, limits, failure of a dependency).\n   List what is out of scope.\n2. **Locate the affected code** through the feature map or by following the entry point\n   of the behavior. Name every file you expect to change.\n   For technology-specific code, read the relevant knowledge under the selected\n   adapter in the pinned Core runtime; use the project's adapter selection, and do not\n   apply guidance from an unselected technology.\n3. **Plan the proof.** Pick a profile check for each claim; plan artifacts and gaps now.\n   Consider optional `mutation` checks for high-risk behavior or suite evaluation. They\n   support only `test-effectiveness` claims about selected injected changes, never\n   production behavior or non-regression.\n4. **Choose the working capacity.** Use the lightest available model that can handle\n   each bounded task reliably. Reserve stronger models for ambiguous requirements,\n   architecture choices, difficult debugging, security-sensitive reasoning and final\n   synthesis. Use cheaper, faster models for mechanical edits, narrow research, test\n   drafting and independent checks when their output is easy to verify. Model names and\n   capabilities vary by host; inspect its available choices instead of assuming a fixed\n   catalog, and do not spend tokens asking a model to repeat context another session\n   already has.\n5. **Delegate only independent work.** Split work when tasks have clear inputs and\n   outputs, can proceed without editing the same files or waiting on each other, and the\n   expected time saved exceeds the cost of starting and coordinating sessions. Give each\n   session a narrow brief with relevant context, expected result and constraints. Use\n   separate sessions for parallel research, isolated test work or independent review;\n   keep shared-state edits and tightly coupled reasoning in one session. Limit concurrent\n   sessions to what the host and task can usefully support.\n   When delegation will save time, register a machine-readable graph with\n   `paved delegation plan --run \u003Cid> --file \u003Cgraph.yaml> --json`, bound to the approved\n   plan digest. Include task dependencies, exact read\u002Fwrite paths, output contracts and\n   model policy. Keep concurrent write scopes disjoint. Use\n   `paved delegation ready --run \u003Cid> --json` to see what can start. Show the complete\n   graph to the user and obtain explicit approval before `paved delegation approve\n   --run \u003Cid> --approve --json`; approval is tied to the immutable graph digest.\n   Start work only after approval. Paved validates\n   and records the graph; the active host owns native agent\u002Fsession creation and work.\n   Use Claude Code's native subagents when available. In Codex, use native collaboration\n   tools when available and account for delegated agents inheriting the parent model and\n   execution environment when the host offers no per-task routing. Inspect the host's\n   actual model and reasoning controls; map `economy`, `balanced` and `frontier` to its\n   lightest suitable options rather than assuming a fixed model catalog. Keep stronger\n   capacity for ambiguity, architecture, difficult debugging and security-sensitive\n   tasks. Treat requested reasoning effort as guidance if the host cannot honor it.\n   Ask `paved delegation capabilities --host \u003Cclaude-code|codex>` for host guidance.\n   Claude Code subagents support per-invocation model and effort selection; prefer\n   isolated worktrees for parallel edits. Codex routing and isolation depend on the\n   active host configuration. Host permissions remain authoritative. Start with\n   `--isolation shared-workspace` or `--isolation isolated-worktree`; shared-workspace\n   writers are serialized. Record the actual host\u002Fmodel\u002Feffort with\n   `paved delegation start`; after the host\n   reports completion, save a concise result under\n   `.paved\u002Fgenerated\u002Fdelegation-results\u002F\u003Crun-id>\u002F` and use `paved delegation finish`\n   with the result path, outcome, each changed path via repeated `--changed-path`, and\n   available usage. Paved checks reported paths against exact write scopes; paths from\n   isolated worktrees remain host-reported and require primary-agent diff inspection.\n   For an interrupted session, verify it has stopped before\n   `paved delegation recover --run \u003Cid> --task \u003Cid> --confirmed-stopped --note \u003Creason>`.\n   Recovery preserves the attempt and makes it retryable. Usage is host-reported, not\n   independently verified. Never store prompts, credentials or raw session ids. Keep\n   short, tightly dependent or shared-file tasks in the primary session when startup\n   and coordination cost exceeds the likely time saved.\n6. **Integrate centrally.** The primary agent owns the approved plan, resolves conflicts, and checks delegated changes against the plan and repository. It remains responsible for tests, verification, evidence and completion. A delegated result is input, not proof: inspect its diff and rerun affected checks. Do not bypass approvals or change scope without updating the plan.\n7. **Choose the smallest complete solution.** Check whether the behavior is needed as stated, then look for a project helper or pattern, platform feature, or installed dependency before adding code or dependencies. Avoid unrequested options, abstractions and future flexibility. Keep the diff readable; finish affected callers, tests and fixtures. Never reduce trust-boundary validation, data-loss handling, error handling, security, accessibility or explicit requirements. For a deliberate shortcut with a known limit, add `shortcut: \u003Climit>; revisit when \u003Ccondition>` in a source comment; `paved gardener debt` lists tracked markers without writing files. Remove the marker when resolved.\n8. **Test clear behavior before implementing it.** For a behavior claim with a known\n   result, write and run the lowest-level test first; confirm its intended failure before\n   making the smallest passing change. If behavior is unresolved, prototype or ask first;\n   refactors pin existing behavior with characterization tests.\n9. **Implement in small steps** that mirror the chosen sibling: naming, structure, error\n   handling, logging, configuration. The diff contains only what the claims need.\n10. **Complete the tests for every relevant level.** Hand tests to the skill for each\n   level:\n   `unit-testing` for logic, `integration-testing` for boundaries with real\n   collaborators, `e2e-testing` when the claim is a user-visible flow.\n11. **Run the fast checks** after each meaningful step and fix failures before going on.\n12. **Clean up** imports, parameters, files and flags the change left unused.\n13. **Self-review** the diff with `core.repository.diff` and confirm with `core.repository.status` that no unintended file changed.\n14. **Verify and record** every required check, then hand over to the `verification` phase.\n\nFor a Paved workflow, keep the durable plan at\n`.paved\u002Fdocuments\u002Fplans\u002F\u003Crun-id>.md`. Put a behavior contract in\n`.paved\u002Fdocuments\u002Fspecs\u002F\u003Crun-id>.md` when the requirement needs one, and a task breakdown\nin `.paved\u002Fdocuments\u002Ftasks\u002F\u003Crun-id>.md` when it helps execute the plan. Use the same\nworkflow run id in related filenames and follow `core.instructions.workflows` for review.\n\n## Tools\n\n`core.repository.diff` for self-review; `core.repository.status` for unintended files. Build and test\ncommands come from the Tools named by Checks in the verification profile.\n\n## Rules\n\n`core.architecture.follow-existing-patterns` and\n`core.architecture.respect-declared-boundaries` shape steps 2 and 4.\n`core.security.no-secrets-in-source` covers test data and examples as well as code.\n`core.quality.evidence-before-completion` governs step 9.\n\n## Verification\n\nRequired: `unit`. Recommended when the profile has them: `build` and `static-analysis`\n(they validate, but prove no behavior), `integration` for changed boundaries, `e2e` for\nchanged user flows.\n\n## Evidence\n\nA check result for every claim, the diff, and a gap for each claim without an\navailable check.\n\n## Completion criteria\n\n- Every claim has a passed check or a supporting artifact, or is an explained gap.\n- The diff touches only files named in step 2, or the plan was updated to say why.\n- No new static-analysis warnings in the changed files.\n\n## Failure modes\n\n| Failure | Signal | Response |\n|---|---|---|\n| Scope creep | Diff touches files unrelated to the claims | Revert the unrelated parts |\n| New pattern by accident | Code differs in style from its siblings | Rewrite to match, or record why not |\n| Proof chosen after the fact | Claims appear only after implementation | Re-plan the claims; confirm the tests assert them |\n| Requirement grows during work | New claims appear mid-implementation | Stop and confirm them with a human |\n\n## References\n\nNone.\n\n\n## Paved integration\n\nUse the project-local Paved contract as the source of truth. Discover state with `node \"${CLAUDE_PLUGIN_ROOT}\u002Fscripts\u002Fpaved.mjs\" status --json`, load only relevant `.paved\u002Fproject\u002F` context, and invoke verification with `node \"${CLAUDE_PLUGIN_ROOT}\u002Fscripts\u002Fpaved.mjs\" verify --json`. Always run it from the repository being worked on, never from the plugin directory. Do not edit generated integration files or bypass Paved lifecycle and ownership checks.\n",{"name":5,"description":7},"main","1cd80f05aff924ea609012e864fa5c22c16c7d2d","plugins\u002Fclaude\u002Fpaved\u002Fskills\u002Ffeature-development",0,"https:\u002F\u002Fgithub.com\u002Fandersonmrodrigues\u002Fpaved","https:\u002F\u002Fgithub.com\u002Fandersonmrodrigues","2026-11-14 20:09:28",{"source":8,"skillName":5,"commands":32,"prompt":42,"zipAvailable":43},[33,36,39],{"tool":34,"command":35},"npx","npx skills add andersonmrodrigues\u002Fpaved --skill feature-development",{"tool":37,"command":38},"bunx","bunx skills add andersonmrodrigues\u002Fpaved --skill feature-development",{"tool":40,"command":41},"pnpm","pnpm dlx skills add andersonmrodrigues\u002Fpaved --skill feature-development","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fandersonmrodrigues\u002Fpaved\u002Fblob\u002Fmain\u002Fplugins\u002Fclaude\u002Fpaved\u002Fskills\u002Ffeature-development\u002FSKILL.md",true,[],[46,53,59,65,71,77],{"skillNo":47,"name":48,"nameZh":6,"description":49,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":50,"categories":51,"keywords":52,"publishedAt":19},"01M7DFBWJT4T1MPBHTWT19PBEK","sample-skill","Does a sample task. Use when a sample is needed.","https:\u002F\u002Fgithub.com\u002Fandersonmrodrigues\u002Fpaved\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fskills\u002Fvalid\u002Fsample-skill\u002FSKILL.md",[],[],{"skillNo":54,"name":55,"nameZh":6,"description":49,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":56,"categories":57,"keywords":58,"publishedAt":19},"01M7DFBS6WTK30PBSW4ZS0NPWT","unexplained-contract","https:\u002F\u002Fgithub.com\u002Fandersonmrodrigues\u002Fpaved\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fskills\u002Finvalid\u002Funexplained-contract\u002FSKILL.md",[],[],{"skillNo":60,"name":61,"nameZh":6,"description":49,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":62,"categories":63,"keywords":64,"publishedAt":19},"01M7DFBPJGG170V9WTMFWY73R4","shell-block","https:\u002F\u002Fgithub.com\u002Fandersonmrodrigues\u002Fpaved\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fskills\u002Finvalid\u002Fshell-block\u002FSKILL.md",[],[],{"skillNo":66,"name":67,"nameZh":6,"description":49,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":68,"categories":69,"keywords":70,"publishedAt":19},"01M7DFBMZYR20JPTXNE5A8EFG6","project-identifier","https:\u002F\u002Fgithub.com\u002Fandersonmrodrigues\u002Fpaved\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fskills\u002Finvalid\u002Fproject-identifier\u002FSKILL.md",[],[],{"skillNo":72,"name":73,"nameZh":6,"description":49,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":74,"categories":75,"keywords":76,"publishedAt":19},"01M7DFBJ8J533DAKA3FTF54SX3","oversized","https:\u002F\u002Fgithub.com\u002Fandersonmrodrigues\u002Fpaved\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fskills\u002Finvalid\u002Foversized\u002FSKILL.md",[],[],{"skillNo":78,"name":79,"nameZh":6,"description":80,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":81,"categories":82,"keywords":83,"publishedAt":19},"01M7DFBFAD0RYCRHTZ2JW4RX7E","no-activation","Does a sample task.","https:\u002F\u002Fgithub.com\u002Fandersonmrodrigues\u002Fpaved\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fskills\u002Finvalid\u002Fno-activation\u002FSKILL.md",[],[]]