agentsclimarketplace

Redeploy frontend

Skill timi-ty/agent-forge/skills/redeploy-frontend

Trigger a Vercel redeploy of the frontend by pushing a harmless comment change. Use when the user says "redeploy", "redeploy frontend", "trigger vercel deploy", or "trigger redeploy".From its SKILL.md

Install
npx -y skills add timi-ty/agent-forge --skill redeploy-frontend

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

7.3 KB, ~1.9k tokens by cl100k_base, as published. Nobody here has run it

Redeploy Frontend

Push a trivial timestamp comment change to the current deploy branch to trigger a Vercel redeploy. Uses a git worktree so the user's working directory is never touched -- works even with uncommitted local changes. Auto-detects the package manager, deploy branch, and target file. Auto-fixes prettier formatting issues before pushing.

Workflow

Step 0: Discover project config

Resolve the repo root and detect project settings before proceeding.

Repo root:

git rev-parse --show-toplevel

All subsequent commands run from this directory. Set $REPO_ROOT to this path.

Repo name -- derive $REPO_NAME from the directory name or git remote.

Package manager -- check for lock files at repo root:

  • pnpm-lock.yamlpnpm
  • yarn.lockyarn
  • bun.lockbbun
  • package-lock.jsonnpm

If multiple lock files exist, prefer in the order listed above.

Deploy branch -- use the currently checked-out branch:

git branch --show-current

The user is responsible for being on the correct deploy branch before invoking this skill.

Timestamp file -- find the file to inject the redeploy comment into, in priority order:

  1. Use your file-search tools (Grep) to find any .ts or .tsx file under src/ or app/ that contains the line // redeploy:. If found, that file is $TIMESTAMP_FILE.
  2. Try common entry points in order: src/app/layout.tsx, app/layout.tsx, src/main.tsx, src/App.tsx, src/index.ts, src/index.tsx
  3. If none of the above exist, ask the user: "Which file should I use to inject the redeploy timestamp comment?"

Set $BRANCH, $PKG_MANAGER, and $TIMESTAMP_FILE for use in all steps below. $TIMESTAMP_FILE is a path relative to the repo root.


Step 1: Create a worktree for the deploy branch

Fetch the latest remote state and create a clean worktree at origin/$BRANCH:

git fetch origin
git worktree add ../$REPO_NAME-wt-redeploy origin/$BRANCH

Set $DEPLOY_DIR to the absolute path of the created worktree.

If the worktree path already exists (from a previous interrupted redeploy), remove it first:

git worktree remove ../$REPO_NAME-wt-redeploy --force

Handle unpushed local commits

Check if the user has local commits on $BRANCH that are not yet on the remote:

git rev-list --count origin/$BRANCH..HEAD

If ahead > 0 and the user is on $BRANCH, ask: "You have {N} unpushed commit(s) on {branch} not yet on the remote. Include them in the redeploy?"

If yes, capture the local tip and merge it into the worktree's detached HEAD:

LOCAL_TIP=$(git rev-parse $BRANCH)
git -C $DEPLOY_DIR merge $LOCAL_TIP --no-edit

Do NOT use git -C $DEPLOY_DIR checkout $BRANCH -- git forbids the same branch in two worktrees simultaneously, and the user's main worktree already has $BRANCH checked out. The worktree is on a detached HEAD (from origin/$BRANCH), so a merge incorporates the local commits without violating the one-branch-per-tree rule.

If no, continue with the worktree at origin/$BRANCH.

Sync build-essential non-tracked files

Copy non-version-controlled files needed for builds from the main repo to the worktree. These files are gitignored and therefore absent from a fresh worktree.

for f in .env .env.local .env.production .env.development .env.production.local .env.development.local .env.test .env.test.local; do
  [ -f "$REPO_ROOT/$f" ] && cp "$REPO_ROOT/$f" "$DEPLOY_DIR/$f"
done

For monorepos, also check subdirectories -- find all .env* files (excluding node_modules and .git) in $REPO_ROOT and copy them to the same relative paths in $DEPLOY_DIR:

find "$REPO_ROOT" -mindepth 2 -name '.env*' -not -path '*/node_modules/*' -not -path '*/.git/*' | while read src; do
  rel="${src#$REPO_ROOT/}"
  mkdir -p "$DEPLOY_DIR/$(dirname "$rel")"
  cp "$src" "$DEPLOY_DIR/$rel"
done

