[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71SF3Z5FDQ7431FVEFMKYH4":3,"skill-same:01M71SF3Z5FDQ7431FVEFMKYH4":66},{"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":6,"ownerDescription":50,"updatedAt":51,"install":52,"resources":65},"01M71SF3Z5FDQ7431FVEFMKYH4","communicating-with-users",null,"Use when writing anything the user will read, such as plans, questions, progress updates, final reports, PR descriptions, and commit messages. Keeps them short, specific, and easy to act on.","Praneeth-Suresh\u002FBeryl","Praneeth-Suresh","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F86470588?v=4","01M71SF2BCZ4JMKKYZR66WNHAF","Praneeth Suresh","01M71SF2C5JMS7B9676HSA2SG6",11,"Apache-2.0","https:\u002F\u002Fgithub.com\u002FPraneeth-Suresh\u002FBeryl\u002Fblob\u002Fmain\u002F.beryl\u002Fagent\u002Fskills\u002Fcommunicating-with-users\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"users","with","communicating","communicating with users","updates","when","commit messages","use","writing","act","plans","easy","short","messages","read","questions","pr","progress","as","reports","2026-11-10 13:02:02",false,"---\nname: communicating-with-users\ndescription: Use when writing anything the user will read, such as plans, questions, progress updates, final reports, PR descriptions, and commit messages. Keeps them short, specific, and easy to act on.\n---\n\n# Communicating With Users\n\n## Purpose\n\nMake the reader's job easy. The user should understand the state of the work,\nand what you need from them, in one read.\n\n## Rules\n\n1. Lead with the answer or the outcome. Put background after it, or leave it\n   out.\n2. Match length to the question. If one sentence answers it, write one\n   sentence.\n3. Be specific. Name the file, the command, the number, and the error. Write\n   \"`tests\u002Ffoo.sh` fails: missing `bar`\" instead of \"some tests have issues\".\n4. Use the user's terms and keep one name per concept. Define a term before\n   you use it.\n5. Write complete sentences with clear subjects. Short is good. Cryptic is not.\n6. Separate facts from guesses. Say what you ran and saw, and label anything\n   you assumed or did not check.\n7. Report failures and skipped checks plainly, in the same place as successes.\n   Do not bury them.\n8. Leave out filler: no preamble, no restating the request, no closing summary\n   of what you just said, no \"Great question\", and no praise for your own\n   work.\n9. Do not inflate. Describe the change at its real size. Avoid words such as\n   \"robust\", \"comprehensive\", \"seamless\", and \"significantly\" unless you can\n   back them with a number.\n\n## Asking Questions\n\n- Ask only what you cannot find out yourself from the repository or tools.\n- Put each question where the user can answer it quickly: numbered, with the\n  options and your recommendation.\n- Say what you will do by default if the user does not answer, when a default\n  is safe.\n\n## Progress Updates\n\nDuring long work, an update states what finished, what is in progress, and any\nblocker. Do not narrate each step.\n\n## Final Reports\n\nA final report states:\n\n- what changed, grouped by purpose;\n- which checks ran and their results;\n- which checks were skipped, and why;\n- anything the user must decide or do next.\n\nUse a short table or list when items are parallel. Use prose for reasoning.\nDo not put a heading on a three-line answer.\n\n## Diagrams\n\nWhen a structure, flow, or comparison is easier to see than to read, load\n`creating-illustrations`.\n","# Communicating With Users\n\n## Purpose\n\nMake the reader's job easy. The user should understand the state of the work,\nand what you need from them, in one read.\n\n## Rules\n\n1. Lead with the answer or the outcome. Put background after it, or leave it\n   out.\n2. Match length to the question. If one sentence answers it, write one\n   sentence.\n3. Be specific. Name the file, the command, the number, and the error. Write\n   \"`tests\u002Ffoo.sh` fails: missing `bar`\" instead of \"some tests have issues\".\n4. Use the user's terms and keep one name per concept. Define a term before\n   you use it.\n5. Write complete sentences with clear subjects. Short is good. Cryptic is not.\n6. Separate facts from guesses. Say what you ran and saw, and label anything\n   you assumed or did not check.\n7. Report failures and skipped checks plainly, in the same place as successes.\n   Do not bury them.\n8. Leave out filler: no preamble, no restating the request, no closing summary\n   of what you just said, no \"Great question\", and no praise for your own\n   work.\n9. Do not inflate. Describe the change at its real size. Avoid words such as\n   \"robust\", \"comprehensive\", \"seamless\", and \"significantly\" unless you can\n   back them with a number.\n\n## Asking Questions\n\n- Ask only what you cannot find out yourself from the repository or tools.\n- Put each question where the user can answer it quickly: numbered, with the\n  options and your recommendation.\n- Say what you will do by default if the user does not answer, when a default\n  is safe.\n\n## Progress Updates\n\nDuring long work, an update states what finished, what is in progress, and any\nblocker. Do not narrate each step.\n\n## Final Reports\n\nA final report states:\n\n- what changed, grouped by purpose;\n- which checks ran and their results;\n- which checks were skipped, and why;\n- anything the user must decide or do next.\n\nUse a short table or list when items are parallel. Use prose for reasoning.\nDo not put a heading on a three-line answer.\n\n## Diagrams\n\nWhen a structure, flow, or comparison is easier to see than to read, load\n`creating-illustrations`.\n",{"name":5,"description":7},"main","3a5bd7e327cbdad81a70b624ec3fc6e43ec91f12",".beryl\u002Fagent\u002Fskills\u002Fcommunicating-with-users",0,"https:\u002F\u002Fgithub.com\u002FPraneeth-Suresh\u002FBeryl","https:\u002F\u002Fgithub.com\u002FPraneeth-Suresh","Just built it.","2026-11-09 18:59:34",{"source":8,"skillName":5,"commands":53,"prompt":63,"zipAvailable":64},[54,57,60],{"tool":55,"command":56},"npx","npx skills add Praneeth-Suresh\u002FBeryl --skill communicating-with-users",{"tool":58,"command":59},"bunx","bunx skills add Praneeth-Suresh\u002FBeryl --skill communicating-with-users",{"tool":61,"command":62},"pnpm","pnpm dlx skills add Praneeth-Suresh\u002FBeryl --skill communicating-with-users","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FPraneeth-Suresh\u002FBeryl\u002Fblob\u002Fmain\u002F.beryl\u002Fagent\u002Fskills\u002Fcommunicating-with-users\u002FSKILL.md",true,[],[67,90,97,130,154,169],{"skillNo":68,"name":69,"nameZh":6,"description":70,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":71,"licenseFileUrl":72,"sourceHtmlUrl":73,"categories":74,"keywords":75,"publishedAt":39},"01M71SGEFHAT82F5TQH73XY6H8","verification-before-completion","Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always","MIT","https:\u002F\u002Fgithub.com\u002FPraneeth-Suresh\u002FBeryl\u002Fblob\u002Fmain\u002F.beryl\u002Fagent\u002Fskills\u002Fverification-before-completion\u002FLICENSE","https:\u002F\u002Fgithub.com\u002FPraneeth-Suresh\u002FBeryl\u002Fblob\u002Fmain\u002F.beryl\u002Fagent\u002Fskills\u002Fverification-before-completion\u002FSKILL.md",[],[76,77,78,79,80,81,82,83,84,24,85,26,86,87,88,89],"verification","verification before completion","committing","commands","about","work","claims","output","evidence","assertions","claim","prs","complete","running",{"skillNo":91,"name":92,"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":93,"categories":94,"keywords":95,"publishedAt":39},"01M71SGD1DV15B9Z2S5V3M8YPH","using-beryl","https:\u002F\u002Fgithub.com\u002FPraneeth-Suresh\u002FBeryl\u002Fblob\u002Fmain\u002F.beryl\u002Fagent\u002Fskills\u002Fusing-beryl\u002FSKILL.md",[],[96],"using beryl",{"skillNo":98,"name":99,"nameZh":6,"description":100,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":101,"categories":102,"keywords":111,"publishedAt":39},"01M71SGAJ7D211GQR4703TTZCW","understand-codebase","Teach a developer how a repository, subsystem, execution path, migration, diff, commit, branch, or pull request works. Use when the user asks to understand, explain, map, walk through, explore, or quiz themselves on code, or asks for an interactive HTML understanding artifact.","https:\u002F\u002Fgithub.com\u002FPraneeth-Suresh\u002FBeryl\u002Fblob\u002Fmain\u002F.beryl\u002Fagent\u002Fskills\u002Funderstand-codebase\u002FSKILL.md",[103,108],{"categoryNo":104,"categoryName":105,"taxonomyType":106,"taxonomyTypeDesc":107},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",{"categoryNo":109,"categoryName":110,"taxonomyType":106,"taxonomyTypeDesc":107},"01JBSEEDCAT000000000000039","教师与教育",[112,113,114,115,116,117,118,119,120,121,26,24,122,123,124,125,126,127,128,129],"understand","codebase","understand codebase","branch","diff","for","explore","execution","quiz","map","code","commit","interactive","explain","artifact","how","pull request","pull",{"skillNo":131,"name":132,"nameZh":6,"description":133,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":71,"licenseFileUrl":134,"sourceHtmlUrl":135,"categories":136,"keywords":145,"publishedAt":39},"01M71SG8H7CZGRND4C2BS49RV2","test-driven-development","Use when implementing any feature or bugfix, before writing implementation code","https:\u002F\u002Fgithub.com\u002FPraneeth-Suresh\u002FBeryl\u002Fblob\u002Fmain\u002F.beryl\u002Fagent\u002Fskills\u002Ftest-driven-development\u002FLICENSE","https:\u002F\u002Fgithub.com\u002FPraneeth-Suresh\u002FBeryl\u002Fblob\u002Fmain\u002F.beryl\u002Fagent\u002Fskills\u002Ftest-driven-development\u002FSKILL.md",[137,142],{"categoryNo":138,"categoryName":139,"taxonomyType":140,"taxonomyTypeDesc":141},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":143,"categoryName":144,"taxonomyType":140,"taxonomyTypeDesc":141},"01JBSEEDCAT000000000000018","写作与文案",[146,147,148,149,150,151,27,26,24,122,152,153],"driven","test","test driven development","development","feature","implementing","bugfix","implementation",{"skillNo":155,"name":156,"nameZh":6,"description":157,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":71,"licenseFileUrl":158,"sourceHtmlUrl":159,"categories":160,"keywords":162,"publishedAt":39},"01M71SG4N855A3ASYXWFX45DH5","systematic-debugging","Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes","https:\u002F\u002Fgithub.com\u002FPraneeth-Suresh\u002FBeryl\u002Fblob\u002Fmain\u002F.beryl\u002Fagent\u002Fskills\u002Fsystematic-debugging\u002FLICENSE","https:\u002F\u002Fgithub.com\u002FPraneeth-Suresh\u002FBeryl\u002Fblob\u002Fmain\u002F.beryl\u002Fagent\u002Fskills\u002Fsystematic-debugging\u002FSKILL.md",[161],{"categoryNo":138,"categoryName":139,"taxonomyType":140,"taxonomyTypeDesc":141},[163,164,165,166,26,24,147,167,168],"systematic","debugging","systematic debugging","fixes","behavior","bug",{"skillNo":170,"name":171,"nameZh":6,"description":172,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":173,"categories":174,"keywords":176,"publishedAt":39},"01M71SG18JMNV8ED6XQ97Z48X0","simplifying-code","Use when code in a specific module or area is hard to understand or change, when the user asks to simplify, refactor, clean up, or improve the design or architecture of some code, or when a maintenance program hands over a refactor slice. Finds unmanaged complexity from evidence and removes it with small, behavior-preserving changes.","https:\u002F\u002Fgithub.com\u002FPraneeth-Suresh\u002FBeryl\u002Fblob\u002Fmain\u002F.beryl\u002Fagent\u002Fskills\u002Fsimplifying-code\u002FSKILL.md",[175],{"categoryNo":104,"categoryName":105,"taxonomyType":106,"taxonomyTypeDesc":107},[177,122,178,179,20,180,181,182,24,26,183,184,185,186,187,188,84,189,190,191],"simplifying code","design","change","architecture","program","simplify","module","changes","improve","clean","up","slice","complexity","behavior-preserving","maintenance"]