🎨 Normalize CRLF line endings in workpad docs

This commit is contained in:
Gabor Körber
2026-10-15 10:39:02 +02:00
parent d001f85b82
commit 7d44a9bd91
3 changed files with 133 additions and 133 deletions
@@ -1,5 +1,5 @@
The task is to use this repo to prepare to push to another.
This folder contains one single plugin, which will become g4b_ai basicly as skills, because these are my core skills i use personally most, or at least, replace some that i did, so some are not yet fully adapted. but it is one plugin basicly. however i want to have themed plugins, so this should become a marketplace, which the reliquary is basicly.
the job is to reshape this into a proper base marketplace, and push it afterwards to git@git.g4b.org:dirigence/reliquary.git instead. The .claude folder can stay, but the .claude-plugin e.g. becomes a claude plugin. core claude and readme have to be replaced, they wander also into the plugin, just as the skills folder. the reliquary should also make it possible to be used as claude marketplace and grabbing the tools independently. but it will not be only claude based, we might integrate other marketplace formats, or other skills, parallel. I do assume, this won't be an issue.
The task is to use this repo to prepare to push to another.
This folder contains one single plugin, which will become g4b_ai basicly as skills, because these are my core skills i use personally most, or at least, replace some that i did, so some are not yet fully adapted. but it is one plugin basicly. however i want to have themed plugins, so this should become a marketplace, which the reliquary is basicly.
the job is to reshape this into a proper base marketplace, and push it afterwards to git@git.g4b.org:dirigence/reliquary.git instead. The .claude folder can stay, but the .claude-plugin e.g. becomes a claude plugin. core claude and readme have to be replaced, they wander also into the plugin, just as the skills folder. the reliquary should also make it possible to be used as claude marketplace and grabbing the tools independently. but it will not be only claude based, we might integrate other marketplace formats, or other skills, parallel. I do assume, this won't be an issue.
+29 -29
View File
@@ -1,29 +1,29 @@
- support `SCRIPTS_DIR` (default: `'scripts/'`, these are usually project shipped scripts), `SCRIPTS_STORE` (default: `'/tmp/'`, this is space to store temporary files and scripts) and `SCRIPTS_UV` (default: `''`, this is the executable to run uv) env vars in the skills boot sequence. Only react if that is successful.
- otherwise agent has to figure it out by running check_uv.py
- detect justfiles, makefiles, misefiles, check for uv or python recipes, specificly to run scripts.
- detect if project itself is a python project, or uv is there to be used by the agent.
- check_uv then should:
- detect uv pins (uv.toml, pyproject.toml, pip requirements)
- detect tainted .venv folders: custom files and folders inside .venv, using .venv as multi-python base dir, etc. should lead to a warning, as it shows that `uv` is not fully embraced in that project.
- detect default packages for skills in main check_uv:
- requests or httpx
- python-dotenv
- pydantic v2+
- pytest
- pyyaml
- tomllib or tomli
- mcp
- reiterate env vars, and doing most detections it can do deterministically
- running check_uv should confirm if the agent found the same conclusion. it is a chicken and egg problem, that can result in the fact, that the check_uv will tell the agent, that it detected a different running pattern, than the agent used.
- the agent finally has to decide, which method it keeps. once this is settled, and this can settle fast if everything is preconfigured, the agent is ready to use python, and both conclusions agree.
- the main task in this performative ritual is to ground on how to use scripts in the project.
- this skills' existence is proof, that the user wants to use helper scripts in the project, and wants to utilize a uv installation locally in the project by the agent, and wants the agent to figure out, which one to use, and then not switch around later on, while the task is to actually focus on executing scripts and skills.
- it should also therefore get the idea of where a local scratch pad (SCRIPTS_STORE), project scripts folder (SCRIPTS_DIR), etc. might exist, and can therefore substitute this also as knowledge if it has to work with other tools, that want files or scripts written, but do not define where a certain folder is. These directories build good fallbacks for such concerns, and python therefore a solid tool to support the developer in tasks.
- for full python projects, it is very likely, that the configured uv is also capable of running actual project code, so namespaces should be respected.
- for rust projects, the uv configuration is almost certainly the local python environment for the agent.
- best would be if we would simply run a universal shell that every skill should support and print out env variables that are maybe relevant immediately.
- support `SCRIPTS_DIR` (default: `'scripts/'`, these are usually project shipped scripts), `SCRIPTS_STORE` (default: `'/tmp/'`, this is space to store temporary files and scripts) and `SCRIPTS_UV` (default: `''`, this is the executable to run uv) env vars in the skills boot sequence. Only react if that is successful.
- otherwise agent has to figure it out by running check_uv.py
- detect justfiles, makefiles, misefiles, check for uv or python recipes, specificly to run scripts.
- detect if project itself is a python project, or uv is there to be used by the agent.
- check_uv then should:
- detect uv pins (uv.toml, pyproject.toml, pip requirements)
- detect tainted .venv folders: custom files and folders inside .venv, using .venv as multi-python base dir, etc. should lead to a warning, as it shows that `uv` is not fully embraced in that project.
- detect default packages for skills in main check_uv:
- requests or httpx
- python-dotenv
- pydantic v2+
- pytest
- pyyaml
- tomllib or tomli
- mcp
- reiterate env vars, and doing most detections it can do deterministically
- running check_uv should confirm if the agent found the same conclusion. it is a chicken and egg problem, that can result in the fact, that the check_uv will tell the agent, that it detected a different running pattern, than the agent used.
- the agent finally has to decide, which method it keeps. once this is settled, and this can settle fast if everything is preconfigured, the agent is ready to use python, and both conclusions agree.
- the main task in this performative ritual is to ground on how to use scripts in the project.
- this skills' existence is proof, that the user wants to use helper scripts in the project, and wants to utilize a uv installation locally in the project by the agent, and wants the agent to figure out, which one to use, and then not switch around later on, while the task is to actually focus on executing scripts and skills.
- it should also therefore get the idea of where a local scratch pad (SCRIPTS_STORE), project scripts folder (SCRIPTS_DIR), etc. might exist, and can therefore substitute this also as knowledge if it has to work with other tools, that want files or scripts written, but do not define where a certain folder is. These directories build good fallbacks for such concerns, and python therefore a solid tool to support the developer in tasks.
- for full python projects, it is very likely, that the configured uv is also capable of running actual project code, so namespaces should be respected.
- for rust projects, the uv configuration is almost certainly the local python environment for the agent.
- best would be if we would simply run a universal shell that every skill should support and print out env variables that are maybe relevant immediately.
+99 -99
View File
@@ -1,99 +1,99 @@
# Commit Message Conventions
Every commit message MUST be prefixed with a gitmoji that describes the nature of the change.
Format: `<emoji> <short description>`
## Gitmoji Reference
| Emoji | Description |
|-------|-------------|
| 🎨 | Improve structure / format of the code |
| ⚡️ | Improve performance |
| 🔥 | Remove code or files |
| 🐛 | Fix a bug |
| 🚑️ | Critical hotfix |
| ✨ | Introduce new features |
| 📝 | Add or update documentation |
| 🚀 | Deploy stuff |
| 💄 | Add or update the UI and style files |
| 🎉 | Begin a project |
| ✅ | Add, update, or pass tests |
| 🔒️ | Fix security or privacy issues |
| 🔐 | Add or update secrets |
| 🔖 | Release / Version tags |
| 🚨 | Fix compiler / linter warnings |
| 🚧 | Work in progress |
| 💚 | Fix CI Build |
| ⬇️ | Downgrade dependencies |
| ⬆️ | Upgrade dependencies |
| 📌 | Pin dependencies to specific versions |
| 👷 | Add or update CI build system |
| 📈 | Add or update analytics or track code |
| ♻️ | Refactor code |
| ➕ | Add a dependency |
| ➖ | Remove a dependency |
| 🔧 | Add or update configuration files |
| 🔨 | Add or update development scripts |
| 🌐 | Internationalization and localization |
| ✏️ | Fix typos |
| 💩 | Write bad code that needs to be improved |
| ⏪️ | Revert changes |
| 🔀 | Merge branches |
| 📦️ | Add or update compiled files or packages |
| 👽️ | Update code due to external API changes |
| 🚚 | Move or rename resources (e.g.: files, paths, routes) |
| 📄 | Add or update license |
| 💥 | Introduce breaking changes |
| 🍱 | Add or update assets |
| ♿️ | Improve accessibility |
| 💡 | Add or update comments in source code |
| 🍻 | Write code drunkenly |
| 💬 | Add or update text and literals |
| 🗃️ | Perform database related changes |
| 🔊 | Add or update logs |
| 🔇 | Remove logs |
| 👥 | Add or update contributor(s) |
| 🚸 | Improve user experience / usability |
| 🏗️ | Make architectural changes |
| 📱 | Work on responsive design |
| 🤡 | Mock things |
| 🥚 | Add or update an easter egg |
| 🙈 | Add or update a .gitignore file |
| 📸 | Add or update snapshots |
| ⚗️ | Perform experiments |
| 🔍️ | Improve SEO |
| 🏷️ | Add or update types |
| 🌱 | Add or update seed files |
| 🚩 | Add, update, or remove feature flags |
| 🥅 | Catch errors |
| 💫 | Add or update animations and transitions |
| 🗑️ | Deprecate code that needs to be cleaned up |
| 🛂 | Work on code related to authorization, roles and permissions |
| 🩹 | Simple fix for a non-critical issue |
| 🧐 | Data exploration / inspection |
| ⚰️ | Remove dead code |
| 🧪 | Add a failing test |
| 👔 | Add or update business logic |
| 🩺 | Add or update healthcheck |
| 🧱 | Infrastructure related changes |
| 🧑‍💻 | Improve developer experience |
| 💸 | Add sponsorships or money related infrastructure |
| 🧵 | Add or update code related to multithreading or concurrency |
| 🦺 | Add or update code related to validation |
| ✈️ | Improve offline support |
| 🦖 | Code that adds backwards compatibility |
## Custom Rules
| Emoji | Description |
|-------|-------------|
| 🤖 | Add or update agent files (CLAUDE.md, skills, AGENTS.md, copilot configs, etc.) |
## Initial Commit
New git repositories MUST use the following as their initial commit message:
```
🦇 BATMAN
```
# Commit Message Conventions
Every commit message MUST be prefixed with a gitmoji that describes the nature of the change.
Format: `<emoji> <short description>`
## Gitmoji Reference
| Emoji | Description |
|-------|-------------|
| 🎨 | Improve structure / format of the code |
| ⚡️ | Improve performance |
| 🔥 | Remove code or files |
| 🐛 | Fix a bug |
| 🚑️ | Critical hotfix |
| ✨ | Introduce new features |
| 📝 | Add or update documentation |
| 🚀 | Deploy stuff |
| 💄 | Add or update the UI and style files |
| 🎉 | Begin a project |
| ✅ | Add, update, or pass tests |
| 🔒️ | Fix security or privacy issues |
| 🔐 | Add or update secrets |
| 🔖 | Release / Version tags |
| 🚨 | Fix compiler / linter warnings |
| 🚧 | Work in progress |
| 💚 | Fix CI Build |
| ⬇️ | Downgrade dependencies |
| ⬆️ | Upgrade dependencies |
| 📌 | Pin dependencies to specific versions |
| 👷 | Add or update CI build system |
| 📈 | Add or update analytics or track code |
| ♻️ | Refactor code |
| ➕ | Add a dependency |
| ➖ | Remove a dependency |
| 🔧 | Add or update configuration files |
| 🔨 | Add or update development scripts |
| 🌐 | Internationalization and localization |
| ✏️ | Fix typos |
| 💩 | Write bad code that needs to be improved |
| ⏪️ | Revert changes |
| 🔀 | Merge branches |
| 📦️ | Add or update compiled files or packages |
| 👽️ | Update code due to external API changes |
| 🚚 | Move or rename resources (e.g.: files, paths, routes) |
| 📄 | Add or update license |
| 💥 | Introduce breaking changes |
| 🍱 | Add or update assets |
| ♿️ | Improve accessibility |
| 💡 | Add or update comments in source code |
| 🍻 | Write code drunkenly |
| 💬 | Add or update text and literals |
| 🗃️ | Perform database related changes |
| 🔊 | Add or update logs |
| 🔇 | Remove logs |
| 👥 | Add or update contributor(s) |
| 🚸 | Improve user experience / usability |
| 🏗️ | Make architectural changes |
| 📱 | Work on responsive design |
| 🤡 | Mock things |
| 🥚 | Add or update an easter egg |
| 🙈 | Add or update a .gitignore file |
| 📸 | Add or update snapshots |
| ⚗️ | Perform experiments |
| 🔍️ | Improve SEO |
| 🏷️ | Add or update types |
| 🌱 | Add or update seed files |
| 🚩 | Add, update, or remove feature flags |
| 🥅 | Catch errors |
| 💫 | Add or update animations and transitions |
| 🗑️ | Deprecate code that needs to be cleaned up |
| 🛂 | Work on code related to authorization, roles and permissions |
| 🩹 | Simple fix for a non-critical issue |
| 🧐 | Data exploration / inspection |
| ⚰️ | Remove dead code |
| 🧪 | Add a failing test |
| 👔 | Add or update business logic |
| 🩺 | Add or update healthcheck |
| 🧱 | Infrastructure related changes |
| 🧑‍💻 | Improve developer experience |
| 💸 | Add sponsorships or money related infrastructure |
| 🧵 | Add or update code related to multithreading or concurrency |
| 🦺 | Add or update code related to validation |
| ✈️ | Improve offline support |
| 🦖 | Code that adds backwards compatibility |
## Custom Rules
| Emoji | Description |
|-------|-------------|
| 🤖 | Add or update agent files (CLAUDE.md, skills, AGENTS.md, copilot configs, etc.) |
## Initial Commit
New git repositories MUST use the following as their initial commit message:
```
🦇 BATMAN
```