@@ -0,0 +1,56 @@
+---
+name: deep-research-content-updates
+description: Use when researching current or latest tips, tricks, tools, recommendations, product changes, or best practices for GenAI-assisted coding, prompt engineering, documentation, reproducibility, Jekyll/GitHub Pages, or the workflows described in this guide.
+---
+
+# Deep Research Content Updates
+
+Use this skill to update the guide from current evidence rather than memory.
+
+## Research Workflow
+
+1. Define the update target:
+   - chapter, appendix, template, script documentation, or setup page
+   - exact workflow step affected
+   - whether the topic is time-sensitive
+
+2. Browse or otherwise verify current facts for:
+   - OpenAI/Codex behavior and prompt guidance
+   - GitHub Copilot, GitHub Pages, Actions, Jekyll, Just the Docs, and Mermaid behavior
+   - reproducible research, data science, R, and documentation practices
+   - current caveats around LLM-generated code review, testing, security, privacy, and provenance
+
+3. Prefer source tiers in this order:
+   - official documentation, release notes, standards, package docs, and peer-reviewed or institutional sources
+   - reputable technical docs and maintained project repositories
+   - practitioner posts only when corroborated or clearly labeled as opinion
+
+4. Produce a research memo before editing:
+   - what changed
+   - why it matters for this textbook
+   - proposed target files and sections
+   - source links
+   - confidence and priority
+   - claims to avoid because they are weak, vendor-specific, or likely to age quickly
+
+5. Only then propose or make content edits, keeping them narrow and durable.
+
+## Writing Rules
+
+- Avoid "latest tool roundup" churn unless the change affects the guide's workflow advice.
+- Prefer durable principles plus short notes on current implementation details.
+- Add dates for time-sensitive claims.
+- Do not cite unsourced product behavior.
+- Keep examples relevant to biostatistics, bioinformatics, data science, or research code.
+- If a recommendation could influence spending, compliance, privacy, or research validity, require stronger sourcing.
+
+## Verification
+
+After edits, run:
+
+```bash
+bundle exec jekyll build
+```
+
+If Conda or Miniforge compiler variables interfere with Ruby gems, use the sanitized environment command documented in `docs/DevelopmentSetup.md`.
+
@@ -0,0 +1,43 @@
+---
+name: just-the-docs-site
+description: Use when modifying or troubleshooting this repository's Jekyll/Just the Docs site, including _config.yml, Gemfile, navigation front matter, GitHub Pages workflow, local preview, Mermaid rendering, or build failures.
+---
+
+# Just The Docs Site
+
+This repo builds a root-level Just the Docs site. Keep the manuscript in place and avoid reorganizing `chapters/`, `docs/`, `docs/templates/`, or `scripts/`.
+
+## Workflow
+
+1. Inspect `_config.yml`, relevant Markdown front matter, and `.github/workflows/pages.yml` before changing site behavior.
+2. Use Bundler-pinned commands:
+
+```bash
+bundle install
+bundle exec jekyll build
+bundle exec jekyll serve --host 127.0.0.1 --port 4000
+```
+
+3. If native gem or Jekyll commands fail because Conda/Miniforge compiler variables are active, run with:
+
+```bash
+env -u CC -u CXX -u LD -u LDFLAGS -u CPPFLAGS -u CFLAGS PATH=/opt/homebrew/opt/ruby@3.3/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/homebrew/bin bundle exec jekyll build
+```
+
+4. Verify generated output is not committed: `_site/`, `.jekyll-cache/`, `.bundle/`, and `vendor/bundle/` should remain ignored.
+
+## Front Matter
+
+Rendered pages should generally use:
+
+```yaml
+---
+layout: default
+title: "Page Title"
+parent: Parent Page
+nav_order: 1
+---
+```
+
+Use `has_toc: false` on parent landing pages when Just the Docs would duplicate curated child links.
+
@@ -0,0 +1,140 @@
+---
+name: mermaid-workflow-diagrams
+description: Use when adding, revising, or reviewing visual explanations in chapters, appendices, landing pages, or script documentation for this Just the Docs site. Includes Mermaid diagram selection guidance and when to choose a non-Mermaid format instead.
+---
+
+# Mermaid Workflow Diagrams
+
+Visuals should make the guide easier to understand, not busier. Start by deciding whether a visual is needed at all, then choose the simplest format that explains the relationship clearly.
+
+This site currently pins Mermaid to `9.1.3` in `_config.yml`. Treat diagram types and syntax introduced after that version as "verify first" options. Do not use newer Mermaid features just because they appear in the current Mermaid documentation unless the site Mermaid version is intentionally upgraded and the build/preview is checked.
+
+## Decision Workflow
+
+1. Identify the teaching job of the visual.
+   - Process: "What happens next?"
+   - Decision: "Which path should I take?"
+   - Interaction: "Who talks to whom, and in what order?"
+   - State: "What modes can this object or workflow be in?"
+   - Structure: "How are things related?"
+   - Time: "When do events happen?"
+   - Evidence/data: "What measured quantity should be compared?"
+2. Decide whether Mermaid is the right medium.
+3. Choose the diagram type from the repository below.
+4. Draft a small version first.
+5. Check readability in the Just the Docs content column and on mobile.
+6. Add accessibility metadata.
+7. Build the site and preview layout-sensitive changes.
+
+## When Not To Use Mermaid
+
+Choose a non-Mermaid format when it is clearer or more reliable:
+
+| Need | Better choice | Why |
+| --- | --- | --- |
+| Fewer than 4 linear steps | Ordered list | Faster to scan than a diagram. |
+| Comparison of options, pros/cons, or rules | Markdown table | Tables support dense text and side-by-side comparison better. |
+| Copy/paste instructions or prompts | Fenced code block | Preserves exact Markdown, prompts, and indentation. |
+| Detailed quantitative data | R/ggplot, Plotly, CSV-backed table, or static chart image | Mermaid charts are not a statistical graphics system. |
+| Screens, UI state, or rendered output | Screenshot or generated image | Shows the real artifact instead of a symbolic approximation. |
+| Publication-quality figure with exact layout | SVG, image, or design tool export | Mermaid layout is algorithmic and hard to fine tune. |
+| Large architecture with many systems and dependencies | C4/Structurizr, Graphviz/DOT, D2, or a hand-authored architecture diagram | Better control and clearer large-system layout. |
+| Conceptual taxonomy with long explanations | Headings, nested list, or table | Text hierarchy is more accessible and easier to maintain. |
+| Decorative visual break | No visual | Decoration adds maintenance cost without teaching value. |
+
+## Diagram Repository
+
+Use this table before writing Mermaid. "Good fit" means the diagram type is usually useful for this guide. "Use sparingly" means it can help in narrow cases but is often worse than prose or a table. "Verify first" means confirm support under the pinned Mermaid version or upgrade Mermaid intentionally before using it.
+
+| Diagram type | Syntax start | Fit for this guide | Use when | Avoid when |
+| --- | --- | --- | --- | --- |
+| Flowchart | `flowchart TB` or `flowchart LR` | Good fit | Workflows, branching decisions, loops, review/refinement cycles, inputs leading to outputs. | The point is an interaction between actors, a data schema, or a time schedule. |
+| Sequence diagram | `sequenceDiagram` | Good fit | Prompt/tool/user interactions, request-response flows, review handoffs, API-like exchanges. | There is only one actor or the ordering is not interaction-driven. |
+| State diagram | `stateDiagram-v2` | Good fit | Status transitions such as draft -> reviewed -> revised -> accepted, or code/test states. | You are showing tasks rather than states. Use a flowchart instead. |
+| Entity relationship diagram | `erDiagram` | Good fit | Data tables, simulated EHR entities, joins, keys, derived datasets. | You need workflow or causal logic. |
+| Class diagram | `classDiagram` | Use sparingly | Object models, package/module responsibilities, typed relationships. | The guide is explaining human workflow or data tables. |
+| User journey | `journey` | Use sparingly | Researcher experience across planning, coding, review, documentation, and friction points. | The content is not persona-centered. |
+| Gantt | `gantt` | Use sparingly | Project schedules, manuscript timelines, release plans. | You only need a checklist or dependency workflow. |
+| Pie chart | `pie` | Use sparingly | Simple proportions that sum to a meaningful whole. | Comparing more than 3-5 categories, showing change over time, or presenting precise data. Prefer a table or real chart. |
+| Git graph | `gitGraph` | Use sparingly | Branch, commit, PR, review, and release examples. | You are explaining conceptual iteration rather than actual git history. |
+| Requirement diagram | `requirementDiagram` | Use sparingly | Trace success criteria to risks, tests, and acceptance checks. | The page is not about requirements or validation. |
+| C4 diagram | `C4Context`, `C4Container`, etc. | Verify first | Software architecture context with people, systems, containers, and dependencies. | You need precise, durable architecture docs. Consider Structurizr or C4-PlantUML for larger systems. |
+| Mindmap | `mindmap` | Verify first | Brainstorming, topic breakdowns, compact conceptual hierarchy. | The hierarchy is long, text-heavy, or needs stable reading order. |
+| Timeline | `timeline` | Verify first | Chronological history, release milestones, or project phases. | You are showing a process that can loop or branch. |
+| Quadrant chart | `quadrantChart` | Verify first | Two-axis prioritization such as impact vs effort or risk vs confidence. | Axes are subjective or the categories need explanation. Prefer a table. |
+| Sankey | `sankey-beta` | Verify first | Flow quantities between stages, if real quantities exist. | You do not have measured weights. Do not fake quantitative flow. |
+| XY chart | `xychart-beta` | Verify first | Simple bar/line examples where exact analytical plotting is not needed. | Research data, statistical graphics, uncertainty, or anything requiring reproducible analysis. Use R. |
+| Block diagram | `block-beta` | Verify first | Spatial grouping of components or conceptual blocks. | A flowchart or table can express the relationship. |
+| Architecture diagram | `architecture-beta` | Verify first | Lightweight architecture sketches if supported by the active Mermaid version. | Stable architecture documentation. Prefer C4/Structurizr/Graphviz. |
+| Kanban | `kanban` | Verify first | Work-in-progress board examples. | The page is about process logic, not current work status. |
+| Radar | `radar-beta` | Verify first | Small multi-factor profiles, if the axes are honest and comparable. | Evidence strength or model/tool rankings without rigorous scoring. |
+| Treemap | `treemap-beta` | Verify first | Hierarchical quantities. | No real quantities exist or labels are long. |
+| Venn | `venn` | Verify first | Small set overlap explanation. | More than 3 sets or non-overlap relationships. |
+| Ishikawa | `ishikawa` | Verify first | Root-cause analysis of errors or workflow failures. | The page is not diagnosing causes. |
+| Wardley map | `wardley` | Verify first | Strategy mapping with value chain and evolution axis. | Most guide content. It is specialized and may confuse readers. |
+| Packet | `packet-beta` | Usually not needed | Network packet structure. | Nearly all content in this repo. |
+| Event modeling | `eventModeling` | Usually not needed | Event-sourced systems with commands, events, views, and policies. | General research coding workflows. |
+| ZenUML | `zenuml` | Usually not needed | UML-like sequence diagrams if support is confirmed. | Standard `sequenceDiagram` is sufficient. |
+| TreeView | `tree` or documented current syntax | Usually not needed | Directory-like trees if support is confirmed. | A fenced text tree or Markdown list is clearer. |
+
+## Mermaid Defaults For This Site
+
+- Prefer `flowchart TB` for long sequences, branching decisions, convergence diagrams, and feedback loops.
+- Use `flowchart LR` only for compact pipelines that fit comfortably in the content column, usually 3-5 short nodes.
+- Avoid `TD` as a habit. Use `TB` for consistency unless an existing diagram uses `TD` and is already readable.
+- Consider `sequenceDiagram` instead of a flowchart when the central question is "who sends what to whom?"
+- Consider `stateDiagram-v2` instead of a flowchart when boxes represent statuses rather than tasks.
+- Consider `erDiagram` instead of a flowchart when boxes represent data entities or tables.
+- For complex flowcharts, use subgraphs only when they reduce cognitive load. If subgraphs make the diagram wider or harder to scan, split the visual or use prose.
+- Keep node labels short, concrete, and action-oriented. Move explanation to surrounding prose.
+- Prefer 5-9 nodes for most diagrams. Reconsider the format above 12 nodes.
+- Use decision diamonds only for real branch points with mutually meaningful paths.
+- Do not encode meaning only with color. Labels and structure must carry the meaning.
+
+## Accessibility Rules
+
+Every Mermaid block must include:
+
+```mermaid
+flowchart TB
+  accTitle: Short useful title
+  accDescr: One sentence describing the diagram's purpose and main structure.
+```
+
+Use `accTitle` and `accDescr` for all diagram types. The title should name the visual, and the description should explain what the reader can learn from it. Do not repeat the page title as the only description.
+
+## Visual Style Rules
+
+- Use the repository's global Mermaid theme in `_includes/mermaid_config.js`; avoid one-off styling unless it fixes comprehension.
+- Avoid low-contrast custom colors and decorative gradients.
+- Do not use icons, emojis, or dense symbol systems inside node labels.
+- Keep arrows simple. Too many edge labels usually means the diagram needs to be split.
+- Use consistent terminology with the surrounding chapter.
+- Avoid long quoted prompt text inside Mermaid. Use a code block for prompts.
+
+## Review Checklist
+
+Before accepting a Mermaid change:
+
+- The visual has a clear teaching job that prose/table/code cannot do better.
+- The selected Mermaid type matches the relationship being explained.
+- The diagram type is supported by the current site Mermaid version or the version was intentionally upgraded.
+- `accTitle` and `accDescr` are present.
+- Orientation is readable in the Just the Docs content column.
+- Labels fit on mobile and do not duplicate adjacent prose.
+- The diagram does not imply quantitative precision unless the data are real.
+- The page still builds with Jekyll.
+
+## Validation
+
+Run the site build after changes:
+
+```text
+bundle exec jekyll build
+```
+
+For layout-sensitive edits, preview locally at:
+
+```text
+http://127.0.0.1:4000/practical-genai-coding-guide/
+```
@@ -0,0 +1,22 @@
+---
+name: prompt-template-curation
+description: Use when editing prompt templates, project plans, refactoring prompts, red-team prompts, or reusable template pages under docs/templates in this repository.
+---
+
+# Prompt Template Curation
+
+Prompt templates in `docs/templates/` must remain easy to copy into an LLM while still rendering cleanly in Just the Docs.
+
+## Rules
+
+- Keep prompt template bodies inside fenced `markdown` code blocks when the page is meant for copy/paste.
+- Keep project plan examples rendered normally when they are better read as example documents.
+- Use `nav_exclude: true` for raw template files that should not appear as sidebar pages.
+- Avoid smart quotes or decorative symbols inside copy/paste prompt bodies unless the source already depends on them.
+- Preserve placeholders exactly when they are part of the reusable template.
+- Check links from Appendix D and template landing pages after renaming or moving files.
+
+## Validation
+
+Run `bundle exec jekyll build` after template changes and inspect the rendered page if nested code fences were edited.
+
@@ -0,0 +1,74 @@
+---
+name: reference-source-audit
+description: Use when validating references, citations, source URLs, link rot, anchor integrity, or whether the current content is supported by the cited reference sources.
+---
+
+# Reference Source Audit
+
+Use this skill to check whether the guide's references still exist and whether cited claims align with the cited sources.
+
+## Audit Workflow
+
+1. Inventory references:
+
+```bash
+rg -n '<a name="ref[0-9]+"></a>|References\\.md#ref[0-9]+|#ref[0-9]+' chapters docs scripts
+```
+
+2. Build three lists:
+   - reference ids defined in `docs/References.md`
+   - reference ids cited from content
+   - URLs attached to each reference
+
+3. Check structural integrity:
+   - every cited `refN` exists
+   - every reference anchor is unique
+   - every reference has a usable title or source name
+   - every URL is present and reasonably canonical
+   - duplicate references are intentional or consolidated
+
+4. Check link health:
+   - URL resolves
+   - redirects are recorded
+   - paywalled or unstable pages are flagged
+   - canonical DOI, PubMed, PMC, arXiv, official docs, or release-note URLs are preferred where available
+
+5. Check claim support:
+   - read the paragraph or sentence around each citation
+   - inspect the cited source for direct support
+   - classify as `supported`, `partially supported`, `unsupported`, `stale/changed`, or `unverifiable`
+
+6. Report before editing:
+   - file and line
+   - ref id
+   - claim summary
+   - source URL
+   - link status
+   - support status
+   - severity
+   - recommended action
+
+## Source Quality
+
+- Strong: official docs, standards, release notes, peer-reviewed papers, PubMed/PMC, arXiv/OpenReview, institutional guidance.
+- Moderate: maintained technical docs, reputable research-team posts, active GitHub repositories.
+- Weak: SEO articles, vendor marketing pages, Medium posts, Reddit, YouTube, and personal blogs unless used as examples or corroborated practitioner perspectives.
+
+For clinical, medical, statistical, privacy, compliance, or research-validity claims, require strong sources.
+
+## Editing Guidance
+
+- Do not replace a source just because it is old if it remains authoritative.
+- Prefer updating weak citations to stronger sources over adding more citations.
+- Preserve stable reference anchors when possible so existing chapter links do not break.
+- If renumbering references is unavoidable, update every inbound citation in the same change.
+- Include access or verification dates for time-sensitive source checks.
+
+## Verification
+
+After edits, run:
+
+```bash
+bundle exec jekyll build
+```
+
@@ -0,0 +1,19 @@
+name = "content-reviewer"
+description = "Use for independent review of chapter, appendix, README, reference, and template prose changes before finalizing documentation work."
+nickname_candidates = ["reviewer", "editor", "content"]
+sandbox_mode = "read-only"
+
+developer_instructions = """
+You review this repository as a technical editor for a practical textbook on GenAI-assisted coding and research workflows.
+
+Focus on:
+- Broken or suspicious relative links.
+- Duplicated navigation or table-of-contents content.
+- Missing or inconsistent Just the Docs front matter.
+- Rendered prompt templates that should instead appear as fenced Markdown code blocks.
+- Prose changes that weaken technical accuracy, reproducibility, or human-review emphasis.
+- Accidental broad rewrites unrelated to the requested task.
+
+Return concise findings with file paths and line references. Do not rewrite content unless explicitly asked.
+"""
+