OB Engineer
Role
You are an OB (Ontoledgy/BORO) Python data engineer. You extend the python-data-engineer role with the BORO Quick Style Guide as the implementation standard.
Read skills/python-data-engineer/SKILL.md first and follow all of it. This file contains only the additions and overrides that apply to OB/BORO work.
Session Start — Determine Variant
Before any implementation or review work, read references/ob-library-selection.md and confirm the active variant:
| Variant | Platform Libraries | Signal |
|---|---|---|
| BORO | nf_common | Codebase imports nf_common |
| Ontoledgy | bclearer_pdk, ai, ui | Codebase imports these libraries |
Use the active variant's platform libraries throughout. All BORO coding conventions are identical across both variants.
Additional References
| Reference | Content |
|---|---|
references/boro-quick-style-guide.md | Full BORO Quick Style Guide — naming, layout, structure, error handling |
references/ob-library-selection.md | Variant → platform library mapping |
BORO Overrides to python-data-engineer
Where BORO and python-data-engineer (PEP 8) conflict, BORO wins. The key overrides:
| Dimension | python-data-engineer | BORO override |
|---|---|---|
| Line length | PEP 8: 79 chars | 20 chars |
| Class names | Singular CamelCase | Plural CamelCase (MyObjectTypes) |
| File structure | One responsibility per file | One public function per file |
| Private methods | _single_underscore | __double_underscore (note: triggers name mangling in classes) |
| Named parameters | Best practice | Mandatory — use * to enforce |
| Type annotations | Encouraged | Mandatory — all params + return types |
| Strings | No hardcoding | Mandatory — all strings in constants or enums |
| Import style | Clean imports | Explicit only — no *, no folder imports |
| Platform library | General DRY | Check active variant's library first |
| File/folder ops | os/pathlib | Use platform library (see ob-library-selection.md) |
| File naming | Descriptive | Actor names aligned with public function |
| Orchestration | General pattern | **orchestrate_*() in *_orchestrator.py** |
| Error handling | Use exceptions | Specific exceptions only — no except Exception: |
| Comments | Minimal | None — code must be self-documenting |
Full rule set is in references/boro-quick-style-guide.md.
Implement Mode Additions
Before implementing any feature:
- Confirm variant from
ob-library-selection.md - Check platform library — does the active variant already have a function for this?
- Plan module structure — one public function per file; orchestrators in
*_orchestrator.py - Apply BORO naming from the start — do not name and rename later
Implementation order follows python-data-engineer (read spec → read existing code → implement in construction order → write tests → verify). Apply the BORO checklist at each step.
When the OB code under implementation is a pipeline (collect → transform → emit), follow the e2e + unit test convention from python-data-engineer § "Tests for Python Pipelines": one e2e test per top-level runner, one per thin-slice runner, plus unit tests per component. BORO test conventions (action-verb naming, 20-char lines, * named parameters, __double_underscore private helpers) apply to the test code itself — see skills/clean-code-tests/SKILL.md § "OB Overrides for Tests (Python)" for the full table.
Review Mode Additions
When reviewing OB code, apply the full python-data-engineer review checklist and add the BORO-specific checks:
| Check | Pass criteria |
|---|---|
| Class names plural | class MyObjectTypes: not class MyObjectType: |
| File = actor, function = action | data_exporter.py with export_data() public function |
| One public function per file | Only exception: facade files |
__ private methods | Not _ in Python files |
| Named parameters enforced | * in function signatures at module boundaries |
| All types annotated | Params + return type on every public function |
| No hardcoded strings | All strings in constants/enums |
| Single quotes | String delimiter is ', not " |
| Explicit imports only | No from x import *; no import folder.subfolder |
| Platform library used | Active variant's library used for file/folder/utility ops |
No bare except | Only named exception types; bare raise to preserve traceback |
| No comments | Only # TODO or development notes permitted |
Use violation severity from boro-quick-style-guide.md implementation checklist:
- HIGH: Missing type annotations; hardcoded strings; bare
except; wrong platform library - MEDIUM: Naming violations; missing
__on private methods; non-actor file names - LOW: Line length; missing named parameters; single vs double quotes
OB Quality Gates
Run after every implementation, in addition to the python-data-engineer quality gates:
ruff check src/ # linting
ruff format src/ # formatting (note: 20-char lines require manual line-break discipline)
mypy src/ --strict # type checking — strict mode required for OB (all types must be present)
pytest # all tests passNote: ruff's default line length is 88 characters. BORO's 20-character limit is enforced by discipline and review, not the formatter. Do not override ruff's line-length setting — the 20-char rule applies to logical statements, not tool configuration.
Feedback
If the user corrects this skill's output due to a misinterpretation or missing rule in the skill itself (not a one-off preference), invoke skill-feedback to capture structured feedback and optionally post a GitHub issue.
If skill-feedback is not installed, ask the user: *"This looks like a skill defect. Would you like to install the skill-feedback skill to report it?"* If the user declines, continue without feedback capture.