showdar-skills 0.2.0

package/skills/showdar-review/SKILL.md

@@ -0,0 +1,155 @@
+---
+name: showdar-review
+description: Use when reviewing code or diffs for general correctness, architecture, performance, maintainability, or tests.
+---
+
+# Showdar Review
+
+## Purpose
+
+- Find defects and material engineering risks in a change without inventing style complaints.
+- Prioritize reachable correctness/security failures over cosmetic preferences.
+- Review the changed behavior in repository context, not isolated diff syntax.
+- Produce actionable findings with location, evidence, impact, and recommended correction.
+- Use `data/review-patterns.csv` as a risk prompt, not as an automatic lint rule.
+
+## When to use
+
+- Reviewing a pull request, branch, staged/uncommitted diff, or proposed patch.
+- Pre-merge quality pass after implementation/tests.
+- Focused security/performance/architecture review of changed paths.
+- Evaluating whether tests prove the behavior introduced by a change.
+
+## When not to use
+
+- The user asks to implement the change rather than review it.
+- There is no concrete code/change/design to inspect.
+- Do not turn code review into a repository-wide refactoring wishlist.
+- Formatter/linter-owned style issues are out of scope unless they hide correctness.
+
+## Inputs and assumptions
+
+- Base/reference revision or the current change set.
+- Repository instructions and relevant surrounding source/tests.
+- Use `scripts/collect-diff.mjs` to collect a read-only diff summary when appropriate.
+- A finding is valid only when a concrete scenario shows the risk is reachable.
+- Existing repository conventions matter; do not impose a different architecture by preference.
+
+## Non-negotiable rules
+
+- Do not invent findings.
+- Every finding includes exact location, evidence, impact, and recommended change.
+- Severity reflects user/system impact and likelihood, not reviewer taste.
+- Review changed behavior plus the minimum surrounding context needed to validate assumptions.
+- Security/auth checks must be verified server/owner-side; client checks are not sufficient policy proof.
+- Do not spend review budget on formatting already automated.
+- If no material findings exist, say so and mention residual verification limits.
+
+## Workflow
+
+### Phase 1 — understand intent and diff
+- Identify intended behavior and changed files/symbols.
+- Read tests and nearby ownership boundaries before judging implementation.
+- Note generated/vendor changes separately.
+
+### Phase 2 — correctness pass
+- Apply `references/correctness.md` to inputs, state transitions, ordering, lifecycle, errors, serialization, nullability, concurrency, and edge cases.
+- Trace at least one happy path and one important failure path.
+
+### Phase 3 — security and data pass
+- Apply `references/security.md` where auth, input, secrets, storage, networking, files, URLs, or sensitive data are touched.
+- Check authorization at authoritative boundaries.
+
+### Phase 4 — architecture and maintainability pass
+- Apply `references/architecture.md` and `references/maintainability.md`.
+- Check policy ownership, dependency direction, public contracts, type safety, and complexity introduced.
+
+### Phase 5 — performance pass
+- Apply `references/performance.md` to realistic hot paths/scales.
+- Look for N+1, event-loop/thread blocking, render/rebuild churn, image/bundle/memory cost.
+
+### Phase 6 — tests pass
+- Apply `references/testing.md`.
+- Ask whether tests can fail for the real changed behavior and critical regression. Use `data/review-patterns.csv` as a searchable prompt across correctness, architecture, security, performance, concurrency, data integrity, API design, state, mobile lifecycle, accessibility, testing, observability, and maintainability.
+
+### Phase 7 — severity and dedupe
+- Merge findings with the same root cause.
+- Assign P0/P1/P2/P3 only after impact is clear.
+- Drop speculative issues that lack a reachable scenario.
+
+## Decision points
+
+- P0: exploitable/critical data loss/outage or universally blocking defect with immediate action required.
+- P1: high-impact correctness/security/performance issue likely in realistic use.
+- P2: material edge-case/maintainability/test gap that can produce defects but is not immediately severe.
+- P3: worthwhile improvement with low defect risk; use sparingly.
+- Existing pattern imperfect but safe? Do not demand redesign unless the change worsens it or violates requirement.
+- Potential issue depends on impossible caller/state? Drop the finding.
+
+## Stack detection
+
+- TypeScript: `stacks/typescript.md` for unsafe casts/external data/impossible state.
+- React Native: `stacks/react-native.md` for lifecycle/list/native/accessibility/release surfaces.
+- Flutter: `stacks/flutter.md` for rebuild/async/layout/disposal/platform concerns.
+- Node backend: `stacks/node-backend.md` for auth/idempotency/transaction/event-loop/resource concerns.
+- Unsupported stack: inspect framework lifecycle and repository conventions before applying generic concerns.
+
+## Failure modes
+
+- Commenting on naming/formatting while missing auth or state defects.
+- Severity inflation: every finding labeled blocking.
+- “Could maybe” findings with no concrete input/state path.
+- Reviewing diff only and missing surrounding contract/owner.
+- Requesting abstraction because reviewer prefers a pattern.
+- Missing generated/native/deployment impact of a small source change.
+- Treating test count as evidence of test quality.
+
+## Stop conditions
+
+- Stop when the requested outcome is outside this skill and hand off to the more appropriate workflow.
+- Stop before destructive, irreversible, production, credential, publishing, or deployment actions unless the user explicitly approved them.
+- Stop when required evidence is unavailable and proceeding would require guessing about behavior, ownership, or safety.
+- Stop when a repository instruction conflicts with this playbook; repository/user instructions win.
+- Stop when all changed behavior has received correctness plus relevant security/architecture/performance/test passes and findings are deduplicated/evidence-backed.
+
+## Escalation conditions
+
+- Escalate suspected critical security/data-loss issues with clear evidence and avoid exploit amplification beyond what is needed to explain remediation.
+- Ask for missing base/diff/context when it prevents judging behavior.
+- If change is too large to review reliably, split by subsystem/commit and state the review boundary.
+- If generated code dominates, identify source generator/inputs before reviewing generated diffs line-by-line.
+
+## Verification
+
+- Re-read every finding and identify the exact execution/input path that triggers it.
+- Confirm referenced line/symbol exists in the current change/context.
+- Check whether existing tests or guards already invalidate the finding.
+- Verify severity matches impact/likelihood.
+- Remove duplicate/style-only/speculative findings.
+- If claiming clean review, state what was and was not executed/tested.
+
+## Output contract
+
+- Findings ordered P0 -> P3.
+- Each finding: **severity/title**, **location**, **evidence**, **impact/scenario**, **recommended change**.
+- After findings: brief **verification gaps/residual risk** if relevant.
+- If no findings: say no material findings found and state unverified areas.
+- Keep praise/summary secondary; findings are the primary review artifact.
+
+## Anti-patterns
+
+- Nitpicking formatter-owned style.
+- Inventing a bug from an unfamiliar API without checking its contract.
+- Reviewing architecture as if repository were greenfield.
+- P0/P1 severity without realistic impact.
+- Recommending “add tests” without naming missing invariant.
+- Large code rewrite suggestion when a local correctness fix is sufficient.
+
+## Example
+
+**P1 — authorization missing on export endpoint**
+- Location: route handler.
+- Evidence: authentication exists but workspace membership check used by sibling endpoints is absent.
+- Impact: authenticated user with another workspace ID can request export.
+- Recommendation: enforce server-side membership policy and add cross-workspace integration test.
+- See `examples/finding.md`.

