tuanle96

Build a lightweight skill index and load full skill instructions only on demand to reduce startup context pressure.

Select and run a multi-agent workflow pattern for work that exceeds one agent's reliable scope. Use for parallel research, independent reviews, cross-domain changes, or high-risk implementation planning.

Select and run a multi-agent workflow pattern for work that exceeds one agent's reliable scope. Use for parallel research, independent reviews, cross-domain changes, or high-risk implementation planning.

Use composable middleware behaviors for provider/tool execution: retry, caching, timeout, telemetry, and budget guards.

Use this skill whenever the agent makes a mistake, the user observes an avoidable failure, a pattern recurs, or someone says "the agent keeps doing X". Files an "Engineer the Harness" entry — Mitchell Hashimoto's discipline: every failure becomes a permanent prevention mechanism. Always invoke this instead of just fixing the immediate symptom.

Use composable middleware behaviors for provider/tool execution: retry, caching, timeout, telemetry, and budget guards.

Use this skill whenever the agent makes a mistake, the user observes an avoidable failure, a pattern recurs, or someone says "the agent keeps doing X". Files an "Engineer the Harness" entry — Mitchell Hashimoto's discipline: every failure becomes a permanent prevention mechanism. Always invoke this instead of just fixing the immediate symptom.

Build a compact read-only context packet for a natural-language codebase question. Use before editing unfamiliar code, when tracing task evidence, contracts, validation, or proof paths, or when the relevant files are not obvious.

Customizing or extending a STANDARD Odoo business app — sale (quotation → order → delivery → invoice), stock / inventory (pickings, moves, reservation, lots), account / accounting (invoices, bills, taxes, posting), mrp / manufacturing (BoM, production, components), purchase (RFQ → PO → receipt → bill), or hr (employees, time-off). Use whenever the work touches one of these domains, even if the user doesn't say the word "skill" — any time you'd otherwise GUESS which method to override, which hook builds the next document, or how the sale→stock→account chain fires. Also holds COUNTRY/REGIME playbooks — currently Vietnamese accounting compliance (VAS, TT200→TT99 2026, e-invoice, VAT/CIT calendar, statutory reports). Each app here is a STARTING MAP of the key models, the methods to read first, and the right extension hook — NOT ground truth. Confirm every name against the running instance with the `odoo-introspect` skill before you write a line.

Authoring or customizing Odoo 17/18/19 QWeb reports — the printable PDF/HTML documents (invoices, sale orders, pickings, custom certificates). Use when creating an ir.actions.report, writing or inheriting a QWeb report template, adding a report.<module>.<name> parser to feed extra data, fixing paperformat / margins / page breaks, translating a report per partner language, or debugging "my changes don't show / wrong template / values undefined in the PDF". Don't guess the template id or whether a parser exists — find the existing report with the `odoo-introspect` skill first, then inherit. NOT for the dynamic financial-statement grids under Accounting → Reporting (P&L, balance sheet, tax reports) — those are the `account.report` engine: use `odoo-statutory-reports`.

Entry point and router for doing Odoo development with an AI agent. Start here whenever a task touches an Odoo codebase and you're not sure which specific skill applies — it maps the task to the right one (introspection, models & overrides, module scaffolding, views, OWL frontend, security, testing, reports, data/sequences, migration, deploy, or domain playbooks), even if the user never says the word "skill". The rule shared by every skill in this suite: Odoo composes each model at runtime from the installed addon graph, so READ GROUND TRUTH FROM THE RUNNING INSTANCE FIRST, then build — never guess fields, MRO, super() chains, view arch, or security. Targets Odoo 17/18/19.

Building or customizing DYNAMIC financial statements with Odoo's account.report engine (Enterprise `account_reports`) — P&L, balance sheet, cash-flow, tax reports, and country statutory formats (VAS, HGB, PCG, …). Use when defining account.report / account.report.line / account.report.expression records, choosing an engine (domain / aggregation / account_codes / custom handler), fixing wrong totals or period semantics (date_scope), writing a `_report_custom_engine_*` method, versioning a report for a new accounting regime, verifying a statutory report is complete/balanced, or exporting multi-sheet data packs a grid can't hold. NOT for QWeb PDF documents (invoices, pickings) — that's `odoo-reports`.

