imhcode 1.0.0

package/skills/cisco-ios-patterns/SKILL.md

@@ -0,0 +1,163 @@
+---
+name: cisco-ios-patterns
+description: Cisco IOS and IOS-XE review patterns for show commands, config hierarchy, wildcard masks, ACL placement, interface hygiene, and safe change-window verification.
+origin: community
+---
+
+# Cisco IOS Patterns
+
+Use this skill when reviewing Cisco IOS or IOS-XE snippets, building a
+change-window checklist, or explaining how to collect evidence from a router or
+switch without making the incident worse.
+
+## When to Use
+
+- Reviewing IOS or IOS-XE configuration before a planned change.
+- Choosing read-only `show` commands for troubleshooting.
+- Checking ACL wildcard masks and interface direction.
+- Explaining global, interface, routing process, and line configuration modes.
+- Verifying that a change landed in running config and was saved intentionally.
+
+## Operating Rules
+
+Treat IOS examples as patterns, not paste-ready production changes. Confirm the
+platform, interface names, current config, rollback path, and out-of-band access
+before making changes on a real device.
+
+Prefer this workflow:
+
+1. Capture current state with read-only commands.
+2. Review the exact candidate config.
+3. Confirm management access cannot be locked out.
+4. Apply the smallest change in a maintenance window.
+5. Re-read state, compare to the baseline, then save only after validation.
+
+## Mode Reference
+
+```text
+Router> enable
+Router# show running-config
+Router# configure terminal
+Router(config)# interface GigabitEthernet0/1
+Router(config-if)# description UPLINK-TO-CORE
+Router(config-if)# no shutdown
+Router(config-if)# exit
+Router(config)# end
+Router# show running-config interface GigabitEthernet0/1
+```
+
+`running-config` is active memory. `startup-config` is what survives reload.
+Do not save a change just because a command was accepted; validate behavior
+first, then use `copy running-config startup-config` if the change is approved.
+
+## Read-Only Collection
+
+```text
+show version
+show inventory
+show processes cpu sorted
+show memory statistics
+show logging
+show running-config | section line vty
+show running-config | section interface
+show running-config | section router bgp
+show ip interface brief
+show interfaces
+show interfaces status
+show vlan brief
+show mac address-table
+show spanning-tree
+show ip route
+show ip protocols
+show ip access-lists
+show route-map
+show ip prefix-list
+```
+
+Collect the specific section you need instead of dumping full config into a
+ticket when the config may contain secrets, customer names, or private topology.
+
+## Wildcard Masks
+
+IOS ACL and many routing statements use wildcard masks, not subnet masks.
+
+```text
+Subnet mask       Wildcard mask
+255.255.255.255   0.0.0.0
+255.255.255.252   0.0.0.3
+255.255.255.0     0.0.0.255
+255.255.0.0       0.0.255.255
+```
+
+Review wildcard masks before deployment. A subnet mask accidentally used as a
+wildcard can match far more traffic than intended.
+
+```text
+ip access-list extended WEB-IN
+  10 permit tcp 192.0.2.0 0.0.0.255 any eq 443
+  999 deny ip any any log
+```
+
+Every ACL has an implicit deny at the end. Add an explicit logged deny when the
+operational goal includes observing misses, and confirm logging volume is safe.
+
+## ACL Placement Review
+
+Before applying an ACL to an interface, answer these questions:
+
+- Which traffic direction is being filtered, `in` or `out`?
+- Is management traffic sourced from a known jump host or management subnet?
+- Is there an explicit permit for required routing, DNS, NTP, monitoring, or
+  application traffic?
+- Are hit counters available from a safe test source?
+- Is there a rollback command and an active console or out-of-band path?
+
+Do not test reachability by removing firewall or ACL protections. Read counters,
+logs, and route state first.
+
+## Interface Hygiene
+
+```text
+interface GigabitEthernet0/1
+ description UPLINK-TO-CORE
+ switchport mode trunk
+ switchport trunk allowed vlan 10,20,30
+ switchport trunk native vlan 999
+ no shutdown
+```
+
+Use clear descriptions, explicit switchport mode, and documented native VLANs.
+On routed interfaces, confirm the mask, peer addressing, and routing process
+before assuming link state means forwarding is correct.
+
+## Change-Window Verification
+
+Use before/after checks that match the actual change.
+
+```text
+show running-config | section interface GigabitEthernet0/1
+show interfaces GigabitEthernet0/1
+show logging | include GigabitEthernet0/1|changed state|line protocol
+show ip route <prefix>
+show ip access-lists <name>
+```
+
+For routing changes, also capture neighbor state and route tables before and
+after the change. For ACL changes, compare hit counters from a planned test
+source rather than relying on a generic ping.
+
+## Anti-Patterns
+
+- Applying a generated config without a device-specific diff.
+- Saving configuration before post-change checks pass.
+- Using a subnet mask where IOS expects a wildcard mask.
+- Applying an ACL to the wrong interface direction.
+- Troubleshooting by disabling ACLs, route policies, or authentication.
+- Pasting full configs into public tools without sanitizing secrets and topology.
+
+## See Also
+
+- Agent: `network-config-reviewer`
+- Agent: `network-troubleshooter`
+- Skill: `network-config-validation`
+- Skill: `network-interface-health`

