GitHub - irahardianto/awesome-agv: Comprehensive sets of standards and practices designed to elevate the capabilities of AI coding agents.

Awesome AGV

A rugged, high-quality configuration suite for AI Agents.
Getting Started · View Rules & Skills · Request Feature ·

About Awesome AGV

Awesome AGV provides a comprehensive set of standards and practices designed to elevate the capabilities of AI coding agents. It provides a suite of strict rules distilled from software engineering best practices that ensure generated code is secure, defensible, and maintainable. It also provides specialized skills that agents load on demand.

Instead of just generating code that works, the rules and skills ensure agents generate code that survives.

⚠️ Opinionated by design. Awesome AGV ships with opinionated defaults for specific technology stacks. See Opinionated Technology Choices for details and how to customize.

While this configuration is originally designed for Antigravity, it is built on standard markdown-based context protocols that are easily portable to other AI coding tools. As a matter of fact, the original form Technical Constitution was first created for Gemini CLI. For example, the principles of the Rugged Software Constitution which is based on Rugged Software Manifesto are universal and will improve the output of any LLM-based coding assistant.

Key Features

📏 25 Rules — covering security, reliability, architecture, and maintainability. Distilled to project-specific decisions only — rules encode what overrides model defaults, not what models already know.
🛠️ 59 Skills — specialized capabilities loaded on demand: language idioms, debugging, design, testing, performance, CI/CD, and more.
🔄 11 Workflows — end-to-end development processes from research to ship, plus specialized testing pipelines.
🤖 21 Agent Personas — specialized sub-agents for multi-agent orchestration arranged in a 4-tier hierarchy.
🏗️ Three-Tier Loading System — always-on mandates + contextual principles + on-demand skills for zero-noise enforcement.

Equipped with Long Running Recursive Multi-Agent System That Gets The Work Done!

💡 Everything is modular. Rules, skills, agents, and workflows work independently — you don't need everything to benefit. Use only what you need, modify anything, or build your own. It's a toolkit, not a framework.

Getting Started

To equip your AI agent with these superpowers, follow these steps.

Prerequisites

An AI Coding Assistant (Antigravity, Roo Code, Cline, etc.)
A project where you want to enforce high standards.

Installation

Quick Install (recommended):

npx awesome-agv

This launches an interactive installer where you choose your installation mode:

Mode	Description
🚀 Default	Install everything — the full arsenal (recommended)
🎯 Curated	Pick your languages & frameworks. Core rules and skills always included.
⚙️ Advanced	Full granular control over every component.

In Curated and Advanced modes, the installer auto-detects your project's tech stack from files like go.mod, Cargo.toml, tsconfig.json, pubspec.yaml, etc. and pre-selects matching stacks.

CLI Flags:

Flag	Description
`--stacks <list>`	Comma-separated stacks to include (additive with existing config)
`--all`	Install everything (equivalent to Default mode)
`--force, -f`	Replace existing `.agents/` — re-prompts from scratch
`--help, -h`	Show help

Examples

# Interactive — choose your mode
npx awesome-agv

# Non-interactive: specific stacks, core always included
npx awesome-agv --stacks go,python

# Add React to existing installation (additive)
npx awesome-agv --stacks react

# Full install, no prompts
npx awesome-agv --all --force

# CI/CD: specific stacks, no prompts
npx awesome-agv --stacks typescript,vue --force

Manual Install:

Clone this repository or copy the .agents folder into the root of your project.
```
cp -r /path/to/awesome-agv/.agents ./your-project-root/
```
Ensure your AI agent is configured to read from the .agents directory (most well-known AI coding assistants adhere to the .agents convention by default, no action needed) or manually ingest the .agents/rules/** as part of its system prompt.

Usage

Once installed, the rules and skills in this repository become active for your agent.

Rule Architecture

The setup uses a three-tier loading system to minimize noise while maximizing coverage:

Tier	Type	Trigger	Purpose
1	Mandates	`always_on`	Non-negotiable constraints loaded in every session (security, logging, code completion, architecture).
2	Principles	`model_decision`	Contextual guidance activated only when working on relevant areas (e.g., database rules activate only when writing queries).
3	Skills	`paths:` or rule reference	Deep expertise loaded on demand — language idioms when touching source files, CI/CD when editing pipelines, testability patterns when architectural rules reference them.

Conflicts between rules are resolved by Rule Priority — security always wins.

Skill Loading Design

Skills use one of three loading mechanisms, chosen by type:

Mechanism	When used	Examples
`paths:` triggers	Language-specific idiom skills	`go-idioms` loads on `*/.go`; `vue-idioms` loads on `*/.vue`, `/store//*.ts`
`name:` + `description:` only	Cross-cutting skills loaded via rule reference	`testability-patterns` (referenced from `architectural-pattern.md`); `logging-implementation` (referenced from `logging-and-observability-mandate.md`)
Both `paths:` + `name:`/`description:`	Infrastructure/domain skills	`ci-cd` (Dockerfiles, CI configs); `feature-flags` (feature flag files)

