Execute qualquer Skill no Manus
com um clique

Execute qualquer Skill no Manus com um clique

Começar

decisions-cursor-worker

Estrelas14

Forks3

Atualizado16 de junho de 2026 às 21:49

Use when Cursor is running work that originated from DecisionsAI tickets, projects, workflows, or Initiative proposals.

Instalação

Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.

Executar no Manus

Fonte

tensology

tensology/decisionsai

Abrir repositório GitHub Ver repositórios do creator

Download

Executar no Manus

Ocupações relacionadasSOC

Baseado na classificação ocupacional SOC

Desenvolvedores de softwareInformática e Matemática·SOC 15-1252

SKILL.md

readonly

name	decisions-cursor-worker
description	Use when Cursor is running work that originated from DecisionsAI tickets, projects, workflows, or Initiative proposals.

DecisionsAI Cursor Worker

When a task comes from DecisionsAI:

Treat the instruction as project-bound work. Use the provided ticket, board, workflow, and project context as the source of truth.
Keep edits scoped to the project folder and the explicit ticket outcome.
If the prompt includes previous-step context or a result packet, use it as state handed over by the DecisionsAI workflow. Do not discard it when implementing or validating the current step.
Respect the model selected by DecisionsAI/Cursor runtime. Do not claim a different model was used unless the runtime explicitly reports it.
For workflow steps, iterate inside the step before reporting complete: do → test → self-assess (drift, security, UI sanity) → correct → report. Use bundled skills when listed in the work packet. The human steers via the orchestrator, not by programming sub-steps in Cursor.

Report status in this shape (one field per line) so the orchestrator records it:

Status: completed | failed | needs_input
Summary: ...
Tests run: ...
Drift check: ...
Security: ...
UI assessment: ...
Self-corrections: ...
Files changed: ...
Blockers: ...

If a ticket lacks enough context, return Status: needs_input with the specific missing decision instead of inventing requirements.
If the task is part of a workflow, include any artifact paths or validation output the next workflow step needs.
If DecisionsAI asks for a practical implementation, make a real, inspectable artifact rather than a plan-only response unless the instruction is explicitly an audit or planning step.
Prefer the Cursor IDE/chat surface as the primary execution context. The CLI is fallback transport for automation or setup checks, not the canonical conversation. Keep responses structured so DecisionsAI can checkpoint, retry, escalate, continue, or close the workflow step.
When a task is too broad for one pass, complete the safest useful slice and set Next step to the exact continuation DecisionsAI should queue.
Apply the DecisionsAI harness prerequisites on every implementation task:
- decisions-harness-stack — master index (ECC, Ponytail, Fallow, RTK, browser/content).
- Ponytail (ponytail skill) — YAGNI ladder, stdlib-first, minimal diff; mark shortcuts with ponytail: comments.
- Fallow (fallow skill) — on JS/TS repos, run npx fallow audit --format json --quiet || true before reporting complete and attach the verdict in Tests run: or Evidence:.
- Browser / QA — browser-qa, decisions-playwright, webapp-testing when touching UI; use Hermes playwright_browser when Decisions is running.
- Content / video — content-engine, article-writing, remotion-video-creation, fal-ai-media when the ticket is content work (see ~/.decisions/harness/mcp-recommendations.json for fal MCP).
- UI ideation — decisions-ui-ideation then decisions-design-references before new screens; use Refero/Mobbin MCP when configured (see ~/.decisions/harness/mcp-setup-design.sh).
- Internet research — decisions-agent-reach + agent-reach for URLs, social, video, GitHub, RSS; run agent-reach doctor --json first.
- 30-day synthesis — last30days when the ticket needs “what people said lately” (heavier than agent-reach; needs last30days scripts + optional API keys).
- Publishable copy — humanizer after drafts; decisions-marketing-skills + product-marketing for GTM work.
- YouTube / subtitles — decisions-yt-dlp or workflow ytdlp steps; not for Bilibili (use agent-reach bili).
- SaaS apps (Gmail, Slack, Notion, Jira) — decisions-composio (Composio Connect MCP); not Rube (deprecated).
For any normal Cursor IDE/chat prompt inside a DecisionsAI project folder, even when it did not originate from a workflow packet, report the turn to DecisionsAI as a project IDE session. At the start of the prompt, call: python3 ~/.cursor/plugins/local/decisions-cursor/scripts/report_decisions_event.py --event-type cursor_prompt_submitted --status observed --input "<user prompt>" --thread-id "<cursor chat id when known>" Before the final response, call: python3 ~/.cursor/plugins/local/decisions-cursor/scripts/report_decisions_event.py --cwd "<project folder>" --turn-output "Status: completed\nSummary: <short result summary>" --thread-id "<cursor chat id when known>" If both sides of a completed turn are only available at the end, call: python3 ~/.cursor/plugins/local/decisions-cursor/scripts/report_decisions_event.py --cwd "<project folder>" --turn-input "<user prompt>" --turn-output "Status: completed\nSummary: <short result summary>" For workflow work packets, the reporter auto-discovers the bridge URL and execution session from the newest .tickets/ticket_*.md or .tickets/decisionsai_*.md file.
If the prompt includes a [DECISIONS CURSOR CALLBACK] block, treat that as live workflow metadata. Use the callback URL or reporter script in that block to report meaningful events back to DecisionsAI:
- cursor_started when work begins.
- cursor_prompt_submitted after every user prompt or IDE instruction submission connected to this DecisionsAI run, including follow-up prompts typed directly in Cursor.
- user_steer when the human changes direction, adds constraints, or corrects the approach.
- cursor_waiting or cursor_needs_input when blocked on a decision.
- cursor_interrupted when the current task is paused or superseded.
- cursor_progress for material implementation milestones.
- cursor_completed or cursor_failed when the work finishes. If there is no workflow callback block, still report project chat events through the reporter script. It will use the current working directory to create or resume a DecisionsAI project IDE session: python3 ~/.cursor/plugins/local/decisions-cursor/scripts/report_decisions_event.py --event-type cursor_prompt_submitted --status observed --message "<what changed>"
Do not keep steering only inside the Cursor conversation. If the human gives new direction while a DecisionsAI workflow is running, report it so DecisionsAI can store the event, update workflow memory, and let the orchestrator decide whether to continue, validate, retry, or ask a follow-up.
Before reporting an event, assume DecisionsAI may or may not be open. If DecisionsAI is reachable and the callback or reporter succeeds, continue normally. If DecisionsAI is not reachable, keep working without surfacing a bridge error to the user unless the task explicitly asks for diagnostics.

