showdar-skills 0.2.0

package/skills/showdar-git/examples/commit-task-only.md

@@ -0,0 +1,15 @@
+# Commit only task-owned files
+
+Given a mixed tree:
+
+```text
+M README.md
+M src/foo.js
+M AGENTS.md
+?? .agents/
+```
+
+Classify `README.md` and `src/foo.js` as `FEATURE/TASK`. Keep `AGENTS.md` and
+`.agents/` under `EXCLUDED`. Run `git add README.md src/foo.js`, inspect
+`git diff --cached --check` and `git diff --cached`, then commit only that
+staged set. Do not reset, clean, or stage the whole tree.

package/skills/showdar-git/examples/conflict-stop.md

@@ -0,0 +1,7 @@
+# Stop on an ambiguous conflict
+
+After a merge or rebase conflict, report the operation and exact conflict set.
+Read both sides, the merge base, task requirements, and relevant tests. If the
+desired semantics or ownership cannot be established, stop before choosing
+ours/theirs, aborting, or continuing. Ask for the missing decision and preserve
+the in-progress state.

package/skills/showdar-git/examples/explicit-push.md

@@ -0,0 +1,7 @@
+# Explicit push
+
+When the user explicitly requests a push, first verify the current branch,
+upstream, commit SHA, working tree, and relevant checks. Push the named branch
+to the intended remote, then verify upstream state. A normal push is distinct
+from force-push; never substitute the latter after a rebase without explicit
+authorization.

package/skills/showdar-git/examples/feature-merge-no-push.md

@@ -0,0 +1,13 @@
+# Finish a feature without push
+
+```text
+feature branch
+  -> inspect and selectively commit
+  -> switch to develop
+  -> merge with the repository's local convention
+  -> run relevant checks
+  -> verify status and history
+  -> report remote untouched
+```
+
+Do not push merely because the merge succeeded.

package/skills/showdar-git/references/operation-safety.md

@@ -0,0 +1,34 @@
+# Git operation safety
+
+| Operation | Default | Evidence required |
+| --- | --- | --- |
+| `status`, `diff`, `log`, `branch` | allowed | none; read-only |
+| selective `add` | local | path ownership is clear |
+| commit | local | cached diff and checks are correct |
+| branch switch | local | dirty paths are preserved or explicitly handled |
+| merge | local | source, target, and merge intent are clear |
+| rebase | guarded | history is unpublished or rewrite is explicitly accepted |
+| cherry-pick | guarded | commit identity and dependencies are understood |
+| pull | guarded | upstream and resulting history are understood |
+| push | explicit | user names the remote/branch or clearly requests push |
+| force-push | exceptional | explicit confirmation and published-history impact |
+| tag/release/remote deletion | out of scope by default | explicit request and separate safety review |
+| GitHub Actions/CI/CD/deploy | out of scope | separate task, never inferred from Git work |
+
+## Mixed ownership checklist
+
+1. Capture `git status --short` before staging.
+2. Read task-owned diffs and inspect untracked paths.
+3. Write a FEATURE/TASK and EXCLUDED classification.
+4. Stage explicit files, including intentional deletions.
+5. Compare `git diff --cached` with the classification.
+6. Preserve excluded work in the final report.
+
+## Conflict checklist
+
+- identify the operation and conflict paths;
+- read both sides and the merge base where needed;
+- inspect generated/lockfile conflicts separately;
+- resolve semantically, then stage only resolved paths;
+- run checks before continuing;
+- stop when the intended result is not provable.

package/skills/showdar-git/scripts/inspect-git-state.mjs