package/skills/showdar-review/data/index.json

@@ -0,0 +1,14 @@
+{
+  "version": 1,
+  "skill": "showdar-review",
+  "datasets": [
+    {
+      "file": "data/review-patterns.csv",
+      "idField": "id",
+      "requiredColumns": ["id", "category", "pattern", "risk", "evidence", "good", "bad", "severity", "false_positive_notes", "tags", "reference", "stack"],
+      "searchableFields": ["category", "pattern", "risk", "evidence", "good", "bad", "false_positive_notes", "tags"],
+      "filterFields": ["category", "severity", "stack"],
+      "reference": "references/correctness.md"
+    }
+  ]
+}

package/skills/showdar-review/data/review-patterns.csv

@@ -0,0 +1,27 @@
+id,category,pattern,risk,evidence,good,bad,severity,false_positive_notes,tags,reference,stack
+correctness-null,correctness,unchecked external null,invalid input crashes or corrupts state,reachable payload and missing-field path,narrow validate and return typed error,cast and dereference directly,P1,known non-null internal invariant with proof is not a finding,nullability,references/correctness.md,typescript
+correctness-error,correctness,error path loses state,failed operation leaves UI or data falsely successful,inject failure and inspect state transition,preserve failed state and recovery action,catch then show success,P1,logging-only catch with propagated error is acceptable,error state,references/correctness.md,*
+correctness-order,correctness,ordering assumption,completion order changes result or side effect,controlled interleaving or event trace,version/cancel/idempotency guard,last callback wins,P1,serial execution proven by owner contract is safe,ordering,references/correctness.md,*
+correctness-boundary,correctness,off-by-one or empty boundary,first last empty or maximum item behaves wrong,table of boundary inputs,explicit boundary tests,only typical input tested,P2,unreachable values should be excluded by validated contract,boundary,references/correctness.md,*
+architecture-owner,architecture,policy in wrong owner,duplicate policy diverges across callers,call graph and sibling behavior,centralize at actual owner,caller-specific patches,P1,local policy is fine when callers intentionally differ,ownership,references/architecture.md,*
+architecture-cycle,architecture,new dependency cycle,initialization and change surface become coupled,imports or package graph,break cycle at stable contract,add another barrel or service,P1,type-only cycle with no runtime effect may be lower risk,dependency cycle,references/architecture.md,typescript
+architecture-abstraction,architecture,abstraction without leverage,indirection hides one simple behavior,new layer has one consumer,keep local or show volatility boundary,generic factory and interface,P2,second consumer or real plugin boundary can justify it,abstraction,references/maintainability.md,*
+security-authz,security,authorization only in client,API can be called without policy,request route lacks owner-side check,enforce policy at server/service,disable button or hide route,P0,public endpoint with no protected resource is not an authz gap,authorization,references/security.md,node
+security-input,security,unvalidated trust input,injection path or malformed data reaches interpreter,request/file/query value flow,validate and parameterize at boundary,regex or UI validation only,P0,validated typed internal values need no duplicate parser,input validation,references/security.md,node
+security-secret,security,secret in log/artifact,credential or personal data exposure,log/build/diff contains value,redact and verify by name/metadata,print env or token,P0,public non-sensitive build metadata is not a secret,secret handling,references/security.md,*
+security-path,security,unbounded path or URL,SSRF traversal or arbitrary file access,attacker controls path/host and sink,allowlist resolve and constrain path,concatenate user value into sink,P0,static trusted path with no attacker input is safe,path security,references/security.md,node
+performance-loop,performance,I/O or query inside loop,N+1 latency and load,query count grows with item count,batch or prefetch with measured bound,add cache without invalidation,P1,small bounded list with explicit product limit may be acceptable,n-plus-one,references/performance.md,node
+performance-render,performance,broad render state,typing/list interaction misses frame budget,profiler render count and data size,narrow owner or virtualization after measurement,memoize every subtree,P1,measured small subtree with budget proof is not a finding,render churn,references/performance.md,react
+performance-event-loop,performance,synchronous heavy work on event loop,all requests stall,profile or input-size growth,stream worker or chunk work,add timeout around blocking call,P1,small bounded work should be stated as such,event loop,references/performance.md,node
+performance-memory,performance,resource retained across lifecycle,memory grows with repeated flow,heap/listener/image/resource delta,dispose and bound cache,raise memory limit,P1,transient allocation returning to baseline is not retention,memory,references/performance.md,react-native
+concurrency-lost-update,concurrency,read-modify-write without lock,lost update or duplicate effect,two overlapping callers and final state,transaction/version/unique constraint,check then write without guard,P1,serialized owner with documented lock is safe,lost update,references/correctness.md,node
+concurrency-retry,concurrency,retry repeats effect,network timeout leaves unknown commit and retry duplicates,request id and durable effect,idempotency key and safe retry,retry every mutation,P1,idempotent operation with proof is not a finding,idempotency,references/correctness.md,*
+data-transaction,data integrity,related writes not atomic,partial state after error,fail second write and inspect DB,one transaction or compensating action,separate commits with no recovery,P1,eventually consistent workflow must document repair path,transaction,references/correctness.md,node
+data-migration,data integrity,destructive schema change,old app or rollback cannot read data,old/new schema compatibility,expand migrate contract,drop/rename in one rollout,P1,offline one-shot system with backup and explicit version gate may differ,migration,references/architecture.md,*
+api-validation,api design,ambiguous error contract,clients cannot recover consistently,status/body mismatch and callers,stable error code and validation shape,throw arbitrary string,P1,internal function with typed domain error may not need HTTP shape,error contract,references/correctness.md,node
+api-versioning,api design,breaking response without migration,old consumer fails on deploy,consumer versions and fixture,additive/versioned change and contract test,remove field silently,P1,all consumers atomically versioned can avoid compatibility window,compatibility,references/architecture.md,*
+mobile-disposal,mobile,async callback after disposal,crash or stale navigation,await crosses unmount/dispose and writes state,cancel/guard lifecycle and test leave-enter,ignore cancellation,P1,operation owned by process lifetime not screen is safe,lifecycle,references/maintainability.md,react-native
+mobile-accessibility,mobile,custom control lacks semantics,screen reader or keyboard cannot operate,role/name/state/focus inspection,native control or complete semantics,clickable visual-only container,P1,decorative noninteractive element is not a finding,accessibility,references/testing.md,react-native
+tests-mock,testing,mock-only behavior proof,regression passes while real boundary is broken,test never observes output/state,assert observable behavior at lowest real level,assert only mock call,P2,mock is valid for unavailable nondeterministic external system,mocks,references/testing.md,*
+tests-flaky,testing,arbitrary sleep or retry hides flake,slow nondeterministic CI and masked race,timing primitive and retry config,barrier/event/state synchronization,increase timeout or retry,P2,documented bounded polling of external state can be valid,flaky,references/testing.md,playwright
+observability-correlation,observability,operation lacks correlation,incident cannot join request/job/logs,request or job path without id,propagate redacted correlation and outcome,log raw payload only,P2,local pure function need not create correlation,diagnostics,references/maintainability.md,node

