knowtis-app: Skill for Claude Code

.agents/skills/deploying/SKILL.md

deploying is a skill for Claude Code, Codex from jovandyaz/knowtis-app. It costs 103 tokens per session (1,534 once invoked), scanned A, original, MIT.

A set of instructions for checking and deploying the Knowtis application through GitHub Actions, Vercel, and Railway. It explains which checks and deployment jobs are involved after code changes.

In plain words
What is it for?
Running pre-deployment checks, reproducing CI, diagnosing failed or stuck deployments, checking deployment status, and configuring deployment environments.
Why use it?
It helps identify which part of the application changed, why a deployment did or did not start, and whether a deployment really finished successfully.

Skill for Claude CodeCodex

Written for no agent in particular: nothing here depends on one. Also seen: installed under .agents/ (shared by several agents).

This is jovandyaz/knowtis-app's own configuration. It tells Claude Code and Codex how to work on knowtis-app itself, so it is not a mod to install elsewhere. Copy it as a starting point and replace the rules that are about this project. Everything knowtis-app configures →

Reuse

Borrowing it

Nothing to install: this file belongs to jovandyaz/knowtis-app. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.

Copy the file
curl -O https://raw.githubusercontent.com/jovandyaz/knowtis-app/main/.agents/skills/deploying/SKILL.md
Clone the repo
git clone --depth 1 https://github.com/jovandyaz/knowtis-app

Made for: Claude Code, Codex.

Wrote this? Show the measurements

A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.

agentmods badge for deploying

README.md
[![agentmods](https://agentmods.dev/badge/skills/jovandyaz/knowtis-app/deploying/github.svg)](https://agentmods.dev/skills/jovandyaz/knowtis-app/deploying)
Your own site
<a href="https://agentmods.dev/skills/jovandyaz/knowtis-app/deploying"><img src="https://agentmods.dev/badge/skills/jovandyaz/knowtis-app/deploying/github.svg" alt="Measured on agentmods" height="20"></a>

Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.

agentmods 80×15 button for deploying

Your own site · 80×15
<a href="https://agentmods.dev/skills/jovandyaz/knowtis-app/deploying"><img src="https://agentmods.dev/badge/skills/jovandyaz/knowtis-app/deploying.svg" alt="Reviewed on agentmods" width="80" height="20"></a>
Per session 103 Skills are progressive disclosure: only the name and description are preloaded; the body loads when the skill is used.
When invoked 1,534 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. A grade says what 26 rules found in the file — not that it is safe.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5.1 $0.00103 $0.01534
Opus 5.5 $0.00041 $0.00614
Sonnet 5.5 $0.00021 $0.00307
Haiku 4.5 $0.00010 $0.00153

Measured 1mo ago against content hash 1e79b3fa1a44, method: parsed. Prices are Anthropic first-party input rates as of 2026-10-07, from the pricing page.

Security

Grade A, and why

deploying scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 1mo ago.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

.agents/skills/deploying/SKILL.md · 78 lines

How it starts

The opening of the file, as written. The whole thing — 78 lines — stays where its author put it; the contents beside it link to each section on GitHub.

Diagnosing CI and deploying Knowtis

All deploy targets are CI-driven from GitHub Actions. Neither Vercel's nor Railway's Git integrations are active. Use references/ci-pipeline.md for affected checks and references/deployment.md for runtime topology and configuration.

Mental model

push to main → affected lint/typecheck/test/build + migration drift check
   ├─ notes affected      → Vercel notes project
   ├─ backoffice affected → Vercel backoffice project
   ├─ api affected        → railway-deploy.sh (waits for terminal status)
   └─ mcp affected        → railway-deploy.sh (if RAILWAY_MCP_SERVICE_ID is set)

The facts that resolve most deploy confusion

  1. Vercel never deploys directly from a push — Git deployments are disabled. Check the affected app and its corresponding deploy-frontend or deploy-backoffice job.
  2. railway up uploads the snapshot, then Railway can skip its build via watchPatterns. Explicit railway up --ci exits 0 when build logs say “No changed files matched patterns”; a detached deployment may later become SKIPPED, observable by polling its exact ID. Compare that state with the Nx affected set and never report it as a successful deployment. The API patterns currently omit packages/**, so package-only transitive changes require particular scrutiny.
  3. Production migrations run in Railway's release phase. CI applies migrations only to its test database and separately checks generated migration drift.
  4. CLI return is not sufficient evidence in agent automation. A non-TTY invocation can return after upload, explicit --ci has a watch-pattern early-success path, and --detach only queues work. Use railway up --detach --json, capture that exact deployment ID, and poll it to SUCCESS; a healthy endpoint alone may still be the previous deployment.
  5. Healthcheck gates differ by service: API uses /api/v1/health/ping with 120 seconds; MCP uses /health with 60 seconds. Check the matching service configuration when a build succeeds but never becomes live.
  6. Manual escape hatch: direct Railway deploys bypass CI and are for explicit emergencies only. Prefer the repository's gated deploy script; otherwise use railway up --detach --json, poll the returned deployment ID to SUCCESS, then verify the service health endpoint before reporting completion.

Read the full file on GitHub · 78 lines

Files

What ships with it

4 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. 1mo ago First seen · 78 lines · 103 tokens per session scan A 1e79b3fa1a44

Subscribe to this mod's changes

deploying is a skill published in the GitHub repository jovandyaz/knowtis-app (4 stars, last pushed yesterday), licensed MIT. It adds 103 tokens to every session and 1,534 once invoked, about $0.0004 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.

Related

Other skills, from other repositories

azure-deployment-operations

Production deployment patterns for Azure Static Web Apps, Container Apps, App Service, and infrastructure.

fabioc-aloha/Alex_Skill_Mall · 23 tokens

mirrord-prev-env

Help users create and manage mirrord preview environments — running a modified service as an isolated pod in a shared Kubernetes cluster, scoped by an environment key and HTTP/queue traffic filtering, so teams can validate and review changes against real traffic without affecting live services. Use when a developer…

metalbear-co/mirrord · 122 tokens

mirrord-chaos

Help users chaos test their app with mirrord: inject artificial latency or connection errors into a mirrord session's outgoing traffic via per-session chaos rules managed with the mirrord chaos CLI. Use when a user wants to add latency or delay to outgoing connections or a dependency (e.g. a slow database), simulate…

metalbear-co/mirrord · 119 tokens

atmos-hooks

Atmos hooks: lifecycle events, hook kinds, command/store/git/security hooks, step/steps hooks, when: conditions, scoping and overrides, toolchain integration, --skip-hooks, and Atmos Pro/local output.

cloudposse/atmos · 46 tokens

atmos-modernization

Atmos Modernization: migrate deprecated or legacy Atmos patterns to current names, Native CI, Atmos Pro drift detection, dependencies.components, nametemplate, and declared secrets.

cloudposse/atmos · 36 tokens

atmos-sbom

Atmos SBOM provenance: CycloneDX and SPDX generation from vendor and Terraform evidence, coverage diagnostics, NTIA validation, and native CI workflow-artifact publication.

cloudposse/atmos · 36 tokens