[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M7D1DWSP4FCZB087RS3VBPDW":3,"skill-same:01M7D1DWSP4FCZB087RS3VBPDW":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},"01M7D1DWSP4FCZB087RS3VBPDW","work-rating",null,"Opt-in, only when the owner asks. Have an independent subagent rate a finished piece of work out of 10 against the user's own prompts. Never run it at the end of a task on your own; the PR's one review is enough (owner, 2026-10-12, 2026-10-22).","aaronified\u002Ffluenough","aaronified","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F59017480?v=4","01M7D1D8YHKHSS51P9FM9BXMCG","Aro","01M7D1D8ZGW6HMSA4GNFPJYKMM",4,"GPL-3.0","https:\u002F\u002Fgithub.com\u002Faaronified\u002Ffluenough\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fwork-rating\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: work-rating\ndescription: Opt-in, only when the owner asks. Have an independent subagent rate a finished piece of work out of 10 against the user's own prompts. Never run it at the end of a task on your own; the PR's one review is enough (owner, 2026-10-12, 2026-10-22).\n---\n\nThe wiki is the source of truth for documentation: https:\u002F\u002Fgithub.com\u002Faaronified\u002Ffluenough\u002Fwiki\n\n# Rate the work before calling it done\n\nA closing pass that asks an independent agent one question: **did the work that was done\nmatch the work that was asked for?** It exists because the author of a change is the worst\njudge of whether it covered the request — especially in a session where the scope arrived in\npieces, which is when a request goes missing.\n\n## When to run it\n\n**Only when the owner asks for a score.** It is not a closing step. The one review per PR (CLAUDE.md, \"Budget\") is the only check. The list below says when it would help, if asked.\n\n- At the end of any task that touched more than a couple of files.\n- Whenever the user's requests arrived across several messages, or mid-task.\n- When the user asks for a rating, a score, or a check on the work.\n- Before reporting a multi-part task complete.\n\nNot worth it for a one-line fix, a question answered in prose, or a task the user is still\nactively redirecting.\n\n`session-digest` is the mid-session counterpart, and the two do not overlap: it reports\nstatus repeatedly and cheaply while the work is still moving, and reports the score this\nskill produced rather than producing one of its own. Its ledger of the user's prompts —\nverbatim, written as each arrived — is also the best source for Step 1's evidence, because it\ncannot have drifted.\n\n## The rule that makes the score mean anything\n\n**The rater is never told the target.** It is not told what score counts as passing, what\nscore previous work received, or that the score has any consequence at all. It is told only\nto rate. A rater that knows the pass mark rates to the pass mark, and the number stops\ncarrying information.\n\nSo: do not put a threshold, an expectation, a previous score, or any encouragement in the\nprompt you hand it. Hand it the prompts, the work, and nothing else.\n\nEqually: do not soften, re-weight, or argue with the number when reporting it. Report the\nscore the rater gave, verbatim, with its findings.\n\n## Procedure\n\n### Step 1 — assemble the evidence\n\nCollect, without editorialising:\n\n- **Every prompt the user sent this session, verbatim and in order.** Include the mid-task\n  ones. Do not summarise them — a paraphrase is where the request quietly becomes the thing\n  that was built.\n- **The work**: `git diff` (or `git diff --stat` plus the diff of each file) for uncommitted\n  work, or `git log -p \u003Cbase>..HEAD` for committed work.\n- **The verification output**: the actual test \u002F build \u002F lint runs, pass or fail. If none\n  were run, say so — that is itself something to be rated.\n\n### Step 2 — spawn the rater\n\nIf your runtime supports subagents, spawn one with the body of `.claude\u002Fagents\u002Fwork-rater.md`\nas its instructions and pass it the evidence from Step 1. Use Sonnet (CLAUDE.md, owner, 2026-10-22).\n\n**ITS OWN HELPERS RUN ON THE CHEAP TIER.** The owner's ruling of 27 September: a rater that\nfans out, or runs the screenshot bot, does it on the cheap tier. The judgement stays with the\nrater; what it hands off is retrieval and capture, and a helper that inherits the rater's deep\ntier pays for judgement nobody asked it for. So any agent a rater starts is started on the\ncheap tier, and screens are captured through the screenshot runner, which is cheap.\n\n**TWO THINGS IN THAT FILE'S FRONTMATTER ARE LOAD-BEARING and are not to be ignored.**\n\n- `tools: Read, Grep, Glob, Bash` — **no `Edit`, no `Write`.** The rater's most valuable\n  technique is breaking the code to see whether a test notices, and the tree under review is\n  the one place it may not do that in. Granted edit access, one of them left a shipped SQL\n  migration with a delete trigger's `kind` clause stripped, at the moment its caller's\n  commit hook was asking for a commit; the file's own section explains the rest.\n- Launch it **isolated** if your runtime can — `isolation: \"worktree\"` in Claude Code's\n  Agent tool — so it has a checkout of its own to mutate. It is told to make one anyway,\n  because it must not depend on having been launched correctly.\n\nAnd do not run anything heavy against the same tree while it works: its test runs and yours\ncompete, and a suite that fails because two things were building at once produces findings\nthat are not findings.\n\nIf your runtime has no subagents, do the pass inline against that same rubric, but say\nplainly in the report that the rating is self-assessed rather than independent.\n\n#### No more than five raters, and the commits grouped to fit\n\nThe owner's ruling: *\"Don't fan out more than 5 raters. Group commits if needed.\"* When the\nwork is more commits than five raters can each take one of, group them — by the area they\ntouch, or by the finding they answer — so that every rater is handed a body of work large\nenough to judge. Each rater gets the prompts behind its whole group, and scores each commit\nin it.\n\n**WHY A CAP, AND NOT ONE RATER PER COMMIT.** A rater must return a rating, and one handed a\ncommit with nothing wrong in it reports something anyway. The owner, stopping a fan-out of\ntwenty-two: *\"If you create such minute raters they will start hallucinating issues\nresulting in regressions.\"* It had been measured before it was ruled. In one consuming\nrepository, pushes rated one commit per rater came back with 40 to 75 findings a round and\nnever converged, and two commits made while answering those rounds were regressions that a\nlater round had to catch: a publish job that stopped running, and a pairing code that\noutlived a factory reset.\n\n**A RATING THAT FINISHED STILL STANDS WHEN THE FAN-OUT IS STOPPED.** Also the owner's:\n*\"You can act on whatever raters already rated. If they were more than 8, those commits are\nalready rated then.\"* Recover the finished results (a workflow's journal records what each\nagent returned) and act on them as on any other round. A commit whose finished rating\nalready clears the caller's bar is rated. Re-rate only the commits with no result, grouped\nas above.\n\n#### Documentation findings are reported, and scored only where a reader meets them\n\nThe owner's ruling: *\"Make the rater cut rating marks only for actual issues, documentation\nproblems are non rated issues (still should be reported) unless it is facing the user in the\napp or about a wrong claim in readme or wiki.\"* So every finding is one of two kinds, and the\nrater's prompt says which is which. That is part of how to score, not a target:\n\n- **Scored.** A behaviour defect. A test that cannot fail for the defect it names. A breach\n  of the repository's rules in code. A documentation problem a reader meets: text a user sees\n  in the app (labels, help, errors, sample content), or a wrong claim in the README or the\n  wiki.\n- **Reported, not scored.** Any other documentation problem: commit bodies, code comments,\n  internal notes such as plans, test headers and fixture notes, and wording slips in any of\n  them. Each is still listed, still fixed or answered in one line, and marked unscored. None\n  of them lowers the number.\n\n**ONE EXCEPTION STAYS SCORED: A FALSE ACCOUNT OF THE WORK.** A body or report claiming a test\nran, a mutation failed, or a thing was done, when it was not, is not a documentation slip. It\nis the dishonest report the score weighs most (see *What the score is measuring*).\n\n**WHY.** It was measured before it was ruled. One consuming repository's release took six\nrating passes. The last four scored commits below the bar almost entirely for their commit\nbodies: a misquote, a miscount, a file named wrong. History there is never rewritten, so each\ncorrection was a new body for the next pass to find fault with, and the loop ended only when\nthe owner stopped it.\n\n### Step 3 — act on it, then report\n\n1. **Fix what the rater found**, if it found something real, before you report anything. A\n   rating is a work item, not a verdict to be filed. CI re-runs the tests after the fix.\n2. **Report the score as given**, then the findings, then what you did about each. If you\n   disagree with a finding, say so in one line with the reason — do not silently drop it.\n3. **Re-rate only after fixing**, and only by handing the rater the new diff. Do not ask it\n   to reconsider the same work; that is asking for a better number rather than a better\n   answer.\n4. **Re-rate at all only when the pass found at least three major findings**, meaning scored\n   ones the rater marked high or medium. The owner's ruling: *\"if a rater didn't find at least 3\n   major issues, no need to rerun rater, regardless of rating.\"* Fewer than three: fix them all\n   and stop, whatever the score. The caller's own bar (a pass mark, say) can only ask for\n   fewer passes than this, never more.\n\n## What the score is measuring\n\nFidelity to the request, in this order of weight: every distinct thing asked for was done;\neach piece is complete (migration, second language, test, doc, every call site the rule\nreaches); it is correct; it fits the surrounding code; and the report of it is honest.\n\nThe last one carries the most weight in both directions. Claiming a suite passed without\nrunning it, describing stubbed work as finished, or narrowing the scope without saying so\nshould cost more than any implementation flaw.\n\n## Do not\n\n- Do not tell the rater the target. Not the pass mark, not a previous score, not that the\n  score has a consequence, and not that you would like it to go well. A rater that knows the\n  pass mark rates to the pass mark.\n- Do not summarise the prompts before handing them over. A paraphrase is where the request\n  quietly becomes the thing that was built.\n- Do not soften, re-weight, or round the number when reporting it.\n- Do not drop a finding you disagree with. Say so in one line, with the reason, and leave it\n  in the report.\n- Do not re-rate by asking the same rater to reconsider the same work. That is asking for a\n  better number rather than a better answer. Fix first, then hand it the new diff.\n- Do not let the agent that did the work rate it, unless the runtime has no subagents — and\n  then say in the report that the rating is self-assessed.\n- Do not fan out more than five raters, and do not hand a rater a commit too small to judge\n  on its own. Group the commits. A rater with nothing real to find invents something, and the\n  fix for an invented finding is how a regression gets in.\n- Do not throw away a finished rating because the run it was part of was stopped.\n- Do not let a rater's helpers inherit its tier. A fan-out or a screenshot run it starts is\n  on the cheap tier.\n- Do not let a documentation problem the reader never meets lower the score. Report it,\n  marked unscored. Only text in the app, or a wrong claim in the README or wiki, is scored,\n  and so is a false account of what was run or done.\n- Do not treat the score as the deliverable. It is a work item; the fixes are the deliverable.\n- Do not run this on a one-line fix, a question answered in prose, or a task the user is still\n  actively redirecting.\n\n## Verify\n\n- [ ] Every prompt the user sent this session reached the rater verbatim and in order,\n      including the ones that arrived mid-task.\n- [ ] The rater was given the diff and the real verification output — or told plainly that\n      none was run, which is itself something to be rated.\n- [ ] Nothing in the rater's prompt named a threshold, an expectation, a previous score, or a\n      consequence.\n- [ ] The rater was independent of the work, or the report says the rating is self-assessed.\n- [ ] No more than five raters ran, and each was given a group of commits large enough to\n      judge.\n- [ ] The rater was told which findings are scored and which are reported unscored, and the\n      report keeps the unscored ones.\n- [ ] A re-rating ran only after a pass with at least three major findings.\n- [ ] Every agent the rater started, and every screenshot run, was on the cheap tier.\n- [ ] The score is reported exactly as given, alongside its findings.\n- [ ] Every finding was either fixed or answered in one line with a reason; none was dropped.\n- [ ] Any re-rate was made against a new diff.\n\n---\n\n## Provenance\n\nCopied from [claude-kit](https:\u002F\u002Fgithub.com\u002Faaronified\u002Fclaude-kit) (MIT,\nCopyright (c) 2026 Aro) and vendored here so it travels with this checkout.\nPaths to the rater agent are rewritten for this repository's layout; the\nprocedure is otherwise unchanged. Fix it upstream as well as here.\n","The wiki is the source of truth for documentation: https:\u002F\u002Fgithub.com\u002Faaronified\u002Ffluenough\u002Fwiki\n\n# Rate the work before calling it done\n\nA closing pass that asks an independent agent one question: **did the work that was done\nmatch the work that was asked for?** It exists because the author of a change is the worst\njudge of whether it covered the request — especially in a session where the scope arrived in\npieces, which is when a request goes missing.\n\n## When to run it\n\n**Only when the owner asks for a score.** It is not a closing step. The one review per PR (CLAUDE.md, \"Budget\") is the only check. The list below says when it would help, if asked.\n\n- At the end of any task that touched more than a couple of files.\n- Whenever the user's requests arrived across several messages, or mid-task.\n- When the user asks for a rating, a score, or a check on the work.\n- Before reporting a multi-part task complete.\n\nNot worth it for a one-line fix, a question answered in prose, or a task the user is still\nactively redirecting.\n\n`session-digest` is the mid-session counterpart, and the two do not overlap: it reports\nstatus repeatedly and cheaply while the work is still moving, and reports the score this\nskill produced rather than producing one of its own. Its ledger of the user's prompts —\nverbatim, written as each arrived — is also the best source for Step 1's evidence, because it\ncannot have drifted.\n\n## The rule that makes the score mean anything\n\n**The rater is never told the target.** It is not told what score counts as passing, what\nscore previous work received, or that the score has any consequence at all. It is told only\nto rate. A rater that knows the pass mark rates to the pass mark, and the number stops\ncarrying information.\n\nSo: do not put a threshold, an expectation, a previous score, or any encouragement in the\nprompt you hand it. Hand it the prompts, the work, and nothing else.\n\nEqually: do not soften, re-weight, or argue with the number when reporting it. Report the\nscore the rater gave, verbatim, with its findings.\n\n## Procedure\n\n### Step 1 — assemble the evidence\n\nCollect, without editorialising:\n\n- **Every prompt the user sent this session, verbatim and in order.** Include the mid-task\n  ones. Do not summarise them — a paraphrase is where the request quietly becomes the thing\n  that was built.\n- **The work**: `git diff` (or `git diff --stat` plus the diff of each file) for uncommitted\n  work, or `git log -p \u003Cbase>..HEAD` for committed work.\n- **The verification output**: the actual test \u002F build \u002F lint runs, pass or fail. If none\n  were run, say so — that is itself something to be rated.\n\n### Step 2 — spawn the rater\n\nIf your runtime supports subagents, spawn one with the body of `.claude\u002Fagents\u002Fwork-rater.md`\nas its instructions and pass it the evidence from Step 1. Use Sonnet (CLAUDE.md, owner, 2026-10-22).\n\n**ITS OWN HELPERS RUN ON THE CHEAP TIER.** The owner's ruling of 27 September: a rater that\nfans out, or runs the screenshot bot, does it on the cheap tier. The judgement stays with the\nrater; what it hands off is retrieval and capture, and a helper that inherits the rater's deep\ntier pays for judgement nobody asked it for. So any agent a rater starts is started on the\ncheap tier, and screens are captured through the screenshot runner, which is cheap.\n\n**TWO THINGS IN THAT FILE'S FRONTMATTER ARE LOAD-BEARING and are not to be ignored.**\n\n- `tools: Read, Grep, Glob, Bash` — **no `Edit`, no `Write`.** The rater's most valuable\n  technique is breaking the code to see whether a test notices, and the tree under review is\n  the one place it may not do that in. Granted edit access, one of them left a shipped SQL\n  migration with a delete trigger's `kind` clause stripped, at the moment its caller's\n  commit hook was asking for a commit; the file's own section explains the rest.\n- Launch it **isolated** if your runtime can — `isolation: \"worktree\"` in Claude Code's\n  Agent tool — so it has a checkout of its own to mutate. It is told to make one anyway,\n  because it must not depend on having been launched correctly.\n\nAnd do not run anything heavy against the same tree while it works: its test runs and yours\ncompete, and a suite that fails because two things were building at once produces findings\nthat are not findings.\n\nIf your runtime has no subagents, do the pass inline against that same rubric, but say\nplainly in the report that the rating is self-assessed rather than independent.\n\n#### No more than five raters, and the commits grouped to fit\n\nThe owner's ruling: *\"Don't fan out more than 5 raters. Group commits if needed.\"* When the\nwork is more commits than five raters can each take one of, group them — by the area they\ntouch, or by the finding they answer — so that every rater is handed a body of work large\nenough to judge. Each rater gets the prompts behind its whole group, and scores each commit\nin it.\n\n**WHY A CAP, AND NOT ONE RATER PER COMMIT.** A rater must return a rating, and one handed a\ncommit with nothing wrong in it reports something anyway. The owner, stopping a fan-out of\ntwenty-two: *\"If you create such minute raters they will start hallucinating issues\nresulting in regressions.\"* It had been measured before it was ruled. In one consuming\nrepository, pushes rated one commit per rater came back with 40 to 75 findings a round and\nnever converged, and two commits made while answering those rounds were regressions that a\nlater round had to catch: a publish job that stopped running, and a pairing code that\noutlived a factory reset.\n\n**A RATING THAT FINISHED STILL STANDS WHEN THE FAN-OUT IS STOPPED.** Also the owner's:\n*\"You can act on whatever raters already rated. If they were more than 8, those commits are\nalready rated then.\"* Recover the finished results (a workflow's journal records what each\nagent returned) and act on them as on any other round. A commit whose finished rating\nalready clears the caller's bar is rated. Re-rate only the commits with no result, grouped\nas above.\n\n#### Documentation findings are reported, and scored only where a reader meets them\n\nThe owner's ruling: *\"Make the rater cut rating marks only for actual issues, documentation\nproblems are non rated issues (still should be reported) unless it is facing the user in the\napp or about a wrong claim in readme or wiki.\"* So every finding is one of two kinds, and the\nrater's prompt says which is which. That is part of how to score, not a target:\n\n- **Scored.** A behaviour defect. A test that cannot fail for the defect it names. A breach\n  of the repository's rules in code. A documentation problem a reader meets: text a user sees\n  in the app (labels, help, errors, sample content), or a wrong claim in the README or the\n  wiki.\n- **Reported, not scored.** Any other documentation problem: commit bodies, code comments,\n  internal notes such as plans, test headers and fixture notes, and wording slips in any of\n  them. Each is still listed, still fixed or answered in one line, and marked unscored. None\n  of them lowers the number.\n\n**ONE EXCEPTION STAYS SCORED: A FALSE ACCOUNT OF THE WORK.** A body or report claiming a test\nran, a mutation failed, or a thing was done, when it was not, is not a documentation slip. It\nis the dishonest report the score weighs most (see *What the score is measuring*).\n\n**WHY.** It was measured before it was ruled. One consuming repository's release took six\nrating passes. The last four scored commits below the bar almost entirely for their commit\nbodies: a misquote, a miscount, a file named wrong. History there is never rewritten, so each\ncorrection was a new body for the next pass to find fault with, and the loop ended only when\nthe owner stopped it.\n\n### Step 3 — act on it, then report\n\n1. **Fix what the rater found**, if it found something real, before you report anything. A\n   rating is a work item, not a verdict to be filed. CI re-runs the tests after the fix.\n2. **Report the score as given**, then the findings, then what you did about each. If you\n   disagree with a finding, say so in one line with the reason — do not silently drop it.\n3. **Re-rate only after fixing**, and only by handing the rater the new diff. Do not ask it\n   to reconsider the same work; that is asking for a better number rather than a better\n   answer.\n4. **Re-rate at all only when the pass found at least three major findings**, meaning scored\n   ones the rater marked high or medium. The owner's ruling: *\"if a rater didn't find at least 3\n   major issues, no need to rerun rater, regardless of rating.\"* Fewer than three: fix them all\n   and stop, whatever the score. The caller's own bar (a pass mark, say) can only ask for\n   fewer passes than this, never more.\n\n## What the score is measuring\n\nFidelity to the request, in this order of weight: every distinct thing asked for was done;\neach piece is complete (migration, second language, test, doc, every call site the rule\nreaches); it is correct; it fits the surrounding code; and the report of it is honest.\n\nThe last one carries the most weight in both directions. Claiming a suite passed without\nrunning it, describing stubbed work as finished, or narrowing the scope without saying so\nshould cost more than any implementation flaw.\n\n## Do not\n\n- Do not tell the rater the target. Not the pass mark, not a previous score, not that the\n  score has a consequence, and not that you would like it to go well. A rater that knows the\n  pass mark rates to the pass mark.\n- Do not summarise the prompts before handing them over. A paraphrase is where the request\n  quietly becomes the thing that was built.\n- Do not soften, re-weight, or round the number when reporting it.\n- Do not drop a finding you disagree with. Say so in one line, with the reason, and leave it\n  in the report.\n- Do not re-rate by asking the same rater to reconsider the same work. That is asking for a\n  better number rather than a better answer. Fix first, then hand it the new diff.\n- Do not let the agent that did the work rate it, unless the runtime has no subagents — and\n  then say in the report that the rating is self-assessed.\n- Do not fan out more than five raters, and do not hand a rater a commit too small to judge\n  on its own. Group the commits. A rater with nothing real to find invents something, and the\n  fix for an invented finding is how a regression gets in.\n- Do not throw away a finished rating because the run it was part of was stopped.\n- Do not let a rater's helpers inherit its tier. A fan-out or a screenshot run it starts is\n  on the cheap tier.\n- Do not let a documentation problem the reader never meets lower the score. Report it,\n  marked unscored. Only text in the app, or a wrong claim in the README or wiki, is scored,\n  and so is a false account of what was run or done.\n- Do not treat the score as the deliverable. It is a work item; the fixes are the deliverable.\n- Do not run this on a one-line fix, a question answered in prose, or a task the user is still\n  actively redirecting.\n\n## Verify\n\n- [ ] Every prompt the user sent this session reached the rater verbatim and in order,\n      including the ones that arrived mid-task.\n- [ ] The rater was given the diff and the real verification output — or told plainly that\n      none was run, which is itself something to be rated.\n- [ ] Nothing in the rater's prompt named a threshold, an expectation, a previous score, or a\n      consequence.\n- [ ] The rater was independent of the work, or the report says the rating is self-assessed.\n- [ ] No more than five raters ran, and each was given a group of commits large enough to\n      judge.\n- [ ] The rater was told which findings are scored and which are reported unscored, and the\n      report keeps the unscored ones.\n- [ ] A re-rating ran only after a pass with at least three major findings.\n- [ ] Every agent the rater started, and every screenshot run, was on the cheap tier.\n- [ ] The score is reported exactly as given, alongside its findings.\n- [ ] Every finding was either fixed or answered in one line with a reason; none was dropped.\n- [ ] Any re-rate was made against a new diff.\n\n---\n\n## Provenance\n\nCopied from [claude-kit](https:\u002F\u002Fgithub.com\u002Faaronified\u002Fclaude-kit) (MIT,\nCopyright (c) 2026 Aro) and vendored here so it travels with this checkout.\nPaths to the rater agent are rewritten for this repository's layout; the\nprocedure is otherwise unchanged. Fix it upstream as well as here.\n",{"name":5,"description":7},"main","e12d242d50df37cf53a73a8f192cf137a076f3a6",".claude\u002Fskills\u002Fwork-rating",0,"https:\u002F\u002Fgithub.com\u002Faaronified\u002Ffluenough","https:\u002F\u002Fgithub.com\u002Faaronified","2026-11-15 04:56:55",{"source":8,"skillName":5,"commands":32,"prompt":42,"zipAvailable":43},[33,36,39],{"tool":34,"command":35},"npx","npx skills add aaronified\u002Ffluenough --skill work-rating",{"tool":37,"command":38},"bunx","bunx skills add aaronified\u002Ffluenough --skill work-rating",{"tool":40,"command":41},"pnpm","pnpm dlx skills add aaronified\u002Ffluenough --skill work-rating","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Faaronified\u002Ffluenough\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fwork-rating\u002FSKILL.md",true,[],[46,53,60],{"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},"01M7D1DK9NZS2SG7QMJ22CPRA4","flutter-dart-code-review","Library-agnostic Flutter\u002FDart code review checklist covering widget best practices, state management patterns (BLoC, Riverpod, Provider, GetX, MobX, Signals), Dart idioms, performance, accessibility, security, and clean architecture. Use when reviewing Flutter or Dart code, whatever state management library the project uses.","https:\u002F\u002Fgithub.com\u002Faaronified\u002Ffluenough\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fflutter-dart-code-review\u002FSKILL.md",[],[],{"skillNo":54,"name":55,"nameZh":6,"description":56,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":57,"categories":58,"keywords":59,"publishedAt":19},"01M7D1DF9ZTJ5Z27EST2XV02T2","changelog","Use before adding or editing a CHANGELOG.md line in a pull request. Rules for what earns a line (only what a learner can see or feel), how to word it, and what never does (CI, workflows, tools, tests, refactors, deck content, docs). Docs-only commits and pushes need no line.","https:\u002F\u002Fgithub.com\u002Faaronified\u002Ffluenough\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fchangelog\u002FSKILL.md",[],[],{"skillNo":61,"name":62,"nameZh":6,"description":63,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":64,"categories":65,"keywords":66,"publishedAt":19},"01M7D1DB9THSSW6X1A72ZW0X82","build-deck","Use when building or extending a Fluenough deck, including writing the next planned unit of a language's B1 plan, a word unit or a grammar unit (a core in decks\u002F\u003Clang>\u002F plus its English layer in decks\u002F\u003Clang>\u002Fen\u002F). Not for app code.","https:\u002F\u002Fgithub.com\u002Faaronified\u002Ffluenough\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fbuild-deck\u002FSKILL.md",[],[]]