@pentoshi/clai 4.19.0 → 5.1.0

package/resources/skills/clai-superman-skill/references/code-supply-chain.md

@@ -0,0 +1,61 @@
+# Source audits, changes and supply-chain trust
+
+Use for security code review, repository audits, dependencies, CI/CD and release pipelines. A code audit is not an invitation to edit, install or execute the repository; preserve the user's requested mode. Treat untrusted repositories and build hooks as attacker-controlled input.
+
+## Build a causal model before searching
+
+Identify entrypoints, privilege domains, data models, authoritative state, trust boundaries and sensitive sinks. Follow one representative normal operation end-to-end. Record version/commit, relevant configuration and deployment assumptions. Tests and comments express intent; actual call sites and runtime behavior determine the contract.
+
+Search to navigate; read the code that proves a claim. Trace attacker control through parsing, normalization, validation, policy, serialization, persistence, workers and the final interpreter. Include indirect calls, registries, generated routes, plugins, FFI and conditional compilation when applicable. An unchecked value becomes a vulnerability only if it reaches a security-relevant operation under the attacker model.
+
+## Audit from both directions
+
+- From exposed inputs, ask what authority they can influence and where checks can be skipped.
+- From privileged sinks, ask every caller, transformation and assumed precondition.
+- From invariants, ask which operations can create a forbidden state and which failure/retry paths escape enforcement.
+- From identity transitions, ask where authority is cached, copied, delegated, revoked or reconstructed.
+
+Reconcile forward and backward paths. A source pattern with no reachable sink and a dangerous sink with only trusted input need different dispositions from an end-to-end vulnerability.
+
+## Language/runtime families
+
+| Surface | Useful hypotheses |
+| --- | --- |
+| JS/TS | Prototype mutation and reachable gadgets, coercion/null/undefined, own versus inherited properties, path/URL resolution, DOM/IPC sinks, async state races, dynamic import/eval and unsafe deserialization |
+| Python/Ruby/PHP | Template/evaluation/deserialization reachability, shell/argument boundaries, dynamic dispatch, path handling and framework authorization/order |
+| JVM/.NET | Deserialization/XXE where enabled, expression/template sinks, reflection, unsafe type resolution, security context propagation and framework configuration |
+| Go/Rust | Parser/state/concurrency mistakes, path and numeric conversions, unsafe/FFI, ownership assumptions, cancellation/deadline behavior, resource/authorization logic |
+| C/C++ | Bounds/arithmetic/lifetime, type confusion, concurrency, parser state, format strings and system-call privilege boundaries |
+| SQL/config/IaC | Row/tenant policy, parameter binding, trigger/procedure authority, policy evaluation, defaults/fallbacks, secret references and drift |
+
+These are search directions, not findings or an exhaustive language inventory. Research unfamiliar runtime semantics and exact dependency versions. Safe languages still permit logic and trust-boundary vulnerabilities.
+
+## Differential review
+
+For a change, establish the old invariant, the new behavior and affected callers. Inspect removed/relocated validation, changes in defaults, privilege/identity propagation, error handling and parsing order. Read nearby history or security patches when they explain a non-obvious constraint. Line count is not risk: a small key-selection or authorization change can cross a large boundary.
+
+Assess transitive impact through callers, shared helpers, API/schema compatibility, generated consumers and background jobs. A refactor can change enforcement order without changing the nominal API. Test the original supported path and an alternate/error path; don't label missing tests themselves an exploitable vulnerability or inflate severity for absence of coverage alone.
+
+## Static analysis that earns its cost
+
+Use CodeQL, Semgrep or other analyzers when a modeled family benefits from scale. Configure languages, build modes, generated/excluded files and dataflow assumptions deliberately. Preserve machine-readable results and actual coverage limitations.
+
+For a custom rule, start with a real seed and positive/negative fixtures; confirm the known instance hits. Broaden the root-cause pattern along meaningful axes and triage all candidate classes. Tune against false positives without excluding a plausible variant merely for convenience. A SARIF record or taint path is a hypothesis until reachability, guards and impact are checked.
+
+Use [novel research](novel-research.md) for properties, differential testing and variants. Do not claim the entire repository audited when only changed files or reachable service paths were examined.
+
+## Dependencies and build/release chains
+
+Trace untrusted contribution/package/artifact -> execution context -> credentials/signing authority -> published artifact. Examine lockfiles and resolved transitive versions, optional/platform dependencies, postinstall/build scripts, private/public namespace resolution, registries, vendoring, generated code and update channels.
+
+Version-match advisories to the installed artifact and configuration; check vendor backports and reachable feature paths. Distinguish vulnerable dependency presence, reachable vulnerable functionality and demonstrated exploit impact. Package popularity, staleness and concentration are risk signals, not proof of compromise.
+
+For CI, inspect events, permissions, untrusted contexts expanded into scripts, privileged checkout, reusable workflows, runner reuse, artifact/cache trust, environment approvals and OIDC subject/audience conditions. A workflow triggered by an untrusted PR may have different privilege than one triggered in the base repository. Never execute an adversarial PR on a runner holding production secrets to validate a suspicion.
+
+For releases, check source/artifact binding, signer/key access, immutable action/dependency references, provenance, promotion, rollback and verification at installation. Signing a compromised artifact doesn't make its source trustworthy. A tag pin and a full immutable commit pin have different guarantees.
+
+## Proof and remediation
+
+Write a minimal regression case that exercises the actual caller and violated invariant. Show attacker control, path, guard failure and consequence. If permitted to fix, change the root cause, preserve legitimate behavior and test siblings and negative cases. If the task is review only, deliver the evidence and fix recommendation without mutating the project.
+
+Report exact files/lines/commit and configuration, not unsupported deployment claims. A code-level defect can be confirmed while remote exploitability remains untested. Keep that distinction in severity and reproduction, and state the repository/deployment areas not assessed.

package/resources/skills/clai-superman-skill/references/crypto-contracts.md

