Active on Alwaldend

Agents

Mon, 01 Jan 0001 00:00:00 +0000

Repository agent skills

This project owns the reusable cross-repository agent skills. Maintained improvement work lives in this project’s OpenSpec workspace. It does not centralize component facts or runtime state: each fact remains canonical at its natural owner.

Start here

Document	Purpose
OpenSpec changes	Maintained work, acceptance, and preserved goal history
Root agent guide	Current repository-wide operating policy

Dated audits remain in migrated history.

Ownership boundaries

openspec/ owns agent-system requirements, changes, and evidence; the migration map locates historical records.
Other components own their specifications and changes under their own openspec/ directory. infra/src/openspec/ describes repository evolution.
skills/ owns reusable cross-product, repository-wide agent procedures and their development-time evaluations. A product-specific procedure belongs with its product; a procedure that no narrower project genuinely owns lives here rather than in a contrived local home.
Product-specific skills remain with their project at projects/<project>/skills/<name>. Do not split one skill across owners.

Skill packaging and discovery

Every canonical skill is packaged as a skill_library in its owning directory.

Agents

Mon, 01 Jan 0001 00:00:00 +0000

This project owns the reusable, cross-project agent skills used across this repository. Each skill is a procedure with its own scope and ownership rules, so an agent loads the guidance it needs for the task at hand instead of one large document.

Features

One skill per procedure, with an explicit description and scope
Discovery written into the agent skills directory from declared sources
Product-specific skills stay with their product; only genuinely shared ones live here

Al

Mon, 01 Jan 0001 00:00:00 +0000

AL is a command runner that prepares credentials and environment variables through plugins, runs your command, and cleans up afterward. Its Bazel rules package commands with their configuration and required plugins.

al tool runs tools declared in AL configuration from a source-keyed executable cache. With no --config, it uses the repository-root al.lua; explicit --config paths replace that default. Cache misses build the tool’s configured Bazel label and publish the selected executable under $XDG_CACHE_HOME/al/tools. AL_TOOL_CACHE or tool --cache-root PATH selects an alternate cache root.

Al

Mon, 01 Jan 0001 00:00:00 +0000

AL is a command runner that prepares credentials and environment variables through plugins, runs your command, and cleans up afterward. Its Bazel rules package commands together with the configuration and plugins they need.

Features

Plugin-based credential and environment preparation around any command
Bazel rules that package a command with its configuration and plugins
A source-keyed executable cache for running declared tools

Bazel agent

Mon, 01 Jan 0001 00:00:00 +0000

bazel_agent is the repository Bazel entry point for agents. It keeps the Bazel invocation behind a validated subcommand while consistently applying the agent configuration:

bazel_agent bazel test //path/to/package:all
    ->
bazel test --config=agent //path/to/package:all

bazel is the only Bazel entry point, and it is a validated subcommand. The runner accepts a known Bazel command after the bazel keyword, rejects arbitrary leading arguments, and places --config=agent after the command. Targets, command options, and arguments after the -- separator of a bazel run invocation pass through unchanged. Later options therefore retain Bazel’s normal precedence and can override settings supplied by the agent configuration. The runner resolves bazel from PATH and replaces itself with that process, so signals and the final exit status are not mediated by another wrapper process. Uses of the persistent Bazel server follow the host Codex network policy; the host-bot profile allows loopback so the client-server connection is not blocked.

Bazel agent

Mon, 01 Jan 0001 00:00:00 +0000

bazel_agent is the Bazel entry point for agents working in this repository. It keeps Bazel behind a validated subcommand while consistently applying the agent configuration.

Features

Validated bazel subcommand instead of arbitrary arguments
Applies the agent configuration in the required position
Preserves signals and exit status by replacing itself with the Bazel process
Read-only doctor diagnostics for runner and workspace state

F-Droid

Mon, 01 Jan 0001 00:00:00 +0000

Pinned fdroidserver environment for local F-Droid builds. The wrapper provisions an isolated Python virtualenv and delegates to fdroid. Use tools/gradle/gradle-wrapper for the Android app’s Gradle build; this tool only drives F-Droid metadata and local builds.

Usage

tools/fdroid/fdroid-wrapper <fdroid-subcommand>

Run from an F-Droid data directory containing config.yml and metadata/. Caches go under the workspace’s ignored out/ tree.

Gradle

Mon, 01 Jan 0001 00:00:00 +0000

Pinned Gradle 8.13 binary distribution from the primary publisher.

Maven Install Gradle Converter

Mon, 01 Jan 0001 00:00:00 +0000

Converts rules_jvm_external maven_install.json lock files into Gradle version catalogs and dependency verification metadata so Bazel-built Android apps can maintain the parallel Gradle build required for F-Droid.

Usage

Use the al_gradle_lock Starlark macro from main/bzl/gradle_lock.bzl in your app’s gradle/BUILD.bazel:

load("//tools/maven_install_gradle_converter:defs.bzl", "al_gradle_lock")

al_gradle_lock(
    name = "update",
    lock_file = "//projects/<app>:maven_lock.json",
    tool = "//tools/maven_install_gradle_converter/cmd/gradle_lock_gen",
)