Design invariant: Cross-cutting skills that apply to all languages (testability, logging) are never loaded via language-specific paths: triggers. They are always referenced from always-on rules so they load regardless of language.

Rule Dependencies

The rules are interconnected to provide comprehensive coverage. You can explore these relationships using the Interactive Rule Dependency Graph, or view the static diagram below.

View Dependency Graph (Mermaid)

graph TD
  accessibility_principles["accessibility-principles.md"]
  api_design_principles["api-design-principles.md"]
  architectural_pattern["architectural-pattern.md"]
  code_idioms_and_conventions["code-idioms-and-conventions.md"]
  code_organization_principles["code-organization-principles.md"]
  command_execution_principles["command-execution-principles.md"]
  concurrency_and_threading_principles["concurrency-and-threading-principles.md"]
  configuration_management_principles["configuration-management-principles.md"]
  core_design_principles["core-design-principles.md"]
  data_serialization_and_interchange_principles["data-serialization-and-interchange-principles.md"]
  database_design_principles["database-design-principles.md"]
  dependency_management_principles["dependency-management-principles.md"]
  documentation_principles["documentation-principles.md"]
  error_handling_principles["error-handling-principles.md"]
  git_workflow_principles["git-workflow-principles.md"]
  logging_and_observability_mandate["logging-and-observability-mandate.md"]
  monitoring_and_alerting_principles["monitoring-and-alerting-principles.md"]
  performance_optimization_principles["performance-optimization-principles.md"]
  project_structure["project-structure.md"]
  resources_and_memory_management_principles["resources-and-memory-management-principles.md"]
  rugged_software_constitution["rugged-software-constitution.md"]
  rule_priority["rule-priority.md"]
  security_mandate["security-mandate.md"]
  security_principles["security-principles.md"]
  testing_strategy["testing-strategy.md"]
  accessibility_principles --> core_design_principles
  accessibility_principles --> security_principles
  accessibility_principles --> testing_strategy
  api_design_principles --> data_serialization_and_interchange_principles
  api_design_principles --> error_handling_principles
  api_design_principles --> logging_and_observability_mandate
  api_design_principles --> security_mandate
  api_design_principles --> security_principles
  architectural_pattern --> code_organization_principles
  architectural_pattern --> core_design_principles
  architectural_pattern --> database_design_principles
  architectural_pattern --> project_structure
  architectural_pattern --> testing_strategy
  code_idioms_and_conventions --> rugged_software_constitution
  code_idioms_and_conventions --> core_design_principles
  code_organization_principles --> architectural_pattern
  code_organization_principles --> core_design_principles
  code_organization_principles --> project_structure
  command_execution_principles --> security_mandate
  command_execution_principles --> security_principles
  core_design_principles --> concurrency_and_threading_principles
  core_design_principles --> performance_optimization_principles
  concurrency_and_threading_principles --> error_handling_principles
  concurrency_and_threading_principles --> resources_and_memory_management_principles
  concurrency_and_threading_principles --> testing_strategy
  configuration_management_principles --> security_mandate
  configuration_management_principles --> security_principles
  core_design_principles --> accessibility_principles
  core_design_principles --> architectural_pattern
  core_design_principles --> code_organization_principles
  core_design_principles --> documentation_principles
  data_serialization_and_interchange_principles --> api_design_principles
  data_serialization_and_interchange_principles --> error_handling_principles
  data_serialization_and_interchange_principles --> security_mandate
  data_serialization_and_interchange_principles --> security_principles
  database_design_principles --> error_handling_principles
  database_design_principles --> performance_optimization_principles
  database_design_principles --> security_principles
  dependency_management_principles --> security_mandate
  dependency_management_principles --> security_principles
  documentation_principles --> code_organization_principles
  documentation_principles --> core_design_principles
  error_handling_principles --> api_design_principles
  error_handling_principles --> core_design_principles
  error_handling_principles --> logging_and_observability_mandate
  error_handling_principles --> security_mandate
  error_handling_principles --> security_principles
  error_handling_principles --> testing_strategy
  git_workflow_principles --> code_idioms_and_conventions
  git_workflow_principles --> security_mandate
  git_workflow_principles --> testing_strategy
  logging_and_observability_mandate --> api_design_principles
  logging_and_observability_mandate --> error_handling_principles
  logging_and_observability_mandate --> monitoring_and_alerting_principles
  monitoring_and_alerting_principles --> error_handling_principles
  monitoring_and_alerting_principles --> logging_and_observability_mandate
  monitoring_and_alerting_principles --> resources_and_memory_management_principles
  performance_optimization_principles --> core_design_principles
  performance_optimization_principles --> concurrency_and_threading_principles
  performance_optimization_principles --> resources_and_memory_management_principles
  project_structure --> architectural_pattern
  project_structure --> code_organization_principles
  resources_and_memory_management_principles --> core_design_principles
  resources_and_memory_management_principles --> concurrency_and_threading_principles
  resources_and_memory_management_principles --> error_handling_principles
  rugged_software_constitution --> architectural_pattern
  rugged_software_constitution --> error_handling_principles
  rugged_software_constitution --> logging_and_observability_mandate
  rugged_software_constitution --> security_mandate
  rule_priority --> architectural_pattern
  rule_priority --> code_idioms_and_conventions
  rule_priority --> logging_and_observability_mandate
  rule_priority --> rugged_software_constitution
  rule_priority --> security_mandate
  security_mandate --> security_principles
  security_principles --> api_design_principles
  security_principles --> command_execution_principles
  security_principles --> configuration_management_principles
  security_principles --> error_handling_principles
  security_principles --> logging_and_observability_mandate
  testing_strategy --> architectural_pattern
  testing_strategy --> error_handling_principles
  testing_strategy --> project_structure

