ワンクリックでManusで任意のスキルを実行

odoo-acceptance

スター7

フォーク3

更新日2026年7月18日 02:55

Run end-to-end Odoo acceptance on a change AND its blast-radius: map the affected cluster, plan an INDEPENDENT oracle, then EXECUTE it on a real running instance/UI and adjudicate PASS/FAIL with evidence. Fire on: acceptance test, QA the affected cluster, verify on the real UI, "write scenarios then run them", verify blast-radius, "works end-to-end before release". Also Vietnamese: "nghiệm thu cụm module", "chạy thật trên UI", "kịch bản test rồi chạy", "kiểm thử chấp nhận". Sole dispatcher of odoo-qa-planner (oracle) + odoo-qa-tester (live run); chains tours/HttpCase via odoo-instance. Routing: a STATIC release test-plan doc / deploy checklist -> route to odoo-qa-suite; rating ONE rendered screen -> route to odoo-ui-review; static code or PR review with no run -> route to odoo-code-review; writing the fix -> route to odoo-coding. EXECUTION needs a live instance + browser MCP (Odoo Semantic is static, no live data); with none up it still scopes + plans the oracle, then emits NEEDS_NEXT to provision one

インストール

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

Manusで実行

ソース

Viindoo

Viindoo/odoo-mcp-client

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

Manusで実行

関連職種SOC

SOC 職業分類に基づく

ソフトウェア品質保証アナリスト・テスターコンピュータ・数学職·SOC 15-1253

ファイルエクスプローラー

2 ファイル

SKILL.md

readonly

このリポジトリの他の Skills

同じリポジトリ

odoo-addon-diff

Viindoo/odoo-mcp-client

Produce a CE vs EE vs custom-distribution comparison for a business domain - feature table, EE-only business-value notes, and an upgrade recommendation ready for a proposal. Version-aware: uses MCP check_module_exists/model_inspect; confirm version when unspecified. Trigger when edition differences come up, even in passing. Trigger on: "CE vs EE feature table", "edition comparison", "which modules are EE-only?", "is X a CE or EE feature?", "upsell argument for EE", "PLM / Studio / Maintenance - which edition?", "which edition is module X in?". Also fires on Vietnamese: "so sánh CE và EE", "tính năng nào chỉ có ở Enterprise", "module X thuộc bản nào", "cần bản Community hay Enterprise". Trigger even when the user names a specific feature/module and asks "what edition do I need?". When the user asks about ONE feature's availability (not a comparison), route to odoo-feature-check. When they want marketing copy for the Enterprise features themselves, route to odoo-feature-highlights

2026-07-187

odoo-brl

Viindoo/odoo-mcp-client

Process a business requirement list (BRL) of any size - tens to thousands of items - into a classified, costed, dependency-ordered implementation plan. For each requirement: 4-way classification (Available-in-Odoo-CE / Available-in-Odoo-EE / Available-in-Viindoo / Custom) via double-profile odoo-semantic-mcp tool calls, a deterministic cost estimate (lookup table, no fabrication), and a requirements traceability matrix (RTM) for consultant export. Runs as a chunked sequential-outer / parallel-inner pipeline with checkpoint/resume after interruption. Fire ANY time someone pastes or points to a multi-item requirement list to scope end-to-end: "classify these 400 requirements", "turn this RFP spreadsheet into an effort + cost plan". Also fires on Vietnamese: "phân loại danh sách yêu cầu này", "biến RFP thành kế hoạch chi phí + công". For a SINGLE feature use odoo-feature-check; for a short ad-hoc gap matrix with no cost, no chunked pipeline, and no scale requirement use odoo-gap-analysis

2026-07-187

odoo-campaign-plan

Viindoo/odoo-mcp-client

Plan a multi-week, multi-channel marketing campaign for an Odoo vertical or geography push - blueprint with timeline, channel mix matrix, asset inventory, KPIs, and owner map (AI-doable vs human-required). ORCHESTRATES campaigns; does NOT draft individual content. Trigger on: "plan a campaign for", "campaign brief", "multi-channel plan for vertical X", "build a campaign blueprint", "marketing push plan for", "campaign roadmap for", "go-to-market blueprint". Also fires on Vietnamese: "lập kế hoạch chiến dịch", "kế hoạch marketing đa kênh", "chiến dịch go-to-market cho ngành X", "lộ trình truyền thông". DO NOT trigger for: individual content draft (→ odoo-content-draft), competitive positioning analysis (→ odoo-competitive-brief), feature-highlight slides for a sales deck (→ odoo-feature-highlights), capability proof for a prospect (→ odoo-capability-proof). STANDALONE-FIRST: works without MCP; OSM optional for feature-claim verification only

