ol_ai_context_library

Publish an approved feature spec (tasks.md) to a Linear project as a structured tree of labeled, nested issues (feature → story → task), each with a spec back-link, requirements traceability, skill-routing label, and point estimate. Use when: the project tracker is Linear and a feature spec has been approved and needs to become a tracked backlog, or when a new requirement needs to be added to an existing Linear feature-issue. Phase 2 of the ol-sdd-workflow orchestrator when the project's tracker is Linear. The Linear parallel of backlog-manager (JIRA), ado-backlog-manager (ADO), and local-backlog-manager (filesystem). Requires Linear MCP — if the MCP is unavailable, fall back to `local-backlog-manager`.

Check installed agent skills for available updates and bring them up to date. Covers the global install (~/.agents/skills + ~/.claude/skills), the current project's install, and — fleet mode — every repo under a user-supplied root folder. Detects three things: lock-tracked skills whose GitHub source moved on (updated via `npx skills update`), installs that drifted from a local library checkout or were never lock-tracked (updated via a deterministic local sync script), and broken .claude/skills symlinks. Use when: the user asks to update their skills, check whether installed skills are stale, roll a library change out to every machine-local install, or audit which repos have skills installed. Cross-cutting infrastructure skill — applies to all skills in the library.

Bootstrap, audit, and align solution-specific Confluence spaces against the canonical Ontoledgy space structure. The Confluence parallel of notion-workspace-manager, selected when the docs backend is Confluence. Operates in three modes: Create, Audit, and Align. Use when: the docs backend is Confluence (not Notion — use notion-workspace-manager for Notion) and a new solution repo needs a Confluence home, an existing space has drifted from convention, or a team wants to align multiple spaces before a release. Companion to `product-vision-steering` (Phase 0) and `release-planner` (Phase 0.5) — provides the *Confluence-side* container they publish into.

Post a structured implementation log as a comment on a tracker work item (or, for `tracker: local`, an Activity Log entry) after a task is completed. Captures files created/modified, code statistics, and structured artifacts (API endpoints, components, functions, classes, integrations) so future engineers and AI agents can discover existing code and avoid duplication. Adapted from the spec-workflow-mcp log-implementation schema. Tracker-agnostic: works against JIRA, Linear, Azure DevOps, or a local filesystem tracker via the task-executor tracker adapter (`skills/task-executor/references/tracker-{jira,linear,ado,local}.md`), selected by the `tracker:` input. Use when: a task has been committed and the implementation needs to be recorded, or when a user asks to backfill a missing implementation log for an already-closed item. Phase 5 of the ol-sdd-workflow orchestrator: normally invoked once per completed task by the executor, but can also be run directly.

Ontoledgy end-to-end Spec-Driven Development (SDD) workflow orchestrator. Drives a team through six phases — Steering → Release Plan → Feature Spec → Backlog → Sprint Plan → Execution — with explicit user approval gates between each phase and structured implementation logs published to the tracker as issue comments. Use when: starting a new product or project from goals, scoping an MVP or release, taking a feature from concept to shipped code, setting up a sprint, or running a sprint with delegated task execution. Backend-agnostic: runs in `tracker: jira|linear|ado|local` and `docs: confluence|notion|ado-wiki|local` mode, routing each phase to the matching backend skill. `tracker: ado` + `docs: ado-wiki` runs the whole workflow on Azure DevOps Boards + Wiki; `tracker: local` + `docs: local` is the fully offline fallback — markdown files in the repo, no MCP — for when JIRA/Confluence/Notion/Linear/ADO are unavailable. Orchestrates product-vision-steering, release-planner, feature-spec-author, the tracker's bac

Agent architecture design and review. Extends ob-architect with agent-specific topology design, tool gap analysis against ol_ai_services agent_dev_kit, context engineering, memory architecture, constraint design, and orchestration graph planning. Designs agents that reuse the ol_ai_services service layer; when tools or components are missing, designs new tools for registration into the service layer via BaseTool or MCP interop. Use when: designing a new AI agent system, reviewing an existing agent architecture, planning multi-agent orchestration, or designing tools for agent use — this skill defines the tool contract (schema, behaviour, interop), then hands off to agent-engineer to implement it from the approved design. Canonical address: architect:design:agent:agnostic.