Mais deste repositório

mesmo repositório

agent-reach

tensology/decisionsai

MUST USE when user wants to research/search/look up/find anything on the internet — e.g. "research this topic", "do a deep dive on X", "search the web for X", "see what people say about X", "look this up". Also MUST USE when user mentions any platform or shares any URL/link: Twitter/X, Reddit, Facebook, Instagram, YouTube, GitHub, Bilibili, XiaoHongShu, Xiaoyuzhou Podcast, LinkedIn/jobs/recruiting, V2EX, Xueqiu (stocks), RSS. 15 platforms, multi-backend routing (OpenCLI / per-platform CLIs / APIs). Zero config for 6 channels. Run `agent-reach doctor --json` to see which backend serves each platform right now. NOT for: writing reports/analysis/translation (this skill only FETCHES internet content); posting/commenting/liking (write operations); platforms that already have a dedicated skill installed (prefer that skill).

2026-06-3014

enterprise

tensology/decisionsai

Dark-themed cloud-platform aesthetic with modular grids, glass-like panels, and strong data hierarchy for productivity dashboards.

2026-06-3014

last30days

tensology/decisionsai

Research what people actually say about any topic in the last 30 days. Pulls posts and engagement from Reddit, X, YouTube, TikTok, Hacker News, Polymarket, GitHub, and the web.

2026-06-3014

visual-plan

tensology/decisionsai

Turn ordinary text plans into rich interactive visual plans with diagrams, file maps, annotated code, open questions, and UI/prototype review when useful.

2026-06-3014

visual-recap

tensology/decisionsai

Turn a PR, branch, commit, or git diff into an interactive visual recap with diagrams, file maps, API/schema summaries, annotated diffs, and focused review notes.

2026-06-3014

decisions-design-aesthetics

tensology/decisionsai

Pick a design aesthetic from awesome-design-skills — bundled minimal/professional/enterprise/shadcn/bento; full catalog in reference for on-demand load.

2026-06-3014

DecisionsAI Cursor Worker

When a task comes from DecisionsAI:

Treat the instruction as project-bound work. Use the provided ticket, board, workflow, and project context as the source of truth.

Keep edits scoped to the project folder and the explicit ticket outcome.

If the prompt includes previous-step context or a result packet, use it as state handed over by the DecisionsAI workflow. Do not discard it when implementing or validating the current step.

Respect the model selected by DecisionsAI/Cursor runtime. Do not claim a different model was used unless the runtime explicitly reports it.

For workflow steps, iterate inside the step before reporting complete: do → test → self-assess (drift, security, UI sanity) → correct → report. Use bundled skills when listed in the work packet. The human steers via the orchestrator, not by programming sub-steps in Cursor.

Report status in this shape (one field per line) so the orchestrator records it:

Status: completed | failed | needs_input Summary: ... Tests run: ... Drift check: ... Security: ... UI assessment: ... Self-corrections: ... Files changed: ... Blockers: ...