Comprehensive Rule Suite (25)

The rules encode project-specific decisions that override model defaults — not general knowledge the model already knows. Every line of a rule answers: "What would this model get wrong without this instruction?"

🔒 Always-On Mandates (10)

Loaded in every session — non-negotiable constraints that fire regardless of what you're working on.

Rule	What it enforces
Rugged Software Constitution	Hostile-environment posture: refuse insecure patterns even if asked, proactively add validation, fail securely
Security Mandate	Deny by default, trust no input, fail closed — security always wins over convenience
Rule Priority	Conflict resolution order: Security → Rugged → Completion/Logging → Testability → Idioms → YAGNI
Logging & Observability Mandate	Every operation entry point must log start/success/failure with correlationId — no exceptions
Architectural Pattern	I/O isolation, pure business logic, dependency inversion — testability-first design
Code Idioms & Conventions	Language-to-skill routing table + completion workflow: generate → validate → remediate → verify → deliver
Code Organization Principles	Feature-based vertical slices, public API boundaries, no circular dependencies
Core Design Principles	Maintainability > UX; Composition > inheritance; Rule of Three for DRY; profile before parallelizing
Project Structure	Single source of truth for directory layout — organize by feature, not by layer
Documentation Principles	Code shows WHAT; comments explain WHY; function docs for API contracts

🎯 Contextual Principles (15)

Activated by the model only when relevant — zero overhead when not applicable.

Security Principles: Auth, authorization, input validation, cryptographic operations
Error Handling Principles: Error types, recovery strategies, resource cleanup
API Design Principles: REST/HTTP endpoints, handlers, response formatting
Database Design Principles: Schemas, migrations, queries, transaction boundaries
Testing Strategy: Pyramid ratios, naming, co-location, test doubles
Concurrency & Threading Principles: Race prevention, deadlock avoidance, message passing
Performance Optimization Principles: Profile-first, bottleneck identification
Configuration Management Principles: Environment variables, secrets, settings hierarchy
Monitoring & Alerting Principles: Health checks, metrics, SLIs/SLOs
Resource Management Principles: Files, connections, locks — always clean up
Data Serialization Principles: JSON, Protobuf, validation at boundaries
Dependency Management Principles: Packages, pinning, license compliance
Command Execution Principles: Shell commands, injection prevention, non-interactive flags
Accessibility Principles: WCAG 2.1 AA, semantic HTML, keyboard navigation
Git Workflow Principles: Conventional commits, branch naming, PR hygiene

