[update] AGENTS file to no longer include sections now broken off into skills

Author: vmarcella

AGENTS.md

@@ -156,185 +156,31 @@ Pull requests MUST:
   options exposed by `lambda-sh/lambda.sh` for consistent builds.
 - Store large assets through `git-lfs` to keep history lean.
 
-## Documentation Metadata & Authoring
-
-Long-lived docs MUST include a metadata header with YAML front matter. Apply
-this to roadmaps, specifications, guides, tutorials, and similar durable
-documents.
-
-Metadata schema:
-
-```yaml
----
-title: "<short, descriptive title>"
-document_id: "<stable-id, e.g., game-roadmap-YYYY-MM-DD>"
-status: "draft"              # draft | living | frozen | deprecated
-created: "<UTC ISO-8601>"    # e.g., 2025-09-24T00:00:00Z
-last_updated: "<UTC ISO-8601>"
-version: "0.x.y"
-engine_workspace_version: "2023.1.30"
-wgpu_version: "26.0.1"
-shader_backend_default: "naga"
-winit_version: "0.29.10"
-repo_commit: "<git sha at update>"
-owners: ["lambda-sh"]
-reviewers: ["engine", "rendering"]
-tags: ["roadmap", "games", "2d", "3d", "desktop"]
----
-```
-
-### Authoring Guidance
-
-- Keep sections short and scannable.
-- Prefer bullets and concise code snippets.
-- Include ASCII diagrams where helpful.
-- Do not commit embedded binaries to the repository.
-- When proposing APIs, mirror existing builder or command patterns and show
-  concise Rust sketches.
-- Update `last_updated`, `version`, and `repo_commit` when making material
-  changes.
-- Append a `Changelog` section for material updates.
-- Prefer ISO-8601 UTC timestamps.
-- Use semantic versioning for the document `version`.
-- Create new specifications by copying `docs/specs/_spec-template.md` and
-  completing the placeholders. Do not start from an existing specification.
-- Always include a table of contents for specifications and tutorials.
-
-### Documentation Tone & Style
-
-All specifications and long-lived docs MUST adopt a professional and precise
-tone.
-
-#### Voice & Register
-
-- Use clear, direct, neutral language.
-- Prefer active voice and present tense.
-- Avoid conversational phrasing, rhetorical questions, and tutorial chatter.
-- Avoid first-person pronouns such as `I` and `we`.
-- Do not address the reader directly unless the context requires an
-  instruction. Prefer terms such as "the API", "the engine", or
-  "this document".
-- Do not include meta commentary, such as "this aims to" or "we want to".
-  State requirements and behavior directly.
-
-#### Normative Language
-
-- Use RFC-2119 keywords where appropriate: MUST, SHOULD, MAY, MUST NOT, and
-  SHOULD NOT.
-- When explaining decisions, use a short `Rationale` sub-bullet instead of a
-  "Why" paragraph.
-
-#### Terminology & Consistency
-
-- Define acronyms on first use in each document, such as
-  "uniform buffer object (UBO)", then use the acronym consistently.
-- Acronyms are permitted in documentation but not in code identifiers.
-- Use consistent technical terms such as `GPU`, `CPU`, `wgpu`, "bind group",
-  and "pipeline layout".
-- Refer to code identifiers with backticks, such as `BindGroupLayout`.
-- Prefer American English spelling, such as "behavior" and "color".
-- When describing implementation areas, refer to crates by name, such as
-  `lambda-rs` and `lambda-rs-platform`, rather than generic labels like
-  "engine layer" or "platform layer".
-
-#### Structure & Formatting
-
-- Keep headings stable and diff-friendly.
-- Avoid frequent heading renames.
-- Keep bullets to one line when practical.
-- Avoid filler sentences.
-- Include only minimal, buildable code snippets.
-- Match repository style in all examples.
-- Avoid marketing claims, subjective adjectives, and speculation.
-
-#### Metadata & Changelog Discipline
-
-- Update `last_updated`, bump `version` semantically, and set `repo_commit` to
-  the current `HEAD` when making substantive edits.
-- Changelog entries MUST use an ISO-8601 date, the document version, and a
-  concise imperative summary of the content change.
-
-#### Prohibitions
-
-- Do not use emojis, exclamation marks for emphasis, or informal asides.
-- Do not reference AI authorship or generation.
-- Do not make unscoped promises such as "we will add" without a linked
-  tracking issue.
-- Do not add commentary in specifications or tutorials about what must or
-  should be done because of this `AGENTS.md` file.
-
-## Tutorials Authoring
-
-Tutorials are step-by-step instructional documents that teach a discrete task
-using the engine. They MUST follow the same metadata schema and tone rules as
-other docs, with the additions below.
-
-### Location & Naming
-
-- Place tutorials under `docs/tutorials/`.
-- Use kebab-case filenames, such as `uniform-buffers.md`.
-- Include the `tutorial` tag in the metadata `tags` array.
-
-### Tone & Voice
-
-- Follow the Documentation Tone & Style rules while using a book-like
-  instructional narrative.
-- Explain intent before each code block, including what is about to be done
-  and why it is necessary.
-- After each code block, include a short narrative paragraph describing the
-  outcome and what was achieved.
-- Include a final `Conclusion` section summarizing what was built and what the
-  tutorial accomplished.
-- Imperative instructions are preferred. Limited second-person language MAY be
-  used when it materially improves clarity.
-- Define acronyms on first use, such as "uniform buffer object (UBO)", and
-  use them consistently.
-
-### Standard Section Structure
-
-- `Goals`: clearly state what will be built and what will be learned.
-- `Overview`: provide a short paragraph defining the task and constraints.
-- `Prerequisites`: list version assumptions, build commands, and paths to
-  examples.
-- `Implementation Steps`: use numbered steps. Each step MUST explain intent
-  and rationale before the code block and include a short narrative paragraph
-  afterward describing the resulting state and why it matters.
-- `Validation`: provide exact commands to build and run, plus the expected
-  visible behavior.
-- `Notes`: capture normative requirements and pitfalls using MUST, SHOULD, and
-  MAY.
-- `Conclusion`: summarize the final system and what was accomplished.
-- `Exercises`: include 5 to 7 focused extensions that reuse concepts from the
-  tutorial.
-- `Changelog`: record the ISO-8601 date, version, and concise change summary.
-
-### Code & Snippets
-
-- Match repository style: 2-space indentation, line width near 80 columns,
-  explicit return statements, and no abbreviations or acronyms in code
-  identifiers.
-- Prefer minimal, buildable snippets.
-- Avoid large, redundant code blocks.
-- Reference files with workspace-relative paths, such as
-  `crates/lambda-rs/examples/uniform_buffer_triangle.rs`.
-- Use ASCII diagrams only.
-- Do not embed binaries.
-
-### Metadata Discipline
-
-- Update `last_updated`, bump `version` semantically, and set `repo_commit` to
-  the current `HEAD` when making substantive edits.
-- Keep `document_id` stable across revisions.
-- Use semantic versioning for the document `version`.
-
-### Consistency
-
-- Keep headings stable and diff-friendly across tutorial revisions.
-- Use consistent terminology such as `bind group`, `pipeline layout`, `GPU`,
-  `CPU`, and `wgpu`.
-
-### Scope & Process Isolation
-
-- Do not reference internal process documents, such as this file.
-- Do not include commentary about guideline updates within tutorials or
-  specifications.
+## Documentation Skills
+
+Use the repo-local Codex skills for detailed documentation workflows.
+
+- Use `.codex/skills/long-lived-docs-authoring/SKILL.md` for specs, roadmaps,
+  guides, plans, and other long-lived Markdown documents.
+- Use `.codex/skills/tutorial-authoring/SKILL.md` for step-by-step tutorials
+  in `docs/tutorials/`.
+- Keep repo-wide policy in this file and keep detailed documentation authoring
+  workflow in those skills.
+
+## Documentation Requirements
+
+- Long-lived docs MUST include YAML front matter with `title`,
+  `document_id`, `status`, `created`, `last_updated`, `version`,
+  `engine_workspace_version`, `wgpu_version`, `shader_backend_default`,
+  `winit_version`, `repo_commit`, `owners`, `reviewers`, and `tags`.
+- New specifications MUST be created from `docs/specs/_spec-template.md`.
+- Specifications and tutorials MUST include a table of contents.
+- Substantive documentation edits MUST update `last_updated`, `version`,
+  `repo_commit`, and the `Changelog`.
+- Long-lived docs MUST use a professional, precise tone with active voice,
+  consistent terminology, American English spelling, and RFC-2119 keywords
+  where appropriate.
+- Tutorials MUST live in `docs/tutorials/`, use kebab-case filenames, include
+  the `tutorial` tag, and include `Goals`, `Overview`, `Prerequisites`,
+  `Implementation Steps`, `Validation`, `Notes`, `Conclusion`, `Exercises`,
+  and `Changelog`.