How do I install the Wjs Looping Feedback skill?

Run npx skillmds@latest add jianshuo/wjs-looping-feedback in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Wjs Looping Feedback safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Wjs Looping Feedback?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Wjs Looping Feedback free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Wjs Looping Feedback?

jianshuo (@jianshuo) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Wjs Looping Feedback by jianshuo — Agent Skill

Name: Wjs Looping Feedback
Author: jianshuo

Wjs Looping Feedback

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".

jianshuo 7e940cd 16 files · 31.7 KB Updated Sep 17, 2026

File contents

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

A floating feedback button (prefills a GitHub Issue — no backend, no keys client-side).
.github/workflows/feedback.yml — allowlist gate → Claude Code Action → auto-commit → push to main (auto-deploy) → ledger + dashboard update → close issue.
/_feedback dashboard — every suggestion, what Claude did, commit, status, one-click revert.
.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.)

---name: wjs-looping-feedbackdescription: 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".---# wjs-looping-feedbackInstalls a self-driving feedback loop into any website repo. Runs entirely on the repoowner's own GitHub Actions, authenticated with their Pro/Max OAuth token or their own`ANTHROPIC_API_KEY` — no extra service or backend.## What it installs1. 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 worksvisitor 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 installRead `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 forexactly two things: the **allowlist** of GitHub usernames and the **auth** (Pro/Max OAuthtoken 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; onlyallowlisted 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.)

Frequently asked questions