Getting it into your agent
This one installs as part of its plugin. Adding the marketplace and installing the plugin brings it with everything else the plugin ships.
/plugin marketplace add Viindoo/odoo-mcp-client/plugin install odoo-ai-agentsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/viindoo/odoo-mcp-client/odoo-pr-monitoring)<a href="https://agentmods.dev/skills/viindoo/odoo-mcp-client/odoo-pr-monitoring"><img src="https://agentmods.dev/badge/skills/viindoo/odoo-mcp-client/odoo-pr-monitoring/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/viindoo/odoo-mcp-client/odoo-pr-monitoring"><img src="https://agentmods.dev/badge/skills/viindoo/odoo-mcp-client/odoo-pr-monitoring.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00267 | $0.04899 |
| Opus 5 | $0.00133 | $0.02449 |
| Sonnet 5 | $0.00053 | $0.00980 |
| Haiku 4.5 | $0.00027 | $0.00490 |
Grade C, and why
odoo-pr-monitoring scanned grade C with 1 finding against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 9d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Recursive force deletehighDestructive command
rm -rf with a variable or a broad path is one typo away from removing the wrong tree.
`find <ISOLATE_DIR>/pr-monitoring/ -maxdepth 1 -type f -name '*.md' -mmin +43200 -exec rm -rf {} +` How it starts
The opening of the file, as written. The whole thing — 266 lines — stays where its author put it; the contents beside it link to each section on GitHub.
odoo-pr-monitoring - the post-PR lifecycle owner (poller)
Where this sits in the flow
Begins where run-harness's terminal integrate land-tail stops at "PR opened": once every node in
that repo is terminal and a DONE verification node covers every module its coding nodes touched,
run-harness squashes the repo's run-integration branch, fresh FIRST-pushes it (non-force), opens ONE
PR for that repo (run-integration -> principal), and STOPS (never merges). The surviving invariant is
exactly ONE PR per repo per run. monitor and merge are ORDINARY plan nodes that run-harness's
pick_ready dispatches like any other node - monitor depends_on integrate, merge depends_on monitor - and this skill is what runs each time either is dispatched; run-harness never
materializes a second one dynamically. CI runs minutes-to-hours and review takes hours-to-days, so a
dispatch of monitor never holds the run's turn open for that long: each poll tick reads once,
classifies, and PARKS - it emits a NEEDS_NEXT Continuation Contract naming itself in next[] so the
driver's turn ends cleanly, and a later /loop tick or /schedule cron re-invocation re-attaches via
run-<id>.json and resumes. Once the watch classifies green + approved + mergeable, the monitor
node itself reaches DONE - it does NOT also perform the merge; that is the separate merge node's
job, dispatched only once monitor is DONE, so the outward L2 gate keeps its own depends_on edge
and its own gate_log entry.
run-harness's last verification node for this repo closes green -> integrate land-tail: squash + fresh first-push + open ONE PR -> STOP at "PR opened"
--- `monitor` node (run-harness dispatches it like any other node; each tick PARKS via NEEDS_NEXT instead of blocking the turn) ---
odoo-pr-monitoring (poll via /loop in-session | /schedule cron)
-> any CI warning/error/fail -> odoo-debug (D3: root-cause) -> odoo-coding (fix)
-> proposed re-push is HUMAN-GATED (X2); max_review_rounds cap; exhaustion -> BLOCKED
-> green + approved + mergeable -> `monitor` node reaches DONE
--- `merge` node (depends_on: monitor; run-harness dispatches it once monitor is DONE) ---
odoo-pr-monitoring -> present merge approval gate -> merge (git-ops)
-> post-merge cleanup (worktrees/branches/tag via git-ops)
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 9d ago First seen · 266 lines · 267 tokens per session scan C 4e2be782a01f
odoo-pr-monitoring is a skill published in the GitHub repository Viindoo/odoo-mcp-client (7 stars, last pushed 6d ago), licensed MIT. It adds 267 tokens to every session and 4,899 once invoked, about $0.0013 per session on Opus 5. A static security scan graded it C with 1 finding (recursive force delete). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-03.
Other skills, from other repositories
github-release-management
Comprehensive GitHub release orchestration with AI swarm coordination for automated versioning, testing, deployment, and rollback management.
deployment-patterns
Deployment workflows, CI/CD pipeline patterns, Docker containerization, health checks, rollback strategies, and production readiness checklists for web applications. Use when setting up deployment infrastructure or planning releases.
agent-github-modes
Agent skill for github-modes - invoke with $agent-github-modes.
baby-sit
Monitor a GitHub pull request until CI is green, diagnose failures, and rerun only evidence-backed flaky GitHub Actions jobs.
chinese-git-workflow
A reference for configuring Git with Chinese code-hosting services such as Gitee, Coding.net, GitLab China, and CNB, including SSH, HTTPS, credentials, CI, and repository mirroring.
atmos-hooks
Atmos hooks: lifecycle events, hook kinds, command/store/git/security hooks, step/steps hooks, when: conditions, scoping and overrides, toolchain integration, --skip-hooks, and Atmos Pro/local output.