メニュー
Burn down the shaketoship feedback backlog - GitHub issues auto-filed from shake-to-record device feedback (title `[feedback][<app>][<screen>]`). Fixes ONE issue per invocation (select -> claim -> debug -> fix in a worktree -> test -> PR "Fixes
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | fix-feedback |
| description | Burn down the shaketoship feedback backlog - GitHub issues auto-filed from shake-to-record device feedback (title `[feedback][<app>][<screen>]`). Fixes ONE issue per invocation (select -> claim -> debug -> fix in a worktree -> test -> PR "Fixes |
You process the feedback backlog one issue per invocation so /loop /fix-feedback
advances the queue one wake at a time. Do exactly one issue, then stop and report
(the loop re-invokes you for the next). Never batch multiple issues in one turn.
GitHub issues in noktadev/apps labelled feedback, auto-filed by the shaketoship
platform: a user shook-to-record on a device, Gemini analysed the video, and wrote a
structured issue. Body carries Severity:, Quote: (the user's words), Screen:, and a
footer anchor <!-- shaketoship project=... -->. Most are [feedback][lockin-chinese][...]
iOS bugs in apps/lockin-chinese/ios (LockInKit) or packages/swift/AppFeedback.
noktadev/apps. App focus: lockin-chinese (skip other apps' feedback
unless told).wip:fixing (claimed), pr-open (fix PR up),
needs-human (not loop-fixable).gh issue list --repo noktadev/apps --label feedback --state open --json number,title,labels,body. Filter to actionable [feedback][lockin-chinese][...] bugs
that do NOT already carry wip:fixing, pr-open, or needs-human. Prioritise by the
body's Severity (crash/bug before minor). Re-derive fresh from gh every time - never
trust memory of the queue across invocations. If none remain: STOP - tell the user the
feedback backlog is clear, and if in a loop, end the loop.needs-human, and STOP (don't consume a fix cycle on it).gh issue edit <n> --repo noktadev/apps --add-label wip:fixing. Read the full
body: Severity, Quote, Screen.superpowers:systematic-debugging. Locate the responsible Swift code
from the Screen + Quote. For a crash, get the real stack from Sentry (lockin iOS
project 4511703095312464, Nokta org, EU) if the Sentry MCP is authed; if not, say so and
reason from the code + the quote (and note in the PR that a Sentry stack would confirm it).superpowers:using-git-worktrees): branch
fix/feedback-<n> off origin/main. Where the bug has a unit-testable seam, write the
failing test FIRST (superpowers:test-driven-development) then fix. Pure-visual bugs
often have no test seam - fix and say so explicitly in the PR rather than faking a test.swift test on the touched package (the
swift-test pre-commit hook also runs on commit); bun run typecheck if any TS changed.
Capture the actual pass/fail. iOS visual/behaviour changes the loop cannot fully verify -
that's expected; the PR carries the device-check ask.Fixes #<n>, a
short what-changed, how-verified (with the real test output), and a
Device verification needed: line naming exactly what a human should check on-device
(tie it to the issue's Quote/Screen). Do NOT auto-merge unless the user opted into it.wip:fixing ->
pr-open. UAT capture (repo convention - docs/playbooks/issue-labels.md): if the fix
has a Device verification needed: line, ALSO add that check (a concrete - [ ] item +
PR pointer) to the open uat-labeled issue for the app's next build - extend the
existing one, or create it (--label uat --label device-verify) when none is open. That
issue is what the human aggregates at build time; a device-check ask buried only in a PR
body gets lost. Tear down the worktree (remove it + delete the local branch; the PR holds
the work). STOP - report the issue #, the PR #, and what you did in 2-3 lines.needs-human, remove wip:fixing, STOP. Never touch the same issue on a later
invocation - the labels are what stop you re-picking it.gh first - concurrent loops
or a prior wake may have claimed things.apps checkout - all fix work happens in the fix/feedback-<n> worktree.needs-human, not a guess.Generate high-converting App Store screenshots by analyzing your app's codebase, discovering core benefits, and creating ASO-optimized screenshot images using Nano Banana Pro.
Orchestrate a fleet of herdr agent panes to ship a multi-chunk backlog in parallel - one labeled pane per chunk (own git worktree), engine-routed (mechanical→codex/gpt-5.5+grok-4.5 twin lanes, judgment→fable-5, review→fable-5/opus-4.8), each chunk plan→TDD→cross-model-consensus-gate→merge, follow-up concerns filed as issues, tracked on a GitHub Project kanban, advanced by event-driven idle-waiters + a fleet-wide liveness monitor that catches stuck/errored/dead panes, dogfooded tracer-bullet after each merge. Use when the user wants to run many build tasks in parallel across herdr panes, act as orchestrator over claude/codex/pi agents, "ship the backlog", "orchestrate the fleet", keep an autonomous overnight build loop going, or fan out a wave-graph of chunks. Builds on herdr-agent-orchestration (low-level pane driving).
Close down a work session or agent pane cleanly - land or file everything of value (follow-up tickets for loose ends, concerns, debt), add human-verification items to a `uat`-labeled checklist issue (builds to verify, flows to smoke), then do safe-only housekeeping (pushed worktrees, own background processes, created sims) and report what was closed, filed, and kept. Use when a session's work is done and the user says "wrap up", "close this down", "can we close this", "clean up and land it", when a fleet run or chunk finishes, or before ending a long session that minted resources.
Drive and orchestrate the AI agents running inside herdr - read their state, send input, start new ones, and migrate in-flight work to another machine through a handoff. Use when the user wants to control a herdr agent or pane, broadcast to running agents, run agents on a remote box, move or hand off work between agents, or mentions herdr orchestration.
A catalog of best-in-class consumer mobile onboarding flows plus the reusable patterns behind them, for designing or auditing onboarding, activation, and paywall placement. Use when you design an onboarding flow, run an onboarding teardown, want to improve activation or first-run conversion, decide where the paywall goes in onboarding, need concrete onboarding examples for a category (health, language learning, fitness, subscription consumer), or want to reduce onboarding drop-off. Complements ux-psychology - that skill owns the cognitive-bias rules, this one owns the concrete app-example catalog + benchmark numbers + resource directory. See CATALOG.md for the per-app entries, cited benchmarks, and the source directory to keep mining.
Offload a running local herdr session to the workbox - relocate an idle agent's in-flight work to the remote box through a handoff so it continues on fast hardware. Use when the user wants to migrate, move, or offload local herdr agents/sessions to the workbox or remote box, dogfood the migration, or get work off the slow-network laptop.