Cerneala is free to inspect, use, modify, and improve in public. Maintainer time is finite. Developers who need faster bug-fix attention or custom implementation work can pay for a priority lane.
> repository.mode
OPEN_SOURCE> execution.model
AI_NATIVE + HUMAN_REVIEW> preferred.engineering_model
OPENAI_GPT_5_6_OR_NEWER> contributor.rule
USE_THE_REPO_TOOLING> forbidden.mutations
CLAUDE_MDCommercial support does not create a private, better Cerneala. It purchases scheduled maintainer attention for the problem that matters to your project.
No guaranteed response window. A good reproduction, a red test, CSI evidence, and a narrow PR move dramatically faster than "button weird, please fix."
Open an issueYou are paying for focused maintainer time, not permission to bypass tests, architecture, documentation, or the public quality bar.
Contact the maintainerDo not try to hold the entire repository in your human working memory. That is not a test of intelligence. It is an inefficient way to misunderstand a large, fast-evolving system.
It established a large part of the initial surface and also made several architectural and implementation mistakes. Historical contribution acknowledged. New engineering work not approved.
Sol corrected substantial parts of the earlier work, implemented major systems properly, strengthened repository navigation and tests, and became the minimum trusted OpenAI engineering baseline.
OpenAI 5.6 or newer is approved. Any Anthropic model with version 5.5 or higher (for example Opus 5.5, Sonnet 5.5, Haiku 5.5) is approved for core engineering and visual work. Any Anthropic model below version 5.5, including Fable 5.1, is not approved for core engineering. Future models earn trust through observed compliance and repository evidence, not provider branding.
Cerneala has the surface area of a repository that would normally require 40+ developers. Its maintainer is one person. Trying to understand every subsystem at once is not diligence; it is a fast route to losing your mind. Give a capable agent the exact scenario, let it load the local context, read the repository instructions, read files directly, use rg for text search and Roslyn MCP for C# symbols, run focused experiments, create tests, and show you evidence. Your job is intent, judgment, review, and deeply understanding the slice you are actually changing.
There is no sacred way to learn Cerneala. Read the implementation, ask a capable AI to translate it into simple language, or work through the enormous documentation surface. Mix all three if that is faster. The choice is yours.
Read files directly for definitions, tests, and the surrounding contracts; use rg for text search.
Browse the sourceAsk what happens, why it exists, and which contracts matter. Request a simple explanation grounded in current files, symbols, tests, and runtime flow. Then inspect the cited evidence instead of trusting confident vapor.
Explain simply how this subsystem works. Show me the relevant source and tests.
Use the API reference, architecture notes, WPF Compendium, roadmap, plans, diagrams, and system guides. The documentation is deliberately massive because the framework is deliberately massive.
This is a repository contribution policy, not a universal leaderboard. Core engineering requires models that can sustain architecture, tool discipline, long context, testing, and precise changes across a large C# codebase.
Every workflow below is an executable skill versioned with Cerneala. Codex loads it from .codex/skills/ and Claude Code loads it from .claude/skills/. Both copies enforce the same contract; the Claude Code copies are adapted to Claude Code's tools.
Codex: $cerneala-fix-bug <your request>
Claude Code: /cerneala-fix-bug <your request>
.codex/skills/<skill-name>/SKILL.md
.claude/skills/<skill-name>/SKILL.md
$cerneala-checklist-plan/cerneala-checklist-planUse it after the behavior, architecture, and open questions have already been discussed. It turns that settled discussion into one or more implementation-ready Markdown plans under docs/plans/, grounded in the current code.
[ ] checklists with explicit, observable gates$cerneala-implement-plan/cerneala-implement-planGive it a plan name. It executes the plan end to end, exactly one stage per batch, and checks a stage off in the plan file only after that stage is verified.
/git-session-commit-push, which commits on a branch and opens a pull request$cerneala-fix-bug/cerneala-fix-bugGive it the visible failure, the expected result, the reproduction steps, and any diagnostics. It reproduces the failure, proves it with a RED test, makes the smallest architecture-correct fix, and verifies the same scenario again.
/git-session-commit-push, which commits on a branch and opens a pull request$cerneala-performance-gate/cerneala-performance-gateUse it for observable lag, stutter, slow startup, CPU, allocation, memory, GPU, or frame-time failures, and only with a concrete threshold. “Make it faster” is not a gate.
/git-session-commit-push, which commits on a branch and opens a pull request$github-issue-raise/github-issue-raiseTurns a discovered Cerneala bug into a GitHub issue that meets the contribution bar. The other skills invoke it on their own when they find a defect.
.artifacts/issue-drafts/$cerneala-breaker/cerneala-breakerGive it a concrete Cerneala API, subsystem, backend, feature, or scenario. It tries to break the documented contract with bounded hostile tests. Unsupported criticism does not count as a finding.
$algorithm-market/algorithm-marketUse it before committing Cerneala to a nontrivial algorithm. It researches established candidates across primary research and production implementations, then separates the strongest absolute method from the best fit for the actual constraints.
$repo-cleanup/repo-cleanupUse it to simplify, deduplicate, or modularize a named area without changing behavior. Leaving sound code alone is a valid result.
/git-session-commit-push, which commits on a branch and opens a pull request$writing-api-documentation/writing-api-documentationUse it to create or update public API documentation from the implementation, tests, established contracts, and existing canonical pages. Names alone are not evidence of behavior.
docs-site/documentation/classes/ and keeps the manifest in sync/git-session-commit-pushCommits and pushes the work of the current conversation in Cerneala's structured commit style, always on a branch, and opens a pull request against master. Invoking it is the approval; it does not ask again. It ships in .claude/skills/; Codex users keep it as a personal skill.
origin/master and opens a session/… branch; on another branch it commits theretype(scope): subject commit with themed sections and a Verification blockcerneala_roslynNot a skill, but the tool the skills lean on. This local MCP server gives Codex and Claude Code real C# symbol navigation over the saved Cerneala.slnx, including members generated from markup. It answers “who calls this?” and “what implements this?” with compiler-level identity instead of text matches. It is pinned to mcpRoslyn v1.4.0 (MIT) with a Roslyn 5.9 patch.
pwsh -NoProfile -File ./Tools/scripts/Install-RoslynMcp.ps1, then run dotnet build ./CernealaPresentation/CernealaPresentation.csproj -c Debug so the source generators have build outputs for the workspace to load.codex/config.toml and for Claude Code in .mcp.json. The Codex config allows twelve navigation tools (workspace_symbol, find_references, find_callers, …) and denies rename_symbol. .mcp.json only registers the server, so Claude Code users restrict its tools in their own local settingsmcpRoslyn.exe. It loads the solution at the first Roslyn call and holds about 1 GB of RAM while it is used. 60 seconds after the last call it unloads the solution and drops to about 100–240 MB, and the next call loads it again in 25–50 seconds. The launcher ends it together with its sessionUse the cerneala-checklist-plan skill to turn our completed discussion into implementation-ready Cerneala checklist plans under docs/plans/. Do not implement the code yet.Use the cerneala-implement-plan skill to implement <plan-name> end to end. Work one stage per batch and check off each stage only after it is implemented and verified.Use the cerneala-fix-bug skill to investigate and fix this Cerneala bug end to end.
Location / custom view:
[describe the affected scenario]
Reproduction:
1. [exact action]
2. [exact action]
3. [observed failure]
Expected:
[what should happen]
Actual:
[what happens instead]
Diagnostics:
[exceptions, traces, screenshots, frame stats, or none]
Reproduce the failure before editing production code, add a focused RED regression test, implement the smallest architecture-correct fix, repeat the automated reproduction, and run the complete repository test suite until GREEN.
Do not claim that you manually tested the real application scenario. Give me the exact steps and expected result so I can perform that validation myself.The agent owns automated evidence. The user owns the real application check. If either side is still red or unconfirmed, the PR is not ready.
No unrelated cleanup, accidental metadata churn, or wholesale rewrite because the agent became artistically inspired.
Bug PRs carry a reliable reproduction. Feature PRs carry the staged checklist that governed the work.
A bug began red. New behavior has contract tests. Every repository test passes after the final implementation.
The user exercised the actual view or Playground scenario and reported the result. The agent must not fabricate this evidence.
Public APIs and developer-facing contracts are documented in the repository source of truth.
Known gaps and uncertainty are stated plainly. The maintainer should not need archaeology to discover what remains.