package/skills/showdar-review/examples/finding.md

@@ -0,0 +1,16 @@
+# Example finding
+
+Severity: P1 — authorization missing on export endpoint.
+
+Location: `routes/export.ts`, before the export job is queued.
+
+Evidence: the handler checks authentication but never verifies workspace
+membership. Sibling read endpoints call `requireWorkspaceMember`, while this
+route accepts a caller-provided workspace ID and starts a long-running job.
+
+Impact: any authenticated user who guesses a workspace ID can request its data.
+The issue is exploitable without a client bug and should block release.
+
+Recommended fix: enforce the shared membership policy before queueing work,
+return the existing forbidden response, and add an integration test for a user
+from another workspace. Re-check that logs and job payloads do not expose data.

package/skills/showdar-review/references/architecture.md

@@ -0,0 +1,3 @@
+# Architecture review
+
+Check ownership and dependency direction, public contract changes, duplicated policy, cross-layer leakage, lifecycle, generated/native ownership, and whether a new abstraction earns its cost. Trace one producer-to-consumer path and one failure path. Do not demand a preferred pattern when the existing design is coherent and safe; report only a reachable defect or material risk introduced by the change.

package/skills/showdar-review/references/correctness.md

@@ -0,0 +1,3 @@
+# Correctness review
+
+Trace changed behavior through inputs, state transitions, failure paths, concurrency, lifecycle, and outputs. Check invalid assumptions, missing branches, stale state, ordering, boundary values, nullability, serialization mismatch, retry/idempotency, and resource leaks. A finding needs a concrete reachable input/state path, evidence in the current code, impact, and a correction that preserves the intended contract.

package/skills/showdar-review/references/maintainability.md

