docopslab-dev 0.1.0 → 0.2.0

data/docs/agent/skills/fix-jekyll-asciidoc-build-errors.md

@@ -6,18 +6,9 @@ As an AI agent, you can help fix Asciidoctor errors in Jekyll builds.
 
 1. Perform a basic Jekyll build that writes verbose output to a local file.
 
-Example with config option
-
-```
-bundle exec jekyll build --verbose --config configs/jekyll.yml > .agent/scratch/jekyll-build.log 2>&1
-```
-
-Note the `2>&1` at the end of the command, which ensures that both standard output and error messages are captured in the log file.
 2. Run the analysis task on the exported file.
 
-```
-bundle exec rake 'labdev:lint:logs[jekyll-asciidoc,.agent/scratch/jekyll-build.log]'
-```
 3. Open the YAML file relayed in the response message (example: `Jekyll AsciiDoc issues report generated: .agent/reports/jekyll-asciidoc-issues-20251214_085323.yml`).
+
 4. Follow the instructions in the report to address the issues found.
 

data/docs/agent/skills/fix-spelling-issues.md

@@ -6,8 +6,5 @@ As an AI agent, you can help DocOps Lab developers fix spelling issues in docume
 
 1. Use the spellcheck task to generate a spelling report.
 
-```
-bundle exec rake labdev:lint:spellcheck
-```
 2. Follow the prompts in the generated report.
 

data/docs/agent/skills/git.md

@@ -11,22 +11,25 @@ Table of Contents
 - The Basics
 - Repository State
 - Development Procedures
-- Commit Message Conventions
-      - Merging Changes
+  - Commit Message Conventions
+  - Merging Changes
 - Dev Branch Rules
 - Commit Messages
-- General Style (Conventional Commits)
-      - Commit Description
-      - Commit Types
-      - Commit Body Conventions
+  - General Style (Conventional Commits)
+  - Commit Description
+  - Commit Types
+  - Commit Body Conventions
 - Use `gh` the GitHub CLI Tool
 
 ## The Basics
 
 1. Follow proper branching procedures as outlined in Repository State.
+
 2. Commit messages should be concise and easy for users to edit.  
 See Commit Messages for guidance.
+
 3. Always prompt user to approve commits before pushing.
+
 4. Use `gh` for interacting with GitHub whenever possible.  
 See Use `gh` the GitHub CLI Tool for more information.
 
