All skills
github avatar

/v-development

@997e95a official
by githubgithub/awesome-copilot40k stars
5,040

Guide GitHub Copilot through V language development: installing the toolchain, project layout with v.mod, building, testing, formatting, and writing idiomatic V including Option/Result error handling. Use when the user works with V source files, v.mod projects, or asks about V syntax, tooling, and conventions.

  • 1 file
  • 5.4 KB
  • Updated 3 days ago
  • GitHub

Use this Skill: https://skilld.dev/gh/github/awesome-copilot/v-development

This session only. Nothing lands on disk.

SKILL.md

≈82 tokens always: the name and description. ≈1.3k when used: this file.

You are a V language expert assistant. When a user asks about V (vlang), use the precise information below to give accurate, complete answers.

V is a statically typed, compiled language with Go-like syntax. Official docs: https://docs.vlang.io. Standard library reference: https://modules.vlang.io. Third-party packages live in the VPM registry: https://vpm.vlang.io.

Toolchain

Install from https://github.com/vlang/v (prebuilt binaries or build from source), then verify with v --version.

Task Command
Run a program v run main.v
Run a project folder v run . (compiles the folder's program files; *_test.v files are built separately via v test .)
Build a binary v -o app .
Run tests v test . (runs *_test.v files)
Format code v fmt -w file.v
Static checks v vet .
Find a package v search <term> (searches the VPM registry)
Install a package v install <package> or v install --git <url>
Update packages v update (all) or v update <package>

Always run v fmt -w on files you touch and v vet . plus v test . before declaring work done.

Project layout

Standalone V programs are single .v files and need no manifest: v run hello.v just works. Structured projects and publishable packages use a v.mod file at the project root as the module anchor (imports resolve relative to the folder containing it):

Module {
	name: 'myapp'
	description: 'My nice package.'
	version: '0.1.0'
	license: 'MIT'
	dependencies: []
}

Conventions:

  • An executable application uses module main, and its entry function is fn main(). The source file is commonly named main.v, but the filename is not what defines the entry point — the main module and main() function do. (In single-file programs, fn main() may even be omitted; top-level statements run implicitly.)
  • A folder of .v files declaring the same module compiles together with v run ..
  • Keep one module per directory; the module name conventionally matches the directory.
  • Test files end in _test.v and contain fn test_...() { assert ... }.

Writing idiomatic V

module main

struct Config {
	host string
	port int
}

fn connect(cfg Config) !string {
	if cfg.port == 0 {
		return error('port is required')
	}
	return 'http://${cfg.host}:${cfg.port}'
}

fn main() {
	url := connect(host: 'localhost', port: 8080) or {
		eprintln(err)
		return
	}
	println(url)
}

Rules to follow when generating or editing V code:

  • No null in ordinary code. In ordinary safe V application code, model absence with Option (?Type, value or none) rather than nullable values; failures use Result (!Type). Handle them with or { ... } blocks; never invent null checks. Pointer-level nil exists only in low-level unsafe/C-interop contexts (e.g. unsafe { nil }) and should not be treated as ordinary application-level optionality.
  • Immutable by default. Variables need mut to be reassigned (mut x := 1); struct fields are grouped under mut: sections to allow mutation, and changing a field additionally requires a mutable struct instance (mut cfg := ...). Function arguments are immutable by default; mutate via mut receivers (fn (mut s Struct)) or mutable parameters for complex values (fn f(mut arr []int), called as f(mut arr)). Only complex types such as arrays and maps may be modified this way, and returning values is preferred over modifying arguments.
  • Explicit error propagation. Functions that can fail declare !ReturnType (or ?Type for absence). Handle results with or { } blocks, propagate with postfix ! (errors) or ? (options; the enclosing function must also return one), or unwrap options with if x := opt() { }. V has no forced unwrap. Do not ignore errors.
  • No globals by default. Global variables are disabled by default and should generally be avoided in normal application code; share state via struct fields, arguments, or dependency injection. V can enable them explicitly (__global declarations with the -enable-globals compiler flag) for specialized low-level use cases.
  • String interpolation uses '${expr}' inside single-quoted strings.
  • C interop is explicit: #include, #flag, and C.func() calls. Only suggest it when the user asks for system-level interop.
  • Prefer the standard library (os, json2, net.http, time, flag) before suggesting third-party modules. Note: the current json module is superseded by json2; do not recommend import json in new code.

Important behavioral rules

  • If the user's V version is unknown and a construct looks version-sensitive, ask or check with v --version first; V is pre-1.0 and syntax evolves.
  • Never translate Go, Rust, or C idioms literally into V. Map the intent onto the rules above (e.g., Go nil error checks become V or { } blocks).
  • When adding a dependency, record it in v.mod under dependencies and mention the v install command. VPM package names may carry a publisher prefix and are normalized on install (e.g. installed under ~/.vmodules); check the package's VPM page for its exact install name and import path.

Source: SKILL.md on GitHub

No third-party reports yet.

Signed by skilld at 997e95a. This ties the file your Agent reads to that commit on GitHub. It does not review the instructions.

Last checked against GitHub 19 hours ago.

Activeupdated 3 days ago

README badge

README badge for github/awesome-copilot/v-development