[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M7CS3EF6P956DAVQJPR8JKAE":3,"skill-same:01M7CS3EF6P956DAVQJPR8JKAE":48},{"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":25,"commitSha":26,"skillDirectory":27,"forksCount":28,"repositoryHtmlUrl":29,"repositoryHomepageUrl":30,"ownerHtmlUrl":31,"ownerBlogUrl":6,"ownerDescription":32,"updatedAt":33,"install":34,"resources":47},"01M7CS3EF6P956DAVQJPR8JKAE","performance-awareness",null,"How the performance score moves for your role. Use when the score context shows a declining trend, or before handing off work you have not self-checked against every criterion.","makifbaysal\u002Ftasktrooper","makifbaysal","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F25031940?v=4","01M7CRG3ZCSYZSSEVDMW3DEYC8","Mehmet Akif Baysal","01M7CRG401FJ8YAXH5ER730XYV",122,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fmakifbaysal\u002Ftasktrooper\u002Fblob\u002Fmain\u002Fcatalog\u002Fagents\u002Fgame-developer\u002Fskills\u002Fperformance-awareness\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: performance-awareness\ncategory: quality\ndescription: How the performance score moves for your role. Use when the score context shows a declining trend, or before handing off work you have not self-checked against every criterion.\n---\n# Performance Awareness\n\n## Overview\n\nEvery agent carries a performance score (0–100, starts at 100). It is not decoration: it reflects how much rework your output causes downstream, and your run context already injects it (`agent.score_context`) — this skill explains what moves it. A task that sails through its gates clean protects your score; one that bounces back at any gate costs you. The score rewards getting it right the first time.\n\n**Core principle:** The cheapest revision is the one that never happens. Every gate you pass clean is points kept; every bounce is points lost AND time lost.\n\n## How the score moves\n\n| Event | Delta | Who is charged |\n|-------|-------|-----------------|\n| Your task reaches **done** or **released** | +5 each | the assignee |\n| Revision requested from **code_review** | −10 | the `in_progress` owner |\n| Revision requested from **ready_for_qa** or **in_qa** | −10 | the `in_progress` owner |\n| **Human UAT** fails | −8 | the `in_progress` and `in_qa` owners |\n| A human overturns your approval at the same review gate (**review escape**) | −10 | the reviewer who approved it |\n| QA: a bug it caught | +6 | QA, per bug |\n| QA: a scenario it confirmed valid \u002F invalid | +1 \u002F −1 | QA, per scenario |\n| QA: finished testing a task | +5 | QA |\n\nThe asymmetry is deliberate: one revision (−10) wipes out two clean releases (+10), and a defect that escapes every earlier gate and fails Human UAT (−8) still costs real points.\n\n## The gates your work passes\n\n```\nin_progress → code_review → ready_for_qa → in_qa → human_uat → done → released\n              (architect)                  (QA)    (human)\n```\n\nA defect caught at code_review costs the developer −10. The SAME defect that slips to in_qa or human_uat still costs the developer and now also charges whoever owned the column it escaped through, plus the time of every role between. Catch your own defects before handoff — that is what the score is measuring.\n\n## To protect your score\n\n1. **Read ALL acceptance criteria before starting.** Most bounces are unmet AC, not bugs.\n2. **Self-check every AC against fresh, executed evidence** before moving the task forward or recording a verdict.\n3. **Never guess a product decision** — add_task_comment with numbered questions instead. A wrong guess becomes a UAT failure, and UAT failures charge more than one role.\n4. **On a revision, address EVERY point** and fix at the root, not the symptom. A partial fix bounces again for another −10.\n5. **Run the real checks in THIS run** before claiming anything passes or is complete.\n\n## Worked Example\n\nTwo developers each ship 5 tasks in a week.\n\n- Dev A rushes: 5 tasks to code_review fast, 3 bounce for unmet AC (−30), fixes them, all 5 eventually released (+50: +25 done, +25 released). Net for the week: **+20**, plus the architect reviewed 8 times.\n- Dev B self-checks every AC before handoff: 5 tasks, 0 bounces, all released (+50). Net: **+50**, architect reviewed 5 times.\n\nSame 5 tasks shipped. The difference is entirely self-verification before handoff.\n\n## Red Flags\n\n- Moving a task forward \"to see if it passes\" — the next gate is not your test suite.\n- Skipping an AC, or a scenario, because \"it's probably fine.\"\n- Leaving a revision point partially addressed.\n- Approving something you did not actually verify — a review escape costs as much as a bounced revision, and it is charged to you alone.\n","# Performance Awareness\n\n## Overview\n\nEvery agent carries a performance score (0–100, starts at 100). It is not decoration: it reflects how much rework your output causes downstream, and your run context already injects it (`agent.score_context`) — this skill explains what moves it. A task that sails through its gates clean protects your score; one that bounces back at any gate costs you. The score rewards getting it right the first time.\n\n**Core principle:** The cheapest revision is the one that never happens. Every gate you pass clean is points kept; every bounce is points lost AND time lost.\n\n## How the score moves\n\n| Event | Delta | Who is charged |\n|-------|-------|-----------------|\n| Your task reaches **done** or **released** | +5 each | the assignee |\n| Revision requested from **code_review** | −10 | the `in_progress` owner |\n| Revision requested from **ready_for_qa** or **in_qa** | −10 | the `in_progress` owner |\n| **Human UAT** fails | −8 | the `in_progress` and `in_qa` owners |\n| A human overturns your approval at the same review gate (**review escape**) | −10 | the reviewer who approved it |\n| QA: a bug it caught | +6 | QA, per bug |\n| QA: a scenario it confirmed valid \u002F invalid | +1 \u002F −1 | QA, per scenario |\n| QA: finished testing a task | +5 | QA |\n\nThe asymmetry is deliberate: one revision (−10) wipes out two clean releases (+10), and a defect that escapes every earlier gate and fails Human UAT (−8) still costs real points.\n\n## The gates your work passes\n\n```\nin_progress → code_review → ready_for_qa → in_qa → human_uat → done → released\n              (architect)                  (QA)    (human)\n```\n\nA defect caught at code_review costs the developer −10. The SAME defect that slips to in_qa or human_uat still costs the developer and now also charges whoever owned the column it escaped through, plus the time of every role between. Catch your own defects before handoff — that is what the score is measuring.\n\n## To protect your score\n\n1. **Read ALL acceptance criteria before starting.** Most bounces are unmet AC, not bugs.\n2. **Self-check every AC against fresh, executed evidence** before moving the task forward or recording a verdict.\n3. **Never guess a product decision** — add_task_comment with numbered questions instead. A wrong guess becomes a UAT failure, and UAT failures charge more than one role.\n4. **On a revision, address EVERY point** and fix at the root, not the symptom. A partial fix bounces again for another −10.\n5. **Run the real checks in THIS run** before claiming anything passes or is complete.\n\n## Worked Example\n\nTwo developers each ship 5 tasks in a week.\n\n- Dev A rushes: 5 tasks to code_review fast, 3 bounce for unmet AC (−30), fixes them, all 5 eventually released (+50: +25 done, +25 released). Net for the week: **+20**, plus the architect reviewed 8 times.\n- Dev B self-checks every AC before handoff: 5 tasks, 0 bounces, all released (+50). Net: **+50**, architect reviewed 5 times.\n\nSame 5 tasks shipped. The difference is entirely self-verification before handoff.\n\n## Red Flags\n\n- Moving a task forward \"to see if it passes\" — the next gate is not your test suite.\n- Skipping an AC, or a scenario, because \"it's probably fine.\"\n- Leaving a revision point partially addressed.\n- Approving something you did not actually verify — a review escape costs as much as a bounced revision, and it is charged to you alone.\n",{"name":5,"category":24,"description":7},"quality","main","910394a0b6db9fc8c9a8f36328ec421d3ebd8b38","catalog\u002Fagents\u002Fgame-developer\u002Fskills\u002Fperformance-awareness",18,"https:\u002F\u002Fgithub.com\u002Fmakifbaysal\u002Ftasktrooper","https:\u002F\u002Ftasktrooper.ai","https:\u002F\u002Fgithub.com\u002Fmakifbaysal","Senior Software Developer","2026-11-15 04:50:29",{"source":8,"skillName":5,"commands":35,"prompt":45,"zipAvailable":46},[36,39,42],{"tool":37,"command":38},"npx","npx skills add makifbaysal\u002Ftasktrooper --skill performance-awareness",{"tool":40,"command":41},"bunx","bunx skills add makifbaysal\u002Ftasktrooper --skill performance-awareness",{"tool":43,"command":44},"pnpm","pnpm dlx skills add makifbaysal\u002Ftasktrooper --skill performance-awareness","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmakifbaysal\u002Ftasktrooper\u002Fblob\u002Fmain\u002Fcatalog\u002Fagents\u002Fgame-developer\u002Fskills\u002Fperformance-awareness\u002FSKILL.md",true,[],[49,55,62,69,74,81],{"skillNo":50,"name":51,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":52,"categories":53,"keywords":54,"publishedAt":19},"01M7CSVEPQW6J6TD6CS2T5FPNZ","visual-craft","https:\u002F\u002Fgithub.com\u002Fmakifbaysal\u002Ftasktrooper\u002Fblob\u002Fmain\u002Fcatalog\u002Fagents\u002Fui-designer\u002Fskills\u002Fvisual-craft\u002FSKILL.md",[],[],{"skillNo":56,"name":57,"nameZh":6,"description":58,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":59,"categories":60,"keywords":61,"publishedAt":19},"01M7CSVAQG91ETHQ0HBNZDG5FR","ux-copy","Use when you write any words a user reads in a mockup or a hand-off - content language and voice, buttons, labels, errors, empty states, confirmations, numbers and dates, and the longest-string check","https:\u002F\u002Fgithub.com\u002Fmakifbaysal\u002Ftasktrooper\u002Fblob\u002Fmain\u002Fcatalog\u002Fagents\u002Fui-designer\u002Fskills\u002Fux-copy\u002FSKILL.md",[],[],{"skillNo":63,"name":64,"nameZh":6,"description":65,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":66,"categories":67,"keywords":68,"publishedAt":19},"01M7CSV6H0J38659NDXHJQ8396","screen-mockup-html","Use when you draw screens as the design task's HTML mockup - ONE canvas document holding every screen and every variant side by side, the sanitizer-safe recipe, phone and wide frames, the states grid, static control states, and the loopback self-check with screenshots at 375, 768 and 1440 attached to the task","https:\u002F\u002Fgithub.com\u002Fmakifbaysal\u002Ftasktrooper\u002Fblob\u002Fmain\u002Fcatalog\u002Fagents\u002Fui-designer\u002Fskills\u002Fscreen-mockup-html\u002FSKILL.md",[],[],{"skillNo":70,"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":71,"categories":72,"keywords":73,"publishedAt":19},"01M7CSV3JFRF3BM3XK52M7YEYR","https:\u002F\u002Fgithub.com\u002Fmakifbaysal\u002Ftasktrooper\u002Fblob\u002Fmain\u002Fcatalog\u002Fagents\u002Fui-designer\u002Fskills\u002Fperformance-awareness\u002FSKILL.md",[],[],{"skillNo":75,"name":76,"nameZh":6,"description":77,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":78,"categories":79,"keywords":80,"publishedAt":19},"01M7CSTZDH00YRF5SCT7BRT9QD","design-variants","Use when a screen design needs variants - how many, variants as side-by-side rows on the one canvas, what makes two variants genuinely different, recommending one, how the human's choice is read, and narrowing to the chosen one in revision","https:\u002F\u002Fgithub.com\u002Fmakifbaysal\u002Ftasktrooper\u002Fblob\u002Fmain\u002Fcatalog\u002Fagents\u002Fui-designer\u002Fskills\u002Fdesign-variants\u002FSKILL.md",[],[],{"skillNo":82,"name":83,"nameZh":6,"description":84,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":85,"categories":86,"keywords":87,"publishedAt":19},"01M7CSTV6P3SM3PAE28DB0RF77","design-system-authoring","Use when you derive, change or extend a design system - where tokens live per stack, the DTCG token tree, role-based names for both themes, base vs layer vs drift, the DESIGN.md section order, the inventory format, the contrast check and the lint every proposal returns","https:\u002F\u002Fgithub.com\u002Fmakifbaysal\u002Ftasktrooper\u002Fblob\u002Fmain\u002Fcatalog\u002Fagents\u002Fui-designer\u002Fskills\u002Fdesign-system-authoring\u002FSKILL.md",[],[]]