@@ -61,34 +64,55 @@ git push -u origin feat/add-widget
 gh pr create --base dev/1.2 --title "feat: add widget" --body "Adds a new widget to the dashboard."
 ```
 
-**Branch naming conventions** :
-   - `feat/…​` for new features OR improvements
-   - `fix/…​` for bugfixes
-   - `chore/…​` for version bumps and sundry tasks with no product impact
-   - `epic/…​` for large features or changes that span releases
+<dl>
+<dt class="hdlist1">Branch naming conventions</dt>
+<dd>
+- `feat/…​` for new features OR improvements
+
+- `fix/…​` for bugfixes
+
+- `chore/…​` for version bumps and sundry tasks with no product impact
+
+- `epic/…​` for large features or changes that span releases
+</dd>
+</dl>
 
 ### Commit Message Conventions
 
-**Description (first line) conventions**:
-   - Use present-tense descriptive verbs (“adds widget”, not “added” or “add”)
-   - `feat: …​` for new features OR improvements
-   - `fix: …​` for bugfixes
-   - `chore: …​` for version bumps and sundry tasks with no product impact
-   - `docs: …​` for documentation changes
-   - `test: …​` for test code changes
-   - `refactor: …​` for code restructuring with no functional changes
-   - `style: …​` for formatting, missing semi-colons, etc; no functional changes
-   - `perf: …​` for performance improvements
-   - `auto: …​` for changes to CI/CD pipelines and build system
-
-**Body conventions** :
-   - Use the body to explain what and why vs. how.
-   - Reference issues and pull requests as needed.
-   - Use bullet points (`- text`) and paragraphs as needed for clarity.
-   - Do not hard-wrap lines, but _do_:
-
-      - use 1-sentence per line
-      - keep sentences short
+<dl>
+<dt class="hdlist1">Description (first line) conventions</dt>
+<dd>
+- Use present-tense descriptive verbs (“adds widget”, not “added” or “add”)
+
+- `feat: …​` for new features OR improvements
+
+- `fix: …​` for bugfixes
+
+- `chore: …​` for version bumps and sundry tasks with no product impact
+
+- `docs: …​` for documentation changes
+
+- `test: …​` for test code changes
+
+- `refactor: …​` for code restructuring with no functional changes
+
+- `style: …​` for formatting, missing semi-colons, etc; no functional changes
+
+- `perf: …​` for performance improvements
+
+- `auto: …​` for changes to CI/CD pipelines and build system
+</dd>
+<dt class="hdlist1">Body conventions</dt>
+<dd>
+- Use the body to explain what and why vs. how.
+
+- Reference issues and pull requests as needed.
+
+- Use bullet points (`- text`) and paragraphs as needed for clarity.
+
+- Do not hard-wrap lines, but _do_:
+</dd>
+</dl>
 
 ### Merging Changes
 
@@ -110,7 +134,9 @@ Delete merged branches.
 ## Dev Branch Rules
 
 - Always branch from `dev/x.y`.
+
 - Always squash-merge into `dev/x.y`.
+
 - Never merge directly into `main`.
 
 ## Commit Messages
@@ -144,25 +170,34 @@ Use the _past tense_ rather than imperative mood (e.g., "Added feature X" instea
 ### Commit Types
 
 - Use present-tense descriptive verbs (“adds widget”, not “added” or “add”)
+
 - `feat: …​` for new features OR improvements
+
 - `fix: …​` for bugfixes
+
 - `chore: …​` for version bumps and sundry tasks with no product impact
+
 - `docs: …​` for documentation changes
+
 - `test: …​` for test code changes
+
 - `refactor: …​` for code restructuring with no functional changes
+
 - `style: …​` for formatting, missing semi-colons, etc; no functional changes
+
 - `perf: …​` for performance improvements
+
 - `auto: …​` for changes to CI/CD pipelines and build system
 
 ### Commit Body Conventions
 
 - Use the body to explain what and why vs. how.
+
 - Reference issues and pull requests as needed.
+
 - Use bullet points (`- text`) and paragraphs as needed for clarity.
-- Do not hard-wrap lines, but _do_:
 
-   - use 1-sentence per line
-   - keep sentences short
+- Do not hard-wrap lines, but _do_:
 
 ## Use `gh` the GitHub CLI Tool
 

data/docs/agent/skills/github-issues.md

@@ -10,10 +10,10 @@ Table of Contents
 - Bulk-posting Issues with Issuer
 - Issue Types
 - Issue Labels
-- Project-specific Labels
-      - Standard Documentation Labels
-      - Admonition Labels
-      - Other Standard Labels
+  - Project-specific Labels
+  - Standard Documentation Labels
+  - Admonition Labels
+  - Other Standard Labels
 
 ## Managing GitHub Issues with `gh`
 
@@ -49,20 +49,28 @@ Follow the instructions at [Issuer](https://github.com/DocOps/issuer) to install
 
 ## Issue Types
 
-**Task** :
-   A specific piece of work that does not directly lead to a change to the product. Used for research, infrastructure management, and other sundry/chore tasks not necessarily associated with repository code changes.
-
-**Bug** :
-   Reports describing unexpected behavior or malfunctions in the product. Bug issues are used directly and become bugfixes (no technical type change) once resolved.
-
-**Feature** :
-   Requests or ideas for new functionality in the product.
-
-**Improvement** :
-   Enhancements of existing features or capabilities.
-
-**Epic** :
-   An issue or collection of issues with a common goal that may involve work performed across release versions (“milestones”).
+<dl>
+<dt class="hdlist1">Task</dt>
+<dd>
+A specific piece of work that does not directly lead to a change to the product. Used for research, infrastructure management, and other sundry/chore tasks not necessarily associated with repository code changes.
+</dd>
+<dt class="hdlist1">Bug</dt>
+<dd>
+Reports describing unexpected behavior or malfunctions in the product. Bug issues are used directly and become bugfixes (no technical type change) once resolved.
+</dd>
+<dt class="hdlist1">Feature</dt>
+<dd>
+Requests or ideas for new functionality in the product.
+</dd>
+<dt class="hdlist1">Improvement</dt>
+<dd>
+Enhancements of existing features or capabilities.
+</dd>
+<dt class="hdlist1">Epic</dt>
+<dd>
+An issue or collection of issues with a common goal that may involve work performed across release versions (“milestones”).
+</dd>
+</dl>
 
 ## Issue Labels
 
@@ -70,66 +78,97 @@ All DocOps Lab projects use a common convention around GitHub issue labels to ca
 
 ### Project-specific Labels
 
-**`component:<part>`** :
-   Label prefix for arbitrarily named product aspects, modules, interfaces, or subsystems. Common components include `component:docker`, `component:cli`, and `component:docs` (see next section). These correspond to the `part` property in ReleaseHx change records.
+<dl>
+<dt class="hdlist1">`component:<part>`</dt>
+<dd>
+Label prefix for arbitrarily named product aspects, modules, interfaces, or subsystems. Common components include `component:docker`, `component:cli`, and `component:docs` (see next section). These correspond to the `part` property in ReleaseHx change records.
+</dd>
+</dl>
 
 ### Standard Documentation Labels
 
-**`component:docs`** :
-   Indicates the issue pertains to documentation infrastructure, layout, deployment, but not core content.
-
-**`documentation`** :
-   The issue relates to documentation _content_ updates or improvements.
-
-**`needs:docs`** :
-   The issue requires documentation updates as part of its resolution. Documentation updates will likely be in a sub-issue with a `documentation` label.
-
-**`needs:note`** :
-   The issue requires a note in the release history when resolved. Release notes are appended to the description body under `## Release Note`.
-
-**`changelog`** :
-   The issue summary should be included in the changelog for the next release, even if no release note is included.
+<dl>
+<dt class="hdlist1">`component:docs`</dt>
+<dd>
+Indicates the issue pertains to documentation infrastructure, layout, deployment, but not core content.
+</dd>
+<dt class="hdlist1">`documentation`</dt>
+<dd>
+The issue relates to documentation _content_ updates or improvements.
+</dd>
+<dt class="hdlist1">`needs:docs`</dt>
+<dd>
+The issue requires documentation updates as part of its resolution. Documentation updates will likely be in a sub-issue with a `documentation` label.
+</dd>
+<dt class="hdlist1">`needs:note`</dt>
+<dd>
+The issue requires a note in the release history when resolved. Release notes are appended to the description body under `## Release Note`.
+</dd>
+<dt class="hdlist1">`changelog`</dt>
+<dd>
+The issue summary should be included in the changelog for the next release, even if no release note is included.
+</dd>
+</dl>
 
 ### Admonition Labels
 
