asana

v0.1.4

Work with your Asana tasks, subtasks, comments, due dates, and project details to create summaries, understand priorities, and prepare clear status updates.

Codex

By Asana, Inc.License: MIT5.2k GitHub starsUpdated 4 weeks ago

Directory evidence

Runtimes: Codex
Parsed components: 0 skill or MCP entries
Source updated: Aug 26, 2026
Manifest status: Canonical path parsed

The directory validates manifest shape and source location. It does not execute the plugin or provide a security endorsement. Review the indexing methodology →

Install asana for Codex

Installs for the current user

codex plugin marketplace add IchenDEV/agent-plugin-mkt
codex plugin marketplace upgrade agent-plugin-marketplace
codex plugin add asana@agent-plugin-marketplace

Paste and run these commands in a terminal with Codex. They add and refresh the PluginsMP catalog, then install this plugin.

Compatibility: the page URL and API slug “asana-2” remain stable.

Codex: asana-2@agent-plugin-marketplace → asana@agent-plugin-marketplace

The installer fetches third-party code from the source repository shown on this page. This directory validates manifest structure and source location, but does not perform a security audit; review the manifest, components, and source before installing.

Get the source manually

$ git clone https://github.com/openai/plugins

Clone the source repository, then follow its setup instructions to add the plugin to a compatible client. The plugin root is plugins/asana/.

Plugin files

plugins/asana/

└── .codex-plugin/plugin.json

Plugin manifests1

plugins/asana/.codex-plugin/plugin.json

{
  "name": "asana",
  "version": "0.1.4",
  "description": "Work with your Asana tasks, subtasks, comments, due dates, and project details to create summaries, understand priorities, and prepare clear status updates.",
  "author": {
    "name": "Asana, Inc.",
    "url": "https://asana.com"
  },
  "homepage": "https://asana.com",
  "repository": "https://github.com/openai/plugins",
  "license": "MIT",
  "keywords": [
    "asana",
    "tasks",
    "project-management",
    "productivity",
    "collaboration",
    "work-management"
  ],
  "apps": "./.app.json",
  "interface": {
    "displayName": "Asana",
    "shortDescription": "Read and manage Asana",
    "longDescription": "Work with your Asana tasks, subtasks, comments, due dates, and project details to create summaries, understand priorities, and prepare clear status updates.",
    "developerName": "Asana, Inc.",
    "category": "Productivity",
    "capabilities": [
      "Interactive",
      "Write"
    ],
    "websiteURL": "https://asana.com",
    "privacyPolicyURL": "https://asana.com/terms/privacy-statement",
    "termsOfServiceURL": "https://asana.com/terms",
    "defaultPrompt": [
      "Create a project to track creative requests",
      "Create a task to track follow up actions",
      "Show me what's on my plate in Asana today."
    ],
    "brandColor": "#FF584A",
    "composerIcon": "./assets/logo.png",
    "logo": "./assets/logo.png",
    "screenshots": []
  }
}

Browse the “asana” tag →

dkj-policy-bwj

by DaveKJohn

The shared law layer for BWJ's two Shopify stores (smartwatchbanden and xoxowildhearts), packaged so both repos run one identical procedure and cannot drift on it. Four chapters. TICKET HANDLING: a discovered issue is created on GitHub first (GitHub is the source of truth), then mirrored to Asana as a colleague-friendly variant, cross-linked both ways; closing the GitHub issue makes a CI workflow post an update saying the work is ready to test and move the card, never ticking the task off - only the colleague who asked for it can do that. THE SYNC LOG: a 'sync/' branch mirrors what a third party changed on the live theme, is exempt from the changelog by design, and therefore owes a sync-log entry instead - dkj-policy-bwj/SYNC-LOG.md, newest at the top, written and committed by dkj-subagents-shopify's sync-main.ps1 in the same breath as the branch, never folded and never released. THE PREVIEW HANDOVER: where a preview is owed, it is a PAIR per market - the preview beside the live control, whose URL pins the live theme id, because preview_theme_id sets a cookie and the bare URL then keeps serving the preview while the reviewer believes they are looking at live. That pair travels as ONE link to a published page carrying a QR code per market, plus what the gates already proved and the one question being asked - never as a table of URLs, which a terminal wraps past selecting and a phone cannot scan. THE THEME LIFECYCLE: the estate owes two things at the two moments it grows - after the live push, the spent preview themes THIS repo created are swept away; at the release cut that closes that push, a fresh backup of live is taken, polled until it is provably complete (the CLI returns long before the copy is), and only then is the previous backup rotated out, so exactly one is retained and there is never a window with none. Every delete is bounded by a reserved name prefix this repo wrote, never by a theme's role: a store carries far more themes belonging to agencies, apps and colleagues than to the repo, and a role-keyed sweep would destroy them all while looking correct. It relaxes nothing about which changes owe a preview, or about no PR opening before one is approved - it tightens both, by adding exactly TWO steps to that workflow's cycle and changing nothing before the step list. The last step under '### CREATE' is always 'Is the change visible in the frontend / storefront?': dropped with its reason where nothing renders, and otherwise a preview theme, a comment on the GitHub issue carrying the steps and every URL, and ticked only once a PERSON confirms they looked - being last is what makes dkj-policy's own step-list gate hold the PR until then, since an agent can prove a theme exists and never that somebody looked at it. And just before the issue is closed, the paste-ready block gains its go-live half: the next release day (BWJ cuts on Mondays), the version that release is on course for, and the live storefront URL per market - written by build-golive-block.ps1, worded as a plan rather than a promise, and leaving out any fact it cannot derive instead of guessing one. It is an ADDITIVE add-on to 'dkj-policy', not a replacement: it extends four seams of that workflow - the ticket-work layer before a branch, what a sync branch owes, how a preview is handed over, and what the theme estate owes at a push and a cut - and says nothing about branch naming, what an ordinary change owes before a PR, or what a release is. Every chapter is policy rather than mechanism: the Asana CI lives in each repo's .github/, and the sync and preview machinery in 'dkj-subagents-shopify'. Requires the core team 'dkj-subagents-alpha' and 'dkj-policy'; the sync and preview chapters also expect 'dkj-subagents-shopify'. Enable this in BWJ's two Shopify store repos for all four chapters, or in this plugin's own source repo for ticket handling alone (admitted September 14, 2026, commit b9b2a65a) -- the other three chapters are Shopify-store policy and stay at the two stores.

Claude Code5 Skills

1Updated yesterday

For maintainers

If you maintain this plugin, link to this source-backed listing from your README so users can review its manifest and indexed components.

[asana on Agent Plugins Marketplace](https://pluginsmp.com/plugins/asana-2)