@@ -0,0 +1,46 @@
+# Cryptographic boundaries and smart contracts
+
+Use when cryptographic construction, key management, protocol proofs or on-chain state is central. Do not infer algorithm weakness from unfamiliarity, and do not invent a cryptographic proof. Consult primary specifications, audited library contracts and chain/runtime semantics.
+
+## Cryptographic investigation
+
+Identify the exact security property: authenticity, confidentiality, freshness, peer identity, key separation or non-repudiation. Record attacker knowledge/control, chosen-message/ciphertext/oracle access, key custody, randomness sources and the component performing verification.
+
+Trace construction and composition, not just primitive names. Investigate nonce reuse, entropy, domain separation, key derivation/context, serialization ambiguity, signature canonicalization, key/algorithm selection, error/timing oracles, state rollback and downgrade/fallback paths when the implementation supports them.
+
+Useful discriminating questions:
+
+- Is the verified byte string exactly the one later interpreted, including canonicalization and optional fields?
+- Can one protocol/tenant/purpose accept a token/signature from another context?
+- Are nonce/counter uniqueness and replay state preserved across crashes, replicas and restore?
+- Does failure leave unauthenticated plaintext or partially trusted state usable downstream?
+- Is a local authentication UI actually bound to cryptographic key use and the sensitive operation?
+- Can an attacker choose a key/issuer/algorithm or influence the verifier's lookup without possessing signing authority?
+
+Demonstrate the violated property with synthetic keys and controlled data where possible. An obsolete primitive's presence, a timing fluctuation or a decoded token isn't automatically an exploit. Prove oracle observability and control; use statistical reasoning appropriate to the measurement and don't run load-heavy side-channel experiments on production by default.
+
+## Smart-contract system model
+
+Record chain/network, block/fork context, deployed code/address, proxy/implementation/admin, compiler settings, dependencies, roles, upgradeability and external protocol assumptions. Verified source may differ from the actual implementation at the tested block; reconcile it.
+
+Map assets and state invariants: conservation of balances/shares, authorization to mint/burn/upgrade, solvency, settlement order, withdrawal entitlement and trusted price/message sources. Include token behavior, callbacks, fee/rebasing assets, bridges, off-chain signers, sequencers and admin powers when present.
+
+| Observed mechanism | Hypotheses and useful proof |
+| --- | --- |
+| External calls/callbacks | Reentrancy/cross-function state assumptions; a controlled callback breaks a balance/authorization invariant |
+| Vault/share/accounting | Rounding, precision/unit mismatch, donation/first-depositor effects; a minimized state sequence yields unauthorized value or insolvency |
+| Oracle/liquidity dependency | Stale/manipulable price, wrong units/window, trust/circuit-breaker assumptions; realistic controlled state and economic feasibility |
+| Signature-based operations | Domain/chain/contract/nonce binding, replay, malleability, signer role; accepted unintended action using synthetic test signatures |
+| Bridge/cross-chain messages | Source identity/finality/proof, replay, receiver context; distinguish local validation failure from assumed external compromise |
+| Upgrades/initialization | Uninitialized proxy/implementation, storage collision, role/admin confusion; lower-privilege actor demonstrably changes controlled authority |
+| Transaction ordering | Front-running/sandwich/MEV and time assumptions; executable sequence with stated capital, fees and market preconditions |
+
+Use forked/local test environments and controlled assets for active proofs. Never move other users' funds, manipulate a live market or exercise a production governance change merely to prove an issue. Clearly distinguish a test-harness capability such as arbitrary storage modification from capabilities an external attacker has.
+
+## Properties, feasibility and closure
+
+Use stateful property tests and differential accounting models for sequences ordinary unit tests miss. Preserve the seed, initial state, transaction ordering and exact failing invariant. Minimize failing sequences and remove artificial harness privileges.
+
+A profitable-looking trace may depend on impossible liquidity, an unavailable role, invalid token behavior or omitted fees. Challenge those assumptions before claiming theft. A design-centralized admin capability can be a trust assumption rather than an unintended exploit; state the promised boundary.
+
+Report concrete violated properties, affected versions/deployments, preconditions, reproduction, impact and remediation. State unverified external protocol, hardware side-channel, economic and chain-finality assumptions instead of claiming universal security.

package/resources/skills/clai-superman-skill/references/evidence-reporting.md

