Claude Skills by kitchen-engineer42

Bundle a finished John workspace from Codex. Use when the user wants to archive, package, hand off, or preserve a John project, or wants the Claude command equivalent of /john:archive.

Generate John's process scorecard, auditor manifests, and shareable run report from a Codex project using John's provider-neutral scripts. Use when the user asks for a John report, run report, scorecard, provenance manifest, self-evaluation manifest, or evidence for template evolution while working in Codex.

Activate a Hamster-built or otherwise applied John template for Codex in the current project. Use when a merged template plugin already exists, when the user asks to use a John template in Codex, or after template apply has produced a Claude `--plugin-dir` path and Codex needs the same overrides, additions, guidance, and agents.

Execute John's high-volume vertical phases with native Codex subagents over the durable `.john/runs` and event contracts. Use for per-chunk extraction, coverage, grounding, per-entry generation, large uniform fan-out, retries, reconciliation, cancellation, or whenever shared John guidance mentions Claude dynamic workflows but the active provider is Codex.

Set, show, or clear the long-running John goal from Codex. Use when the user wants endurance mode, a persistent project finish line, or the Claude command equivalent of /john:endurance.

Scaffold a John workspace in the current project from Codex. Use when the user wants to start using John, initialize a John project, import input materials into .john/input, or run the Claude command equivalent of /john:init.

When a produced app accepts an input and runs an expensive generation job the end-user waits on — upload → queued → staged generation → progress → download — build the job runtime instead of letting the job live and die inside one HTTP request. Use this skill whenever a produced app has generation taking more than a few seconds, a progress bar, a job queue, an upload-then-download flow, cancellation, or anything an end-user might refresh the page during. Triggers on "background job", "task qu...

Evolve the skills that do the work — capture lessons at phase boundaries into .john/lessons/, draft project-local skill overrides when guidance fights reality, and train workerLLM skills with a scored, gated edit loop when the domain has a scorer. Use this skill at every phase boundary ("what did this phase teach us?"), whenever worker output quality disappoints, when the user says "improve/optimize/train this skill or prompt", when a template ships a scorer or eval set, or when you notice a ...

Show John workspace status from Codex. Use when the user asks what is done, where the John project is, what phase is current, what inputs or events exist, or wants the Claude command equivalent of /john:status.

Design the runtime structure and production pipeline for the produced app — the 2app analog of [[schema-design]]. Use this skill whenever the 2skills half is complete (or nearly so), when the user mentions building the app / runtime / UX / production / deploy, when the four-structures section of PLAN.md needs its runtime + pipeline rows settled, or when [[ralph-loop]] advances out of packaging into 2app. The shape of the produced app gets decided here; downstream phases follow.

Break parsed markdown into a tree of progressively-disclosed chunks for downstream extraction. Use this skill whenever a phase needs to work on per-chunk units, when the user mentions chunking or splitting documents, or when transitioning from parsing to extraction — make sure to chunk before extraction unless the user has explicitly OK'd skipping it. Handles both onion-peeler (one long doc → tree) and onion-wrapper (many short files → assembled tree).

Apply deterministic quality checks to the code John produces — catch the 80% of issues (leaked API keys, hardcoded prod URLs, broken imports, missing dependencies, infinite spinners, dead error states, debug logs in production) without invoking the LLM at all; only fall back to LLM-driven repair for the residual edge cases. Use this skill whenever you're about to ship produced-app code, after a build phase completes, when the user mentions code quality / security review / production readiness...

How to survive long-running John sessions where the work spans hours or days. Pin the endurance goal, offload large tool results, use sub-agent firewalls, compact at phase boundaries, and accept graceful degradation to fresh sessions.

The append-only event log + deterministic reducer pattern John uses to coordinate parallel subagent work on shared state. Each subagent emits its own event files; one reducer folds all events into canonical state. Beats file locks, scales to thousands of work units.

Sweep chunks for entries that match the project's schema and emit them via the event log. Use whenever the chunk phase has produced chunks and the extract phase is next, when the user says "extract X from the corpus," or when [[ralph-loop]] advances into the extraction phase. Subagent fan-out is the norm; each subagent processes one chunk; canonical state lives in the reducer's output.

Turn the raw event-log entries from extraction into clean, cross-linked, deduplicated knowledge ready for packaging. Use after the extract phase has produced events and canonical state, when the user mentions rewriting or polishing, or when [[ralph-loop]] advances into the rewrite phase. Header+body progressive disclosure, two-tier dedup, and cross-link enrichment are the three jobs.

Emit the cleaned, cross-linked, deduplicated knowledge from the rewrite phase as Claude Code skills at `<project>/.claude/skills/`. Use this skill whenever the 2skills half wraps, when the user says "package the skills" / "ship the knowledge" / "finalize 2skills" / "we're ready for 2app," or when [[ralph-loop]] signals packaging is next. Make sure to invoke this skill before the 2app phases run — 2app reads the produced skills as its starting context. This is the deliverable boundary between ...

