[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6R9EJSQW9WYW737271RCRB6":3,"skill-same:01M6R9EJSQW9WYW737271RCRB6":104},{"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":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":44,"commitSha":45,"skillDirectory":46,"forksCount":47,"repositoryHtmlUrl":48,"repositoryHomepageUrl":6,"ownerHtmlUrl":49,"ownerBlogUrl":50,"ownerDescription":51,"updatedAt":52,"install":53,"resources":66},"01M6R9EJSQW9WYW737271RCRB6","speedup-proof",null,"Find software performance hotspots, propose focused safe optimizations, require explicit user approval before changing any project file, and prove or reject approved changes with repeatable before-and-after benchmarks. Use when Codex is asked to make code faster, optimize a function or hot path, reduce runtime work, investigate a performance regression, benchmark a command, validate a refactor, compare performance before and after a change, or produce an evidence-backed optimization report while preserving behavior.","Nairon-AI\u002Fagentic-starter-pack","Nairon-AI","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F260662138?v=4","01M6R8PZ1Y8CSQGFN61VACZGTH","Nairon AI","01M6R8PZ6184VR3BA88YZFBC3N",4,"MIT","https:\u002F\u002Fgithub.com\u002FNairon-AI\u002Fagentic-starter-pack\u002Fblob\u002Fmain\u002Fengineering\u002Fspeedup-proof\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"speedup proof","proof","evidence","when","reduce","path","make","software","project","optimize","safe","command","work","regression","before and after","refactor","benchmark","code","change","performance","2026-11-10 10:12:30",false,"---\nname: speedup-proof\ndescription: Find software performance hotspots, propose focused safe optimizations, require explicit user approval before changing any project file, and prove or reject approved changes with repeatable before-and-after benchmarks. Use when Codex is asked to make code faster, optimize a function or hot path, reduce runtime work, investigate a performance regression, benchmark a command, validate a refactor, compare performance before and after a change, or produce an evidence-backed optimization report while preserving behavior.\n---\n\n# Speedup Proof\n\nTreat every optimization as a falsifiable experiment: inspect first, propose one exact change, obtain explicit approval, preserve behavior, measure a baseline, implement only the approved change, verify correctness, measure again, and keep only a result supported by evidence.\n\n## Require approval before edits\n\nTreat invocation of `$speedup-proof` as consent to inspect the project, never as consent to modify it.\n\n- Always begin with read-only analysis, even when the initial request says optimize, apply, fix, implement, or use `prove` mode.\n- Do not create or edit project files, benchmark harnesses, tests, reports, dependency files, configuration, worktrees, or generated artifacts before the approval checkpoint.\n- Do not install dependencies, run formatters, execute migrations, or run commands that can mutate project state before approval.\n- Never interpret broad phrases such as `optimize this codebase`, `do it`, or a bare skill invocation as approval for an unseen patch.\n- Ask for approval only after showing a concrete bounded proposal. Do not ask for blank-cheque approval before analysis.\n\nPresent this checkpoint and stop:\n\n```markdown\n## Proposed speedup\n\n- Hotspot: file and line\n- Evidence: why this path is likely costly\n- Exact files to change or create\n- Proposed transformation\n- Behavior that must remain identical\n- Benchmark and test plan\n- Main risk\n- Scope: one logical optimization\n\nNo project files have been modified. Do you want me to apply this exact change?\n```\n\nContinue only after the user explicitly approves that displayed proposal. Approval applies only to the listed files and transformation. If the scope, file list, behavior, dependencies, or optimization changes, stop and request fresh approval. Never apply a second unrelated optimization under the first approval.\n\n## Select a mode\n\n- Use `prove` when asked to optimize, fix, improve, or speed up code. Inspect, propose, wait for approval, then measure, edit, verify, remeasure, and report.\n- Use `audit` when asked to inspect, analyze, scan, or report. Rank candidates without editing source files.\n- Use `regression` when asked what became slower in a branch, commit, PR, or recent change. Compare equivalent workloads without disturbing uncommitted work.\n\nNever edit files in `audit` mode. In every other mode, require the approval checkpoint before modifying project state.\n\n## Run the proof workflow\n\n### 1. Establish the contract\n\n- Identify the exact function, endpoint, render path, query, build step, or command in scope.\n- Record outputs, ordering, errors, side effects, public APIs, permissions, persistence, and other behavior that must remain stable.\n- Detect the relevant tests, typecheck, lint, and build commands.\n- Choose realistic input sizes and distributions. Do not prove a production claim with a toy fixture.\n\n### 2. Find and rank candidates\n\n- Prefer profiler output, telemetry, traces, slow tests, query logs, or existing benchmarks.\n- Otherwise inspect likely hot paths for repeated scans, nested lookups, unnecessary allocations, repeated parsing or serialization, N+1 I\u002FO, render churn, duplicate filesystem work, and avoidable recomputation.\n- Rank candidates by execution frequency × input size × unit cost × confidence.\n- Read `references\u002Foptimization-patterns.md` when selecting transformations.\n- Pick one high-confidence candidate. Do not bundle unrelated changes into one measurement.\n\n### 3. Request approval\n\n- Show the required approval checkpoint with the exact hotspot, evidence, files, transformation, preserved behavior, benchmark, tests, and risk.\n- State clearly that no project files have been modified.\n- Stop and wait for explicit approval.\n- If approval is denied, offer the read-only findings and make no changes.\n\n### 4. Measure the baseline\n\n- Reuse an existing benchmark only when it exercises the relevant behavior.\n- Otherwise create the smallest harness that imports real production code and uses deterministic, representative fixtures.\n- Exclude fixture construction from the timed region unless setup is part of the user-visible workload.\n- Run at least 2 warmups and 7 measured iterations. Use more for short or variable work.\n- Keep runtime, dependencies, machine conditions, fixtures, caches, and command equivalent before and after.\n- Use median as the primary metric; retain p95, range, and coefficient of variation.\n- Read `references\u002Fmeasurement-playbook.md` before creating a new benchmark.\n- Use the bundled runner when command-level timing is appropriate:\n\n```bash\npython3 scripts\u002Fbenchmark_command.py --label before --warmups 2 --runs 9 --output before.json -- python3 benchmark.py\n```\n\nIf the workload depends on uncontrolled network latency, shared remote services, changing data, or interactive timing, isolate the variable or return `INCONCLUSIVE`.\n\n### 5. Make the approved safe change\n\n- Modify only the files and behavior described in the approved proposal.\n- Add or strengthen a focused correctness test first when behavior is ambiguous.\n- Preserve output equality, ordering, side effects, authorization, error handling, and public interfaces.\n- Keep the patch small enough to attribute the measured effect.\n- Do not add caching without an invalidation strategy.\n- Do not remove validation, security, logging, accessibility, or error handling to manufacture a speedup.\n\n### 6. Verify and remeasure\n\n- Run the narrowest correctness test, then the broadest relevant test\u002Fbuild\u002Ftypecheck.\n- Rerun the exact same benchmark under equivalent conditions.\n- Compare the two evidence files:\n\n```bash\npython3 scripts\u002Fcompare_results.py before.json after.json comparison.json --correctness passed\n```\n\n- Reject or revert the optimization if it breaks behavior or causes a regression. Never retain a slower patch only because its Big-O estimate looks cleaner.\n\n### 7. Report the verdict\n\nUse one evidence label:\n\n- `PROVEN` — Correctness checks pass and stable measurements beat the noise threshold.\n- `INCONCLUSIVE` — The difference is too small, noisy, unrepresentative, or correctness is unverified.\n- `REGRESSION` — The after measurement is materially slower or correctness fails.\n- `UNMEASURED` — No credible benchmark could be constructed within scope.\n\nNever claim a speedup from Big-O reasoning, code appearance, one run, or an estimated percentage. Complexity analysis may explain an observed result; it cannot replace measurement.\n\n## Create the native report\n\nFor a completed `prove` or `regression` run, create:\n\n- `outputs\u002Fspeedup-proof-results.json` — machine-readable benchmark and comparison evidence.\n- `outputs\u002Fspeedup-proof-report.md` — the user-facing report that opens directly in Codex and renders on GitHub.\n\nPrepare a context JSON following `references\u002Freport-schema.md`, then run:\n\n```bash\npython3 scripts\u002Fgenerate_report.py comparison.json context.json outputs\u002Fspeedup-proof-report.md\n```\n\nInclude the target, contract, verdict, before\u002Fafter table, exact workload, modification, clickable changed-file links, tests, reproduction steps, limitations, and residual risks. Open or link the Markdown report in Codex; do not leave the user with raw logs alone.\n\n## Protect regression comparisons\n\n- Preserve uncommitted work.\n- Prefer an existing separate worktree or create a temporary worktree for the comparison revision.\n- Keep dependency versions, runtime, fixtures, environment, warmups, and runs identical.\n- Do not rewrite history, reset the working tree, or modify lockfiles merely to benchmark.\n- Attribute a regression to the revision only when the workloads are equivalent.\n\n## Hand off the result\n\nReport the verdict first, then:\n\n1. Before and after medians\n2. Percentage change and speedup ratio when proven\n3. Benchmark command, input scale, warmups, runs, and variability\n4. Files changed\n5. Correctness checks\n6. Limitations or residual risk\n7. Link to `outputs\u002Fspeedup-proof-report.md`\n\nIf no safe measurable win exists, say so directly. An honest `INCONCLUSIVE` result is more valuable than an invented optimization.\n","# Speedup Proof\n\nTreat every optimization as a falsifiable experiment: inspect first, propose one exact change, obtain explicit approval, preserve behavior, measure a baseline, implement only the approved change, verify correctness, measure again, and keep only a result supported by evidence.\n\n## Require approval before edits\n\nTreat invocation of `$speedup-proof` as consent to inspect the project, never as consent to modify it.\n\n- Always begin with read-only analysis, even when the initial request says optimize, apply, fix, implement, or use `prove` mode.\n- Do not create or edit project files, benchmark harnesses, tests, reports, dependency files, configuration, worktrees, or generated artifacts before the approval checkpoint.\n- Do not install dependencies, run formatters, execute migrations, or run commands that can mutate project state before approval.\n- Never interpret broad phrases such as `optimize this codebase`, `do it`, or a bare skill invocation as approval for an unseen patch.\n- Ask for approval only after showing a concrete bounded proposal. Do not ask for blank-cheque approval before analysis.\n\nPresent this checkpoint and stop:\n\n```markdown\n## Proposed speedup\n\n- Hotspot: file and line\n- Evidence: why this path is likely costly\n- Exact files to change or create\n- Proposed transformation\n- Behavior that must remain identical\n- Benchmark and test plan\n- Main risk\n- Scope: one logical optimization\n\nNo project files have been modified. Do you want me to apply this exact change?\n```\n\nContinue only after the user explicitly approves that displayed proposal. Approval applies only to the listed files and transformation. If the scope, file list, behavior, dependencies, or optimization changes, stop and request fresh approval. Never apply a second unrelated optimization under the first approval.\n\n## Select a mode\n\n- Use `prove` when asked to optimize, fix, improve, or speed up code. Inspect, propose, wait for approval, then measure, edit, verify, remeasure, and report.\n- Use `audit` when asked to inspect, analyze, scan, or report. Rank candidates without editing source files.\n- Use `regression` when asked what became slower in a branch, commit, PR, or recent change. Compare equivalent workloads without disturbing uncommitted work.\n\nNever edit files in `audit` mode. In every other mode, require the approval checkpoint before modifying project state.\n\n## Run the proof workflow\n\n### 1. Establish the contract\n\n- Identify the exact function, endpoint, render path, query, build step, or command in scope.\n- Record outputs, ordering, errors, side effects, public APIs, permissions, persistence, and other behavior that must remain stable.\n- Detect the relevant tests, typecheck, lint, and build commands.\n- Choose realistic input sizes and distributions. Do not prove a production claim with a toy fixture.\n\n### 2. Find and rank candidates\n\n- Prefer profiler output, telemetry, traces, slow tests, query logs, or existing benchmarks.\n- Otherwise inspect likely hot paths for repeated scans, nested lookups, unnecessary allocations, repeated parsing or serialization, N+1 I\u002FO, render churn, duplicate filesystem work, and avoidable recomputation.\n- Rank candidates by execution frequency × input size × unit cost × confidence.\n- Read `references\u002Foptimization-patterns.md` when selecting transformations.\n- Pick one high-confidence candidate. Do not bundle unrelated changes into one measurement.\n\n### 3. Request approval\n\n- Show the required approval checkpoint with the exact hotspot, evidence, files, transformation, preserved behavior, benchmark, tests, and risk.\n- State clearly that no project files have been modified.\n- Stop and wait for explicit approval.\n- If approval is denied, offer the read-only findings and make no changes.\n\n### 4. Measure the baseline\n\n- Reuse an existing benchmark only when it exercises the relevant behavior.\n- Otherwise create the smallest harness that imports real production code and uses deterministic, representative fixtures.\n- Exclude fixture construction from the timed region unless setup is part of the user-visible workload.\n- Run at least 2 warmups and 7 measured iterations. Use more for short or variable work.\n- Keep runtime, dependencies, machine conditions, fixtures, caches, and command equivalent before and after.\n- Use median as the primary metric; retain p95, range, and coefficient of variation.\n- Read `references\u002Fmeasurement-playbook.md` before creating a new benchmark.\n- Use the bundled runner when command-level timing is appropriate:\n\n```bash\npython3 scripts\u002Fbenchmark_command.py --label before --warmups 2 --runs 9 --output before.json -- python3 benchmark.py\n```\n\nIf the workload depends on uncontrolled network latency, shared remote services, changing data, or interactive timing, isolate the variable or return `INCONCLUSIVE`.\n\n### 5. Make the approved safe change\n\n- Modify only the files and behavior described in the approved proposal.\n- Add or strengthen a focused correctness test first when behavior is ambiguous.\n- Preserve output equality, ordering, side effects, authorization, error handling, and public interfaces.\n- Keep the patch small enough to attribute the measured effect.\n- Do not add caching without an invalidation strategy.\n- Do not remove validation, security, logging, accessibility, or error handling to manufacture a speedup.\n\n### 6. Verify and remeasure\n\n- Run the narrowest correctness test, then the broadest relevant test\u002Fbuild\u002Ftypecheck.\n- Rerun the exact same benchmark under equivalent conditions.\n- Compare the two evidence files:\n\n```bash\npython3 scripts\u002Fcompare_results.py before.json after.json comparison.json --correctness passed\n```\n\n- Reject or revert the optimization if it breaks behavior or causes a regression. Never retain a slower patch only because its Big-O estimate looks cleaner.\n\n### 7. Report the verdict\n\nUse one evidence label:\n\n- `PROVEN` — Correctness checks pass and stable measurements beat the noise threshold.\n- `INCONCLUSIVE` — The difference is too small, noisy, unrepresentative, or correctness is unverified.\n- `REGRESSION` — The after measurement is materially slower or correctness fails.\n- `UNMEASURED` — No credible benchmark could be constructed within scope.\n\nNever claim a speedup from Big-O reasoning, code appearance, one run, or an estimated percentage. Complexity analysis may explain an observed result; it cannot replace measurement.\n\n## Create the native report\n\nFor a completed `prove` or `regression` run, create:\n\n- `outputs\u002Fspeedup-proof-results.json` — machine-readable benchmark and comparison evidence.\n- `outputs\u002Fspeedup-proof-report.md` — the user-facing report that opens directly in Codex and renders on GitHub.\n\nPrepare a context JSON following `references\u002Freport-schema.md`, then run:\n\n```bash\npython3 scripts\u002Fgenerate_report.py comparison.json context.json outputs\u002Fspeedup-proof-report.md\n```\n\nInclude the target, contract, verdict, before\u002Fafter table, exact workload, modification, clickable changed-file links, tests, reproduction steps, limitations, and residual risks. Open or link the Markdown report in Codex; do not leave the user with raw logs alone.\n\n## Protect regression comparisons\n\n- Preserve uncommitted work.\n- Prefer an existing separate worktree or create a temporary worktree for the comparison revision.\n- Keep dependency versions, runtime, fixtures, environment, warmups, and runs identical.\n- Do not rewrite history, reset the working tree, or modify lockfiles merely to benchmark.\n- Attribute a regression to the revision only when the workloads are equivalent.\n\n## Hand off the result\n\nReport the verdict first, then:\n\n1. Before and after medians\n2. Percentage change and speedup ratio when proven\n3. Benchmark command, input scale, warmups, runs, and variability\n4. Files changed\n5. Correctness checks\n6. Limitations or residual risk\n7. Link to `outputs\u002Fspeedup-proof-report.md`\n\nIf no safe measurable win exists, say so directly. An honest `INCONCLUSIVE` result is more valuable than an invented optimization.\n",{"name":5,"description":7},"main","c9d0c408715983e993b2f9ebffdbfa7f10153bcb","engineering\u002Fspeedup-proof",0,"https:\u002F\u002Fgithub.com\u002FNairon-AI\u002Fagentic-starter-pack","https:\u002F\u002Fgithub.com\u002FNairon-AI","https:\u002F\u002Fwww.naironai.com\u002F","Building the future of Work","2026-09-20 17:40:05",{"source":8,"skillName":5,"commands":54,"prompt":64,"zipAvailable":65},[55,58,61],{"tool":56,"command":57},"npx","npx skills add Nairon-AI\u002Fagentic-starter-pack --skill speedup-proof",{"tool":59,"command":60},"bunx","bunx skills add Nairon-AI\u002Fagentic-starter-pack --skill speedup-proof",{"tool":62,"command":63},"pnpm","pnpm dlx skills add Nairon-AI\u002Fagentic-starter-pack --skill speedup-proof","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FNairon-AI\u002Fagentic-starter-pack\u002Fblob\u002Fmain\u002Fengineering\u002Fspeedup-proof\u002FSKILL.md",true,[67,73,78,82,86,90,96,100],{"path":68,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":71,"sourceHtmlUrl":72},"agents\u002Fopenai.yaml","REFERENCE","参考文档",265,"https:\u002F\u002Fgithub.com\u002FNairon-AI\u002Fagentic-starter-pack\u002Fblob\u002Fmain\u002Fengineering\u002Fspeedup-proof\u002Fagents\u002Fopenai.yaml",{"path":74,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":76,"sourceHtmlUrl":77},"LICENSE","许可证",1074,"https:\u002F\u002Fgithub.com\u002FNairon-AI\u002Fagentic-starter-pack\u002Fblob\u002Fmain\u002Fengineering\u002Fspeedup-proof\u002FLICENSE",{"path":79,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":80,"sourceHtmlUrl":81},"references\u002Fmeasurement-playbook.md",3362,"https:\u002F\u002Fgithub.com\u002FNairon-AI\u002Fagentic-starter-pack\u002Fblob\u002Fmain\u002Fengineering\u002Fspeedup-proof\u002Freferences\u002Fmeasurement-playbook.md",{"path":83,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":84,"sourceHtmlUrl":85},"references\u002Foptimization-patterns.md",1915,"https:\u002F\u002Fgithub.com\u002FNairon-AI\u002Fagentic-starter-pack\u002Fblob\u002Fmain\u002Fengineering\u002Fspeedup-proof\u002Freferences\u002Foptimization-patterns.md",{"path":87,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":88,"sourceHtmlUrl":89},"references\u002Freport-schema.md",1367,"https:\u002F\u002Fgithub.com\u002FNairon-AI\u002Fagentic-starter-pack\u002Fblob\u002Fmain\u002Fengineering\u002Fspeedup-proof\u002Freferences\u002Freport-schema.md",{"path":91,"resourceType":92,"resourceTypeDesc":93,"sizeBytes":94,"sourceHtmlUrl":95},"scripts\u002Fbenchmark_command.py","SCRIPT","脚本",4134,"https:\u002F\u002Fgithub.com\u002FNairon-AI\u002Fagentic-starter-pack\u002Fblob\u002Fmain\u002Fengineering\u002Fspeedup-proof\u002Fscripts\u002Fbenchmark_command.py",{"path":97,"resourceType":92,"resourceTypeDesc":93,"sizeBytes":98,"sourceHtmlUrl":99},"scripts\u002Fcompare_results.py",3267,"https:\u002F\u002Fgithub.com\u002FNairon-AI\u002Fagentic-starter-pack\u002Fblob\u002Fmain\u002Fengineering\u002Fspeedup-proof\u002Fscripts\u002Fcompare_results.py",{"path":101,"resourceType":92,"resourceTypeDesc":93,"sizeBytes":102,"sourceHtmlUrl":103},"scripts\u002Fgenerate_report.py",7260,"https:\u002F\u002Fgithub.com\u002FNairon-AI\u002Fagentic-starter-pack\u002Fblob\u002Fmain\u002Fengineering\u002Fspeedup-proof\u002Fscripts\u002Fgenerate_report.py",[105,141,163,184,204,224],{"skillNo":106,"name":107,"nameZh":6,"description":108,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":109,"categories":110,"keywords":121,"publishedAt":39},"01M6RBCG630Y8X99XWR9Q4GYNY","writing-shape","Take a markdown file of raw material and shape it into an article through a conversational session — drafting candidate openings, growing the piece paragraph by paragraph, arguing about format (lists, tables, callouts, quotes) at each step. Use when the user has a pile of notes, fragments, or a rough draft and wants help turning it into something publishable.","https:\u002F\u002Fgithub.com\u002FNairon-AI\u002Fagentic-starter-pack\u002Fblob\u002Fmain\u002Fwriting\u002Fwriting-shape\u002FSKILL.md",[111,116],{"categoryNo":112,"categoryName":113,"taxonomyType":114,"taxonomyTypeDesc":115},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":117,"categoryName":118,"taxonomyType":119,"taxonomyTypeDesc":120},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[122,123,124,125,126,127,128,129,130,131,132,133,134,135,136,137,138,139,140,22],"writing","writing shape","shape","notes","help","file","markdown","format","session","use","take","draft","article","material","it","about","quotes","at","candidate",{"skillNo":142,"name":143,"nameZh":6,"description":144,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":145,"categories":146,"keywords":149,"publishedAt":39},"01M6RBCCCB1KMF01P5SYGFWBSW","writing-fragments","Grilling session that mines the user for fragments — heterogeneous nuggets of writing (claims, vignettes, sharp sentences, half-thoughts) — and appends them to a single document as raw material for a future article. Use when the user wants to develop ideas before imposing structure, or mentions \"fragments\", \"ideate\", or \"raw material\" for writing.","https:\u002F\u002Fgithub.com\u002FNairon-AI\u002Fagentic-starter-pack\u002Fblob\u002Fmain\u002Fwriting\u002Fwriting-fragments\u002FSKILL.md",[147,148],{"categoryNo":112,"categoryName":113,"taxonomyType":114,"taxonomyTypeDesc":115},{"categoryNo":117,"categoryName":118,"taxonomyType":119,"taxonomyTypeDesc":120},[122,150,151,152,153,154,130,131,155,156,157,134,158,135,159,160,161,162,22],"writing fragments","grilling","ideate","develop","user","document","structure","ideas","as","sharp","claims","for","single",{"skillNo":164,"name":165,"nameZh":6,"description":166,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":167,"categories":168,"keywords":171,"publishedAt":39},"01M6RBC8V7NHHKMTAZB4BPXVYQ","writing-beats","Shape an article as a journey of beats, choose-your-own-adventure style. The user picks a starting beat from the raw material, you write only that beat, then offer options for where to pivot next, beat by beat, until the article reaches a natural end. Use when the user has raw material and wants to assemble it as a narrative rather than an argument.","https:\u002F\u002Fgithub.com\u002FNairon-AI\u002Fagentic-starter-pack\u002Fblob\u002Fmain\u002Fwriting\u002Fwriting-beats\u002FSKILL.md",[169,170],{"categoryNo":112,"categoryName":113,"taxonomyType":114,"taxonomyTypeDesc":115},{"categoryNo":117,"categoryName":118,"taxonomyType":119,"taxonomyTypeDesc":120},[122,172,173,174,131,175,176,124,177,178,179,134,180,158,181,135,182,183,161,22],"writing beats","choose","write","assemble","only","journey","next","options","end","style","narrative","argument",{"skillNo":185,"name":186,"nameZh":6,"description":187,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":188,"categories":189,"keywords":192,"publishedAt":39},"01M6RBC58SG5Y5SC4ZV4ZNEFHC","stop-slop","Remove AI writing patterns from prose. Use when drafting, editing, or reviewing text to eliminate predictable AI tells.","https:\u002F\u002Fgithub.com\u002FNairon-AI\u002Fagentic-starter-pack\u002Fblob\u002Fmain\u002Fwriting\u002Fstop-slop\u002FSKILL.md",[190,191],{"categoryNo":112,"categoryName":113,"taxonomyType":114,"taxonomyTypeDesc":115},{"categoryNo":117,"categoryName":118,"taxonomyType":119,"taxonomyTypeDesc":120},[193,194,195,122,196,197,198,199,200,131,201,202,203,161,22],"stop","stop slop","slop","content","https","text","editing","remove","prose","patterns","drafts",{"skillNo":205,"name":206,"nameZh":6,"description":207,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":208,"categories":209,"keywords":212,"publishedAt":39},"01M6RBBJTTCJ7KZCP16G9JDFZH","humanizer","Remove signs of AI-generated writing from text. Use when editing or reviewing\ntext to make it sound more natural and human-written. Based on Wikipedia's\ncomprehensive \"Signs of AI writing\" guide. Detects and fixes patterns including:\ninflated symbolism, promotional language, superficial -ing analyses, vague\nattributions, em dash overuse, rule of three, AI vocabulary words, passive\nvoice, negative parallelisms, and filler phrases.","https:\u002F\u002Fgithub.com\u002FNairon-AI\u002Fagentic-starter-pack\u002Fblob\u002Fmain\u002Fwriting\u002Fhumanizer\u002FSKILL.md",[210,211],{"categoryNo":112,"categoryName":113,"taxonomyType":114,"taxonomyTypeDesc":115},{"categoryNo":117,"categoryName":118,"taxonomyType":119,"taxonomyTypeDesc":120},[206,122,36,213,198,214,174,215,216,200,217,218,202,219,220,25,221,222,223,22],"em dash","read","edit","generated","guide","opencode","three","human","wikipedia","vague","dash",{"skillNo":225,"name":226,"nameZh":6,"description":227,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":228,"categories":229,"keywords":230,"publishedAt":39},"01M6RBBEQKJ5HRH8AV9J85QB1T","feedback","Prepare, deliver, and debrief timely interpersonal feedback using a question-first coaching flow, observable behavior, owned experience, and concrete impact. Use when drafting feedback, coaching managers, rehearsing a feedback conversation, praising specific behavior, or reviewing whether feedback landed.","https:\u002F\u002Fgithub.com\u002FNairon-AI\u002Fagentic-starter-pack\u002Fblob\u002Fmain\u002Fwriting\u002Ffeedback\u002FSKILL.md",[],[226,231,232,233,234,235,131,236,237,238,239,240,22,241],"prepare","flow","first","question","behavior","conversation","coaching","debrief","impact","managers","deliver"]