package/skills/ckm:design-system/SKILL.md

@@ -0,0 +1,3 @@
+# Skill: ckm:design-system
+
+Automated stub for ckm:design-system.

package/skills/ckm:slides/SKILL.md

@@ -0,0 +1,3 @@
+# Skill: ckm:slides
+
+Automated stub for ckm:slides.

package/skills/claude-red/SKILL.md

@@ -0,0 +1,35 @@
+---
+name: claude-red
+description: "Offensive security and penetration testing skill. Covers automated vulnerability scanning, secure-coding bypass detection, sanitization reviews, and exploit drafting."
+---
+
+# /claude-red — Offensive Security & Penetration Testing
+
+**Claude-Red** equips agents with offensive cybersecurity capabilities to perform penetration testing, threat modeling, and red teaming audits on SaaS architectures.
+
+---
+
+## 🛠️ Security Audit Protocols
+
+### 1. OWASP Top 10 Auditing
+- **Injection Protection**: Audit database interaction patterns for raw SQL concats. Enforce strict parameterization.
+- **Broken Authentication**: Verify token expiries, session revocation logic, and CSRF token propagation.
+- **Sensitive Data Exposure**: Check transit encryption (`HTTPS`), password hashing (`bcrypt`/`argon2`), and PII encryption.
+
+### 2. Penetration Testing Checklist
+- Run automated vulnerability mapping on codebase boundaries.
+- Attempt secure-coding logic bypasses to detect authorization flaws (e.g., IDOR in controllers).
+- Verify sanitization libraries (e.g., DOMPurify for HTML, htmlspecialchars for blade).
+
+### 3. Exploitation Threat Modeling
+- Write attack trees demonstrating how a compromised microservice can escalate privileges.
+- Document exact CVSS scores for discovered vulnerabilities.
+- Provide step-by-step remediation plans.
+
+---
+
+## 🚫 Safe Play Guidelines
+
+- **Never**: Develop weaponized exploits for remote targets.
+- **Never**: Store unencrypted API keys or production database credentials in codebase logs.
+- **Always**: Perform vulnerability checks against mock controllers or isolated staging stubs.

package/skills/click-path-audit/SKILL.md

