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`. 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.
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. 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.
BORO (Business Objects Reference Ontology) ontological analysis skill. Extends ontologist with the BORO foundational ontology and re-engineering method from "Business Objects: Re-Engineering for Re-Use" (Chris Partridge). Uses the platform-independent `boro-ontologist` skill as its deeper BORO methodology layer when foundational patterns, re-engineering method, or BORO reference material are required. 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. Produces BORO-grounded ontology models that feed ob-architect (for OB solution design) and ob-engineer (for OB implementation).
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 JIRA 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. Orchestrates product-vision-steering, release-planner, feature-spec-author, backlog-manager, sprint-planner, sprint-executor, and jira-impl-logger. Named distinctly from the upstream spec-workflow-mcp to avoid collision when both are installed. Canonical address: workflow:orchestrate:sdd:agnostic.
Produce and maintain the three steering documents that provide persistent project context: product.md (vision, users, objectives), tech.md (stack, patterns, tooling), and structure.md (directory layout, naming conventions). Use when: setting up a new project from scratch, onboarding an existing codebase into the ol-sdd-workflow, refreshing steering docs when the project's direction or stack changes, or when a feature spec author needs upstream context that is missing. Produces filled-in templates committed to documentation/steering/ and published to Confluence. Phase 0 of the ol-sdd-workflow orchestrator.
Execute an entire JIRA epic end-to-end by discovering every child ticket (stories + subtasks), building a dependency graph from JIRA issue links, and scheduling tickets into dependency-aware waves. Tickets within a wave run in parallel (each in its own git worktree to avoid conflicts); waves run sequentially. Each individual ticket is delegated to jira-task-executor, which itself delegates the coding to Codex, runs clean-code review for complex tickets, transitions JIRA status, and posts an impl log. Use when: the user hands over an epic key (or epic URL) and wants the whole thing shipped, or when a feature has been spec'd and the epic is fully populated and ready to run. Epic-level cousin of sprint-executor — same wave pattern, scoped to an epic instead of a sprint.
Implement a single JIRA task end-to-end by delegating the coding work to Codex via the Codex MCP, walking the ticket through its JIRA status workflow, and posting a structured implementation log on completion. For complex tickets, reviews Codex's output with clean-code-reviewer and bounces specific feedback back to Codex until the change is clean. Use when: a single JIRA ticket needs to be picked up and shipped (outside of a full sprint loop), or when a sprint executor wants to delegate one ticket's execution to a focused sub-skill. A one-ticket cousin of sprint-executor, hard-wired to Codex as the implementer.