@@ -0,0 +1,3 @@
+# Maintainability review
+
+Prefer clear contracts, local reasoning, typed state, explicit error behavior, and testable boundaries. Flag complexity that materially raises defect risk; skip personal style preferences already owned by formatter/linter.

package/skills/showdar-review/references/performance.md

@@ -0,0 +1,3 @@
+# Performance review
+
+Review named hot paths, algorithmic growth, repeated I/O, N+1 queries, render/rebuild churn, image/bundle cost, event-loop/main-thread blocking, memory retention, and unnecessary network work. Require realistic workload or profiler evidence where possible. Prioritize a measurable regression with user impact over generic optimization preference; state the scale at which it matters.

package/skills/showdar-review/references/security.md

@@ -0,0 +1,3 @@
+# Security review
+
+Inspect authentication and authorization at the authoritative owner, input validation, injection, secret handling, sensitive logging, insecure storage, SSRF/file/path handling, dependency trust, mobile deep links, IPC/capabilities, and data exposure. Follow attacker-controlled input to a sink and state prerequisites. Distinguish a reachable exploit from a theoretical concern; do not report client-only visibility as security enforcement.

package/skills/showdar-review/references/testing.md

@@ -0,0 +1,3 @@
+# Testing review
+
+Ask whether tests can fail for the right regression. Check missing critical branch/contract coverage, fragile mocks, non-determinism, timing sleeps/retries, leaked state, and whether changed behavior has proof at the lowest effective level. Name the missing invariant and the smallest test boundary that would catch it. Do not equate test count, snapshots, or coverage percentage with behavior proof.

package/skills/showdar-review/scripts/collect-diff.mjs

@@ -0,0 +1,5 @@
+#!/usr/bin/env node
+import { spawnSync } from 'node:child_process';
+const cwd=process.argv[2]??process.cwd(); const base=process.argv[3]??'HEAD';
+const run=a=>{const r=spawnSync('git',a,{cwd,encoding:'utf8'});return r.status===0?r.stdout.trim():null};
+console.log(JSON.stringify({base,status:run(['status','--short']),files:run(['diff','--name-only',base])?.split('\n').filter(Boolean)??[],stat:run(['diff','--stat',base]),diff:run(['diff','--no-ext-diff','--unified=3',base])},null,2));

package/skills/showdar-review/stacks/android.md

@@ -0,0 +1,3 @@
+# Android review
+
+Check lifecycle-aware coroutines, state restoration, main-thread work, permissions, manifest/resources, navigation, accessibility, and process death. Review Gradle/AGP/JDK and release/R8/signing impact when native configuration changes. Require a reachable scenario for each finding.

package/skills/showdar-review/stacks/flutter.md

@@ -0,0 +1,3 @@
+# Flutter review
+
+Review state ownership/rebuild scope, async lifecycle guards, constraints/layout overflow, list laziness, platform channels, disposal, semantics/text scaling, and native runner impact.

package/skills/showdar-review/stacks/ios.md

@@ -0,0 +1,3 @@
+# iOS review
+
+Review lifecycle/task cancellation, data decoding, thread/actor ownership, permissions, deep links, accessibility, and native package/config changes. Check scheme, deployment target, entitlements, privacy usage, and release diagnostics when touched. Do not infer a signing defect from source-only changes without target evidence.

package/skills/showdar-review/stacks/nextjs.md

@@ -0,0 +1,3 @@
+# Next.js review
+
+Check server/client boundaries, route handlers, authorization, cache/revalidation, hydration determinism, metadata, image cost, and route loading/error behavior. A client guard is not authorization. A successful build does not prove runtime cache or environment behavior; ask for route-level evidence.

package/skills/showdar-review/stacks/node-backend.md

@@ -0,0 +1,3 @@
+# Node backend review
+
+Review request validation, authz, idempotency, transactions, pool/resource cleanup, event-loop blocking, retry semantics, observability, shutdown, and migration compatibility.

package/skills/showdar-review/stacks/react-native.md

@@ -0,0 +1,3 @@
+# React Native review
+
+Review lifecycle/navigation, list virtualization, unstable render inputs, image cost, native module/API compatibility, permissions, keyboard/safe-area behavior, and release-native changes.

package/skills/showdar-review/stacks/react.md

@@ -0,0 +1,3 @@
+# React review
+
+Review state ownership, effect synchronization, stable keys, hydration, semantic HTML, focus, and data-fetching boundaries. Require a concrete stale-state, accessibility, or render-cost scenario before reporting. Distinguish derived state from an intentional user-editable draft.

package/skills/showdar-review/stacks/swift-kotlin.md

@@ -0,0 +1,3 @@
+# Swift and Kotlin review
+
+Look for unsafely shared mutable state, cancellation leaks, unchecked decoded input, blocking main/UI work, and platform lifecycle violations. Prefer type narrowing, explicit ownership, structured concurrency, and tests at the affected boundary over broad defensive guards.

package/skills/showdar-review/stacks/typescript.md

@@ -0,0 +1,3 @@
+# TypeScript review
+
+Watch unsound casts, `any` at boundaries, impossible union states, unchecked external data, promise/error typing, mutation of shared objects, and APIs that erase useful types. Prefer narrowing and explicit domain types over assertion chains.

package/skills/showdar-security/SKILL.md

