Generated banner for V Development
Generated logo for V Development

V Development

GitHubOfficialFirst committed by ulises-jeremiasDistributed by GitHub

  • Skill
  • Tool integration
  • Software development
  • MIT
  • No issues found

From the author

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.
— the description by ulises-jeremias

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides comprehensive guidance for developing applications in the V programming language. It acts as an expert advisor for setting up the V toolchain, managing project structures via v.mod files, and adhering to idiomatic V coding standards. The assistant is equipped to handle V-specific concepts such as Option/Result error handling, immutability, and proper module organization, ensuring that generated code is clean, idiomatic, and maintainable.

What it does

  • Provides commands for building, testing, formatting, and managing V projects.
  • Guides the creation and maintenance of v.mod files for structured projects.
  • Enforces idiomatic V patterns like Option/Result error handling and immutability.
  • Advises on standard library usage and VPM package management.
  • Ensures code quality through automated formatting and static analysis checks.
  • Translates programming intent into V-specific syntax rather than literal translations from other languages.

When to use it

  • When starting a new V project or setting up the V toolchain.
  • When writing or refactoring V source code to ensure it follows idiomatic conventions.
  • When managing project dependencies and module configurations.
  • When troubleshooting V-specific error handling or compiler-related issues.
  • When preparing a V application for testing or production builds.

Advantages

  • Promotes consistent and idiomatic V code structure.
  • Reduces errors by enforcing proper error propagation and handling patterns.
  • Simplifies project lifecycle management from setup to testing.
  • Prevents the use of deprecated modules by prioritizing modern standard library alternatives.

Usage examples

“How do I structure a new V project with a module manifest?”
The agent explains the v.mod file format and provides a template for the project root, including fields for name, description, and dependencies.
“How should I handle errors in a function that might fail?”
The agent provides an example using the !ReturnType syntax and an or { } block to handle errors, explaining why this is preferred over null checks.
“How do I run tests for my V project?”
The agent instructs the user to use the 'v test .' command and explains the convention of naming test files with the _test.v suffix.
“Can you help me add a third-party package to my project?”
The agent guides the user to search for the package using 'v search', install it, and update the dependencies list in the v.mod file.

Install

  1. Download the skill as a ZIP:

    https://mp-staging.autogineer.com/agent-skills/github/v-development/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip v-development.zip -d .agents/skills

Documentation by ulises-jeremias

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.

TaskCommand
Run a programv run main.v
Run a project folderv run . (compiles the folder's program files; *_test.v files are built separately via v test .)
Build a binaryv -o app .
Run testsv test . (runs *_test.v files)
Format codev fmt -w file.v
Static checksv vet .
Find a packagev search <term> (searches the VPM registry)
Install a packagev install <package> or v install --git <url>
Update packagesv 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.

Files

ATTRIBUTION.md

Attribution

This folder is an unmodified copy of the Agent Skill "v-development", distributed by AutoGineer (https://autogineer.com/agent-skills).

The skill's own files are unmodified copies. AutoGineer is not affiliated with or endorsed by the author or the publisher.

Files added by AutoGineer

  • ATTRIBUTION.md: this file, written by AutoGineer

  • LICENSE: copied from LICENSE

Requirements and compatibility

Written for: GitHub Copilot

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

First committed by
GitHub avatar of ulises-jeremiasulises-jeremias
Publisher
GitHub (Official)
Distributed by
GitHub
Source
github/awesome-copilot · skills/v-development · commit 797337f
Licence
MIT License (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced
Contributors
ulises-jeremias

AutoGineer is not affiliated with or endorsed by ulises-jeremias or GitHub.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download v-development.zip