Specialized Skills (59)

Skills are deep expertise modules loaded on demand — agents only pay the token cost when the skill is relevant.

🔧 Core Engineering Skills

Debugging Protocol: Systematic hypothesis-driven approach to solving errors
Sequential Thinking: Dynamic, reflective problem-solving through iterative thought chains, adapted from Sequential Thinking MCP Server
Code Review: Structured code review protocol against the full rule set
Guardrails: Pre-flight checklist and post-implementation self-review
ADR: Architecture Decision Records — document significant decisions with context and trade-offs
Performance Optimization: Profile-driven optimization (pprof, Lighthouse, bundle analysis)
Refactoring Patterns: Code smell taxonomy, safe transformation techniques, behavior preservation
Research Methodology: Structured research protocol for technologies and patterns
Git Commit Integrity: Independent per-commit build/lint/test verification, pre-commit hook isolation, and safe diff splitting

🏛️ Architecture & Infrastructure Skills

Structured Spec: Machine-parseable specification standard (PRD, SDD, TSD, BDD, ADR, Plan) with requirement-to-contract-to-test traceability and multi-agent slicing
Testability Patterns: I/O isolation, pure logic, dependency direction — code examples across Go, TypeScript, Python, Rust, Dart. Loaded via reference from architectural-pattern.md.
Logging Implementation: Structured logging patterns, log levels, per-language libraries (Go slog, pino, structlog), PII scrubbing. Loaded via reference from logging-and-observability-mandate.md.
CI/CD: Pipeline design, multi-stage Docker builds, image scanning, SBOM attestation, environment promotion (Level 0–2)
CI/CD GitOps & Kubernetes: ArgoCD, Kubernetes deployment patterns — bundled with ci-cd
Feature Flags: Release flags, kill switches, experiment flags, lifecycle rules — PRD-gated, loaded only when required
Code Audit: Reference material for the audit workflow — dimension scope cards and final report templates. Loaded via reference from audit.md workflow.
Security Audit: Reference material for the security audit workflow — dimension scope cards and final report templates. Loaded via reference from security-audit.md workflow.

🧪 Testing Skills

Testing Strategy: Test doubles strategy, integration test infrastructure (Testcontainers, Firebase emulator), naming conventions, test organization patterns
Mobile Testing: Mobile E2E testing patterns — Flutter integration_test, Patrol, Maestro, golden testing, device matrix, and test data management

🎨 Design & UI Skills

Frontend Design: Production-grade frontend interfaces, bold aesthetics, typography, motion
Mobile Design: Platform-native mobile interfaces for Flutter and React Native

🔀 Multi-Agent Orchestration Skills

Parallel Dispatch: MECE task decomposition, scope sizing, file ownership enforcement, DAG-based execution, and safe merge protocol for intra-domain parallel dispatch.
Agent Protocols: Shared behavioral protocols for all agents: recursive nesting, pre-implementation restatement, agent definition cascade, parallel dispatch format, and completion reporting with reply-to address routing.

🌐 Language & Framework Idioms (26)

Language-specific patterns, tooling, project layout, and quality commands. Each skill auto-loads via paths: triggers when the agent touches files in that language.

Core stacks (with bundled project structure references):

Skill	Ecosystem	Auto-loads on
Go Idioms + layout	Go stdlib, error wrapping, table-driven tests, gofumpt	`*/.go`, `**/go.mod`
TypeScript Idioms + layout	Strict mode, type narrowing, Zod, vitest	`*/.ts`, `*/.tsx`
Vue Idioms + layout	Vue 3 Composition API, Pinia (Setup Store), composables	`*/.vue`, `/store//.ts`, `/.store.ts`
Flutter Idioms + layout	Riverpod 3, freezed, go_router, const widgets	`*/.dart`, `/pubspec.yaml`, `/analysis_options.yaml`
Rust Idioms + layout	Ownership, tokio, thiserror/anyhow, clippy pedantic	`*/.rs`, `**/Cargo.toml`
Python Idioms + layout	Type hints, Protocols, ruff, mypy strict, pytest	`*/.py`, `**/pyproject.toml`