Run bazel run :update_toml_write to regenerate the checked-in version catalog. The corresponding *_write_test target fails when it goes stale.

Gradle owns verification-metadata.xml because it must record the plugin classpath in addition to the Bazel lock. Regenerate it with:

MCP Cordis

Mon, 01 Jan 0001 00:00:00 +0000

mcp_cordis is a standalone stdio MCP server that mounts runtime JavaScript packages through Cordis. It is intentionally an MCP server, not a Codex plugin bundle.

Reusable definitions are ordinary ESM files in projects/mcp_cordis/plugins, listed by projects/mcp_cordis/cordis.yaml. Disposable definitions use the same layout under out/<task>/mcp_cordis/runs/<run>/. Each run writes a bounded manifest with explicit task, run, worker, information, budget, retention, lock, and cleanup fields. AGENT_TASK_ID, AGENT_RUN_ID, and AGENT_WORKER_ID may provide stable identities; the launcher otherwise creates process-scoped identities. Every package is addressed by both scope and name, so a scratch package never silently shadows a reusable package.

MCP Cordis

Mon, 01 Jan 0001 00:00:00 +0000

mcp_cordis is a standalone stdio MCP server that mounts workspace-local runtime packages behind one stable server interface, so packages can change without changing how a client connects.

Features

One stable stdio MCP server for workspace-local packages
Reusable and disposable package definitions in the same layout
Ordinary ESM files rather than a bespoke plugin format

OpenSpec

Mon, 01 Jan 0001 00:00:00 +0000

This package runs the upstream OpenSpec CLI with Bazel’s pinned Node toolchain. tools/package.json pins @fission-ai/openspec to 1.11.0; tools/pnpm-lock.yaml records the package integrities and transitive dependency versions. Package lifecycle scripts are disabled. No global npm installation is needed.

Each component owns an OpenSpec workspace at <owner>/openspec/. The repository’s evolution belongs to infra/src/openspec/, which is the default for the runnable target. Run commands from the enclosing repository root; OPENSPEC_PROJECT selects a different owner directory:

Rules binary toolchain

Mon, 01 Jan 0001 00:00:00 +0000

rules_binary_toolchain creates Bazel toolchains and runnable targets for packaged executable binaries. Archive entries can include runtime files, which the generated binary targets expose through Bazel runfiles.

Rules Dnscontrol

Mon, 01 Jan 0001 00:00:00 +0000

rules_dnscontrol packages a DNSControl JavaScript entrypoint together with its record configuration files and emits a generated requires.json manifest of relative paths matching the Bazel runfiles tree. Record symlinks retain a .json suffix so DNSControl parses them as JSON. Load the manifest with require() and load each listed path with another require() call; DNSControl’s JavaScript loader does not implement CommonJS module.exports.

Rules docs

Mon, 01 Jan 0001 00:00:00 +0000

rules_docs packages Markdown documentation under a common archive prefix.

Documentation rule

Add the module dependency:

bazel_dep(name = "rules_docs", version = "<VERSION>")

Then declare the package documentation. srcs defaults to glob(["*.md"]); visibility is optional.

load("@rules_docs//docs:defs.bzl", "docs_filegroup")

docs_filegroup(
    name = "docs",
    deps = ["child"],
)

Relative dependency names without a colon are normalized to the child package’s docs target. prefix defaults to the current package beneath content/docs/.

Files are packaged at their basename by default. When a package’s sources span subdirectories that hold identically named files, set preserve_paths = True so each source keeps its package-relative path and the destinations stay distinct.

Rules docs Gazelle

Mon, 01 Jan 0001 00:00:00 +0000

rules_docs_gazelle adds a docs_filegroup to existing Bazel packages that contain a README.md. The generated rule loads its macro from rules_docs.

Add rules_docs as a normal dependency and this generator as a development dependency:

bazel_dep(name = "rules_docs", version = "<VERSION>")
bazel_dep(
    name = "rules_docs_gazelle",
    version = "<VERSION>",
    dev_dependency = True,
)

Add the public language target to the repository’s custom Gazelle binary:

load("@gazelle//:def.bzl", "gazelle_binary")

gazelle_binary(
    name = "gazelle_binary",
    languages = [
        "@rules_docs_gazelle//gazelle",
    ],
)

The extension only operates in directories where both a BUILD file and a README.md already exist. Newly generated rules use glob(["*.md"]) and are visible only to their nearest ancestor Bazel package. Existing srcs, deps, visibility, and prefix attributes are preserved.

Rules Hugo

Mon, 01 Jan 0001 00:00:00 +0000

rules_hugo builds Hugo sites with a registered Hugo toolchain. It keeps the site archive in the target configuration and the Hugo binary in the execution configuration so site sources are not rebuilt for the execution platform.

al_hugo_site wraps a site source archive and its PostCSS tooling. al_hugo_run_binary builds the site with the registered Hugo toolchain and al_hugo_binary exposes a runnable Hugo command for a site. The optional al_hugo_worker rule runs the build through a persistent worker.