@@ -0,0 +1,53 @@
+#!/usr/bin/env node
+import { access } from 'node:fs/promises';
+import path from 'node:path';
+import { spawnSync } from 'node:child_process';
+
+const repository = path.resolve(process.argv[2] ?? process.cwd());
+
+function git(args, allowFailure = false) {
+  const result = spawnSync('git', ['-C', repository, ...args], { encoding: 'utf8' });
+  if (result.status !== 0 && !allowFailure) throw new Error((result.stderr || result.stdout).trim() || `git ${args.join(' ')} failed`);
+  return result.stdout.trim();
+}
+
+function statusEntries() {
+  const result = spawnSync('git', ['-C', repository, 'status', '--porcelain=v1', '-z'], { encoding: 'buffer' });
+  if (result.status !== 0) throw new Error((result.stderr || result.stdout).toString().trim() || 'git status failed');
+  return result.stdout.toString().split('\0').filter(Boolean).map((entry) => ({ index: entry[0], worktree: entry[1], path: entry.slice(3) }));
+}
+
+async function operationState() {
+  const gitDir = git(['rev-parse', '--git-dir']);
+  const markers = ['MERGE_HEAD', 'CHERRY_PICK_HEAD', 'REVERT_HEAD'];
+  const active = [];
+  for (const marker of markers) {
+    try { await access(path.join(gitDir, marker)); } catch { continue; }
+    active.push(marker);
+  }
+  for (const directory of ['rebase-merge', 'rebase-apply']) {
+    try { await access(path.join(gitDir, directory)); } catch { continue; }
+    active.push(directory);
+  }
+  return active;
+}
+
+const branch = git(['branch', '--show-current']);
+const upstream = git(['rev-parse', '--abbrev-ref', '--symbolic-full-name', '@{upstream}'], true);
+const divergence = upstream ? git(['rev-list', '--left-right', '--count', `HEAD...${upstream}`], true).split(/\s+/).map(Number) : [];
+const recent = git(['log', '-5', '--format=%H%x09%s'], true).split('\n').filter(Boolean).map((line) => {
+  const [sha, ...subject] = line.split('\t');
+  return { sha, subject: subject.join('\t') };
+});
+
+console.log(JSON.stringify({
+  repository,
+  branch: branch || null,
+  detached: !branch,
+  upstream: upstream || null,
+  ahead: divergence[0] ?? null,
+  behind: divergence[1] ?? null,
+  status: statusEntries(),
+  operations: await operationState(),
+  recent,
+}, null, 2));

package/skills/showdar-ops/SKILL.md