Community language skills:

Skill	Ecosystem
Angular + layout	Angular components, signals, DI, RxJS
Axum	Axum HTTP routing, extractors, Tower middleware
C++	Modern C++ (RAII, smart pointers, CMake)
C#	.NET, async/await, LINQ, records
Django	Django ORM, views, middleware
.NET	ASP.NET Core, Entity Framework
Elixir	OTP, GenServer, supervision trees
Hono + layout	Hono routing, middleware, Zod validation, RPC
Java	Streams, records, sealed classes
JavaScript	ES2024+, async patterns, ESM
Kotlin	Coroutines, sealed classes, Android
Laravel	Eloquent, middleware, queues
Next.js + layout	App Router, RSC, ISR
PHP	PHP 8+, type declarations, Composer
Rails	ActiveRecord, conventions, RSpec
React + layout	Hooks, Suspense, Server Components
Ruby	Blocks, modules, metaprogramming
Spring Boot	Spring DI, JPA, WebFlux
SQL	Query optimization, indexes, migrations
Swift	SwiftUI, Combine, async/await

Database-specific skills:

Skill	Coverage
PostgreSQL Idioms	Query performance & indexing, connection pooling, RLS & security, schema design, concurrency & locking, data access patterns, monitoring, JSONB & full-text search

🏢 Domain Skills

API Documentation: OpenAPI 3.1 specs, request/response examples, versioning
Browser Automation: Playwright MCP-first automation for E2E testing, UI review, and Playwright MCP interactive development
Chaos Testing: Controlled failure injection and resilience verification
CLI Development: CLI tool design, argument parsing, and distribution
Data Engineering: ETL/ELT patterns, data quality, and orchestration
Embedded Systems: Real-time patterns, RTOS, and hardware abstraction
Incident Response: Severity classification, triage, diagnosis, and blameless postmortem
ML Engineering: ML pipelines, feature engineering, model serving, and MLOps
Payment Integration: PCI DSS compliance, tokenization, and webhook reliability
Supply Chain Security: SBOM generation, CVE scanning, and license compliance

Agent Personas (21)

Agent personas are specialized sub-agents designed for multi-agent orchestration. The system uses a 4-layer pipeline architecture with an overseer/conductor command structure. Each agent has an exclusive domain, clear boundaries, and never crosses into another agent's territory — enforcing MECE at the architecture level.

Layers

Layer	Agents	Purpose
L0 Supervisor	`overseer`	Pipeline supervisor: spawns conductor, monitors progress, dispatches red team, owns cleanup
L1 Orchestration	`conductor`	Build orchestrator: tier assessment, scope decomposition, dispatches builders and reviewers
Build	`tech-lead`, `backend-engineer`, `frontend-engineer`, `mobile-engineer`, `database-expert`, `devops-engineer`, `test-automation-engineer`, `performance-engineer`, `refactoring-specialist`	Implementation — tech-lead coordinates multi-domain scope cards, specialists handle single-domain tasks
Review	`reviewer`	Independent quality gate: integrity enforcement, code quality, spec compliance — sole PASS/FAIL authority
Red Team	`red-team-lead`, `delivery-validator`, `integration-prober`	Adversarial validation: smoke testing, environment bootstrap, service connectivity probing
Research	`scout`	Codebase exploration, pattern discovery, technology research
Design	`architect` + optional `ux-craftsman`, `database-expert`, `security-engineer`	System design, ADRs, API contracts
Support	`technical-writer`, `incident-responder`	Documentation and incident response

All code-writing agents are hardened with always-on mandates (security-mandate, rugged-software-constitution, code-idioms-and-conventions, logging-and-observability-mandate) plus the guardrails skill for pre-flight and post-implementation safety checks.

See the workflow-team workflow for the full dispatch protocol, including adaptive tier routing, recursive parallel dispatch with MECE file ownership, and DAG-based execution ordering.

Development Workflows (11)

The setup includes opinionated, end-to-end workflows that chain rules and skills into structured development processes.

🏭 Feature Workflow — Single Agent (`/workflow-solo`)

A lean, single-agent pipeline with adaptive complexity routing. The agent assesses task scope, risk, and knowledge to route into one of three tracks:

