Rules & On-Demand Skills

Enforce architectural guardrails and activate specialized capabilities dynamically without permanent context window penalties.

Project Rules & AGENTS.md

Enforce architectural invariants, styling rules, and testing standards across your entire engineering team using project-level rule files.

Place a file named .kernax/rules or AGENTS.md in your workspace root. Kernax injects these rules as authoritative constraints into every agent turn:

# Project Architecture Invariants
- Language: TypeScript 5.5+ with strict null checks.
- State Management: Use Zustand stores only; never use Redux or raw React Context for global state.
- Database: All queries must pass through Prisma ORM. Raw SQL is strictly forbidden.
- Testing: Every public endpoint in `src/routes/` requires an accompanying integration test in `tests/`.
- Styling: Tailwind CSS classes only. Do not write vanilla CSS files.

Global Engineering Directives

If you want certain conventions to apply to all projects on your workstation (such as personal indentation preferences, git commit conventions, or favorite libraries), place them in:

# Global Developer Preferences
- Always write concise, production-ready code with zero placeholder comments (`// TODO`).
- Follow the Conventional Commits specification for all suggested commit messages.
- Prefer functional paradigms with immutable data structures where practical.

Zero-Token-Waste On-Demand Skills

Traditional AI tools force you to stuff dozens of pages of instructions into the global system prompt, needlessly burning thousands of tokens on every single interaction.

Kernax introduces On-Demand Skills. Skills live as modular instruction folders in ~/.kernax/skills/<skill-name>/SKILL.md.

Creating Custom Skills

To create a reusable engineering skill, add a directory inside ~/.kernax/skills/ with a SKILL.md file containing YAML frontmatter:

---
name: docker-hardening
description: Best practices for auditing and hardening Dockerfiles for production security.
---
# Docker Hardening Instructions
When authoring or modifying Dockerfiles:
1. Always use multi-stage builds to minimize runtime image footprint.
2. Pin base images to specific sha256 digests or exact patch versions (e.g. `node:22.4-alpine`).
3. Run container processes under a non-root user (`USER node`).
4. Ensure `.dockerignore` excludes `.git`, `.env`, and test artifacts.

Whenever you ask the agent to "Review our container setup", Kernax matches the description, mounts docker-hardening into that turn, and unmounts it immediately afterward.