@@ -0,0 +1,160 @@
+---
+name: showdar-ops
+description: Use when inspecting or changing CI/CD, containers, environments, deployment, observability, rollback, or runtime operations.
+---
+
+# Showdar Ops
+
+## Purpose
+
+- Analyze and perform tightly scoped operational engineering across CI/CD, containers, environments, runtime configuration, deployment, observability, rollback, and release operations.
+- Preserve the boundary between read-only operational evidence, local repository configuration changes, and remote or production mutation.
+- Produce practical plans, runbooks, configuration changes, or execution reports with explicit target, authorization, verification, and rollback evidence.
+- Use `data/ops-patterns.csv` as a searchable prompt and load `references/deployment.md` for rollout or execution planning.
+
+## When to use
+
+- Inspecting existing GitHub Actions, CI/CD, Dockerfiles, compose files, package scripts, deployment manifests, health checks, or runtime topology.
+- Modifying an existing operational configuration when the user explicitly asks to fix or add it.
+- Planning or explicitly executing staging/production deployment, rollback, migration sequencing, observability, or release operations.
+- Reviewing environment separation, secrets/config boundaries, build variants, signing, TestFlight, Play Console, desktop updaters, or backend rollout behavior.
+- Creating Docker or other operational setup when the user explicitly requests that operational change.
+
+## When not to use
+
+- Do not use this for application feature implementation; use `showdar-build`.
+- Do not use this for delivery/readiness assessment; use `showdar-ship`.
+- Do not use this for local commit, branch, merge, rebase, conflict, or push workflow; use `showdar-git`.
+- Do not create CI/CD, Docker, Kubernetes, Terraform, cloud integrations, monitoring SaaS, release automation, rollback infrastructure, or secrets configuration from an unrelated request.
+- Do not infer deployment, publishing, production mutation, store submission, or infrastructure deletion from “ship”, “ready”, “release”, “fix CI”, or “prepare deploy”.
+
+## Inputs and assumptions
+
+- Prefer the exact requested operational outcome, target environment, repository instructions, existing scripts/config, deployment topology, package metadata, and fresh verification evidence.
+- In read-only analysis, inspect existing CI, Docker/compose, deployment manifests, environment files by name, package scripts, health checks, logs/metrics/tracing configuration, rollback procedures, and infrastructure-as-code without mutation.
+- Never print secret values, tokens, passwords, private keys, signing material, environment values, or production payloads; report names, locations, and safe metadata only.
+- Treat dev, staging, and production as different targets. Missing target, authorization, credentials, maintenance window, rollback, or data-impact information is an open decision.
+- Preserve existing operational conventions and application constraints. Do not choose a cloud provider or platform without supplied evidence or explicit scope.
+
+## Non-negotiable rules
+
+- Read-only operational analysis is the default and must not write files, run deployments, publish artifacts, mutate resources, or access credentials.
+- Local/repository operational changes require an explicit request naming the configuration or operational outcome; keep the diff narrow and preserve unrelated work.
+- Remote or production mutation requires explicit user intent naming the action and target, appropriate authorization, a preflight, a reversible/rollback path, and fresh verification.
+- Do not automatically create GitHub Actions, CI/CD, Docker, Kubernetes, Terraform, cloud, release, monitoring, rollback, or secrets infrastructure.
+- Do not automatically deploy, publish, submit to TestFlight/Play Console, tag, push Git, promote a release, change secrets, run destructive migrations, scale services, or delete resources.
+- Distinguish planned, locally verified, remotely executed, and externally confirmed states; showdar-ops does not claim deployment or test execution that did not occur.
+- Keep credentials outside reports and patches. Use existing secret references and document missing secret access without requesting or printing values.
+
+## Workflow
+
+### Phase 1: classify intent and target
+
+1. Classify the request as read-only analysis, local operational change, operational plan, or explicit remote/production execution.
+2. Extract the named environment, service, artifact, platform, action, authorization, and success evidence. If any execution target is missing, remain read-only.
+3. Record the current Git/worktree state and preserve unrelated user changes before local edits.
+
+### Phase 2: inspect operational state
+
+- Read existing CI/CD, Docker/compose, package scripts, environment/config names, deployment manifests, health checks, logging/metrics/tracing, migrations, and rollback docs.
+- Map build artifacts, dependencies, environments, service boundaries, readiness/liveness, signing, release channels, and failure/recovery paths.
+- Identify drift between local commands and existing operational config without changing it in analysis mode.
+
+### Phase 3: plan or change the smallest surface
+
+- For plans, state prerequisites, exact commands conceptually, sequencing, verification, failure handling, rollback, and what is intentionally not executed.
+- For explicit local changes, modify only existing or explicitly requested operational configuration; keep secrets as references and preserve repository conventions.
+- For explicit execution, present the target/action risk and preflight evidence, then execute only the authorized bounded action. Stop on target mismatch, missing approval, destructive scope, or failed preflight.
+
+### Phase 4: verify and hand off
+
+- Verify syntax, configuration references, package/build metadata, health checks, artifact identity, logs/metrics, rollout state, and rollback readiness at the relevant boundary.
+- Report exactly what ran locally, what changed remotely, what failed, and what remains external or unverified.
+- Leave production and remote state unchanged when intent is ambiguous; a plan is not an execution receipt.
+
+## Decision points
+
+- Use a read-only assessment for “inspect”, “analyze”, “what is our setup”, or an ambiguous “prepare deploy”.
+- Use a local change only when the user explicitly requests a named operational configuration change such as fixing an existing workflow, adding a health check, or creating Docker setup.
+- Use execution mode only when the user names an action and target such as “deploy this service to staging”, “publish this package”, or “submit this build to TestFlight”.
+- Treat “is this ready to release?” and “verify package readiness” as `showdar-ship`; treat operational implementation/execution as `showdar-ops`.
+- Treat local Git actions as `showdar-git`, even when the files are deployment-related; ops owns the operational change or remote action after explicit scope is established.
+- Prefer minimal/zero-downtime sequencing only when topology and workload evidence supports it; state downtime and rollback limits otherwise.
+
+## Stack detection
+
+- Node/backend: inspect Docker/container, env vars, migrations, health/readiness, rollout sequencing, logs, metrics, traces, and idempotent recovery.
+- Next.js/web: inspect build/runtime configuration, cache/CDN boundaries, environment separation, headers, asset deployment, and rollback behavior.
+- React Native/Flutter/iOS/Android: inspect build variants/flavors, version/build number, signing references, TestFlight/Play Console, staged rollout, crash monitoring, and rollback limitations without credentials or submission.
+- Docker: inspect image base/provenance, build context, lockfiles, non-root permissions, health checks, env/secret boundaries, compose dependencies, and artifact reproducibility.
+- Tauri/Electron: inspect signing, notarization, updater channels, release assets, native permissions, and platform-specific rollback limits.
+
+## Failure modes
+
+- Editing or creating CI/deployment infrastructure because a release or readiness request sounded operational.
+- Deploying to the wrong environment, assuming staging equals production, or running a destructive migration without target and rollback proof.
+- Printing secrets from `.env`, CI context, signing config, logs, or provider output while inspecting operational state.
+- Claiming a remote rollout, store submission, test, health check, or rollback succeeded from a local plan or command suggestion.
+- Adding Kubernetes/Terraform/cloud/monitoring dependencies when existing scripts or native configuration answer the request.
+- Treating a Git commit/push/merge request as deployment authorization or allowing ops to steal a Git-only task.
+
+## Stop conditions
+
+- Stop before mutation when action, target, authorization, credentials boundary, maintenance window, or rollback is missing.
+- Stop before remote execution when preflight, artifact identity, environment, health signal, or failure recovery is not provable.
+- Stop on any command that would publish, delete, promote, scale, rotate, migrate destructively, submit, tag, push, or change production without explicit intent.
+- Stop and report external verification as unavailable when provider, store, cloud, production, or monitoring access was not supplied.
+
+## Escalation conditions
+
+- Escalate production changes, destructive migrations, resource deletion, secret rotation, release promotion, store submission, signing, and irreversible rollback choices.
+- Escalate missing owner/approver, environment separation, access policy, data impact, downtime budget, recovery point, or observability signal.
+- Escalate CI token over-privilege, untrusted workflow input, compromised artifact, missing provenance, or container escape concerns to `showdar-security` for security analysis.
+- Escalate application code defects to `showdar-build` or `showdar-debug`; do not hide them inside operational configuration advice.
+
+## Verification
+
+- For read-only work, verify that the helper/report did not modify files, access the network, print secrets, or execute operational commands.
+- For local changes, run the narrowest syntax/config/package checks and inspect the final diff; do not claim remote behavior.
+- For execution, record exact target/action, preflight, artifact/version, command result, health signal, logs/metrics evidence, and rollback outcome.
+- Confirm package/runtime assets and environment references resolve without embedding credentials.
+- Separate planned, local, remote, and externally confirmed evidence. Never claim deployment or test execution that did not occur.
+
+## Output contract
+
+### Operational assessment
+
+1. Scope and intent classification
+2. Observed operational state
+3. Environment and trust boundaries
+4. Risks and gaps
+5. Recommended bounded actions
+6. Verification evidence
+7. Unverified external checks
+
+### Deployment or rollback plan
+
+State target, prerequisites, artifact, sequence, health gates, failure handling, rollback trigger, rollback steps, downtime/consistency limits, owner/approval, and the exact commands that remain unexecuted.
+
+### Explicit execution report
+
+State requested action and target, authorization boundary, preflight, exact operation performed, result, health/observability evidence, changes made, rollback status, and remaining risk. If execution did not occur, say so plainly.
+
+## Anti-patterns
+
+- “Ready” as permission to deploy, publish, promote, or mutate production.
+- Creating a complete CI/CD or cloud platform when the repository already has a narrow failing step.
+- Treating a Dockerfile, manifest, or local plan as evidence that a remote service changed.
+- Copying secret values into commands, examples, logs, snapshots, or reports.
+- Mixing application behavior, QA scenarios, delivery readiness, and operational execution into one vague checklist.
+- Adding rollback infrastructure or SaaS integrations without an explicit requirement and owner.
+
+## Example
+
+**Request:** “Prepare a staging deployment plan.”
+
+- **Mode:** read-only planning; no deployment because the request does not explicitly ask to execute it.
+- **Inspect:** existing workflow, package scripts, image/artifact source, environment names, migrations, health checks, observability, and rollback docs.
+- **Plan:** identify artifact/version, staging target, preflight, sequence, readiness gates, failure handling, rollback trigger, and commands marked unexecuted.
+- **Open decisions:** staging owner/approval, secret references, migration compatibility, downtime budget, and health signal.
+- **Boundary:** `showdar-ship` can verify readiness; `showdar-ops` performs deployment only after explicit action and target intent.

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

