openclaw-workspace

Structured PR review — security scan, correctness, consistency, style. Covers diff analysis, comment posting via gh, and priority-based finding reports. Use when: A PR needs review, someone asks for code feedback, or changes need security/correctness validation before merge. Also use for pre-commit review of your own changes. Don't use when: The issue is a runtime pod failure (use pod-troubleshooting), a Flux reconciliation error (use flux-debugging), or a CI build failure (use ci-diagnosis). Don't use for architecture-level design discussions (use architecture-design instead). Outputs: Review comment posted on the PR via `gh pr review`, or a structured findings report grouped by severity (Critical/High/Medium/Low).

Spec-driven development workflow — proposals, requirements, design docs, task breakdowns, and implementation using the OpenSpec framework. Use when: Starting a new feature or change that needs planning, someone says "I want to build X", creating proposals or specs, breaking down requirements into tasks, or transitioning from planning to implementation. Don't use when: Debugging or troubleshooting (use appropriate troubleshooting skill). Don't use for Kubernetes manifest changes (use pr-workflow). Don't use for reviewing existing code (use code-review). Outputs: OpenSpec change folder with proposal.md, specs/, design.md, and tasks.md. Implementation follows directly from tasks.md.

Analyze agent sessions for tool failures, retry patterns, knowledge gaps, context limits, and config drift. Use when: Running periodic session reviews (cron), investigating agent reliability issues, looking for recurring failure patterns, or identifying workspace improvements from real usage. This is the primary skill for Robert's review cron job. Don't use when: You're making changes to fix issues (use workspace-improvement for that). Don't use for live debugging of a current issue (use the appropriate troubleshooting skill). Don't use for code review of PRs (use code-review). Outputs: Session analysis report with categorized findings (tool failures, retries, knowledge gaps, config drift), severity ratings, and proposed fixes. Written to /tmp/outputs/session-review.md for handoff.

OpenClaw pod architecture, volumes, networking, secrets, and provider configuration reference. Use when: Debugging container, mount, networking, or credential issues. Also use when you need to understand pod structure, check which providers are configured, verify volume mounts, or inspect secrets configuration. Don't use when: Debugging pod crashes (use pod-troubleshooting). Don't use for Flux issues (use flux-debugging). Don't use for deploying changes (use gitops-deploy). This is a reference skill, not a diagnostic workflow. Outputs: Architecture reference information. No artifacts — this skill provides context for other skills to use.

End-to-end deployment workflow — commit, CI, Flux reconcile, pod restart, verify. Includes ConfigMap changes, Flux postBuild escaping, and SOPS secret management. Use when: You need to deploy changes to the OpenClaw pod — config updates, workspace changes, image rebuilds, or secret rotations. Also use when someone asks "how do I deploy this?" or "push this change live." Don't use when: You're debugging why a deployment failed (use flux-debugging or pod-troubleshooting). Don't use for changes to kubernetes-manifests repo (Dyson's pr-workflow handles that). Don't use for registry/image inspection (use zot-registry). Outputs: Deployed changes verified in the running pod. Confirmation includes CI status, Flux reconciliation state, pod status, and startup logs.

Look up OpenClaw documentation via web_fetch for config validation and verification. Use when: You need to verify a config key, understand OpenClaw configuration options, or check documentation for Kubernetes-specific settings before making changes. Don't use when: The answer is already in CONFIG.md, AGENTS.md, TOOLS.md in your workspace.

Reference for how secrets flow from SOPS-encrypted files in Git through Flux postBuild substitution into Kubernetes Secrets and Pods. Use when: Debugging why a pod can't read a credential, tracing where a secret value comes from, adding a new secret to the pipeline, or understanding the substitution chain (Git → Flux → Secret → Pod). Don't use when: The pod is crashing for non-credential reasons (use pod-troubleshooting). Don't use for Flux reconciliation failures (use flux-debugging). Don't use for OpenClaw-specific config escaping (use config-audit — that covers the $${VAR} pattern). Don't use for CI/CD pipeline issues (use ci-diagnosis). Outputs: Architecture reference. No artifacts — provides context for debugging credential issues across the kubernetes-manifests repo.

Full multi-cluster health assessment across all 3 Kubernetes clusters. Use when: Running periodic health checks, investigating cross-cluster issues, or someone asks "how are the clusters doing?" Covers nodes, pods, Ceph, Flux, certs, alerts, and resource utilization. Don't use when: Debugging a specific pod failure (use pod-troubleshooting). Don't use for Flux-specific reconciliation errors (use flux-ops). Don't use for Ceph-specific deep dives (use storage-ops). Don't use for a single cluster's issue — this skill scans ALL clusters. Outputs: Structured health report covering all 3 clusters with issues flagged and severity noted.

