skills/dev-setup-temp-resource/SKILL.md
Set up and use the committed `_temp-resource/<issue>-<topic>/` convention for handing scratch resources (prototypes, design references, fixtures, sample data) from one Claude Code session to a LATER session through git — not Dropbox/cclogs. Use when: (1) setting up `_temp-resource/` in a repo, (2) a planning or dev session must delegate files a later session will need — especially `/big-plan` → `/x-wt-teams`, or any handoff to Claude Code web where Dropbox/cclogs is unavailable, (3) deciding where to put prototype output (e.g. from `/prototype-first-wisdom`) that you've decided a downstream session should reuse, (4) reading resources a prior session left under `_temp-resource/`. Keywords: _temp-resource, temp resource, delegate resources, share prototype across sessions, web Claude Code handoff, "use this PR as base".
npx skillsauth add takazudo/claude-resources dev-setup-temp-resourceInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
A repo-committed handoff channel for scratch resources that one session produces and a later session consumes. Git is the channel — so it works where Dropbox/cclogs does not (most importantly Claude Code web, which has no Dropbox).
_temp-resource/ at the repo root, committed (NOT gitignored). Being in git is the
whole point — the resources ride the branch/PR to whatever machine or web session picks the work up._temp-resource/<issue-number>-<topic-slug>/, e.g. _temp-resource/4444-tweak-header/.
The number is the GitHub issue — the epic for /big-plan, the single issue for /x-as-pr.Use it only when delegating to a later session AND the resource is not already in the repo and is too big/binary to express inline in the issue (a prototype, a design mockup + screenshots, test fixtures, sample data).
Do not reflexively store everything. /prototype-first-wisdom output is often discarded or never
acted on — keep that in cclogs. Promote a copy into _temp-resource/ only once you've decided a
downstream session concretely needs it. In-session work needs none of this; just use the file directly.
A stray prototype (.ts/.tsx/.md/.html) under _temp-resource/ must not trip CI's
format / lint / test gates. Most repo tooling is path-scoped (e.g. pnpm --filter ...) and never
sees a root dir — but the broad scanners (markdown formatters, repo-wide linters, root test configs)
will, so they need an explicit exclude. Run the helper:
bash "$HOME/.claude/skills/dev-setup-temp-resource/scripts/ensure-temp-resource.sh"
It creates _temp-resource/ + a README.md, verifies the dir is not gitignored, and auto-patches
the configs whose shape is known and safe to edit:
.prettierignore / .eslintignore / .stylelintignore..mdx-formatter.json → adds _temp-resource/** to its exclude array..design-token-lint.json → adds **/_temp-resource/** to its ignore array.Then it reports the remaining lint / test / typecheck configs for you to finish by hand (their shapes vary too much to patch blindly):
eslint.config.* (flat) → "_temp-resource/**" in an ignores entry; .eslintrc* →
ignorePatterns; biome.json → files.ignore.vitest.config.* / vite.config.* (if it defines test) → "_temp-resource/**" in
test.exclude; jest.config.* → testPathIgnorePatterns; playwright.config.* is usually
testDir-scoped (safe — just confirm testDir isn't the repo root).tsconfig*.json → "_temp-resource" in exclude, but only if its include globs
the repo root (per-package tsconfigs that scope to their own src need nothing).Edit the tool's own config array — never add a CLI
--ignore/--excludeflag to the npm script. For tools that auto-load a config (mdx-formatter's.mdx-formatter.json, etc.), a CLI flag replaces the config's list instead of extending it, silently re-exposing everything else the config was excluding (e.g. generated docs). The helper edits the config array for exactly this reason.
Commit this setup once (its own small PR, or fold it into the first delegating base branch). It is permanent repo plumbing; the per-topic subdirs come and go on feature branches.
mkdir -p _temp-resource/<issue>-<slug>/ and put the files there.$DROPBOX_*/$HOME/cclogs/absolute
path (those don't exist on another machine or on web). A compact inline summary (e.g. ASCII of a
layout) alongside the path makes the issue self-contained even before the file is opened./big-plan → /x-wt-teamsBy default /x-wt-teams creates the base branch and /big-plan creates issues only. When resources
must be delegated, /big-plan prepares the base branch instead, and /x-wt-teams reuses it:
/big-plan (after the epic + sub-issues exist, so the epic number is known):base/<impl-title-slug> from the parent branch._temp-resource/<epic#>-<slug>/; push; open the base PR
(base/<slug> → parent)._temp-resource/<epic#>-<slug>/ path. This is the cross-session message./x-wt-teams: when the epic says "use this PR as base", reuse that existing base branch —
do NOT create a new one. Topic branches fork from it, so every child inherits the resources, and each
sub-issue can point at _temp-resource/<epic#>-<slug>/ in the working tree.For Claude Code web this is the only reliable handoff: the PR + committed dir ARE the shared state.
The resources are already on the branch — read _temp-resource/<issue>-<topic>/ straight from the
working tree. The issue body points there. No download step, no Dropbox.
When the delegated work merges, remove _temp-resource/<issue>-<topic>/ so it doesn't land on the
default branch — fold this into the consuming workflow's cleanup/confirm step (or the docs step that
migrates anything durable into real docs). Leaving it is harmless but untidy.
tools
Acceptance gate for a branch produced by an OpenAI Codex CLI run — usually Codex implementing a /big-plan epic that was handed off to it. Codex reports the work 'done' (or the user flags it WIP with corrections); this skill confirms the branch actually fulfils the original spec, fixes what falls short, and routes larger discoveries into GitHub issues. Use when: (1) User says '/finalize-codex-work', 'finalize codex work', 'confirm the codex work', 'check the codex branch', or 'codex said it's done', (2) A branch is the result of a Codex CLI session and needs verification against its spec issue/PR, (3) After assigning a /big-plan epic to Codex CLI. Pass -m/--merge to run /pr-complete -c at the end.
tools
Read a Figma design node directly from a share URL via the Figma REST API — no Dev Mode subscription, no MCP, no desktop app. Renders the node to PNG and dumps its full style/layout JSON so the design can be described, compared, or implemented. Use whenever the user gives a Figma design URL (figma.com/design/... or /file/...) and wants to see, read, inspect, reference, or implement that node — including `/fig-url-refer <url>`. This is the URL-based counterpart to `/figrefer` (which needs a Dev-plan desktop MCP); prefer this one when the input is a URL rather than a live desktop selection.
tools
Sync the user's Claude Code workflow skills into the OpenAI Codex CLI settings repo ($HOME/.codex) as Codex-native ports, fix the Codex .gitignore for new local state, then commit and push. Use when: (1) user says '/dev-codex-sync-settings-from-claude', 'sync codex settings', 'sync claude skills to codex', 'port skills to codex', or 'update codex from claude'; (2) after updating ~/.claude workflow skills (big-plan, x, x-as-pr, x-wt-teams) and Codex should catch up; (3) the $HOME/.codex repo has drifted behind $HOME/.claude. The ports are condensed Codex-native REWRITES, never file copies.
development
Analyze a video file (mov, mp4, webm, etc.) or a YouTube video by extracting still frames with ffmpeg and reading them chronologically with vision — Claude cannot ingest video files directly. Use whenever the user provides a video file path or YouTube URL and wants to know what happens in it: "read this video", "watch this video", "check this recording", "what happens in this .mov/.mp4", analyzing a screen recording of a UI bug, or verifying UI behavior captured in a video, even if they don't name this skill.