Security audit
Security checks for vulnerabilities and agentic risk
This skill mainly converts local DOCX files to REDCap CSVs, but it also instructs agents to send generated clinical-data CSVs through Feishu without clear recipient, consent, or privacy controls.
Review before installing in clinical workflows. Use it only on documents you are allowed to process, prefer local-only CSV output, do not let it send files through Feishu unless the recipient and approval are explicit, and inspect generated CSVs before opening them in spreadsheet software or importing them into REDCap.
scripts/process_upload.py:300Spreadsheet Formula Injection in Generated CSV Files
SKILL.md:27Unpinned Third-Party Dependencies Allow Mutable Installation Results
The description presents a broad, smart document-to-REDCap converter for Word/Excel CRF/protocol files with advanced extraction features. The supplied code is much narrower: it only accepts a .docx path from the command line, depends on python-docx, assumes a specific document shape, hard-codes many questionnaire items and REDCap metadata, and extracts from the first two tables only. While it does generate a REDCap CSV and supports radio/checkbox/Likert/frequency-style choices, most of the advertised capabilities are absent. This is a material description-behavior mismatch because the primary implementation is a bespoke converter for one known questionnaire rather than a general-purpose intelligent REDCap dictionary generator.
描述与代码存在明显能力不一致。代码的核心用途确实是从 Word 文档生成 REDCap CSV 数据字典，这与高层目标部分一致；但描述列出了多项关键能力，而代码中未见对应实现。具体而言，脚本通过 python-docx 遍历段落和表格，对标题、分节、简单“变量名: 标签”模式和表格列进行启发式解析，然后写出 CSV。虽然导入了 markitdown，但完全未使用，也没有任何 Excel 解析、OCR、图片分析、分支逻辑提取、计算表达式抽取、Likert/频率量表专门识别或 CDISC 命名规则实现。其实际能力更接近“基础 DOCX 到 REDCap CSV 的简单启发式转换器”，明显弱于描述中宣称的功能范围，因此应判定为描述与行为不匹配。
The documentation says generated CSV files are sent via Feishu, creating a potential outbound transmission path for highly sensitive clinical and identifier data. Without explicit user consent, transmission details, or security controls, users may unknowingly exfiltrate regulated data to a third-party messaging platform.
Without declared permissions the skill's intent is opaque and cannot be validated.
The manifest and usage sections describe automatic image OCR and sending the generated CSV through Feishu, which are substantive capabilities beyond plain document-to-CSV conversion. However, the listed requirements and installation steps only cover document parsing libraries (python-docx, lxml, markitdown) and do not support OCR tooling or Feishu APIs, indicating the claimed behavior is not matched by the actual documented setup for the skill.
The skill is designed to process clinical trial CRFs/protocols and OCR-derived content, which commonly contain sensitive personal and medical data. Failing to warn users about privacy, retention, and handling expectations can lead to inadvertent disclosure or inappropriate processing of regulated health information.
The module docstring states it converts Word CRF/protocol documents to REDCap data dictionaries, and the manifest further claims Word/Excel support with intelligent recognition of forms and fields. In reality, parse_docx builds much of the output from fixed question lists and two specific table indices, with no Excel parsing and no general-purpose structure inference, so the implemented behavior is substantially narrower than the claimed capability.
The parse_docx docstring presents the function as parsing the DOCX file, but lines L97-L113 and L164-L175 define large blocks of questionnaire items directly in code, independent of document contents. This is more than an incomplete comment: it implies document-driven extraction while the implementation partially synthesizes a predetermined schema.
The skill description says it converts Word/Excel CRF or protocol documents into a REDCap CSV data dictionary. In this file, parsing is implemented only through Document(docx_path) from python-docx, with no Excel parsing path, so the actual behavior is narrower than the claimed capability.
The manifest highlights automatic image OCR, branching logic, and calculated fields. In this code, OCR is absent, branching logic fields are always left empty, and calculated fields are only passed through as a normalized type without logic extraction, indicating a mismatch between claimed functionality and implemented behavior in this file.
The natural-language instructions and operational guidance are presented exclusively in Chinese, which effectively forces a specific language for users. The file does not offer an alternative language option or explain that the skill is intentionally limited to a Chinese-speaking or region-specific audience.
The overview says the skill converts Word/Excel/PDF documents and the core flow says it uses markitdown to parse documents, but the dependency list does not include any explicit PDF-processing tooling and the rest of the file focuses on docx/image handling. This creates an intent-level contradiction between what the documentation says is supported and what the documented implementation appears equipped to handle.
The file-level docstring presents the tool description, rules, dependencies, and installation instructions entirely in Chinese. Under the policy, language-specific behavior should not be forced without user opt-in or a clearly documented locale justification, and no such choice or justification appears here.
The module docstring and CLI description are written only in Chinese, which imposes a specific language on users without opt-in or alternatives. This matches the language/locale policy concern for natural-language content because the skill does not offer any user language choice or justify a locale restriction.
No suspicious patterns detected.