Security audit
Security checks for vulnerabilities and agentic risk
This workflow helper is mostly coherent, but some scripts can read or write outside the intended task folders when given unsafe task data.
Review before installing. Use this only in trusted workspaces, avoid passing untrusted task IDs or task JSON into its scripts, and fix task-ID validation plus output path containment before relying on it for sensitive deployments, document sync, cron, or long-running automation.
toolkit/scripts/new-task.sh:10Unvalidated Task Identifiers Permit Path Traversal and Filesystem Writes
toolkit/scripts/task-export.py:237Mutable Task Metadata Controls an Unconfined Report Write Destination
toolkit/scripts/new-task.sh:48Manual Shell Interpolation Allows Task JSON Corruption and Property Injection
The declared description presents this skill as a durable workflow system for managing long-running jobs. The provided code does not implement workflow orchestration or execution behavior; it only bootstraps files into a workspace by creating directories and copying templates/scripts when absent. That is a materially different primary purpose from the declared description, so this is a clear description-behavior mismatch.
The supplied code does not appear malicious or unrelated, but it is materially narrower than the declared description. The description presents a comprehensive durable workflow layer for long-running, recoverable, parallel, auditable execution. In contrast, this code is a single command-line script whose purpose is to finalize an existing task record in local JSON storage: validate a final status, update timestamps and status fields, set/reset result/error fields, normalize stage states, append an audit event, and save the file. The audit/event behavior aligns loosely with 'auditable outputs,' and task/stage state management is consistent with a workflow system, but this chunk does not itself implement the broader workflow-layer capabilities claimed in the description. Therefore this is a description/behavior mismatch due to overbroad declared purpose versus the actual narrow behavior shown.
The declared description presents a broad durable workflow system for orchestrating long-running work, including recoverability, parallelization, background execution, external side effects, and resumable/auditable execution. The supplied code instead is a narrow inspection utility: it reads task JSON files from a local tasks directory, derives dependency readiness states, and prints a report of currently open tasks. While it relates to task/workflow metadata, it does not implement the primary capabilities claimed in the description. This is a material purpose mismatch: the code is a status-reporting/listing script, not a durable workflow layer.
The declared description presents a general-purpose durable workflow layer/runtime for orchestrating long-running recoverable work. The supplied code is not such a workflow layer; it is a one-off maintenance/migration utility for task metadata files. Its primary behavior is reading and rewriting local JSON task files to enforce schema defaults and record a migration event. While task records and audit-style events are conceptually adjacent to workflow systems, this code does not implement background execution, parallelized sub-agents, resumability mechanics, cron handling, or orchestration logic. Therefore the actual code's primary purpose materially differs from the declared purpose.
The declared description presents this skill as a durable workflow layer for managing complex long-running work, including recovery, parallelization, background execution, cron, and auditable resumable execution. The supplied code chunk does not implement those capabilities. It is a simple CLI script that accepts a task ID, loads a corresponding JSON file from a local tasks directory, and prints stored fields such as status, stages, events, errors, and results. While the displayed fields reference workflow concepts like stages, child tasks, and cron job IDs, the script itself only reads and formats existing task data. That is materially different from the declared primary purpose, so this is a mismatch.
The code is specifically a 'task doctor' CLI that inspects task JSON records and filesystem artifact paths for consistency. It validates statuses, dependencies, parent/child links, rollback metadata, notifications, and execution-mode-related fields, then emits findings. While this supports auditability and may be adjacent to a durable workflow system, it does not itself provide the declared primary capability of a durable workflow layer for executing and resuming long-running work. The actual behavior is materially narrower and different in purpose: validation/health checking rather than orchestration/execution.
The declared description suggests a substantial workflow engine/layer responsible for orchestrating long-running work, recovery, parallelism, resumability, and auditable execution. The supplied code chunk does not implement such behavior. Instead, it is a read-only inspection tool for task event history: it parses CLI arguments, loads a single task JSON file, optionally filters events by type and limit, and prints them. While viewing task events may support auditability as a minor supporting detail, the code’s primary purpose is event retrieval/display, not workflow execution or durable coordination. Therefore the code materially underdelivers relative to the declared purpose, so this is a mismatch.
The implemented code does not provide a durable workflow layer or orchestration system. It only loads existing task metadata from local JSON files and renders/export them in various formats. This is an auditing/reporting/visualization utility, not a mechanism for executing multi-stage work, resuming runs, coordinating sub-agents, scheduling background jobs, or managing external side effects. That makes the primary purpose materially different from the declared description.
The declared description presents a substantial workflow system for orchestrating durable long-running work. The supplied code chunk does something much narrower: it scans a local tasks folder, parses task JSON files, derives parent-child relationships, filters for open/root tasks, and prints a textual tree. This is a read-only inspection/reporting script, not a workflow layer. While task visualization could support a workflow system, this chunk’s primary purpose is materially different from the declared purpose, so it should be flagged as a mismatch.
The skill instructs the agent to copy bundled assets into the workspace and create runtime directories, which requires file read/write capability, but it declares no explicit tool scope or permissions boundary. This creates a least-privilege and transparency problem: an agent may perform filesystem mutations without users or policy layers being able to evaluate that capability from the manifest.
The trigger phrase "continue" is excessively generic and is likely to appear in ordinary conversation, which can cause the resume workflow to activate when the user did not intend to resume a durable task. In this skill, unintended invocation is more dangerous because the playbook directs the agent to inspect task state, read logs and outputs, and potentially update checkpoint JSON, which could lead to unintended disclosure or state changes.
The script concatenates an untrusted task ID into a filesystem path and only checks whether that resulting path exists. Because no validation or canonical-path containment check is performed, an attacker can supply path traversal sequences such as '../' to read arbitrary JSON files outside the intended tasks directory, subject to the script's OS permissions. In this skill context, task data includes process/session IDs, cron job IDs, log paths, output directories, recent events, errors, and results, which can expose sensitive operational metadata and make follow-on attacks easier.
The script is presented as an export utility, but when invoked with --write-report it mutates task metadata and writes files to disk. This side effect can surprise callers, break trust boundaries, and enable unintended persistence or state tampering in workflows that expect read-only export behavior.
write_long_report uses a task-controlled artifacts.outputDir to build report_path and then joins it with ROOT without validating that the final path stays inside an approved directory. An attacker who can influence task JSON could supply absolute paths or traversal segments, causing arbitrary file write outside the intended workspace and potentially overwriting sensitive files accessible to the process.
This markdown file defines activation-style user intents such as "列出未完成任务" and "看下哪个任务卡住了" that could overlap with ordinary conversation about tasks, but it does not clearly state the context in which this recovery guide should or should not activate. There are no exclusion conditions or negative examples to limit invocation to explicit task-recovery scenarios.
The listed user intents are entirely in Chinese, which implies a language-specific invocation pattern. The file does not state that the skill is region-specific or offer equivalent language options, so it may violate language/locale choice policy.
The task title and goal are written in Chinese, indicating a fixed language choice in user-facing task metadata. In this example JSON, there is no indication that the language is optional, user-selected, or justified as a region-specific requirement, which can violate language/locale policy constraints.
The user-facing title and goal are written only in Chinese, which imposes a language choice without any visible opt-in or justification in the file. Under the locale policy rule, this is a natural-language policy concern because the skill does not offer a language alternative or document that it is intentionally region-specific.
The example invocation hardcodes a Chinese title and goal, which can signal an implicit language expectation in user-facing guidance. Under the language/locale policy, forcing a specific language without user opt-in can be a natural-language policy violation unless the file clearly offers a choice or justifies the locale constraint.
This shell script creates directories, truncates a log file, and writes a new task JSON file, but the code provides no prior warning, confirmation, or comment disclosing that it will modify files on disk. For code files, file writes should be flagged when there is no visible user disclosure and the operation is not clearly documented in-code.
This manifest hard-codes user-facing task metadata in Chinese ("部署服务", related goal text) with no indication that language selection is optional or region-specific. That can violate a language/locale policy when skills are expected to be language-neutral or user-selectable.
The title and goal are written in Chinese, which indicates a fixed language choice in user-facing task content. The file does not provide any indication that the user selected this locale or that the task is region-specific, so it may violate language/locale policy requirements.
This JSON manifest-like template describes syncing local changes to a Feishu document, but it does not define any explicit trigger phrases, invocation constraints, or exclusion conditions. For a manifest/plain-text scoped rule, the broad description could allow unintended invocation in contexts where a user mentions syncing or updating a document without intending this specific remote-write workflow.
This JSON schema is a manifest-file type, so vague-trigger review applies. The schema defines a very broad, general-purpose task object without any natural-language constraints, scope boundaries, or negative examples indicating when a skill using this schema should or should not be invoked, which can contribute to unintended matching in manifest-driven systems.