Documentation Index
Fetch the complete documentation index at: https://mintlify.com/xxyoudeadpunkxx/csbp-codex-shared-best-practice/llms.txt
Use this file to discover all available pages before exploring further.
shared-best-practice-compiler.txt is the practice formation layer. It defines the rules for evaluating candidates, normalizing them into runtime block shape, and managing the full practice lifecycle. It is a fixed file — never modified.
File identity
| Property | Value |
|---|---|
| Name | shared-best-practice-compiler.txt |
| Version | 0.1 |
| Role | Practice formation and evaluation |
| Mutable | No — fixed system-definition layer |
Object and non-object
The compiler is for:- Evaluate recurring global or environment-global operational best practices
- Normalize candidates into runtime block shape
- Promote valid candidates to
shared-best-practice.txt - Revise candidates where wording, scope, or split needs work
- Deprecate active practices that no longer meet criteria
- Remove deprecated or invalid practices from
shared-best-practice.txt - Reject candidates that are not suitable for shared runtime practice
- Replacing
AGENTS.md - Replacing local project instructions or project-local guidance
- Storing project-specific instructions
- Storing policy, tone, or style guidance
- Storing one-off fixes
- Storing recovery-only logic
- Storing speculative advice
- Storing broad behavioral framing
Input types
The compiler accepts the following inputs from the operator:- Operator observation
- Free-text description
- Conversation fragment
- Rough hypothesis
- Reported recurring mistake
- Reported recurring omission
- Reported recurring missed opportunity during real work
Discussion
When working with a candidate, the compiler protocol may:- Reinterpret the reported issue
- Identify the likely underlying pattern
- Split multiple patterns
- Merge similar patterns
- Narrow or broaden the formulation
- Classify the issue as operational-level, policy-level, project-specific, or too weak in recurrence, scope, or clarity for promotion
External check
The compiler may suggest a lightweight web check when outside recurrence could materially clarify the decision. An external check is optional and is for practical corroboration, not proof. Prefer primary practical sources with direct relevance — sources close to the real environment, tool, workflow, or issue being discussed. Avoid broad or unnecessary research.Admission and rejection criteria
See the Admission Criteria reference for the full list of admit and reject criteria.Normalization rules
Candidate practices must be normalized before promotion. The compiler applies the following rules:- Rewrite as a preventive default
- Rewrite as a runtime-ready instruction
- Keep one pattern per practice
- Remove narrative
- Remove non-operational explanation
- Remove project-specific detail
- Prefer short stable wording
- Prefer direct verbs
- Avoid fallback phrasing
- Avoid recovery-first phrasing
Block shape
Every promoted practice uses this fixed eight-field shape:Field rules
Use
PNNN sequential format. Assigned only at operator-approved promotion — never in a proposal draft. Never reused.Classify the practice as
global or environment-global.Classify the primary role of the practice for runtime interpretation.
Describe the operational condition, not the project.
State the intended operational effect.
State the primary correct default action.
State the recurring wrong pattern.
Scope values
| Value | Meaning |
|---|---|
global | Stable across work contexts |
environment-global | Stable across the current working environment across sessions |
Kind rules
| Value | Use for |
|---|---|
environment | Stable environment conditions, constraints, or affordances |
orientation | Setup, framing, or initial approach during real work |
operation | Operational actions or working methods during real work |
verification | Checking, confirmation, or closure practices |
Block quality rules
One practice = one recurring pattern. Split if more than one main action or wrong pattern is present. Rewrite or reject if too broad, too narrow, overly explanatory, or not usable during real work. If revise produces a split, evaluate each fragment independently before promotion.
Compiler decisions
There are five possible decision outcomes:promote— candidate is ready for runtime use and entersshared-best-practice.txtrevise— candidate is valid but wording, scope, or split needs work; revision happens in the same working passreject— candidate is not suitable for shared runtime practicedeprecate— active practice becomes deprecated; excluded from runtime useremove— deprecated or invalid practice is deleted fromshared-best-practice.txt
Proposal shape
Formation proposals use this shape:id field is left unassigned until operator-approved promotion.
Lifecycle
Runtime maintenance
Runtime maintenance operations are:- Revise active practice
- Deprecate active practice
- Remove deprecated or invalid practice
Maintenance rule
Remove rule
- Remove a deprecated practice only on direct operator instruction
- Remove an invalid active practice only on direct operator instruction
- Do not remove a runtime practice during normal runtime use
Promotion
Only promoted practices entershared-best-practice.txt.
Runtime relation
shared-best-practice.txt is the runtime layer loaded after CSBP-entry-point.txt. Apply active practices only when relevant. Do not let runtime practices override operator instruction, AGENTS.md, or local project instructions or project-local guidance.