Active on Alwaldend

Agents

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

Repository agent system

This project owns the repository-wide agent-system contract, its durable improvement goals, and reusable cross-repository skills. It does not centralize component facts or runtime state: each fact remains canonical at its natural owner, and system-wide views are derived projections.

Start here

Document	Purpose
Current state	Evidence-backed baseline and material seams
Architecture	Canonical abstraction tower, authorities, and invariants
Roadmap	Dependency-ordered future work and acceptance signals
Durable goals	Versioned attempts, evidence, and acceptance state
Root agent guide	Current repository-wide operating policy

The current-state document describes supported entry points and their evidence boundaries. Dated audits remain in the goal records. The architecture defines the intended composition contract; the roadmap does not claim that proposed interfaces already exist.

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.

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.

Hugo Landing

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

hugo_landing packages a reusable Hugo landing site. al_hugo_landing combines the shared source with one project README and emits a Hugo-ready source archive. al_hugo_landing_site also builds the rendered site.

Usage

al_hugo_landing(
    name = "landing_site",
    docs = "//projects/goal:docs",
    project = "goal",
    title = "Goal",
    docs_url = "https://alwaldend.com/docs/projects/goal/",
    repository_url = "https://github.com/alwaldend/src",
)

al_hugo_landing_site(
    name = "site",
    docs = "//projects/goal/docs:docs",
    project = "goal",
    title = "Goal",
    docs_url = "https://alwaldend.com/docs/projects/goal/",
    repository_url = "https://github.com/alwaldend/src",
)

Site collection

Each project owns its rendered landing target at //projects/<project>/landing:site. The shared macro remains in hugo_landing so the visual shell and README-to-site transformation stay reusable.

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.

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/.

Gazelle extension

Generation support is packaged separately so consumers of the documentation rule do not inherit Gazelle and Go dependencies. Add it as a development-only module dependency:

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_skill", 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_skill as a normal dependency and rules_skill_gazelle as a development dependency:

bazel_dep(name = "rules_skill", 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_skill 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_skill", version = "<VERSION>")

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

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

load("@rules_skill//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_skill repository, so Bzlmod repository mappings are respected.

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

bazel_dep(name = "rules_skill", 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 system

Start here

Al

Links

Bazel agent

Hugo Landing

Usage

Site collection

MCP Cordis

Rules binary toolchain

Rules Dnscontrol

Rules docs

Documentation rule

Gazelle extension

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