Skills

Read the owning repository's AGENTS.md and site-theme/docs/WRITING-STYLE.md. Locate site-theme beside the current repository, or resolve this skill's real path. Use the writing policy for all new original technical text and substantive prose edits.

Classify original prose and protected content before the edit. Preserve reader text, translations, quotations, names, citations, legal text, and code. Preserve NDB fictional dialogue, story text, bestiary prose, and item descriptions. Preserve data, formulas, formal statements, hypotheses, quantifiers, proof dependencies, and uncertainty.

Use short, complete sentences and consistent technical terms. Give instructions in the imperative, with prerequisite conditions first. Limit instructions to 20 words and descriptions to 25 words per sentence. Limit a paragraph to one topic and six sentences. Use active voice, simple verb forms, and no semicolons. Check dictionary meanings and parts of speech when the official dictionary is available. Retain precise mathematical and interface terms under the technical-term rules.

Edit the source of generated content. Rebuild affected pages, PDFs, exports, and indexes. Compare protected content with the original. Run the repository's tests. Obtain a separate technical-meaning review for mathematical proof edits. Report actual checks and any dictionary-review limit. Do not claim unsupported complete compliance.

Read the owning repository's AGENTS.md and the theme's PHILOSOPHY.md and docs/DESIGN-SYSTEM.md. Locate site-theme beside the current repo, or resolve this skill's real path to its owning site-theme checkout.

Identify the primary task and choose the surface around it: reading, reference, collection, live monitor, chart exploration, or puzzle workspace. Put the real material or controls in the first useful viewport. Use the Readers reference: Georgia text and controls, bold Palatino headings, mono values, and sans only for tiny chart annotations. Retain paper/charcoal modes, restrained blue, square controls and quiet rules; do not impose a card grid or marketing hero.

Treat each project as an independent page with useful local navigation and source/download links. Retain the shared abstract Home emblem in the existing header beside the theme dial; do not add a fixed footer or new sticky bar. include it in authored/generator HTML for a no-JavaScript fallback. NDB Idle is exempt. For a masthead, use the shared identity contract in docs/COMPONENTS.md: a relevant transparent PNG from v2/marks as img.site-mark, 32px, empty alt—not Unicode or emoji. Keep identity separate from data colors.

Use margins for meaningful context and comparison; remove unexplained number gutters, oversized gaps and empty hero space. Remove duplicate headings, redundant controls in the same context and obvious instructions, but retain uncertainty, provenance, privacy boundaries and actionable state text. A puzzle's PNG-centered divider belongs at the start of its main puzzle unit, after complete rules and worked examples. Keep the unit's lead-in, solve links and grids together below it; identify the boundary by meaning, not the first image. Use the puzzle transition contract in docs/COMPONENTS.md for explicit exceptions and preserve all source content/order.

Give the puzzle transition a small ornament distinct from the masthead logo. When the grid and solve links feel detached, one thin, square-edged sheet may enclose the complete main unit, using the divider as its top edge. Keep examples outside and original diagram colors intact; avoid shadows and excess inset. Group only verified solver-only content into an action row, preserving post-grid links and notes in source order.

Inspect existing layout and CSS ownership before editing. Regular reading targets 1rem; navigation and controls .875rem; secondary metadata .75rem. These are design targets. Judge dense chart marks separately instead of shrinking all labels or changing board geometry. Ordinary single-choice selects adopt data-ui-select; retain richer grouped VN chapter browsers. Choose compact paginated rows with detail or an overflowing comparison matrix, not pagination plus an internally scrolling two-axis table.

Make a representative improvement, then extend only the proven pattern. Keep data, ranking, scientific interpretation, puzzle logic and bot policy outside a visual change. Record the actual reusable decision in site-theme/docs/DECISIONS.md and the shipped scope in docs/CHANGELOG.md. Use docs/QA-MATRIX.md to choose checks proportional to the change; do not report unperformed browser checks as passed.

Shared section: Original technical writing

Locate the canonical site-theme checkout and read PHILOSOPHY.md, docs/DESIGN-SYSTEM.md and docs/REPOSITORIES.md. Inspect the consumer's actual load order: theme.js in the head, base.css, then local CSS.

The foundation owns tokens, type roles, common shells, focus, controls and color-mode behavior. Local styles own content layout, special tables and visualization geometry. Remove a duplicated override only after verifying its role. Avoid an appended !important override layer. Keep a CSS fallback for a newly introduced token in independently deployed consumer files.

Keep v1 unchanged. Preserve v2 token names, data-theme, the legacy .dark class, jehlp-theme, migration from jwknt-theme/bst-reader-theme/solverTheme, and jehlp:themechange plus jwknt:themechange. Breaking contracts need a new version directory. A stable v2 URL means the release affects consumers not present in this archive: inventory them rather than assuming safety.

Mastheads use relevant transparent PNGs from v2/marks, with the img.site-mark contract; do not restore font glyphs as identity marks. Keep optional data-ui-select behavior in the component layer and local control widths in consumers. Check native fallback before removing conflicting select styles.