@@ -0,0 +1,169 @@
+---
+name: showdar-security
+description: Use when assessing threat models, attack surfaces, trust boundaries, auth/authz, secrets, exposure, or exploitability.
+---
+
+# Showdar Security
+
+## Purpose
+
+- Perform evidence-backed security analysis, threat modeling, secure-design review, and implementation-security guidance.
+- Follow sensitive data from requirements, code, configuration, architecture, dependencies, and runtime boundaries to its security outcome.
+- Produce practical findings with affected assets, trust boundaries, impact, exploitability, remediation, residual risk, and verification.
+- Use `data/security-patterns.csv` as a focused prompt set and load `references/threat-modeling.md` when modeling a larger flow.
+
+## When to use
+
+- The user asks for a threat model, security posture review, attack-surface map, or secure-design review.
+- A change involves authentication, authorization, sessions, tokens, secrets, credentials, sensitive data, storage, URLs, files, IPC, or permissions.
+- The user asks to review an API for authz, IDOR/BOLA, injection, SSRF, XSS, CSRF, or data exposure risk.
+- A mobile flow involves deep links, WebViews, local storage, biometrics, app lifecycle, or Android/iOS permission boundaries.
+- A backend, desktop, dependency, supply-chain, or security-configuration change needs a security regression assessment.
+
+## When not to use
+
+- Do not use this for general correctness, maintainability, architecture, performance, or test review; use `showdar-review`.
+- Do not use this to diagnose the root cause of an observed crash or failure; use `showdar-debug`.
+- Do not implement automated tests; use `showdar-test`. Do not own QA scenario or regression planning; use `showdar-quality`.
+- Do not perform offensive exploitation, credential guessing, network attacks, destructive probes, or production changes by default.
+- Do not treat a generic word such as “review” as security intent without security, auth, exposure, secret, threat, or exploitability context.
+
+## Inputs and assumptions
+
+- Prefer the supplied requirement, change diff, repository instructions, architecture, schemas, handlers, state models, configuration, dependency manifests, and tests.
+- Record the evidence boundary: files, commands, environments, versions, and runtime surfaces actually inspected.
+- Never print secret values, tokens, keys, cookies, passwords, credentials, personal data, or sensitive payloads; report only redacted names, locations, and metadata.
+- Separate confirmed issue, suspected risk, accepted control, unknown, and open decision. A code smell is not automatically an exploitable vulnerability.
+- Preserve application constraints and existing security controls unless evidence shows they are unsafe or the user explicitly changes scope.
+
+## Non-negotiable rules
+
+- Use evidence for every finding: location, data flow, reachable condition, affected asset, and trust boundary.
+- Do not invent vulnerabilities, attacker capabilities, exploitability, severity, or stakeholder decisions that evidence does not support.
+- Distinguish exploitability from theoretical weakness and state attacker prerequisites instead of claiming exploitability without proof.
+- Explain impact, exploitability/preconditions, affected scope, bounded remediation, residual risk, and verification for actionable findings.
+- Assign P0/P1/P2/P3 or Info only when impact and realistic reachability are sufficiently evidenced; do not label everything critical.
+- Review authorization at the authoritative owner, not only client visibility or route guards. Check API authorization, IDOR/BOLA, role/tenant boundaries, and object ownership.
+- Check validation and output handling for injection, unsafe deserialization, command execution, path traversal, file upload, SSRF, XSS, and CSRF where the stack makes them relevant.
+- Check authentication, session/token lifecycle, refresh/revocation, credential exposure, secrets handling, storage, encryption use, sensitive logging, and privacy boundaries.
+- Check mobile deep links, WebViews, local storage, biometric/auth flows, native permissions, and Android/iOS bridges; check Tauri/Electron IPC, capabilities, filesystem, and command boundaries.
+- Check dependency and supply-chain risk, security configuration, permissions, and security regression coverage without adding offensive tooling.
+
+## Workflow
+
+### Phase 1: establish scope and evidence
+
+1. Identify the requested decision: threat model, review, checklist, remediation guidance, or regression verification.
+2. Map changed and reachable surfaces: actors, assets, entry points, data stores, integrations, jobs, native bridges, and runtime boundaries.
+3. Read only relevant source, configuration, schemas, manifests, tests, and existing security documentation; record what was not inspected.
+4. Redact sensitive values immediately. Keep filenames, variable names, hashes, and safe metadata only when they do not disclose secrets.
+
+### Phase 2: map the attack surface
+
+- List assets and their confidentiality, integrity, availability, or privacy impact.
+- Identify actors, authorization decisions, anonymous and authenticated entry points, and trust boundaries.
+- Trace attacker-controlled input through validation, parsing, storage, logging, rendering, network calls, command execution, or filesystem access.
+- Identify controls at the correct owner: server/API, backend service, native platform, desktop host, browser, or client UI.
+
+### Phase 3: assess practical threats
+
+- Consider spoofing/authentication, tampering/integrity, repudiation/auditability, information disclosure, denial of service, and elevation of privilege when useful.
+- Test reasoning against denial, expired/revoked sessions, duplicate requests, cross-tenant objects, malformed input, offline/retry state, deep-link impersonation, and permission changes.
+- State the exact preconditions for a finding: attacker access, account role, network position, feature flag, platform, configuration, or user action.
+- Classify each result as confirmed issue, suspected risk, control, unknown, or open decision.
+
+### Phase 4: prioritize and remediate
+
+- Prefer the smallest fix that closes the actual trust-boundary or data-flow gap.
+- Order work by realistic impact and exploitability, then by scope and verification cost.
+- Preserve compatible behavior, migration constraints, and existing controls; call out when a safe fix requires a stakeholder or platform decision.
+- Define a security regression check for each remediation and identify external evidence that remains unavailable.
+
+## Decision points
+
+- Use a security review when concrete code, configuration, or architecture is available; use a threat model when actors, assets, and boundaries need to be made explicit first.
+- Use a checklist only after identifying the context: auth, payments, upload, deep links, API endpoints, WebView, local storage, or desktop IPC.
+- Treat missing authorization, data ownership, secret rotation, privacy, encryption, deletion, or production access rules as escalation items.
+- Use P0/Critical for immediate severe impact with credible reachability, P1/High for realistic high-impact exposure, P2/Medium for material bounded risk, P3/Low for limited impact, and Info for evidence or hardening with no demonstrated vulnerability.
+- Do not force CVSS, OWASP labels, or STRIDE terminology when a plain risk explanation is clearer.
+
+## Stack detection
+
+- Web/Next.js: inspect browser/server boundaries, cookies, CSRF, XSS/output encoding, SSRF, cache/privacy, headers, and runtime configuration.
+- Backend/API/Node: inspect schema validation, authorization, tenant/object ownership, idempotency, timeouts, deserialization, logging, persistence, and dependency exposure.
+- React Native/Flutter/iOS/Android: inspect deep links, WebViews, local storage, biometrics, permission states, lifecycle, native bridges, signing boundaries, and supported OS behavior.
+- Tauri/Electron: inspect IPC commands, capability policy, serialization, preload/context isolation, filesystem paths, shell/command execution, updater, and packaging permissions.
+- Docker and CI/CD: inspect build context, image provenance, dependency installation, secret injection, token permissions, artifact exposure, and workflow trust boundaries without changing infrastructure by default.
+
+## Failure modes
+
+- Calling a theoretical weakness exploitable without a reachable source-to-sink path or prerequisites.
+- Treating client-side hiding as authorization, a dependency age as a vulnerability, or a missing scanner as proof of insecurity.
+- Printing a secret while trying to prove secret exposure, or copying credentials into a report, command, fixture, or patch.
+- Inflating severity, duplicating one root cause across many findings, or recommending a broad rewrite when a bounded control closes the gap.
+- Reviewing only the named file while ignoring the authoritative authorization owner, trust boundary, or consuming caller.
+
+## Stop conditions
+
+- Stop before declaring exploitability when the relevant code path, configuration, attacker prerequisite, or runtime boundary was not observed.
+- Stop before suggesting production or destructive security changes when authorization, rollback, maintenance window, or data impact is unknown.
+- Stop and report an open decision when a secure behavior depends on an unstated role, tenant, retention, consent, encryption, or platform policy.
+- Stop before any offensive probe, credential access, network attack, or secret handling beyond redacted metadata; request separate explicit scope if required.
+
+## Escalation conditions
+
+- Escalate credible credential, token, private-key, personal-data, payment, cross-tenant, command-execution, or production-integrity exposure immediately with redacted evidence.
+- Escalate missing ownership or authorization rules, secret rotation responsibility, privacy/compliance requirements, encryption/key management, and unsupported platform/version decisions.
+- Escalate suspected supply-chain compromise, malicious dependency behavior, tampered release artifact, or CI token over-privilege without attempting to investigate offensively.
+- Escalate a conflict between current controls and supplied requirements instead of silently choosing the weaker interpretation.
+
+## Verification
+
+- Re-check every finding against its source location, affected asset, trust boundary, preconditions, impact, and severity rationale.
+- Verify that remediation closes the data-flow or authorization gap and does not expose new secrets, logs, permissions, or compatibility regressions.
+- Add or request a deterministic security regression test at the right boundary; hand automated implementation to `showdar-test`.
+- Separate local evidence from unavailable external evidence such as provider scans, penetration tests, mobile store review, production telemetry, or secret rotation confirmation.
+- Report residual risk and unverified assumptions explicitly; never claim a clean security posture from a limited review.
+
+## Output contract
+
+### Security review
+
+1. Summary
+2. Attack surface
+3. Findings
+4. Severity
+5. Evidence
+6. Impact
+7. Remediation
+8. Residual risk
+9. Verification
+
+Each finding includes status (`confirmed issue`, `suspected risk`, `control`, `unknown`, or `open decision`), affected asset/trust boundary, severity only when supported, exact redacted evidence, exploitability/preconditions, impact, remediation, and verification.
+
+### Threat model
+
+Use the smallest useful set of: Assets, Actors, Trust boundaries, Entry points, Threats, Controls, Gaps, and Priority mitigations. Use STRIDE-like reasoning only when it improves coverage.
+
+### Security checklist
+
+Choose only context-relevant checks for auth, payments, file upload, deep links, API endpoints, WebView, local storage, or desktop IPC. Mark each item observed, passed, failed, not applicable, or unknown, with evidence and an owner.
+
+## Anti-patterns
+
+- “No issues found” without stating files, boundaries, evidence limits, and residual risk.
+- One giant generic OWASP checklist that hides the actual changed data flow.
+- Critical severity for every missing hardening control, scanner warning, or old dependency.
+- Secret values, exploit payloads, credential guesses, destructive commands, or production changes in the report.
+- Treating requirements, current behavior, and assumptions as the same security fact.
+- Replacing the application architecture instead of fixing the smallest proven boundary failure.
+
+## Example
+
+**Request:** “Review this API for authorization and data exposure risks.”
+
+- **Evidence:** inspect route, handler, policy owner, object lookup, tenant filter, response serializer, logs, and tests; record exact paths without printing tokens or data.
+- **Threat model:** authenticated user is an actor, account records are assets, API boundary is the entry point, and the authorization middleware-to-query boundary is the trust boundary.
+- **Confirmed issue:** if a request-supplied object ID reaches a query without owner/tenant enforcement, report a confirmed IDOR/BOLA path with role and account prerequisites.
+- **Remediation:** enforce owner/tenant authorization at the authoritative service boundary and add a cross-account regression test.
+- **Residual risk:** provider WAF, production telemetry, and secret rotation remain unverified unless evidence was supplied.