If the project has a .env.example or .env.template in the repo root but no .env, warn the user: "No .env file found. The build may fail if environment variables are required."

Do not log or display the contents of these files -- they may contain secrets.

Step 2: Install dependencies

Install dependencies in the worktree so the build step works:

cd $DEPLOY_DIR
$PKG_MANAGER install

Optimization: For large projects where install is slow, you may symlink node_modules from the main worktree instead: ln -s $REPO_ROOT/node_modules $DEPLOY_DIR/node_modules (Unix) or mklink /J $DEPLOY_DIR\node_modules $REPO_ROOT\node_modules (Windows). This avoids a full install. Only do this if both worktrees are on the same branch and dependency versions match.

Step 3: Local pre-build check and auto-fix

All commands in this step run in $DEPLOY_DIR.

Run the build locally to catch failures before pushing:

cd $DEPLOY_DIR
$PKG_MANAGER run build

If the build passes, continue to Step 4.

If the build fails, inspect the output:

  • Prettier-only failure -- the output contains [warn] lines listing files and ends with Code style issues found. The build phase never ran. Auto-fix:

    cd $DEPLOY_DIR
    $PKG_MANAGER run format
    

    Then re-run $PKG_MANAGER run build to confirm the fix.

    • If the re-run passes, continue to Step 4. The formatted files will be staged alongside the timestamp change in Step 5.
    • If the re-run fails with a different error, treat as non-trivial (see below).
  • Non-trivial failure (ESLint errors, TypeScript type errors, build errors) -- abort, clean up the worktree (Step 7), and report the full build output to the user. Ask follow-up questions about how to resolve before pushing.

Step 4: Update the redeploy timestamp

Open $DEPLOY_DIR/$TIMESTAMP_FILE. Look for an existing line matching the pattern // redeploy:.

  • If the line exists, replace it with a new UTC timestamp: // redeploy: <timestamp>
  • If no such line exists, insert // redeploy: <timestamp> as the very first line of the file.

Generate the timestamp:

date -u +%Y-%m-%dT%H:%M:%SZ                                    # macOS/Linux/Git Bash
(Get-Date).ToUniversalTime().ToString("yyyy-MM-ddTHH:mm:ssZ")   # Windows PowerShell

Example result:

// redeploy: 2026-03-05T14:23:00Z
// ... rest of file

Step 5: Commit and push

All commands in this step run in $DEPLOY_DIR.

If prettier auto-fixed files in Step 3, stage everything and use the format-aware message:

cd $DEPLOY_DIR
git add .
git commit -m "chore: format and trigger redeploy"
git push origin $BRANCH

If no prettier fixes were needed (only the timestamp changed), stage just the timestamp file:

cd $DEPLOY_DIR
git add $TIMESTAMP_FILE
git commit -m "chore: trigger redeploy"
git push origin $BRANCH

Step 6: Confirm

Report the push result to the user. Include the commit hash from the output.

Step 7: Cleanup worktree

Remove the worktree:

git worktree remove ../$REPO_NAME-wt-redeploy

If removal fails, force it:

git worktree remove --force ../$REPO_NAME-wt-redeploy

This step runs after Step 6 on success, or after a build failure abort in Step 3.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most design frontend skills give in ~1.9k tokens

Counted across 1,169 of the 1,878 authors here whose files we hold, read 2026-08-07

  • Use CSS variables for color consistencyin 72 of 1169, across 23 files
  • Commit to one bold aesthetic direction before codingin 72 of 1169, across 27 files
  • Match implementation complexity to the aesthetic visionin 70 of 1169, across 20 files
  • Add atmospheric background effects and texturesin 57 of 1169, across 9 files
  • Use unexpected spatial compositions and layoutsin 56 of 1169, across 8 files
  • Implement real working codein 55 of 1169, across 7 files
  • Vary themes and aesthetics across different designsin 48 of 1169, across 7 files
  • Launch chromium in headless modein 47 of 1169, across 4 files
  • Close the browser when donein 47 of 1169, across 4 files
  • Run provided scripts with help flag firstin 47 of 1169, across 4 files
  • Wait for network idle statein 47 of 1169, across 4 files
  • Use descriptive selectors for elementsin 47 of 1169, across 4 files

Said here and by no other author read

  • resolve repo root before proceeding
  • detect package manager from lock files
  • create a clean worktree
  • copy environment files to the worktree
  • run the build locally before pushing
  • run the format script if prettier fails

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 326,499. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.