القائمة
Core architectural principles governing the design, layout, and execution of the Kest toolkit. Strictly reference these principles before creating new components or refactoring.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Key principles for designing reliable, polyglot libraries. Use this skill when making structural or design decisions for the Kest toolkit.
Use this skill when you need documentation for a third-party library, SDK, or API before writing code that uses it (e.g. "use the OpenAI API", "call the Stripe API"). Fetch the docs with chub before answering, rather than relying on training knowledge. Also used for maintaining project-specific context via the :sync-docs task.
This skill should be used when the user asks to "configure moon", "set up moonrepo", "create moon tasks", "run moon commands", "configure moon workspace", "add moon project", "moon ci setup", "moon docker", "moon query", "migrate to moon v2", or mentions moon.yml, .moon/workspace.yml, .moon/toolchains.yml, moon run, moon ci, or moonrepo in general.
This skill should be used when the user asks to "install proto", "configure proto", "manage tool versions", "pin versions", "set up .prototools", "install node version", "install rust version", "install python version", "proto plugins", or mentions proto commands, .prototools file, or multi-language version management.
Standard software engineering and testing practices (TDD, SRP, DI) for library development. Reference this skill before writing tests or designing new logic.
| name | principles |
| description | Core architectural principles governing the design, layout, and execution of the Kest toolkit. Strictly reference these principles before creating new components or refactoring. |
These principles govern the design, layout, and execution of the Kest global toolkit. As an AI Agent, you must strictly reference and follow these principles before making structural or design decisions.
The repository is modular. Every package lives in libs/<feature>/<language> and must be independently testable and deployable. Packages do not cross-pollinate directly outside of explicit dependency declarations.
Transparency is mandatory for all operations:
DESIGN.md in the package root).The showcase/ partition is strictly for deployable or runnable demonstrations (e.g., Docker environments, k3d clusters). Demos must be polished and instructional.
Tests reside immediately alongside the logic (_test.py), except for extensive integration/E2E tests which belong in a dedicated test suite or showcase.
Keep library boundaries small and focused. Favor readability over cleverness.
Core domain logic must not rely on presentation details (e.g., FastAPI, Keycloak). Integrations belong in explicit ext (extension) packages.
Ad-hoc scripts and internal scratchpads must be isolated in the .gitignored /scratchpad/ directory. They must not pollute the main repository. Proper examples meant for teaching will eventually live in version-tracked directories.
To keep this prompt concise, deeper context is stored locally. If you need explicit examples or supplemental context regarding principles, use your list_dir or view_file tools to explore the examples/ and resources/ subdirectories in this skill folder.