agentleFS
MicrosoftKnown publishermicrosoft/verona/.agents/skills/add-test/SKILL.md

add-test

Skill3.7k starsChanged 3 months agoMITView on GitHub

Create a new Verona compiler test case. Use when the user wants to add a test, create a test, or scaffold a test for the compiler.

18 other projects use a version of this.

Trending

Quiet this year.about the whole repository

Dec 2025: 0 mentionsJan 2026: 0 mentionsFeb 2026: 0 mentionsMar 2026: 0 mentionsApr 2026: 0 mentionsMay 2026: 0 mentionsJun 2026: 0 mentionsJul 2026: 0 mentionsAug 2026: 0 mentionsSep 2026: 0 mentionsOct 2026: 0 mentionsNov 2026: 0 mentions
Dec 2025Jun 2026Nov 2026
Mentions a month of the microsoft/verona repository that our weekly crawl found. There is no adoption data for this file yet.

Most recently taken up by

Who's talking about microsoft/verona

The biggest 5 of 18 mentions linking to the repository that our crawl found. Each line is their own headline.

See all 18

Talked about on GitHub and Hacker News (18 times).

On GitHub · 12

7 more on GitHub

On Hacker News · 6

1 more on Hacker News

Used with

Projects with it also use review-pr and triage.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • DockerSkill

    review-pr

    Review one or more incoming Docker documentation pull requests as a maintainer. Independently validate technical claims, assess editorial fit and information architecture, choose a verdict, and draft exact inline or PR-wide feedback behind a confirmation gate. Use for requests such as "review PR 123", "is this PR correct?", "does this information belong here?", "validate this PR", or "help review backlog PRs". Do not use to maintain or fix a PR you own; use maintain-pr for that.

    Also in 3 projects that use this

  • Google CloudSkill

    triage

    Gather context on a change or bug and plan the implementation.

    Also in 3 projects that use this

The file

Show its rules and text

We split this skill into the rules it gives an agent

17 rules. 0 are common, 2 are distinctive, and 15 are very specific to this project.

  • 0

    Common

    Most of the 17 edited versions we read keep these.

  • 2

    Distinctive

    This author's own choices. Worth a look.

  • 15

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Create a new test case in testsuite/v/ for the Verona compiler.

    line 9
  2. Very specific:

    Create testsuite/v/$0/$0.v with appropriate Verona source code.

    line 20
  3. Very specific:

    Use only _builtin types

    line 26
  4. Very specific:

    Do NOT write use "_builtin" — it is always implicitly available

    line 27
  5. Very specific:

    No semicolons after closing braces of control flow (for, if, while)

    line 28
  6. Very specific:

    Don't use explicit type annotations on literals when inference can determine the type from context (write 0 not usize 0)

    line 30
  7. Very specific:

    Use Type(args) constructor sugar: callback(f) instead of callback::create(f)

    line 34
  8. Very specific:

    Use (obj.field)(args) for apply on field access, x.method for zero-arg methods

    line 35
  9. Very specific:

    Use the bitmask exit code pattern: var result = 0.

    line 38
  10. Distinctive:

    Write code that should fail to compile

    line 43
  11. Very specific:

    Keep the test under testsuite/v/compile_only/ so no run node is registered

    line 45
  12. Distinctive:

    If the test relies on init functions running, it MUST include at least one reachable FFI call from the same lib — init functions are only …

    line 49
  13. Very specific:

    Call FFI wrappers as ffi::func_name(args) for functions in _builtin/ffi/

    line 51
  14. Very specific:

    Run from the build directory:

    line 55
  15. Very specific:

    Check that the golden compile/ directory has the expected files:

    line 71
  16. Very specific:

    All 14 pass dumps: 00_parse.trieste through 13_typecheck.trieste

    line 72
  17. Very specific:

    If pass dumps are missing (e.g., only 0–5 present), it usually means a WF violation in a later pass.

    line 78

“Common” is measured: kept by at least 6 in 10 of the 17 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Add a Verona Compiler Test

Create a new test case in testsuite/v/ for the Verona compiler.

Arguments

  • $0 — the test name (required, snake_case)
  • $1 — if set to error, creates a compile-error test (exit code 1, no run/ directory). If set to ffi, creates a test that uses FFI builtins.

Steps

1. Create the source file

Create testsuite/v/$0/$0.v with appropriate Verona source code. For an expected compile error, use testsuite/v/compile_only/$0/$0.v instead.

Conventions:

  • Tests must be self-contained — no external dependencies (no use "https://...")
  • Use only _builtin types
  • Do NOT write use "_builtin" — it is always implicitly available
  • No semicolons after closing braces of control flow (for, if, while)
  • Semicolons are needed after statements and field definitions
  • Don't use explicit type annotations on literals when inference can determine the type from context (write 0 not usize 0)
  • Class definitions use bare names: myclass[T] { ... }
  • Fields need semicolons: val: T;
  • new uses new { field = val } (no class name after new)
  • Use Type(args) constructor sugar: callback(f) instead of callback::create(f)
  • Use (obj.field)(args) for apply on field access, x.method for zero-arg methods

For success tests (default):

  • Use the bitmask exit code pattern: var result = 0; then if cond { result = result + N; } with powers of 2
  • Exit code 0 means all checks passed
  • The main function must return i32

For compile-error tests ($1 = error):

  • Write code that should fail to compile
  • The test validates that the compiler correctly rejects invalid code
  • Keep the test under testsuite/v/compile_only/ so no run node is registered

For FFI tests ($1 = ffi):

  • Tests that use FFI builtins (:::name(...) syntax) or _builtin/ffi/ wrappers (e.g., ffi::add_external())
  • If the test relies on init functions running, it MUST include at least one reachable FFI call from the same lib — init functions are only reified when their lib's FFI symbols are called from reachable code
  • Declare FFI symbols in a use block with a Lib string
  • Call FFI wrappers as ffi::func_name(args) for functions in _builtin/ffi/

2. Generate golden files

Run from the build directory:

cd build
ninja install && ninja update-dump

This auto-generates the golden file directory structure:

  • testsuite/v/$0/$0/compile/ (or testsuite/v/compile_only/$0/$0/compile/ for errors) — contains exit_code.txt, stdout.txt, stderr.txt, pass dump files (00_parse.trieste through 13_typecheck.trieste), *_final.trieste, and .vbc file (success tests only)
  • testsuite/v/$0/$0/run/ — contains exit_code.txt, stdout.txt, stderr.txt (only for success tests that produce a .vbc)

3. Verify golden file completeness

Check that the golden compile/ directory has the expected files:

  • All 14 pass dumps: 00_parse.trieste through 13_typecheck.trieste
  • *_final.trieste
  • exit_code.txt (value 0 for success, 1 for error, no trailing newline)
  • stdout.txt and stderr.txt
  • *.vbc file (success tests only)

If pass dumps are missing (e.g., only 0–5 present), it usually means a WF violation in a later pass. Investigate with dist/vc/vc build ../testsuite/v/$0 --dump_passes=dump_$0 to see which pass fails.

For error tests: no run/ directory, no .vbc file, exit_code.txt = 1.

4. Verify the test passes

cd build && ctest --output-on-failure -R "^vbc/v/$0/$0" -j$(nproc)

This should show the test passing. If it fails, check the source code and re-run ninja update-dump. For an expected compile error, use "^vbc/v/compile_only/$0/$0" instead.

5. Report

State the test name, whether it's a success/error/ffi test, what it tests, and the expected exit code.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.