Rules Promptfoo

Mon, 01 Jan 0001 00:00:00 +0000

rules_promptfoo runs repository skills through a pinned Promptfoo CLI. It keeps dependency resolution reproducible in Bazel while deliberately running model calls only at test runtime.

Setup

Add the module and its skill-provider dependency:

bazel_dep(name = "rules_promptfoo", version = "<VERSION>")
bazel_dep(name = "rules_skills", version = "<VERSION>")

The development checkout uses sibling local_path_override declarations. Published releases must replace those local overrides with registry versions.

Evaluate a skill

load("@rules_promptfoo//promptfoo:defs.bzl", "promptfoo_test")

promptfoo_test(
    name = "answer_question_eval",
    config = "promptfooconfig.yaml",
    skills = ["//projects/agents/skills/answer-question:skill"],
    env_inherit = [
        "CODEX_HOME",
        "CODEX_PATH_OVERRIDE",
    ],
    reuse_codex_login = True,
)

The runner physically copies each selected SkillInfo.files_by_path bundle to an isolated Bazel test-temporary workspace/.agents/skills/<name>/ tree. Point the Codex SDK provider at the exported workspace and, when using a compatible host Codex executable, at the exported executable path:

Rules Promptfoo Gazelle

Mon, 01 Jan 0001 00:00:00 +0000

rules_promptfoo_gazelle generates required, offline promptfoo_validate_test targets for Promptfoo configurations below an evals/ directory. It never creates an evals subpackage and never generates live promptfoo_test targets.

Add rules_promptfoo as a normal dependency and this generator as a development dependency:

bazel_dep(name = "rules_promptfoo", version = "<VERSION>")
bazel_dep(
    name = "rules_promptfoo_gazelle",
    version = "<VERSION>",
    dev_dependency = True,
)

For one-pass skill package creation, also add rules_skills as a normal dependency and rules_skill_gazelle as a development dependency:

bazel_dep(name = "rules_skills", version = "<VERSION>")
bazel_dep(
    name = "rules_skill_gazelle",
    version = "<VERSION>",
    dev_dependency = True,
)

Add both public language targets to the repository’s custom Gazelle binary:

Rules skill

Mon, 01 Jan 0001 00:00:00 +0000

rules_skills packages all files belonging to a Codex skill and validates its instructions and optional OpenAI metadata with a hermetic Bazel aspect.

Getting started

Add the module and register the validation aspect:

bazel_dep(name = "rules_skills", version = "<VERSION>")

build --aspects @rules_skills//skill:defs.bzl%skill_validation_aspect
build --output_groups=+skill_validation

Declare one library in the skill’s named, non-root package:

load("@rules_skills//skill:defs.bzl", "skill_library")

skill_library(
    name = "skill",
    srcs = glob(
        ["**"],
        exclude = [
            "BUILD.bazel",
            "BUILD",
            "evals/**",
        ],
    ),
)

The package’s final path segment is the skill name, so a skill_library cannot be declared in a repository root package. Move a root-level skill into a named subpackage before declaring it.

Rules skill Gazelle

Mon, 01 Jan 0001 00:00:00 +0000

rules_skill_gazelle adds a skill_library(name = "skill") to each named subpackage that contains a SKILL.md. The generated rule loads its macro from the apparent rules_skills repository, so Bzlmod repository mappings are respected.

Add rules_skills as a normal dependency and this generator as a development dependency:

bazel_dep(name = "rules_skills", version = "<VERSION>")
bazel_dep(
    name = "rules_skill_gazelle",
    version = "<VERSION>",
    dev_dependency = True,
)

Add the public language target to the repository’s custom Gazelle binary:

load("@gazelle//:def.bzl", "gazelle_binary")

gazelle_binary(
    name = "gazelle_binary",
    languages = [
        "@rules_skill_gazelle//gazelle",
    ],
)

The generated source bundle is:

Rules template

Mon, 01 Jan 0001 00:00:00 +0000

rules_template provides Bazel rules and a Go command for rendering template files. A registered toolchain supplies the templating executable to build actions.

Getting started

MODULE.bazel:

bazel_dep(name = "rules_template", version = "<VERSION>")
register_toolchains("@rules_template//main/bzl:all")

BUILD.bazel:

rules_iso

Mon, 01 Jan 0001 00:00:00 +0000

Module extension that downloads ISO images with http_file and adds a runnable iso_flash target next to each image.

Active on Alwaldend

Agents

Repository agent skills

Start here

Ownership boundaries

Skill packaging and discovery

Agents

Features

Al

Al

Features

Bazel agent

Bazel agent

Features

F-Droid

Usage

Gradle

Links

Maven Install Gradle Converter

Usage

MCP Cordis

MCP Cordis

Features

OpenSpec

Rules binary toolchain

Rules Dnscontrol

Rules docs

Documentation rule

Rules docs Gazelle

Rules Hugo

Rules Promptfoo

Setup

Evaluate a skill

Rules Promptfoo Gazelle

Rules skill

Getting started

Rules skill Gazelle

Rules template

Getting started

rules_iso