Feat/enhanced agents and regulatory templates#2
Conversation
Signed-off-by: Jefferson Rodrigues <jefferson.rodrigues@lerian.studio>
Signed-off-by: Jefferson Rodrigues <jefferson.rodrigues@lerian.studio>
Signed-off-by: Jefferson Rodrigues <jefferson.rodrigues@lerian.studio>
Signed-off-by: Jefferson Rodrigues <jefferson.rodrigues@lerian.studio>
Signed-off-by: Jefferson Rodrigues <jefferson.rodrigues@lerian.studio>
Signed-off-by: Jefferson Rodrigues <jefferson.rodrigues@lerian.studio>
Signed-off-by: Jefferson Rodrigues <jefferson.rodrigues@lerian.studio>
Initial setup for regulatory templates - handles template selection and context initialization. Signed-off-by: Jefferson Rodrigues <jefferson.rodrigues@lerian.studio>
Gate 1 of regulatory templates - performs regulatory compliance analysis and field mapping. Signed-off-by: Jefferson Rodrigues <jefferson.rodrigues@lerian.studio>
Gate 2 of regulatory templates - validates uncertain mappings and confirms all field specifications. Signed-off-by: Jefferson Rodrigues <jefferson.rodrigues@lerian.studio>
Gate 3 of regulatory templates - generates the complete .tpl template file with all validated mappings. Signed-off-by: Jefferson Rodrigues <jefferson.rodrigues@lerian.studio>
Main orchestrator for Brazilian regulatory templates (BACEN CADOCs, e-Financeira, DIMP, APIX) to Midaz/Reporter mapping. Orchestrates 3-gate validation process through modular sub-skills with dynamic context passing, culminating in template file generation. Signed-off-by: Jefferson Rodrigues <jefferson.rodrigues@lerian.studio>
…mplates - Add multi-tenancy, OAuth2/WorkOS auth, and AWS Lambda support to backend-engineer-golang agent - Expand devops-engineer with GitHub Actions, Helm, Terraform deep expertise and multi-tenancy infra - Update finops-analyzer/creator documentation paths for regulatory templates - Add interactive validation workflow for templates without data dictionary in gate1 - Implement hierarchical template selection (authority → specific template) in setup skill - Standardize dictionary base path across all regulatory skills Signed-off-by: Claude <noreply@anthropic.com>
Add documentation for Brazilian regulatory compliance templates: - Reporter template guide with format specifications - RFB DIMP v10 manual reference - RFB e-Financeira specifications - BACEN CADOC 4010/4016 documentation Generated-by: Claude AI
WalkthroughThis pull request introduces a comprehensive documentation and configuration framework for AI agent roles and a regulatory template processing system. It adds seven new agent specifications (Backend Engineer (Go), DevOps Engineer, Frontend Engineer, QA Analyst, SRE, FinOps Analyzer, and FinOps Creator) defining responsibilities, technical expertise, and scope boundaries. Additionally, it establishes a Brazilian regulatory template infrastructure including data dictionaries (YAML), XML schemas (XSD), validation examples, and a multi-gate workflow orchestration system for processing templates through specification analysis and template generation phases. A schema helper module and comprehensive reference guides (reporter template reference, registry) support the regulatory processing pipeline. Sequence Diagram(s)sequenceDiagram
participant User
participant Orchestrator as Orchestrator<br/>(regulatory-templates)
participant Setup as Setup<br/>(gate-setup)
participant Gate1 as Gate1<br/>(placeholder-mapping)
participant Analyzer as FinOps<br/>Analyzer
participant Gate2 as Gate2<br/>(validation)
participant Gate3 as Gate3<br/>(template-gen)
participant Creator as FinOps<br/>Creator
User->>Orchestrator: Initiate workflow
Orchestrator->>Setup: Execute setup sub-skill
activate Setup
Setup->>User: Authority & template selection
User-->>Setup: Selections + deadline
Setup-->>Orchestrator: Return: setup context
deactivate Setup
rect rgb(200, 220, 255)
Note over Orchestrator,Analyzer: Gate 1: Specification & Placeholder Mapping
Orchestrator->>Gate1: Dispatch with setup context
activate Gate1
Gate1->>Gate1: Map placeholders to snake_case<br/>Add data source prefixes
Gate1-->>Orchestrator: Placeholder mappings
deactivate Gate1
Orchestrator->>Analyzer: Dispatch to finops-analyzer agent
activate Analyzer
Analyzer->>Analyzer: Regulatory compliance analysis<br/>Field mapping validation<br/>Risk assessment
Analyzer-->>Orchestrator: Return: Specification Report
deactivate Analyzer
end
rect rgb(220, 255, 220)
Note over Orchestrator,Gate2: Gate 2: Technical Validation
Orchestrator->>Gate2: Dispatch with Gate1 results
activate Gate2
Gate2->>Gate2: Validate uncertain mappings<br/>Apply template-specific rules<br/>Cross-field validation
Gate2-->>Orchestrator: Return: Validation results + merged context
deactivate Gate2
end
rect rgb(255, 240, 200)
Note over Orchestrator,Creator: Gate 3: Template Generation
Orchestrator->>Gate3: Dispatch with Gate2 context
activate Gate3
Gate3->>Creator: Dispatch to finops-automation agent
activate Creator
Creator->>Creator: Generate .tpl template<br/>Apply Reporter filters<br/>Validate output
Creator-->>Gate3: Production .tpl + documentation
deactivate Creator
Gate3-->>Orchestrator: Return: Generated template files
deactivate Gate3
end
Orchestrator-->>User: Workflow complete: .tpl template<br/>Specification report
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Tip 📝 Customizable high-level summaries are now available in beta!You can now customize how CodeRabbit generates the high-level summary in your pull requests — including its content, structure, tone, and formatting.
Example instruction:
Note: This feature is currently in beta for Pro-tier users, and pricing will be announced later. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 7
🧹 Nitpick comments (12)
default/docs/regulatory/templates/BACEN/CADOC/cadoc-4010-4016.md (1)
60-144: Tidy up markdownlint issues (code block languages, tables, bare URLs)markdownlint is flagging a few style issues that are easy to fix and will help automated docs tooling:
- Add a language to fenced code blocks that are currently untyped (e.g., the ASCII diagrams and hierarchy) –
textusually works well here.- Ensure tables are surrounded by blank lines for MD058.
- Convert bare URLs into markdown links to address MD034.
For example:
-``` +```text ┌──────────────────────────────────────────────┐ ... -``` +``` -### 1.5 Prazos de Envio - -| Documento | Prazo | +### 1.5 Prazos de Envio + +| Documento | Prazo | |-----------|-------| | **4010** | Dia 18 do mês seguinte à data-base (ou dia útil subsequente) | | **4016** | Último dia útil do mês seguinte à data-base | + ... -- **Sistema**: STA - Sistema de Transmissão de Arquivos -- **URL**: https://www.bcb.gov.br/meubc/sistematransferenciaarquivos +- **Sistema**: STA - Sistema de Transmissão de Arquivos +- **URL**: [https://www.bcb.gov.br/meubc/sistematransferenciaarquivos](https://www.bcb.gov.br/meubc/sistematransferenciaarquivos)Also applies to: 214-265
default/skills/regulatory-templates-gate1/schemas/field-extraction.js (1)
3-68: Stabilize schema map and clarify expected template namesThe implementation is correct as-is, but a few small improvements would make it more robust:
- Avoid recreating the
schemasmap on every call; define it once at module scope.- If callers might customize schemas at runtime, consider returning a clone instead of the shared object.
- Ensure
templateNamevalues passed in (e.g., from the registry or orchestrator) exactly match"CADOC 4010"/"CADOC 4111"; otherwise everything silently falls back to the base schema.For example:
-const cadoc4111Schema = { +const cadoc4111Schema = { ...baseFieldSchema, properties: { ...baseFieldSchema.properties, specificFields: { type: "object", properties: { contaCosif: { type: "string" }, saldoDiario: { type: "number" }, dataMovimento: { type: "string" } } } } }; -function getFieldExtractionSchema(templateName) { - const schemas = { - "CADOC 4010": cadoc4010Schema, - "CADOC 4111": cadoc4111Schema, - "default": baseFieldSchema - }; - - return schemas[templateName] || schemas.default; -} +const SCHEMAS = { + "CADOC 4010": cadoc4010Schema, + "CADOC 4111": cadoc4111Schema, + default: baseFieldSchema +}; + +function cloneSchema(schema) { + return JSON.parse(JSON.stringify(schema)); +} + +function getFieldExtractionSchema(templateName) { + const schema = SCHEMAS[templateName] || SCHEMAS.default; + return cloneSchema(schema); +}To double-check the name matching, you can grep where
getFieldExtractionSchemais called and confirm thetemplateNamestrings align with the keys inSCHEMAS.default/skills/regulatory-templates-gate3/SKILL.md (1)
45-45: Add language specifiers to fenced code blocks for improved readability.Multiple code blocks lack language identifiers, which affects syntax highlighting and markdown validation. Lines 45, 138, 145, 209, and 222 all have
```without a language specifier.Apply language specifiers to all fenced code blocks:
- Line 45: -``` +``` +GATE 3: TEMPLATE FILE GENERATION - Line 138: -``` +``` When executing Gate 3, call the Task tool with: - Line 145: -``` +``` - Line 209: -``` +``` SKILL: regulatory-templates-gate3 - Line 222: -``` +``` SKILL: regulatory-templates-gate3Per markdown best practices (markdownlint MD040), all fenced code blocks should include language specifiers.
Also applies to: 138-138, 145-145, 209-209, 222-222
default/agents/finops-analyzer.md (1)
118-131: Add language specifiers to fenced code blocks.Lines 147, 159, and 170 contain code blocks without language identifiers. Line 186 (YAML example) should specify
yamlto enable proper syntax highlighting.Add language specifiers:
- Line 118: ### Executive Summary Structure -```markdown +```markdown - Line 147: Fenced block without language → add `markdown` - Line 159: Fenced block without language → add `markdown` - Line 170: Fenced block without language → add `markdown` - Line 186: Should be `yaml` instead of generic ```These changes follow markdown best practices (MD040) and improve readability with proper syntax highlighting.
Also applies to: 144-180, 186-219
default/skills/regulatory-templates-gate1/SKILL.md (2)
58-88: Add blank lines around tables per markdown formatting guidelines.Tables at lines 58, 88, 187-196, and 1256-1262 lack blank lines before and after them, violating MD058. This affects readability and markdown linting.
Add blank lines before and after each table:
+ [blank line] | Data Source | Description | | ... | + [blank line]This applies to:
- Lines 58-60: "Available Data Sources" table
- Lines 88-93: "Common Regulatory Field Mappings" table
- Lines 187-206: "Templates WITH Dictionary" table (and the REQUIRE Interactive table)
- Lines 1257-1262: "Issue/Solution" table
These changes follow markdown best practices (MD058).
Also applies to: 187-196, 1256-1262
211-211: Add language specifiers to fenced code blocks.Multiple code blocks lack language identifiers (MD040). Add language specifiers to improve syntax highlighting:
- Line 211: Diagram/flowchart - use comment block or remove fence
- Line 756: JavaScript-like pseudo code - specify
javascriptorjs- Line 1011: JavaScript-like pseudo code - specify
javascriptorjs- Line 1196: Status output - specify
textorplaintext- Line 1212: Status output - specify
textorplaintextExample fix:
-``` +```javascript // HIERARCHICAL SEARCH const dictionaryPath = ... -``` +``` -``` +```text SKILL: regulatory-templates-gate1 STATUS: PASSED -``` +```Following markdown best practices (MD040).
Also applies to: 756-756, 1011-1011, 1196-1196, 1212-1212
default/skills/regulatory-templates/SKILL.md (1)
55-93: Add language specifier to ASCII diagram code block.The workflow diagram uses a plain code block without a language specifier. While this is valid Markdown, adding
textorplaintextimproves linter compliance and editor rendering.-``` +```text ┌─────────────────────┐ │ ORCHESTRATOR │default/docs/regulatory/dictionaries/apix-001.yaml (1)
335-344: Clarify that API integration URLs are placeholders.The base URLs use
example.comwhich is appropriate for documentation, but adding a note would help prevent confusion during implementation.api_integration_notes: crm_api: - base_url: "https://api.crm.example.com/v1" + base_url: "https://api.crm.example.com/v1" # Replace with actual CRM endpoint authentication: "Bearer token in header" rate_limit: "100 requests per minute" midaz_api: - base_url: "https://api.midaz.example.com/v1" + base_url: "https://api.midaz.example.com/v1" # Replace with actual Midaz endpoint authentication: "Bearer token in header"default/skills/regulatory-templates-gate2/SKILL.md (1)
61-108: Add language specifier to prompt template code block.The prompt template block lacks a language specifier. Consider using
textormarkdownfor clarity.-``` +```text GATE 2: TECHNICAL VALIDATION ⚠️ CRITICAL: DO NOT MAKE MCP API CALLSdefault/docs/regulatory/templates/RFB/DIMP/dimp-v10-manual.md (1)
51-66: Add language specifier to hierarchy diagram.The registry hierarchy diagram lacks a language specifier.
-``` +```text Nível 0 Nível 1 Nível 2 Nível 3 Nível 4 Nível 5 ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐default/skills/regulatory-templates-setup/SKILL.md (2)
235-256: Add language specifier to selection flow diagram.-``` +```text ┌─────────────────────────────────────┐ │ Step 1: Select Authority │
465-601: Consider referencing the centralized registry.yaml instead of duplicating template metadata.The
TEMPLATE_REGISTRYobject duplicates information that exists indefault/docs/regulatory/templates/registry.yaml. This creates a maintenance burden where updates must be synchronized in multiple places.Consider loading template metadata from the centralized registry at runtime, or adding a comment noting that this registry must stay synchronized with
registry.yaml.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (2)
default/docs/regulatory/templates/BACEN/CADOC/4010/generated/cadoc4010_preview.tplis excluded by!**/generated/**default/docs/regulatory/templates/BACEN/CADOC/4010/generated/cadoc4010_preview.tpl.docsis excluded by!**/generated/**
📒 Files selected for processing (24)
default/agents/backend-engineer-golang.md(1 hunks)default/agents/devops-engineer.md(1 hunks)default/agents/finops-analyzer.md(1 hunks)default/agents/finops-creator.md(1 hunks)default/agents/frontend-engineer.md(1 hunks)default/agents/qa-analyst.md(1 hunks)default/agents/sre.md(1 hunks)default/docs/regulatory/dictionaries/apix-001.yaml(1 hunks)default/docs/regulatory/dictionaries/cadoc-4010.yaml(1 hunks)default/docs/regulatory/dictionaries/cadoc-4016.yaml(1 hunks)default/docs/regulatory/dictionaries/efinanceira-evtCadDeclarante.yaml(1 hunks)default/docs/regulatory/templates/BACEN/APIX/001/APIX001_2-5.xsd(1 hunks)default/docs/regulatory/templates/BACEN/APIX/001/examples/APIX001-erro-1.xml(1 hunks)default/docs/regulatory/templates/BACEN/APIX/001/examples/APIX001-ok-1.xml(1 hunks)default/docs/regulatory/templates/BACEN/CADOC/cadoc-4010-4016.md(1 hunks)default/docs/regulatory/templates/RFB/DIMP/dimp-v10-manual.md(1 hunks)default/docs/regulatory/templates/registry.yaml(1 hunks)default/docs/regulatory/templates/reporter-guide.md(1 hunks)default/skills/regulatory-templates-gate1/SKILL.md(1 hunks)default/skills/regulatory-templates-gate1/schemas/field-extraction.js(1 hunks)default/skills/regulatory-templates-gate2/SKILL.md(1 hunks)default/skills/regulatory-templates-gate3/SKILL.md(1 hunks)default/skills/regulatory-templates-setup/SKILL.md(1 hunks)default/skills/regulatory-templates/SKILL.md(1 hunks)
🧰 Additional context used
🪛 LanguageTool
default/docs/regulatory/templates/BACEN/CADOC/cadoc-4010-4016.md
[grammar] ~138-~138: Segundo o Acordo Ortográfico de 45, os meses e as estações do ano devem ser capitalizados.
Context: ...s/traços | Importante: A partir de janeiro de 2025, o plano de contas COSIF se est...
(AO45_MONTHS_CASING)
[style] ~221-~221: Se for linguagem de Internet, considere escrever “para”, “por” ou “pela” por extenso. Se quis dizer “p”, coloque entre aspas.
Context: ...------| | Diretor | 051 | Diretor resp. p/ contabilidade - Res.CMN 4.924/Res.BCB 1...
(INTERNET_ABBREVIATIONS)
default/docs/regulatory/templates/RFB/DIMP/dimp-v10-manual.md
[misspelling] ~23-~23: Possível erro ortográfico.
Context: ...ade da Federação - Transmissão: Via TED-TEF (validação, assinatura digital e transm...
(PT_MULTITOKEN_SPELLING_HYPHEN)
[grammar] ~158-~158: Possível erro de concordância.
Context: ..."1100" | N | 4 | - | O | | COD_IP_PAR | Código instituição parceira | X | - | - | OC | | COD_CLIEN...
(GENERAL_GENDER_AGREEMENT_ERRORS)
[grammar] ~174-~174: Possível erro de concordância.
Context: ...ial único | X | - | - | F | | COD_AUT | Código autorização | X | - | - | O | | ID_TRANSAC | ID da ...
(GENERAL_GENDER_AGREEMENT_ERRORS)
[grammar] ~191-~191: Possível erro de concordância.
Context: ...pago 8. Saque/troco estabelecimento 11. Recepção pagamento boletos terceiros #### Registro 1120 -...
(GENERAL_GENDER_AGREEMENT_ERRORS)
[misspelling] ~299-~299: Possível erro ortográfico.
Context: ... disponível no site do CONFAZ - Sistema TED-TEF para validação e transmissão - Suporte ...
(PT_MULTITOKEN_SPELLING_HYPHEN)
default/agents/finops-creator.md
[style] ~21-~21: Consider a different adjective to strengthen your wording.
Context: ...iance testing - Regulatory Formats: Deep understanding of Brazilian regulatory s...
(DEEP_PROFOUND)
🪛 markdownlint-cli2 (0.18.1)
default/skills/regulatory-templates-gate3/SKILL.md
45-45: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
138-138: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
145-145: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
209-209: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
222-222: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
default/skills/regulatory-templates-gate1/SKILL.md
66-66: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
188-188: Tables should be surrounded by blank lines
(MD058, blanks-around-tables)
196-196: Tables should be surrounded by blank lines
(MD058, blanks-around-tables)
211-211: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
756-756: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
1011-1011: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
1196-1196: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
1212-1212: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
default/docs/regulatory/templates/BACEN/CADOC/cadoc-4010-4016.md
49-49: Bare URL used
(MD034, no-bare-urls)
55-55: Bare URL used
(MD034, no-bare-urls)
56-56: Bare URL used
(MD034, no-bare-urls)
64-64: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
86-86: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
112-112: Tables should be surrounded by blank lines
(MD058, blanks-around-tables)
117-117: Tables should be surrounded by blank lines
(MD058, blanks-around-tables)
122-122: Tables should be surrounded by blank lines
(MD058, blanks-around-tables)
127-127: Tables should be surrounded by blank lines
(MD058, blanks-around-tables)
134-134: Tables should be surrounded by blank lines
(MD058, blanks-around-tables)
141-141: Tables should be surrounded by blank lines
(MD058, blanks-around-tables)
261-261: Bare URL used
(MD034, no-bare-urls)
262-262: Bare URL used
(MD034, no-bare-urls)
263-263: Bare URL used
(MD034, no-bare-urls)
264-264: Bare URL used
(MD034, no-bare-urls)
default/skills/regulatory-templates/SKILL.md
55-55: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
219-219: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
340-340: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
446-446: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
default/skills/regulatory-templates-gate2/SKILL.md
61-61: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
367-367: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
382-382: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
default/docs/regulatory/templates/RFB/DIMP/dimp-v10-manual.md
51-51: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
default/agents/finops-analyzer.md
88-88: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
106-106: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
147-147: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
159-159: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
170-170: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
default/docs/regulatory/templates/reporter-guide.md
389-389: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
default/skills/regulatory-templates-setup/SKILL.md
235-235: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
610-610: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
🔇 Additional comments (16)
default/agents/frontend-engineer.md (1)
1-99: Frontend agent scope and boundaries are well definedRole description, responsibilities, and “does NOT handle” section are consistent and precise; no changes needed from a documentation or usage‑guidance perspective.
default/agents/qa-analyst.md (1)
1-130: QA agent responsibilities and boundaries look solidThe document gives a comprehensive yet focused scope for QA (strategy, API/E2E/performance/security, compliance) and clearly defers non‑QA concerns to other agents; I don’t see gaps that need changes.
default/agents/sre.md (1)
1-118: SRE agent definition is clear and consistent with adjacent rolesThe SRE scope (observability, reliability, performance, DB reliability, incidents, chaos) and exclusions line up well with DevOps/Backend/QA agents; this should avoid overlap and confusion.
default/agents/devops-engineer.md (1)
1-171: DevOps agent spec is thorough and aligns with other rolesCI/CD, Kubernetes, Helm, Terraform, and multi‑tenancy responsibilities are well covered, and the non‑scope section cleanly defers app logic/monitoring/tests to the right agents; no changes needed.
default/agents/backend-engineer-golang.md (1)
1-132: Backend Go agent definition looks well-scoped for financial backendsResponsibilities (APIs, data layer, messaging, multi‑tenancy, auth/WorkOS, serverless) and exclusions are coherent and match how other agents are framed; I don’t see anything that needs adjustment.
default/docs/regulatory/templates/BACEN/APIX/001/examples/APIX001-erro-1.xml (1)
1-174: Erroneous APIX XML example is well-formed and clearly annotatedThe file is structurally valid XML and the inline comments make the intended validation failures explicit, which is ideal for negative tests. Please just ensure it actually fails only the intended XSD/business rules (and not for being malformed XML) by running it against
APIX001_2-5.xsdin your validation pipeline.default/docs/regulatory/templates/BACEN/CADOC/cadoc-4010-4016.md (1)
247-277: Verify BACEN manual licensing status before redistributionThe search results confirm that the Banco Central do Brasil publishes datasets under the Open Data Commons ODbL license, with each dataset indicating its license in metadata, and that Brazilian Copyright Law defines public domain categories, and licenses vary across BACEN publications from ODbL to Creative Commons.
However, the specific license status of the "Manual de Instruções de Preenchimento dos Documentos 4010/4016" could not be determined from public sources. Before keeping this extraction in the repository, you must:
- Check if the manual is published on BACEN's Open Data portal and verify its license metadata
- Confirm the license permits this level of redistribution and derivative use, or
- Obtain explicit written permission from BACEN
BACEN requires that you check the license on the specific document page before redistributing; if unclear, request written permission from BACEN/legal.
default/skills/regulatory-templates-gate1/SKILL.md (1)
42-51: No issues found - snake_case requirement is already fully implemented.Verification confirms the "CRITICAL: NAMING CONVENTION - SNAKE_CASE STANDARD" requirement in lines 42-51 is correctly enforced across all regulatory dictionaries:
- cadoc-4010.yaml: All
api_fieldvalues use snake_case (e.g.,legal_document,operation_route)- cadoc-4016.yaml: All
api_fieldvalues use snake_case with explicit normalization comment- efinanceira-evtCadDeclarante.yaml: All
api_fieldvalues use snake_case (e.g.,legal_document,categoria_declarante,zip_code)- camelCase search: Zero violations found across all dictionaries
The documented requirement is properly implemented and enforced uniformly.
default/docs/regulatory/dictionaries/apix-001.yaml (1)
1-14: Well-structured data dictionary with comprehensive field mappings.The dictionary provides clear field definitions with confidence levels, transformation rules, and validation requirements. The structure with
field_mappings,json_structure,validation_rules, andcompliance_notesfollows good practices for regulatory data mapping specifications.default/docs/regulatory/templates/reporter-guide.md (2)
1-16: Comprehensive template reference with clear syntax documentation.The template model section clearly documents the
.tplextension requirement, output format mapping, and placeholder syntax. This provides a solid foundation for template authors.
336-349: Testing checklist provides good quality gates.The 10-point checklist covers essential validation criteria including extension, mandatory fields, date/numeric formats, structure matching, and the template size guideline (under 100 lines).
default/docs/regulatory/templates/BACEN/APIX/001/examples/APIX001-ok-1.xml (1)
1-170: XML example correctly demonstrates APIX001 structure.The example includes all required sections (Transacoes, Devolucoes, BloqueiosCautelares, Receitas, TemposTransacoes, TemposDict, ConsultasDict, Disponibilidade, TempoAutorizacoes, Autorizacoes) with the correct occurrence counts matching the XSD constraints (12 Transacao, 2 Devolucao, 4 BloqueioCautelar, 4 Receita, 2 Autorizacao).
default/docs/regulatory/templates/RFB/DIMP/dimp-v10-manual.md (1)
1-35: Comprehensive DIMP v10 specification reference.The manual provides thorough documentation of file structure, field types, and validation rules for Brazilian regulatory compliance. The organization with clear sections for general information, file structure, technical specifications, and implementation timeline is well-suited for reference use.
default/docs/regulatory/templates/BACEN/APIX/001/APIX001_2-5.xsd (3)
62-84: Well-defined APIX001 document structure with comprehensive constraints.The
tipoAPIX001complex type properly defines all required child elements and attributes with appropriate type constraints. The use of required attributes for header fields (DtArquivo, Ano, Mes, ISPB, NomeResp, EmailResp, TelResp, TipoEnvio) ensures complete document metadata.
367-375: Email validation pattern is reasonable but has limitations.The
tipoEmailResppattern validates common email formats but may not cover all RFC 5322 compliant addresses (e.g., quoted local parts, IP address domains). For regulatory compliance, this is typically acceptable as it covers practical business email formats.
4-10: No action needed—header reference is correct.The document identifier "Documento 1201" refers to the official BACEN code for "Dados dos participantes do Pix", while APIX001 is the STA file/code for the same document in XML/XSD format. These are complementary identifiers, not conflicting ones, so the header reference is accurate per BACEN naming conventions.
| address_structure_mapping: | | ||
| def map_addresses(crm_addresses): | ||
| result = [] | ||
| mapping_config = {...} # Load from field_mapping | ||
| for key, address in crm_addresses.items(): | ||
| if address: | ||
| mapped = {} | ||
| for crm_field, apix_field in mapping_config['field_mapping'].items(): | ||
| if crm_field in address: | ||
| mapped[apix_field] = address[crm_field] | ||
| result.append(mapped) | ||
| return result |
There was a problem hiding this comment.
Incomplete placeholder in address_structure_mapping function.
The function contains {...} as a placeholder which would cause a syntax error if this code is ever executed. If this is meant to be documentation-only, consider adding a comment; otherwise, provide the actual implementation.
address_structure_mapping: |
def map_addresses(crm_addresses):
result = []
- mapping_config = {...} # Load from field_mapping
+ # mapping_config should be loaded from field_mapping section
+ mapping_config = {
+ 'field_mapping': {
+ 'line1': 'streetName',
+ 'line2': 'additionalInfo',
+ 'zip_code': 'postalCode',
+ 'city': 'townName',
+ 'state': 'countrySubDivision',
+ 'country': 'country'
+ }
+ }
for key, address in crm_addresses.items():📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| address_structure_mapping: | | |
| def map_addresses(crm_addresses): | |
| result = [] | |
| mapping_config = {...} # Load from field_mapping | |
| for key, address in crm_addresses.items(): | |
| if address: | |
| mapped = {} | |
| for crm_field, apix_field in mapping_config['field_mapping'].items(): | |
| if crm_field in address: | |
| mapped[apix_field] = address[crm_field] | |
| result.append(mapped) | |
| return result | |
| address_structure_mapping: | | |
| def map_addresses(crm_addresses): | |
| result = [] | |
| # mapping_config should be loaded from field_mapping section | |
| mapping_config = { | |
| 'field_mapping': { | |
| 'line1': 'streetName', | |
| 'line2': 'additionalInfo', | |
| 'zip_code': 'postalCode', | |
| 'city': 'townName', | |
| 'state': 'countrySubDivision', | |
| 'country': 'country' | |
| } | |
| } | |
| for key, address in crm_addresses.items(): | |
| if address: | |
| mapped = {} | |
| for crm_field, apix_field in mapping_config['field_mapping'].items(): | |
| if crm_field in address: | |
| mapped[apix_field] = address[crm_field] | |
| result.append(mapped) | |
| return result |
🤖 Prompt for AI Agents
In default/docs/regulatory/dictionaries/apix-001.yaml around lines 306 to 317,
the address_structure_mapping function uses a literal placeholder mapping_config
= {...} which will raise a syntax error; replace the placeholder with actual
logic: obtain mapping_config from the surrounding context (e.g., load
field_mapping or field_mapping.get('address_structure') / a provided config
variable), validate it contains 'field_mapping' (fallback to an empty dict if
missing), then iterate mapping_config['field_mapping'] as shown; alternatively,
if this snippet is documentation-only, change the placeholder to a clear comment
like "# mapping_config should be loaded from field_mapping" so it is not
interpreted as code.
| <TemposTransacoes | ||
| Perc50TempoExpUsuarioLiqSPI="5.1" | ||
| Perc99TempoExpUsuarioLiqSPI ="8.9" | ||
| Perc50TempoExpUsuarioLiqForaSPI="4.6" | ||
| Perc99TempoExpUsuarioLiqForaSPI="9.9" | ||
| TempoMaxBloqueioCautelar="9.2" /> |
There was a problem hiding this comment.
Extra space in XML attribute may cause validation issues.
Line 143 has an extra space before = in Perc99TempoExpUsuarioLiqSPI ="8.9". While some XML parsers tolerate this, it's inconsistent with the other attributes and could cause issues with strict validators.
<TemposTransacoes
Perc50TempoExpUsuarioLiqSPI="5.1"
- Perc99TempoExpUsuarioLiqSPI ="8.9"
+ Perc99TempoExpUsuarioLiqSPI="8.9"
Perc50TempoExpUsuarioLiqForaSPI="4.6"
Perc99TempoExpUsuarioLiqForaSPI="9.9"
TempoMaxBloqueioCautelar="9.2" />📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| <TemposTransacoes | |
| Perc50TempoExpUsuarioLiqSPI="5.1" | |
| Perc99TempoExpUsuarioLiqSPI ="8.9" | |
| Perc50TempoExpUsuarioLiqForaSPI="4.6" | |
| Perc99TempoExpUsuarioLiqForaSPI="9.9" | |
| TempoMaxBloqueioCautelar="9.2" /> | |
| <TemposTransacoes | |
| Perc50TempoExpUsuarioLiqSPI="5.1" | |
| Perc99TempoExpUsuarioLiqSPI="8.9" | |
| Perc50TempoExpUsuarioLiqForaSPI="4.6" | |
| Perc99TempoExpUsuarioLiqForaSPI="9.9" | |
| TempoMaxBloqueioCautelar="9.2" /> |
🤖 Prompt for AI Agents
In default/docs/regulatory/templates/BACEN/APIX/001/examples/APIX001-ok-1.xml
around lines 141 to 146, the attribute "Perc99TempoExpUsuarioLiqSPI" contains an
extra space before the '=' (Perc99TempoExpUsuarioLiqSPI ="8.9"); remove the
stray space so it reads Perc99TempoExpUsuarioLiqSPI="8.9" to match the other
attributes and avoid XML validation issues.
| reference_files: | ||
| schema: null | ||
| examples: [] | ||
| dictionary: "BACEN/CADOC/4010/dictionary.yaml" |
There was a problem hiding this comment.
🧩 Analysis chain
Verify dictionary reference paths match actual file locations.
The registry references dictionary paths that may not match the actual file structure. For example:
- Line 36: References
"BACEN/CADOC/4010/dictionary.yaml" - Actual file:
default/docs/regulatory/dictionaries/cadoc-4010.yaml
The path structure in reference_files.dictionary should match the actual file organization, or these paths should be clarified as logical/legacy references.
Verify that all reference_files.dictionary paths in the registry point to actual files or are intended as abstract identifiers for internal reference. Run the following to check:
Also applies to: 52-55
🏁 Script executed:
#!/bin/bash
# Check if dictionary paths referenced in registry exist
rg "dictionary_path|dictionary:" default/docs/regulatory/templates/registry.yaml | while read line; do
path=$(echo "$line" | grep -oP '"[^"]*dictionary[^"]*"' | tr -d '"')
echo "Checking: $path"
if [ -z "$path" ]; then continue; fi
# Try different base paths
if [ -f "default/docs/regulatory/dictionaries/$path" ]; then
echo " ✓ Found at dictionaries/"
elif [ -f "default/docs/regulatory/$path" ]; then
echo " ✓ Found at regulatory/"
else
echo " ✗ NOT FOUND"
fi
doneLength of output: 443
Need to locate the actual dictionary files in the repository to confirm the path mismatch. Let me search for them.
---
🏁 Script executed:
```shell
#!/bin/bash
# Find all dictionary files in the repository
echo "=== Finding all dictionary files ==="
fd -e yaml -e yml | grep -i dict | head -20
echo -e "\n=== Finding files in regulatory directory ==="
fd . default/docs/regulatory --type f | head -30
echo -e "\n=== Checking for BACEN/CADOC/4010 related files ==="
fd . default/docs/regulatory --type f | grep -i cadoc | head -10
Length of output: 1614
| "transformation": "UTC to America/Sao_Paulo", | ||
| "test_data": { | ||
| "input": "2025-01-15T10:30:00Z", | ||
| "expected": "2025-01-15 08:30:00", | ||
| "actual": "2025-01-15 08:30:00", | ||
| "status": "passed" | ||
| } | ||
| } | ||
| ``` |
There was a problem hiding this comment.
🧩 Analysis chain
Timezone conversion example may be incorrect.
The test data shows UTC 10:30:00Z converting to São Paulo time 08:30:00, implying UTC-2. However, São Paulo (America/Sao_Paulo) is typically UTC-3 (or UTC-2 during daylight saving). The expected output should likely be 07:30:00 for standard time.
Verify the correct UTC offset for the America/Sao_Paulo timezone during the expected operation period:
🌐 Web query:
What is the UTC offset for America/Sao_Paulo timezone?
💡 Result:
America/Sao_Paulo is UTC−03:00 (Brasília Time, BRT); it does not observe DST currently. [1][2]
Sources:
[1] timeanddate — São Paulo, Brazil time zone (BRT — UTC−3).
[2] TimeZoneDB — America/Sao_Paulo (GMT offset UTC−03:00, DST: No).
Fix timezone conversion in test data: expected output should be 07:30:00, not 08:30:00.
America/Sao_Paulo uses UTC−03:00 (Brasília Time, BRT) and does not observe DST currently. The test data shows UTC 10:30:00Z converting to 08:30:00, which incorrectly implies UTC-2. The correct conversion for UTC-3 is 07:30:00.
Update the expected value in the test data from "2025-01-15 08:30:00" to "2025-01-15 07:30:00".
🤖 Prompt for AI Agents
In default/skills/regulatory-templates-gate2/SKILL.md around lines 156 to 164,
the test_data expected time is wrong for the UTC to America/Sao_Paulo
conversion; update the "expected" field from "2025-01-15 08:30:00" to
"2025-01-15 07:30:00" to reflect UTC−03:00 (BRT) so the input
"2025-01-15T10:30:00Z" correctly maps to "2025-01-15 07:30:00".
| function validateMandatoryFields(context) { | ||
| // Get mandatory fields from template-specific skill | ||
| const templateSkill = `regulatory-${context.template_code.toLowerCase()}`; | ||
| const mandatoryFields = await loadTemplateSpecificMandatoryFields(templateSkill); | ||
| const validationResults = []; | ||
|
|
||
| for (const field of mandatoryFields) { | ||
| const result = { | ||
| field_code: field.code, | ||
| field_name: field.name, | ||
| is_mandatory: true, | ||
| checks: { | ||
| mapped: checkFieldIsMapped(field, context.gate1.field_mappings), | ||
| confidence_ok: checkConfidenceLevel(field, context.gate1.field_mappings) >= 80, | ||
| validated: checkFieldValidated(field, context.gate2.validated_mappings), | ||
| tested: checkFieldTested(field, context.gate2.test_results), | ||
| transformation_ok: checkTransformationWorks(field, context.gate2.test_results) | ||
| } | ||
| }; | ||
|
|
||
| result.status = Object.values(result.checks).every(v => v === true) ? "PASS" : "FAIL"; | ||
| validationResults.push(result); | ||
| } | ||
|
|
||
| const allPassed = validationResults.every(r => r.status === "PASS"); | ||
| const coverage = (validationResults.filter(r => r.status === "PASS").length / mandatoryFields.length) * 100; | ||
|
|
||
| return { | ||
| all_mandatory_fields_valid: allPassed, | ||
| validation_results: validationResults, | ||
| coverage_percentage: coverage, | ||
| failed_fields: validationResults.filter(r => r.status === "FAIL") | ||
| }; | ||
| } | ||
| ``` |
There was a problem hiding this comment.
Function uses await but is not declared as async.
The validateMandatoryFields function uses await loadTemplateSpecificMandatoryFields() on line 288, but the function declaration on line 285 is not marked as async.
-function validateMandatoryFields(context) {
+async function validateMandatoryFields(context) {
// Get mandatory fields from template-specific skill
const templateSkill = `regulatory-${context.template_code.toLowerCase()}`;
const mandatoryFields = await loadTemplateSpecificMandatoryFields(templateSkill);📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| function validateMandatoryFields(context) { | |
| // Get mandatory fields from template-specific skill | |
| const templateSkill = `regulatory-${context.template_code.toLowerCase()}`; | |
| const mandatoryFields = await loadTemplateSpecificMandatoryFields(templateSkill); | |
| const validationResults = []; | |
| for (const field of mandatoryFields) { | |
| const result = { | |
| field_code: field.code, | |
| field_name: field.name, | |
| is_mandatory: true, | |
| checks: { | |
| mapped: checkFieldIsMapped(field, context.gate1.field_mappings), | |
| confidence_ok: checkConfidenceLevel(field, context.gate1.field_mappings) >= 80, | |
| validated: checkFieldValidated(field, context.gate2.validated_mappings), | |
| tested: checkFieldTested(field, context.gate2.test_results), | |
| transformation_ok: checkTransformationWorks(field, context.gate2.test_results) | |
| } | |
| }; | |
| result.status = Object.values(result.checks).every(v => v === true) ? "PASS" : "FAIL"; | |
| validationResults.push(result); | |
| } | |
| const allPassed = validationResults.every(r => r.status === "PASS"); | |
| const coverage = (validationResults.filter(r => r.status === "PASS").length / mandatoryFields.length) * 100; | |
| return { | |
| all_mandatory_fields_valid: allPassed, | |
| validation_results: validationResults, | |
| coverage_percentage: coverage, | |
| failed_fields: validationResults.filter(r => r.status === "FAIL") | |
| }; | |
| } | |
| ``` | |
| async function validateMandatoryFields(context) { | |
| // Get mandatory fields from template-specific skill | |
| const templateSkill = `regulatory-${context.template_code.toLowerCase()}`; | |
| const mandatoryFields = await loadTemplateSpecificMandatoryFields(templateSkill); | |
| const validationResults = []; | |
| for (const field of mandatoryFields) { | |
| const result = { | |
| field_code: field.code, | |
| field_name: field.name, | |
| is_mandatory: true, | |
| checks: { | |
| mapped: checkFieldIsMapped(field, context.gate1.field_mappings), | |
| confidence_ok: checkConfidenceLevel(field, context.gate1.field_mappings) >= 80, | |
| validated: checkFieldValidated(field, context.gate2.validated_mappings), | |
| tested: checkFieldTested(field, context.gate2.test_results), | |
| transformation_ok: checkTransformationWorks(field, context.gate2.test_results) | |
| } | |
| }; | |
| result.status = Object.values(result.checks).every(v => v === true) ? "PASS" : "FAIL"; | |
| validationResults.push(result); | |
| } | |
| const allPassed = validationResults.every(r => r.status === "PASS"); | |
| const coverage = (validationResults.filter(r => r.status === "PASS").length / mandatoryFields.length) * 100; | |
| return { | |
| all_mandatory_fields_valid: allPassed, | |
| validation_results: validationResults, | |
| coverage_percentage: coverage, | |
| failed_fields: validationResults.filter(r => r.status === "FAIL") | |
| }; | |
| } |
🤖 Prompt for AI Agents
In default/skills/regulatory-templates-gate2/SKILL.md around lines 285–319, the
function validateMandatoryFields uses await but is not declared async; change
the function declaration to async validateMandatoryFields(context) and ensure
any call sites that invoke validateMandatoryFields either await its result or
handle the returned Promise so the asynchronous behavior is propagated
correctly.
| const DICTIONARY_BASE_PATH = "~/.claude/docs/regulatory/dictionaries"; | ||
|
|
||
| const TEMPLATES_WITH_DICTIONARY = { | ||
| "CADOC_4010": `${DICTIONARY_BASE_PATH}/cadoc-4010.yaml`, | ||
| "CADOC_4016": `${DICTIONARY_BASE_PATH}/cadoc-4016.yaml`, | ||
| "APIX_001": `${DICTIONARY_BASE_PATH}/apix-001.yaml`, | ||
| "EFINANCEIRA_evtCadDeclarante": `${DICTIONARY_BASE_PATH}/efinanceira-evtCadDeclarante.yaml` | ||
| }; |
There was a problem hiding this comment.
Inconsistent dictionary path prefix.
The DICTIONARY_BASE_PATH uses ~/.claude/docs/regulatory/dictionaries (home directory), but documentation paths elsewhere in the file (lines 374, 400, 416, etc.) use .claude/docs/ (relative path). This inconsistency could cause file resolution failures.
Standardize the path format. If paths should be relative to the repository root:
// STANDARDIZED DICTIONARY PATH
-const DICTIONARY_BASE_PATH = "~/.claude/docs/regulatory/dictionaries";
+const DICTIONARY_BASE_PATH = ".claude/docs/regulatory/dictionaries";Or update the comment on line 366 accordingly:
// Dictionary status (CRITICAL - determines validation mode)
- // STANDARDIZED PATH: ~/.claude/docs/regulatory/dictionaries/
+ // STANDARDIZED PATH: .claude/docs/regulatory/dictionaries/
dictionary_status: {📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| const DICTIONARY_BASE_PATH = "~/.claude/docs/regulatory/dictionaries"; | |
| const TEMPLATES_WITH_DICTIONARY = { | |
| "CADOC_4010": `${DICTIONARY_BASE_PATH}/cadoc-4010.yaml`, | |
| "CADOC_4016": `${DICTIONARY_BASE_PATH}/cadoc-4016.yaml`, | |
| "APIX_001": `${DICTIONARY_BASE_PATH}/apix-001.yaml`, | |
| "EFINANCEIRA_evtCadDeclarante": `${DICTIONARY_BASE_PATH}/efinanceira-evtCadDeclarante.yaml` | |
| }; | |
| const DICTIONARY_BASE_PATH = ".claude/docs/regulatory/dictionaries"; | |
| const TEMPLATES_WITH_DICTIONARY = { | |
| "CADOC_4010": `${DICTIONARY_BASE_PATH}/cadoc-4010.yaml`, | |
| "CADOC_4016": `${DICTIONARY_BASE_PATH}/cadoc-4016.yaml`, | |
| "APIX_001": `${DICTIONARY_BASE_PATH}/apix-001.yaml`, | |
| "EFINANCEIRA_evtCadDeclarante": `${DICTIONARY_BASE_PATH}/efinanceira-evtCadDeclarante.yaml` | |
| }; |
🤖 Prompt for AI Agents
In default/skills/regulatory-templates-setup/SKILL.md around lines 276 to 283
(and consistent with documentation paths at ~lines 366, 374, 400, 416), the
DICTIONARY_BASE_PATH uses a home-dir-prefixed "~/.claude/…" while other paths
use a repository-relative ".claude/…" format; change DICTIONARY_BASE_PATH to the
relative path ".claude/docs/regulatory/dictionaries" (or the agreed
repository-relative value) so all template entries use the same prefix, and
update the comment on line 366 to reflect the chosen relative path convention.
| | Sub-skill | Purpose | Input | Output | | ||
| |-----------|---------|-------|--------| | ||
| | regulatory-templates-setup | Initial configuration | User selections | Base context | | ||
| | regulatory-templates-gate1 | Regulatory analysis | Base context | Field mappings, uncertainties | | ||
| | regulatory-templates-gate2 | Technical validation | Context + Gate 1 | Validated mappings, rules | | ||
| | regulatory-templates-gate3 | API readiness | Context + Gates 1-2 | Authentication, endpoints | | ||
| | regulatory-templates-gate4 | Template creation | Complete context | Template ID, verification | | ||
|
|
There was a problem hiding this comment.
Quick Reference table is inconsistent with the documented 3-gate workflow.
The table references 5 sub-skills including regulatory-templates-gate4, but the entire document describes only a 3-gate workflow (Gate 1, 2, 3). Additionally:
- Line 484 describes Gate 3 as "API readiness" but the workflow states Gate 3 is "Template file generation"
- Line 485 references Gate 4 which doesn't exist
Apply this diff to align with the documented workflow:
| Sub-skill | Purpose | Input | Output |
|-----------|---------|-------|--------|
| regulatory-templates-setup | Initial configuration | User selections | Base context |
| regulatory-templates-gate1 | Regulatory analysis | Base context | Field mappings, uncertainties |
-| regulatory-templates-gate2 | Technical validation | Context + Gate 1 | Validated mappings, rules |
-| regulatory-templates-gate3 | API readiness | Context + Gates 1-2 | Authentication, endpoints |
-| regulatory-templates-gate4 | Template creation | Complete context | Template ID, verification |
+| regulatory-templates-gate2 | Technical validation | Context + Gate 1 | Validated mappings, test results |
+| regulatory-templates-gate3 | Template generation | Context + Gates 1-2 | .tpl template file |📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| | Sub-skill | Purpose | Input | Output | | |
| |-----------|---------|-------|--------| | |
| | regulatory-templates-setup | Initial configuration | User selections | Base context | | |
| | regulatory-templates-gate1 | Regulatory analysis | Base context | Field mappings, uncertainties | | |
| | regulatory-templates-gate2 | Technical validation | Context + Gate 1 | Validated mappings, rules | | |
| | regulatory-templates-gate3 | API readiness | Context + Gates 1-2 | Authentication, endpoints | | |
| | regulatory-templates-gate4 | Template creation | Complete context | Template ID, verification | | |
| | Sub-skill | Purpose | Input | Output | | |
| |-----------|---------|-------|--------| | |
| | regulatory-templates-setup | Initial configuration | User selections | Base context | | |
| | regulatory-templates-gate1 | Regulatory analysis | Base context | Field mappings, uncertainties | | |
| | regulatory-templates-gate2 | Technical validation | Context + Gate 1 | Validated mappings, test results | | |
| | regulatory-templates-gate3 | Template generation | Context + Gates 1-2 | .tpl template file | |
1 participant
Summary by CodeRabbit
Release Notes
New Features
Documentation
✏️ Tip: You can customize this high-level summary in your review settings.