package/skills/showdar-security/data/index.json

@@ -0,0 +1,14 @@
+{
+  "version": 1,
+  "skill": "showdar-security",
+  "datasets": [
+    {
+      "file": "data/security-patterns.csv",
+      "idField": "id",
+      "requiredColumns": ["id", "category", "prompt", "evidence", "output", "risk", "tags", "reference", "stack"],
+      "searchableFields": ["category", "prompt", "evidence", "output", "risk", "tags"],
+      "filterFields": ["category", "stack"],
+      "reference": "references/threat-modeling.md"
+    }
+  ]
+}

package/skills/showdar-security/data/security-patterns.csv

@@ -0,0 +1,13 @@
+id,category,prompt,evidence,output,risk,tags,reference,stack
+threat-model,threat-model,What assets actors entry points and trust boundaries define this threat model?,requirements architecture data flow runtime boundaries,concise threat model with threats controls gaps and priority mitigations,unmapped boundaries hide practical attack paths,"threat model,attack surface,trust boundaries",references/threat-modeling.md,*
+authz-review,authorization,Can the authoritative owner enforce role tenant and object authorization?,routes handlers policies queries serializers authorization tests,confirmed or suspected authz gap with IDOR/BOLA preconditions and remediation,client-only checks expose cross-account data,"authorization,IDOR BOLA,API authz",references/authz-secrets.md,node;nextjs
+secrets-review,secrets,Where can credentials tokens keys or private data be exposed or logged?,env names CI config logs storage bundle and reports,redacted exposure finding with rotation owner and verification,secret values in reports create a second incident,"secrets,credentials,redaction,sensitive logging",references/authz-secrets.md,*
+input-injection,input,Which untrusted inputs reach interpreters files URLs queries or rendered output?,schemas parsers sinks encoding and network/file calls,bounded injection SSRF XSS CSRF or path-risk analysis,untraced input reaches a dangerous sink,"input validation,injection,SSRF,XSS CSRF",references/authz-secrets.md,react;node;nextjs
+mobile-deeplink,mobile,What happens when an untrusted deep link or WebView payload reaches a mobile action?,navigation intent filters WebView bridge local storage biometrics and permissions,platform-specific deep-link security review with lifecycle and recovery checks,web assumptions fail across mobile trust boundaries,"mobile deep link,WebView,local storage,biometric permissions",references/mobile-security.md,react-native;flutter;ios;android
+api-exposure,api,Which API responses and errors reveal sensitive data across auth and tenant boundaries?,OpenAPI handlers serializers logs and integration tests,API data-exposure review with owner-side control and redacted evidence,overbroad responses leak private or cross-tenant data,"API authorization,sensitive data,tenant boundary",references/authz-secrets.md,node;nextjs
+desktop-ipc,desktop,Which Tauri or Electron IPC commands cross into filesystem shell or native capabilities?,preload commands capability policy serialization and path validation,desktop boundary review with command and permission mitigations,renderer input can reach privileged native operations,"desktop IPC,command execution,filesystem permissions",references/mobile-security.md,tauri;electron
+dependency-supply-chain,dependency,What dependency and build-chain trust assumptions affect this release?,lockfiles provenance install scripts CI permissions and artifacts,supply-chain risk with evidence and bounded controls,dependency age alone is not proof of a vulnerability,"dependency,supply chain,unsafe deserialization",references/supply-chain.md,node;docker
+session-tokens,session,Are authentication session and refresh tokens validated rotated revoked and stored safely?,issuance refresh logout expiry storage cookies and tests,session lifecycle gaps with attacker prerequisites and regression evidence,stale or replayable tokens extend unauthorized access,"authentication,session tokens,refresh revocation",references/authz-secrets.md,react;node;react-native
+storage-encryption,storage,Does sensitive data use appropriate storage and encryption boundaries?,database mobile storage key management backups and access policy,storage and encryption review with key ownership and residual risk,plaintext persistence expands compromise impact,"storage,encryption,key management,privacy",references/mobile-security.md,node;react-native;ios;android
+security-regression,regression,Which security controls need deterministic regression coverage after this change?,changed boundary authz input data storage dependency and tests,security regression scope handed to showdar-test without claiming execution,security fixes regress when only happy paths are checked,"security regression,regression coverage,verification",references/threat-modeling.md,*
+logging-privacy,logging,Do logs metrics traces and error responses avoid secrets and unnecessary personal data?,logging config telemetry serializers redaction tests and retention,privacy-safe observability review with redacted evidence,diagnostic output can become a data-exposure surface,"logging,privacy,data exposure",references/authz-secrets.md,node;react-native