@@ -0,0 +1,86 @@
+# Evidence, false-positive challenge and closure
+
+Use when a lead becomes a finding, an exploit chain is claimed, or the engagement is approaching closure. Scale the artifact to the task. A narrow answer may belong in chat; create a report file when requested or when the engagement deliverable calls for it, not as an automatic side effect of a question.
+
+## Evidence ladder
+
+Keep these levels separate:
+
+1. **Signal:** banner, scanner alert, reflection, crash, unusual response, graph edge or suspicious source pattern.
+2. **Mechanism:** the input/state reaches the responsible component and the suspected validation/authorization/state assumption fails.
+3. **Security consequence:** an attacker under the stated capabilities crosses a protected boundary or violates a security property.
+4. **Bounded impact:** the effect is independently observed and contextualized; potential broader harm is explicitly inferred or untested.
+5. **Reproducibility:** another operator can reproduce the claim under documented conditions without guessing missing prerequisites.
+
+A source-level finding can establish a real defect while remote deployment remains unverified. An interrupted exploit can establish a partial chain. Report those accurately instead of promoting them to demonstrated compromise or discarding useful evidence entirely.
+
+## Capture only what proves the claim
+
+For HTTP preserve method/URL, relevant headers, body, status, redirect chain, cookies/auth context by secure reference, raw response and actual state/callback evidence. Avoid browser-readable extraction when comments, scripts or exact headers matter. Record disabled TLS verification and how routing/virtual-host/SNI was established.
+
+For native/mobile/runtime work preserve artifact hash/build, platform, input/state, principal/process context, minimal trace/stack and observed effect. For cloud/AD preserve actual identity/session and effective policy context. For stochastic AI tests record relevant history/configuration, retrieved artifacts, exact tool calls and successes/trials.
+
+Record timestamp/timezone, environment/version, tool options, capture truncation, relevant sampling and artifact path/hash. Screenshots illustrate; raw transactions, inputs, state and traces make reproduction possible. Never fabricate missing output, exit status, privilege, callbacks or data.
+
+Use secure storage and redacted report excerpts. Do not put secrets in command arguments, public reports, reusable instructions or model context. A unique canary or metadata proof is usually preferable to real sensitive data. Respect retention and do not upload client artifacts to public sandboxes without permission.
+
+## False-positive challenge
+
+Before confirming, answer the questions relevant to this mechanism:
+
+- Is this the intended target/service/build, not a proxy, challenge, error template or stale local replica?
+- Does the attacker actually control the triggering input/state and reach the path under the reported privilege?
+- Is the claimed boundary supposed to hold, or is this an intentionally granted feature/admin power?
+- Did the valid baseline work and the negative control behave differently?
+- Could caching, shared state, redirects, reflection, test instrumentation or preexisting data explain the signal?
+- Was the security effect independently observed, not just claimed by the tool/model or inferred from a response code?
+- Do sanitization, a dominating check, a transaction, permissions, mitigation or unreachable feature defeat the path?
+- Can a fresh controlled state reproduce the effect? If nondeterministic, are the observed conditions and trial counts stated?
+- Does the conclusion depend on an unproved chain edge, unrealistic capability, unavailable role or destructive assumption?
+
+Seek the strongest counterexample, not just confirming variations. Refute the narrow mechanism when contradicted; don't relabel every failed attempt as evidence the system is secure.
+
+## Minimal safe PoC
+
+A PoC should include setup, controlled identities/objects, exact input/sequence, expected legitimate behavior, observed unauthorized behavior and cleanup. It should do only enough to demonstrate the property. Prefer one owned record, one harmless execution marker, one canary file or a read-only identity/capability check to dumping data or modifying production controls.
+
+Include negative and legitimate controls and describe external callbacks or test infrastructure. Prevent retries from multiplying state changes. Document rate/concurrency and stop conditions for stateful tests. If execution would exceed scope or allowed impact, supply the established evidence and label the remaining consequence untested rather than executing it anyway.
+
+For chains, document each edge's input capability, preconditions, action, result and proof. Show that adjacent edges are compatible. Clearly mark where a chain stops; a plausible endpoint is not a demonstrated endpoint.
+
+## Severity and classification
+
+Explain likelihood/preconditions and business/technical impact separately. Distinguish exposure, weakness, exploitability and risk. Use the engagement's requested scoring standard; if none is specified and a score is useful, use the current applicable CVSS guidance and a verified calculator rather than guessing a number.
+
+When publishing CVSS, provide version, nomenclature/metric groups, score, vector and rationale for non-obvious metrics. CVSS is owned by FIRST and used by permission. A Base score communicates intrinsic severity, not the organization's complete risk; incorporate environment and threat context separately. Do not transfer a vendor score unchanged when the demonstrated conditions differ.
+
+Use specific CWE and framework identifiers only after checking their definitions and fit. ATT&CK/ATLAS describes behavior; OWASP lists/control standards guide relevant tests; neither proves exploitability. Novel behavior may need a narrative instead of a forced identifier.
+
+Group manifestations by root cause and remediation while preserving materially different impacts. Don't inflate severity or finding count because several tools reported the same issue. Hardening opportunities and architectural trust assumptions should not be disguised as confirmed exploit findings.
+
+## Report contract
+
+For each confirmed finding provide:
+
+- Title, affected asset/interface/build and status/confidence.
+- Attacker prerequisites and violated security boundary.
+- Reproduction with minimal inputs and expected versus actual behavior.
+- Evidence references and relevant redacted excerpts.
+- Demonstrated impact, clearly separated inferred consequences and limits.
+- Severity rationale and verified classification if used.
+- Root cause, concrete remediation and verification criteria.
+- Related variants/chains, cleanup and retest status.
+
+At engagement level provide objective/scope, assessment period/vantages, tested identities and material surfaces, sampling rationale, findings, control observations, limitations, unresolved leads and next actions. A truthful negative assessment says “no issue demonstrated within these tests,” not “no vulnerabilities exist.”
+
+## Cleanup and retest
+
+Reconcile all test-created accounts/files/objects, listeners/processes, credentials/certificates, ACL/config changes, test AP/device state and external infrastructure. Remove/revoke only engagement-owned state according to the agreed procedure; preserve audit trails and evidence. Record what was actually cleaned and what an owner must still do.
+
+Retest the original case on the remediated build with comparable identity, state and vantage. Test a legitimate baseline plus relevant sibling/alternate path. Distinguish **fixed**, **partially fixed**, **still reproducible**, **not reproducible under current conditions**, and **blocked/untested**. Failure to reproduce without the original prerequisites does not prove a patch.
+
+## Final reconciliation
+
+Compare scope and objectives against the ledger: assets, services, identities, tenants, features, states, trust boundaries, versions, observed anomalies and chain edges. Every material unresolved item needs a disposition and reason. Make budget exhaustion, absent credentials/hardware, unavailable services and forbidden impact visible.
+
+Declare completion only for the stated assessment boundary and evidence. If stopped early, use an honest status such as `partial`, `blocked` or `paused_budget`, name remaining work and preserve a concrete resumption point. Never hide unfinished testing behind a polished report.

package/resources/skills/clai-superman-skill/references/identity-ad.md

