[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M79AM09WMYRG3WDQZ3DVVRME":3,"skill-same:01M79AM09WMYRG3WDQZ3DVVRME":68},{"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":37,"commitSha":38,"skillDirectory":39,"forksCount":40,"repositoryHtmlUrl":41,"repositoryHomepageUrl":6,"ownerHtmlUrl":42,"ownerBlogUrl":43,"ownerDescription":6,"updatedAt":44,"install":45,"resources":57},"01M79AM09WMYRG3WDQZ3DVVRME","golang-code-style",null,"Golang code style conventions — line length and breaking, variable declarations, control flow clarity, when comments help vs hurt. Use when writing or reviewing Go code, asking about style or clarity, or establishing project coding standards. Not for naming conventions (→ See `samber\u002Fcc-skills-golang@golang-naming` skill), linter configuration (→ See `samber\u002Fcc-skills-golang@golang-lint` skill), or doc comments (→ See `samber\u002Fcc-skills-golang@golang-documentation` skill).","CCH-HQ\u002Fcchp-automation","CCH-HQ","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F253065381?v=4","01M79AG9QPRTJEVTCT1ZS7TM9J","CCH HQ","01M79AG9RNM4TAB3PJQH71X62P",2,"MIT","https:\u002F\u002Fgithub.com\u002FCCH-HQ\u002Fcchp-automation\u002Fblob\u002Fmain\u002Fskills-backup\u002Fskills\u002Fgolang-code-style\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: golang-code-style\ndescription: \"Golang code style conventions — line length and breaking, variable declarations, control flow clarity, when comments help vs hurt. Use when writing or reviewing Go code, asking about style or clarity, or establishing project coding standards. Not for naming conventions (→ See `samber\u002Fcc-skills-golang@golang-naming` skill), linter configuration (→ See `samber\u002Fcc-skills-golang@golang-lint` skill), or doc comments (→ See `samber\u002Fcc-skills-golang@golang-documentation` skill).\"\nuser-invocable: true\nlicense: MIT\ncompatibility: Designed for Claude Code or similar AI coding agents, and for projects using Golang.\nmetadata:\n  author: samber\n  version: \"1.2.2\"\n  openclaw:\n    emoji: \"🎨\"\n    homepage: https:\u002F\u002Fgithub.com\u002Fsamber\u002Fcc-skills-golang\n    requires:\n      bins:\n        - go\n    install: []\nallowed-tools: Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent\n---\n\n**Orchestration mode:** Use `ultracode` when reviewing code style across a large codebase — orchestrate the sub-agents described in the \"Parallelizing Code Style Reviews\" section, each covering an independent style concern, and merge their findings.\n\n> **Community default.** A company skill that explicitly supersedes `samber\u002Fcc-skills-golang@golang-code-style` skill takes precedence.\n\n# Go Code Style\n\nStyle rules that require human judgment — linters handle formatting, this skill handles clarity. For naming see `samber\u002Fcc-skills-golang@golang-naming` skill; for design patterns see `samber\u002Fcc-skills-golang@golang-design-patterns` skill; for struct\u002Finterface design see `samber\u002Fcc-skills-golang@golang-structs-interfaces` skill.\n\n> \"Clear is better than clever.\" — Go Proverbs\n\nWhen ignoring a rule, add a comment to the code.\n\n## Line Length & Breaking\n\nNo rigid line limit, but lines beyond ~120 characters MUST be broken. Break at **semantic boundaries**, not arbitrary column counts. Function calls with 4+ arguments MUST use one argument per line — even when the prompt asks for single-line code:\n\n```go\n\u002F\u002F Good — each argument on its own line, closing paren separate\nmux.HandleFunc(\"\u002Fapi\u002Fusers\", func(w http.ResponseWriter, r *http.Request) {\n    handleUsers(\n        w,\n        r,\n        serviceName,\n        cfg,\n        logger,\n        authMiddleware,\n    )\n})\n```\n\nWhen a function signature is too long, the real fix is often **fewer parameters** (use an options struct) rather than better line wrapping. For multi-line signatures, put each parameter on its own line.\n\n## Variable Declarations\n\nSHOULD use `:=` for non-zero values, `var` for zero-value initialization. The form signals intent: `var` means \"this starts at zero.\"\n\n```go\nvar count int              \u002F\u002F zero value, set later\nname := \"default\"          \u002F\u002F non-zero, := is appropriate\nvar buf bytes.Buffer       \u002F\u002F zero value is ready to use\n```\n\n### Slice & Map Initialization\n\nSlices and maps MUST be initialized explicitly, never nil. Nil maps panic on write; nil slices serialize to `null` in JSON (vs `[]` for empty slices), surprising API consumers.\n\n```go\nusers := []User{}                       \u002F\u002F always initialized\nm := map[string]int{}                   \u002F\u002F always initialized\nusers := make([]User, 0, len(ids))      \u002F\u002F preallocate when capacity is known\nm := make(map[string]int, len(items))   \u002F\u002F preallocate when size is known\n```\n\nDo not preallocate speculatively — `make([]T, 0, 1000)` wastes memory when the common case is 10 items.\n\n### Composite Literals\n\nComposite literals MUST use field names — positional fields break when the type adds or reorders fields:\n\n```go\nsrv := &http.Server{\n    Addr:         \":8080\",\n    ReadTimeout:  5 * time.Second,\n    WriteTimeout: 10 * time.Second,\n}\n```\n\n## Control Flow\n\n### Reduce Nesting\n\nErrors and edge cases MUST be handled first (early return). Keep the happy path at minimal indentation:\n\n```go\nfunc process(data []byte) (*Result, error) {\n    if len(data) == 0 {\n        return nil, errors.New(\"empty data\")\n    }\n\n    parsed, err := parse(data)\n    if err != nil {\n        return nil, fmt.Errorf(\"parsing: %w\", err)\n    }\n\n    return transform(parsed), nil\n}\n```\n\n### Eliminate Unnecessary `else`\n\nWhen the `if` body ends with `return`\u002F`break`\u002F`continue`, the `else` MUST be dropped. Use default-then-override for simple assignments — assign a default, then override with independent conditions or a `switch`:\n\n```go\n\u002F\u002F Good — default-then-override with switch (cleanest for mutually exclusive overrides)\nlevel := slog.LevelInfo\nswitch {\ncase debug:\n    level = slog.LevelDebug\ncase verbose:\n    level = slog.LevelWarn\n}\n\n\u002F\u002F Bad — else-if chain hides that there's a default\nif debug {\n    level = slog.LevelDebug\n} else if verbose {\n    level = slog.LevelWarn\n} else {\n    level = slog.LevelInfo\n}\n```\n\n### Complex Conditions & Init Scope\n\nWhen an `if` condition has 3+ operands, MUST extract into named booleans — a wall of `||` is unreadable and hides business logic. Keep expensive checks inline for short-circuit benefit. [Details](.\u002Freferences\u002Fdetails.md)\n\n```go\n\u002F\u002F Good — named booleans make intent clear\nisAdmin := user.Role == RoleAdmin\nisOwner := resource.OwnerID == user.ID\nisPublicVerified := resource.IsPublic && user.IsVerified\nif isAdmin || isOwner || isPublicVerified || permissions.Contains(PermOverride) {\n    allow()\n}\n```\n\nScope variables to `if` blocks when only needed for the check:\n\n```go\nif err := validate(input); err != nil {\n    return err\n}\n```\n\n### Switch Over If-Else Chains\n\nWhen comparing the same variable multiple times, prefer `switch`:\n\n```go\nswitch status {\ncase StatusActive:\n    activate()\ncase StatusInactive:\n    deactivate()\ndefault:\n    panic(fmt.Sprintf(\"unexpected status: %d\", status))\n}\n```\n\n## Function Design\n\n- Functions SHOULD be **short and focused** — one function, one job.\n- Functions SHOULD have **≤4 parameters**. Beyond that, use an options struct (see `samber\u002Fcc-skills-golang@golang-design-patterns` skill).\n- **Parameter order**: `context.Context` first, then inputs, then output destinations.\n- Naked returns help in very short functions (1-3 lines) where return values are obvious, but become confusing when readers must scroll to find what's returned — name returns explicitly in longer functions.\n\n```go\nfunc FetchUser(ctx context.Context, id string) (*User, error)\nfunc SendEmail(ctx context.Context, msg EmailMessage) error  \u002F\u002F grouped into struct\n```\n\n### Prefer `range` for Iteration\n\nSHOULD use `range` over index-based loops. Use `range n` (Go 1.22+) for simple counting.\n\n```go\nfor _, user := range users {\n    process(user)\n}\n```\n\n## Value vs Pointer Arguments\n\nPass small types (`string`, `int`, `bool`, `time.Time`) by value. Use pointers when mutating, for large structs (~128+ bytes), or when nil is meaningful. [Details](.\u002Freferences\u002Fdetails.md)\n\n## Code Organization Within Files\n\n- **Group related declarations**: type, constructor, methods together\n- **Order**: package doc, imports, constants, types, constructors, methods, helpers\n- **One primary type per file** when it has significant methods\n- **Blank imports** (`_ \"pkg\"`) register side effects (init functions). Restricting them to `main` and test packages makes side effects visible at the application root, not hidden in library code\n- **Dot imports** pollute the namespace and make it impossible to tell where a name comes from — never use in library code\n- **Unexport aggressively** — you can always export later; unexporting is a breaking change. → See `samber\u002Fcc-skills-golang@golang-gopls` skill to unexport safely — its rename updates every call site atomically and refuses the change when lowercasing a method would break interface satisfaction, a breakage grep\u002Fsed silently ships.\n\n## String Handling\n\nUse `strconv` for simple conversions (faster), `fmt.Sprintf` for complex formatting. Use `%q` in error messages to make string boundaries visible. Use `strings.Builder` for loops, `+` for simple concatenation.\n\n## Type Conversions\n\nPrefer explicit, narrow conversions. Use generics over `any` when a concrete type will do:\n\n```go\nfunc Contains[T comparable](slice []T, target T) bool  \u002F\u002F not []any\n```\n\n## Philosophy\n\n- **\"A little copying is better than a little dependency\"**\n- **Use `slices` and `maps` standard packages**; for filter\u002Fgroup-by\u002Fchunk, use `github.com\u002Fsamber\u002Flo`\n- **\"Reflection is never clear\"** — avoid `reflect` unless necessary\n- **Don't abstract prematurely** — extract when the pattern is stable\n- **Minimize public surface** — every exported name is a commitment\n\n## Parallelizing Code Style Reviews\n\nWhen reviewing code style across a large codebase, use up to 5 parallel sub-agents (via the Agent tool), each targeting an independent style concern (e.g. control flow, function design, variable declarations, string handling, code organization).\n\n## Enforce with Linters\n\nMany rules are enforced automatically: `gofmt`, `gofumpt`, `goimports`, `gocritic`, `revive`, `wsl_v5`. → See the `samber\u002Fcc-skills-golang@golang-lint` skill.\n\n## Cross-References\n\n- → See the `samber\u002Fcc-skills-golang@golang-naming` skill for identifier naming conventions\n- → See the `samber\u002Fcc-skills-golang@golang-structs-interfaces` skill for pointer vs value receivers, interface design\n- → See the `samber\u002Fcc-skills-golang@golang-design-patterns` skill for functional options, builders, constructors\n- → See the `samber\u002Fcc-skills-golang@golang-lint` skill for automated formatting enforcement\n- → See `samber\u002Fcc-skills-golang@golang-continuous-integration` skill for automated AI-driven code review in CI using these guidelines\n- → See `samber\u002Fcc-skills-golang@golang-refactoring` skill for mechanically applying guard-clause conversion, function extraction, and options-struct migration safely across many call sites once a review surfaces violations at scale\n","**Orchestration mode:** Use `ultracode` when reviewing code style across a large codebase — orchestrate the sub-agents described in the \"Parallelizing Code Style Reviews\" section, each covering an independent style concern, and merge their findings.\n\n> **Community default.** A company skill that explicitly supersedes `samber\u002Fcc-skills-golang@golang-code-style` skill takes precedence.\n\n# Go Code Style\n\nStyle rules that require human judgment — linters handle formatting, this skill handles clarity. For naming see `samber\u002Fcc-skills-golang@golang-naming` skill; for design patterns see `samber\u002Fcc-skills-golang@golang-design-patterns` skill; for struct\u002Finterface design see `samber\u002Fcc-skills-golang@golang-structs-interfaces` skill.\n\n> \"Clear is better than clever.\" — Go Proverbs\n\nWhen ignoring a rule, add a comment to the code.\n\n## Line Length & Breaking\n\nNo rigid line limit, but lines beyond ~120 characters MUST be broken. Break at **semantic boundaries**, not arbitrary column counts. Function calls with 4+ arguments MUST use one argument per line — even when the prompt asks for single-line code:\n\n```go\n\u002F\u002F Good — each argument on its own line, closing paren separate\nmux.HandleFunc(\"\u002Fapi\u002Fusers\", func(w http.ResponseWriter, r *http.Request) {\n    handleUsers(\n        w,\n        r,\n        serviceName,\n        cfg,\n        logger,\n        authMiddleware,\n    )\n})\n```\n\nWhen a function signature is too long, the real fix is often **fewer parameters** (use an options struct) rather than better line wrapping. For multi-line signatures, put each parameter on its own line.\n\n## Variable Declarations\n\nSHOULD use `:=` for non-zero values, `var` for zero-value initialization. The form signals intent: `var` means \"this starts at zero.\"\n\n```go\nvar count int              \u002F\u002F zero value, set later\nname := \"default\"          \u002F\u002F non-zero, := is appropriate\nvar buf bytes.Buffer       \u002F\u002F zero value is ready to use\n```\n\n### Slice & Map Initialization\n\nSlices and maps MUST be initialized explicitly, never nil. Nil maps panic on write; nil slices serialize to `null` in JSON (vs `[]` for empty slices), surprising API consumers.\n\n```go\nusers := []User{}                       \u002F\u002F always initialized\nm := map[string]int{}                   \u002F\u002F always initialized\nusers := make([]User, 0, len(ids))      \u002F\u002F preallocate when capacity is known\nm := make(map[string]int, len(items))   \u002F\u002F preallocate when size is known\n```\n\nDo not preallocate speculatively — `make([]T, 0, 1000)` wastes memory when the common case is 10 items.\n\n### Composite Literals\n\nComposite literals MUST use field names — positional fields break when the type adds or reorders fields:\n\n```go\nsrv := &http.Server{\n    Addr:         \":8080\",\n    ReadTimeout:  5 * time.Second,\n    WriteTimeout: 10 * time.Second,\n}\n```\n\n## Control Flow\n\n### Reduce Nesting\n\nErrors and edge cases MUST be handled first (early return). Keep the happy path at minimal indentation:\n\n```go\nfunc process(data []byte) (*Result, error) {\n    if len(data) == 0 {\n        return nil, errors.New(\"empty data\")\n    }\n\n    parsed, err := parse(data)\n    if err != nil {\n        return nil, fmt.Errorf(\"parsing: %w\", err)\n    }\n\n    return transform(parsed), nil\n}\n```\n\n### Eliminate Unnecessary `else`\n\nWhen the `if` body ends with `return`\u002F`break`\u002F`continue`, the `else` MUST be dropped. Use default-then-override for simple assignments — assign a default, then override with independent conditions or a `switch`:\n\n```go\n\u002F\u002F Good — default-then-override with switch (cleanest for mutually exclusive overrides)\nlevel := slog.LevelInfo\nswitch {\ncase debug:\n    level = slog.LevelDebug\ncase verbose:\n    level = slog.LevelWarn\n}\n\n\u002F\u002F Bad — else-if chain hides that there's a default\nif debug {\n    level = slog.LevelDebug\n} else if verbose {\n    level = slog.LevelWarn\n} else {\n    level = slog.LevelInfo\n}\n```\n\n### Complex Conditions & Init Scope\n\nWhen an `if` condition has 3+ operands, MUST extract into named booleans — a wall of `||` is unreadable and hides business logic. Keep expensive checks inline for short-circuit benefit. [Details](.\u002Freferences\u002Fdetails.md)\n\n```go\n\u002F\u002F Good — named booleans make intent clear\nisAdmin := user.Role == RoleAdmin\nisOwner := resource.OwnerID == user.ID\nisPublicVerified := resource.IsPublic && user.IsVerified\nif isAdmin || isOwner || isPublicVerified || permissions.Contains(PermOverride) {\n    allow()\n}\n```\n\nScope variables to `if` blocks when only needed for the check:\n\n```go\nif err := validate(input); err != nil {\n    return err\n}\n```\n\n### Switch Over If-Else Chains\n\nWhen comparing the same variable multiple times, prefer `switch`:\n\n```go\nswitch status {\ncase StatusActive:\n    activate()\ncase StatusInactive:\n    deactivate()\ndefault:\n    panic(fmt.Sprintf(\"unexpected status: %d\", status))\n}\n```\n\n## Function Design\n\n- Functions SHOULD be **short and focused** — one function, one job.\n- Functions SHOULD have **≤4 parameters**. Beyond that, use an options struct (see `samber\u002Fcc-skills-golang@golang-design-patterns` skill).\n- **Parameter order**: `context.Context` first, then inputs, then output destinations.\n- Naked returns help in very short functions (1-3 lines) where return values are obvious, but become confusing when readers must scroll to find what's returned — name returns explicitly in longer functions.\n\n```go\nfunc FetchUser(ctx context.Context, id string) (*User, error)\nfunc SendEmail(ctx context.Context, msg EmailMessage) error  \u002F\u002F grouped into struct\n```\n\n### Prefer `range` for Iteration\n\nSHOULD use `range` over index-based loops. Use `range n` (Go 1.22+) for simple counting.\n\n```go\nfor _, user := range users {\n    process(user)\n}\n```\n\n## Value vs Pointer Arguments\n\nPass small types (`string`, `int`, `bool`, `time.Time`) by value. Use pointers when mutating, for large structs (~128+ bytes), or when nil is meaningful. [Details](.\u002Freferences\u002Fdetails.md)\n\n## Code Organization Within Files\n\n- **Group related declarations**: type, constructor, methods together\n- **Order**: package doc, imports, constants, types, constructors, methods, helpers\n- **One primary type per file** when it has significant methods\n- **Blank imports** (`_ \"pkg\"`) register side effects (init functions). Restricting them to `main` and test packages makes side effects visible at the application root, not hidden in library code\n- **Dot imports** pollute the namespace and make it impossible to tell where a name comes from — never use in library code\n- **Unexport aggressively** — you can always export later; unexporting is a breaking change. → See `samber\u002Fcc-skills-golang@golang-gopls` skill to unexport safely — its rename updates every call site atomically and refuses the change when lowercasing a method would break interface satisfaction, a breakage grep\u002Fsed silently ships.\n\n## String Handling\n\nUse `strconv` for simple conversions (faster), `fmt.Sprintf` for complex formatting. Use `%q` in error messages to make string boundaries visible. Use `strings.Builder` for loops, `+` for simple concatenation.\n\n## Type Conversions\n\nPrefer explicit, narrow conversions. Use generics over `any` when a concrete type will do:\n\n```go\nfunc Contains[T comparable](slice []T, target T) bool  \u002F\u002F not []any\n```\n\n## Philosophy\n\n- **\"A little copying is better than a little dependency\"**\n- **Use `slices` and `maps` standard packages**; for filter\u002Fgroup-by\u002Fchunk, use `github.com\u002Fsamber\u002Flo`\n- **\"Reflection is never clear\"** — avoid `reflect` unless necessary\n- **Don't abstract prematurely** — extract when the pattern is stable\n- **Minimize public surface** — every exported name is a commitment\n\n## Parallelizing Code Style Reviews\n\nWhen reviewing code style across a large codebase, use up to 5 parallel sub-agents (via the Agent tool), each targeting an independent style concern (e.g. control flow, function design, variable declarations, string handling, code organization).\n\n## Enforce with Linters\n\nMany rules are enforced automatically: `gofmt`, `gofumpt`, `goimports`, `gocritic`, `revive`, `wsl_v5`. → See the `samber\u002Fcc-skills-golang@golang-lint` skill.\n\n## Cross-References\n\n- → See the `samber\u002Fcc-skills-golang@golang-naming` skill for identifier naming conventions\n- → See the `samber\u002Fcc-skills-golang@golang-structs-interfaces` skill for pointer vs value receivers, interface design\n- → See the `samber\u002Fcc-skills-golang@golang-design-patterns` skill for functional options, builders, constructors\n- → See the `samber\u002Fcc-skills-golang@golang-lint` skill for automated formatting enforcement\n- → See `samber\u002Fcc-skills-golang@golang-continuous-integration` skill for automated AI-driven code review in CI using these guidelines\n- → See `samber\u002Fcc-skills-golang@golang-refactoring` skill for mechanically applying guard-clause conversion, function extraction, and options-struct migration safely across many call sites once a review surfaces violations at scale\n",{"name":5,"license":15,"metadata":24,"description":7,"allowed-tools":34,"compatibility":35,"user-invocable":36},{"author":25,"version":26,"openclaw":27},"samber","1.2.2",{"emoji":28,"install":29,"homepage":30,"requires":31},"🎨",[],"https:\u002F\u002Fgithub.com\u002Fsamber\u002Fcc-skills-golang",{"bins":32},[33],"go","Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent","Designed for Claude Code or similar AI coding agents, and for projects using Golang.",true,"main","a93764baed707eda5a68d91e19e5719368e6335e","skills-backup\u002Fskills\u002Fgolang-code-style",0,"https:\u002F\u002Fgithub.com\u002FCCH-HQ\u002Fcchp-automation","https:\u002F\u002Fgithub.com\u002FCCH-HQ","https:\u002F\u002Fclaude-code-hub.app\u002F","2026-11-09 20:50:54",{"source":8,"skillName":5,"commands":46,"prompt":56,"zipAvailable":36},[47,50,53],{"tool":48,"command":49},"npx","npx skills add CCH-HQ\u002Fcchp-automation --skill golang-code-style",{"tool":51,"command":52},"bunx","bunx skills add CCH-HQ\u002Fcchp-automation --skill golang-code-style",{"tool":54,"command":55},"pnpm","pnpm dlx skills add CCH-HQ\u002Fcchp-automation --skill golang-code-style","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FCCH-HQ\u002Fcchp-automation\u002Fblob\u002Fmain\u002Fskills-backup\u002Fskills\u002Fgolang-code-style\u002FSKILL.md",[58,64],{"path":59,"resourceType":60,"resourceTypeDesc":61,"sizeBytes":62,"sourceHtmlUrl":63},"evals\u002Fevals.json","REFERENCE","参考文档",35853,"https:\u002F\u002Fgithub.com\u002FCCH-HQ\u002Fcchp-automation\u002Fblob\u002Fmain\u002Fskills-backup\u002Fskills\u002Fgolang-code-style\u002Fevals\u002Fevals.json",{"path":65,"resourceType":60,"resourceTypeDesc":61,"sizeBytes":66,"sourceHtmlUrl":67},"references\u002Fdetails.md",2722,"https:\u002F\u002Fgithub.com\u002FCCH-HQ\u002Fcchp-automation\u002Fblob\u002Fmain\u002Fskills-backup\u002Fskills\u002Fgolang-code-style\u002Freferences\u002Fdetails.md",[69,76,83,90,97,104],{"skillNo":70,"name":71,"nameZh":6,"description":72,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":73,"categories":74,"keywords":75,"publishedAt":19},"01M79B44RKSB6Z0GENGYFCCZYA","writing-skills","Use when creating new skills, editing existing skills, or verifying skills work before deployment","https:\u002F\u002Fgithub.com\u002FCCH-HQ\u002Fcchp-automation\u002Fblob\u002Fmain\u002Fskills-backup\u002Fskills\u002Fwriting-skills\u002FSKILL.md",[],[],{"skillNo":77,"name":78,"nameZh":6,"description":79,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":80,"categories":81,"keywords":82,"publishedAt":19},"01M79B410BHDSNHZ7MKAYXWJHS","writing-plans","Use when you have a spec or requirements for a multi-step task, before touching code","https:\u002F\u002Fgithub.com\u002FCCH-HQ\u002Fcchp-automation\u002Fblob\u002Fmain\u002Fskills-backup\u002Fskills\u002Fwriting-plans\u002FSKILL.md",[],[],{"skillNo":84,"name":85,"nameZh":6,"description":86,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":87,"categories":88,"keywords":89,"publishedAt":19},"01M79B3XK29MCD5HGD50YGYXQZ","wizard","Generate an interactive bash wizard that walks a human through steps only they can perform. Use when provisioning infrastructure, setting up credentials or CI secrets, walking an unfamiliar third-party dashboard, or running a one-off migration or cutover. Don't invoke this for steps the agent can perform itself.","https:\u002F\u002Fgithub.com\u002FCCH-HQ\u002Fcchp-automation\u002Fblob\u002Fmain\u002Fskills-backup\u002Fskills\u002Fwizard\u002FSKILL.md",[],[],{"skillNo":91,"name":92,"nameZh":6,"description":93,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":94,"categories":95,"keywords":96,"publishedAt":19},"01M79B3TFQEXXM2KK5V44H64DV","wayfinder","Plan a huge chunk of work — more than one agent session can hold — as a shared map of decision tickets on your issue tracker, and resolve them one at a time until the way to the destination is clear.","https:\u002F\u002Fgithub.com\u002FCCH-HQ\u002Fcchp-automation\u002Fblob\u002Fmain\u002Fskills-backup\u002Fskills\u002Fwayfinder\u002FSKILL.md",[],[],{"skillNo":98,"name":99,"nameZh":6,"description":100,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":101,"categories":102,"keywords":103,"publishedAt":19},"01M79B3Q3WTMJDM6NNGG1X4NYK","verification-before-completion","Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always","https:\u002F\u002Fgithub.com\u002FCCH-HQ\u002Fcchp-automation\u002Fblob\u002Fmain\u002Fskills-backup\u002Fskills\u002Fverification-before-completion\u002FSKILL.md",[],[],{"skillNo":105,"name":106,"nameZh":6,"description":107,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":108,"categories":109,"keywords":110,"publishedAt":19},"01M79B3GW8YCKT7W489HKWFMNC","vercel-react-best-practices","React and Next.js performance optimization guidelines from Vercel Engineering. This skill should be used when writing, reviewing, or refactoring React\u002FNext.js code to ensure optimal performance patterns. Triggers on tasks involving React components, Next.js pages, data fetching, bundle optimization, or performance improvements.","https:\u002F\u002Fgithub.com\u002FCCH-HQ\u002Fcchp-automation\u002Fblob\u002Fmain\u002Fskills-backup\u002Fskills\u002Fvercel-react-best-practices\u002FSKILL.md",[],[]]