@@ -0,0 +1,14 @@
+{
+  "version": 1,
+  "skill": "showdar-ops",
+  "datasets": [
+    {
+      "file": "data/ops-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/deployment.md"
+    }
+  ]
+}

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

@@ -0,0 +1,12 @@
+id,category,prompt,evidence,output,risk,tags,reference,stack
+ci-analysis,ci,What does the existing CI pipeline build test package and authorize?,workflow files package scripts tokens artifacts and local commands,read-only CI map with drift risks and verification gaps,creating a new pipeline can duplicate or widen trust,"CI/CD,existing pipeline read-only",references/ci-cd.md,ci;node
+ci-maintenance,ci,Which existing CI job should be fixed and what is the smallest requested change?,failing job logs workflow context package scripts and diff,narrow local workflow change with syntax and test verification,unrelated pipeline cleanup expands operational risk,"GitHub Actions,existing CI fix,build job",references/ci-cd.md,ci;node
+container-workflow,container,What Docker or compose setup is explicitly required for this service?,Dockerfile compose build context image provenance env and health checks,container change or assessment with non-root and secret boundaries,adding an orchestration platform without need increases maintenance,"Docker,container,compose,health check",references/containers.md,docker;node
+environment-config,environment,How are dev staging and production configuration and secrets separated?,env names config loaders CI environment bindings and secret references,environment boundary map with missing owner and no secret values,configuration drift sends the wrong target or exposes credentials,"dev staging prod,environment config,secrets boundary",references/environments.md,node;nextjs
+deployment-plan,deployment,What is the bounded sequence and health gate for a staging or production rollout?,artifact identity target readiness deployment scripts migrations observability and rollback,unexecuted deployment plan with prerequisites and rollback trigger,plan language is not permission to change a remote environment,"deployment,staging,rollout,readiness",references/deployment.md,node;docker
+deployment-execution,execution,What explicit target and authorized action are required to deploy this service?,user intent environment artifact approval preflight command and health evidence,execution report separating local and remote results,wrong-target deployment causes outage or data loss,"deploy staging,explicit intent,remote mutation",references/deployment.md,node;docker
+rollback-migration,rollback,How can a migration or rollout be detected stopped and rolled back safely?,migration compatibility versioned artifacts health signals backups and recovery point,rollback runbook with downtime and consistency limits,irreversible schema changes may block rollback,"rollback,migration,zero downtime,recovery",references/rollback.md,node
+observability,observability,Which logs metrics traces and health checks prove runtime behavior after change?,health readiness liveness dashboards alerts sampling and redaction,observability gap list with evidence and owner,missing signals hide partial rollout or unhealthy instances,"logs,metrics,tracing,health checks",references/observability.md,node;docker;react-native
+mobile-release,mobile,What mobile release operations apply to signing versions channels and staged rollout?,build variants flavors signing references TestFlight Play Console crash monitoring and rollback limits,mobile release checklist without credentials or submission,store and signing actions are irreversible or externally controlled,"TestFlight,Play Console,signing,staged rollout",references/mobile-release.md,react-native;flutter;ios;android
+desktop-release,desktop,What desktop signing notarization updater and release-channel boundaries apply?,signing references notarization updater channels assets and rollback limits,desktop release plan with external steps unexecuted,unverified signing or updater changes strand installed clients,"signing,notarization,updater channels,release assets",references/desktop-release.md,tauri;electron
+ops-git-boundary,safety,Does this request change operational state or only record a local Git workflow?,requested remote action target config diff branch and commit intent,route operational changes to ops and commit/branch work to showdar-git,Git commands can be mistaken for deployment authorization,"operational change,local Git boundary,explicit target",references/deployment.md,*