-**`REMOVAL`** :
-   Removes functionality or features.
-
-**`DEPRECATION`** :
-   Announces planned removal of functionality or features in a future release. (Only appropriate for `documentation` issues.)
-
-**`BREAKING`** :
-   Includes one or more changes that are not backward-compatible.
-
-**`SECURITY`** :
-   Addresses or documents a security vulnerability or risk.
+<dl>
+<dt class="hdlist1">`REMOVAL`</dt>
+<dd>
+Removes functionality or features.
+</dd>
+<dt class="hdlist1">`DEPRECATION`</dt>
+<dd>
+Announces planned removal of functionality or features in a future release. (Only appropriate for `documentation` issues.)
+</dd>
+<dt class="hdlist1">`BREAKING`</dt>
+<dd>
+Includes one or more changes that are not backward-compatible.
+</dd>
+<dt class="hdlist1">`SECURITY`</dt>
+<dd>
+Addresses or documents a security vulnerability or risk.
+</dd>
+</dl>
 
 ### Other Standard Labels
 
-**`question`** :
-   User or community member inquiries about the product or project.
-
-**`priority:high`** :
-   Indicates that the issue is important and should be prioritized for release as soon as possible.
-
-**`priority:low`** :
-   The issue is not urgent and can be addressed in a future release.
-
-**`priority:stretch`** :
-   Issue is slated for the next release but can be bumped if it’s holding up releasee.
-
-**`wontfix`** :
-   The issue will not be addressed. Comment from maintainers should explain why.
-
-**`duplicate`** :
-   The issue is a duplicate of another issue, which should be linked in the comments.
-
-**`posted-by-issuer`** :
-   Indicates that the issue was created by the Issuer tool.
-
-**`good first issue`** :
-   Designates an issue suitable for new contributors to the project.
-
-**`help wanted`** :
-   Indicates that maintainers are seeking assistance from the community to resolve the issue.
+<dl>
+<dt class="hdlist1">`question`</dt>
+<dd>
+User or community member inquiries about the product or project.
+</dd>
+<dt class="hdlist1">`priority:high`</dt>
+<dd>
+Indicates that the issue is important and should be prioritized for release as soon as possible.
+</dd>
+<dt class="hdlist1">`priority:low`</dt>
+<dd>
+The issue is not urgent and can be addressed in a future release.
+</dd>
+<dt class="hdlist1">`priority:stretch`</dt>
+<dd>
+Issue is slated for the next release but can be bumped if it’s holding up releasee.
+</dd>
+<dt class="hdlist1">`wontfix`</dt>
+<dd>
+The issue will not be addressed. Comment from maintainers should explain why.
+</dd>
+<dt class="hdlist1">`duplicate`</dt>
+<dd>
+The issue is a duplicate of another issue, which should be linked in the comments.
+</dd>
+<dt class="hdlist1">`posted-by-issuer`</dt>
+<dd>
+Indicates that the issue was created by the Issuer tool.
+</dd>
+<dt class="hdlist1">`good first issue`</dt>
+<dd>
+Designates an issue suitable for new contributors to the project.
+</dd>
+<dt class="hdlist1">`help wanted`</dt>
+<dd>
+Indicates that maintainers are seeking assistance from the community to resolve the issue.
+</dd>
+</dl>
 