If a ticket lacks enough context, return Status: needs_input with the specific missing decision instead of inventing requirements.

If the task is part of a workflow, include any artifact paths or validation output the next workflow step needs.

If DecisionsAI asks for a practical implementation, make a real, inspectable artifact rather than a plan-only response unless the instruction is explicitly an audit or planning step.

Prefer the Cursor IDE/chat surface as the primary execution context. The CLI is fallback transport for automation or setup checks, not the canonical conversation. Keep responses structured so DecisionsAI can checkpoint, retry, escalate, continue, or close the workflow step.

When a task is too broad for one pass, complete the safest useful slice and set Next step to the exact continuation DecisionsAI should queue.

Apply the DecisionsAI harness prerequisites on every implementation task:

decisions-harness-stack — master index (ECC, Ponytail, Fallow, RTK, browser/content).
Ponytail (ponytail skill) — YAGNI ladder, stdlib-first, minimal diff; mark shortcuts with ponytail: comments.
Fallow (fallow skill) — on JS/TS repos, run npx fallow audit --format json --quiet || true before reporting complete and attach the verdict in Tests run: or Evidence:.
Browser / QA — browser-qa, decisions-playwright, webapp-testing when touching UI; use Hermes playwright_browser when Decisions is running.
Content / video — content-engine, article-writing, remotion-video-creation, fal-ai-media when the ticket is content work (see ~/.decisions/harness/mcp-recommendations.json for fal MCP).
UI ideation — decisions-ui-ideation then decisions-design-references before new screens; use Refero/Mobbin MCP when configured (see ~/.decisions/harness/mcp-setup-design.sh).
Internet research — decisions-agent-reach + agent-reach for URLs, social, video, GitHub, RSS; run agent-reach doctor --json first.
30-day synthesis — last30days when the ticket needs “what people said lately” (heavier than agent-reach; needs last30days scripts + optional API keys).
Publishable copy — humanizer after drafts; decisions-marketing-skills + product-marketing for GTM work.
YouTube / subtitles — decisions-yt-dlp or workflow ytdlp steps; not for Bilibili (use agent-reach bili).
SaaS apps (Gmail, Slack, Notion, Jira) — decisions-composio (Composio Connect MCP); not Rube (deprecated).

For any normal Cursor IDE/chat prompt inside a DecisionsAI project folder, even when it did not originate from a workflow packet, report the turn to DecisionsAI as a project IDE session. At the start of the prompt, call:

python3 ~/.cursor/plugins/local/decisions-cursor/scripts/report_decisions_event.py --event-type cursor_prompt_submitted --status observed --input "<user prompt>" --thread-id "<cursor chat id when known>"

Before the final response, call:

python3 ~/.cursor/plugins/local/decisions-cursor/scripts/report_decisions_event.py --cwd "<project folder>" --turn-output "Status: completed\nSummary: <short result summary>" --thread-id "<cursor chat id when known>"

If both sides of a completed turn are only available at the end, call:

python3 ~/.cursor/plugins/local/decisions-cursor/scripts/report_decisions_event.py --cwd "<project folder>" --turn-input "<user prompt>" --turn-output "Status: completed\nSummary: <short result summary>"

For workflow work packets, the reporter auto-discovers the bridge URL and execution session from the newest .tickets/ticket_*.md or .tickets/decisionsai_*.md file.

If the prompt includes a [DECISIONS CURSOR CALLBACK] block, treat that as live workflow metadata. Use the callback URL or reporter script in that block to report meaningful events back to DecisionsAI:

cursor_started when work begins.
cursor_prompt_submitted after every user prompt or IDE instruction submission connected to this DecisionsAI run, including follow-up prompts typed directly in Cursor.
user_steer when the human changes direction, adds constraints, or corrects the approach.
cursor_waiting or cursor_needs_input when blocked on a decision.
cursor_interrupted when the current task is paused or superseded.
cursor_progress for material implementation milestones.
cursor_completed or cursor_failed when the work finishes. If there is no workflow callback block, still report project chat events through the reporter script. It will use the current working directory to create or resume a DecisionsAI project IDE session: python3 ~/.cursor/plugins/local/decisions-cursor/scripts/report_decisions_event.py --event-type cursor_prompt_submitted --status observed --message "<what changed>"

Do not keep steering only inside the Cursor conversation. If the human gives new direction while a DecisionsAI workflow is running, report it so DecisionsAI can store the event, update workflow memory, and let the orchestrator decide whether to continue, validate, retry, or ask a follow-up.

Before reporting an event, assume DecisionsAI may or may not be open. If DecisionsAI is reachable and the callback or reporter succeeds, continue normally. If DecisionsAI is not reachable, keep working without surfacing a bridge error to the user unless the task explicitly asks for diagnostics.