2026-07-187

odoo-code-review

Viindoo/odoo-mcp-client

Review Odoo code (Python, JavaScript, XML, OWL) for bugs, convention violations, security, and performance - severity-graded findings, suggested fixes, corrected version. Dispatches to the odoo-code-reviewer agent. Fire whenever code is shared with feedback intent, even without the word "review". Trigger on: "does this look correct?", "audit this PR", "should I worry about N+1?", "before I merge", "review PR #123". Also fires on Vietnamese: "review giúp đoạn này", "kiểm tra code Odoo", "code này có bug không", "soát trước khi merge", "đánh giá PR". Trigger on model overrides, write/create overrides, computed fields, OWL components, or XML view overrides - Odoo-specific failure modes a generic reviewer misses. Static analysis only - a live render/console error -> odoo-debug, rating a rendered screen's look/UX -> odoo-ui-review. Write new code -> odoo-coding. Pre-upgrade audit -> odoo-deprecation-audit. A dedicated performance-only deep scan -> odoo-perf-audit; a security-only scan -> odoo-security-audit

2026-07-187

odoo-coding

Viindoo/odoo-mcp-client

Use when someone wants to build or change Odoo behavior and needs the code written - the single front door for ALL Odoo coding and the ONLY dispatcher of the per-module odoo-coder coordinator, scoping modules and ordering by dependency. Fire on ANY request to add or change something in an Odoo module, even with no technical words (e.g. "discount can never exceed 20% of unit price", "ticking urgent sets the deadline to tomorrow"): new model/field, computed/related field, constraint, onchange/auto-fill, create/write/unlink override, access rights, migration script, OWL/JS/QWeb/SCSS widget or form/list/kanban UI. Also Vietnamese: "thêm trường / model", "override create/write", "ràng buộc", "onchange tự điền", "phân quyền đọc ghi", "widget OWL / sửa form". DO NOT trigger for non-Odoo code. Review existing code → odoo-code-review. Hook point → odoo-override-finding. Design first → odoo-solution-design. Runtime/render bug → odoo-debug. Rate a screen → odoo-ui-review. Planning/estimate → odoo-planning

2026-07-187

odoo-competitive-brief

Viindoo/odoo-mcp-client

Produce a competitive intelligence brief for a Strategist / CEO - board-ready capability matrix vs Odoo, GTM moves (user-provided only), threat assessment, and recommended response. Standalone-first - works WITHOUT OSM. Fire when user mentions a competitor alongside strategic intent: "competitor brief on", "analyze competitor X", "competitive landscape analysis", "competitive update for board", "threat assessment for", "competitive intelligence update". Also fires on Vietnamese: "phân tích đối thủ X", "brief cạnh tranh cho ban lãnh đạo", "đánh giá mối đe doạ cạnh tranh". DO NOT trigger for: (a) sales talking-point objections ("they say Odoo can't do X") → odoo-objection-handling; (b) feature comparison drill-down between Odoo versions → odoo-version-diff; (c) detailed add-on diff → odoo-addon-diff; (d) marketing copy or campaign messaging about competitive positioning → odoo-content-draft or odoo-campaign-plan; (e) simple feature availability check → odoo-feature-check

2026-07-187

name	odoo-acceptance
argument-hint	[module/cluster to accept]
description	Run end-to-end Odoo acceptance on a change AND its blast-radius: map the affected cluster, plan an INDEPENDENT oracle, then EXECUTE it on a real running instance/UI and adjudicate PASS/FAIL with evidence. Fire on: acceptance test, QA the affected cluster, verify on the real UI, "write scenarios then run them", verify blast-radius, "works end-to-end before release". Also Vietnamese: "nghiệm thu cụm module", "chạy thật trên UI", "kịch bản test rồi chạy", "kiểm thử chấp nhận". Sole dispatcher of odoo-qa-planner (oracle) + odoo-qa-tester (live run); chains tours/HttpCase via odoo-instance. Routing: a STATIC release test-plan doc / deploy checklist -> route to odoo-qa-suite; rating ONE rendered screen -> route to odoo-ui-review; static code or PR review with no run -> route to odoo-code-review; writing the fix -> route to odoo-coding. EXECUTION needs a live instance + browser MCP (Odoo Semantic is static, no live data); with none up it still scopes + plans the oracle, then emits NEEDS_NEXT to provision one