data/docs/agent/skills/rake-cli-dev.md

@@ -7,7 +7,7 @@ If you need to add or modify Rake tasks for the current project, follow the guid
 Table of Contents
 
 - Rake CLIs
-- Rake CLI Model
+  - Rake CLI Model
 
 ## Rake CLIs
 

data/docs/agent/skills/readme-driven-dev.md

@@ -9,5 +9,6 @@ We will eventually provide detailed documentation of the conventions and protoco
 For now, Agents should:
 
 - Peruse the local `README.adoc` and `specs/data/*.{yml,yaml}`
+
 - Prompt their Operators to provide examples from relevant/neighboring projects.
 

data/docs/agent/skills/release-history.md

@@ -17,13 +17,7 @@ The general procedure is as follows:
 
 1. Generate a draft release history in YAML.
 
-```
-bundle exec rhx <version> --yaml --fetch
-```
 2. Edit the generated YAML to ensure clarity and completeness.
-3. Generate the Markdown version.
 
-```
-bundle exec rhx <version> --md docs/release/<version>.md
-```
+3. Generate the Markdown version.
 

data/docs/agent/skills/ruby.md

@@ -11,44 +11,55 @@ However, conventions are not exhaustively listed, and deviations are rarely poin
 ### Naming Conventions
 
 - Use `snake_case` for variable and method names.
+
 - Use `CamelCase` for class and module names.
+
 - Use `SCREAMING_SNAKE_CASE` for constants.
+
 - Use descriptive names that convey the purpose of the variable, method, or class.
+
 - Avoid abbreviations unless they are widely understood.
