Tirosman Demo Skill

Drive the TirOSMAN autonomous multi-agent demo (5 projects × 150 tasks, Jira-like lifecycle, QA approval) from any MCP-aware client.

Security Scan

The skill's instructions match a TirOSMAN demo controller, but the package metadata omits environment variables the runtime expects (and the skill can post events to external webhooks), so the manifest and runtime behavior are inconsistent and deserve caution.

Purpose & Capability

The name/description (drive a TirOSMAN demo via an MCP) aligns with the SKILL.md instructions: it calls demo_* actions over an MCP HTTP endpoint. However, the SKILL.md expects a bearer API key (TIROSMAN_MCP_API_KEY) and an optional webhook URL, yet registry metadata declares no required environment variables or primary credential — an inconsistency between claimed requirements and actual runtime needs.

Instruction Scope

The instructions are scoped to the demo lifecycle and MCP endpoints (estimate/start/run/status/board/reset/qa). They reference two environment variables (TIROSMAN_MCP_API_KEY and TIROSMAN_DEMO_WEBHOOK_URL) and note that task-status events will be POSTed to the webhook if set. The instructions do not tell the agent to read unrelated system files, but they do cause outbound network calls (MCP endpoint and optional arbitrary webhook) which can transmit demo event data externally.

Install Mechanism

No install spec and no code files — instruction-only skill. This is the lowest-risk install mechanism; nothing is written to disk by the skill package itself.

Credentials

The SKILL.md references TIROSMAN_MCP_API_KEY (required for bearer auth) and TIROSMAN_DEMO_WEBHOOK_URL (optional) but the registry metadata lists no required env vars or primary credential. That omission is disproportionate/unexplained. The webhook URL, if set, will receive real-time task transitions and could be used to exfiltrate demo data, so users must ensure any webhook is trusted and does not point to external collectors they don't control.

Persistence & Privilege

always is false and the skill is user-invocable; it does not request persistent or system-wide privileges. The skill does not declare that it will modify other skills or system configs.

What to consider before installing

The skill appears to implement a TirOSMAN demo controller, but the manifest omitted environment variables the runtime expects. Before installing: 1) Confirm the MCP endpoint (mcp.url) and whether a TIROSMAN_MCP_API_KEY is required — ask the publisher to add it to the metadata or refuse until corrected. 2) Never point TIROSMAN_DEMO_WEBHOOK_URL at an untrusted external endpoint — webhook events contain task transitions and could leak data. 3) Run the demo only against a non-production company_id and an isolated/local MCP/Postgres instance so demo_start/demo_reset won't touch real data. 4) If you need higher assurance, request the publisher to publish a homepage/source and to declare required env vars and a security/privacy note. The current mismatch between docs and manifest is a red flag — treat it as suspicious until clarified.

TirOSMAN Demo Mode

Multi-agent demo powered by the real NVIDIA adapter (meta/llama-3.1-405b-instruct). Five concurrent projects × 30 tasks each × agent roles (pm, dev, frontend, qa, ceo), stored in Postgres with RLS, ticked through a Jira-like lifecycle: backlog → analysis → in_progress → code_review → qa → done.

When to use

• User says "start the TirOSMAN demo" / "kick off the 150-task run" / "show the Jira board."
• User wants a cost preview before burning NVIDIA tokens.
• User needs to approve or reject QA-blocked tasks.
• User wants to wipe every demo-generated task and start over.

Call order

1. demo_estimate first — returns projected tokens + cost, zero DB writes. Use it to confirm intent.
2. demo_start(company_id, auto_run=True) — creates tasks AND kicks off the batch executor. Pass auto_run=False if you want a confirm step before burning tokens.
3. demo_run(company_id, projects?) — resume execution when auto_run=False, after QA approvals, or after an interruption. Idempotent.
4. Poll demo_status(company_id) until all tasks are done/failed/qa.
5. If any task lands in qa, use demo_qa_approve or demo_qa_reject, then demo_run again to push it through.
6. demo_board(company_id, project?) for the visual column layout.
7. demo_reset(company_id) wipes everything the demo created.

Notes

• demo_start only creates the rows. The batch executor runs inside TirOSMAN via FastAPI BackgroundTasks, triggered by POST /api/companies/{id}/demo-mode. If you called demo_start directly over MCP, the UI "advance" button or the HTTP endpoint has to drive execution.
• Task-status events are also POSTed to $TIROSMAN_DEMO_WEBHOOK_URL if set. Downstream webhook plugins (n8n, Zapier, Slack) see every transition in real time.
• Estimates are static — they do not change as tasks run.

Failure modes

• No agents on the company → demo_start returns started=false with an explanation.
• Invalid company_id → tools surface a 404 from the HTTP layer.
• MCP bearer missing when TIROSMAN_MCP_API_KEY is set server-side → 401.