reviewing-erp-doc

Reviews generated ERP technical documentation against X.13 sources and DIVA reference rules.

6|Updated May 11, 2026
One-click install
npx skills add https://github.com/divalto/divalto-ia-devkit --skill reviewing-erp-doc-divalto
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: reviewing-erp-doc
Source: https://github.com/divalto/divalto-ia-devkit/tree/main/plugins/divalto-devkit/skills/reviewing-erp-doc
Command: npx skills add https://github.com/divalto/divalto-ia-devkit --skill reviewing-erp-doc-divalto

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill requires jinja2, and includes scripts (resource) and references (resource) components.

What problem does it solve? Technical documentation generated by an LLM-based producer (documenting-erp) can contain hallucinated claims, misread source code, or structural omissions that the producer itself cannot detect. This Skill acts as an independent second voice that re-reads the deliverable and challenges every assertion against the original X.13 sources, the SQL schema, and the DIVA reference corpus before publication. ## Core Features & Use Cases - Four error categories: Detects E1 (unsourced narrative claims), E2 (narrative misaligned with its cited source), E3 (structural omissions of fields, indexes, or foreign keys), and E4 (contradictions with the DIVA reference documentation), each with deterministic severity rules. - Hybrid deterministic + LLM pipeline: Regex-based detectors and vendored parsers (.dhsd, .dhsf, X.13 context extraction) handle structural checks, while an LLM pass evaluates semantic alignment between narrative and cited code context. - Strict read-only review: Produces review.md, review.json, and review.stats.json reports with a severity-ranked verdict (publishable / corrections needed / CA4 regression) and a producer coverage ratio, without ever modifying the deliverable or the reference docs. - Use Case: After generating documentation for the DAV module (entities CLI, FOU, ART, SOC, VRP), run this Skill to catch a planted misreading such as "CLI.Bloque = client actif" contradicting the cited source line, and receive an editorial synthesis plus a machine-readable report. ## Quick Start Review the UC-200 deliverable for the DAV module against the X.13 sources and DIVA reference docs, then show me the severity-ranked report and verdict.

Frequently Asked Questions about reviewing-erp-doc

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I review LLM-generated technical documentation for accuracy?

Run this Skill on the deliverable directory produced by documenting-erp. It ingests the YAML entities, runs deterministic detectors for unsourced claims and structural omissions, then uses an LLM pass to compare each narrative against 20 lines of cited source context, producing a severity-ranked report.

What types of documentation errors does this review detect?

It detects four categories: E1 unsourced narrative claims (error), E2 narrative misaligned with its cited source (warning), E3 structural omissions of fields, indexes, or foreign keys (error), and E4 contradictions with the DIVA reference docs (warning). Categories are mutually exclusive with E1 taking priority.

Does the review modify the generated documentation or reference files?

No, the Skill enforces strict read-only access on both the UC-200 deliverable and the DIVA reference corpus. It only signals issues in separate review.md, review.json, and review.stats.json outputs; the collaborator arbitrates any corrections downstream.

Can the review run without access to the DIVA reference docs?

Yes, pass 'skip' as the docs-root parameter. The E4 contradiction detection is then skipped or limited to the hardcoded suffix-to-Nature taxonomy, and a global warning is recorded in the final report noting that E4 was not fully verified.

Why do two review passes on the same deliverable need idempotence?

Idempotence guarantees that two runs on identical inputs produce identical reports, excluding timestamps. Items are sorted deterministically by entity, category, severity, and source line, so any diff between runs indicates a real change rather than ordering noise.