Nx Generate
nomcopter/react-mosaic
Generate code using nx generators. An agent skill from nomcopter/react-mosaic.
A skill your agent uses when making Workfront load your locally running App Builder extension, or when a local extension that worked before has stopped appearing.
Install Workfront Local Testing
$ npx skills add adobe/skills --skill workfront-local-testing -a claude-codeProject install by default; add -g for ~/.claude/skills/.
$ gh skill install adobe/skills workfront-local-testing --agent claude-codeProject scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).
$ git clone --depth 1 https://github.com/adobe/skills.git skills-src && mkdir -p .claude/skills && cp -r skills-src/plugins/app-builder/skills/appbuilder-workfront/workfront-local-testing .claude/skills/workfront-local-testing && rm -rf skills-srcUse ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.
Claude Code skills documentation · loads skills from .claude/skills/
Install the "workfront-local-testing" agent skill from https://github.com/adobe/skills/tree/main/plugins/app-builder/skills/appbuilder-workfront/workfront-local-testing into .claude/skills/workfront-local-testing/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "workfront-local-testing", then confirm the skill loads.Claude Code copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$skill-installer install https://github.com/adobe/skills/tree/main/plugins/app-builder/skills/appbuilder-workfront/workfront-local-testingType this inside Codex. $skill-installer <name> installs a curated skill from openai/skills. The installer writes to $CODEX_HOME/skills (default ~/.codex/skills). Restart Codex if the skill does not show up.
$ npx skills add adobe/skills --skill workfront-local-testing -a codexProject install goes to .agents/skills/; add -g for ~/.codex/skills/.
$ gh skill install adobe/skills workfront-local-testing --agent codexProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/adobe/skills.git skills-src && mkdir -p .agents/skills && cp -r skills-src/plugins/app-builder/skills/appbuilder-workfront/workfront-local-testing .agents/skills/workfront-local-testing && rm -rf skills-srcUse ~/.agents/skills/ instead of .agents/skills for a personal install.
Codex skills documentation · loads skills from .agents/skills/
Install the "workfront-local-testing" agent skill from https://github.com/adobe/skills/tree/main/plugins/app-builder/skills/appbuilder-workfront/workfront-local-testing into .agents/skills/workfront-local-testing/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "workfront-local-testing", then confirm the skill loads.Codex copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add adobe/skills --skill workfront-local-testing -a cursorProject install goes to .agents/skills/; add -g for ~/.cursor/skills/.
$ gh skill install adobe/skills workfront-local-testing --agent cursorProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/adobe/skills.git skills-src && mkdir -p .cursor/skills && cp -r skills-src/plugins/app-builder/skills/appbuilder-workfront/workfront-local-testing .cursor/skills/workfront-local-testing && rm -rf skills-srcUse ~/.cursor/skills/ instead of .cursor/skills for a personal install.
Cursor skills documentation · loads skills from .cursor/skills/, .agents/skills/, .claude/skills/, .codex/skills/
Install the "workfront-local-testing" agent skill from https://github.com/adobe/skills/tree/main/plugins/app-builder/skills/appbuilder-workfront/workfront-local-testing into .cursor/skills/workfront-local-testing/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "workfront-local-testing", then confirm the skill loads.Cursor copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gemini skills install https://github.com/adobe/skills.git --path plugins/app-builder/skills/appbuilder-workfront/workfront-local-testing--scope user (default) or --scope workspace; --path is the subfolder of the repo that holds the skill; --consent skips the security confirmation prompt.
$ npx skills add adobe/skills --skill workfront-local-testing -a gemini-cliProject install goes to .agents/skills/; add -g for ~/.gemini/skills/.
$ gh skill install adobe/skills workfront-local-testing --agent gemini-cliProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/adobe/skills.git skills-src && mkdir -p .gemini/skills && cp -r skills-src/plugins/app-builder/skills/appbuilder-workfront/workfront-local-testing .gemini/skills/workfront-local-testing && rm -rf skills-srcUse ~/.gemini/skills/ instead of .gemini/skills for a personal install, then run /skills reload.
Gemini CLI skills documentation · loads skills from .gemini/skills/, .agents/skills/
Install the "workfront-local-testing" agent skill from https://github.com/adobe/skills/tree/main/plugins/app-builder/skills/appbuilder-workfront/workfront-local-testing into .gemini/skills/workfront-local-testing/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "workfront-local-testing", then confirm the skill loads.Gemini CLI copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gh skill install adobe/skills workfront-local-testingInstalls for Copilot at project scope by default; add --scope user for a personal install. Preview a skill first with gh skill preview. Needs GitHub CLI 2.90.0 or later (public preview).
$ npx skills add adobe/skills --skill workfront-local-testing -a github-copilotProject install goes to .agents/skills/; add -g for ~/.copilot/skills/.
$ git clone --depth 1 https://github.com/adobe/skills.git skills-src && mkdir -p .github/skills && cp -r skills-src/plugins/app-builder/skills/appbuilder-workfront/workfront-local-testing .github/skills/workfront-local-testing && rm -rf skills-srcUse ~/.copilot/skills/ instead of .github/skills for a personal install. Commit .github/skills so cloud agent and code review can use it.
GitHub Copilot skills documentation · loads skills from .github/skills/, .claude/skills/, .agents/skills/
Install the "workfront-local-testing" agent skill from https://github.com/adobe/skills/tree/main/plugins/app-builder/skills/appbuilder-workfront/workfront-local-testing into .github/skills/workfront-local-testing/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "workfront-local-testing", then confirm the skill loads.GitHub Copilot copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add adobe/skills --skill workfront-local-testing -a opencodeOpenCode documents no install command of its own. Project install goes to .agents/skills/; add -g for ~/.config/opencode/skills/.
$ gh skill install adobe/skills workfront-local-testing --agent opencodeProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/adobe/skills.git skills-src && mkdir -p .opencode/skills && cp -r skills-src/plugins/app-builder/skills/appbuilder-workfront/workfront-local-testing .opencode/skills/workfront-local-testing && rm -rf skills-srcUse ~/.config/opencode/skills/ instead of .opencode/skills for a personal install.
OpenCode skills documentation · loads skills from .opencode/skills/, .claude/skills/, .agents/skills/
Install the "workfront-local-testing" agent skill from https://github.com/adobe/skills/tree/main/plugins/app-builder/skills/appbuilder-workfront/workfront-local-testing into .opencode/skills/workfront-local-testing/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "workfront-local-testing", then confirm the skill loads.OpenCode copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
Facts
- Skill name
workfront-local-testing- GitHub stars
- 195
- Token cost
- ~2.4k tokens
- SKILL.md length
- 1,148 words
- Files
- 2
- Skills in repo
- 105
- Repo updated
- First seen
- Licence
- Apache-2.0
At a glance
A skill your agent uses when making Workfront load your locally running App Builder extension, or when a local extension that worked before has stopped appearing.
- Works in 4 steps: extensionOverride (the key step) → Accept the dev certificate → Chrome 142+ Local Network Access → …
- Making Workfront load your locally running App Builder extension
- SKILL.md covers 1. extensionOverride (the key…, Deployed app, no publish?…, Open the deployed app — the… and 2. Accept the dev certificate, plus 3 more sections
- Reaches experience-stage.adobe.com and experience.adobe.com
What it does
Workfront Local Testing is an agent skill from adobe/skills. Use when making Workfront load your locally running App Builder extension, or when a local extension that worked before has stopped appearing. Reach for this whenever the user is: trying to preview their local build inside Workfront before deploying; setting extensionOverride in localStorage but Workfront still shows the published version; seeing buttons, widgets, or left-panel items not appear in Workfront even though aio app dev is running; hitting a cert warning on localhost that blocks Workfront from loading…
Its SKILL.md is about 2.4k tokens, which your agent loads only when the skill is triggered. The skill folder holds 2 other files (for example `evals/evals.json`).
It sits in Development, covering Project scaffolding. The repository describes itself as: Adobe Skills for Agents. The licence is Apache-2.0.
When your agent uses it
- Making Workfront load your locally running App Builder extension
- A local extension that worked before has stopped appearing
Example prompts
- “/workfront-local-testing”
Workflow steps
4 steps, taken from the step headings in SKILL.md.
What it can do on your machine
Read from SKILL.md and the folder at commit cbc9952. It shows what the files ask for, not the result of running them.
Tool permissions
Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.
From allowed-tools in the SKILL.md frontmatter.
Runs code
No scripts in the folder and no shell commands in SKILL.md.
From the folder's file list and the shell code blocks in SKILL.md.
Network
Hosts in commands or code, which the agent is likely to contact:
experience-stage.adobe.comexperience.adobe.com
From URLs in SKILL.md, links to its own repository left out.
Credentials
Names no API keys, tokens, secrets or passwords.
From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.
Context cost
Workfront Local Testing loads about 2.4k tokens when it runs. Until then it costs about 257 tokens; SKILL.md has 1,148 words of instructions outside code blocks.
Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.
Safety
Auto-check passed
The automated check found no risky patterns in SKILL.md.
Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.
SKILL.md
The full file from adobe/skills at commit cbc9952, republished under its Apache-2.0 licence (© adobe). 1,148 words, ~2,444 tokens.
Download SKILL.mdSave it as
.claude/skills/workfront-local-testing/SKILL.md (or your agent's skills folder). This skill also uses 1 other file; get the full folder from GitHub.- name
- workfront-local-testing
- description
- Use when making Workfront load your locally running App Builder extension, or when a local extension that worked before has stopped appearing. Reach for this whenever the user is: trying to preview their local build inside Workfront before deploying; setting `extensionOverride` in localStorage but Workfront still shows the published version; seeing buttons, widgets, or left-panel items not appear in Workfront even though `aio app dev` is running; hitting a cert warning on localhost that blocks Workfront from loading the extension; seeing a local extension silently break after a Chrome update (Chrome 142+ blocks localhost connections); asking what value to set `extensionOverride` to and exactly where to set it in the browser; asking whether a custom-form widget should appear in the field picker; or wondering if Workfront admin rights are needed to see locally-loaded extension points. Separate from `appbuilder-workfront` (the umbrella) and `appbuilder-project-init` (scaffolding / dev server).
- license
- Apache-2.0
Test a local extension inside Workfront
After aio app dev (command catalog in appbuilder-workfront → references/commands.md) you have a localhost URL. This makes Workfront load your local app instead of (or alongside) published ones — no deploy required.
1. extensionOverride (the key step)
In the browser, on your Workfront tab (*.workfront.com or *.workfront.adobe.com):
DevTools → Application → Local Storage → add an entry:
- key:
extensionOverride - value: your dev URL, e.g.
https://localhost:9080
Take the exact URL/port from the aio app dev output. Reload the layout-template page — your extension's buttons/widgets appear.
For custom-form widgets, the widget picker lists locally-active apps when the override is set (surfaced as
extensionoverride=TRUE).
Deployed app, no publish? Extension Manager (Bring Your Own)
extensionOverride points Workfront at a local (localhost) build. To use a deployed app (its CDN URL) in an org without the prod publish + approval process, register it in Extension Manager:
Workfront → Extension Manager — always give the user the direct link (pick the org in the switcher if @<org> differs):
- Stage:
https://experience-stage.adobe.com/#/@<org>/workfront/extension-manager - Prod:
https://experience.adobe.com/#/@<org>/workfront/extension-manager
(If the org has more than one Workfront instance, the shell scopes the link with a so:<instance> segment before /workfront/ — …/@<org>/so:<instance>/workfront/extension-manager. If the link lands on the wrong instance, copy @<org>/so:<instance> verbatim from a Workfront page you're already on.)
→ Bring Your Own extension, then fill in (always list these fields):
- Extension Url — the deployed app's
index.html, e.g.https://<namespace>.dev.runtime.adobe.io/index.html - Extension Name, Description, Support Email
Save, then toggle it on under Installed Extensions — it defaults to Disabled. No cert / Chrome-flag hassle (it's a real HTTPS CDN URL) and no approval. Then place it via a layout template (below).
Three tiers, least → most permanent: extensionOverride (local build) → Extension Manager / BYO (deployed app, one org, no approval) → publish (org-wide, needs approval; see appbuilder-workfront).
Open the deployed app — the direct link
Once the app is deployed and registered in that instance (BYO-enabled above, or published), the Main Menu button opens a real, shareable Experience Cloud URL. After aio app deploy, hand the user this link so they can open the app directly:
https://experience{-stage}.adobe.com/#/@<org>/so:<instance>/workfront/custom-applications/<extensionId>/<menuRoute>e.g. https://experience-stage.adobe.com/#/@workfrontaidevarm/so:ai-dev-arm-Dev/workfront/custom-applications/combined-timeline-view/combined-timeline
| Segment | Source |
|---|---|
experience-stage / experience | stage vs prod — the env you deployed to (AIO_CLI_ENV=stage → experience-stage) |
@<org> | org handle (e.g. @workfrontaidevarm) — copy from a Workfront page the user already has open; don't derive it from the org name |
so:<instance> | selects the Workfront instance (e.g. so:ai-dev-arm-Dev) — copy verbatim from that same URL (the segment right after @<org>) |
<extensionId> | the registration id — the non-empty extensionId in Constants.js (the id passed to register()) |
<menuRoute> | the Main Menu item's route — the #/ fragment of its getItems() url (…#/combined-timeline → combined-timeline); matches the <Route path> in App.js |
aio app deploy prints the CDN URL but not @<org> or so:<instance> — those are tenant/env facts. Reliable recipe: you already know <extensionId> and <menuRoute> from the code you built; take the whole prefix up to and including /workfront/ from a live Workfront page (or the Extension Manager link above) and append custom-applications/<extensionId>/<menuRoute>.
Two traps: the bare CDN …/index.html#/<menuRoute> renders with no Workfront host → no sharedContext; and the second path segment must be the real menu route — reusing the app id there (…/<extensionId>/<extensionId>) loads the background registration frame, not the view.
2. Accept the dev certificate
If you haven't already, open https://localhost:<port> directly → Advanced → Proceed to localhost (unsafe). Workfront can't load your app until the self-signed cert is trusted.
3. Chrome 142+ Local Network Access
Chrome 142+ blocks a public origin from reaching localhost and will silently break the override. Disable the check:
chrome://flags/#local-network-access-check → Disabled → Relaunch.
4. Make the app visible
Extension points only render where a layout template places them. Toggling a BYO extension to Enabled is not enough by itself — until it's placed in a layout template's Main Menu (or an object's left panel), it's registered but invisible to every user, including you.
Concrete click path for Main Menu placement (Workfront web UI):
- Setup (Main Menu → Setup, bottom of the menu) → Interface (expand it in the left sidebar) → Layout Templates.
- Pick the template actually assigned to your user — don't blindly edit a shared/
Default template, since that affects every user assigned to it; a personally-named template (or checking the layout template's Assignments panel) is the safer target for testing. - Open it → click Set Main Menu (top-right, under "Main Menu").
- Find your app's tile in the grid — greyed out with a
+icon means it's not yet placed; click it to toggle it active (it turns blue with a-icon, next to the other already-placed custom apps). - Done (closes the Main Menu dialog) → Save and close (top of the layout template editor) — the dialog's Done alone does not persist the change.
- Reload the Workfront tab and open Main Menu — the item now appears alongside the native items.
Show full SKILL.md (377 more words)Show less
Do this yourself via Playwright/browser MCP — don't ask the human to click through it
Everything above (Extension Manager registration, the Enabled toggle, the entire Layout Template → Set Main Menu flow) is ordinary UI navigation once a session is authenticated — an agent with browser automation (Playwright MCP) should drive it directly instead of asking the user to do the clicking. The only steps that genuinely require the human are the ones no tool can do on someone's behalf: completing Adobe SSO/MFA (entering a password or approving an MFA prompt), and giving informed consent to a legal agreement (e.g. accepting Developer Terms of Use — read the actual terms before clicking "Accept" on someone's behalf, or better, have the human click it after you've navigated them to the exact screen). A fresh Playwright browser session starts logged out — get the human to sign in once in that session, then keep driving every subsequent screen (Extension Manager, Setup, Layout Templates, dialogs, toggles) yourself. Don't default to "please open X and click Y" for steps that are just navigation; that's the point of having browser automation available.
Not showing up? Checklist
- Is
aio app devstill running, and is the exacthttps://localhost:<port>inextensionOverride? - Cert accepted? Chrome LNA flag disabled (Chrome 142+)?
- Are you on the right Workfront domain's Local Storage?
- Registered via Extension Manager (BYO) instead? It defaults to Disabled — toggle it on under Installed Extensions.
- Does a layout template that includes your app actually apply to you?
- Do the
id/urlinExtensionRegistrationmatch a real route inApp.js? (seeworkfront-ui-extension) - Is
extensionIdnon-empty, and isid: extensionIdkept undermethodsinregister()? An emptyextensionId, or droppingidfrommethods, makes the item register but silently not render (seeworkfront-ui-extension). This is the usual cause — before blaming the environment, check this. - Registers but still missing from the live menu (it shows in the layout-template picker, and the console shows the host calling
getItems)? Suspect the Workfront environment, not your code — a shell error like…/jumpseat/api/…/configuration 503or "Detected multiple done events" breaks nav rendering. Reload later or try a healthy instance. extensionOverrideis only for unpublished apps. For the item to appear in the live menu without an override, the app must be published (submit + approve from Production — seeappbuilder-workfront).
© adobe, Apache-2.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file
Files
SKILL.md and 1 other file in plugins/app-builder/skills/appbuilder-workfront/workfront-local-testing of adobe/skills.
- SKILL.md
- evals/evals.json
Open the folder on GitHubat commit cbc9952
Compare with similar skills
Workfront Local Testing next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.
| Skill | Stars | Used in | Tokens | Auto-check | Licence | Repo updated |
|---|---|---|---|---|---|---|
| Workfront Local Testing this skilladobe/skills | 195 | — | ~2.4k | Automated safety check: Pass | Apache-2.0 | |
| Nx Generatenomcopter/react-mosaic | 4.8k | 6 repos | ~1.9k | Automated safety check: Pass | Custom licence | |
| PonytailDavidObando/gsharp | 564 | 8 repos | ~1.7k | Automated safety check: Pass | MIT | |
| Run Nx Generatornrwl/nx | 29k | 2 repos | ~592 | Automated safety check: Notes | MIT | |
| Conductor Setupgemini-cli-extensions/conductor | 3.8k | — | ~4.2k | Automated safety check: Pass | Apache-2.0 | |
| Mirage VFS Adapter Authoringstrukto-ai/mirage | 3.7k | — | ~2.4k | Automated safety check: Pass | Apache-2.0 |
Similar skills
Ponytail
DavidObando/gsharp
Forces the laziest solution that actually works, simplest, shortest, most minimal.
Run Nx Generator
nrwl/nx
Run Nx generators with prioritization for workspace-plugin generators.
Conductor Setup
gemini-cli-extensions/conductor
Scaffolds the project and sets up the Conductor environment.
Mirage VFS Adapter Authoring
strukto-ai/mirage
Builds or extends a custom Mirage virtual filesystem adapter for an API, database, object store or app data, with a working mount configuration and filesystem tests.
Siteboon Backend Module Standards
siteboon/claudecodeui
Enforces this repository's TypeScript backend module architecture under server/: feature folders, barrel exports, and where shared types and utilities belong.
More from adobe/skills
All 105 skills in this repoAdobe App Builder Action Scaffolder
adobe/skills
Scaffolds, implements, deploys and debugs Adobe Runtime actions in App Builder projects, with templates for webhooks, events, database CRUD, sequences and Asset Compute workers.
CDP Extension Pilot
adobe/skills
Launches Chrome with an unpacked extension over CDP, opens its sidepanel, popup or options page, and hands over to cdp-connect for clicks, typing and screenshots.
Web Page Resource Collector
adobe/skills
Extracts icons, metadata, text, forms, videos and social links from any web page with playwright-cli, with SVG icon classification and cleanup.
Page Langs
adobe/skills
Detect all languages used on a webpage — both declared (html@lang, hreflang alternate links, nested lang= attributes, meta content-language) and actually present in the body text (Google CLD3 via…
Page Prep
adobe/skills
Prepare any webpage for clean interaction by detecting and removing disruptive overlays (cookie banners, GDPR consent, modals, popups, newsletter signups, paywalls, login walls).
Page Reduce
adobe/skills
Reduce a webpage to a structural skeleton with semantic tokens.
Related
Categories
Questions about Workfront Local Testing
What does Workfront Local Testing do?
A skill your agent uses when making Workfront load your locally running App Builder extension, or when a local extension that worked before has stopped appearing. Workfront Local Testing is an agent skill from adobe/skills. Use when making Workfront load your locally running App Builder extension, or when a local extension that worked before has stopped appearing.
When should I use Workfront Local Testing?
Workfront Local Testing fits situations like: making Workfront load your locally running App Builder extension; A local extension that worked before has stopped appearing.
How do I install Workfront Local Testing in Claude Code?
Run `npx skills add adobe/skills --skill workfront-local-testing -a claude-code`. Or copy the skill folder (plugins/app-builder/skills/appbuilder-workfront/workfront-local-testing in adobe/skills) into .claude/skills/workfront-local-testing in your project. Claude Code loads it when a task matches its description.
How do I install Workfront Local Testing in Codex?
Run `npx skills add adobe/skills --skill workfront-local-testing -a codex`. Or copy the skill folder (plugins/app-builder/skills/appbuilder-workfront/workfront-local-testing in adobe/skills) into .agents/skills/workfront-local-testing in your project. Codex loads it when a task matches its description.
Can I use Workfront Local Testing in Cursor, Gemini CLI or GitHub Copilot?
Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add adobe/skills --skill workfront-local-testing -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/workfront-local-testing, .gemini/skills/workfront-local-testing, .github/skills/workfront-local-testing and .opencode/skills/workfront-local-testing in your project.
What does Workfront Local Testing need to run?
SKILL.md names no scripts, command-line tools or credentials: Workfront Local Testing is instructions for the agent only.
Does Workfront Local Testing access the network?
SKILL.md names 2 domains. In commands or code: experience-stage.adobe.com and experience.adobe.com; the agent is likely to contact these when it follows the instructions. This is read from the text; nothing was executed.
Is Workfront Local Testing safe to install?
Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.
What licence does Workfront Local Testing use?
Workfront Local Testing is published under the Apache-2.0 licence (declared in SKILL.md). It allows redistribution, so the full SKILL.md is shown on this page.
How many tokens does Workfront Local Testing use?
About 2.4k tokens (SKILL.md is roughly 9.8k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.
What are the alternatives to Workfront Local Testing?
Skills that share tags, products or a category with Workfront Local Testing: Nx Generate (nomcopter/react-mosaic, 4.8k stars), Ponytail (DavidObando/gsharp, 564 stars), Run Nx Generator (nrwl/nx, 29k stars) and Conductor Setup (gemini-cli-extensions/conductor, 3.8k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.
Who maintains Workfront Local Testing?
adobe (a GitHub organization) maintains it in adobe/skills, which has 195 GitHub stars. The repository holds 105 skills in this directory. The repository was last updated on October 6, 2026.
Source: adobe/skills on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.