agentsclimarketplace

Wjs looping feedback

Skill jianshuo/claude-skills/wjs-looping-feedback

13 Claude Code skills for video production (transcribe / translate / dub / multicam / subtitles / reframe) + WeChat publishing. Compatible with Claude Code, OpenAI Codex CLI, Cursor, Gemini.

Install
npx -y skills add jianshuo/claude-skills --skill wjs-looping-feedback

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

What its author says it does

Copied from the file, not written here

Use when the user wants to add an in-site feedback loop to a website repo — a floating "提个建议" button where allowlisted visitors submit suggestions that become a GitHub Issue, which GitHub Actions turns into an automatic code change via Claude Code, auto-merges and deploys, and records on a /_feedback dashboard with one-click revert. Triggers — "给网站加个反馈对话框", "提一句话就自动改网站", "装上反馈闭环", "feedback loop", "/wjs-looping-feedback".

SKILL.md

3.1 KB, as published. Nobody here has run it

wjs-looping-feedback

Installs a self-driving feedback loop into any website repo. Runs entirely on the repo owner's own GitHub Actions, authenticated with their Pro/Max OAuth token or their own ANTHROPIC_API_KEY — no extra service or backend.

What it installs

  1. A floating feedback button (prefills a GitHub Issue — no backend, no keys client-side).
  2. .github/workflows/feedback.yml — allowlist gate → Claude Code Action → auto-commit → push to main (auto-deploy) → ledger + dashboard update → close issue.
  3. /_feedback dashboard — every suggestion, what Claude did, commit, status, one-click revert.
  4. .feedback/ runtime: feedback-lib.mjs, feedback-finalize.mjs, INSTRUCTIONS.md, feedback-ledger.json, config.json.

How it works

visitor clicks button → fills suggestion → prefilled GitHub Issue (label feedback) → Actions checks the author is in FEEDBACK_ALLOWLIST (else closes the issue) → Claude Code edits the site per .feedback/INSTRUCTIONS.md → workflow commits to main, updates the ledger + dashboard → the deploy ships it → the issue gets a comment with the commit and a link to /_feedback. Revert is the same loop driven by a revert: #N issue.

Deploy triggering — read before you install (common gotcha)

The workflow pushes to main with the built-in GITHUB_TOKEN. Two cases:

  • External push-deploy host (Cloudflare Pages git-connect, Vercel, Netlify): their webhook fires on every push, so the bot's commit deploys automatically. Nothing to do.
  • Deploy is itself a GitHub Actions workflow in the SAME repo (e.g. GitHub Pages via Actions): GitHub deliberately does NOT let a GITHUB_TOKEN push trigger another workflow (recursion prevention), so the deploy workflow's on: push will NOT fire — the change lands on main but never goes live. Bridge it by adding a workflow_run trigger to the deploy workflow (see references/install.md step 4.5).

To install

Read references/install.md and follow it in the target repo. It detects the site type (Hugo / Next.js / Astro / static), copies assets, injects the widget, and asks the user for exactly two things: the allowlist of GitHub usernames and the auth (Pro/Max OAuth token via claude setup-token, or an ANTHROPIC_API_KEY).

Scope (route 1)

Runs in the user's own repo with their own auth. Submitters need a GitHub account; only allowlisted authors trigger work. Not a hosted service — no anonymous submit, no billing, no multi-tenant. (A future GitHub-App packaging would reuse every asset here.)

Keep looking

Skills are one crate of 328,083. 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.