+
 - Use verbs for method names to indicate actions.
+
 - Use nouns for class and module names to indicate entities.
 
 ### Architectural Conventions
 
 - Use classes and class instance methods for objects that work like _objects_ — they have state and do not act on other objects' state.
+
 - Use module methods acting on objects or carrying out general operations/utility functions.
+
 - Use Rake for internal (developer) CLI; use Thor for user-facing CLI
+
 - Gems may begin life as a module within another gem.
 
 ### Path Conventions
 
 - Use `lib/` for main application code.
 
-   - `lib/<project_name>.rb` for the main file
-   - `lib/<project_name>/` for supporting files and modules
-   - `lib/<project_name>/<module_name>/` for submodules
 - Use `spec/` for specifications and tests.
+
 - Use `docs/` or `_docs/` for documentation.
+
 - Use `build/` for pre-runtime artifacts.
+
 - Use `_build/` as default in applications that generate files at runtime, unless another path is more appropriate (ex: `_site/` in Jekyll-centric apps).
-- Do NOT assume or insist upon perfect alignment with Ruby path conventions:
 
-   - `SomeModule` or `SomeClass` may be sourced at `lib/some_module.rb` or `lib/some_class.rb` instead of `lib/some/module.rb` or `lib/some/class.rb`.
-   - Some modules like `SchemaGraphy` and `AsciiDoc` are never broken up into `schema_graphy` or `ascii_doc` namespaces.
-   - Modules with multiple parallel sibling modules in a category like (`WriteOps`, `DraftOps`) belong in paths like `lib/ops/write.rb` instead of `lib/write_ops.rb` or `lib/write/ops.rb`.
+- Do NOT assume or insist upon perfect alignment with Ruby path conventions:
 
 ### Syntax Conventions
 
 - Use 2 spaces for indentation.
+
 - Limit lines to 120 characters or so when possible.
+
 - Use parentheses for method calls with arguments, but omit them for methods without arguments.
+
 - Do not use parentheses in method definitions (`def method_name arg1, arg2`).
+
 - Use single quotes for strings that do not require interpolation or special symbols.
+
 - Use double quotes for strings that require interpolation or special symbols.
 
 ### Commenting Conventions

data/docs/agent/skills/schemagraphy-sgyml.md

@@ -7,8 +7,11 @@ SGYML stands for SchemaGraphy YAML-based Modeling Language, a format designed, s
 It is a specialized YAML preprocessing syntax that provides:
 
 - A human-readable schema model that can define, govern, and parse the structure and contents of complex data objects and text documents alike
+
 - An extension for YAML documents to incorporate new properties like `$ref` transclusion directives and inheritance/overlay properties
+
 - A standardization around a base subset of YAML capabilities to constrain the complexity of YAML documents and support thereof
+
 - Highly semantic data-typing to replace YAML’s clunky model
 
 SchemaGraphy Schemas and the SGYML and tooling to support them are in a nascent stage, still under development.

data/docs/agent/skills/tests-running.md

@@ -6,20 +6,28 @@ As an AI agent, you can help DocOps Lab developers run tests effectively using s
 
 All Ruby gem projects with tests should implement these standard Rake tasks in their `Rakefile`:
 