Agent implementation skill. Extends ob-engineer with agent-specific construction patterns using ol_ai_services agent_dev_kit: BaseTool implementation, interop client configuration, agent configuration wiring, orchestration graph building, skill manifest creation, and memory integration. When tools or components are missing from ol_ai_services, implements them following BaseTool and interop contracts for registration into the service layer. Use when: implementing an agent from an approved architecture design, building tools for agent use by implementing them from an approved tool design/contract (the contract itself is designed by agent-architect), creating skill manifests, wiring orchestration graphs, or reviewing agent implementation code. For architecture-level review (topology, tool selection, memory design), use agent-architect instead. Canonical address: engineer:implement:agent:python.

Author a full feature specification — requirements, design, and tasks — for a single feature in the ol-sdd-workflow. Wraps software-architect in feature-design mode and extends it to produce all three artifacts (requirements.md, design.md, tasks.md) with three in-phase approval gates. Use when: designing a new feature that needs the full spec (requirements + design + tasks with three approval gates), breaking a feature from the development plan into implementable tasks, or re-specifying an existing feature. For design-only work (the design.md artifact alone, no requirements/tasks gates), use software-architect's Feature Design mode directly — this skill wraps that mode and adds the surrounding gates. Phase 1 of the ol-sdd-workflow orchestrator. Outputs land in documentation/specs/{feature-name}/ and on the docs surface (Confluence, Notion, ADO Wiki, or local files via the docs adapter).