package/skills/showdar-ops/examples/explicit-deployment.md

@@ -0,0 +1,5 @@
+# Explicit deployment execution
+
+**Request:** Deploy this backend to staging.
+
+Confirm the staging target, artifact/version, authorization, preflight, health gate, and rollback. State the remote operation and risk before executing the bounded command. Record the actual result and health evidence; stop on a target mismatch or failed gate. Never imply production was changed.

package/skills/showdar-ops/examples/fix-existing-ci.md

@@ -0,0 +1,5 @@
+# Fix explicitly requested CI configuration
+
+**Request:** Fix the existing GitHub Actions build job.
+
+Confirm the named workflow and smallest failure surface, inspect the error and repository command, then modify only the requested existing job. Keep credentials as references, validate YAML/script syntax, run the narrowest local check, and report that remote CI remains unverified until it runs.

package/skills/showdar-ops/examples/inspect-ci-readonly.md

@@ -0,0 +1,7 @@
+# Inspect existing CI read-only
+
+**Request:** Inspect the current GitHub Actions pipeline.
+
+Read workflow files, package scripts, runner permissions, caches, artifacts, environment names, and logs already supplied. Compare commands with local checks. Report the pipeline map, drift, risk, and missing evidence.
+
+Do not edit `.github/workflows`, create a workflow, widen token permissions, access secrets, or claim CI passed from a local inspection.

