'v1'

2026-07-06 18:06:28 +02:00
parent 9d189020de
commit fdbe811cdc
279 changed files with 60644 additions and 0 deletions
@@ -0,0 +1,56 @@
+---
+name: cobol-teacher
+description: A pedagogical companion designed to teach COBOL syntax, structural logic, and history through progressive, interactive HTML lessons.
+disable-model-invocation: true
+category: education
+risk: safe
+tags:
+  - cobol
+  - education
+  - mainframes
+  - gnu-cobol
+---
+
+# COBOL Teacher
+
+## Purpose
+
+To guide the user step-by-step through learning COBOL, focusing on historical context, divisions, data structures, and standard execution without automated code generation.
+
+## When to Use
+
+Use when the user wants to progress through COBOL lessons, take quizzes, review syntax cards, or update their learning records.
+
+## Workspace Structure
+
+The teaching workspace utilizes the following layout:
+- `MISSION.md`: Defines why the user is learning COBOL.
+- `./lessons/0001-*.html`: Self-contained interactive HTML lessons.
+- `./reference/`: Compressed syntax and structure sheets.
+- `./learning-records/`: Log of mastered concepts.
+
+## GnuCOBOL Dev Container Environment
+
+When setting up and testing user code:
+- Ensure the user's workspace contains `.devcontainer/devcontainer.json` configured for GnuCOBOL.
+- Keep in mind the strict compilation rules:
+  - Never append intermediate `.o` object extensions to final executables.
+  - Compile using `cobc -x -o bin/program src/program.cbl` for binaries.
+
+## Retrieval Practice & Spacing
+
+Always design lessons to build **long-term storage strength**:
+- Require the user to write divisions and picture clauses from memory.
+- Reinforce strict layout margins:
+  - **Columns 1-6**: Sequence numbers (optional/historical).
+  - **Column 7**: Indicator area (`*` for comments, `-` for continuation).
+  - **Columns 8-11 (Area A)**: Division, Section, and Paragraph headers.
+  - **Columns 12-72 (Area B)**: Statements and entries.
+  - **Columns 73-80**: Identification area (ignored by compiler).
+
+## Core Curriculum Map
+
+1. **Lesson 0001: The Punch Card Layout** (Columns, Area A vs. Area B margins).
+2. **Lesson 0002: The Four Divisions** (IDENTIFICATION, ENVIRONMENT, DATA, PROCEDURE).
+3. **Lesson 0003: DATA DIVISION Types** (PIC X, PIC 9, PIC S9(4) COMP, values).
+4. **Lesson 0004: Basic Verbs** (DISPLAY, ACCEPT, PERFORM, EVALUATE).
@@ -0,0 +1,64 @@
+---
+name: foundryvtt-modding
+description: Guidance on FoundryVTT module and custom system development using TypeScript, Vite, or Rollup.
+disable-model-invocation: false
+category: GameDev
+risk: safe
+tags:
+  - foundryvtt
+  - typescript
+  - modding
+  - javascript
+---
+
+# FoundryVTT Modding
+
+## Purpose
+
+To guide the development of custom FoundryVTT modules and systems, emphasizing TypeScript configuration, modern build tools (Vite/Rollup), schema structures (`module.json`), Actor/Item sheet architecture, and hook lifecycles.
+
+## When to Use
+
+Use when writing, refactoring, or structuring TypeScript/JavaScript code for FoundryVTT modules or systems, defining manifest metadata, or hooking into Foundry's rendering lifecycle.
+
+## TypeScript & Build Configuration
+
+- Use `@league-of-foundry-developers/foundry-vtt-types` for autocomplete and type safety of the `game`, `canvas`, and other global variables.
+- Configure `tsconfig.json` to target ES2022+ and resolve modules correctly.
+- Set up `vite.config.ts` or `rollup.config.js` to bundle files into a single distribution file under `dist/` and copy assets/templates.
+
+## Manifest Layout (`module.json` / `system.json`)
+
+Ensure the manifest contains clean references to script entrypoints:
+```json
+{
+  "id": "my-module",
+  "title": "My Foundry Module",
+  "description": "Custom additions for Homebrew Magic",
+  "version": "1.0.0",
+  "compatibility": {
+    "minimum": "11",
+    "verified": "12"
+  },
+  "esmodules": ["dist/module.mjs"],
+  "styles": ["styles/module.css"]
+}
+```
+
+## Lifecycle Hooks
+
+Standardize hook registrations to keep initialization organized:
+- `init`: Register game settings, active effect keys, and customize configuration structures (`CONFIG`).
+- `setup`: Perform setups dependent on settings availability.
+- `ready`: Execute scripts that require canvas or database collections to be fully loaded.
+
+```typescript
+Hooks.once("init", () => {
+  console.log("Initializing Homebrew Magic Module");
+  
+  // Register custom sheets
+  Actors.registerSheet("homebrew-magic", CustomActorSheet, {
+    makeDefault: true
+  });
+});
+```
@@ -0,0 +1,50 @@
+---
+name: openscad-parametric
+description: Algorithmic solid modeling and precise geometry generation for multi-nozzle toolchanging setups (Bambu Lab H2C).
+disable-model-invocation: false
+category: CAD
+risk: safe
+tags:
+  - openscad
+  - 3d-printing
+  - cad
+  - parametric
+---
+
+# OpenSCAD Parametric Design
+
+## Purpose
+
+To guide the generation of modular, algorithmic, and mathematically precise solid geometry in OpenSCAD, optimized for multi-material toolchanger systems.
+
+## When to Use
+
+Use when writing or editing OpenSCAD (`.scad`) code, calculating tolerances/clearances, structuring modular assemblies, or designing fixtures/parts for Bambu Lab H2C toolchanging architectures.
+
+## Core Design Principles
+
+### 1. Parametric Rigidity
+- Define all key dimensions (lengths, thicknesses, hole diameters, clearances) as variables at the top of the file.
+- Derive dependent geometry using mathematical relations (e.g., `wall_thickness * 2`) rather than hardcoding numbers.
+- Use `$fn` selectively to control cylinder resolution; prefer lower `$fn` (e.g., 16-32) during preview and higher (e.g., 64-128) only for final rendering.
+
+### 2. Multi-Nozzle / Multi-Material Design
+- Organize components into separate modules representing different nozzles/materials.
+- Avoid geometry overlap (which causes slicing artifacts). Use explicit `difference()` operators to cut channels for different materials to lock into each other mechanically.
+- Add clearance margins (typically `0.15mm` to `0.3mm`) between interlocking toolchanged parts depending on the printer's dimensional accuracy.
+
+### 3. Bambu Lab H2C Toolchanger Assemblies
+- Focus on toolchanger mount coordinates, bolt/nut clearances, and alignment pins.
+- Use standardized alignment pins (`4.0mm` diameter pins with `0.2mm` clearance holes) to locate mating parts securely.
+- Ensure overhangs respect the 45-degree rule, or design custom print-in-place breakaway supports.
+
+## Math Utilities Library
+
+Prefer clean mathematical algorithms for curves and shapes:
+```openscad
+// Parametric ellipse helper
+module ellipse(rx, ry, h) {
+    scale([1, ry/rx, 1])
+        cylinder(r=rx, h=h, center=true);
+}
+```
@@ -0,0 +1,53 @@
+---
+name: ttrpg-lore-weaver
+description: TTRPG worldbuilding, lore organization, dynamic workspace scanning, and character visual generation using Stable Diffusion.
+disable-model-invocation: false
+category: Creative
+risk: safe
+tags:
+  - ttrpg
+  - lore
+  - obsidian
+  - stable-diffusion
+---
+
+# TTRPG Lore Weaver
+
+## Purpose
+
+To guide the creation, organization, and visual design of TTRPG lore, characters, and settings, integrating dynamic workspace analysis and image generation rules.
+
+## When to Use
+
+Use when generating lore documents, writing character sheets, designing setting hooks, or running stable diffusion image generation pipelines for your custom TTRPG campaign.
+
+## Step-by-Step Workflow
+
+### Phase 1: Workspace Structure Analysis
+Before generating any lore files or suggesting edits:
+1. **Scan the Directory Structure**: Inspect the active workspace. Determine if running in the root project directory `hbm-books` or inside the `ObsidianNotes` subfolder.
+2. **Detect Folders**: Check for the presence of folders like `npcs`, `lore`, `locations`, `rules`, `items`, `spells`.
+3. **Action**:
+   - If directories are structured correctly, proceed.
+   - If files are misplaced or missing organization, suggest explicit folder structure modifications to the user before writing content.
+
+### Phase 2: Tone & Thematic Anchors
+Use these **Leading Words** to keep writing consistent:
+- *Homebrew Magic*: Modern day, high fantasy, rule-bending, experimental mechanics.
+
+### Phase 3: Character Sheet Integration
+When generating a new NPC or Player Character sheet:
+1. **Write Content First**: Generate the markdown file containing stats, attributes, and lore text.
+2. **Visual Generation**: Build the prompt based on character features.
+   - **AutismSDXL Syntax**: Use Danbooru-style tags. Translate descriptors (e.g., `1girl, female elf, dark leather armor, holding dagger, long silver hair`).
+   - **Negative Prompt**: Apply the strict negative prompt:
+     `score_5_up, score_4_up, source_furry, source_pony, 3d, photo, realistic, lowres, text, error, cropped, worst quality, low quality, jpeg artifacts, blurry, signature, watermark, username, artist name, deformed, disfigured`
+3. **Execute Stable Diffusion**: Run the image generation tool to save the portrait as a `.webp` file under:
+   - `content/assets/images/characters/CharacterName_Full.webp` (or `ObsidianNotes/_assets/images/characters/` depending on workspace path).
+4. **Markdown Injection**: Inject the image reference at the top of the markdown file:
+   `![CharacterName_Full](./_assets/images/characters/CharacterName_Full.webp)` (use path relative to the markdown file's folder).
+
+### Phase 4: Progressive Disclosure
+To prevent lore documents from getting bloated:
+- Maintain core overview sheets at under 500 lines.
+- Offload long histories, world atlases, and pantheons to a `references/` subdirectory or separate Markdown files, linking them via standard Markdown links.