[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6JYTEXXM735EEB4BYK9B83G":3,"skill-same:01M6JYTEXXM735EEB4BYK9B83G":79},{"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":26,"publishedAt":51,"linkOnly":52,"markdownContent":53,"markdownBody":54,"frontMatter":55,"refName":56,"commitSha":57,"skillDirectory":58,"forksCount":59,"repositoryHtmlUrl":60,"repositoryHomepageUrl":6,"ownerHtmlUrl":61,"ownerBlogUrl":62,"ownerDescription":63,"updatedAt":64,"install":65,"resources":78},"01M6JYTEXXM735EEB4BYK9B83G","architecture-quality",null,"Keep web applications, APIs and services readable as they grow: choose feature or domain seams, assign state ownership, enforce dependency direction, keep adapters thin, and verify file shape. Use when starting or extending a web app, backend, frontend, API or multi-page product; when a change makes a module hard to read; when architecture review finds a god file, cross-feature imports, a circular dependency or a framework-heavy domain. Load architecture-first first for a new system, and refactoring-safely for an existing oversized module. Do not use for a one-file script, throwaway spike or a purely local naming change.","AnastasiyaW\u002Fcodex-claude-code-config","AnastasiyaW","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F92753226?v=4","01M6JYPD9X5RRF8G7AH91NYD3R","Anastasiia Butova","01M6JYPDFBGM5EV8G8BABQ3GDY",214,"MIT","https:\u002F\u002Fgithub.com\u002FAnastasiyaW\u002Fcodex-claude-code-config\u002Fblob\u002Fmain\u002Fskills\u002Fdevelopment\u002Farchitecture-quality\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",[27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50],"architecture","architecture quality","quality","read","extending","new","when","throwaway","imports","direction","app","grow","local","dependency","frontend","choose","refactoring","api","framework","product","architecture review","change","spike","review","2026-11-10 10:12:30",false,"---\nname: architecture-quality\ndescription: >\n  Keep web applications, APIs and services readable as they grow: choose feature or\n  domain seams, assign state ownership, enforce dependency direction, keep adapters\n  thin, and verify file shape. Use when starting or extending a web app, backend,\n  frontend, API or multi-page product; when a change makes a module hard to read;\n  when architecture review finds a god file, cross-feature imports, a circular\n  dependency or a framework-heavy domain. Load architecture-first first for a new\n  system, and refactoring-safely for an existing oversized module. Do not use for a\n  one-file script, throwaway spike or a purely local naming change.\n---\n\n# Architecture quality — readable by construction\n\nThis skill turns the architecture decision into a small, repeatable delivery\ncontract. It complements `architecture-first`; it does not add layers for their own\nsake.\n\n## Working contract\n\nBefore a non-trivial web or service change, record these five facts in\n`ARCHITECTURE.md` or `docs\u002Farchitecture\u002FREADME.md`:\n\n1. **Feature\u002Fdomain modules** — name them by reason to change, not by a generic\n   `utils`, `helpers` or `services` bucket.\n2. **Ownership** — each mutable state, database table boundary and external side\n   effect has one owner.\n3. **Dependency direction** — policy\u002Fdomain code is independent of the web\n   framework, ORM, queue and filesystem; adapters point inward through small ports.\n4. **Vertical slice** — prove one user-visible path from entry point to state and\n   test before multiplying layers or pages.\n5. **Verification boundary** — list the architecture checks and the test command\n   that must remain green after the change.\n\nIf the project is a small script or a single-module experiment, state that scope and\nskip the document. A missing document is a finding only once the project has enough\nshape to need one, not a reason to create ceremony around a toy.\n\n## Web application shape\n\n- Keep routes\u002Fcontrollers thin: parse input, call a use-case or feature API, map the\n  result and return. Do not put business policy, SQL and provider retries in a route.\n- Keep domain\u002Fuse-case code framework-free where practical. Inject ports for storage,\n  clocks, queues and providers; keep concrete adapters at the edge.\n- Organize user-facing behavior by feature or bounded context. A page may compose\n  features, but one feature must not reach into another feature's private state.\n- Give each page a stable route-level composition boundary. Shared UI primitives are\n  visual primitives, not a second business-logic layer.\n- Treat a `utils` or `common` import that keeps growing as a boundary question. Move\n  code to the module that owns its reason to change; do not create a universal bag.\n- Prefer a modular monolith until an independently deployable or scalable boundary is\n  proven. A microservice split is not a substitute for a missing internal boundary.\n\n## Shape checks\n\nRun the repository audit before broadening a new app and after a structural change:\n\n```powershell\npython \"${CLAUDE_PLUGIN_ROOT}\u002Fscripts\u002Farchitecture_audit.py\" --root .\n```\n\nThe audit is intentionally conservative. It reports, rather than invents, findings:\n\n- a sizeable application with no `ARCHITECTURE.md` or architecture directory;\n- a source file crossing the calibrated shape thresholds;\n- an explicitly declared project marker without a readable architecture anchor.\n\nThe live `module-shape-advisor.py` hook repeats the file-shape check after\n`Write|Edit|MultiEdit` in both Codex and Claude. It is advisory: acknowledge the\nfinding, split at an ownership boundary, or record why the file is intentionally\nlarge. `CLAUDE_ALLOW_BIG_MODULES=1` is an explicit, reviewable escape hatch, not a\ndefault.\n\nFor dependency rules, use the tool native to the stack when the project has earned\nit:\n\n- Python: `import-linter` contracts for allowed import direction;\n- JavaScript\u002FTypeScript: `dependency-cruiser` for cycles, orphans and forbidden\n  folder edges;\n- Java: `ArchUnit` architecture tests alongside unit tests;\n- C\u002FC++: compiler\u002Finclude tooling plus explicit CMake target boundaries; do not infer\n  a domain architecture from a raw include graph alone.\n\nDo not install all four. Pick one boundary mechanism, commit its rules, and run it in\nthe same CI lane as the tests that prove the behavior.\n\n## Review questions\n\n- Can a new feature be changed without editing an unrelated feature's internals?\n- Does a route, page or controller own policy that belongs inside a use-case\u002Fdomain?\n- Is state ownership named, or are modules reaching into shared mutable objects?\n- Are imports crossing a documented boundary? If yes, is the exception recorded with\n  a reason and expiry?\n- Is the file becoming large because one change is crossing multiple reasons to\n  change? If yes, split the seam before adding more behavior.\n- Did the change update the architecture document and the focused architecture\u002Ftest\n  evidence together?\n\n## Gotchas\n\n- **Folders are not boundaries.** Moving files without changing imports or ownership\n  only makes the same coupling harder to see.\n- **Thin controllers can still hide a fat service.** Inspect the next boundary; a\n  generic `ApplicationService` is often a god module with a nicer name.\n- **A metric is a signal, not a verdict.** Generated code, migrations and large\n  declarative tables need explicit exemptions; production logic needs an explanation\n  before an exemption.\n- **Microservices can multiply unreadability.** Network boundaries add failure,\n  deployment and observability costs; prove the module boundary first.\n\n## Troubleshooting\n\n| Symptom | Likely cause | Action |\n|---|---|---|\n| The audit reports a missing architecture anchor | An app marker and several source files exist, but the boundary is implicit | Write the small module\u002Fownership\u002Fdependency map before adding more features |\n| `module-shape-advisor` reports a large file | Local edits accumulated in one ownership boundary | Add characterization tests, split one named slice, then rerun the audit |\n| A cycle appears | Two modules own part of the same concept or one imports an implementation detail | Move the concept behind an inner port or extract a genuinely shared concept |\n| Every change touches many folders | Layer-first layout scatters a feature across technical layers | Recut the next slice by feature; migrate incrementally with tests |\n| The guard is noisy on generated code | The file is outside the built-in exemption list | Add a narrow, documented project exemption; do not silence the whole hook |\n","# Architecture quality — readable by construction\n\nThis skill turns the architecture decision into a small, repeatable delivery\ncontract. It complements `architecture-first`; it does not add layers for their own\nsake.\n\n## Working contract\n\nBefore a non-trivial web or service change, record these five facts in\n`ARCHITECTURE.md` or `docs\u002Farchitecture\u002FREADME.md`:\n\n1. **Feature\u002Fdomain modules** — name them by reason to change, not by a generic\n   `utils`, `helpers` or `services` bucket.\n2. **Ownership** — each mutable state, database table boundary and external side\n   effect has one owner.\n3. **Dependency direction** — policy\u002Fdomain code is independent of the web\n   framework, ORM, queue and filesystem; adapters point inward through small ports.\n4. **Vertical slice** — prove one user-visible path from entry point to state and\n   test before multiplying layers or pages.\n5. **Verification boundary** — list the architecture checks and the test command\n   that must remain green after the change.\n\nIf the project is a small script or a single-module experiment, state that scope and\nskip the document. A missing document is a finding only once the project has enough\nshape to need one, not a reason to create ceremony around a toy.\n\n## Web application shape\n\n- Keep routes\u002Fcontrollers thin: parse input, call a use-case or feature API, map the\n  result and return. Do not put business policy, SQL and provider retries in a route.\n- Keep domain\u002Fuse-case code framework-free where practical. Inject ports for storage,\n  clocks, queues and providers; keep concrete adapters at the edge.\n- Organize user-facing behavior by feature or bounded context. A page may compose\n  features, but one feature must not reach into another feature's private state.\n- Give each page a stable route-level composition boundary. Shared UI primitives are\n  visual primitives, not a second business-logic layer.\n- Treat a `utils` or `common` import that keeps growing as a boundary question. Move\n  code to the module that owns its reason to change; do not create a universal bag.\n- Prefer a modular monolith until an independently deployable or scalable boundary is\n  proven. A microservice split is not a substitute for a missing internal boundary.\n\n## Shape checks\n\nRun the repository audit before broadening a new app and after a structural change:\n\n```powershell\npython \"${CLAUDE_PLUGIN_ROOT}\u002Fscripts\u002Farchitecture_audit.py\" --root .\n```\n\nThe audit is intentionally conservative. It reports, rather than invents, findings:\n\n- a sizeable application with no `ARCHITECTURE.md` or architecture directory;\n- a source file crossing the calibrated shape thresholds;\n- an explicitly declared project marker without a readable architecture anchor.\n\nThe live `module-shape-advisor.py` hook repeats the file-shape check after\n`Write|Edit|MultiEdit` in both Codex and Claude. It is advisory: acknowledge the\nfinding, split at an ownership boundary, or record why the file is intentionally\nlarge. `CLAUDE_ALLOW_BIG_MODULES=1` is an explicit, reviewable escape hatch, not a\ndefault.\n\nFor dependency rules, use the tool native to the stack when the project has earned\nit:\n\n- Python: `import-linter` contracts for allowed import direction;\n- JavaScript\u002FTypeScript: `dependency-cruiser` for cycles, orphans and forbidden\n  folder edges;\n- Java: `ArchUnit` architecture tests alongside unit tests;\n- C\u002FC++: compiler\u002Finclude tooling plus explicit CMake target boundaries; do not infer\n  a domain architecture from a raw include graph alone.\n\nDo not install all four. Pick one boundary mechanism, commit its rules, and run it in\nthe same CI lane as the tests that prove the behavior.\n\n## Review questions\n\n- Can a new feature be changed without editing an unrelated feature's internals?\n- Does a route, page or controller own policy that belongs inside a use-case\u002Fdomain?\n- Is state ownership named, or are modules reaching into shared mutable objects?\n- Are imports crossing a documented boundary? If yes, is the exception recorded with\n  a reason and expiry?\n- Is the file becoming large because one change is crossing multiple reasons to\n  change? If yes, split the seam before adding more behavior.\n- Did the change update the architecture document and the focused architecture\u002Ftest\n  evidence together?\n\n## Gotchas\n\n- **Folders are not boundaries.** Moving files without changing imports or ownership\n  only makes the same coupling harder to see.\n- **Thin controllers can still hide a fat service.** Inspect the next boundary; a\n  generic `ApplicationService` is often a god module with a nicer name.\n- **A metric is a signal, not a verdict.** Generated code, migrations and large\n  declarative tables need explicit exemptions; production logic needs an explanation\n  before an exemption.\n- **Microservices can multiply unreadability.** Network boundaries add failure,\n  deployment and observability costs; prove the module boundary first.\n\n## Troubleshooting\n\n| Symptom | Likely cause | Action |\n|---|---|---|\n| The audit reports a missing architecture anchor | An app marker and several source files exist, but the boundary is implicit | Write the small module\u002Fownership\u002Fdependency map before adding more features |\n| `module-shape-advisor` reports a large file | Local edits accumulated in one ownership boundary | Add characterization tests, split one named slice, then rerun the audit |\n| A cycle appears | Two modules own part of the same concept or one imports an implementation detail | Move the concept behind an inner port or extract a genuinely shared concept |\n| Every change touches many folders | Layer-first layout scatters a feature across technical layers | Recut the next slice by feature; migrate incrementally with tests |\n| The guard is noisy on generated code | The file is outside the built-in exemption list | Add a narrow, documented project exemption; do not silence the whole hook |\n",{"name":5,"description":7},"main","ac20f93f36e574610dbc51743bb21e7765142e95","skills\u002Fdevelopment\u002Farchitecture-quality",32,"https:\u002F\u002Fgithub.com\u002FAnastasiyaW\u002Fcodex-claude-code-config","https:\u002F\u002Fgithub.com\u002FAnastasiyaW","https:\u002F\u002Fhappyin.work","ComfyUI specialist · turnkey image-processing pipelines · diffusion models, computer vision · Belgrade","2026-11-14 01:35:49",{"source":8,"skillName":5,"commands":66,"prompt":76,"zipAvailable":77},[67,70,73],{"tool":68,"command":69},"npx","npx skills add AnastasiyaW\u002Fcodex-claude-code-config --skill architecture-quality",{"tool":71,"command":72},"bunx","bunx skills add AnastasiyaW\u002Fcodex-claude-code-config --skill architecture-quality",{"tool":74,"command":75},"pnpm","pnpm dlx skills add AnastasiyaW\u002Fcodex-claude-code-config --skill architecture-quality","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FAnastasiyaW\u002Fcodex-claude-code-config\u002Fblob\u002Fmain\u002Fskills\u002Fdevelopment\u002Farchitecture-quality\u002FSKILL.md",true,[],[80,91,106,132,160,178],{"skillNo":81,"name":82,"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":83,"categories":84,"keywords":88,"publishedAt":51},"01M6JZ2SNGKFN8NK3HZBMVGQP1","owner-voice","https:\u002F\u002Fgithub.com\u002FAnastasiyaW\u002Fcodex-claude-code-config\u002Fblob\u002Fmain\u002Fskills\u002Fwriting\u002Fowner-voice\u002FSKILL.md",[85],{"categoryNo":86,"categoryName":87,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[89,90],"owner voice","voice",{"skillNo":92,"name":93,"nameZh":6,"description":94,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":95,"categories":96,"keywords":98,"publishedAt":51},"01M6JZ2N0C2WFCAK6T8N3RMBVS","humanize-russian","Редактировать русский текст для ясности и естественного звучания, сохраняя факты,\nтермины, источники и жанр. Использовать когда: убрать канцелярит, сделать текст\nживее, отредактировать русский черновик или статью перед публикацией.\nНе определяет авторство и не обещает обход детекторов. Для английского —\nhumanize-english; для структуры и доказательств — article-structure-review.","https:\u002F\u002Fgithub.com\u002FAnastasiyaW\u002Fcodex-claude-code-config\u002Fblob\u002Fmain\u002Fskills\u002Fwriting\u002Fhumanize-russian\u002FSKILL.md",[97],{"categoryNo":86,"categoryName":87,"taxonomyType":21,"taxonomyTypeDesc":22},[99,100,101,102,50,103,104,105],"russian","humanize","humanize russian","english","structure","article","2026",{"skillNo":107,"name":108,"nameZh":6,"description":109,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":110,"categories":111,"keywords":112,"publishedAt":51},"01M6JZ2GN264R6GKBQ5QVZE0ZS","humanize-english","Edit English drafts for clear, natural language while preserving facts, uncertainty,\ntechnical meaning, citations and genre. Use when: humanize this text, remove AI-style\nfiller, improve English prose, or edit an English article before publication.\nNot an authorship detector or a promise to bypass one. For Russian use\nhumanize-russian; for thesis\u002Fevidence and structure use article-structure-review.","https:\u002F\u002Fgithub.com\u002FAnastasiyaW\u002Fcodex-claude-code-config\u002Fblob\u002Fmain\u002Fskills\u002Fwriting\u002Fhumanize-english\u002FSKILL.md",[],[100,102,113,114,99,115,116,117,118,103,119,120,121,50,122,105,33,123,124,125,126,127,128,129,104,130,131],"humanize english","technical","evidence","use","remove","edit","text","improve","Citations","Publication","for","facts","natural language","drafts","meaning","uncertainty","style","thesis","promise",{"skillNo":133,"name":134,"nameZh":6,"description":135,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":136,"categories":137,"keywords":138,"publishedAt":51},"01M6JZ2BM31D5Y609DQJJJM6MM","caveman","Ultra-compressed reply mode. Cuts output tokens ~65-75% by answering in terse \"caveman\" style while keeping full technical accuracy, and shapes what survives: action first, state restated every turn, concrete time estimates, visible wins. Intensity levels: lite, full (default), ultra, wenyan-lite, wenyan-full, wenyan-ultra. Use when user says \"caveman\", \"talk like caveman\", \"use caveman\", \"less tokens\", \"be brief\", or Russian \"пещерный режим\", \"говори как пещерный\", \"кратко\", \"меньше токенов\", \"экономь токены\" — or invokes \u002Fcaveman. Preserves the user's language (Russian in → Russian caveman out). Off only: \"stop caveman\" \u002F \"normal mode\" \u002F \"обычный режим\". Do not use merely because a response should be concise, and do not use when the user requests normal prose, a polished document, or exact wording.","https:\u002F\u002Fgithub.com\u002FAnastasiyaW\u002Fcodex-claude-code-config\u002Fblob\u002Fmain\u002Fskills\u002Fwriting\u002Fcaveman\u002FSKILL.md",[],[134,129,33,139,140,141,142,143,144,145,146,147,148,149,150,151,152,99,153,154,155,156,116,114,157,158,159],"normal","terse","accuracy","ultra","mode","document","requests","concise","output","intensity","tokens","full","time","do","action","default","stop","only","first","brief","state",{"skillNo":161,"name":162,"nameZh":6,"description":163,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":164,"categories":165,"keywords":175,"publishedAt":51},"01M6JZ25Y5GJXFKXNR6TRQX237","article-structure-review","Проверить структуру технической статьи после черновика: задача читателя, жанр,\nопора значимых утверждений на доказательства и честные ограничения.\nUse after the first draft, before publication. Исправлять структуру, когда это\nвходит в запрос; не создавать обязательный конвейер из других навыков.\nДля локальной языковой редактуры — humanize-english или humanize-russian.","https:\u002F\u002Fgithub.com\u002FAnastasiyaW\u002Fcodex-claude-code-config\u002Fblob\u002Fmain\u002Fskills\u002Fwriting\u002Farticle-structure-review\u002FSKILL.md",[166,169,170],{"categoryNo":167,"categoryName":168,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":86,"categoryName":87,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":171,"categoryName":172,"taxonomyType":173,"taxonomyTypeDesc":174},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[176,104,103,50,177,100,99,116,157,102,122,105],"article structure review","draft",{"skillNo":179,"name":180,"nameZh":6,"description":181,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":182,"categories":183,"keywords":187,"publishedAt":51},"01M6JZ1XN7WQQCWCHHMTTD8K28","video-post-production","Video post-production rules: audio mastering, color, captions, platform export. Use when: 'add music', 'add voiceover', 'export for tiktok', 'add captions', 'color grade', 'audio levels', 'master audio', 'export settings', 'platform requirements'. Covers FFmpeg patterns, audio chain, subtitle standards, and platform-specific export configs. Do NOT use to generate or animate the video frames\u002Fscenes in code (use remotion-production-guide), to write the script (use video-narrative-arc), or to evaluate script quality (use script-evaluator); this is the finishing stage applied to an already-rendered video.","https:\u002F\u002Fgithub.com\u002FAnastasiyaW\u002Fcodex-claude-code-config\u002Fblob\u002Fmain\u002Fskills\u002Fvideo-production\u002Fvideo-post-production\u002FSKILL.md",[184],{"categoryNo":185,"categoryName":186,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000016","图像与多媒体",[188,189,190,191,192,33,193,194,195,196,197,198,199,200,201,202,203,204,205,206,207],"video post production","post","Production","Video","patterns","post-production","narrative","add","chain","tiktok","voiceover","master","export","write","music","Captions","Audio","Remotion","code","generate"]