For doc-verification projects the runtime shape is locked. John core's `app-design-thinking` is co-authored, taste-driven, open-ended; this template narrows it because the kc_cli methodology only ships one product archetype: a doc-verifier with the pipeline below. Per-project customization happens *

Parsed markdown is rarely the right unit for downstream rule extraction or rule testing. Chunking turns parsed output into a **tree of progressively-disclosed pieces** the rule-extraction phase can sweep and the rule-testing phase can match against.

The produced app is the deliverable. The user trusts it not to leak credentials, not to ship debug noise, not to crash on the first run. This skill is the discipline that makes that trust possible — adapted from skills2app's production quality patterns: inherit those methods, but skill-ify them ra

The produced verification app outputs `results.json` (machine-readable) AND an `dashboard.html` (human-readable). This skill teaches layer-2 Claude to scaffold the dashboard via `scaffold_release_bundle.py` and customize per project.

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.

The 2skills half ends here. Packaging turns John's working knowledge state (in `<project>/.john/knowledge/`) into the deliverable that the 2app half consumes (in `<project>/.claude/skills/`). After this phase, the produced skills are project-scoped Claude Code skills — auto-discovered by any Claud

You are layer-2 Claude designing phases for your user's project. The phases will live in their `<project>/PLAN.md` and drive every loop iteration via [[ralph-loop]].

You are writing PLAN.md for the first time on a new John project. After this, [[plan-md-evolution]] takes over — this skill is just the bootstrap.

[[plan-md-authoring]] bootstraps PLAN.md at project start. This skill takes over for the entire rest of the project lifecycle — every phase advance, every decision, every blocker, every iteration. PLAN.md is the durable contract; evolution is what keeps it durable.

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 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).

The team has converged on a clear parser preference order for documents. Use it; don't ad-hoc pick a parser per project.

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]].

The Phase 2 extraction step for doc-verification projects. Sweep regulation source documents and produce atomic, falsifiable, testable rules + glossary terms in the schema defined by the overridden [[schema-design]].

After Phases 3 + 4 produce verified per-rule skills that work on SOTA Claude (Opus), Phase 6 distills each into a `<project>/workflows/R<id>/workflow.py` + per-step worker-LLM prompts that run on tier-3/4 cheap models with accuracy within tolerance of the SOTA reference. The distilled workflows are

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.

A dynamic workflow is a JavaScript script the Claude Code runtime executes in the background. You describe the work; you write the script with your Workflow tool; the runtime fans out subagents (up to 16 at once, 1,000 per run), keeps every intermediate result in *script variables* instead of your c