Track	When	Pipeline
Light	All dimensions Low (1–3 files, no breaking changes)	IMPLEMENT → VERIFY → COMMIT
Standard	Any dimension Medium/High	RESEARCH → IMPLEMENT → VERIFY → COMMIT
Thorough	Multiple dimensions High	RESEARCH → IMPLEMENT → VERIFY (full) → COMMIT

Each phase references existing rules and skills rather than restating content — the workflow is 133 lines total. Subagent spawning is allowed but not prescribed.

🤖 Multi-Agent Orchestration (`/workflow-team`)

The multi-agent pipeline boots an @overseer supervisor that spawns a @conductor for build orchestration. The conductor assesses task complexity using a 3-signal check (scope, risk, knowledge) and routes into adaptive tiers:

Tier	When	Pipeline
Tier 1	Single-domain, low risk	Builder → Reviewer
Tier 2	Multi-domain or medium risk	Scout → Design → Tech-Lead + Builders → Reviewer → Red Team
Tier 3	Cross-cutting, high risk	Scout → Design → Multiple Tech-Leads (parallel) → Reviewer → Red Team

Includes system prompt templates for all agent roles, MECE file ownership for parallel execution, and resilience protocols (conductor succession, overseer role identity lock, cleanup fallback).

🧪 Testing Workflows

Specialized workflows for retroactive testing improvements on existing codebases:

Workflow	Pipeline	Purpose
`/test-unit`	ANALYZE → PRIORITIZE → REFACTOR → TEST → VERIFY	Coverage-gap-first unit test improvement — analyze gaps, prioritize by business risk and git churn, refactor for testability if needed
`/test-integration`	AUDIT → INFRASTRUCTURE → TEST → VERIFY	Adapter audit — scan for I/O boundaries, set up Testcontainers/mocks, write contract-compliance tests
`/test-e2e`	PLAN → SETUP → AUTHOR → EXECUTE → REPORT	Platform-adaptive E2E — web (Playwright) + mobile (Flutter/Patrol/Maestro), journey-based with evidence capture
`/test-scenarios`	INPUT → INVENTORY → ANALYZE → DERIVE → EXPAND → ORGANIZE → OUTPUT → HUMAN REVIEW	Hybrid structured derivation + mutation-informed expansion — generates prioritized test scenarios that feed into the above workflows

🔧 Specialized Workflows

Workflow	When to Use
`/bugfix`	Bug fixes — from hotfixes to complex debugging sessions
`/refactor`	Safely restructure code while preserving behavior
`/audit`	Code review and quality inspection (no new features)
`/security-audit`	Structured security review using parallel subagents
`/perf-optimize`	Profile-driven performance optimization

Directory Structure