package/skills/showdar-security/examples/api-authorization-review.md

@@ -0,0 +1,9 @@
+# API authorization review
+
+**Request:** Review an account endpoint for authorization and data exposure.
+
+**Evidence:** Read the route, handler, policy owner, object lookup, tenant filter, serializer, logs, and tests. Record paths and redacted identifiers only.
+
+**Finding format:** State whether the issue is confirmed or suspected, the affected account asset and API trust boundary, the caller role and prerequisites, impact, severity rationale, bounded remediation, residual risk, and verification.
+
+**Example:** If a request ID reaches a lookup without owner/tenant enforcement, report the reachable IDOR/BOLA path and enforce authorization at the service boundary. Add a cross-account regression test through `showdar-test`; do not infer security from client-side route hiding.

package/skills/showdar-security/examples/mobile-deeplink-review.md

@@ -0,0 +1,7 @@
+# Mobile deep-link security review
+
+**Scope:** Review a React Native deep link that opens a payment or account screen.
+
+Check URL parsing, allowlisted hosts/routes, authentication state, token handoff, replay, WebView navigation, native intent filters, background/resume state, and local storage. Separate iOS and Android evidence.
+
+Mark missing link ownership, permission, or authentication decisions as open questions. Do not open attacker-controlled links, access device credentials, or claim exploitability without a reachable path and prerequisites.