Isolated feature development for a LIVE Odoo dev environment using git worktree — build/test on the running instance while committing to a clean branch cut from production, without touching prod or the active dev branch. Use whenever a feature must not land on the current dev/uat branch yet (pending approval/training), when the Odoo container mounts the main working tree (so you can't just switch branches), when syncing changes between a worktree branch and the live working copy, or when packaging ORM-created records into an addon that must install identically on a clean DB (post_init_hook adopt-vs-create + clean-install test ritual).

Migrate Odoo custom modules and databases between major versions, currently specialized for Odoo 18 -> 19. Use this skill WHENEVER the user mentions upgrading Odoo, migrating a module/addon to a new version, "port to 19", version bump, breaking changes between Odoo versions, writing migration scripts (pre/post/end-migrate), OpenUpgrade, upgrade.odoo.com, or fixing a module that fails to install after an upgrade — even if they don't use the word "migration". Also trigger when a traceback clearly comes from version-incompatible code (removed model/field/xmlid, tree->list, _sql_constraints, type='json' routes).

Writing Odoo upgrade/migration scripts — when a module bump needs code beyond what the ORM does on -u, and how to write it. Use whenever renaming a field or model, changing a field's type, backfilling a new required field, merging or moving data, dropping obsolete columns, recomputing a changed stored compute, or asking "will -u handle this automatically or will I lose data?". Covers the migrations/<version>/ pre-/post-/end- layout, the migrate(cr, version) hook, odoo.upgrade.util / openupgradelib helpers, and version bumps. Read the live field inventory from odoo-introspect before assuming a column's name or type.

Shipping data with an Odoo module — XML/CSV data files, seeded records, ir.sequence numbering, and configuration via res.config.settings / ir.config_parameter. Use whenever adding records to data/ or demo/, writing <record>/<field> XML, wiring external IDs (ref/eval/command tuples), setting noupdate, ordering the __manifest__ data list, generating document numbers, or chasing "my edit reverts on -u" / "duplicate seeded record" bugs. Don't guess what's already seeded or whether a record is protected — read ground truth from ir.model.data via odoo-introspect's metadata script first.

Use this skill whenever a decision is made about architecture, dependencies, frameworks, naming conventions, or layer order. Creates a numbered ADR (Architecture Decision Record) in `.harness/docs/adr/` in the canonical Nygard format. Always invoke this before changing layer order, adding a layer, swapping a major dependency, or introducing a new external service.

Use this skill whenever the user asks to add, implement, or build a new feature, capability, endpoint, page, command, or anything user-visible. Enforces the Anthropic two-fold harness pattern — read .harness/feature_list.json, pick exactly one feature, implement incrementally, run the structural test on every save, and never declare "done" without updating the JSON. Always invoke this skill instead of writing new feature code freehand.

Use this skill whenever the user reports a bug, unexpected output, or "this doesn't work". Runs the dev server, drives the failing flow via Playwright MCP if installed (else captures stdout/stderr), and produces a minimal repro before any fix. Mirrors the OpenAI Chrome-DevTools-Protocol-into-runtime pattern at solo scale — verify the failure before you propose a fix.

Use this skill whenever the user asks to analyze, audit, review, summarize, produce a report, write a plan, make a proposal, draft a decision doc, list "next actions", or any other task that produces a DOCUMENT a HUMAN reads-and-acts-on. Outputs a self-contained <slug>.html at repo root using the shared dark-theme CSS. Why HTML and not Markdown: golden principle #9 — Markdown is great for files an agent reads-and-edits (CLAUDE.md, SKILL.md, ADRs), but a HUMAN reading a 700-line MD deliverable will scroll, miss the conclusion, and ask the agent to clarify — burning turns and tokens. HTML deliverable is read once, decided once. Do NOT use this skill for files the agent itself reads (those stay MD), for stdout output from /review-this-pr or /garbage-collection (pass-through MD), or for short summaries under ~30 lines (overhead not worth it).

Use this skill weekly, before releases, or when the user mentions "stale docs", "doc drift", "docs are wrong", or "the README is out of date". Cross-checks every code path, file path, and command referenced in `.harness/docs/` and `CLAUDE.md` against the current repo state and produces a list of stale references — the doc-gardening agent pattern.

Use this skill whenever a skill, subagent, or hook is changed, before merging to main, or when the user mentions "eval", "regression test for the harness", or "is the harness still working". This skill is a thin wrapper — it runs a single shell command (`npm run harness:eval` or `python -m harness.eval_runner`) and summarizes the JSONL output. Do not implement the eval logic yourself; the runner is already deterministic.

Use this skill on Fridays, before tagging a release, or when the user mentions "cleanup", "tech debt", "AI slop", "GC", or "garbage collection". Runs the deterministic linters, structural tests, and doc-drift scans, then proposes the top-3 highest-leverage cleanups (with risk/cost/benefit) — does NOT auto-merge. This is the solo-dev shrunk version of OpenAI's Friday garbage-collection ritual.

Use this skill to scaffold a new human-language locale for the kit's skills/agents/CLAUDE.md. Mirrors every existing SKILL.md.hbs into a SKILL.md.<locale>.hbs stub so a translator (or LLM) can edit copy without touching machine-readable frontmatter. Default locale codes — vi, ja, fr, es, de — but accepts any 2-5 char code.

Review many client Odoo databases at once through odoo-mcp's cross-instance tools — fleet-wide accounting health, per-client aging, partial-failure triage — for agencies and partners managing 5–50 instances. Use when the user asks "which client...", "across all instances/databases", or wants a fleet/portfolio status.

Audit an Odoo database's data quality with evidence before trusting AI answers, importing, or migrating — duplicates, missing required values, orphaned references, format anomalies — and drive remediation through odoo-mcp's gated write workflow. Use when the user asks to "check data quality", "clean up data", "prepare for migration", "find duplicates", or when aggregate answers look suspicious.

Plan and de-risk an Odoo version upgrade (16→17→18→19/20) using odoo-mcp's migration workbench — audit custom addons, classify upgrade-log failures into a worklist, resolve model renames, and preview JSON-2 payloads for the XML-RPC sunset. Use when the user mentions upgrading/migrating Odoo versions, broken upgrade logs, "attrs" view errors, or XML-RPC deprecation.

Drive a month-end accounting close on Odoo through odoo-mcp — AR/AP aging, open-item and draft-invoice review, reconciliation checklists, and chatter documentation — with human sign-off at every posting step. Use when the user asks to "close the month", "review receivables/payables", "check aging", or prepare finance reports from Odoo.