.agents/
├── agents/            # 21 agent personas (multi-agent orchestration)
│   ├── overseer.md              # L0 Pipeline Supervisor
│   ├── conductor.md             # L1 Build Orchestrator
│   ├── tech-lead.md             # Scope card owner + builder dispatcher
│   ├── reviewer.md              # Independent quality gate (PASS/FAIL)
│   ├── red-team-lead.md         # Adversarial validation orchestrator
│   ├── architect.md
│   ├── backend-engineer.md
│   └── ...            # 14 more specialized agents
├── rules/             # 25 rules: 10 always-on mandates + 15 contextual principles
│   │                  # Each rule = project-specific decisions only (not model knowledge)
│   ├── rugged-software-constitution.md   # always_on: hostile-environment posture
│   ├── security-mandate.md               # always_on: deny by default
│   ├── logging-and-observability-mandate.md  # always_on: all ops must log
│   ├── architectural-pattern.md          # always_on: I/O isolation, testability
│   ├── rule-priority.md                  # always_on: conflict resolution
│   └── ...            # 5 more always-on + 15 contextual principles
├── skills/            # 59 specialized skills — loaded on demand, not always
│   ├── code-audit/              # reference-loaded from audit workflow
│   ├── security-audit/          # reference-loaded from security-audit workflow
│   ├── go-idioms/               # paths: **/*.go — includes references/project-structure.md
│   ├── typescript-idioms/       # paths: **/*.ts, **/*.tsx
│   ├── vue-idioms/              # paths: **/*.vue, **/store/**/*.ts, **/*.store.ts
│   ├── flutter-idioms/          # paths: **/*.dart, **/analysis_options.yaml
│   ├── rust-idioms/             # paths: **/*.rs, **/Cargo.toml
│   ├── python-idioms/           # paths: **/*.py, **/pyproject.toml
│   ├── testability-patterns/    # reference-loaded from architectural-pattern.md
│   ├── logging-implementation/  # reference-loaded from logging-and-observability-mandate.md
│   ├── testing-strategy/        # test doubles, naming, infrastructure patterns
│   ├── mobile-testing/          # Flutter integration_test, Patrol, Maestro, golden testing
│   │   └── references/          # flutter.md, maestro.md — framework-specific details
│   ├── ci-cd/                   # paths: Dockerfile, .github/workflows/*, Jenkinsfile, ...
│   ├── feature-flags/           # paths: feature*flag*, feature*toggle* (PRD-gated)
│   ├── debugging-protocol/      # Core engineering (reference-loaded)
│   ├── code-review/
│   ├── guardrails/
│   ├── postgres-idioms/         # PostgreSQL best practices — query, indexing, RLS, connection mgmt
│   ├── parallel-dispatch/       # Multi-agent orchestration — consolidated safety invariants
│   ├── angular-idioms/          # Community language skills (18 ecosystems)
│   ├── react-idioms/
│   ├── java-idioms/
│   ├── incident-response/       # Domain skills
│   └── ...
└── workflows/         # 11 development workflows
    ├── workflow-solo.md          # Single-agent: lean adaptive pipeline
    ├── workflow-team.md          # Multi-agent: hierarchical orchestration
    ├── test-unit.md              # Testing: unit test coverage improvement
    ├── test-integration.md       # Testing: integration test coverage
    ├── test-e2e.md               # Testing: E2E mobile & web
    ├── test-scenarios.md         # Testing: scenario generator
    ├── bugfix.md                 # Standalone: bug fixes
    ├── refactor.md               # Standalone: code restructuring
    ├── audit.md                  # Standalone: code review
    ├── security-audit.md         # Standalone: structured security review
    └── perf-optimize.md          # Standalone: performance tuning

Roadmap

Opinionated Technology Choices

Awesome AGV ships with opinionated defaults for specific technology stacks. Each stack has a dedicated idiom skill that auto-loads when touching files in that language, providing patterns, tooling, project layout, and quality commands.

Stack	Default Choice	Idiom Skill
Backend	Go — vanilla stdlib, minimal deps	go-idioms
Frontend	TypeScript + Vue 3 — Composition API, Pinia, Vitest	typescript-idioms + vue-idioms
Mobile	Flutter + Riverpod 3 — freezed models, go_router	flutter-idioms
Systems	Rust — tokio, thiserror/anyhow, clippy pedantic	rust-idioms
Scripting/AI	Python — ruff, mypy strict, pytest, Pydantic	python-idioms

Using a different framework? The idiom skills are modular — swap or edit them to match your stack. Community language skills are available for Angular, React, Next.js, Hono, Axum, Spring Boot, Django, Laravel, Rails, and more. See the Adapting guide for which files to change.

Project Adaptation Guide

This setup supports different project structures:

Project Type	Adaptation
Monorepo (default)	Use as-is
Single backend	Remove frontend workflows, keep backend idiom skill
Single frontend	Remove backend workflows, keep frontend idiom skills
Microservices	Adapt `project-structure.md` per service, add service mesh rules
Mobile (Flutter/RN)	Use flutter-idioms or react-idioms skill

To adapt: Edit project-structure.md and the relevant idiom skill's references/project-structure.md to match your project layout.

Contributing

Contributions are what make the open source community such an amazing place to learn, inspire, and create. Any contributions you make are greatly appreciated.

Fork the Project
Create your Feature Branch (git checkout -b feature/AmazingFeature)
Commit your Changes (git commit -m 'Add some AmazingFeature')
Push to the Branch (git push origin feature/AmazingFeature)
Open a Pull Request

License

Distributed under the MIT License. See the LICENSE file for details.

Built with ❤️ for the Developer Community

Name		Name	Last commit message	Last commit date
.agents		.agents
.github/workflows		.github/workflows
cli		cli
github-pages		github-pages
scripts		scripts
.gitignore		.gitignore
LICENSE		LICENSE
README.md		README.md
agv.config.json		agv.config.json
banner.png		banner.png
rmas-design.png		rmas-design.png

Latest commit

History

Folders and files

Repository files navigation