Use stylesheet-relative CSS assets. Rebuild logical-solver/dist/ubahn-solver.html after a shared change; its build must inline theme CSS/JS, masks, favicon and PNG masthead. Run node --test tests/*.test.mjs in site-theme, then affected consumer builds/checks. Review both sparse reading and dense working surfaces before publishing a shared revision. Record evidence and exceptions, not a generic “looks good.”

Shared section: Original technical writing

Locate the canonical site-theme checkout and read its PHILOSOPHY.md and docs/COMPONENTS.md. Inspect components.html for working examples and the owning page's load order and generator. Optional components live in v2/components.css and v2/components.js; base tokens and theme preferences remain in their existing foundation files.

Choose the smallest pattern that serves the material. Existing contracts cover directories, grouped fields, single-choice selects, segmented selections, responsive disclosures, section indexes, overflow regions, native dialog shells, copyable code and highlighted code listings (jehlp-code-highlighting). Extract a new behavior when real consumers share its semantics, not merely similar class names. Prove it in a representative page before spreading it. Keep intentional local differences explicit.

Use classes for appearance and data attributes for behavior. Native HTML remains useful if the optional script fails. Shared components do not own application data, filtering policy, API calls, or puzzle logic. JehlpUI.enhance(root) is idempotent; use it for newly inserted components and remove superseded local listeners. Geometry, content, and dataset rendering stay local.

Adopt data-ui-select for ordinary native single-choice dropdowns. Preserve the native label, options, form name/value and change handlers; call JehlpUI.enhance(select) after programmatic value changes or option population. Do not layer it over the richer VN chapter browser or flatten meaningful chapter groups to obtain matching styling. Use the shared reader-like control scale. Keep one navigation model per table: natural-flow pagination with record detail, or named matrix overflow without pagination. Consult the current contract rather than copying superseded local selectors or listeners.

Edit authored templates before regenerating output. Publish new assets before their consumers. Check focus, keyboard, breakpoint transitions, empty/populated, and no-script behavior as relevant, plus existing consumer tests. Record contracts and adopters in docs/COMPONENTS.md; add a working gallery example when it helps future adoption. Do not add an abstraction or dependency solely to increase the component count.

Shared section: Original technical writing

Read the owning repository's AGENTS.md, the theme's PHILOSOPHY.md and the code contract in docs/COMPONENTS.md. Locate site-theme beside the current repository, or resolve this skill's real path to its owning site-theme checkout.

Highlight code during the build. Use highlight.js at a pinned version as a development dependency. Do not load a highlighter or a highlight.js theme in the browser. Choose the language from the file extension, and use plain text when the language is unknown. Highlighting adds spans only: compare the text content with the source after a change.

Use the shared markup: <pre class="ui-code" tabindex="0" aria-label="Source of name.py"><code class="hljs language-python">…</code></pre>. Load v2/components.css after base.css. The --code-* tokens in base.css follow the theme tones, so dark mode and print need no second palette. Do not add token backgrounds, line shading, bold keywords or a page-specific syntax theme. Long lines scroll inside the named code block. Use .ui-code--wrap for data whose values are prose, such as pretty-printed JSON notes.

Render one or two listings in the page. For a large collection, put each listing in a native details element with the file name in its summary. Generate one static fragment per listing and fetch it on the first open. Keep a plain-text source link in the closed panel, so the listing remains available without JavaScript. Link fragments for search only when their text is useful search content.

Format JSON with two-space indentation before you highlight it. Render Markdown and prose notes as prose, not as code. Add data-copy-code when readers will copy the listing. Do not reduce the type size to fit long lines.

Check both color modes, print, keyboard focus on the code block, a narrow screen and the largest listing. Record new adopters in docs/COMPONENTS.md.

Shared section: Original technical writing

Read the consumer's README, AGENTS.md, existing tests and relevant renderer before editing. Distinguish the stable data contract from presentation. Mystery-report ranking/export, profile scientific content, and dashboard state interpretation must remain intact during UI work.

Keep search/filter/sort controls together with results. Preserve reset, counts, access to every result, accessible labels, keyboard paths and dialog focus. Use data-ui-select for ordinary single-choice filters; preserve their native values/change handlers and resync after programmatic changes. Show sort direction in headings without visible priority digits; explain primary/secondary sorting in advanced controls and accessible names. Empty, loading, disconnected, stale and failed are different states; unavailable telemetry is not zero and is not a successful action. The NGU public dashboard stays read-only. Do not start the bot or call a live mutation endpoint to test layout.

Choose the collection model before adding overflow. Paginated rows flow with the page: retain essential comparison fields and put secondary fields in accessible detail, without removing them from sorting/export. A true matrix may use a named focusable overflow wrapper without pagination. Do not combine pagination with an internally scrolling two-axis table. Use aligned/tabular values and one connected native header band. A visual chart needs readable text for essential values; smaller annotations are a measured local exception, not a precedent for 9px filter labels.

Preserve source datasets and factual copy. Exercise representative populated/empty/extreme states and the existing tests. Use local fixtures for live UI checks where available; identify them as fixtures. Record remaining data or browser limitations in site-theme/docs/VALIDATION.md or the dated successor record.

Shared section: Original technical writing

Read site-theme/docs/QA-MATRIX.md and select the rows relevant to the requested change. Inspect existing test commands before running them; report static tests, script behavior tests, and rendered browser evidence separately.

For shared-theme work, make the browser actually load the candidate local theme. Use temporary response rewriting or request interception for the production theme URL, or a throwaway preview copy. Never commit localhost URLs. Rebuild generated documents and the solver export first. Build Jekyll locally; do not mistake archived _site output for the candidate source.

Exercise 390px and 1440px light/dark layouts, keyboard traversal, meaningful focus, 200% text enlargement, and relevant no-JS/print/reduced-motion behavior. Add widths only when a concrete breakpoint defect needs isolation. Test real primary interactions rather than taking only screenshots. Capture representative evidence with viewport, theme and state.

For the MTL contents disclosure, check hidden links, Escape, heading selection, resize and no-JS. For data dialogs, check naming, focus and close. For solver export, disable network. For the dashboard, preserve read-only behavior and truthful offline/stale state.

For select changes, exercise keyboard/typeahead, Escape without selection, reset, disabled options, dynamic option population, programmatic value synchronization and native fallback. Compare equal-role reader controls for matching size; check that chapter groups survive and redundant glossary controls do not return. Check PNG masthead loading at its actual small size in both modes. Review the first useful viewport for empty hero space or unexplained number gutters. A paginated table must not also need internal two-axis scrolling; inspect first/last rows, details and sort direction. For a true matrix, test connected headers in each scroll direction. For puzzle dividers, inspect the complete rules/examples and the main puzzle's lead-in, solve links and grids on both sides of the boundary. An ornament before the first image is not sufficient: examples stay above, while the complete main puzzle unit stays below. Check the reviewed lead-in/paired-grid exceptions in docs/COMPONENTS.md and verify exact source text, link and diagram preservation; image counts alone cannot establish a correct semantic boundary.

For puzzle sheets, verify a distinct transition ornament, one top edge, and the complete main unit inside the frame, including paired grids and reference charts. Only a verified leading solver-only run may become an action row; post-grid links stay in source order. Check narrow/enlarged-text control wrapping, unchanged bitmap colors and proportions, and print's normal top border without the ornament.

For code listings, check token contrast in both modes and print, keyboard focus and scrolling in a long listing, the first open of a lazily loaded listing and its no-script source link.

Fix demonstrated failures at the responsible layer. Stop optional testing when concrete risks are covered. Leave an honest checklist of unavailable gates; never treat a DOM stub or source regex as proof of browser accessibility.

Shared section: Original technical writing

Read site-theme/docs/REPOSITORIES.md, the current repo's remote, branch, git status, Pages workflow/settings, CNAME if present, and generator scripts. Confirm the actual destination: site maps to jehlp/JWsite, and ngu-idle-bot maps to JWKNT/ngu-idle-autopilot in the supplied snapshot. Folder names do not prove hosted paths.

Preserve existing user work. Use an explicit file list per repo; never git add -A across the desktop bin directory. Build from authored sources, include tracked generated outputs, and review git diff --check. Do not commit local credentials, runtime game state, preview URL rewrites or stale _site output. Theme skills are maintained in site-theme and versioned with its source.

Before a shared v2 release, review available consumers outside the archive, including reader surfaces, and confirm local candidates passed relevant QA. Publish new PNG marks and component assets before their consumers reference them. Consumer code using new CSS tokens should keep fallback values so release order does not blank the UI. Identify the theme commit, affected consumer commits and rollback commits; rebuild embedded exports, including their PNG identities, where needed.

Prepare a concrete release plan and commits. Push or deploy only when included in the user's current authorization; a local preparation request does not authorize publication. After an authorized deploy, verify the actual public routes, stylesheet/script asset responses, canonical metadata and a representative interaction. If routing ownership is unclear, report the precise unresolved setting rather than guessing or rewriting remotes.

Shared section: Original technical writing

Use the canonical site-theme checkout. Read the current docs/CHANGELOG.md, docs/DECISIONS.md and affected repository guidance. Preserve PHILOSOPHY.md as the long-lived intent; do not rewrite it for every implementation detail.

For an actual change, record date, problem, files or affected projects, resulting behavior, tests actually run and material remaining work. A reusable choice gets a short decision entry: evidence, decision, tradeoff, and when to reconsider it. Routine spacing fixes need only a changelog entry. Do not invent past intent or claim visual validation from static checks.

A handoff names the recipient's requested model/reasoning, exact current state and base commits, dirty-work constraints, ordered next actions, commands, and completion gates. Make local edits and generated files concrete before handing off. Distinguish done, prepared, untested and blocked.

Use current official documentation when specifying Codex installation/model configuration; preserve the user's chosen target. Keep skills self-contained and under site-theme/skills; update their catalog when triggers change. Version these changes in the owning Git repository and keep the portable handoff import separate from live repository metadata.

Shared section: Original technical writing