Project Router

Terminal-first project bootstrapper and workspace context manager. Use when the user asks for /project-style workflows: detect current project, read project context/brief, run standardized targets (build/test/lint/deploy), init a .project bundle via plan/apply, manage artifacts, or expose these actions via MCP server mcp-project-router and CLI project.

Security Scan

The skill mostly matches a local project/CLI router but contains multiple mismatches and fragile/hardcoded assumptions (hardcoded binary path, undocumented install step, unimplemented Trello/DB features) and will execute arbitrary shell commands from project targets using the agent environment—so proceed with caution.

Purpose & Capability

The name/description promise a CLI + MCP server + Trello sync + canonical SQLite store. The repository includes a CLI (scripts/project.js) and an MCP server wrapper (scripts/server.js), but there is no Trello adapter, no SQLite integration, and no homepage or install instructions. The SKILL.md recommends a DB path and Trello conventions but the code does not implement those features; the server also assumes the CLI binary lives at a hardcoded path (/home/safa/clawd/bin/project). These mismatches suggest the distribution is incomplete or configured for a specific developer environment.

Instruction Scope

The runtime code and SKILL.md direct the agent to run local CLI commands and an MCP server that will spawn the project CLI. The CLI's runTarget will execute commands from .project/targets.json with spawnSync(shell: true) inheriting process.env, which means arbitrary shell commands can run with the agent's environment and their stdout/stderr is returned to callers. The search functionality reads many files under the repo. The SKILL.md does not explicitly warn that targets run arbitrary shell commands or that command output may include sensitive data.

Install Mechanism

No install spec is provided (instruction-only), yet server.js expects a binary at /home/safa/clawd/bin/project. The included scripts/project.js could serve as that binary, but there's no guidance to install or place it at that path. This is a fragile, developer-specific assumption rather than a transparent install mechanism.

Credentials

The skill declares no required env vars or credentials, yet SKILL.md documents Trello sync and a canonical DB path (both referencing a specific user 'safa' and /home/safa/clawd) without showing any credential handling. More importantly, when running targets the CLI inherits process.env so target commands can read any environment secrets available to the agent. There is no explicit declaration or mitigation for that exposure.

Persistence & Privilege

The skill does not request persistent platform privileges (always:false) and only writes to project-local .project/ files through an explicit plan/apply flow. The MCP server acts as a wrapper and does not modify other skills or global agent configuration.

What to consider before installing

This skill implements a local project CLI and an MCP server wrapper but shows several red flags you should address before installing: (1) The MCP server expects the 'project' binary at /home/safa/clawd/bin/project — there are no install steps; ensure you know where the CLI will be installed and adjust that path. (2) SKILL.md mentions Trello sync and a SQLite canonical DB, but the included code does not implement them; treat those features as untrusted/unfinished. (3) Running 'project target run' will execute arbitrary shell commands from .project/targets.json with the agent's environment—inspect targets.json before executing, and avoid running this skill in directories containing secrets or as a privileged user. (4) The search and other commands read repository files; be careful if those files contain sensitive information. If you plan to use this skill: request or provide clear install instructions, replace the hardcoded PROJECT_BIN with a configurable path, audit .project/targets.json and any planned commands, and do not run it with elevated privileges. My confidence is medium; additional information that would raise confidence: an explicit install script/instructions, removal of hardcoded paths, or confirmation that Trello/DB integrations are intentionally omitted or provided with secure credential handling.

This skill is Safa’s canonical project management + context switching control plane.

Core idea:

• Canonical PM is local + queryable (SQLite): projects, tasks, context packs.
• Trello is a tracking backend/UI: cards mirror canonical tasks; lists mirror status; labels mirror priority.
• The “killer feature” is context switching: load the right docs/code/index for a project/task quickly and deterministically.

It provides:

• CLI: project <verb> ...
• MCP server: mcp-project-router (tools mirror the CLI)
• Per-project bundle stored in .project/ (brief, targets, artifact index)
• A canonical task store (SQLite) + Trello sync adapter

Project bundle layout (v1)

The .project/ bundle is the project-local context nucleus. The canonical PM DB points at these bundles.

Inside a project root:

• .project/project.json — structured manifest
• .project/PROJECT.md — living brief
• .project/targets.json — target definitions (commands)
• .project/index/artifacts.json — artifact index
• .project/history/plans/*.json — plans
• .project/history/applies/*.json — apply receipts

CLI quick start

Baseline / existing commands

From anywhere inside a repo/workspace:

• project detect
• project context
• project target list
• project target run <name>

Initialize a bundle (dry-run plan + apply):

• project init (prints plan)
• project apply <planId>

Artifacts:

• project artifact add <path|url> [--tags a,b,c] (plan + apply)

Canonical PM + context switching (new)

Note: these verbs are the target UX. Implementations should remain idempotent and safe.

Project registration:

• project pm project add <slug> --name "..." --root <path>
• project pm project list

Task management:

• project pm task add <slug> "<title>" --priority P0|P1|P2|P3 [--status inbox|next|doing|blocked|waiting|done]
• project pm task list [--project <slug>] [--status ...]
• project pm task set-status <taskId> <status>

Context switching:

• project pm switch <slug>
  • prints pinned docs + top targets + active tasks
• project pm focus <taskId>
  • loads task-linked files/artifacts and updates the task activity log

Trello sync:

• project pm trello sync [--project <slug>]
  • ensures the single "Safa — PM" Trello board exists
  • ensures lists exist (Inbox/Next/Doing/Blocked/Waiting/Done)
  • upserts cards for canonical tasks
  • moves cards to match status
  • applies priority labels (P0..P3)

MCP quick start (via mcporter)

• mcporter list mcp-project-router --schema --timeout 120000 --json

Examples:

• Detect:
  • mcporter call --server mcp-project-router --tool project_detect --args '{}'
• Read context:
  • mcporter call --server mcp-project-router --tool project_context_read --args '{}'
• Run target:
  • mcporter call --server mcp-project-router --tool project_target_run --args '{"target":"test"}'

Trello backend conventions

Single-board setup:

• Board name: Safa — PM (or configurable)
• Lists == canonical statuses:
  • Inbox, Next, Doing, Blocked, Waiting, Done
• Card title: [<project_slug>] <task_title>
• Card description begins with a machine block for idempotency:

  --- pm ---
  task_id: <stable-id>
  project: <slug>
  status: <status>
  priority: P0|P1|P2|P3
  ---
  

• Labels (priority, color-coded):
  • P0 = red
  • P1 = orange
  • P2 = yellow
  • P3 = blue

Canonical PM storage (SQLite)

Recommended DB location (in workspace):

• /home/safa/clawd/data/pm/pm.sqlite

Minimum tables (v0):

• projects(slug PRIMARY KEY, name, root_path, created_at, updated_at)
• tasks(task_id PRIMARY KEY, project_slug, title, status, priority, created_at, updated_at)
• task_refs(task_id, kind, ref) (file paths / urls / artifacts)
• external_refs(task_id, system, external_id, meta_json) (e.g., Trello card_id/list_id)

Safety

• Project bundle writes remain plan/apply.
• Canonical PM writes should be idempotent and auditable (timestamps + activity log).
• Trello sync should be safe to re-run repeatedly (upsert by task_id marker; never duplicate cards).
• project_target_run executes commands defined in .project/targets.json.