[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71SFYCTTCDRHPPVXBPPB7DR":3,"skill-same:01M71SFYCTTCDRHPPVXBPPB7DR":77},{"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":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":49,"commitSha":50,"skillDirectory":51,"forksCount":52,"repositoryHtmlUrl":53,"repositoryHomepageUrl":6,"ownerHtmlUrl":54,"ownerBlogUrl":6,"ownerDescription":55,"updatedAt":56,"install":57,"resources":70},"01M71SFYCTTCDRHPPVXBPPB7DR","refreshing-context",null,"Use when the user asks to refresh, review, audit, or clean up the agent context files, periodically (for example monthly), or after a large change to the repository such as a restructure, migration, or major feature. Checks the context layer against the code, quizzes the developer to confirm what is still true, and removes or fixes redundant and misleading context with approval.","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\u002Frefreshing-context\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"context","refreshing context","repository","audit","change","refresh","with","review","code","when","use","files","true","clean","up","example","for","fixes","feature","as","2026-11-10 13:02:02",false,"---\nname: refreshing-context\ndescription: Use when the user asks to refresh, review, audit, or clean up the agent context files, periodically (for example monthly), or after a large change to the repository such as a restructure, migration, or major feature. Checks the context layer against the code, quizzes the developer to confirm what is still true, and removes or fixes redundant and misleading context with approval.\n---\n\n# Refreshing Context\n\n## Purpose\n\nKeep the context layer in `.beryl\u002Fagent\u002F` true, short, and useful. Agents\ntrust these files, so a stale or misleading line costs more than a missing\none. This skill finds drift between the context and the code, checks it with\nthe developer, and removes or fixes what is wrong.\n\nThe context layer is the project-owned files in `.beryl\u002Fagent\u002F`:\n\n- `project-brief.md`\n- `architecture.md` (boundaries, design concept, open decisions, decision record, pressure points)\n- `ubiquitous-language.md`\n- `testing-policy.md`\n- the same files in module `agent\u002F` directories, when the repository has them\n\nOther files in `.beryl\u002Fagent\u002F`, such as `agent-rules.md`, `task-routing.md`,\n`security-policy.md`, and the skills, are managed by Beryl and replaced on\nupdate. Report problems in them to the user instead of editing them, except in\nthe Beryl source repository itself.\n\n## When To Run\n\n- The user asks to refresh, review, or clean up context.\n- On a regular cadence, such as monthly.\n- After a large change: a restructure, a migration, a renamed domain concept,\n  a new or removed bounded context, or a big feature.\n- When an agent finds that a context file contradicts the code.\n\n## 1. Gather Evidence\n\nDo this before asking the developer anything. Do not edit files in this step.\n\n1. Run `.\u002F.beryl\u002Fagent\u002Fskills\u002Frefreshing-context\u002Fscripts\u002Fcontext-drift.sh`.\n   It reports paths named in context files that no longer exist, how much code\n   changed since each context file was last updated, and top-level directories\n   that no context file mentions. Treat its output as leads, not verdicts.\n2. Read each context file. For each claim that can be checked, check it\n   against the code: do the named modules, entry points, commands, and adapters\n   exist and work as described? Do the glossary terms appear in the code, and\n   does the code use other names for the same concepts?\n3. Look at what changed since the context was last updated:\n   `git log --since=\u003Cdate> --stat`. Note new areas, removed areas, and renames.\n4. Sort every finding into one of these:\n\n| Kind | Meaning | Default action |\n| --- | --- | --- |\n| Broken | Names a file, command, or module that does not exist. | Fix or remove. |\n| Contradicted | The code does something different from what the file says. | Ask which is right. |\n| Redundant | Says the same thing as another file, or repeats what the code or tooling already enforces. | Remove the copy. |\n| Generic | Advice that applies to any project and teaches a capable model nothing. | Remove. |\n| Missing | An important area, boundary, or term with no context. | Ask whether to add it. |\n| Unverifiable | A claim the code cannot confirm, such as intent or priorities. | Ask. |\n\n## 2. Quiz The Developer\n\nTurn the findings that need human judgement into a short quiz. The quiz checks\nthat the context matches what the developer believes, and it surfaces\nknowledge that is only in their head. Keep it light and quick to answer.\n\n- Ask in rounds of up to five questions. Number them so the developer can\n  answer in one line, such as \"1 true, 2 b, 3 skip\".\n- Mix question types:\n  - **True or false:** quote a line from a context file and ask if it is still true.\n  - **Which is right:** show what the file says and what the code does, and ask which one should win.\n  - **Spot the stale line:** show three short claims and ask which one is out of date.\n  - **Name it:** show a code concept that has no glossary entry and ask what the team calls it.\n  - **Still a rule?:** quote a rule and ask whether it still earns its place.\n- Give your recommended answer under each question, based on the evidence, so\n  the developer can accept it with \"yes\".\n- Say where each question comes from (file and line, and the code evidence).\n- After each round, give a one-line score of how many lines were confirmed,\n  fixed, or removed, and say how many questions are left. Stop when the user\n  asks, or after three rounds, and offer to continue another time.\n- If an answer contradicts the code, say so and ask whether the code or the\n  context is wrong. A wrong code finding is a bug or a plan, not a context edit.\n\nDo not ask about facts you can check yourself.\n\n## 3. Propose The Edits\n\nList every change before making it, grouped by file:\n\n- what to delete, and why;\n- what to rewrite, with the new text;\n- what to add, with the new text;\n- what to move, such as a decision from prose into one line in the Decision Record.\n\nPrefer deleting over rewording. Context should be the shortest text that stops\nan agent from making a mistake. Keep one source for each fact; where two files\noverlap, keep the line in the file that owns it and delete the other.\n\nFollow the deletion safeguard in `agent-rules.md`: list what is removed and\nwhere any replacement lives, then wait for explicit approval.\n\n## 4. Apply And Verify\n\nAfter approval:\n\n1. Make the edits.\n2. If `tool-instruction-template.md` changed, run\n   `.\u002F.beryl\u002Fagent\u002Fscripts\u002Fsync-agent-env.sh`.\n3. Run the context drift script again and confirm the broken entries are gone.\n4. Run `.\u002F.beryl\u002Fagent\u002Fscripts\u002Fagent-doctor.sh` and `.\u002F.beryl\u002Fscripts\u002Fcheck.sh`\n   (`--development` in the Beryl source checkout).\n\n## Rules\n\n- Never change code to match the context in this workflow. Report the\n  mismatch and route it to `planning` or `systematic-debugging`.\n- Do not edit vendored skills listed in `.beryl\u002Fagent\u002Fskills\u002FVENDORED.md`.\n- Do not add progress notes or a log of this refresh to the context files.\n  The commit message records what changed.\n- Keep the developer's answers as the source of truth for intent. Keep the\n  code as the source of truth for behavior.\n\n## Output\n\nFollow `communicating-with-users`. Report the quiz results, the edits made per\nfile, lines removed and added, the checks run, and any mismatch that needs a\ncode change.\n","# Refreshing Context\n\n## Purpose\n\nKeep the context layer in `.beryl\u002Fagent\u002F` true, short, and useful. Agents\ntrust these files, so a stale or misleading line costs more than a missing\none. This skill finds drift between the context and the code, checks it with\nthe developer, and removes or fixes what is wrong.\n\nThe context layer is the project-owned files in `.beryl\u002Fagent\u002F`:\n\n- `project-brief.md`\n- `architecture.md` (boundaries, design concept, open decisions, decision record, pressure points)\n- `ubiquitous-language.md`\n- `testing-policy.md`\n- the same files in module `agent\u002F` directories, when the repository has them\n\nOther files in `.beryl\u002Fagent\u002F`, such as `agent-rules.md`, `task-routing.md`,\n`security-policy.md`, and the skills, are managed by Beryl and replaced on\nupdate. Report problems in them to the user instead of editing them, except in\nthe Beryl source repository itself.\n\n## When To Run\n\n- The user asks to refresh, review, or clean up context.\n- On a regular cadence, such as monthly.\n- After a large change: a restructure, a migration, a renamed domain concept,\n  a new or removed bounded context, or a big feature.\n- When an agent finds that a context file contradicts the code.\n\n## 1. Gather Evidence\n\nDo this before asking the developer anything. Do not edit files in this step.\n\n1. Run `.\u002F.beryl\u002Fagent\u002Fskills\u002Frefreshing-context\u002Fscripts\u002Fcontext-drift.sh`.\n   It reports paths named in context files that no longer exist, how much code\n   changed since each context file was last updated, and top-level directories\n   that no context file mentions. Treat its output as leads, not verdicts.\n2. Read each context file. For each claim that can be checked, check it\n   against the code: do the named modules, entry points, commands, and adapters\n   exist and work as described? Do the glossary terms appear in the code, and\n   does the code use other names for the same concepts?\n3. Look at what changed since the context was last updated:\n   `git log --since=\u003Cdate> --stat`. Note new areas, removed areas, and renames.\n4. Sort every finding into one of these:\n\n| Kind | Meaning | Default action |\n| --- | --- | --- |\n| Broken | Names a file, command, or module that does not exist. | Fix or remove. |\n| Contradicted | The code does something different from what the file says. | Ask which is right. |\n| Redundant | Says the same thing as another file, or repeats what the code or tooling already enforces. | Remove the copy. |\n| Generic | Advice that applies to any project and teaches a capable model nothing. | Remove. |\n| Missing | An important area, boundary, or term with no context. | Ask whether to add it. |\n| Unverifiable | A claim the code cannot confirm, such as intent or priorities. | Ask. |\n\n## 2. Quiz The Developer\n\nTurn the findings that need human judgement into a short quiz. The quiz checks\nthat the context matches what the developer believes, and it surfaces\nknowledge that is only in their head. Keep it light and quick to answer.\n\n- Ask in rounds of up to five questions. Number them so the developer can\n  answer in one line, such as \"1 true, 2 b, 3 skip\".\n- Mix question types:\n  - **True or false:** quote a line from a context file and ask if it is still true.\n  - **Which is right:** show what the file says and what the code does, and ask which one should win.\n  - **Spot the stale line:** show three short claims and ask which one is out of date.\n  - **Name it:** show a code concept that has no glossary entry and ask what the team calls it.\n  - **Still a rule?:** quote a rule and ask whether it still earns its place.\n- Give your recommended answer under each question, based on the evidence, so\n  the developer can accept it with \"yes\".\n- Say where each question comes from (file and line, and the code evidence).\n- After each round, give a one-line score of how many lines were confirmed,\n  fixed, or removed, and say how many questions are left. Stop when the user\n  asks, or after three rounds, and offer to continue another time.\n- If an answer contradicts the code, say so and ask whether the code or the\n  context is wrong. A wrong code finding is a bug or a plan, not a context edit.\n\nDo not ask about facts you can check yourself.\n\n## 3. Propose The Edits\n\nList every change before making it, grouped by file:\n\n- what to delete, and why;\n- what to rewrite, with the new text;\n- what to add, with the new text;\n- what to move, such as a decision from prose into one line in the Decision Record.\n\nPrefer deleting over rewording. Context should be the shortest text that stops\nan agent from making a mistake. Keep one source for each fact; where two files\noverlap, keep the line in the file that owns it and delete the other.\n\nFollow the deletion safeguard in `agent-rules.md`: list what is removed and\nwhere any replacement lives, then wait for explicit approval.\n\n## 4. Apply And Verify\n\nAfter approval:\n\n1. Make the edits.\n2. If `tool-instruction-template.md` changed, run\n   `.\u002F.beryl\u002Fagent\u002Fscripts\u002Fsync-agent-env.sh`.\n3. Run the context drift script again and confirm the broken entries are gone.\n4. Run `.\u002F.beryl\u002Fagent\u002Fscripts\u002Fagent-doctor.sh` and `.\u002F.beryl\u002Fscripts\u002Fcheck.sh`\n   (`--development` in the Beryl source checkout).\n\n## Rules\n\n- Never change code to match the context in this workflow. Report the\n  mismatch and route it to `planning` or `systematic-debugging`.\n- Do not edit vendored skills listed in `.beryl\u002Fagent\u002Fskills\u002FVENDORED.md`.\n- Do not add progress notes or a log of this refresh to the context files.\n  The commit message records what changed.\n- Keep the developer's answers as the source of truth for intent. Keep the\n  code as the source of truth for behavior.\n\n## Output\n\nFollow `communicating-with-users`. Report the quiz results, the edits made per\nfile, lines removed and added, the checks run, and any mismatch that needs a\ncode change.\n",{"name":5,"description":7},"main","3a5bd7e327cbdad81a70b624ec3fc6e43ec91f12",".beryl\u002Fagent\u002Fskills\u002Frefreshing-context",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":58,"prompt":68,"zipAvailable":69},[59,62,65],{"tool":60,"command":61},"npx","npx skills add Praneeth-Suresh\u002FBeryl --skill refreshing-context",{"tool":63,"command":64},"bunx","bunx skills add Praneeth-Suresh\u002FBeryl --skill refreshing-context",{"tool":66,"command":67},"pnpm","pnpm dlx skills add Praneeth-Suresh\u002FBeryl --skill refreshing-context","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FPraneeth-Suresh\u002FBeryl\u002Fblob\u002Fmain\u002F.beryl\u002Fagent\u002Fskills\u002Frefreshing-context\u002FSKILL.md",true,[71],{"path":72,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":75,"sourceHtmlUrl":76},"scripts\u002Fcontext-drift.sh","SCRIPT","脚本",4187,"https:\u002F\u002Fgithub.com\u002FPraneeth-Suresh\u002FBeryl\u002Fblob\u002Fmain\u002F.beryl\u002Fagent\u002Fskills\u002Frefreshing-context\u002Fscripts\u002Fcontext-drift.sh",[78,101,108,135,159,173],{"skillNo":79,"name":80,"nameZh":6,"description":81,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":82,"licenseFileUrl":83,"sourceHtmlUrl":84,"categories":85,"keywords":86,"publishedAt":44},"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",[],[87,88,89,90,91,92,93,94,95,33,96,34,97,98,99,100],"verification","verification before completion","committing","commands","about","work","claims","output","evidence","assertions","claim","prs","complete","running",{"skillNo":102,"name":103,"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":104,"categories":105,"keywords":106,"publishedAt":44},"01M71SGD1DV15B9Z2S5V3M8YPH","using-beryl","https:\u002F\u002Fgithub.com\u002FPraneeth-Suresh\u002FBeryl\u002Fblob\u002Fmain\u002F.beryl\u002Fagent\u002Fskills\u002Fusing-beryl\u002FSKILL.md",[],[107],"using beryl",{"skillNo":109,"name":110,"nameZh":6,"description":111,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":112,"categories":113,"keywords":118,"publishedAt":44},"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",[114,115],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":116,"categoryName":117,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000039","教师与教育",[119,120,121,122,123,40,124,125,126,127,34,33,32,128,129,130,131,132,133,134],"understand","codebase","understand codebase","branch","diff","explore","execution","quiz","map","commit","interactive","explain","artifact","how","pull request","pull",{"skillNo":136,"name":137,"nameZh":6,"description":138,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":82,"licenseFileUrl":139,"sourceHtmlUrl":140,"categories":141,"keywords":150,"publishedAt":44},"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",[142,147],{"categoryNo":143,"categoryName":144,"taxonomyType":145,"taxonomyTypeDesc":146},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":148,"categoryName":149,"taxonomyType":145,"taxonomyTypeDesc":146},"01JBSEEDCAT000000000000018","写作与文案",[151,152,153,154,42,155,156,34,33,32,157,158],"driven","test","test driven development","development","implementing","writing","bugfix","implementation",{"skillNo":160,"name":161,"nameZh":6,"description":162,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":82,"licenseFileUrl":163,"sourceHtmlUrl":164,"categories":165,"keywords":167,"publishedAt":44},"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",[166],{"categoryNo":143,"categoryName":144,"taxonomyType":145,"taxonomyTypeDesc":146},[168,169,170,41,34,33,152,171,172],"systematic","debugging","systematic debugging","behavior","bug",{"skillNo":174,"name":175,"nameZh":6,"description":176,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":177,"categories":178,"keywords":180,"publishedAt":44},"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",[179],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[181,32,182,28,30,183,184,185,33,34,186,187,188,37,38,189,95,190,191,192],"simplifying code","design","architecture","program","simplify","module","changes","improve","slice","complexity","behavior-preserving","maintenance"]