---
name: ai-documents-validation-document-type
description: Develop, extend, plan, review, or integrate supported document types in the ai-documents-validation/docvalidator repository. Use when Codex must add a new document type, modify field extraction parsers, align classification REFERENCE_TEXTS, field diagnostics, business rules, reliability, API catalog, CLI, tests, public documentation, or integrate the FastAPI validation API into another application for E:\ai-documents-validation or the canonical ai_documents_validation project.
---

# AI Documents Validation Document Type

Specialist skill for `ai-documents-validation` / `docvalidator`. Use it to keep document-type changes complete across classification, extraction, diagnostics, rules, reliability, API/CLI, tests, docs, and API consumers.

## Start Here

1. Resolve `project_path` from the prompt, current workspace, or known paths:
   - `E:\ai-documents-validation`
   - `S:\ai_projects\ai_documents_validation`
2. Read the target repo `AGENTS.md` first.
3. Apply the repo docs-first policy before relying on Markdown files. See [references/docs-first-policy.md](references/docs-first-policy.md).
4. For new or changed document types, load [references/new-document-type-checklist.md](references/new-document-type-checklist.md).
5. For parser or extraction changes, load [references/diagnostic-contract.md](references/diagnostic-contract.md).
6. For external app integration, load [references/api-integration.md](references/api-integration.md).
7. For verification, load [references/test-and-validation.md](references/test-and-validation.md).

## Core Workflow

For a document-type change:

1. Read existing implementations before editing: `durc.py`, `identity.py`, extraction router, `rules.py`, `reliability.py`, API catalog, CLI, and related tests.
2. Define document code, classification markers, extracted fields, mandatory fields, KO/WARNING rules, context inputs, and fixtures before coding.
3. Implement parser with full field diagnostics; never add only `REFERENCE_TEXTS`.
4. Keep router, rules, reliability, API catalog, CLI, tests, README, and `_documentation/` aligned in the same change.
5. Run targeted tests first, then broader API/non-slow tests based on impact.

For API integration into another application:

1. Treat `docvalidator` as a separate FastAPI service by default.
2. Use `GET /api/v1/health`, `GET /api/v1/supported-types`, and `POST /api/v1/validate`.
3. Model consumer behavior on machine-readable fields: `status`, `issues`, `extracted_fields`, `field_diagnostics`, and `metadata`.
4. Distinguish HTTP errors from validation `status = "KO"`.
5. Cover auth, CORS, privacy, request IDs, and consumer tests.

## Boundaries

- Use `mcp-technical-analyst` first when the task starts from tickets, commits, attachments, DB evidence, or mixed sources to reconstruct.
- Use `mcp-master-orchestrator` when the work needs multi-phase coordination across several skills.
- Use `mcp-code-reviewer` for generic diff/commit/PR review not specific to this document-validation domain.
- Use `mcp-docs-navigator` for pure docs shelf/search/tagging work.
- Use `mcp-office-expert` if source PDFs/DOCX must be extracted before parser design.

## Stop Conditions

Stop and surface the issue when:

- required document fields or business rules are unknown;
- project docs conflict with code and no local evidence resolves it;
- real PDF examples contain sensitive data that would be committed or logged;
- a new context/API parameter would affect external consumers but has no explicit contract;
- changes touch server/API runtime and the user must restart or refresh the MCP/Codex environment.

## References

- [references/new-document-type-checklist.md](references/new-document-type-checklist.md)
- [references/docs-first-policy.md](references/docs-first-policy.md)
- [references/diagnostic-contract.md](references/diagnostic-contract.md)
- [references/api-integration.md](references/api-integration.md)
- [references/test-and-validation.md](references/test-and-validation.md)