@@ -0,0 +1,51 @@
+# Identity, Active Directory and enterprise trust
+
+Use for AD DS, Windows domains, hybrid identity, IdPs and federated SaaS. Separate exposure, effective permissions and demonstrated escalation. Technique prerequisites change with server updates and policy; consult current Microsoft/vendor documentation rather than assuming an old exploit still works.
+
+## Build the identity and trust graph
+
+Record domains/forests/tenants, principals and groups, nested membership, delegation, trust directions, management tiers, enrollment authorities, sync/federation paths, service identities and administrative interfaces. Label edges by who controls what, from which host, using which authentication protocol. Include local versus domain privileges and SaaS control versus data-plane permissions.
+
+Establish the current principal, logon type, token/group membership, network vantage, authentication method, domain policy and relevant builds. Clock skew, name resolution, SPNs, proxy behavior and SMB/LDAP negotiation can invalidate a test before it touches the target mechanism. Preserve that distinction.
+
+An attack-graph edge is a candidate permission relationship, not an executed path. Validate important edges against effective permissions, deny entries, inheritance, object protection, network reachability and current server behavior. Do not assume every diagrammed shortest path is feasible.
+
+## High-value families
+
+| Observed capability | Hypothesis | Discriminating validation |
+| --- | --- | --- |
+| Low-privileged authenticated domain identity | Excessive directory/object ACLs, group ownership, writable GPO or service configuration | Resolve inherited/effective rights and object scope; use a controlled reversible object change only when allowed |
+| Kerberos service accounts/delegation | Weak service credential protection, constrained/unconstrained/resource-based delegation, incorrect SPN/trust binding | Verify exact principal, flags, service reachability and policy; bounded approved ticket/credential handling, not indiscriminate collection |
+| NTLM-capable services | Relay/coercion prerequisites, missing signing/channel binding/EPA | Identify a compatible source/destination and actual enforcement; TLS alone does not prove binding; don't coerce arbitrary users |
+| AD CS enrollment/control | Subject/SAN control, template ACLs, agent/signing/EKU misuse, enrollment endpoint relay | Trace requester -> template/CA permissions -> issuance -> mapping -> accepted identity; certificate issuance alone is not domain takeover |
+| Local foothold | Privileged service/task/autorun paths, weak ACLs, credential exposure, token boundary mistakes | Show a lower-privilege principal can influence a privileged execution or access path; admin inspecting admin secrets is not escalation |
+| Hybrid identity/sync/federation | Sync account rights, app consent, federation key/control, cross-tenant trust | Establish which authority can mint/accept identities and the exact tenant/resource boundary |
+| SaaS support/admin interfaces | Delegated admin, role switching, invitation and recovery bypasses | Test principal/tenant/resource binding and revocation with controlled accounts |
+
+## Authentication is a stateful protocol
+
+For Kerberos, NTLM, LDAP, SMB, WinRM, RDP and HTTP negotiate the actual protocol and protections. A service banner or policy's intended default is not proof of enforcement. Test downgrade/fallback only within the agreed method; distinguish credential rejection, unavailable service and transport failure.
+
+For certificate services evaluate template permissions, enrollment/approval requirements, purpose restrictions, authorized signatures, certificate-to-account mapping, endpoint protection and patch-level behavior together. ESC names are research labels that evolve: verify the specific current prerequisites rather than treating every certificate template as vulnerable.
+
+For federation evaluate signature validation, issuer/audience/resource binding, destination/recipient, freshness/replay, key rollover, claim transformation and token exchange. Distinguish identity provider guarantees from the application's authorization. A valid identity token for one audience need not authorize another service.
+
+## Credentials: a capability, not a collection objective
+
+Use secure credential references; never paste hashes, tickets, passwords, certificates or recovery material into ordinary prompts and logs. Discovering a secret does not authorize using it on unrelated services. Identify owner, scope, lifetime and rotation needs without exposing the value.
+
+Establish lockout/MFA/rate limits before any credential testing. Password spraying, ticket requests, coercion, credential dumping, replication, persistence and account changes have operational consequences; do them only when needed for the authorized objective and allowed impact. Prefer a test principal or minimal capability proof over extracting the domain's secrets.
+
+A successful low-privilege login establishes only that login. “Domain admin” requires verified effective privilege under that identity; membership-like strings and graph predictions are not enough. If a benign proof satisfies the objective, further collection adds risk without evidence value.
+
+## Chain reasoning
+
+Example candidate chain: writable group edge -> enrollment right -> certificate issuance -> accepted elevated identity. For each edge record prerequisite, supporting evidence, negative control, impact and cleanup. Validate current protections between edges. Don't report the final privilege if only the first permission was observed.
+
+After a confirmed root cause, examine the policy/permission family: equivalent templates, delegated OU trees, nested groups, sibling applications, service accounts and trust relationships. Reconcile identities and management planes left untested instead of declaring the whole directory assessed from a single foothold.
+
+## Detection and cleanup
+
+For emulation, agree whether the goal is path feasibility, prevention, telemetry generation or alert/response validation. Record principal, host, time, source, technique and expected telemetry; use [security operations](security-operations.md) for the detection pipeline. An alert means neither blocked execution nor successful containment.
+
+Track every created account, certificate, group/ACL/policy modification, task, service, process, ticket and test artifact. Revoke or remove only engagement-created state using an agreed cleanup procedure; don't erase audit trails. Retest original and alternate paths after remediation with the same principal and build context.

package/resources/skills/clai-superman-skill/references/mobile-client.md

