Dida365 Openapi
Security checks across static analysis, malware telemetry, and agentic risk
Overview
This appears to be a coherent Dida365 task-management integration, but it gives an authorized agent read/write control over tasks and projects and caches OAuth credentials locally.
This skill is reasonable to install if you want an agent to manage your Dida365 tasks. Before using it, verify OAuth/base URL settings, protect the local token/config files, and require explicit confirmation for deletes, moves, or other bulk account changes.
Static analysis
No static analysis findings were reported for this release.
VirusTotal
VirusTotal findings are pending for this skill version.
Risk analysis
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.
If authorized, the agent can make meaningful changes to your Dida365 account, including moving or deleting tasks/projects.
The documented API surface includes creating, updating, moving, completing, and deleting Dida365 projects/tasks. This is aligned with the skill purpose, but it is account-changing authority.
`POST /open/v1/project` ... `DELETE /open/v1/project/{projectId}` ... `POST /open/v1/task/move` ... `DELETE /open/v1/project/{projectId}/task/{taskId}`Install only if you want the agent to manage Dida365 data, and ask it to confirm destructive or bulk actions such as delete, move, or project updates.
Anyone or any process that can read these local files may be able to reuse credentials or tokens to access task data.
The skill persistently stores OAuth app credentials and token responses locally so later API calls can access the user's Dida365 account.
`config.json`: stores resolved auth settings such as `client_id`, `client_secret`... `token.json`: stores the raw token response from Dida365.
Protect the local config directory, avoid sharing logs or files from it, use `auth clear-token` when access is no longer needed, and rotate credentials if exposed.
A mistaken or maliciously set base URL could route OAuth secrets, bearer tokens, or task content to a non-Dida365 endpoint.
The defaults point to Dida365, but CLI/env/config overrides can change the OAuth and API destinations that receive credentials and task data.
DEFAULT_AUTH_BASE_URL = "https://dida365.com" ... DEFAULT_API_BASE_URL = "https://api.dida365.com" ... "auth_base_url": "DIDA365_AUTH_BASE_URL", "api_base_url": "DIDA365_API_BASE_URL"
Leave auth/API base URLs at their defaults unless you intentionally use a trusted test or proxy endpoint, and check environment variables before authenticating.
You have less registry-level context for verifying the publisher or upstream repository.
The registry metadata does not provide a source URL or homepage, which reduces provenance clarity even though the supplied artifacts include bundled code.
Source: unknown; Homepage: none
Review the bundled files and, if provenance matters, independently verify the referenced project/repository before relying on the skill.