Turn raw input materials (PDFs, DOCX, mixed docs) into structured markdown for the rest of John's pipeline. Use whenever the user's `<project>/.john/input/` has unparsed files, when a phase needs to read source documents, or when the user mentions parsing/OCR/ingestion. Routes between `ppx_parse.py` (PDFs, layout-aware) and `markitdown_parse.py` (everything else); fails loud with install hints when dependencies are missing.

How to decide what phases this project actually needs, when you're sketching PLAN.md or revising it mid-flight. Use this skill whenever you need to design, evaluate, or revise phases for a John project — phases are John's horizontal axis, suggestions not enforcements, and getting them right is what makes ralph-loop work.

How to write the initial PLAN.md at the start of a John project. Use this skill whenever the user has just run /john:init, when there is no PLAN.md yet, or when the user says "let's start a new project" / "design the plan" / "what should we build." PLAN.md is the durable contract that spans 2skills knowledge engineering and 2app app building in ONE session — get it right at the top or every phase pays for it.

Keep PLAN.md current as work proceeds — subdivide a phase that turned out bigger, merge phases whose work is coupled, drop a phase whose intent no longer applies, insert one you didn't anticipate, mark TBD phases as concrete once decisions land, manage the append-only Log + Open Decisions + Subagent matrix. Use this skill whenever a phase advances, when the corpus surprises you, when the user changes their mind, when [[ralph-loop]] step 5 ("update PLAN.md") fires — this is what runs at that s...

When the produced app needs to authenticate users via the team's SSO system, use this skill. Triggers whenever the user mentions "auth", "login", "SSO", "session", "permissions", "Bearer token", "who's logged in", or designs any feature that depends on user identity. Teaches the standard team pattern (sso-client.js + Bearer token verify); does NOT ship the auth backend (the platform already runs it).

When the produced app performs priced operations (LLM calls, image generation, document parsing, PDF conversion, anything the platform charges users for), use this skill. Triggers on "credits", "billing", "quota", "rate limit", "is this priced?", or any feature that consumes platform resources. Teaches the lock/settle/cancel idempotency pattern; does NOT implement the credit backend (the platform owns it).

When the produced app is ready to ship to the team's hosted platform, use this skill. Triggers on "deploy", "ship", "release", "Docker", "Traefik", "container", "go live", or anywhere the user asks "how do I get this on the website?". Teaches the team's container-per-app pattern (Docker + Traefik labels → automatic {uuid}.{APP_DOMAIN_SUFFIX} URL). Does NOT do the actual deploy — calls into skills2app's existing docker_ops machinery.

When the produced app makes LLM calls in production, use this skill. Triggers on "LLM call", "call Claude", "call GPT", "call DeepSeek", "model API", "rate limit", "timeout", or any feature that talks to a model at runtime. Teaches the team's wrap-LLM-calls-in-credits-plus-rate-limit pattern with recovery on truncation. Does NOT ship a proxy backend; teams use the platform's existing one.

When choosing which LLM model to call from a produced app, or wiring model-key acquisition, use this skill. Triggers on "which model", "model tier", "T1/T2/T3", "model config", "LLM_MODEL_CHAT", "model env vars", "key backend". Teaches the team's tier policy + standard env var names. Does NOT manage API keys (the platform's key backend does that).

When parsing input documents (PDF, DOCX, HTML, scans) for a produced app or during the 2skills `parsing` phase in a platform-integrated project, use this skill. Triggers on "parse PDF", "parse DOCX", "PDF_PARSE_SERVER", "extract text", "OCR", or any decision about which parsing tool to reach for. Teaches the team's standard parser preference order (PDF_PARSE_SERVER → pypdf → vision fallback) and when to deviate.

When the produced app needs to emit observability events for the team's analytics + monitoring (session starts, LLM calls, fallbacks, completed actions, errors), use this skill. Triggers on "logging", "tracing", "analytics", "instrument", "track event", "app insight", or any feature where the operations team needs visibility. Teaches the standard event taxonomy + SDK init; uses the team's `app-insight.js` library.

The iterative plan-driven advancement pattern John runs on. Read PLAN.md, advance one phase, update PLAN.md, repeat. Adapted from snarktank/ralph for John's longer-horizon, multi-half, subagent-fanout scope.

Decide what shape the knowledge takes in this project — facts, rules, stories, wiki entries, screenplays, custom. Use whenever the user is starting a project, the four-structures section of PLAN.md is unsettled, you're about to enter the extract phase without a clear target schema, or anyone says "what format should we use?". Schema decisions cascade — get this loose enough to iterate but specific enough to write a starter extractor.

When and how to spawn subagents for the vertical axis of John's work matrix. Subagents handle per-entry parallel work (extract this chunk, author this skill, generate this slide) so your main context stays clean and the work scales.

When designing the produced app's overall structure for a platform-integrated project (auth + credits + telemetry wired, deployed via the team's container pipeline), use this skill as orientation. Triggers on "build a subsite", "build a custom app for the website", "produced app structure", "what does the produced app look like?", or whenever a project is heading toward the team's standard app shape. Higher-level overview that points at the focused platform-* skills.

