Khaos-Brain: Skill for Codex

When this skill is used, follow this workflow:

Rule authority:

• Treat PROJECT_SPEC.md as the canonical source for thresholds, maintenance boundaries, and governance rules.
• Treat docs/maintenance_runbook.md as the canonical operational runbook for sleep maintenance.
• Keep this skill focused on the workflow shape. If this skill and the spec disagree, follow the spec.

Default stance: run a quick scan first for repository tasks; keep the scan lightweight unless the returned entries are clearly relevant. This includes GitHub publish work, release audits, README presentation passes, public template cleanup, and repo-boundary/privacy review. Those still count as repository tasks and should not bypass the scan. Keep the active path mathematically simple and easy to audit. During normal task flow, retrieval should use explicit additive rules and should not try to normalize or repair the KB inline.

Preferred Codex operating pattern:

• For non-trivial work, start a read-oriented kb-scout sidecar sub-agent before the main task so the primary agent can stay focused on the critical path.
• For long mixed tasks, add phase-change KB checkpoints to the plan. Re-run retrieval before a substantially different action class or risk surface begins, such as moving from analysis to code edits, from edits to packaging, from local validation to GitHub push/tag/release, or into privacy-sensitive, organization-KB, automation, or public-publication work. Do not rerun retrieval for every repeated same-type subtask.
• After the main task, treat KB postflight as part of done. Start a kb-recorder sidecar sub-agent whenever the task exposed feedback worth keeping, comments, misses, route gaps, card weaknesses, or candidate lessons.
• Run deeper consolidation in a separate scheduled maintenance conversation or automation rather than inside the main task thread.
• If sub-agents are unavailable, or if the task is trivial, fall back to a lightweight inline scan and inline feedback note.

Rule discipline:

• Keep retrieval scoring as a simple additive rule: structural route evidence + lexical evidence + small confidence/status adjustment.
• Do not let confidence or status create a hit by themselves. They may rerank plausible matches, but they should not turn unrelated entries into matches.
• Keep runtime survival separate from KB repair. A malformed lexical candidate may be excluded, but missing or inconsistent exact LogicGuard authority is a visible failure. Never continue through a readable-card, legacy-YAML, or floating-head fallback; leave repair and republication to Sleep or the versioned upgrade owner.
• Keep parameters few and fixed. Prefer counts, weights, and thresholds that a human can inspect over adaptive or opaque heuristics.
• Keep canonical machine interfaces separate from localized display projection. CLI tools, installed launchers, automation payloads, and installer checks should use canonical machine output and encoding-stable JSON; Chinese display belongs in i18n.zh-CN, route display labels, and UI view models.

Sleep maintenance lanes:

• deterministic repair: schema normalization, field-type cleanup, canonical path alignment, low-ambiguity formatting, and other fixes that can be expressed as fixed rules and validated mechanically.
• semantic repair: LogicGuard model revisions, ModelMesh membership or grounded relation changes, candidate creation, merges, promotions, deprecations, taxonomy changes, and other changes that depend on accumulated evidence rather than a single malformed field.
• Keep semantic auto-apply thresholds simple. Do not restate every threshold here; use the canonical thresholds from PROJECT_SPEC.md and docs/maintenance_runbook.md.
• If a change does not satisfy a deterministic rule or a simple semantic threshold, leave it as a proposal for a later maintenance pass.

Independent maintenance thread:

• Use a separate maintenance chat or automation for the library's "sleep" workflow. Do not let deep consolidation interrupt the user's main task thread.
• In the current implementation, Sleep may safely publish exact model generations, deterministic card projections, history events, consolidation artifacts, rollback manifests, candidate models, and explicit decision traces for ignored observations, rejected candidates, model gaps, and confidence reviews.
• Do not treat the current tooling as permission to rewrite trusted models or restructure taxonomy silently inside a main task. Durable model and mesh changes belong to Sleep; Dream and ordinary retrieval remain read-only.
• A practical active-build cadence is once per day. For calmer periods, two or three times per week is usually enough.