⚠️ Potential issue | 🟡 Minor

Use hyphenated compound adjective at Line 166.

Change “Single page audit” to “Single-page audit” for grammar consistency.

Verify each finding against the current code and only fix it if needed.

In `@skills/click-path-audit/SKILL.md` at line 166, Replace the phrase "Single
page audit" with the hyphenated compound adjective "Single-page audit" in the
SKILL.md content (look for the exact string "Single page audit" in the line that
reads "- **Single page audit:** Use after building a new page or after a user
reports a broken button."); update that markdown line to "- **Single-page
audit:** Use after building a new page or after a user reports a broken button."
to restore correct grammar.

Broken skill references — namespace superpowers: does not exist

The integration section references three skills using a /superpowers: namespace prefix that does not exist in this repository:

• /superpowers:systematic-debugging
• /superpowers:verification-before-completion
• /superpowers:test-driven-development

Running git ls-files skills/ reveals no superpowers/ directory and no files matching this namespace pattern. As a result, users following this guidance will get errors or silent no-ops when attempting to chain these skills together.

The equivalent skills in this repo appear to be:

• /tdd-workflow (maps to superpowers:test-driven-development)

The other two don't have clear equivalents in the current skills/ tree and should either be removed or replaced with the correct skill invocation paths.

Stale Closure example is technically misleading

The example includes count in useCallback's dependency array ([count]), yet the inline comment says // captures stale count. This is contradictory: when a dependency is correctly listed, React regenerates the callback whenever count changes, so the closure is not stale.

The two consecutive setCount(count + 1) calls do both resolve to the same value, but this is because React batches synchronous state updates within a single event handler — not because of a stale closure. The actual stale-closure pattern occurs when the dependency array is empty or incorrect (e.g., []), causing an outdated count to be captured across renders.

As written, this example teaches the wrong mental model for two different bugs at once, which will reduce its effectiveness as a debugging reference.

App-specific component names make skill non-reusable for the community

The recommended agent-split template hard-codes component names that belong to the author's private production app (DanteChatColumn, JustChatPage, ThreadList, DraftArea, EmailsPage, ProjectsPage, ProjectOverviewTab, NewProjectWizard, CRM). A community skill contributor should replace these with generic placeholders so that adopters can fill in their own app structure.

For example:

Agent 1: Map ALL state stores (Step 1) — this is shared context for all other agents
Agent 2: <Dashboard page(s)>
Agent 3: <Chat / messaging page(s)>
Agent 4: <Email / inbox page(s)>
Agent 5: <Projects / tasks page(s)>
Agent 6: <CRM / contacts page(s)>
Agent 7: <Settings / profile page(s)>
Agent 8: <Any remaining page(s)>

Replace each agent's scope with the actual page names in your app.

Async Race pattern doesn't cover the dominant finding described in the PR

The PR description states that 30 of 48 bugs were "async race conditions where React useState guards could be bypassed by double-clicks in the same render frame" with "ref-based synchronous guards" as the universal fix. However, Pattern 2 illustrates a completely different scenario — two concurrent fetch calls whose .then callbacks land in an unpredictable order. That is a valid race, but it's not the one that was the dominant finding.

Developers reading this skill will have no guidance on how to prevent or fix the double-click guard bypass pattern. Consider adding a dedicated Pattern 2b (or expanding Pattern 2) with the ref-based guard anti-pattern and fix, e.g.:

// Double-click bypass — useState guard is not synchronous
const [isLoading, setIsLoading] = useState(false)
const handler = async () => {
  if (isLoading) return            // ← guard reads STALE state mid-render
  setIsLoading(true)
  await doWork()
  setIsLoading(false)
}
// Fix: use a ref for the synchronous guard
const isLoadingRef = useRef(false)
const handlerFixed = async () => {
  if (isLoadingRef.current) return  // ← synchronous, not batched
  isLoadingRef.current = true
  await doWork()
  isLoadingRef.current = false
}

P2: Use valid local skill command paths here; the /superpowers:... references are not resolvable in this repository, so users following this integration guidance will hit command errors.

Check if this issue is valid — if so, understand the root cause and fix it. At skills/click-path-audit/SKILL.md, line 204:

<comment>Use valid local skill command paths here; the `/superpowers:...` references are not resolvable in this repository, so users following this integration guidance will hit command errors.</comment>

<file context>
@@ -0,0 +1,244 @@
+
+## Integration with Other Skills
+
+- Run AFTER `/superpowers:systematic-debugging` (which finds the other 54 bug types)
+- Run BEFORE `/superpowers:verification-before-completion` (which verifies fixes work)
+- Feeds into `/superpowers:test-driven-development` — every bug found here should get a test
</file context>

P3: This “Stale Closure” example is incorrect with [count] in the dependency array, because the callback is refreshed when count changes. Update the example to intentionally omit count (or use a different scenario) so it actually demonstrates a stale closure bug.

Check if this issue is valid — if so, understand the root cause and fix it. At skills/click-path-audit/SKILL.md, line 116:

<comment>This “Stale Closure” example is incorrect with `[count]` in the dependency array, because the callback is refreshed when `count` changes. Update the example to intentionally omit `count` (or use a different scenario) so it actually demonstrates a stale closure bug.</comment>

<file context>
@@ -0,0 +1,244 @@
+const handler = useCallback(() => {
+  setCount(count + 1)  // captures stale count
+  setCount(count + 1)  // same stale count — increments by 1, not 2
+}, [count])
+```
+
</file context>