[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6WZJBHEZDR8YCX6CA0VPNPD":3,"skill-same:01M6WZJBHEZDR8YCX6CA0VPNPD":67},{"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":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":43,"commitSha":44,"skillDirectory":45,"forksCount":46,"repositoryHtmlUrl":47,"repositoryHomepageUrl":48,"ownerHtmlUrl":49,"ownerBlogUrl":50,"ownerDescription":51,"updatedAt":52,"install":53,"resources":66},"01M6WZJBHEZDR8YCX6CA0VPNPD","testsuite",null,"Verona compiler test suite infrastructure — running tests, updating golden files, verifying pass completeness, checking error codes. Use when debugging test failures, regenerating golden files, or understanding the test framework.","microsoft\u002Fverona","microsoft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6154722?v=4","01M698VYDXZ6JW5WH3CRV650R8","Microsoft","01M6WZHTA01TB3YK5SZM938MTG",3742,"MIT","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fverona\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Ftestsuite\u002FSKILL.md",[],[5,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"tests","running","when","error codes","suite","codes","error","golden","completeness","test","files","test suite","use","compiler","running tests","framework","debugging","infrastructure","test framework","2026-11-10 10:12:30",false,"---\nname: testsuite\ndescription: Verona compiler test suite infrastructure — running tests, updating golden files, verifying pass completeness, checking error codes. Use when debugging test failures, regenerating golden files, or understanding the test framework.\n---\n\n# Verona Test Suite Guide\n\n## Test Infrastructure Overview\n\nThe test suite uses Trieste's `testsuite.cmake` framework. Tests are defined in `testsuite\u002FCMakeLists.txt`, which calls `testsuite(vbc)`. Two collection files define complete compile\u002Frun pipelines:\n\n| Collection | File | Pipeline | Input |\n|------------|------|----------|-------|\n| **vc** | `testsuite\u002Fvc.cmake` | Verona → bytecode → execute | `*.v` files |\n| **vir** | `testsuite\u002Fvir.cmake` | IR → bytecode → execute | `*.vir` files |\n\nEach collection owns its compiler invocation and registers a dependent\ninterpreter node. Sources under a `compile_only\u002F` directory register only the\ncompile node.\n\nEach test produces `exit_code.txt`, `stdout.txt`, and `stderr.txt` in its output directory. The vc layer also produces per-pass `.trieste` dump files, a `*_final.trieste`, and a `.vbc` file (on success).\n\n## Running Tests\n\n### Full test suite\n```bash\ncd build && ctest --output-on-failure -j$(nproc)\n\n### Run specific test(s) by name\n```bash\ncd build && ctest --output-on-failure -R \"^vbc\u002F\u003Cname>\" -j$(nproc)\n```\n\nThe `^vbc\u002F` prefix matches both compile and run tests for a given name. For example, `^vbc\u002Fhello` matches:\n- `vbc\u002Fhello\u002Fhello\u002Fcompile` (the compilation test)\n- `vbc\u002Fhello\u002Fhello\u002Fcompile-exit_code.txt` (exit code comparison)\n- `vbc\u002Fhello\u002Fhello\u002Fcompile-stdout.txt` etc.\n- `vbc\u002Fhello\u002Fhello\u002Frun` (the runtime test, if it exists)\n- `vbc\u002Fhello\u002Fhello\u002Frun-exit_code.txt` etc.\n\n### Run only compile or only runtime tests\n```bash\ncd build && ctest --output-on-failure -R \"compile\" -j$(nproc)   # all compile tests\ncd build && ctest --output-on-failure -R \"run\" -j$(nproc)       # all runtime tests\n```\n\n### List available tests without running\n```bash\ncd build && ctest -N | grep \u003Cname>\n```\n\n## Golden Files\n\n### Structure\n\nEach test `testsuite\u002Fv\u002F\u003Cname>\u002F\u003Cname>.v` has golden files at:\n- `testsuite\u002Fv\u002F\u003Cname>\u002F\u003Cname>\u002Fcompile\u002F` — compilation golden output\n- `testsuite\u002Fv\u002F\u003Cname>\u002F\u003Cname>\u002Frun\u002F` — runtime golden output (success tests only)\n\n### Expected compile\u002F contents (success tests)\n\n```\n00_parse.trieste          # Pass 0 output\n01_structure.trieste      # Pass 1 output\n02_ident.trieste          # Pass 2 output\n03_sugar.trieste          # Pass 3 output\n04_functype.trieste       # Pass 4 output\n05_dot.trieste            # Pass 5 output\n06_application.trieste    # Pass 6 output\n07_anf.trieste            # Pass 7 output\n08_infer.trieste          # Pass 8 output\n09_reify.trieste          # Pass 9 output\n10_assignids.trieste      # Pass 10 output\n11_validids.trieste       # Pass 11 output\n12_liveness.trieste       # Pass 12 output\n13_typecheck.trieste      # Pass 13 output\n\u003Cname>_final.trieste      # Final AST\n\u003Cname>.vbc                # Compiled bytecode\nexit_code.txt             # \"0\" (no trailing newline)\nstdout.txt                # Usually empty\nstderr.txt                # Usually empty\n```\n\n### Expected compile\u002F contents (error tests)\n\nSame pass dumps up to the point of failure. No `.vbc` file. `exit_code.txt` = `1`.\n\n### Expected run\u002F contents\n\n```\nexit_code.txt             # Expected exit code (no trailing newline)\nstdout.txt                # Expected stdout\nstderr.txt                # Expected stderr (usually empty)\n```\n\n### Regenerating golden files\n\nWhen source code changes, the golden files must be regenerated:\n\n```bash\ncd build\nninja install && ninja update-dump\n```\n\n- `ninja install` — rebuild the compiler (needed so installed binary has `_builtin`)\n- `ninja update-dump` — regenerates golden output by running each test and copying results\n\n### When ALL golden files change\n\nAdding or modifying a `.v` file under `vc\u002F_builtin\u002F` changes compilation output for EVERY test, because `_builtin` is always parsed. In this case, you MUST regenerate ALL golden files:\n\n```bash\ncd build && ninja install && ninja update-dump\n```\n\nThis can take a while. All golden file changes must be committed.\n\n## Verifying Golden File Correctness\n\n### Pass completeness check\n\nAfter generating golden files, verify the `compile\u002F` directory has all 14 pass dumps (`00_parse.trieste` through `13_typecheck.trieste`). Missing passes indicate a WF (well-formedness) violation or pass failure.\n\n**Common causes of missing passes:**\n- New token\u002Fop not added to the relevant WF definition in `vc\u002Flang.h` (frontend WFs) or `include\u002Fvbcc.h` (backend WFs)\n- WF mismatch between what a pass produces and what the next pass expects\n\n**Debugging missing passes:**\n```bash\ncd build && dist\u002Fvc\u002Fvc build ..\u002Ftestsuite\u002Fv\u002F\u003Cname> --dump_passes=dump_\u003Cname>\n```\nThis dumps each pass output to the given directory. Check which pass produces the last `.trieste` file — the next pass is the one that fails.\n\n### Exit code verification\n\n- `exit_code.txt` contains the exit code as a plain number with NO trailing newline\n- The file is generated by cmake's `file(WRITE ...)` which doesn't append a newline\n- Success compile tests: `0`\n- Error compile tests: `1`\n- Runtime tests: depends on what `main` returns (typically `0` for passing tests)\n\n### Checking for correct error codes\n\nFor compile-error tests, verify:\n1. `compile\u002Fexit_code.txt` contains `1`\n2. No `run\u002F` directory exists (compilation failed, nothing to run)\n3. No `.vbc` file in `compile\u002F` (compilation didn't produce output)\n4. `stderr.txt` may contain error messages (but the framework doesn't validate error messages, only exit codes)\n\nFor runtime tests with expected non-zero exit codes:\n1. `run\u002Fexit_code.txt` contains the expected value\n2. The bitmask pattern (`result + 1`, `result + 2`, `result + 4`, ...) helps diagnose which checks failed\n\n## How the Framework Works\n\n### Test execution flow\n\n1. Trieste discovers each collection file (for example, `vc.cmake`)\n2. Its `TESTSUITE_DEFINE` callback registers a named node for each selected input\n3. CTest runs Trieste's node executor with the registered command\n4. stdout → `stdout.txt`, stderr → `stderr.txt`, exit code → `exit_code.txt`\n5. Declared artifacts are checked and declared goldens are compared\n6. Dependent run nodes execute only after their compile nodes pass\n\n### Golden file comparison\n\n1. Each file declared in `GOLDENS` is compared with the corresponding output\n2. Comparison ignores line-ending differences\n3. If a file differs, the node fails and shows a diff\n4. `exit_code.txt`, `stdout.txt`, and `stderr.txt` are declared for every node\n\n### Test naming convention\n\nTests are named hierarchically: `vbc\u002F\u003Cname>\u002F\u003Cname>\u002Fcompile` and `vbc\u002F\u003Cname>\u002F\u003Cname>\u002Frun`.\n\nEach node is one CTest test. Run nodes declare their compile node in `DEPENDS`, so\nCTest runs and verifies compilation first.\n\n## Common Pitfalls\n\n1. **Forgot `ninja install`**: The build binary at `build\u002Fvc\u002Fvc` does NOT have `_builtin` next to it. Only `build\u002Fdist\u002Fvc\u002Fvc` does. Always `ninja install` before `update-dump`.\n\n2. **Build was not regenerated**: Re-run `ninja` after adding a test so CMake's configured file globs discover it.\n\n3. **Stale golden files**: Remove files explicitly when they are no longer declared as golden outputs.\n\n4. **Hidden `.vbc` file**: Running `vc build .` from inside a test directory produces `.vbc` (hidden file) because the project name is \".\". Always run from `build\u002F`: `dist\u002Fvc\u002Fvc build ..\u002Ftestsuite\u002Fv\u002F\u003Cname>`.\n\n5. **Timeout failures**: Tests that hang (infinite loops, deadlocks) are killed after 20 seconds and produce a non-zero exit code. The `exit_code.txt` will contain a timeout error string, not a number.\n\n6. **New `_builtin` files**: Changes to `vc\u002F_builtin\u002F` affect ALL tests. Must regenerate all golden files and commit all changes.\n\n7. **Missing pass dumps**: Usually a WF violation. Check which pass is the last one that produced output and investigate the next pass's WF definition.\n\n```\n","# Verona Test Suite Guide\n\n## Test Infrastructure Overview\n\nThe test suite uses Trieste's `testsuite.cmake` framework. Tests are defined in `testsuite\u002FCMakeLists.txt`, which calls `testsuite(vbc)`. Two collection files define complete compile\u002Frun pipelines:\n\n| Collection | File | Pipeline | Input |\n|------------|------|----------|-------|\n| **vc** | `testsuite\u002Fvc.cmake` | Verona → bytecode → execute | `*.v` files |\n| **vir** | `testsuite\u002Fvir.cmake` | IR → bytecode → execute | `*.vir` files |\n\nEach collection owns its compiler invocation and registers a dependent\ninterpreter node. Sources under a `compile_only\u002F` directory register only the\ncompile node.\n\nEach test produces `exit_code.txt`, `stdout.txt`, and `stderr.txt` in its output directory. The vc layer also produces per-pass `.trieste` dump files, a `*_final.trieste`, and a `.vbc` file (on success).\n\n## Running Tests\n\n### Full test suite\n```bash\ncd build && ctest --output-on-failure -j$(nproc)\n\n### Run specific test(s) by name\n```bash\ncd build && ctest --output-on-failure -R \"^vbc\u002F\u003Cname>\" -j$(nproc)\n```\n\nThe `^vbc\u002F` prefix matches both compile and run tests for a given name. For example, `^vbc\u002Fhello` matches:\n- `vbc\u002Fhello\u002Fhello\u002Fcompile` (the compilation test)\n- `vbc\u002Fhello\u002Fhello\u002Fcompile-exit_code.txt` (exit code comparison)\n- `vbc\u002Fhello\u002Fhello\u002Fcompile-stdout.txt` etc.\n- `vbc\u002Fhello\u002Fhello\u002Frun` (the runtime test, if it exists)\n- `vbc\u002Fhello\u002Fhello\u002Frun-exit_code.txt` etc.\n\n### Run only compile or only runtime tests\n```bash\ncd build && ctest --output-on-failure -R \"compile\" -j$(nproc)   # all compile tests\ncd build && ctest --output-on-failure -R \"run\" -j$(nproc)       # all runtime tests\n```\n\n### List available tests without running\n```bash\ncd build && ctest -N | grep \u003Cname>\n```\n\n## Golden Files\n\n### Structure\n\nEach test `testsuite\u002Fv\u002F\u003Cname>\u002F\u003Cname>.v` has golden files at:\n- `testsuite\u002Fv\u002F\u003Cname>\u002F\u003Cname>\u002Fcompile\u002F` — compilation golden output\n- `testsuite\u002Fv\u002F\u003Cname>\u002F\u003Cname>\u002Frun\u002F` — runtime golden output (success tests only)\n\n### Expected compile\u002F contents (success tests)\n\n```\n00_parse.trieste          # Pass 0 output\n01_structure.trieste      # Pass 1 output\n02_ident.trieste          # Pass 2 output\n03_sugar.trieste          # Pass 3 output\n04_functype.trieste       # Pass 4 output\n05_dot.trieste            # Pass 5 output\n06_application.trieste    # Pass 6 output\n07_anf.trieste            # Pass 7 output\n08_infer.trieste          # Pass 8 output\n09_reify.trieste          # Pass 9 output\n10_assignids.trieste      # Pass 10 output\n11_validids.trieste       # Pass 11 output\n12_liveness.trieste       # Pass 12 output\n13_typecheck.trieste      # Pass 13 output\n\u003Cname>_final.trieste      # Final AST\n\u003Cname>.vbc                # Compiled bytecode\nexit_code.txt             # \"0\" (no trailing newline)\nstdout.txt                # Usually empty\nstderr.txt                # Usually empty\n```\n\n### Expected compile\u002F contents (error tests)\n\nSame pass dumps up to the point of failure. No `.vbc` file. `exit_code.txt` = `1`.\n\n### Expected run\u002F contents\n\n```\nexit_code.txt             # Expected exit code (no trailing newline)\nstdout.txt                # Expected stdout\nstderr.txt                # Expected stderr (usually empty)\n```\n\n### Regenerating golden files\n\nWhen source code changes, the golden files must be regenerated:\n\n```bash\ncd build\nninja install && ninja update-dump\n```\n\n- `ninja install` — rebuild the compiler (needed so installed binary has `_builtin`)\n- `ninja update-dump` — regenerates golden output by running each test and copying results\n\n### When ALL golden files change\n\nAdding or modifying a `.v` file under `vc\u002F_builtin\u002F` changes compilation output for EVERY test, because `_builtin` is always parsed. In this case, you MUST regenerate ALL golden files:\n\n```bash\ncd build && ninja install && ninja update-dump\n```\n\nThis can take a while. All golden file changes must be committed.\n\n## Verifying Golden File Correctness\n\n### Pass completeness check\n\nAfter generating golden files, verify the `compile\u002F` directory has all 14 pass dumps (`00_parse.trieste` through `13_typecheck.trieste`). Missing passes indicate a WF (well-formedness) violation or pass failure.\n\n**Common causes of missing passes:**\n- New token\u002Fop not added to the relevant WF definition in `vc\u002Flang.h` (frontend WFs) or `include\u002Fvbcc.h` (backend WFs)\n- WF mismatch between what a pass produces and what the next pass expects\n\n**Debugging missing passes:**\n```bash\ncd build && dist\u002Fvc\u002Fvc build ..\u002Ftestsuite\u002Fv\u002F\u003Cname> --dump_passes=dump_\u003Cname>\n```\nThis dumps each pass output to the given directory. Check which pass produces the last `.trieste` file — the next pass is the one that fails.\n\n### Exit code verification\n\n- `exit_code.txt` contains the exit code as a plain number with NO trailing newline\n- The file is generated by cmake's `file(WRITE ...)` which doesn't append a newline\n- Success compile tests: `0`\n- Error compile tests: `1`\n- Runtime tests: depends on what `main` returns (typically `0` for passing tests)\n\n### Checking for correct error codes\n\nFor compile-error tests, verify:\n1. `compile\u002Fexit_code.txt` contains `1`\n2. No `run\u002F` directory exists (compilation failed, nothing to run)\n3. No `.vbc` file in `compile\u002F` (compilation didn't produce output)\n4. `stderr.txt` may contain error messages (but the framework doesn't validate error messages, only exit codes)\n\nFor runtime tests with expected non-zero exit codes:\n1. `run\u002Fexit_code.txt` contains the expected value\n2. The bitmask pattern (`result + 1`, `result + 2`, `result + 4`, ...) helps diagnose which checks failed\n\n## How the Framework Works\n\n### Test execution flow\n\n1. Trieste discovers each collection file (for example, `vc.cmake`)\n2. Its `TESTSUITE_DEFINE` callback registers a named node for each selected input\n3. CTest runs Trieste's node executor with the registered command\n4. stdout → `stdout.txt`, stderr → `stderr.txt`, exit code → `exit_code.txt`\n5. Declared artifacts are checked and declared goldens are compared\n6. Dependent run nodes execute only after their compile nodes pass\n\n### Golden file comparison\n\n1. Each file declared in `GOLDENS` is compared with the corresponding output\n2. Comparison ignores line-ending differences\n3. If a file differs, the node fails and shows a diff\n4. `exit_code.txt`, `stdout.txt`, and `stderr.txt` are declared for every node\n\n### Test naming convention\n\nTests are named hierarchically: `vbc\u002F\u003Cname>\u002F\u003Cname>\u002Fcompile` and `vbc\u002F\u003Cname>\u002F\u003Cname>\u002Frun`.\n\nEach node is one CTest test. Run nodes declare their compile node in `DEPENDS`, so\nCTest runs and verifies compilation first.\n\n## Common Pitfalls\n\n1. **Forgot `ninja install`**: The build binary at `build\u002Fvc\u002Fvc` does NOT have `_builtin` next to it. Only `build\u002Fdist\u002Fvc\u002Fvc` does. Always `ninja install` before `update-dump`.\n\n2. **Build was not regenerated**: Re-run `ninja` after adding a test so CMake's configured file globs discover it.\n\n3. **Stale golden files**: Remove files explicitly when they are no longer declared as golden outputs.\n\n4. **Hidden `.vbc` file**: Running `vc build .` from inside a test directory produces `.vbc` (hidden file) because the project name is \".\". Always run from `build\u002F`: `dist\u002Fvc\u002Fvc build ..\u002Ftestsuite\u002Fv\u002F\u003Cname>`.\n\n5. **Timeout failures**: Tests that hang (infinite loops, deadlocks) are killed after 20 seconds and produce a non-zero exit code. The `exit_code.txt` will contain a timeout error string, not a number.\n\n6. **New `_builtin` files**: Changes to `vc\u002F_builtin\u002F` affect ALL tests. Must regenerate all golden files and commit all changes.\n\n7. **Missing pass dumps**: Usually a WF violation. Check which pass is the last one that produced output and investigate the next pass's WF definition.\n\n```\n",{"name":5,"description":7},"main","e9256534317bd40707e7e78ba022b8bcd0eb6577",".agents\u002Fskills\u002Ftestsuite",173,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fverona","https:\u002F\u002Fmicrosoft.github.io\u002Fverona\u002F","https:\u002F\u002Fgithub.com\u002Fmicrosoft","https:\u002F\u002Fopensource.microsoft.com","Open source projects and samples from Microsoft","2026-11-13 21:03:28",{"source":8,"skillName":5,"commands":54,"prompt":64,"zipAvailable":65},[55,58,61],{"tool":56,"command":57},"npx","npx skills add microsoft\u002Fverona --skill testsuite",{"tool":59,"command":60},"bunx","bunx skills add microsoft\u002Fverona --skill testsuite",{"tool":62,"command":63},"pnpm","pnpm dlx skills add microsoft\u002Fverona --skill testsuite","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fverona\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Ftestsuite\u002FSKILL.md",true,[],[68,89,108,125,141,146],{"skillNo":69,"name":70,"nameZh":6,"description":71,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":72,"categories":73,"keywords":74,"publishedAt":38},"01M6WZM7JFY7GMHE7YTCC4K0ZS","verona-type-inference","Verona compiler type inference model — bidirectional refinement, per-function inference, lambda\u002Fcontext propagation, algebraic and structural typing, generics, and debugging. Use when changing or debugging `vc\u002Fpasses\u002Finfer.cc` or investigating type inference failures.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fverona\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fverona-type-inference\u002FSKILL.md",[],[75,76,77,78,21,79,80,81,82,83,84,85,31,86,87,88,32,35],"verona type inference","type","inference","cc","vc","refinement","typing","infer","false","propagation","structural","context","model","lambda",{"skillNo":90,"name":91,"nameZh":6,"description":92,"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":38},"01M6WZM48VF2FFX61WFYTD5XVJ","verona-conventions","Verona compiler coding conventions, C++ style, trieste patterns, and project structure. Applies when writing or reviewing Verona compiler code.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fverona\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fverona-conventions\u002FSKILL.md",[],[96,97,98,83,99,100,101,102,103,32,104,105,106,21,107],"verona conventions","conventions","writing","project","c++","structure","patterns","coding","code","project structure","style","coding conventions",{"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":114,"publishedAt":38},"01M6WZM0Z3CTQG1ZRV9V2DZX9W","verona-coding","Patterns, pitfalls, and idioms for writing Verona source code (.v files). Use when writing library code, _builtin types, or user programs.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fverona\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fverona-coding\u002FSKILL.md",[],[115,103,21,116,117,118,119,120,102,121,29,122,31,123,124,104,98],"verona coding","source code","source","for","pitfalls","types","builtin","idioms","user","library",{"skillNo":126,"name":127,"nameZh":6,"description":128,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":129,"categories":130,"keywords":131,"publishedAt":38},"01M6WZKWW9ZCQ1EXZYR4GZ00YF","vbci-memory","Verona interpreter (vbci) memory management model — regions, reference counting, write barriers, dragging, cowns, and finalization. Use when working on or debugging vbci runtime memory management code.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fverona\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fvbci-memory\u002FSKILL.md",[],[132,133,134,21,135,136,137,138,31,139,140,87,104,35],"vbci memory","memory","runtime","counting","interpreter","memory management","reference","management","write",{"skillNo":142,"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":143,"categories":144,"keywords":145,"publishedAt":38},"01M6WZKP04VZBWRZ2449FBRDNY","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fverona\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Ftestsuite\u002FSKILL.md",[],[5,31,21,22,23,24,25,26,27,19,29,30,20,32,33,34,35,36,37,28],{"skillNo":147,"name":148,"nameZh":6,"description":149,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":150,"categories":151,"keywords":157,"publishedAt":38},"01M6WZKGQY812K6W0R89Y7HD9T","review","Run a principle-based code review on the current branch. Use when the user asks for a review, or at mandatory review checkpoints (after planning, after implementation before PR).","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fverona\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Freview\u002FSKILL.md",[152],{"categoryNo":153,"categoryName":154,"taxonomyType":155,"taxonomyTypeDesc":156},"01JBSEEDCAT000000000000007","代码审查","SCENARIO","使用场景",[148,158,159,160,161,162,104,21,118,163,123,31,164,165,166],"planning","branch","code review","pr","run","at","checkpoints","implementation","base"]