Diagnose and manage Flux CD across all 3 clusters (Ottawa, Robbinsdale, StPetersburg). Multi-cluster Flux management including source health, kustomization status, HelmRelease debugging, and reconciliation operations. Use when: You need to check or fix Flux across multiple clusters, diagnose cross-cluster Flux issues, force reconcile across all clusters, or manage suspended resources. This is the multi-cluster Flux skill. Don't use when: Debugging Flux for the OpenClaw namespace specifically (main agent's flux-debugging skill handles that). Don't use for pod-level issues after Flux applies successfully (use pod-troubleshooting). Don't use for making code/manifest changes (use pr-workflow). Outputs: Flux status report across all clusters, or targeted diagnosis of a specific Flux failure with remediation commands.

Clone kubernetes-manifests, branch, fix, validate, and open a PR. Use when: You've identified an issue in the kubernetes-manifests repo that needs fixing — resource limits, HelmRelease values, Flux kustomization config, namespace labels, or any manifest change. This is the standard workflow for making changes via pull request. Don't use when: The change is in openclaw-workspace repo (that's a direct push to main, not a PR to kubernetes-manifests). Don't use for diagnosing issues (use cluster-health, flux-ops, or storage-ops first, then come here to fix). Don't use when you're unsure what to change — diagnose first. Outputs: A pull request on rajsinghtech/kubernetes-manifests with validated changes, conventional commit message, and descriptive PR body.

Rook-Ceph diagnostics (Ottawa + Robbinsdale) and storage troubleshooting for all clusters including local-path on StPetersburg. Use when: Ceph health is not OK, PVCs are stuck in Pending, OSD is down, pools are near full, or volume attachment errors occur. Also use for routine storage capacity monitoring. Don't use when: The issue is a pod crash unrelated to storage (use pod-troubleshooting). Don't use for Flux reconciliation errors (use flux-ops). Don't use for image pull failures (use zot-registry). Don't use for general cluster health (use cluster-health — it includes a storage summary). Outputs: Storage health diagnosis with specific Ceph status, OSD state, pool capacity, and PVC status. Remediation steps for identified issues.

Systematic debugging — reproduce, isolate, trace root cause, verify fix. Covers code path tracing, log analysis, binary search for regressions, and hypothesis-driven debugging. Use when: Something is broken and you need to find the root cause in code or configuration. The error is in application logic, a regression was introduced, or behavior doesn't match expectations. Don't use when: The issue is a pod not starting or crashing (use pod-troubleshooting), a Flux reconciliation failure (use flux-debugging), a CI pipeline failure (use ci-diagnosis), or a Ceph/storage issue (use storage-ops). Don't use for code review of proposed changes (use code-review). Outputs: Root cause analysis with specific file:line references, a proposed fix, and verification steps to confirm the fix works.

Diagnose Flux CD reconciliation failures — stale revisions, failed applies, dependency errors, SOPS decrypt failures. Use when: A kustomization is not Ready, source shows an old commit, Flux events show errors, or changes pushed to git aren't being applied to the cluster. Don't use when: The pod is crashing after Flux successfully applied (use pod-troubleshooting). Don't use for CI build failures (use ci-diagnosis). Don't use for registry/image issues (use zot-registry). Don't use for deploying new changes step-by-step (use gitops-deploy). Outputs: Identified root cause of Flux reconciliation failure with specific remediation commands.

Context hygiene, memory flush before compaction, sub-agent lifecycle, and daily operations patterns. Use when: Context is growing large and you need to prepare for compaction, switching between unrelated tasks, or establishing a daily operations routine. Also use when spawning sub-agents for long tasks. Don't use when: Debugging a specific issue (use the appropriate troubleshooting skill). Don't use for deploying changes (use gitops-deploy). This is an internal operations pattern, not a diagnostic tool. Outputs: No external artifacts. This skill guides internal behavior — writing to workspace files, spawning sub-agents, and managing context.

Debug pod crashes, CrashLoopBackOff, ImagePullBackOff, OOMKilled, init container errors, and EBUSY config failures. Use when: Pods are not Running, containers are restarting, init containers fail, or the pod is Running but the application inside isn't working. Don't use when: Flux reconciliation is the problem (use flux-debugging). Don't use for registry-level image issues (use zot-registry). Don't use for Ceph/storage failures (use storage-ops). Don't use for deploying changes (use gitops-deploy). Outputs: Diagnosis of why the pod is unhealthy, with specific cause identified and remediation steps.

Cross-reference workspace docs against live deployment — container names, volume mounts, model providers, agent list, skill directories. Includes PR creation workflow with validation and deduplication. Use when: You have findings from session-review that need to be fixed, workspace docs may be stale, or you need to verify workspace accuracy against the live cluster. Also use after a deployment change to ensure docs stay in sync. Don't use when: You haven't done a session review yet (do that first with session-review). Don't use for live debugging (use the appropriate troubleshooting skill). Don't use for changes to kubernetes-manifests repo (Dyson's pr-workflow handles that). Outputs: Pull request(s) on rajsinghtech/openclaw-workspace with validated fixes to workspace docs, skills, or config. Max 2 PRs per run.

Look up OpenClaw documentation via web_fetch — config reference, agent runtime, skills, cron, providers, sessions. Use when: You need to verify a config key, understand an OpenClaw feature, or look up documentation before making changes. Always use before changing config keys you're unsure about or when encountering unknown features. Don't use when: The answer is already in your workspace files (AGENTS.md, TOOLS.md, MEMORY.md, or skill files). Don't use for Kubernetes docs (use kubectl --help or official k8s docs). Don't use for general web searches (use web_search instead). Outputs: Documentation content fetched via web_fetch. No persistent artifacts — the information is used in-context.

Evaluate system design, recommend refactors, review boundaries and coupling. Use when: Evaluating a new feature design before implementation, choosing between implementation approaches, reviewing component boundaries, or creating architectural decision records. Also use when refactoring existing code for maintainability. Don't use when: Reviewing a specific PR's code changes (use code-review). Don't use for debugging runtime failures (use debug-troubleshooting). Don't use for Kubernetes manifest or infrastructure design (use the appropriate ops skill). Don't use for writing tests (use testing-strategies). Outputs: Architecture analysis document with current state assessment, recommendations with tradeoffs, and incremental migration steps.

Identify missing test coverage, design test cases, recommend test strategies. Covers unit, integration, and end-to-end testing patterns with coverage gap analysis. Use when: You need to identify missing test coverage, design test cases for new or existing code, choose a testing approach, or validate that a fix includes proper tests. Don't use when: Reviewing code for correctness/security (use code-review). Don't use for debugging failures (use debug-troubleshooting). Don't use for validating Kubernetes manifests (use manifest-lint). Don't use for architecture discussions (use architecture-design). Outputs: Test coverage gap analysis, test case designs with expected behavior, or testing strategy recommendations.

OCI registry operations — image inspection, push troubleshooting, multi-arch manifests, pull secret verification. Use when: You need to inspect images in the registry, troubleshoot "manifest invalid" errors, debug ImagePullBackOff caused by registry issues, verify pull secrets, or check if a new image was pushed after CI. Don't use when: The pod is crashing for non-image reasons (use pod-troubleshooting). Don't use for Flux reconciliation failures (use flux-debugging). Don't use for CI build failures before the push step (use ci-diagnosis). Don't use for deploying changes end-to-end (use gitops-deploy). Outputs: Image manifest details, tag listings, digest verification, pull secret validation results, or push troubleshooting diagnosis.

Diagnose GitHub Actions workflow failures — build errors, skopeo push failures, crane manifest issues, workspace build problems. Use when: A CI workflow run failed, images aren't updating after a push, or someone asks "why did the build fail?" Covers both build-openclaw.yaml and build-workspace.yaml pipelines. Don't use when: The pod is crashing after a successful CI run (use pod-troubleshooting). Don't use for Flux reconciliation issues (use flux-debugging). Don't use for registry inspection when CI succeeded (use zot-registry). Don't use for code-level bugs (use debug-troubleshooting). Outputs: Root cause of CI failure with specific step, error message, and fix recommendation.

Validate openclaw.json and related config files — JSON syntax, model references, env var escaping, agent configuration, and known bad patterns. Use when: Config was recently edited, a new provider or agent was added, the pod crashes on startup with config errors, or you want to verify config correctness before deploying. Don't use when: The config is fine and a pod is crashing for other reasons (use pod-troubleshooting). Don't use for kustomize/manifest validation (use manifest-lint). Don't use for Flux-specific issues (use flux-debugging). Don't use for runtime behavior bugs (use debug-troubleshooting). Outputs: List of config issues found (if any), categorized by severity, with specific line references and fix suggestions.

Validate kustomize build, cross-reference resources, check container names, volume mounts, and ConfigMap generators. Use when: Any file in kustomization/ was edited and needs validation before deploying. Also use for periodic manifest hygiene checks or when kustomize build is failing. Don't use when: Validating only openclaw.json content (use config-audit). Don't use for Flux reconciliation debugging (use flux-debugging). Don't use for CI pipeline failures (use ci-diagnosis). Don't use for pod runtime issues (use pod-troubleshooting). Outputs: Pass/fail validation result with specific errors identified, including file and line references for each issue found.