[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71SFQKCKQ0AQEWHYXV72PRC":3,"skill-same:01M71SFQKCKQ0AQEWHYXV72PRC":46},{"skillNo":4,"name":5,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":20,"linkOnly":21,"markdownContent":22,"markdownBody":22,"frontMatter":23,"refName":24,"commitSha":25,"skillDirectory":26,"forksCount":27,"repositoryHtmlUrl":28,"repositoryHomepageUrl":6,"ownerHtmlUrl":29,"ownerBlogUrl":6,"ownerDescription":30,"updatedAt":31,"install":32,"resources":45},"01M71SFQKCKQ0AQEWHYXV72PRC","initial-build",null,"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\u002Finitial-build\u002FSKILL.md",[],[18,19],"build","initial build","2026-11-10 13:02:02",false,"# Initial Build\n\n## Purpose\n\nGuide the first coordinated implementation of a large or greenfield application\nin a repository where Beryl is installed. Clarification questions are part of\nthe workflow and precede approval of a dependency-ordered build that can resume\nacross agent sessions. It is an instruction contract, not a model-, vendor-,\nCLI-, or tool-specific implementation.\n\n## Use When\n\nUse this workflow only when the user explicitly asks to build a large\napplication, start a greenfield application, or coordinate the repository's\nfirst substantial build. Ordinary feature work, repairs, debugging, and\nexplanations use their normal workflows.\n\nIf `.beryl\u002Fagent\u002Fhierarchy.md` already exists, treat it as an active initial\nbuild and resume this workflow. Do not create a second hierarchy or restart the\ninterview without first reading the existing hierarchy and asking the user\nwhether they want to pause or abandon that build.\n\n## Required Context\n\nRead these files before making a plan or changing code:\n\n- `.beryl\u002Fagent\u002Fproject-brief.md`\n- `.beryl\u002Fagent\u002Farchitecture.md`\n- `.beryl\u002Fagent\u002Fubiquitous-language.md`\n- `.beryl\u002Fagent\u002Ftesting-policy.md`\n- `.beryl\u002Fagent\u002Fagent-rules.md`\n- `.beryl\u002Fagent\u002Ftask-routing.md`\n\nThen inspect the repository's source tree, package\u002Fbuild configuration, existing\ntests, entry points, deployment configuration, and relevant documentation. Use\nthe repository as the source of truth. Do not treat hidden chat history as\nproject context.\n\n## New-Build Process\n\nFollow these phases in order. Do not skip a gate because the request sounds\nclear.\n\n### 1. Discover the repository\n\nBefore proposing architecture or implementation work, identify what already\nexists: stack and entry points, executable commands, test and check commands,\ndata and integration boundaries, deployment targets, existing conventions,\nconstraints, and relevant gaps. Record only the facts needed to ask useful\nquestions and form a plan; do not create `hierarchy.md` during discovery.\n\n### 2. Clarify one question at a time\n\nAsk exactly one focused question per turn and wait for the user's answer before\nasking another. Prefer a recommended default when a choice is not already\nsettled by the repository. Cover the decisions that materially affect the\nbuild, including:\n\n- primary users, outcomes, and highest-value workflows;\n- required platforms, integrations, data ownership, and security or privacy\n  constraints;\n- scope boundaries, non-goals, rollout assumptions, and delivery constraints;\n- acceptance criteria, operational expectations, and required checks.\n\nDo not ask questions whose answers can be discovered from the repository. Keep\nanswers in the conversation until they become durable project knowledge.\n\n### 3. Develop the hierarchical plan\n\nAfter clarification, propose a complete plan before editing build code. Decompose\nthe request into a hierarchy of deliverables, not a flat list of prompts. Cover\nproduct boundaries, domain\u002Fdata boundaries, architecture and adapters,\nvertical slices, migrations or rollout, testing, observability, documentation,\nand operational checks as applicable.\n\nFor every node, state its parent, dependencies, deliverable, acceptance checks,\nstatus, and canonical context targets. Order nodes so a node is implemented only\nwhen all of its dependencies are complete. Make dependencies explicit even when\ntwo nodes are in the same feature area. Include non-goals and assumptions in the\nproposal so the user can review scope rather than only tasks.\n\n### 4. Require ratification\n\nPresent the clarified scope and the full hierarchy, including implementation\norder, dependencies, deliverables, checks, context targets, risks, and open\nassumptions. Ask the user to ratify the plan. Silence, a partial answer, or a\nrequest to keep planning is not ratification.\n\nBefore ratification:\n\n- do not create `.beryl\u002Fagent\u002Fhierarchy.md`;\n- do not edit application code or build configuration;\n- do not claim that implementation has started.\n\nIf the user changes scope, update the proposal and seek ratification again.\n\n### 5. Create the tracked hierarchy\n\nOnly after explicit ratification, create `.beryl\u002Fagent\u002Fhierarchy.md` in the\nrepository. It is intentionally Git-tracked and must not be added to a\ngitignore. The file is authoritative for active initial-build order and\nprogress, but it is a transient lifecycle artifact rather than permanent\nproject documentation.\n\nVerify that `git check-ignore .beryl\u002Fagent\u002Fhierarchy.md` does not report the\nfile, then run `git add .beryl\u002Fagent\u002Fhierarchy.md` as part of preparing the\nfirst build commit the user authorizes. If an ignore rule or Git error prevents\nstaging it, stop and resolve that condition instead of continuing with an\nuntracked hierarchy. Do not claim that it is Git-tracked until `git ls-files\n.beryl\u002Fagent\u002Fhierarchy.md` confirms it. Keep later hierarchy updates in the\nsame authorized commits as their corresponding implementation slices so a\ncheckout contains the active build state. Do not create an otherwise\nunauthorized commit only to track the hierarchy.\n\nUse this minimum schema:\n\n```markdown\n# Initial Build Hierarchy\n\n## Build Contract\n- Scope:\n- Non-goals:\n- Ratified on:\n- Last updated:\n- Completion rule: every node and required check passes, durable context is promoted\n\n## Nodes\n\n### \u003Cstable-node-id> — \u003Cshort name>\n- Parent: \u003Cstable-node-id or root>\n- Dependencies: \u003Cstable-node-id list or none>\n- Deliverable: \u003Cobservable result>\n- Acceptance checks:\n  - \u003Ccommand, test, inspection, or user-visible check>\n- Status: pending | ready | in-progress | blocked | complete\n- Canonical context targets:\n  - \u003C.beryl\u002Fagent\u002F\u003Cfile>.md or none>\n- Evidence: \u003Cshort command\u002Fresult or link to review evidence>\n```\n\nEvery node must have all seven fields: stable id, parent, dependencies,\ndeliverable, acceptance checks, status, and canonical context targets. Keep the\nhierarchy readable in ordinary Markdown. Do not store secrets in it.\n\n### 6. Implement in dependency order\n\nSelect only nodes whose dependencies are complete. Implement one coherent\nvertical slice at a time using the normal feature, testing, architecture, and\nsecurity workflows. Before each slice, confirm the node's acceptance checks and\nthe relevant host-project commands. After each slice:\n\n1. Run the node's narrow checks, then the broader deterministic project gate.\n2. Update the node status and evidence in `hierarchy.md`.\n3. Update canonical Markdown when a durable scope decision, boundary,\n   vocabulary term, architecture decision, or verification rule changes.\n4. Keep progress notes, temporary rationale, and unresolved scratch details in\n   `hierarchy.md`, not in canonical docs.\n\nIf a node is blocked, mark it blocked with the concrete reason and do not\nimplement dependent nodes. Re-plan affected nodes and seek user ratification if\nscope, dependencies, or acceptance criteria change materially.\n\n### 7. Promote durable context and complete\n\nBefore declaring the initial build complete, verify that every node is complete,\nevery required node and project check passes, and all durable knowledge has been\npromoted to the smallest relevant canonical file. Durable knowledge includes\nsettled scope and non-goals, bounded-context ownership, public interfaces,\nadapters, stable vocabulary, architecture decisions, and verification rules.\n\nDo not copy the hierarchy wholesale into canonical files. Progress, sequencing,\ntemporary rationale, and completed-node evidence are lifecycle state.\n\nOnly after those conditions pass may you delete `.beryl\u002Fagent\u002Fhierarchy.md`.\nDeletion is the narrow declared exception to the normal documentation deletion\nsafeguard: preserve the durable promotions first, verify the completion gate,\nthen remove only this file. Include the deletion in the same authorized final\nbuild commit as the last durable promotions, and verify that the completed tree\nno longer tracks the file. Report the deletion and the checks that authorized\nit. If any node or check remains incomplete, keep the file and resume later.\n\n## Resumption\n\nAt the start of every session, check for `.beryl\u002Fagent\u002Fhierarchy.md` before\nstarting a new build. If present, read its build contract, node statuses,\ndependencies, blocked reasons, evidence, and context targets. Continue from the\nfirst dependency-ready node. Reconcile the hierarchy with the current working\ntree before editing; if the tree or user request conflicts with it, pause that\nnode and ask one focused question.\n\n## Completion Checklist\n\n- [ ] The request was explicitly classified as a large or greenfield initial build.\n- [ ] Repository discovery happened before the hierarchy was proposed.\n- [ ] Clarification questions were asked one at a time.\n- [ ] Scope, non-goals, hierarchy, dependencies, deliverables, checks, and\n      context targets were explicitly ratified.\n- [ ] `hierarchy.md` was created only after ratification and was Git-tracked.\n- [ ] The hierarchy entered the first authorized build commit and its updates\n      were committed with their implementation slices.\n- [ ] Nodes were implemented only after their dependencies completed.\n- [ ] Hierarchy statuses and evidence were updated after each slice.\n- [ ] Durable context was promoted to canonical Markdown as it changed.\n- [ ] Every node and required check passed before deletion.\n- [ ] `hierarchy.md` was deleted only after the previous conditions passed.\n- [ ] The deletion was committed with the final durable context promotions.\n\n## Output Contract\n\nWhen stopping before ratification, report the discovery findings, unanswered\nquestion (one at a time), proposed scope, and what remains before approval.\n\nWhen implementing, report the active node, dependency status, changed files,\ncontext promotions, checks, evidence, and next dependency-ready node. At\ncompletion, report the durable files updated, all checks run, and the authorized\ndeletion of `hierarchy.md`.\n",{},"main","3a5bd7e327cbdad81a70b624ec3fc6e43ec91f12",".beryl\u002Fagent\u002Fskills\u002Finitial-build",0,"https:\u002F\u002Fgithub.com\u002FPraneeth-Suresh\u002FBeryl","https:\u002F\u002Fgithub.com\u002FPraneeth-Suresh","Just built it.","2026-11-09 18:59:34",{"source":7,"skillName":5,"commands":33,"prompt":43,"zipAvailable":44},[34,37,40],{"tool":35,"command":36},"npx","npx skills add Praneeth-Suresh\u002FBeryl --skill initial-build",{"tool":38,"command":39},"bunx","bunx skills add Praneeth-Suresh\u002FBeryl --skill initial-build",{"tool":41,"command":42},"pnpm","pnpm dlx skills add Praneeth-Suresh\u002FBeryl --skill initial-build","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FPraneeth-Suresh\u002FBeryl\u002Fblob\u002Fmain\u002F.beryl\u002Fagent\u002Fskills\u002Finitial-build\u002FSKILL.md",true,[],[47,72,79,112,137,152],{"skillNo":48,"name":49,"nameZh":6,"description":50,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":51,"licenseFileUrl":52,"sourceHtmlUrl":53,"categories":54,"keywords":55,"publishedAt":20},"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",[],[56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71],"verification","verification before completion","committing","commands","about","work","claims","output","evidence","when","assertions","use","claim","prs","complete","running",{"skillNo":73,"name":74,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":75,"categories":76,"keywords":77,"publishedAt":20},"01M71SGD1DV15B9Z2S5V3M8YPH","using-beryl","https:\u002F\u002Fgithub.com\u002FPraneeth-Suresh\u002FBeryl\u002Fblob\u002Fmain\u002F.beryl\u002Fagent\u002Fskills\u002Fusing-beryl\u002FSKILL.md",[],[78],"using beryl",{"skillNo":80,"name":81,"nameZh":6,"description":82,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":83,"categories":84,"keywords":93,"publishedAt":20},"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",[85,90],{"categoryNo":86,"categoryName":87,"taxonomyType":88,"taxonomyTypeDesc":89},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",{"categoryNo":91,"categoryName":92,"taxonomyType":88,"taxonomyTypeDesc":89},"01JBSEEDCAT000000000000039","教师与教育",[94,95,96,97,98,99,100,101,102,103,67,65,104,105,106,107,108,109,110,111],"understand","codebase","understand codebase","branch","diff","for","explore","execution","quiz","map","code","commit","interactive","explain","artifact","how","pull request","pull",{"skillNo":113,"name":114,"nameZh":6,"description":115,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":51,"licenseFileUrl":116,"sourceHtmlUrl":117,"categories":118,"keywords":127,"publishedAt":20},"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",[119,124],{"categoryNo":120,"categoryName":121,"taxonomyType":122,"taxonomyTypeDesc":123},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":125,"categoryName":126,"taxonomyType":122,"taxonomyTypeDesc":123},"01JBSEEDCAT000000000000018","写作与文案",[128,129,130,131,132,133,134,67,65,104,135,136],"driven","test","test driven development","development","feature","implementing","writing","bugfix","implementation",{"skillNo":138,"name":139,"nameZh":6,"description":140,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":51,"licenseFileUrl":141,"sourceHtmlUrl":142,"categories":143,"keywords":145,"publishedAt":20},"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",[144],{"categoryNo":120,"categoryName":121,"taxonomyType":122,"taxonomyTypeDesc":123},[146,147,148,149,67,65,129,150,151],"systematic","debugging","systematic debugging","fixes","behavior","bug",{"skillNo":153,"name":154,"nameZh":6,"description":155,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":156,"categories":157,"keywords":159,"publishedAt":20},"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",[158],{"categoryNo":86,"categoryName":87,"taxonomyType":88,"taxonomyTypeDesc":89},[160,104,161,162,163,164,165,166,65,67,167,168,169,170,171,172,64,173,174,175],"simplifying code","design","change","with","architecture","program","simplify","module","changes","improve","clean","up","slice","complexity","behavior-preserving","maintenance"]