Software architecture design and review grounded in two independent ontological methods: BORO (Business Objects Reference Ontology — ontology of the world) for domain analysis, and BIE (Data Identity Ontology — ontology of the data) for deterministic data identity. Use when: designing a new solution or system, reviewing an existing architecture for alignment with design philosophy, choosing between structural approaches, or mapping requirements to technology components. Operates in three modes: High-Level Solution Design (BORO domain analysis, project setup, development plan), Feature Design (individual feature spec using design-template), and Review (gap analysis against design philosophy). For a BORO/Ontoledgy codebase (nf_common or bclearer_pdk) use ob-architect; for a bclearer pipeline specifically use bclearer-pipeline-architect; for a frontend use ui-architect; for an AI agent system use agent-architect — this base skill is for platform-agnostic / non-OB solution design. For a full feature spec (require

UI architecture design and review. Extends software-architect with frontend-specific patterns: component architecture selection (Atomic Design, Feature-Sliced), design system design, UX journey flows for process-driven interfaces (document upload, pipeline kick-off, results review), and data visualisation strategy. Knows the ol_ui_library and can design extensions to it. Use when: designing a frontend solution or component library, defining UX journeys for process-driven flows, choosing a data visualisation strategy, or reviewing an existing frontend for architectural alignment. Canonical address: architect:design:ui:agnostic.

Execute an entire epic end-to-end: discover every child ticket, order them into dependency-aware waves, and delegate each ticket to task-executor (which picks the engine, reviews, moves tracker status, and logs). Waves run sequentially; tickets within a wave run in parallel, each in its own git worktree. Tracker-agnostic across JIRA, Linear, Azure DevOps, or a local filesystem tracker. Use when: the user hands over an epic key/id or URL (e.g. `TI-100`, `ONT-27`, `AB#100`, `LOC-100`) and wants the whole epic shipped, or a feature has been spec'd and its epic is fully populated and ready to run — not a time-boxed sprint (use sprint-executor), not a single ticket (use task-executor). Epic-level cousin of sprint-executor — same wave pattern, scoped to an epic instead of a sprint.

Publish an approved feature spec (tasks.md) to a local filesystem tracker as a structured tree of markdown work-item files. Creates one epic file per feature, story files that group tasks by requirement, and task files for each atomic task — each with a back-link to the spec, requirements traceability, skill-routing label, and estimate. The offline parallel of backlog-manager (JIRA) and linear-backlog-manager (Linear): no MCP, the repo's documentation/tracker/ folder is the board. Use when: the project tracker is local (no JIRA/Linear/ADO MCP available) and a feature spec has been approved and needs to become a tracked backlog, or when a new requirement needs to be added to an existing local epic. Phase 2 of the ol-sdd-workflow orchestrator when the project's tracker is local.

Execute a planned sprint as tech lead. For each ticket in the sprint, delegate implementation to the assigned engine (the routed Claude-native engineer skill, or delegated Codex), review the return with clean-code-reviewer, run quality checks, commit with conventional-commits format, move the tracker ticket forward, and trigger the implementation log. Use when: executing a time-boxed sprint — the user hands over a sprint / cycle / iteration id (a JIRA sprint, a Linear cycle, an ADO iteration, or a local `sprint:` tag) with an approved kickoff, or resuming an in-flight sprint — not a whole epic (use epic-executor), not a single ticket (use task-executor). Phase 4 of the ol-sdd-workflow orchestrator. Runs `mode: serial` (one ticket at a time, default) or `mode: parallel` — fanning each dependency-ordered wave out across git worktrees and subagents, one ticket per worktree, then merging and integration-checking on the sprint base. The codex-vs-claude engine for each ticket is assigned upstream (the `exec:` label

Implement a single tracker ticket end-to-end: delegate the coding to an implementation engine (Codex or the routed Claude-native engineer skill), review and iterate on the result, walk the ticket through its status workflow, and post a structured implementation log. Tracker-agnostic across JIRA, Linear, Azure DevOps, or a local filesystem tracker. Use when: a single ticket needs to be picked up and shipped outside a full sprint loop, or an executor wants to delegate one ticket to a focused sub-skill — including as the per-lane unit a parallel sprint-executor runs in a git worktree. A one-ticket cousin of sprint-executor and epic-executor.

C# data engineering implementation and review skill. Extends data-engineer with .NET naming conventions, async/await patterns, LINQ idioms, record types, and tooling (dotnet CLI, xUnit, Roslyn analyzers). Use when: implementing a C# pipeline, service, or library targeting .NET 8+; reviewing C# code for clean-coding compliance; or modernising code to record types and LINQ idioms. For a standalone clean-coding violation scan without implementation work, route to `clean-code-reviewer` instead.

General data engineering implementation and review skill. Use when: implementing data pipelines, building new features in a data codebase, reviewing code for clean coding compliance, or applying clean coding standards to existing code. For a standalone, focused clean-coding violation report, route to clean-code-reviewer instead. When the target language is known (Python, JavaScript/TypeScript, C#, Rust, Go), route to the matching python-/javascript-/csharp-/rust-/go-data-engineer instead; use this base skill only for language-agnostic data engineering or when no language-specific skill exists. Grounded in clean coding principles and general data engineering patterns. Designed to be extended by specialised data engineer skills (e.g. python-data-engineer, bie-data-engineer) without modification.

Go data engineering implementation and review skill. Extends data-engineer with Go-specific idioms — explicit error returns, implicit interface satisfaction, goroutines and channels for pipeline concurrency, context propagation, generics (1.18+), and tooling (go mod, go fmt, go vet, golangci-lint, go test). Use when: implementing a Go pipeline, streaming/ETL worker, CLI tool, or high-throughput service; reviewing Go code for clean-coding compliance; or designing goroutine/channel concurrency. For a standalone clean-coding violation scan without implementation work, route to `clean-code-reviewer` instead.

JavaScript/TypeScript data engineering implementation and review skill. Extends data-engineer with TypeScript conventions, async/await patterns, module system, and tooling (eslint, prettier, vitest/jest, tsc). Use when: implementing a JavaScript/TypeScript pipeline, API, or library; reviewing JS/TS code for clean-coding compliance; or migrating a module to TypeScript. For frontend or UI JavaScript/TypeScript (React, Vue, Angular), route to `ui-engineer` instead. For a standalone clean-coding violation scan without implementation work, route to `clean-code-reviewer` instead.

Python data engineering implementation and review skill. Extends data-engineer with Python-specific naming conventions, error handling idioms, type annotation patterns, and tooling (ruff, mypy, pytest, pyproject.toml). Use when: implementing a Python data pipeline or library, reviewing Python code for clean-coding compliance, or adding type annotations to an existing module. For a BORO/Ontoledgy Python codebase (nf_common or bclearer_pdk), use ob-engineer, which applies the BORO Quick Style Guide over PEP 8. For a standalone clean-coding violation scan without implementation work, route to `clean-code-reviewer` instead.

Rust data engineering implementation and review skill. Extends data-engineer with Rust-specific ownership/borrowing model, Result/Option idioms, trait-based design, and tooling (cargo, clippy, rustfmt, cargo-test). Use when: implementing a Rust pipeline, CLI tool, or high-performance processing library; reviewing Rust code for clean-coding compliance; or resolving an ownership/borrowing design. For a standalone clean-coding violation scan without implementation work, route to `clean-code-reviewer` instead.

Validate or generate commit messages per the Conventional Commits specification. Use when: checking a commit message before pushing, generating a compliant message from a diff or change description, or integrating commit quality into a CI/CD workflow.

Audits a codebase for duplicated code (copy/paste clones and structural repetition), ranks the worst clones with per-language detection tools, triages false positives, and proposes a deduplication strategy — then routes each fix to the right downstream skill. Use when: a repository has grown by copy/paste, the same logic appears in several places, you want a DRY-focused clean-code triage before refactoring, or you need a consolidation plan before handing work to `clean-code-refactor` or a `[language]-data-engineer` (for oversized-file triage use clean-code-size instead). Runs jscpd as the cross-language detector and documents native tools per language (pylint, eslint-plugin-sonarjs, PMD CPD, dupl/golangci-lint, cargo-dupes). Supports Python, JavaScript/TypeScript, C#, Rust, and Go.

Standalone naming skill — audit, fix, or suggest names for code symbols against clean coding standards. Use when: reviewing names before a rename refactor, fixing naming violations flagged by clean-code-reviewer, or generating candidate names for a new symbol — when naming is the ONLY concern. When naming fixes are part of a broader violation report, use `clean-code-refactor mode=naming` instead. Highest daily-use value of the clean coding sub-skills. Supports Python, JavaScript/TypeScript, C#, Rust, and Go. Supports both general (Clean Code) and OB (BORO Quick Style Guide) naming conventions.

Rewrites code to fix clean coding violations. Use when: acting on a violation report from clean-code-reviewer, fixing specific non-naming code-level issues (function size, error handling, smells) in existing code (for naming-only fixes use clean-code-naming instead), or as the final step in a refactoring workflow after an architect has designed the target structure. Does NOT make architectural changes — structural redesign is the responsibility of the appropriate data-engineer in Implement Mode, working from an architect's design. Supports Python, JavaScript/TypeScript, C#, Rust, and Go. Supports both general (Clean Code) and OB (BORO Quick Style Guide) convention sets via the `standard` parameter.

Analyses code and produces a structured violation report against clean coding standards. Use when: auditing code before a refactoring task, reviewing a PR for clean coding compliance, or establishing a baseline before applying clean-code-refactor. Produces a violation report that clean-code-refactor and data-engineer Implement Mode can act on. Its smells mode flags duplication inline; for deep duplication-only analysis (cross-file clone detection with jscpd, clone-type triage, a deduplication plan) use clean-code-duplication. Supports Python, JavaScript/TypeScript, C#, Rust, and Go. Supports both general (Clean Code) and OB (BORO Quick Style Guide) convention sets via the `standard` parameter.

Generate and review tests following project testing standards. Use when: adding tests for a new or untested function/class, reviewing existing tests for quality compliance, or identifying untested paths in a module. Targets test files only; for clean-coding reviews of production code use clean-code-reviewer instead. Supports Python, JavaScript/TypeScript, C#, Rust, and Go. Supports both general (Clean Code) and OB (BORO Quick Style Guide) convention sets via the `standard` parameter.

bclearer pipeline architecture design and review. Extends software-architect with bclearer-specific pipeline topology, interop service conventions, and orchestration patterns. Use when: designing a new bclearer pipeline or reviewing an existing one for alignment with bclearer architectural conventions (use this over ob-architect specifically for bclearer pipeline topology; for non-pipeline OB/Ontoledgy architecture use ob-architect instead). You do NOT implement code — implementation is the responsibility of `bclearer-pipeline-engineer`. Produces architecture designs for approval and documents findings in Confluence.

bclearer pipeline implementation skill. Extends ob-engineer with bclearer-specific pipeline code conventions, interop usage patterns, and orchestration wiring. Use when: implementing a bclearer pipeline from an approved architecture design, reviewing bclearer pipeline code for convention compliance, or adding stages to an existing pipeline. Delegates BIE domain implementation to bie-data-engineer.

BIE component ontology design and review. Use when: designing a new BIE component, reviewing a BIE implementation for gaps, extracting a component model from code, analyzing BIE identity dependence. Produces a component ontology model that must be approved before implementation. Does NOT produce implementation artifacts (enums, calculation tables, code) — those are the data engineer's job.

OB (Ontoledgy/BORO) architecture design and review. Extends software-architect with BORO coding conventions applied at the architectural level: actor-action module naming, explicit orchestration layers, mandatory constants/enum configuration, typed component contracts, and fail-fast boundary design. Use when: designing a BORO or Ontoledgy solution, or reviewing an OB architecture against BORO conventions — excluding bclearer pipelines, whose architecture belongs to bclearer-pipeline-architect (route any bclearer pipeline design/review there, not here). Canonical address: architect:design:ontology:agnostic.

BORO ontological modelling and re-engineering skill using the Business Objects Reference Ontology methodology. Use when: modelling a domain with the BORO methodology, four-dimensionalism, extensional identity, re-engineering entity models, BORO patterns, type vs role distinctions, state modelling, event participation, sign construction, spatio-temporal extent, tuple reification, whole-part decomposition, any reference to Chris Partridge's Business Objects methodology, or validating/critiquing a data model against ontological principles — AND the model is platform-independent with no OB/Ontoledgy-solution coupling (if it must feed an OB solution via ob-architect/ob-engineer, use ob-ontologist instead). This skill is platform-independent and can be used directly or loaded by `ob-ontologist` when deeper BORO foundations, patterns, or method guidance are needed.

BORO (Business Objects Reference Ontology) ontological analysis skill — produces BORO-grounded ontology models that feed ob-architect (for OB solution design) and, via ob-architect, ob-engineer (for OB implementation). Use when: analysing a domain using BORO methodology, classifying entities against the BORO upper ontology (Elements, Types, Tuples, Sets), performing 4D extensionalist analysis, re-engineering legacy data models into ontologically grounded models, or reviewing a domain model for BORO compliance — AND the resulting model feeds an OB/Ontoledgy solution (ob-architect/ob-engineer) rather than being a platform-independent BORO model (for that, use boro-ontologist instead). Use this over the base ontologist skill when the domain analysis must follow BORO methodology or feed a BORO/OB-grounded model. Extends ontologist with the BORO foundational ontology and re-engineering method from "Business Objects: Re-Engineering for Re-Use" (Chris Partridge), and uses the platform-independent `boro-ontologist` s

General ontological analysis skill. Use when: analysing a domain to identify what things exist, how they relate, and what makes them the same thing over time; producing a domain ontology model from requirements or existing systems; reviewing an existing model for ontological coherence — including model reviews where BORO/4D-extensionalist methodology is not required. Produces ontology models that inform architects (for solution design) and engineers (for implementation). For BORO/4D-extensionalist analysis or re-engineering legacy models, use ob-ontologist (when the model feeds an OB/Ontoledgy solution) or boro-ontologist (for platform-independent BORO modelling) instead. Does NOT produce architecture designs or code — those are downstream concerns.

Publish an approved feature spec (tasks.md) to Azure DevOps Boards as a structured hierarchy of work items. Creates one Feature per feature spec (under the release Epic when present), User Stories that group tasks by requirement, and Tasks for each atomic task — each with a back-link to the spec wiki page, requirements traceability, skill-routing tag, and estimate. The Azure DevOps parallel of backlog-manager (JIRA) and linear-backlog-manager (Linear). Use when: the project tracker is ADO and a feature spec has been approved and needs to become a tracked backlog, or when a new requirement needs to be added to an existing ADO Feature. Phase 2 of the ol-sdd-workflow orchestrator when the project's tracker is ado. Requires Azure DevOps MCP — if the MCP is unavailable, fall back to `local-backlog-manager`.

Publish an approved feature spec (tasks.md) to JIRA as a structured hierarchy of epic, stories, and subtasks. Creates one epic per feature, stories that group tasks by requirement, and subtasks for each atomic task — each with back-link to the Confluence spec, requirements traceability, skill-routing label, and estimate. Use when: the project tracker is JIRA and a feature spec has been approved and needs to become a tracked backlog, or when a new requirement needs to be added to an existing JIRA epic. Phase 2 of the ol-sdd-workflow orchestrator when the project's tracker is jira. The JIRA parallel of `ado-backlog-manager` (ADO) and `linear-backlog-manager` (Linear). Requires Atlassian MCP — if the MCP is unavailable, fall back to `local-backlog-manager`.

BIE domain implementation from an approved model. Use when: implementing a BIE domain in Python, creating domain enums, identity vectors, bie_id creator functions, BieDomainObjects subclasses, registration helpers, domain universe setup; or auditing existing BIE domain code against framework patterns (Review Mode). Requires an approved domain ontology model as input. General/foundation infrastructure code already exists — only creates domain-specific code.

Audits a codebase for oversized source files, reports the worst offenders with language-aware size thresholds, and then routes each flagged file through an architect-style decomposition review to propose smaller modules and clearer component boundaries. Use when: a repository feels monolithic, files have become hard to review or own, you want a size-focused clean-code triage before refactoring, or you need a structural split plan before handing work to `clean-code-refactor` or a `[language]-data-engineer` (for duplicate-code triage use clean-code-duplication instead). Supports Python, JavaScript/TypeScript, C#, Rust, and Go.

Gather structured feedback when a skill's output does not match the user's expectations, and optionally post a GitHub issue to fix the skill. Supports named or anonymous issue submission. Use when: the user corrects a skill's output and the root cause appears to be a skill defect, or the user explicitly asks to report a skill issue. Cross-cutting infrastructure skill — applies to all skills in the library.

Bootstrap, audit, and align solution-specific Notion workspaces against the canonical Ontoledgy structure. The Notion parallel of confluence-space-manager, selected when the docs backend is Notion. Operates in three modes: (1) Create — scaffold a solution's page tree (Overview, Steering, Releases, Architecture, Specs, Sprints, Reviews, Ontology, References, WIP) under a root page, using a page-tree + database hybrid; (2) Audit — compare an existing workspace against the canonical structure and produce a gap report; (3) Align — apply approved improvements (rename, move, create, archive). Use when: the docs backend is Notion (not Confluence — use confluence-space-manager for Confluence) and a new solution repo needs a Notion home, an existing workspace has drifted, or a team wants to align workspaces before a release. Reads the repo's documentation/steering/, documentation/releases/, and documentation/specs/ to seed the structure. Companion to product-vision-steering (Phase 0) and release-planner (Phase 0.5) —

Plan a sprint by selecting tracker tickets from one or more feature epics, ordering them into dependency-aware execution waves, matching capacity against estimates, and producing a sprint kickoff document modelled on the tech-lead delegation pattern. Use when: preparing the next sprint, replanning mid-sprint, or turning a prioritised backlog into an executable plan. Phase 3 of the ol-sdd-workflow orchestrator. Tracker-agnostic (jira | linear | ado | local). Output is a committed sprint-kickoff.md and a tracker sprint/cycle/iteration (or local `sprint:` tag) populated with the selected tickets.