Casely
PassAudited by ClawScan on May 1, 2026.
Overview
Casely appears purpose-aligned for generating QA test cases from local documents, with disclosed local setup, file-processing, export, and persistence behavior that users should review.
Before installing or using Casely, run it only in the intended repository, review dependency changes from uv setup, provide explicit project paths when multiple projects exist, and inspect the generated style guide and Excel exports before relying on or importing them.
Findings (4)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
Running /init may modify the local repository's Python project files and install third-party packages.
The skill directs dependency installation and possible repository-root project initialization even though there is no install spec. This is relevant supply-chain/setup behavior, but it is disclosed and directly supports document parsing and Excel export.
Check if `pyproject.toml` exists at the repo root. If not, run `uv init` there. Install/verify dependencies: `uv add docling openpyxl`
Run setup only in the intended repository, review changes to pyproject or lock files, and pin or approve dependencies according to your team's normal process.
The wrong local project could be parsed or exported if the agent runs scripts without explicit paths.
When no paths are provided, the parser selects the most recently modified project under projects/ and processes its requirements and examples. This is convenient but can target an unintended project if multiple projects exist.
return max(subdirs, key=lambda d: d.stat().st_mtime)
Provide explicit input and output paths, or confirm the selected project before running /parse or /export when more than one project exists.
Private conventions or unintended instructions embedded in examples could influence future generated test cases for that project.
The skill creates persistent project context from example test cases and uses it to shape future generated cases. This is expected for style consistency, but it means project-derived guidance is reused across later tasks.
Generate `test_style_guide.md` in the project root. This file acts as the "source of truth"
Review and edit test_style_guide.md before generation, and keep sensitive or irrelevant content out of example files.
Mistakes or unsafe literal spreadsheet-like values in generated tables could be carried into Excel exports and downstream test-management workflows.
Generated Markdown cell values are copied directly into Excel cells. This is normal export behavior, but unreviewed generated or source-derived content can propagate into files intended for TMS import.
cell = ws.cell(row=row_idx, column=col_idx, value=clean_value)
Review exported spreadsheets before importing them into a TMS, especially when source documents or examples come from untrusted parties.