package/skills/showdar-security/examples/secret-exposure-review.md

@@ -0,0 +1,5 @@
+# Secret exposure and configuration review
+
+Inspect environment file names, CI configuration, source history when in scope, bundles, logs, crash reports, examples, and telemetry configuration. Output only locations, variable names, hashes, or counts that do not disclose values.
+
+For a suspected exposure, state evidence status, affected credential or data boundary, rotation owner, blast radius, and verification needed. Treat rotation and revocation as explicit operational actions; do not silently change credentials.

package/skills/showdar-security/examples/threat-model-open-assumptions.md

@@ -0,0 +1,11 @@
+# Threat model with unresolved assumptions
+
+**Assets:** account data and session tokens.
+
+**Actors:** anonymous visitor, authenticated user, support operator, and service account as supplied or observed.
+
+**Trust boundaries:** browser/mobile client to API, API to data store, and CI to release artifact.
+
+**Threats and controls:** consider cross-account access, token replay, sensitive logs, malformed input, and artifact tampering; list only controls observed in code or configuration.
+
+**Open questions:** who owns tenant authorization, which deep-link hosts are trusted, how long sessions remain valid, and who can rotate credentials. Do not convert these decisions into invented requirements.

package/skills/showdar-security/references/authz-secrets.md

@@ -0,0 +1,7 @@
+# Authentication, authorization, and secrets
+
+Inspect the authoritative owner of each decision. For APIs, follow identity and tenant/object IDs through middleware, service policy, query filters, serializers, and audit logs. Test the reasoning for anonymous, wrong-role, cross-tenant, expired, revoked, duplicate, and replayed requests.
+
+For sessions and tokens, check issuance, audience, expiry, refresh, rotation, revocation, storage, cookie flags, deep-link handoff, logout, and error handling. For secrets, report only the variable or file name and location; never copy values into output. Check CI logs, bundles, source control, crash reports, telemetry, and examples as exposure surfaces.
+
+Recommend the smallest owner-side fix and a regression check. Secret rotation, key ownership, privacy retention, and compliance decisions remain explicit open decisions when not supplied.

package/skills/showdar-security/references/mobile-security.md

@@ -0,0 +1,7 @@
+# Mobile, WebView, and desktop boundaries
+
+For React Native, Flutter, iOS, and Android, inspect URL/deep-link parsing, intent filters, universal/app links, WebView navigation and bridges, local storage, biometric fallback, permission transitions, foreground/background state, screenshots, backups, and native bridge arguments.
+
+For Tauri and Electron, inspect preload/context isolation, IPC command allowlists, capability policy, serialization, path normalization, shell execution, filesystem permissions, updater channels, signing, and renderer-to-host trust boundaries.
+
+Split acceptance by platform and lifecycle. A client-side guard is not authoritative authorization. Keep device, signing, store, and production checks separate from local evidence.

package/skills/showdar-security/references/supply-chain.md

@@ -0,0 +1,5 @@
+# Dependency and supply-chain review
+
+Inspect lockfiles, install scripts, registries, provenance, artifact integrity, dependency permissions, CI token scope, untrusted pull-request inputs, and build context. Distinguish known advisory evidence from an age or naming concern.
+
+Recommend bounded controls such as pinned or reviewed versions, least-privilege tokens, protected publishing, reproducible artifacts, and reviewable update paths. Do not download suspicious packages, execute untrusted payloads, probe a network, or claim compromise without evidence.

package/skills/showdar-security/references/threat-modeling.md

@@ -0,0 +1,12 @@
+# Threat modeling
+
+Start with assets, actors, entry points, trust boundaries, and the decision the review must support. Trace the most important attacker-controlled input to its first authoritative control and final sensitive sink.
+
+Use a compact table when useful:
+
+| Asset | Actor/entry point | Trust boundary | Threat | Existing control | Gap/evidence |
+| --- | --- | --- | --- | --- | --- |
+
+Consider spoofing, tampering, repudiation, information disclosure, denial of service, and privilege escalation only where they explain a reachable risk. Record prerequisites such as account role, network position, platform, feature flag, or user action.
+
+Separate confirmed issues from suspected risks and unknowns. A missing control is not automatically exploitable; state what evidence would confirm it. Keep secret values and sensitive payloads redacted.