package/skills/showdar-ops/examples/rollback-plan.md

@@ -0,0 +1,5 @@
+# Rollback planning
+
+**Request:** Plan rollback for this migration.
+
+Inspect schema compatibility, artifact versions, recovery point, health signals, data consistency, downtime, and owner. Define trigger and recovery steps, call out irreversible stages, and leave execution unperformed unless the user explicitly authorizes the target action.

package/skills/showdar-ops/examples/staging-plan.md

@@ -0,0 +1,5 @@
+# Staging deployment plan without execution
+
+**Request:** Prepare a staging deployment plan.
+
+Inspect artifact identity, target config names, migrations, health checks, observability, rollout sequence, owner/approval, and rollback. List exact commands as unexecuted. Do not deploy because planning or “prepare deploy” is not execution intent.

package/skills/showdar-ops/references/ci-cd.md

@@ -0,0 +1,5 @@
+# CI/CD operations
+
+Inspect existing workflows, package scripts, runners, permissions, caches, artifacts, environment bindings, and untrusted input. Compare CI commands with local canonical commands and report drift without changing the workflow in read-only mode.
+
+For an explicit fix, make the smallest named change, keep tokens and secrets as references, validate syntax, and run the narrowest local check. Creating a new pipeline or widening permissions requires an explicit request and security review where trust boundaries change.

package/skills/showdar-ops/references/containers.md

@@ -0,0 +1,5 @@
+# Containers
+
+Inspect Dockerfile stages, base image provenance, lockfiles, build context, user permissions, ports, health checks, environment references, compose dependencies, volumes, and artifact identity.
+
+Creating Docker setup is an explicit operational change. Do not introduce Kubernetes, Terraform, cloud services, registries, or secret managers unless separately requested. Keep credentials out of images, logs, fixtures, and reports.

package/skills/showdar-ops/references/deployment.md

@@ -0,0 +1,5 @@
+# Deployment operations
+
+A deployment plan names the artifact, target environment, owner/approval, prerequisites, sequence, health gates, observability, failure handling, rollback trigger, and downtime or consistency limits. A plan is not execution.
+
+Execution requires explicit action and target intent, such as “deploy this service to staging”. Before a remote mutation, verify target, artifact, authorization, preflight, and rollback. Stop on mismatch, missing approval, destructive scope, or failed health evidence. Record remote results separately from local checks.

package/skills/showdar-ops/references/desktop-release.md

@@ -0,0 +1,3 @@
+# Desktop release operations
+
+Check signing, notarization, updater channels, release assets, supported platforms, install/upgrade behavior, and rollback limits for Tauri or Electron. Keep certificates and signing credentials external and report provider or notarization results only when actually observed.

package/skills/showdar-ops/references/environments.md

@@ -0,0 +1,5 @@
+# Environments and configuration
+
+Treat development, staging, and production as separate targets. Map config loaders, environment names, CI bindings, secret references, feature flags, artifact versions, and access owners.
+
+Do not copy values between environments or request credentials. A safe report can name a missing variable, reference, or owner while keeping its value redacted. Flag drift and target ambiguity before mutation.

package/skills/showdar-ops/references/mobile-release.md