-**`bundle exec rake rspec`** :
-   Run RSpec test suite using the standard pattern matcher.
-
-**`bundle exec rake cli_test`** :
-   Validate command-line interface functionality. May test basic CLI loading, help output, version information.
-
-**`bundle exec rake yaml_test`** :
-   Validate YAML configuration files and data structures. Should test all project YAML files for syntax correctness.
-
-**`bundle exec rake pr_test`** :
-   Comprehensive test suite for pre-commit and pull request validation. Typically includes: RSpec tests, CLI tests, YAML validation.
-
-**`bundle exec rake install_local`** :
-   Build and install the project locally for testing.
+<dl>
+<dt class="hdlist1">`bundle exec rake rspec`</dt>
+<dd>
+Run RSpec test suite using the standard pattern matcher.
+</dd>
+<dt class="hdlist1">`bundle exec rake cli_test`</dt>
+<dd>
+Validate command-line interface functionality. May test basic CLI loading, help output, version information.
+</dd>
+<dt class="hdlist1">`bundle exec rake yaml_test`</dt>
+<dd>
+Validate YAML configuration files and data structures. Should test all project YAML files for syntax correctness.
+</dd>
+<dt class="hdlist1">`bundle exec rake pr_test`</dt>
+<dd>
+Comprehensive test suite for pre-commit and pull request validation. Typically includes: RSpec tests, CLI tests, YAML validation.
+</dd>
+<dt class="hdlist1">`bundle exec rake install_local`</dt>
+<dd>
+Build and install the project locally for testing.
+</dd>
+</dl>
 
 Note that non-gem projects may have some or all of these tasks, as applicable.
 

data/docs/agent/skills/tests-writing.md

@@ -6,40 +6,63 @@ As an AI agent, you can help DocOps Lab developers write comprehensive tests fol
 
 Tests should be organized into these categories:
 
-**Unit Tests** :
-   - Module loading and initialization
-   - Class structure validation
-   - Basic functionality verification
-   - Individual method testing
-
-**Integration Tests** :
-   - Data processing workflows
-   - Template rendering operations
-   - Configuration loading scenarios
-   - API client functionality (where applicable)
-
-**Validation Tests** :
-   - File format compliance (YAML, JSON)
-   - Configuration schema validation
-   - Template syntax verification
-   - Command-line option parsing
+<dl>
+<dt class="hdlist1">Unit Tests</dt>
+<dd>
+- Module loading and initialization
 
-All Ruby gem projects with tests should implement these standard Rake tasks in their `Rakefile`:
+- Class structure validation
+
+- Basic functionality verification
+
+- Individual method testing
+</dd>
+<dt class="hdlist1">Integration Tests</dt>
+<dd>
+- Data processing workflows
+
+- Template rendering operations
 
-**`bundle exec rake rspec`** :
-   Run RSpec test suite using the standard pattern matcher.
+- Configuration loading scenarios
 
-**`bundle exec rake cli_test`** :
-   Validate command-line interface functionality. May test basic CLI loading, help output, version information.
+- API client functionality (where applicable)
+</dd>
+<dt class="hdlist1">Validation Tests</dt>
+<dd>
+- File format compliance (YAML, JSON)
 
-**`bundle exec rake yaml_test`** :
-   Validate YAML configuration files and data structures. Should test all project YAML files for syntax correctness.
+- Configuration schema validation
 
-**`bundle exec rake pr_test`** :
-   Comprehensive test suite for pre-commit and pull request validation. Typically includes: RSpec tests, CLI tests, YAML validation.
+- Template syntax verification
+
+- Command-line option parsing
+</dd>
+</dl>
+
+All Ruby gem projects with tests should implement these standard Rake tasks in their `Rakefile`:
 
-**`bundle exec rake install_local`** :
-   Build and install the project locally for testing.
+<dl>
+<dt class="hdlist1">`bundle exec rake rspec`</dt>
+<dd>
+Run RSpec test suite using the standard pattern matcher.
+</dd>
+<dt class="hdlist1">`bundle exec rake cli_test`</dt>
+<dd>
+Validate command-line interface functionality. May test basic CLI loading, help output, version information.
+</dd>
+<dt class="hdlist1">`bundle exec rake yaml_test`</dt>
+<dd>
+Validate YAML configuration files and data structures. Should test all project YAML files for syntax correctness.
+</dd>
+<dt class="hdlist1">`bundle exec rake pr_test`</dt>
+<dd>
+Comprehensive test suite for pre-commit and pull request validation. Typically includes: RSpec tests, CLI tests, YAML validation.
+</dd>
+<dt class="hdlist1">`bundle exec rake install_local`</dt>
+<dd>
+Build and install the project locally for testing.
+</dd>
+</dl>
 
 Note that non-gem projects may have some or all of these tasks, as applicable.