NextCloud Deck Tracker

Track OpenClaw tasks on NextCloud Deck board. Auto-add tasks to Queue, move through states.

Security Scan

The skill's runtime instructions require Nextcloud credentials and a 'deck' CLI and describe background monitoring and notifications, but the registry metadata declares no required credentials or install — a clear mismatch that warrants caution before installing or granting secrets.

Purpose & Capability

The skill claims to manage Nextcloud Deck cards, which legitimately requires DECK_URL, DECK_USER, DECK_PASS and a client (the 'deck' CLI). However the registry metadata lists no required environment variables, no primary credential, and no required binaries. The SKILL.md repeatedly instructs use of a 'deck' CLI and environment variables — so the declared metadata does not match the actual capabilities and requirements.

Instruction Scope

Instructions direct the agent to create and update cards, write temp files under /tmp, spawn a background monitor that logs every 60s and 'sends a chat notification' every 120s (defaulting to a user named 'Skander'). The monitor behaviour and the unspecified 'chat notification' endpoint are ambiguous and could result in outbound notifications or data disclosure to an external recipient. Otherwise most commands stay within Nextcloud Deck API usage, but the background-notify behavior and the hardcoded default target are red flags.

Install Mechanism

This is an instruction-only skill (no install spec, no code files). The README suggests installing via 'clawhub' or cloning a GitHub repo (https://github.com/SkanderHelali/openclaw-deck-tracker), but the registry provides no automated install. That means the agent's instructions expect an external 'deck' CLI to already exist or for a user to manually install code from the referenced repo — which could contain arbitrary code. No automatic downloads are performed by the registry entry, lowering automatic install risk, but the manual install path relies on an external GitHub repo that should be inspected before use.

Credentials

The SKILL.md and README both instruct setting DECK_URL, DECK_USER, DECK_PASS, BOARD_ID and optional STACK_* variables. These are appropriate for Nextcloud Deck but are not declared in the registry metadata. DECK_PASS is sensitive (an app password) and granting it without the registry advertising credential needs is a mismatch and increases risk. No other unrelated credentials are requested.

Persistence & Privilege

The skill is not 'always: true' and does not request persistent installation or global config changes. However it explicitly instructs spawning a background monitoring process that runs periodically and sends notifications; that creates runtime persistence while active. Autonomous invocation is allowed (platform default), which combined with unadvertised credential requirements and background notification increases the blast radius — worth noting but not by itself proof of malicious intent.

What to consider before installing

This skill is internally inconsistent: its instructions require a 'deck' CLI and Nextcloud credentials (DECK_URL, DECK_USER, DECK_PASS) but the registry entry lists none. Before installing or providing secrets: 1) Do NOT export your real DECK_PASS until you verify the code. Use a limited-scope Nextcloud App Password. 2) Inspect the referenced GitHub repo (https://github.com/SkanderHelali/openclaw-deck-tracker) — review the 'deck' CLI code and monitor/notification implementation to confirm where notifications are sent. 3) Change the default notification target (the SKILL.md defaults to 'Skander') or disable notifications if you can't verify destination. 4) If you want to test, run the tool in an isolated environment (temporary VM or container) and use least-privilege credentials. 5) Ask the publisher to update registry metadata to declare required env vars and any install steps, and to explain the notification endpoint and monitor process in detail. If you can't verify these, treat the skill as high-risk and avoid giving it credentials.

Deck Tracker v1.0.0

Track tasks on a NextCloud Deck board.

Board Structure

This skill assumes a board with 4 stacks (columns):

Stack	Default ID	Purpose
Queue	1	New incoming tasks
In Progress	2	Currently working on
Waiting	3	Blocked/waiting for user
Done Today	4	Completed tasks

Configuration

Set the following environment variables (e.g. in your .bashrc or OpenClaw config):

export DECK_URL="https://your-nextcloud.com/index.php/apps/deck/api/v1.0"
export DECK_USER="your_username"
export DECK_PASS="your_app_password" # Use an App Password!
export BOARD_ID=1

If your stack IDs differ from the defaults (1, 2, 3, 4), override them:

export STACK_QUEUE=10
export STACK_PROGRESS=11
export STACK_WAITING=12
export STACK_DONE=13

Commands

List all cards on the board

deck list

Add a new task to Queue

deck add "Task title" "Optional description"

Options:

• --progress: Automatically move the new card to "In Progress" immediately.
• --stack <id>: Create in a specific stack ID (default: Queue).

Example with auto-start:

deck add "Urgent Fix" "Fixing production bug" --progress

Move a card to a different stack

deck move <card_id> <queue|progress|waiting|done>

Get card details

deck get <card_id>

Update card title/description

deck update <card_id> [--title "New title"] [--description "New desc"]

Log a status update to a card

deck log <card_id> <status> "Message"

Statuses: progress, success, error, warning, info.

Start automated heartbeat monitoring

deck monitor <card_id> [target_id]

Spawns a background process that appends a "Still working..." log entry every 60 seconds. Additionally, it sends a chat notification to the specified target_id (defaults to Skander) every 120 seconds. The process terminates automatically when the card is moved out of the "In Progress" stack (to Done or Waiting). Use for tasks expected to take >2 minutes.

Dump all completed tasks as JSON

deck dump-done

Outputs the JSON payload for all cards in "Done Today". Useful for memory synthesis.

Archive all completed cards

deck archive-done

Moves all cards in "Done Today" to the archived state. Useful for daily cleanup via cron.

Delete a card

deck delete <card_id>

Workflow & Memory Protocol

1. New task arrives → deck add "Title" "Rich Initial Description" (Use --progress to start immediately).
2. Detailed Descriptions: Start descriptions with Objective, Plan, and Constraints.
3. Log updates → deck log <id> progress "Finished step 1".
4. Closing Task: Use deck update <id> --description "Rich Summary" to include Technical Summary, Operations Performed, and Outcome.
5. Memory Synthesis: Before archiving, use deck dump-done to parse the day's work and reinforce long-term memory.
6. Daily cleanup → deck archive-done.

🚨 AI Protocol: Complex Descriptions

When updating cards with multi-line markdown descriptions, ALWAYS use the temp file method to prevent shell expansion errors:

# 1. Write rich description to temp file
cat > /tmp/deck_desc_<id>.txt << 'EOF'
[Rich Markdown]
EOF

# 2. Update deck using the temp file
deck update <id> --description "$(cat /tmp/deck_desc_<id>.txt)"