Top-level orientation for John (joharnessburg). Read this skill at the start of every John session and re-read it after every context compaction. Use it whenever the user mentions John, joharnessburg, ralph-loop, 2skills, 2app, knowledge engineering, or asks you to do knowledge-dense app building. It tells you what John is, the shape of the user's working state, where to look, and what to do at each phase of work — without it, you'll likely under-trigger the other John skills.

Author a Claude Code dynamic workflow to run a John fan-out phase at scale. Use this skill whenever a phase has dozens-to-thousands of uniform per-entry work units (extract every chunk, apply every rule to every chapter, render every slide) and the session is configured for workflows. It is John's vertical-axis execution engine — it fans out worker subagents off your context, adversarially cross-checks them before anything folds in, and wires every worker to John's event log. Reach for it ins...

When a produced app needs to call workerLLMs at runtime (e.g., a doc-verification check_R<id>.py asking DeepSeek for a judgment call, or a slide-renderer asking Qwen to summarize a chunk), wire it to call John's local LLM client server. Triggers on "call workerLLM", "runtime LLM call", "call DeepSeek", "call SiliconFlow", "produced app needs an LLM", or any pattern where a produced app needs reasoning beyond Claude's main API. Teaches the standalone OpenAI-compatible call shape against `$JOHN...

Disk is truth. Never trust your in-memory belief about what's done; check disk. Idempotent operations, checkpoint before risky moves, append-only event logs, observable done criteria. The discipline that makes John recoverable across compaction, crashes, and fresh sessions.

Composite confidence scoring for verification findings — combines method prior, source presence, historical accuracy, and corner-case proximity. Use this skill in Phase 7 when calibrating confidence from rule-testing + production-QC data, when [[production-qc]] needs to pick sampling rates, when the dashboard needs confidence bins, or when designing per-rule confidence floors/ceilings. The composite formula is locked; per-rule overrides + project tuning are open.

Manage the per-rule corner-case registry — failures from Phase 4 testing that DON'T fit the main rule logic. Use this skill whenever rule-testing surfaces idiosyncratic failures (<10% rate, no shared pattern), when the runtime needs to load corner cases for a rule, or when the user asks how to handle exceptions. The KEY DISCIPLINE is: NEVER patch the main rule logic with corner-case fixes — keep them isolated in the registry, loaded lazily at runtime AFTER the main check.

Identify and verify rules whose verdict depends on facts spanning MULTIPLE documents (e.g., consistency between a prospectus + periodic report, or product info disclosed differently across two filings). Use this skill in Phase 5 after per-doc Phase 4 testing, or whenever the user asks about cross-doc rules / consistency rules. Cross-doc rules need different sample setup (folder-per-sample), different check signatures (dict-of-docs not single-doc), and different testing budgets. Skip Phase 5 i...

Generate HTML dashboards for the verification app's auditor / developer user — tabs (Summary, Per-Rule, Exceptions, Confidence Heatmap), optional two-column PDF review dashboard with click-to-page jumps. Use this skill in Phase 8 when scaffolding the release bundle's dashboard, when the user mentions dashboard / report / visualization, or when customizing dashboard fields per project. The base dashboard ships via scaffold_release_bundle.py; per-project customization happens after scaffolding.

Run distilled workflows on production batches with confidence-stratified sampling for quality control (Phase 7). Use this skill when running the first production batches, when the user mentions QC / sampling / quality control / batch verification, or when calibrating the confidence model with real production evidence. The sampling rates are tunable per project; LLM-as-Judge reviews sampled findings; per-batch calibration feeds back into [[confidence-system]].

Source-first sweep of regulation documents to extract atomic, falsifiable, testable rules + glossary terms — the Phase 2 extraction step for doc-verification projects. Use this skill whenever the extract phase fires in a doc-verification project, when the user says "extract the rules" / "sweep the regulations" / "find rules" / "extract from regulation". The source-first principle (sweep regulations BEFORE looking at samples) is MANDATORY — kc_cli learned this the hard way.

Test each rule-skill against labeled sample documents; measure accuracy per rule; iterate with the systemic-vs-corner-case split (≥10% failure = rewrite the rule; <10% = move to corner-case registry, NEVER patch main logic). Use this skill in Phase 4 of a doc-verification project, after per-rule skills have been authored in Phase 3 and labeled samples are available. Accuracy thresholds are severity-tiered (project picks defaults in PLAN.md).

REQUIRED Phase 6. Distill expensive SOTA rule-skills (Claude check.py on Opus) into cheap Python + tier-3/4 worker-LLM workflows that preserve accuracy within tolerance. The distilled workflow is the production artifact; the rule-skill is the SOTA reference. Use this skill when Phase 6 fires, when the user mentions distillation / workflow / cheap LLM / production cost, or when [[ralph-loop]] advances out of cross-doc verification. The "method over steps" caveat from kc_cli applies — don't ove...