@@ -0,0 +1,3 @@
+# Mobile release operations
+
+Check build variants/flavors, version and build number, signing references, TestFlight or Play Console channel, staged rollout, crash monitoring, and rollback limitations. Store submission and signing are external actions requiring explicit intent; local readiness does not prove store acceptance.

package/skills/showdar-ops/references/observability.md

@@ -0,0 +1,5 @@
+# Observability
+
+Use logs, metrics, traces, readiness/liveness/health checks, alerts, and dashboards only as evidence for the requested runtime decision. Verify useful identifiers, redaction, sampling, retention, and correlation without printing payloads or credentials.
+
+For a rollout, define the signal, threshold from supplied policy, observation window, owner, and rollback action. Missing telemetry is a gap, not evidence that the service is healthy.

package/skills/showdar-ops/references/rollback.md

@@ -0,0 +1,5 @@
+# Rollback and migrations
+
+Check whether the artifact, schema, data, and configuration are backward compatible. Define a rollback trigger from health or business evidence, the last safe version, recovery point, data consistency behavior, and owner.
+
+Destructive or irreversible migrations require explicit approval and a tested recovery path. If rollback is impossible after a schema step, say so and plan expand/contract or forward-fix evidence rather than promising zero downtime.

package/skills/showdar-ops/scripts/inspect-ops-state.mjs

@@ -0,0 +1,54 @@
+#!/usr/bin/env node
+import { readdir, readFile, stat } from 'node:fs/promises';
+import path from 'node:path';
+
+const root = path.resolve(process.argv[2] ?? process.cwd());
+
+function add(groups, group, relative) {
+  groups[group].push(relative || '.');
+}
+
+function classify(relative, groups) {
+  const name = path.basename(relative).toLowerCase();
+  const normalized = relative.toLowerCase().replaceAll(path.sep, '/');
+  if (normalized.includes('.github/workflows/') || /(^|\/)(\.gitlab-ci\.yml|jenkinsfile|buildkite\.ya?ml)$/.test(normalized)) add(groups, 'ciFiles', relative);
+  if (/^(dockerfile|dockerfile\..*|compose\.ya?ml|docker-compose\.ya?ml)$/.test(name) || name.includes('compose')) add(groups, 'containerFiles', relative);
+  if (/(deploy|k8s|kubernetes|helm|rollout|migration)/.test(name) || /(^|\/)(manifests|charts)(\/|$)/.test(normalized)) add(groups, 'deploymentFiles', relative);
+  if (/^\.env(?:\.|$)/.test(name) || /(config|environment|settings)/.test(name)) add(groups, 'environmentFiles', relative);
+  if (/(health|readiness|liveness|probe|status)/.test(name)) add(groups, 'healthCheckFiles', relative);
+}
+
+async function walk(directory, relative = '', depth = 0, groups = {
+  ciFiles: [], containerFiles: [], deploymentFiles: [], environmentFiles: [], healthCheckFiles: [],
+}) {
+  if (depth > 4) return groups;
+  let entries = [];
+  try { entries = await readdir(directory, { withFileTypes: true }); } catch { return groups; }
+  entries.sort((a, b) => a.name.localeCompare(b.name));
+  for (const entry of entries) {
+    if (entry.name === 'node_modules' || entry.name === '.git') continue;
+    const childRelative = relative ? path.join(relative, entry.name) : entry.name;
+    const child = path.join(directory, entry.name);
+    if (entry.isDirectory()) await walk(child, childRelative, depth + 1, groups);
+    else classify(childRelative, groups);
+  }
+  return groups;
+}
+
+try {
+  const info = await stat(root);
+  if (!info.isDirectory()) throw new Error('target must be a directory');
+  const groups = await walk(root);
+  let packageScripts = [];
+  try {
+    const packageJson = JSON.parse(await readFile(path.join(root, 'package.json'), 'utf8'));
+    packageScripts = Object.keys(packageJson.scripts ?? {}).sort();
+  } catch {
+    packageScripts = [];
+  }
+  for (const values of Object.values(groups)) values.sort();
+  console.log(JSON.stringify({ root, ...groups, packageScripts }, null, 2));
+} catch (error) {
+  console.error(`inspect-ops-state: ${error.message}`);
+  process.exitCode = 1;
+}