Role

Odoo acceptance conductor: own the loop that closes a change - map blast-radius -> plan an independent oracle -> execute it live across the affected cluster -> adjudicate against the oracle -> drive the fix. Keep your context clean; delegate each heavy phase to a specialist. Preserve the anti-bias invariant: oracle author, code author, and adjudicator are three different contexts (${CLAUDE_PLUGIN_ROOT}/snippets/acceptance-oracle-contract.md). EXECUTION needs a live Odoo instance (via odoo-instance) plus a browser MCP; Odoo Semantic is STATIC and never a source of live data.

Sole dispatcher of acceptance fan-out. This skill is the ONLY component that launches the odoo-qa-planner (independent oracle author) and odoo-qa-tester (live executor + adjudicator) agents. Any other skill needing an oracle authored and/or executed-and-adjudicated routes that work HERE via the Skill tool - centralizing the three-context invariant and the browser single-flight rule. Provision live execution by invoking the odoo-instance skill.

Dispatch-brief skeleton. When composing the dispatch prompt for odoo-qa-planner, odoo-qa-tester, or any other specialist agent dispatched below, fill the caller-side skeleton in ${CLAUDE_PLUGIN_ROOT}/snippets/dispatch-brief.md (read it by path) plus the target agent's family delta; never inline that file verbatim into a hard-leaf brief.

Out of Scope

A static release test-plan doc, deploy checklist, or user-level bug triage (no execution) -> odoo-qa-suite
Rating ONE rendered screen (aesthetics/a11y/perf/theme verdict, read-only) -> odoo-ui-review
Static review of a diff / PR / pasted block (no run) -> odoo-code-review
Writing or fixing the code -> odoo-coding; finding root cause of one symptom -> odoo-debug
Writing a standalone durable test (a tour/HttpCase with no live acceptance loop) -> odoo-test-writing
Authoring the oracle alone (no execution wanted) -> still THIS skill (run Phase 1 only) - it is the sole dispatcher of odoo-qa-planner; do NOT spawn the raw agent
Writing walkthrough TEXT or usage scenarios for documentation (no execution required) -> odoo-doc-walkthrough. This skill drives live UI and yields a PASS/FAIL verdict; it does NOT produce text-only scenario docs

MCP tools

Pick the right tool first. Odoo Semantic (the odoo-semantic-mcp server) is the INDEXED Odoo source-code knowledge graph: a pre-built graph + vector index of Odoo source across every indexed Odoo version (legacy through latest) and repos/editions, with inheritance, override, and cross-module impact already resolved. It gives AUTHORITATIVE STRUCTURAL facts about how Odoo source IS DEFINED, with no local checkout needed. Unique signature: indexed, cross-version, inheritance-resolved, whole-graph, checkout-free. It is a STATIC index with NO runtime/live data.

This is your PRIMARY, context-efficient source for Odoo source/structure questions - the Odoo codebase is huge and reading it directly burns context, so prefer Odoo Semantic first. Order of precedence: (1) Odoo Semantic available -> use it; (2) available but it lacks the specific detail -> THEN read the source (Read/Grep your checkout) to fill that gap; (3) unavailable -> read the source. Reading code is the FALLBACK, never the first move when Odoo Semantic can answer.

Do NOT use Odoo Semantic for:

LIVE DATA / runtime - actual record values, search/read/write real records, executing a method, this instance's installed modules -> use a live Odoo MCP server (one exposing read_record/search_records/execute_method), NOT Odoo Semantic.

Look-live-but-static tools (return indexed source, never runtime data): model_inspect, module_inspect, entity_lookup, validate_domain, validate_depends, validate_relation. These tool names look like they query a live instance but return indexed source data only. If you need live records, Odoo Semantic is the wrong server.

Session bootstrap (call once at session start):

set_active_version(odoo_version='17.0') - Pin a CONCRETE Odoo version (sentinels like 'auto' are rejected; the call doubles as a cheap reachability probe; 24h idle TTL).

Primary tools:

impact_analysis - Risk assessment of changing or removing a field, method, or model: blast radius, dependent modules, and downstream fields.
module_inspect ★ - Module-level architecture overview: manifest summary, models defined/extended, views, OWL components, QWeb templates, JS patches, module dependency chain, or test class list in one call.
model_inspect ★ - Superset inspection of an ORM model: enumerate or fully describe fields, methods, views, extenders, or a summary in one call.

Stay light on tools: pin the version once with set_active_version(odoo_version=<concrete>) (also a reachability probe) and pass that CONCRETE version into every dispatched agent brief; deep grounding happens inside the agents. Fan-out and model-tier policy: ${CLAUDE_PLUGIN_ROOT}/skills/_shared/concurrency-guard.md.

When the CHP capability probe is positive (Agent Team mode on), TaskCreate one task per dispatched work-item, inject TASK_ID + REPLY_TO: <this skill's current orchestrating context> (main when the main-context driver invoked this skill; do NOT hardcode a literal main if running nested inside a non-lead agent) + NOTIFY: into each teammate brief, poll TaskList/TaskGet, and read each result from the teammate's SendMessage push (NEVER from the .output transcript) - per ${CLAUDE_PLUGIN_ROOT}/snippets/agent-team-protocol.md. When off, dispatch

collect as today.

Inputs

A change reference (changed modules / diff / design doc), the odoo_version, and a way to reach a live instance (INSTANCE_HANDLE if a run already provisioned one, else resolve per ${CLAUDE_PLUGIN_ROOT}/snippets/instance-resolution.md, which also yields the BROWSER_MODE - headed/headless - for the live channel). Generate one slug for the run and reuse it in every artifact path below.

Phase 0 - SCOPE (verify-scope manifest)

Build the verify-scope manifest per ${CLAUDE_PLUGIN_ROOT}/snippets/acceptance-scope.md: reverse impact_analysis closure on the changed set -> rank each dependent module/screen by risk (likelihood x impact) -> enumerate the affected screens (views binding a changed symbol) -> emit install_set / test_set / render_check_set. Resolve the Tier-2 ISOLATE dir per ${CLAUDE_PLUGIN_ROOT}/snippets/state-root-resolution.md's resolve-capture-substitute protocol (captured path shown as <ISOLATE_DIR> below) and write it to <ISOLATE_DIR>/qa/<slug>-scope.md. This is the scope every later phase obeys - depth on High tier, smoke on Low.

Phase 1 - PLAN (independent oracle)

Dispatch odoo-qa-planner (tier per the model-tier SSOT - sonnet default; escalate ONLY when the requirement spans multiple hard business domains with heavy cross-module coupling, never for cluster width or scenario count alone) with REQUIREMENT (+ DESIGN_DOC §1/§9 when present), odoo_version, CHANGED_SET, the SCOPE_MANIFEST path, and SCENARIOS_PATH: <ISOLATE_DIR>/qa/<slug>-scenarios.md. It returns the immutable oracle (GWT + EP/BVA/negative + role/CRUD/state/search matrices, risk-tagged). The planner derives expected from the requirement only - it never reads the implementation to decide it.

Phase 2 - provision the cluster (once)

Provision the live instance via odoo-instance with the FULL install_set co-installed as ONE cluster (demo=on, --http-port) - co-installing surfaces MRO / load-order breaks a single-module install hides. Capture INSTANCE_HANDLE once and forward it to every dispatch below (precedence: ${CLAUDE_PLUGIN_ROOT}/snippets/instance-handle-contract.md). Provisioning and the test-run lifecycle are NOT owned here - odoo-instance (the odoo-instance-ops agent) owns create/init/run-tests/drop and grounds per-series odoo-bin flags via cli_help; this skill stays conductor/adjudicator. Lifecycle + test-invocation conventions: ${CLAUDE_PLUGIN_ROOT}/docs/reference/INSTANCE-LIFECYCLE.md and ${CLAUDE_PLUGIN_ROOT}/docs/reference/ODOO-TESTING.md.

Phase 2a - DURABLE channel (parallelizable, no browser)

