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
AGENTS_MD / ROSLYN_INDEXERCommercial 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. Anthropic Fable-tier models or newer peers are approved. The standard rises with capable models instead of preserving nostalgia for weaker ones.
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, navigate through RoslynIndexer, 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.
Follow the exact subsystem you care about through RoslynIndexer. Read definitions, references, tests, and the surrounding contracts instead of scanning random folders until your eyes file for divorce.
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.
Cerneala keeps these two Codex skills under .codex/skills/ for the handoff between a resolved engineering discussion and verified implementation. Codex can load the workflow directly from the repository that owns it.
$cerneala-checklist-plan
Use it after the requirements, behavior, architecture, and open questions have already been discussed. It turns that context into one or more implementation-ready Markdown plans under docs/plans/.
[ ] checklists with explicit gates$cerneala-implement-plan
Give it the plan name and it creates a persistent /goal, audits the remaining checklist, and implements the work end to end in coherent, verifiable batches.
[x] only after a batch is implemented and verified.codex/skills/cerneala-checklist-plan/
.codex/skills/cerneala-implement-plan/
Use $cerneala-checklist-plan to turn our completed discussion into implementation-ready Cerneala checklist plans under docs/plans/. Do not implement the code yet.Use $cerneala-implement-plan to implement <plan-name> end to end. Create a persistent /goal and check off each item only as its batch is completed and verified.CernealaFixBug carries the old bug-fix protocol as an executable Codex workflow: reproduce the actual failure, prove it red, make the smallest correct change, and verify the same scenario again.
$cerneala-fix-bug
Give the skill the user-visible failure, expected result, reproduction steps, and whatever diagnostics you have. It drives the fix from evidence instead of treating the first plausible theory like holy scripture.
Reduce the report to a deterministic failing scenario and capture the relevant state.
Add a focused regression test that fails for the observed contract violation.
Change the owning implementation without speculative rewrites or unrelated cleanup.
Repeat the automated reproduction, then run focused tests and the complete repository suite.
.codex/skills/cerneala-fix-bug/
Repository skill, versioned with Cerneala
Use $cerneala-fix-bug 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.