@@ -0,0 +1,52 @@
+# Android, iOS and desktop clients
+
+Use for mobile/desktop security assessments and shipped artifacts. Separate client-local guarantees from backend enforcement and analysis-environment limitations. OWASP MASVS describes controls; MASTG supplies testing procedures. Consult current platform behavior for the target OS/SDK rather than applying legacy advice unchanged.
+
+## Establish the exact artifact and environment
+
+Record package/bundle ID, version/build, artifact hash, signing identity, architecture, minimum/target SDK or OS, distribution channel and relevant entitlements/permissions. Verify which device/emulator, profile and app instance the tools address. Preserve an original copy and analyze a working copy.
+
+Map app -> OS/IPC -> local storage/key service -> network/backend -> third-party SDKs. Discover normal workflows and deep links, background services, local HTTP/IPC endpoints, extensions, notifications, update and recovery paths. Include native libraries, JavaScript bridges and WebViews. Backend APIs belong in [web and API](web-api.md), not just the mobile checklist.
+
+Use available artifact-analysis tooling when appropriate. In clai, check REA availability and enable its shipped-artifact workflow when it applies; do not make REA a hard dependency, and do not send ordinary source repositories to a binary-analysis workflow. Otherwise choose installed unpackers, disassemblers, decompilers and instrumentation suited to the artifact.
+
+## Android hypotheses
+
+| Surface | Questions that distinguish a bug | Evidence to seek |
+| --- | --- | --- |
+| Exported activities/services/receivers/providers | Can a different unprivileged app invoke sensitive behavior? Are permissions and caller identity checked at the right stage? | Controlled second-app/IPC invocation, actual permission context and consequence |
+| Intents/deep links/app links | Can URI parsing, link ownership, task behavior or nested intent forwarding cross trust? | Complete entry -> transformation -> privileged action trace on the supported OS |
+| Content/file providers and URI grants | Can caller-supplied path/URI or grant lifetime expose unintended files or objects? | Own sentinel accessed beyond intended scope; distinguish temporary grant from general access |
+| PendingIntent and callbacks | Can another party modify, replay or redirect a privileged pending operation? | Concrete creator/recipient privileges, mutability and accepted altered action |
+| WebView/JS bridges | Which origins can load, navigate and call native methods? Are messages origin/caller-bound? | Harmless untrusted content invoking a privileged bridge, not merely JavaScript enabled |
+| Storage/backup/logs/clipboard/notifications | What lower-privilege or physical attacker can obtain sensitive state? | Non-root threat-model access or explicitly labeled rooted-device scenario |
+| Keystore and local authentication | Is authentication cryptographically bound to key use and sensitive action? | Show the action succeeds under the actual attacker model, not only UI bypass |
+| Network and signing/update | Is trust validation correct? Can a less-trusted update/plugin become code? | Original release behavior and artifact trust chain, not behavior created only by analyst patching |
+
+Manifest flags, exported components and embedded strings are leads. Export can be intentional; a browser API key may be public; use of a weak primitive may protect non-security data. Trace reachability and impact before reporting.
+
+## iOS hypotheses
+
+Inspect entitlements, keychain accessibility/access groups, data protection classes, app groups/extensions, URL schemes/universal links, pasteboard/shares, WebViews/message handlers, network trust, local auth and update/signing assumptions. Check where OS-managed identity ends and app-supplied data begins.
+
+Validate access on the relevant OS, lock state and device class. A jailbroken device can observe data that the supported production attacker cannot; report that precondition explicitly. A missing resilience technique or successful hook is not automatically an exploitable vulnerability.
+
+## Desktop/Electron/Tauri and local services
+
+Map renderer/web content -> preload/bridge -> privileged main process/plugin -> OS. Inspect navigation/window creation, sandbox/context isolation, Node exposure, IPC method permissions and sender/origin binding, custom protocols, file handlers, extensions and local service authentication.
+
+For each IPC operation ask: who can call it, what input controls path/command/URL, what validation survives serialization, and whose authority executes it? Origin checks on the main window may not cover newly opened windows, custom schemes, frames or forwarded messages. Bridge exposure alone is not exploitation; show a lower-trust caller reaching a sensitive primitive.
+
+Trace updater and installer trust: signer, artifact integrity, channel selection, rollback, writable staging paths, extraction, privilege elevation and restart behavior. A TLS URL alone is not the whole update guarantee. Use controlled artifacts; never ship a malicious update to users.
+
+## Dynamic proof without confusing the threat model
+
+Observe original behavior first. Interception, pinning bypass, hooks, repackaging and debug builds can help inspect internal paths but may remove the very control being assessed. Keep analyst-created capabilities separate from attacker capabilities. Reproduce the security effect in an unmodified supported configuration, or clearly state that the conclusion is limited to the instrumented build.
+
+Use test accounts, canary files and an isolated device/profile. Avoid logging real tokens, accessing unrelated apps' data or retaining personal device captures. A finding should name package/build, OS, caller capability, trigger, observed boundary crossing, relevant logs/traces and cleanup.
+
+## Variant and regression paths
+
+After a confirmed component/bridge bug examine sibling components, equivalent methods, background paths, URI variants, secondary windows and shared libraries. Compare debug/release, upgrade/new install and supported OS differences when they change enforcement.
+
+Retest legitimate flows and the exact lower-trust caller after remediation. Mark unavailable physical devices, entitlements, hardware-backed key behavior and backend roles as gaps. Emulator success or failure does not cover all supported devices.

package/resources/skills/clai-superman-skill/references/novel-research.md