For High- AND Med-tier modules in test_set, launch the odoo-test-writer agent (mode tour/HttpCase; it authors by invoking the odoo-test-writing skill inline, in its own context) to realize the oracle's user-flow scenarios as durable regression, then have odoo-instance run them (headless --test-enable). This channel uses no browser, parallelizes across ephemeral DBs, feeds CI, and MAY run concurrently with Phase 2b. Delegation boundary (writer != executor, INSTANCE_HANDLE precedence, output-volume): ${CLAUDE_PLUGIN_ROOT}/snippets/test-execution-handoff.md.

Phase 2b - LIVE channel (browser-exclusive, single-flight)

Browser work is single-flight: dispatch ONE browser-driving agent at a time, never two at once (this channel may overlap Phase 2a, which uses no browser).

High-tier screens (deep): for each High-tier module dispatch ONE odoo-qa-tester with ORACLE_PATH, the INSTANCE_HANDLE, that module's SCOPE (screens + roles), BROWSER_MODE, and REPORT_PATH: <ISOLATE_DIR>/qa/<slug>-acceptance-report.md. It drives real CRUD + at least two roles + state transitions + search on each in-scope screen and adjudicates PASS/FAIL/UNVERIFIED with evidence. Optionally, in the same serial slot, dispatch odoo-ui-reviewer for that module's screens for the read-only one-screen quality verdict (distinct from the tester's behavior verdict; do not duplicate).
Med/Low-tier screens (smoke): cover the rest of render_check_set with a smoke pass - open each screen and assert it renders with NO console error and NO 4xx/5xx (a lightweight odoo-qa-tester smoke dispatch) - so P0's "smoke on Low" is actually executed, not just computed.

Between Phase 2a/2b and Phase 3, call allocator.py heartbeat <token> on the cluster's INSTANCE_HANDLE so the TTL backstop never reaps this long-lived run while the fix-loop below is still iterating. Full rule: ${CLAUDE_PLUGIN_ROOT}/snippets/resource-teardown-contract.md T3.

Phase 3 - ADJUDGE + fix-loop (bounded)

Read the tester report and durable results, reconcile them against the oracle, and produce the acceptance verdict + consolidated bug list (severity / repro / expected-vs-actual / suspected module). On any FAIL, drive the fix yourself: odoo-debug for root cause -> odoo-coding for the fix -> re-run the failed scenarios on whichever channel failed (Phase 2a durable and/or Phase 2b live). Bound the loop to 3 iterations; if still not clean, STOP and escalate with what remains - never loop forever. A UNVERIFIED on a High-tier scenario blocks ACCEPTED until evidence is obtained.

Release on the final verdict (conditions DONE). Once the verdict is final (ACCEPTED, or the 3-iteration escalation STOP), RELEASE the Phase 2 cluster instance you provisioned - via odoo-instance or allocator.py release <token> --run-id <id> - before emitting your terminal status. Do NOT release between iterations of the fix-loop above (the re-runs need the same live cluster); release exactly once, after the verdict is final. DONE is not valid while that instance is still leased. Full rule: ${CLAUDE_PLUGIN_ROOT}/snippets/resource-teardown-contract.md T0/T1/T3.

Output

<ISOLATE_DIR>/qa/<slug>-scope.md - the verify-scope manifest
<ISOLATE_DIR>/qa/<slug>-scenarios.md - the immutable oracle (planner)
<ISOLATE_DIR>/qa/<slug>-acceptance-report.md - per-scenario verdict + evidence + bug list (tester), with the final ACCEPTED/REJECTED roll-up

Standalone-first fallback

When Odoo Semantic is unreachable, structural grounding falls back to the local checkout (${CLAUDE_PLUGIN_ROOT}/snippets/osm-first-contract.md §4): derive the closure from disk (__manifest__.py depends + grep for _inherit) and label the manifest "closure approximate from disk". When NO live instance + browser MCP is reachable, EXECUTION cannot run: still produce Phase 0 scope and the Phase 1 oracle, then emit NEEDS_NEXT -> odoo-instance to provision one (${CLAUDE_PLUGIN_ROOT}/snippets/test-execution-handoff.md); fall back to BLOCKED only when provisioning is impossible. Never report ACCEPTED without live evidence.

Continuation Contract

When you finish, append a Continuation Contract block per ${CLAUDE_PLUGIN_ROOT}/snippets/continuation-contract.md (status / produced / next). Set produced to the artifact paths written. Emit NEEDS_NEXT -> odoo-debug / odoo-coding while FAILs remain (or -> odoo-instance when execution is blocked on provisioning); DONE only on ACCEPTED with evidence.