[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6R9CVKCT3WZMKFDQJ6WR22N":3,"skill-same:01M6R9CVKCT3WZMKFDQJ6WR22N":67},{"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},"01M6R9CVKCT3WZMKFDQJ6WR22N","review-for-engineering-taste",null,"Review code at a high level for subtle design papercuts that create long-term slop creep. Use when the user asks for an engineering taste review, wants a high-level code quality pass, asks \"does this feel clean?\", \"what feels off?\", \"what are the papercut decisions here?\", or wants to catch problematic small decisions before they calcify into local conventions.","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\u002Freview-for-engineering-taste\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"review","review for engineering taste","for","taste","engineering","code","decisions","use","taste review","clean","local","create","long","high","code quality","slop","catch","papercuts","when","design","2026-11-10 10:12:30",false,"---\nname: review-for-engineering-taste\ndescription: Review code at a high level for subtle design papercuts that create long-term slop creep. Use when the user asks for an engineering taste review, wants a high-level code quality pass, asks \"does this feel clean?\", \"what feels off?\", \"what are the papercut decisions here?\", or wants to catch problematic small decisions before they calcify into local conventions.\n---\n\n# Review For Engineering Taste\n\nUse this skill for a taste review, not a correctness review.\n\nThe job is to spot small design decisions that individually look acceptable but collectively make a codebase slower to change, harder to trust, or easier to bloat. Focus on choices that create future drag: awkward boundaries, vague ownership, leaky abstractions, incidental complexity, and defensive structure added before it pays for itself.\n\nIf a concern looks repeatable, do not stop at the review comment. Run the structuralization checkpoint below so the developer can decide whether the pattern should become a project constraint, a `lintcn` rule, a brain note, or just a one-off fix.\n\n## Default Stance\n\n- Review the shape of the solution before the syntax.\n- Prefer questions that expose design tension over style comments.\n- Look for decisions that will get copied.\n- Favor the smallest cleanup that restores clarity.\n- Be specific about why something is a slop risk.\n\n## Workflow\n\n1. Build a quick mental model of the change or area under review.\n2. Run the question set below.\n3. Report only the questions that surfaced real risk.\n4. For any repeatable concern, run the structuralization checkpoint with the developer.\n5. End with the top 1 to 3 slop-creep concerns and the smallest worthwhile correction for each.\n\nIf nothing rises above taste preference, say that explicitly.\n\n## Structuralization Checkpoint\n\nWhen a concern looks like something the codebase could accidentally normalize, ask before encoding:\n\n- \"Is this actually undesirable in this repo, or was it a reasonable tradeoff here?\"\n- \"If it's undesirable, do you want to enforce that going forward?\"\n\nThen decide whether the finding should become:\n- a `lintcn` rule\n- a brain principle or pitfall\n- a one-off correction with no structural follow-up\n\nDefault to `warn` for new taste-oriented `lintcn` rules unless the pattern is an objective anti-pattern with low false-positive risk.\n\n## Question Set\n\nAsk these questions in order. Skip ones that are clearly irrelevant.\n\n### 1. Boundary Fit\n\n- Does this code live in the right module, layer, or component, or is it quietly teaching the wrong ownership boundary?\n- Did the change introduce a new concept that is really just a one-off detail in disguise?\n- Is an abstraction being added because multiple callers need it now, or because it might be useful later?\n\n### 2. Local Reasoning\n\n- Can a future reader understand the control flow without jumping through too many files, helpers, or indirections?\n- Did the code trade a simple direct path for a \"cleaner\" structure that is harder to mentally execute?\n- Are there too many moving pieces for the amount of behavior implemented?\n\n### 3. Naming And Intent\n\n- Do the names describe the real job of the code, or do they hide uncertainty behind generic terms like `utils`, `manager`, `data`, `handle`, or `process`?\n- Is the public API sharper than the implementation, or is vagueness leaking outward?\n- Would a new engineer form the right mental model from the names alone?\n\n### 4. Data Shape And Invariants\n\n- Are important invariants obvious in the types, function boundaries, or data model, or are they only implied by call-site discipline?\n- Did the change add optionality, fallback behavior, or config surface where the domain really wants one clear path?\n- Is the code preserving the natural shape of the data, or forcing it through unnecessary mapping, normalization, or wrapper layers?\n\n### 5. Coupling And Escape Hatches\n\n- Did this introduce hidden coupling between modules, UI state, storage, network logic, or framework details?\n- Is there a new flag, callback, prop, or option that acts as an escape hatch for unclear ownership?\n- Are we solving one awkward call site by making the whole API less coherent?\n\n### 6. Complexity Versus Change Rate\n\n- Is the amount of structure proportional to how often this code is likely to change?\n- Did the author pay an abstraction tax before the repetition or volatility justified it?\n- Would deleting or inlining part of this make the system easier to evolve?\n\n### 7. Failure And Debuggability\n\n- When this breaks, will the failure show up near the cause, or will it become a scavenger hunt?\n- Did the change hide important branching or fallback behavior behind helpers that make debugging harder?\n- Are errors, defaults, retries, or null handling making the happy path look cleaner while obscuring real behavior?\n\n### 8. Test Shape\n\n- Do the tests reinforce the intended contract, or do they lock in incidental structure?\n- Is the code hard to test because the design is muddy, not because the test is weak?\n- Are mocks, setup, or fixture layers compensating for avoidable design friction?\n\n### 9. Copyability\n\n- If another engineer copied this pattern five times, would the codebase get cleaner or sloppier?\n- Is this setting a precedent for new wrappers, new configuration knobs, or new special cases?\n- Does this teach restraint, or does it normalize ceremony?\n\n## Output Format\n\nWhen you find issues, report them as:\n\n- `Question:` the specific question that tripped\n- `Why it matters:` the slop-creep risk, in concrete terms\n- `Smallest fix:` the least invasive correction that would materially improve the design\n- `Structural follow-up:` only when applicable. State whether this should become a `lintcn` rule candidate, a brain principle, or nothing structural.\n\nKeep the final summary high signal:\n\n- `Top risks:` 1 to 3 bullets\n- `What to leave alone:` call out anything that looks unusual but is actually a reasonable tradeoff\n\n## Gotchas\n\n- Do not turn this into a bug hunt, security review, or lint pass unless those issues reveal a deeper taste problem.\n- Do not flag code just because you would personally write it differently.\n- Do not reward abstraction density. Fewer concepts is usually better when the behavior is still small.\n- Do not recommend framework-shaped patterns unless they clearly improve local reasoning in this codebase.\n- Do not confuse \"a little duplication\" with a design failure. Premature deduplication is a common source of slop.\n- Do not produce a long list of weak nits. If the issue would not matter six months from now, drop it.\n- Do not create a `lintcn` rule candidate without confirming that the developer actually wants repo-wide enforcement for subjective taste issues.\n","# Review For Engineering Taste\n\nUse this skill for a taste review, not a correctness review.\n\nThe job is to spot small design decisions that individually look acceptable but collectively make a codebase slower to change, harder to trust, or easier to bloat. Focus on choices that create future drag: awkward boundaries, vague ownership, leaky abstractions, incidental complexity, and defensive structure added before it pays for itself.\n\nIf a concern looks repeatable, do not stop at the review comment. Run the structuralization checkpoint below so the developer can decide whether the pattern should become a project constraint, a `lintcn` rule, a brain note, or just a one-off fix.\n\n## Default Stance\n\n- Review the shape of the solution before the syntax.\n- Prefer questions that expose design tension over style comments.\n- Look for decisions that will get copied.\n- Favor the smallest cleanup that restores clarity.\n- Be specific about why something is a slop risk.\n\n## Workflow\n\n1. Build a quick mental model of the change or area under review.\n2. Run the question set below.\n3. Report only the questions that surfaced real risk.\n4. For any repeatable concern, run the structuralization checkpoint with the developer.\n5. End with the top 1 to 3 slop-creep concerns and the smallest worthwhile correction for each.\n\nIf nothing rises above taste preference, say that explicitly.\n\n## Structuralization Checkpoint\n\nWhen a concern looks like something the codebase could accidentally normalize, ask before encoding:\n\n- \"Is this actually undesirable in this repo, or was it a reasonable tradeoff here?\"\n- \"If it's undesirable, do you want to enforce that going forward?\"\n\nThen decide whether the finding should become:\n- a `lintcn` rule\n- a brain principle or pitfall\n- a one-off correction with no structural follow-up\n\nDefault to `warn` for new taste-oriented `lintcn` rules unless the pattern is an objective anti-pattern with low false-positive risk.\n\n## Question Set\n\nAsk these questions in order. Skip ones that are clearly irrelevant.\n\n### 1. Boundary Fit\n\n- Does this code live in the right module, layer, or component, or is it quietly teaching the wrong ownership boundary?\n- Did the change introduce a new concept that is really just a one-off detail in disguise?\n- Is an abstraction being added because multiple callers need it now, or because it might be useful later?\n\n### 2. Local Reasoning\n\n- Can a future reader understand the control flow without jumping through too many files, helpers, or indirections?\n- Did the code trade a simple direct path for a \"cleaner\" structure that is harder to mentally execute?\n- Are there too many moving pieces for the amount of behavior implemented?\n\n### 3. Naming And Intent\n\n- Do the names describe the real job of the code, or do they hide uncertainty behind generic terms like `utils`, `manager`, `data`, `handle`, or `process`?\n- Is the public API sharper than the implementation, or is vagueness leaking outward?\n- Would a new engineer form the right mental model from the names alone?\n\n### 4. Data Shape And Invariants\n\n- Are important invariants obvious in the types, function boundaries, or data model, or are they only implied by call-site discipline?\n- Did the change add optionality, fallback behavior, or config surface where the domain really wants one clear path?\n- Is the code preserving the natural shape of the data, or forcing it through unnecessary mapping, normalization, or wrapper layers?\n\n### 5. Coupling And Escape Hatches\n\n- Did this introduce hidden coupling between modules, UI state, storage, network logic, or framework details?\n- Is there a new flag, callback, prop, or option that acts as an escape hatch for unclear ownership?\n- Are we solving one awkward call site by making the whole API less coherent?\n\n### 6. Complexity Versus Change Rate\n\n- Is the amount of structure proportional to how often this code is likely to change?\n- Did the author pay an abstraction tax before the repetition or volatility justified it?\n- Would deleting or inlining part of this make the system easier to evolve?\n\n### 7. Failure And Debuggability\n\n- When this breaks, will the failure show up near the cause, or will it become a scavenger hunt?\n- Did the change hide important branching or fallback behavior behind helpers that make debugging harder?\n- Are errors, defaults, retries, or null handling making the happy path look cleaner while obscuring real behavior?\n\n### 8. Test Shape\n\n- Do the tests reinforce the intended contract, or do they lock in incidental structure?\n- Is the code hard to test because the design is muddy, not because the test is weak?\n- Are mocks, setup, or fixture layers compensating for avoidable design friction?\n\n### 9. Copyability\n\n- If another engineer copied this pattern five times, would the codebase get cleaner or sloppier?\n- Is this setting a precedent for new wrappers, new configuration knobs, or new special cases?\n- Does this teach restraint, or does it normalize ceremony?\n\n## Output Format\n\nWhen you find issues, report them as:\n\n- `Question:` the specific question that tripped\n- `Why it matters:` the slop-creep risk, in concrete terms\n- `Smallest fix:` the least invasive correction that would materially improve the design\n- `Structural follow-up:` only when applicable. State whether this should become a `lintcn` rule candidate, a brain principle, or nothing structural.\n\nKeep the final summary high signal:\n\n- `Top risks:` 1 to 3 bullets\n- `What to leave alone:` call out anything that looks unusual but is actually a reasonable tradeoff\n\n## Gotchas\n\n- Do not turn this into a bug hunt, security review, or lint pass unless those issues reveal a deeper taste problem.\n- Do not flag code just because you would personally write it differently.\n- Do not reward abstraction density. Fewer concepts is usually better when the behavior is still small.\n- Do not recommend framework-shaped patterns unless they clearly improve local reasoning in this codebase.\n- Do not confuse \"a little duplication\" with a design failure. Premature deduplication is a common source of slop.\n- Do not produce a long list of weak nits. If the issue would not matter six months from now, drop it.\n- Do not create a `lintcn` rule candidate without confirming that the developer actually wants repo-wide enforcement for subjective taste issues.\n",{"name":5,"description":7},"main","c9d0c408715983e993b2f9ebffdbfa7f10153bcb","engineering\u002Freview-for-engineering-taste",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 review-for-engineering-taste",{"tool":59,"command":60},"bunx","bunx skills add Nairon-AI\u002Fagentic-starter-pack --skill review-for-engineering-taste",{"tool":62,"command":63},"pnpm","pnpm dlx skills add Nairon-AI\u002Fagentic-starter-pack --skill review-for-engineering-taste","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FNairon-AI\u002Fagentic-starter-pack\u002Fblob\u002Fmain\u002Fengineering\u002Freview-for-engineering-taste\u002FSKILL.md",true,[],[68,103,124,145,164,185],{"skillNo":69,"name":70,"nameZh":6,"description":71,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":72,"categories":73,"keywords":84,"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",[74,79],{"categoryNo":75,"categoryName":76,"taxonomyType":77,"taxonomyTypeDesc":78},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":80,"categoryName":81,"taxonomyType":82,"taxonomyTypeDesc":83},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[85,86,87,88,89,90,91,92,93,26,94,95,96,97,98,99,100,101,102,37],"writing","writing shape","shape","notes","help","file","markdown","format","session","take","draft","article","material","it","about","quotes","at","candidate",{"skillNo":104,"name":105,"nameZh":6,"description":106,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":107,"categories":108,"keywords":111,"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",[109,110],{"categoryNo":75,"categoryName":76,"taxonomyType":77,"taxonomyTypeDesc":78},{"categoryNo":80,"categoryName":81,"taxonomyType":82,"taxonomyTypeDesc":83},[85,112,113,114,115,116,93,26,117,118,119,96,120,97,121,122,21,123,37],"writing fragments","grilling","ideate","develop","user","document","structure","ideas","as","sharp","claims","single",{"skillNo":125,"name":126,"nameZh":6,"description":127,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":128,"categories":129,"keywords":132,"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",[130,131],{"categoryNo":75,"categoryName":76,"taxonomyType":77,"taxonomyTypeDesc":78},{"categoryNo":80,"categoryName":81,"taxonomyType":82,"taxonomyTypeDesc":83},[85,133,134,135,26,136,137,87,138,139,140,96,141,120,142,97,143,144,21,37],"writing beats","choose","write","assemble","only","journey","next","options","end","style","narrative","argument",{"skillNo":146,"name":147,"nameZh":6,"description":148,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":149,"categories":150,"keywords":153,"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",[151,152],{"categoryNo":75,"categoryName":76,"taxonomyType":77,"taxonomyTypeDesc":78},{"categoryNo":80,"categoryName":81,"taxonomyType":82,"taxonomyTypeDesc":83},[154,155,34,85,156,157,158,159,160,26,161,162,163,21,37],"stop","stop slop","content","https","text","editing","remove","prose","patterns","drafts",{"skillNo":165,"name":166,"nameZh":6,"description":167,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":168,"categories":169,"keywords":172,"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",[170,171],{"categoryNo":75,"categoryName":76,"taxonomyType":77,"taxonomyTypeDesc":78},{"categoryNo":80,"categoryName":81,"taxonomyType":82,"taxonomyTypeDesc":83},[166,85,24,173,158,174,135,175,176,160,177,178,162,179,180,181,182,183,184,37],"em dash","read","edit","generated","guide","opencode","three","human","make","wikipedia","vague","dash",{"skillNo":186,"name":187,"nameZh":6,"description":188,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":189,"categories":190,"keywords":191,"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",[],[187,192,193,194,195,196,26,197,198,199,200,201,37,202],"prepare","flow","first","question","behavior","conversation","coaching","debrief","impact","managers","deliver"]