@@ -0,0 +1,97 @@
+# Research beyond known templates
+
+Use when observed behavior is unexplained, a mature system resists ordinary testing, a known issue needs variants, or the task explicitly calls for original vulnerability research. Novel research is a method for testing new hypotheses—not a promise to discover a zero-day. Age, popularity and a clean scan are not security proofs.
+
+## Start with an invariant, not an exploit name
+
+Describe the protected property in the target's own terms: identity stays bound to the action; a parser's validated object is the one later interpreted; a resource is consumed once; a lower-trust component cannot choose a privileged destination; a pointer remains valid until its last use; an upgrade cannot change who authorizes itself.
+
+List assumptions each component makes about its neighbors. Prioritize assumptions enforced by convention, duplicated differently, invalidated asynchronously or invisible to normal tests. A useful hypothesis names a reachable input/state and predicts a security-relevant deviation. “There must be a zero-day here” has no predictive value.
+
+## Discover where guarantees can diverge
+
+| Research axis | Questions and useful experiments |
+| --- | --- |
+| Representation | Can two byte strings represent the same object, or one string mean different objects to validator and consumer? Compare normalization, encoding, duplicate fields, numeric precision and serializer behavior |
+| Time | Is validation bound to execution time, resource version and identity? Reorder/replay/cancel/resume; change a controlled reference after approval; observe stale capabilities |
+| Authority | Does a helper/worker/plugin act for the caller or itself? Follow delegated identity, tenant and consent across one edge at a time |
+| Failure | What happens after timeout, partial commit, retry, parser error or unavailable verifier? Inject controlled failures in a safe replica and inspect state, not just error text |
+| Composition | Do individually correct controls disagree when combined? Compare cache key versus authorization context, router versus origin, signature bytes versus interpreted object |
+| Lifecycle | Does create/update/import/export/restore/migrate use the same enforcement? Test equivalent operations through distinct consumers |
+| Concurrency | Is a request actually atomic? Identify sub-states, shared records, transaction scope, session locks, multi-process and worker interleavings |
+| Boundary values | Empty/absent/null, zero/negative/extreme lengths, integer conversion, Unicode, recursion depth, container nesting and resource handles—only along a reachable path |
+| History | What invariant did a previous patch restore? Inspect neighboring callers, old compatibility paths, partial fixes and backports for the same missing assumption |
+| Deployment | Does the built/released/feature-flagged code differ from the reviewed source or test harness? Compare exact artifacts and runtime configuration |
+
+Choose axes from system evidence. This table is a generator of questions, not a request to spray every encoding or sequence.
+
+## Research a lead without anchoring
+
+Write two competing explanations: the security hypothesis and the strongest benign explanation. Define a test whose outcomes differ. Before investing further verify the observed component, request, build, identity and instrumentation. Promote the lead when the result improves causal confidence or reveals a new boundary—not because it is exciting.
+
+When unfamiliar, search by component/version + observed behavior + violated property. Prefer protocol/runtime documentation, vendor advisories and patches, original research, release notes and reproducible tests. Read the prerequisites and limitations, not just search snippets. Separate a technique that exists from a technique applicable to this configuration. Treat exploit repositories and sample binaries as untrusted; inspect and isolate before executing.
+
+Do not overfit to a remembered CVE. The root cause might be a product-specific state machine or a novel composition. Conversely, an unfamiliar symptom can be a known bug with different packaging. Keep novelty separate from validity and impact.
+
+## Choose the analysis engine from the question
+
+- **Manual tracing:** best when authority, workflow or a small causal path matters more than input volume.
+- **Static/dataflow analysis:** useful for scaling a known source/sink/root-cause family; validate guards and runtime dispatch.
+- **Dynamic tracing/instrumentation:** useful when wrappers, generated code, IPC, binary dispatch or timing hide the real consumer.
+- **Property/stateful testing:** useful when a compact invariant should hold over many sequences.
+- **Differential testing:** useful when two implementations, versions, platforms or parsers should agree on a defined property.
+- **Coverage-guided fuzzing:** useful when a reachable parser/state machine can be safely and repeatedly exercised.
+- **Constraint/symbolic reasoning:** useful for a bounded difficult path with explicit constraints; model errors and path explosion can dominate.
+
+Combine methods when each resolves a specific uncertainty. Running several engines without an oracle or a target model is expensive enumeration, not research.
+
+## Construct an oracle that detects the real failure
+
+An oracle answers whether the invariant failed. Examples: cross-tenant canary visibility; invalid state after a controlled transaction; sanitizer-detected out-of-bounds access; different acceptance of an authenticated object; an unauthorized tool action independently recorded.
+
+Response status, timing, coverage and crashes are proxies. Explain what each proxy can and cannot distinguish. For timing use interleaved controls and enough bounded samples to assess noise; seek a direct effect where possible. For differential behavior identify which specification/invariant says the difference is wrong. Two implementations can disagree without either being exploitable.
+
+Metamorphic relationships can supply oracles when outputs are hard to predict: a round-trip preserves the defined canonical object; irrelevant field order doesn't change authority; revoking a role doesn't expand access; a replay doesn't duplicate a one-time operation. Verify the relationship is actually promised by the target—don't report valid non-canonical behavior as a flaw.
+
+## Fuzzing that reaches useful code
+
+Use a safe harness/replica, not unconstrained production traffic. Record exact source/artifact revision, toolchain, sanitizer/instrumentation, harness, corpus, options, seed and limits.
+
+A useful harness:
+
+- Invokes the real target path with valid enough outer structure to reach interesting logic.
+- Accepts empty, malformed and large inputs without failures caused only by the harness.
+- Resets per-case state or deliberately models state sequences, including session/identity context.
+- Avoids uncontrolled network, filesystem and external process side effects; joins/cleans resources per case.
+- Is deterministic where feasible and fast enough for feedback to matter.
+- Has a known valid seed and a deliberately failing oracle/control proving the detector works.
+
+Choose mutation structure deliberately: dictionaries for magic/constants; grammar/schema-aware generation for nested formats; valid checksums/signatures for layers preceding the target; stateful action sequences for business protocols. If checks block coverage, use a dedicated analysis build to reach deeper logic but keep that altered precondition out of exploitability claims.
+
+Inspect real code/edge/state coverage, corpus diversity and time spent in the intended target. Executions per second and fuzzer uptime alone are not progress. If plateaued, inspect barriers and update seeds/harness/oracle before merely extending runtime. State which code/behaviors were never reached.
+
+## Minimize, explain, reproduce
+
+For a failure preserve the original input/state, then minimize bytes, fields, operations and timing dependencies without losing the security effect. Reproduce in a fresh process/session and the relevant unmodified build. Separate harness/monitor defects, expected rejections and environmental failures from product bugs.
+
+Produce a causal explanation: attacker-controlled input -> missing/wrong check or lifetime/state assumption -> forbidden operation -> demonstrated consequence. For memory corruption characterize the primitive and mitigations separately from speculative code execution. For logic bugs inspect persistent state independently from a success response.
+
+## Variant search from a root cause
+
+Extract the missing invariant rather than a vulnerable function's spelling. Validate a search against the known instance. Expand along distinct meaningful relationships: shared validator/sink, sibling interfaces, callers/overrides, alternate types/encodings, async paths, versions and platforms. Broaden one causal axis at a time so noise can be explained.
+
+For every candidate check attacker control, reachability, dominating guards, context and consequence. Record why a candidate is refuted or blocked. Don't count nearby code as a variant or duplicate multiple manifestations into inflated finding counts. If one root-cause fix covers them all, group them and name materially distinct impacts.
+
+Search historical fixes for incomplete coverage and semantic substitutes: a removed exact pattern may still exist through another helper or representation. Conversely, don't endlessly re-run a broad query that only generates known benign matches. Preserve the envelope and reopen only on a meaningful change.
+
+## Build only compatible chains
+
+Represent an edge with input capability, exact preconditions, action, resulting capability, evidence and side effects. To compose edges, verify that the first result actually satisfies the next prerequisites under the same identity/network/state/version context. An SSRF that only performs GET cannot automatically invoke a POST-only control plane; a credential restricted to one resource doesn't imply account-wide compromise.
+
+Use the minimum proof that resolves the objective. Discuss plausible untested consequences separately. Do not perform destructive or sensitive-data impact just to replace a safely demonstrated capability with a more dramatic screenshot.
+
+## Exit, park or continue
+
+Continue when a reachable unexplained anomaly, untested important invariant or promising new evidence offers a realistic gain. Pivot when repetitions no longer distinguish explanations, prerequisite access is absent, or another boundary has higher supported value. A well-recorded refutation is progress; sunk cost is not a reason to grind.
+
+Before a long pause preserve exact artifacts, minimized case, competing explanations, failed experiments with envelopes, research sources and one next discriminating test. State budget/runtime limits honestly. Never call a bug “zero-day” merely because a search found no match; describe it as apparently undocumented pending vendor/advisory/history checks and coordinated disclosure through the agreed process.

package/resources/skills/clai-superman-skill/references/operations.md