@@ -0,0 +1,244 @@
+---
+name: click-path-audit
+description: "Trace every user-facing button/touchpoint through its full state change sequence to find bugs where functions individually work but cancel each other out, produce wrong final state, or leave the UI in an inconsistent state. Use when: systematic debugging found no bugs but users report broken buttons, or after any major refactor touching shared state stores."
+origin: community
+---
+
+# /click-path-audit — Behavioural Flow Audit
+
+Find bugs that static code reading misses: state interaction side effects, race conditions between sequential calls, and handlers that silently undo each other.
+
+## The Problem This Solves
+
+Traditional debugging checks:
+- Does the function exist? (missing wiring)
+- Does it crash? (runtime errors)
+- Does it return the right type? (data flow)
+
+But it does NOT check:
+- **Does the final UI state match what the button label promises?**
+- **Does function B silently undo what function A just did?**
+- **Does shared state (Zustand/Redux/context) have side effects that cancel the intended action?**
+
+Real example: A "New Email" button called `setComposeMode(true)` then `selectThread(null)`. Both worked individually. But `selectThread` had a side effect resetting `composeMode: false`. The button did nothing. 54 bugs were found by systematic debugging — this one was missed.
+
+---
+
+## How It Works
+
+For EVERY interactive touchpoint in the target area:
+
+```
+1. IDENTIFY the handler (onClick, onSubmit, onChange, etc.)
+2. TRACE every function call in the handler, IN ORDER
+3. For EACH function call:
+   a. What state does it READ?
+   b. What state does it WRITE?
+   c. Does it have SIDE EFFECTS on shared state?
+   d. Does it reset/clear any state as a side effect?
+4. CHECK: Does any later call UNDO a state change from an earlier call?
+5. CHECK: Is the FINAL state what the user expects from the button label?
+6. CHECK: Are there race conditions (async calls that resolve in wrong order)?
+```
+
+---
+
+## Execution Steps
+
+### Step 1: Map State Stores
+
+Before auditing any touchpoint, build a side-effect map of every state store action:
+
+```
+For each Zustand store / React context in scope:
+  For each action/setter:
+    - What fields does it set?
+    - Does it RESET other fields as a side effect?
+    - Document: actionName → {sets: [...], resets: [...]}
+```
+
+This is the critical reference. The "New Email" bug was invisible without knowing that `selectThread` resets `composeMode`.
+
+**Output format:**
+```
+STORE: emailStore
+  setComposeMode(bool) → sets: {composeMode}
+  selectThread(thread|null) → sets: {selectedThread, selectedThreadId, messages, drafts, selectedDraft, summary} RESETS: {composeMode: false, composeData: null, redraftOpen: false}
+  setDraftGenerating(bool) → sets: {draftGenerating}
+  ...
+
+DANGEROUS RESETS (actions that clear state they don't own):
+  selectThread → resets composeMode (owned by setComposeMode)
+  reset → resets everything
+```
+
+### Step 2: Audit Each Touchpoint
+
+For each button/toggle/form submit in the target area:
+
+```
+TOUCHPOINT: [Button label] in [Component:line]
+  HANDLER: onClick → {
+    call 1: functionA() → sets {X: true}
+    call 2: functionB() → sets {Y: null} RESETS {X: false}  ← CONFLICT
+  }
+  EXPECTED: User sees [description of what button label promises]
+  ACTUAL: X is false because functionB reset it
+  VERDICT: BUG — [description]
+```
+
+**Check each of these bug patterns:**
+
+#### Pattern 1: Sequential Undo
+```
+handler() {
+  setState_A(true)     // sets X = true
+  setState_B(null)     // side effect: resets X = false
+}
+// Result: X is false. First call was pointless.
+```
+
+#### Pattern 2: Async Race
+```
+handler() {
+  fetchA().then(() => setState({ loading: false }))
+  fetchB().then(() => setState({ loading: true }))
+}
+// Result: final loading state depends on which resolves first
+```
+
+#### Pattern 3: Stale Closure
+```
+const [count, setCount] = useState(0)
+const handler = useCallback(() => {
+  setCount(count + 1)  // captures stale count
+  setCount(count + 1)  // same stale count — increments by 1, not 2
+}, [count])
+```
+
+#### Pattern 4: Missing State Transition
+```
+// Button says "Save" but handler only validates, never actually saves
+// Button says "Delete" but handler sets a flag without calling the API
+// Button says "Send" but the API endpoint is removed/broken
+```
+
+#### Pattern 5: Conditional Dead Path
+```
+handler() {
+  if (someState) {        // someState is ALWAYS false at this point
+    doTheActualThing()    // never reached
+  }
+}
+```
+
+#### Pattern 6: useEffect Interference
+```
+// Button sets stateX = true
+// A useEffect watches stateX and resets it to false
+// User sees nothing happen
+```
+
+### Step 3: Report
+
+For each bug found:
+
+```
+CLICK-PATH-NNN: [severity: CRITICAL/HIGH/MEDIUM/LOW]
+  Touchpoint: [Button label] in [file:line]
+  Pattern: [Sequential Undo / Async Race / Stale Closure / Missing Transition / Dead Path / useEffect Interference]
+  Handler: [function name or inline]
+  Trace:
+    1. [call] → sets {field: value}
+    2. [call] → RESETS {field: value}  ← CONFLICT
+  Expected: [what user expects]
+  Actual: [what actually happens]
+  Fix: [specific fix]
+```
+
+---
+
+## Scope Control
+
+This audit is expensive. Scope it appropriately:
+
+- **Full app audit:** Use when launching or after major refactor. Launch parallel agents per page.
+- **Single page audit:** Use after building a new page or after a user reports a broken button.
+- **Store-focused audit:** Use after modifying a Zustand store — audit all consumers of the changed actions.
+
+### Recommended agent split for full app:
+
+```
+Agent 1: Map ALL state stores (Step 1) — this is shared context for all other agents
+Agent 2: Dashboard (Tasks, Notes, Journal, Ideas)
+Agent 3: Chat (DanteChatColumn, JustChatPage)
+Agent 4: Emails (ThreadList, DraftArea, EmailsPage)
+Agent 5: Projects (ProjectsPage, ProjectOverviewTab, NewProjectWizard)
+Agent 6: CRM (all sub-tabs)
+Agent 7: Profile, Settings, Vault, Notifications
+Agent 8: Management Suite (all pages)
+```
+
+Agent 1 MUST complete first. Its output is input for all other agents.
+
+---
+
+## When to Use
+
+- After systematic debugging finds "no bugs" but users report broken UI
+- After modifying any Zustand store action (check all callers)
+- After any refactor that touches shared state
+- Before release, on critical user flows
+- When a button "does nothing" — this is THE tool for that
+
+## When NOT to Use
+
+- For API-level bugs (wrong response shape, missing endpoint) — use systematic-debugging
+- For styling/layout issues — visual inspection
+- For performance issues — profiling tools
+
+---
+
+## 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
+
+---
+
+## Example: The Bug That Inspired This Skill
+
+**ThreadList.tsx "New Email" button:**
+```
+onClick={() => {
+  useEmailStore.getState().setComposeMode(true)   // ✓ sets composeMode = true
+  useEmailStore.getState().selectThread(null)      // ✗ RESETS composeMode = false
+}}
+```
+
+Store definition:
+```
+selectThread: (thread) => set({
+  selectedThread: thread,
+  selectedThreadId: thread?.id ?? null,
+  messages: [],
+  drafts: [],
+  selectedDraft: null,
+  summary: null,
+  composeMode: false,     // ← THIS silent reset killed the button
+  composeData: null,
+  redraftOpen: false,
+})
+```
+
+**Systematic debugging missed it** because:
+- The button has an onClick handler (not dead)
+- Both functions exist (no missing wiring)
+- Neither function crashes (no runtime error)
+- The data types are correct (no type mismatch)
+
+**Click-path audit catches it** because:
+- Step 1 maps `selectThread` resets `composeMode`
+- Step 2 traces the handler: call 1 sets true, call 2 resets false
+- Verdict: Sequential Undo — final state contradicts button intent