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