@@ -0,0 +1,109 @@
+# Engagement control and efficient persistence
+
+Use for substantial assessments and long investigations. Adapt the amount of state to the task. Do not create a bureaucracy before a single useful test.
+
+## Objective and system model
+
+Translate the objective into an observable outcome: demonstrate cross-tenant read/write, evaluate a control, validate a reported issue, assess material exposed boundaries, test a specified adversary path, or resolve an incident hypothesis. A red-team objective reached does not imply a full vulnerability assessment; an audit with no findings does not imply no attack path.
+
+Identify the operating constraints that change the next action: production versus clone, allowable state changes, tested identities, third parties, address ranges, egress, test window, physical access, rate/concurrency limits, account lockout, evidence retention and cleanup. Resolve scope-changing ambiguity before acting on the uncertain asset; continue independent known-in-scope work. Discovery of an address, credential, subsidiary or vendor does not itself expand authorization.
+
+Draw the smallest useful graph:
+
+`actor/capability -> entry -> transformation/decision -> privileged action -> asset`
+
+Add transport/identity/state labels to edges. Include both control and data planes: UI to API; API to queue; queue to worker; client to local service; federated identity to tenant; pod to node; Wi-Fi client to wired network. Ask which component believes which other component already checked authorization or canonicalized input.
+
+## A lightweight working ledger
+
+Reuse an engagement's existing artifacts. For multi-stage work, keep these records in an appropriate engagement directory or durable task state, not global project instructions. Store sensitive captures separately from redacted summaries. A compact Markdown table or JSONL file is enough; do not build a database unless needed.
+
+| Record | Minimum useful content |
+| --- | --- |
+| Objective | desired effect/control, proof condition, exclusions, budget |
+| Surface | stable ID, asset/interface, version/vantage, principal/role, operation/object/state, boundary, source of discovery |
+| Hypothesis | linked surface, invariant, mechanism, preconditions, confirming/refuting signal, next experiment, priority rationale |
+| Experiment | input/command, baseline/control, timestamp/timezone, tool version, context, artifact pointers, observation, interpretation |
+| Finding | attacker path, consequence, confidence, reproduction, root cause, sibling/chain links, cleanup |
+| Gap | untested boundary, reason, impact on confidence, access or experiment needed to resolve |
+
+Use dispositions precisely:
+
+- **Queued/active:** a candidate with a specific next experiment, not a vulnerability.
+- **Observed:** behavior recorded; mechanism or impact not yet established.
+- **Confirmed:** security consequence demonstrated under the recorded preconditions.
+- **Refuted for this case:** a stated mechanism contradicted by a discriminating test; not the whole vulnerability class ruled out.
+- **Parked:** currently low-yield; preserve evidence and what would make it worth reopening.
+- **Blocked:** missing access, hardware, approval, availability or another prerequisite.
+- **Not applicable:** architecture or product behavior gives a defensible reason, with evidence.
+- **Untested:** discovered but no adequate assessment yet. Never relabel this “passed.”
+
+A negative result has an envelope: build, vantage, principal, operation, representation, state and experiment. Reopen it when a material part of the envelope changes. Deduplicate by that envelope and hypothesis, not just URL or function name.
+
+## Cover the boundary, not just the inventory
+
+For each material family, consider actor/role/tenant, object ownership, operation, lifecycle state, entrypoint/protocol, representation and deployment. Select equivalence classes based on shared enforcement, not superficial naming. If REST and GraphQL share a service but authorize in separate resolvers, they are not one tested surface. If one shared middleware is verified, representative checks can support broader coverage with an explicit sampling rationale.
+
+Discovery channels complement each other:
+
+- Black box: observed traffic, linked resources, DNS/TLS, service negotiation, documentation, errors, normal workflows.
+- Authenticated: each role's routes, exports/imports, lifecycle transitions, admin/support, APIs behind the UI.
+- Artifacts/source: manifests, routes, generated clients, schemas, workers, configs, build metadata, changelogs.
+- Runtime: actual process/IPC/network/file behavior, traces, logs and policy evaluation.
+
+Reconcile differences: documented but unexposed, deployed but undocumented, UI-hidden but server-callable, main path patched but worker still vulnerable. Breadth comes from finding meaningful boundaries, not indiscriminate enumeration.
+
+## Choose the next experiment
+
+Use a qualitative comparison, not invented arithmetic:
+
+- **Impact:** Which protected asset or invariant would fail? How valuable is the next edge?
+- **Evidence:** Does observed behavior support the precondition, or is it merely imaginable?
+- **Reachability:** Can the actual attacker reach it under the engagement's identity and network conditions?
+- **Information gain:** Will the result separate competing explanations or unlock many sibling tests?
+- **Cost and risk:** How much setup, runtime, noise, state change or collateral risk is involved?
+- **Coverage debt:** Which important boundary has been neglected while a deep lead consumed attention?
+
+Prefer tests that distinguish hypotheses. Example: if an export may ignore tenant context, another injection scanner adds little. Two controlled tenants and an export created before membership revocation can distinguish per-request checks from a worker's stale authorization.
+
+Do the fast prerequisite test before an expensive exploit. Preserve promising anomalies even when temporarily blocked; do not let them trigger speculative full chains. Do not invent fixed percentages, tool-derived certainty, or priorities solely from a CVSS banner.
+
+## Escalation ladder for a promising anomaly
+
+1. Verify target, routing, session, request and artifact are the intended ones.
+2. Reproduce against baseline/control and remove accidental variables.
+3. Localize the responsible component or state transition using one changed dimension.
+4. Research implementation, patch history, protocol guarantees or source code.
+5. Build the smallest harness/PoC that observes the security invariant directly.
+6. Challenge with a benign explanation, boundary case and alternate observation channel.
+7. Establish bounded impact, then examine siblings or a supported chain.
+
+Enter wherever evidence permits. This is not a requirement to execute seven steps for every lead.
+
+## Stalls, failures and pivots
+
+| Observation | Decision-changing next move |
+| --- | --- |
+| Identical status/body across nonexistent and interesting paths | Fingerprint the catch-all before more discovery; retain meaningful size/status/redirect differences |
+| Every request is challenged | Distinguish edge/WAF response from application behavior; acquire legitimate session or approved alternate vantage |
+| PoC fails before reaching vulnerable logic | Fix prerequisite, version, feature flag, encoding or harness; record path reachability separately |
+| Same payload produces unstable timing | Interleave baseline/control, inspect queue/caching/network effects, use a direct state or callback oracle |
+| Static taint path stops at a wrapper | Trace runtime dispatch, validator order, transformations and downstream interpretation |
+| Fuzzer is busy but no meaningful coverage grows | Check harness reachability, seed validity, dictionaries, state reset and gate conditions |
+| Repeated changed inputs yield no new distinction | Park this mechanism with its envelope; advance a different unresolved boundary |
+| One finding explains many alerts | Group the root cause, verify representative variants; don't inflate counts |
+| New credential or role appears | Revalidate scope and capability, add new identity-boundary tests; don't automatically spray or dump secrets |
+
+A retry needs a new reason and a distinct predicted result. A tool installation problem is not a target vulnerability. A blocked experiment is not a failed security control. Don't route around permission denials, and don't treat removing a control in a clone as proof that production is exploitable.
+
+## Concurrency and long-running work
+
+Use only available, authorized orchestration. Delegate genuinely independent investigations with explicit surfaces and expected evidence; keep final causal verification with the owner. Do not have multiple workers duplicate scans, mutate the same state, or contaminate each other's timing/cache experiments. Schedule race tests deliberately rather than accidentally.
+
+Use clai's actual job lifecycle: long finite jobs belong to the supported durable/Responder mechanism; interactive logins need an owned terminal; servers/watchers are not finite analysis jobs. Track artifacts and read terminal results before drawing conclusions. Parallelize research or another surface while a job runs; don't poll repeatedly or relaunch a live equivalent.
+
+A checkpoint should preserve scope, versions, verified facts, working identities by secure reference, exact artifact paths, open/parked/blocked hypotheses, running job IDs, changed state and the next discriminating experiment. Resume from evidence rather than redoing the engagement. Never persist client credentials or sensitive findings in a reusable skill or public memory.
+
+## Closure decision
+
+Close the requested boundary when its proof conditions hold and material feasible work would no longer change the result. For a comprehensive assessment, this requires reconciling the surface ledger and important sibling/alternate paths—not just reaching one goal. If a budget or prerequisite prevents this, stop honestly at that limit and describe the frontier. A clean result can be valid; inventing a vulnerability to satisfy a motivational instruction cannot.

package/resources/skills/clai-superman-skill/references/security-operations.md

@@ -0,0 +1,55 @@
+# Security operations, hunting, detection and response
+
+Use when the objective is investigate, detect, contain or validate defensive controls. Do not turn a suspected active incident into an offensive exploitation exercise. NIST SP 800-61 Rev. 3 places detection, response and recovery within broader risk management; adapt to the organization's incident authority and process.
+
+## Classify the job
+
+- **Threat hunt:** test a behavior hypothesis using available evidence; success includes a well-bounded negative result and visibility gaps.
+- **Detection validation/purple team:** distinguish successful execution, telemetry, rule match, alert delivery, analyst action and containment.
+- **Incident response/forensics:** establish what happened and current risk while preserving evidence; containment may take precedence over complete observation under the incident lead's authority.
+- **Exposure/vulnerability management:** verify applicability and reachable impact; prioritize remediation, then retest actual enforcement.
+
+Confirm objective, time window/timezone, hosts/identities, data sources, retention and response authority. Recover existing incident scope rather than scanning adjacent systems by default.
+
+## Evidence before interpretation
+
+Preserve raw logs/artifacts with acquisition time, source, hash where appropriate and chain of custody. Work on copies; note time skew, ingestion delay, sampling, parser changes and collection gaps. Do not erase logs or “clean up” suspicious files before preserving evidence and receiving response direction.
+
+Build a timeline that separates event time, ingest time and analyst observation. Correlate stable identifiers: principal/session, host/process tree, request/correlation ID, source/destination, cloud resource, file hash and related transaction. An IP address alone rarely establishes actor identity.
+
+Record known facts, alternative explanations and the next discriminating query. An alert may be a true detection of benign admin/test activity; no alert may be missing telemetry rather than absent attacker behavior.
+
+## Hunting from behaviors
+
+Start with a concrete claim: a lower-tier identity requested unusual privileged access; a workload identity was used outside its normal context; an update child process performed an unexpected network action. Choose telemetry that can actually observe the behavior and explicitly state what it cannot observe.
+
+Map relevant behavior to verified current ATT&CK/ATLAS techniques, but don't let the framework suppress unmodeled activity. Query a bounded cohort/time range, inspect representative raw records and compare a legitimate baseline. Expand scope/time based on linked evidence rather than searching every index indiscriminately.
+
+Useful pivots include identity -> sessions -> devices -> processes -> network -> resources -> resulting state. Preserve causal uncertainty: a shared service account, NAT, proxy, VPN or delayed log delivery can make a superficially compelling chain false.
+
+## Detection validation as a pipeline
+
+| Stage | Evidence needed | Frequent false conclusion |
+| --- | --- | --- |
+| Execution | Actual action/outcome in the relevant security context | Tool exit zero means technique worked |
+| Sensor | Raw event with required fields/time/source | “No alert” means no event |
+| Ingestion/parsing | Event reached the correct dataset with usable fields | Local log proves SIEM visibility |
+| Rule/analytic | Exact rule version, conditions, window, match/suppression result | One matched event proves all variants covered |
+| Alert/case | Routing, severity, dedup/suppression and delivery | Rule match means analyst saw it |
+| Response | Documented analyst/control action and effective containment | An alert means the attack was blocked |
+
+Use controlled benign emulation and agreed test windows. Verify cleanup and don't disable defensive controls or erase evidence to obtain a successful demonstration. When a test fails, localize the missing pipeline stage before changing the detection rule or rerunning the attack.
+
+Test representative alternate procedures when they materially change observability: different parent/child process context, identity source, API, runtime or platform. Do not claim technique-wide coverage from a single known signature. Balance recall against legitimate baseline false positives and operational cost.
+
+## Response decisions
+
+For a live incident, state the containment decision, expected risk reduction, evidence lost, business impact and reversibility. Coordinate host isolation, session revocation, key rotation, blocking and restoration through the incident authority. Do not rotate, delete or quarantine unilaterally just because access exists.
+
+Determine initial access, executed actions, persistence, credential/token exposure, affected assets and scope of impact to the extent evidence supports them. Avoid unsupported attribution and precise dwell-time claims beyond retention. Distinguish evidence of access, collection, staging and actual exfiltration.
+
+## Remediation and recovery proof
+
+Verify the defect/control was addressed on the affected build/configuration and that compromised credentials/sessions cannot still act. Confirm legitimate business behavior and required telemetry survive the fix. Recovery is not just a service becoming reachable; validate integrity, restored trust and monitoring for recurrence.
+
+Deliver timeline, scope, confidence and alternatives, evidence references, containment/remediation actions actually taken, residual exposure, unobservable periods and next owner/actions. Use [evidence and closure](evidence-reporting.md) for concise defensible findings and retest outcomes.