Your Claude Code AI assistant, elevated to professional standards
100% Factual Accuracy |
82% Token Savings |
50% Faster Response |
100% Constitutional |
- ⚡ Quick Start
- ✨ Features
- 📁 Rule Files
- 📦 Installation
- 📂 Design Documentation Structure
- 🔗 Integration Guide
- 🎓 Framework Highlights
- 🖼️ Visual Guide
- 📊 Before & After
- 📊 Performance Metrics
- 🔒 Safety Guarantees
- 🤝 Contributing
- 📜 License
- 🙏 Acknowledgments
Use the script for your platform. Both install the current active runtime rules only.
# Clone once
if [ ! -d "claude-code-rules" ]; then
git clone https://github.com/DarKWinGTM/claude-code-rules.git
fi
cd claude-code-rules || exit 1
# Install active runtime rules into ~/.claude/rules/
mkdir -p "$HOME/.claude/rules"
rule_files=(
accurate-communication.md
technical-snapshot-communication.md
response-closing-and-action-framing.md
answer-presentation.md
anti-mockup.md
anti-sycophancy.md
artifact-initiation-control.md
authority-and-scope.md
custom-agent-selection-priority.md
dan-safe-normalization.md
document-consistency.md
document-changelog-control.md
document-design-control.md
document-patch-control.md
emergency-protocol.md
evidence-grounded-burden-of-proof.md
explanation-quality.md
external-verification-and-source-trust.md
flow-diagram-no-frame.md
functional-intent-verification.md
memory-governance-and-session-boundary.md
natural-professional-communication.md
no-variable-guessing.md
operational-failure-handling.md
phase-implementation.md
portable-implementation-and-hardcoding-control.md
project-documentation-standards.md
recovery-contract.md
refusal-classification.md
refusal-minimization.md
runtime-topology-control.md
safe-file-reading.md
safe-terminal-output.md
strict-file-hygiene.md
tactical-strategic-programming.md
todo-standards.md
unified-version-control-system.md
zero-hallucination.md
high-signal-communication.md
execution-continuity-and-mode-selection.md
goal-set-review-and-priority-balance.md
)
for file in "${rule_files[@]}"; do
cp "$file" "$HOME/.claude/rules/$file"
done# Clone once
if (-not (Test-Path "claude-code-rules")) {
git clone https://github.com/DarKWinGTM/claude-code-rules.git
}
Set-Location claude-code-rules
# Install active runtime rules into ~/.claude/rules/
$rulesDir = Join-Path $HOME ".claude/rules"
New-Item -ItemType Directory -Force -Path $rulesDir | Out-Null
$ruleFiles = @(
"accurate-communication.md",
"technical-snapshot-communication.md",
"response-closing-and-action-framing.md",
"answer-presentation.md",
"anti-mockup.md",
"anti-sycophancy.md",
"artifact-initiation-control.md",
"authority-and-scope.md",
"custom-agent-selection-priority.md",
"dan-safe-normalization.md",
"document-consistency.md",
"document-changelog-control.md",
"document-design-control.md",
"document-patch-control.md",
"emergency-protocol.md",
"evidence-grounded-burden-of-proof.md",
"explanation-quality.md",
"external-verification-and-source-trust.md",
"flow-diagram-no-frame.md",
"functional-intent-verification.md",
"memory-governance-and-session-boundary.md",
"natural-professional-communication.md",
"no-variable-guessing.md",
"operational-failure-handling.md",
"phase-implementation.md",
"portable-implementation-and-hardcoding-control.md",
"project-documentation-standards.md",
"recovery-contract.md",
"refusal-classification.md",
"refusal-minimization.md",
"runtime-topology-control.md",
"safe-file-reading.md",
"safe-terminal-output.md",
"strict-file-hygiene.md",
"tactical-strategic-programming.md",
"todo-standards.md",
"unified-version-control-system.md",
"zero-hallucination.md",
"high-signal-communication.md",
"execution-continuity-and-mode-selection.md",
"goal-set-review-and-priority-balance.md"
)
foreach ($file in $ruleFiles) {
Copy-Item $file (Join-Path $rulesDir $file) -Force
}- Already cloned the repo? Skip the clone step and run the install block only.
- Need project-specific install instead? Change the destination from
~/.claude/rules/to./.claude/rules/. - This runtime-only install copies active rule files only. Governed design/changelog/TODO artifacts plus
phase-implementation-template.mdremain in the repository for maintenance and synchronized updates.
If you want an AI CLI to install or adapt this repo for you, paste one of these prompts directly into that tool.
Claude Code — native install into ~/.claude/rules/
Install this rules repo for me from:
https://github.com/DarKWinGTM/claude-code-rules
Requirements:
- clone the repo if needed
- read the README Quick Start section first
- install only the active runtime rule set into ~/.claude/rules/
- do not install files from suspend/, support/, plugin/, design/, changelog/, phase/, patch/, or TODO.md
- verify the installed files after copying
- report exactly what was installed
Codex CLI — adapt active rules into AGENTS.md
Use this repo as the source of truth:
https://github.com/DarKWinGTM/claude-code-rules
Please:
- clone or inspect the repo
- read the README Quick Start and active root rule set
- create/update AGENTS.md for this project so Codex follows the same active rule intent
- adapt the rules into Codex-native instructions instead of copying Claude-specific runtime structure blindly
- ignore files under suspend/, support/, plugin/, design/, changelog/, phase/, patch/, and TODO.md unless explicitly needed as reference
- keep the result concise but faithful to the active rules
- summarize which source rules were mapped into AGENTS.md
Gemini CLI — adapt active rules into GEMINI.md
Use this repo as the source of truth:
https://github.com/DarKWinGTM/claude-code-rules
Please:
- clone or inspect the repo
- read the README Quick Start and active root rule set
- create/update GEMINI.md for this project so Gemini CLI follows the same active rule intent
- adapt the rules into Gemini-native instructions instead of copying Claude-specific runtime structure blindly
- ignore files under suspend/, support/, plugin/, design/, changelog/, phase/, patch/, and TODO.md unless explicitly needed as reference
- keep the result concise but faithful to the active rules
- summarize which source rules were mapped into GEMINI.md
When to use which prompt
- Use the Claude Code prompt when you want direct runtime installation into
~/.claude/rules/ - Use the Codex CLI prompt when you want equivalent behavior through
AGENTS.md - Use the Gemini CLI prompt when you want equivalent behavior through
GEMINI.md
|
|
|
|
Fundamental principles that govern all AI behavior
| Rule | Purpose | Key Benefit |
|---|---|---|
anti-mockup.md |
Real systems over simulations | No fake implementations |
anti-sycophancy.md |
Truth over agreement | Honest feedback that stays calm, claim-focused, and free of praise-heavy softening |
zero-hallucination.md |
Verified information only | 100% accuracy |
Ensure consistent, safe, and well-documented outputs
| Rule | Purpose | Key Benefit |
|---|---|---|
accurate-communication.md |
Clear, honest communication | No vague claims, no over-strong contradiction wording, reusable partial-evidence technical snapshot wording, stronger human-language glosses, easy-explanation continuity so plain Thai explanations stay simple through the full answer, clearer explanation of variables/fields/config keys/internal labels when answers depend on them, goal-qualified proposal wording for advisory future-work ideas, honest duplicate-looking team-agent reporting, governing-basis clarification before deep branch analysis, compact post-compact re-anchor wording, explicit memory-derived-context disclosure wording for path-matched remembered context, natural-professional wording, direct human-readable action/result wording preferred over metaphor-heavy internal shorthand, main-point-first framing for diagnosis/test/recommendation/proposal/update answers, continuation-first guidance, clearer recommendation-plus-reason next-step wording that still preserves alternatives when multiple paths are real, and active summaries that keep resolved topics available for reasoning without repeating them as current issues by default |
artifact-initiation-control.md |
Startup artifact governance | Resolve design/changelog/TODO/phase/patch posture before meaningful governed work drifts, initialize live task tracking early when non-trivial work needs visible execution state, treat phase-backed live task tracking as expected startup behavior, keep initialized live task lists as the continuing surface for the active objective, keep newly encountered unclear files in classification-first posture rather than disposal-first posture, and keep patch non-default during greenfield startup unless a real before/after review surface exists |
authority-and-scope.md |
Decision hierarchy | User authority respected, checked master/governed repo surfaces outrank git-state cleanup heuristics when classifying file meaning, fresh user directives override previously offered assistant options, unnecessary option branching is discouraged when one safe continuation path already exists, future-work proposals stay advisory until explicitly selected, user-declared RULES-first issues stay RULES-first instead of being diverted into memory-first fixes, memory applicability now defers to the dedicated memory-governance owner, non-matching path-scoped remembered context cannot override the current repo/objective, unresolved governing-basis selection stays user-owned unless authority/evidence already settles it, compacted-session continuation re-anchors to the latest active directive and active frame, and overlapping team expansion stays advisory unless a distinct new role is actually needed |
custom-agent-selection-priority.md |
Custom agent selection priority | Prefer visible user custom agents as the primary specialist pool when a task clearly matches them, and reuse an existing matching teammate before spawning another overlapping team role |
dan-safe-normalization.md |
Prompt-wrapper normalization | Safer intent evaluation before decisioning |
document-consistency.md |
Cross-reference validation | Keeps portable, source-side, destination/runtime, local execution, and reusable source-artifact references from drifting into each other so tool-local paths do not silently become skill/plugin/source contracts, and requires governed reference/history checks before junk/disposal classification |
document-changelog-control.md |
Version tracking system | Single Source of Truth |
document-design-control.md |
Design document standards | Standardized structure plus required capture of implementation-relevant truth extracted from external docs/specs/provider references when later work still depends on it |
document-patch-control.md |
Patch Control | Governed patch/review artifacts kept separate from the live /phase execution workspace, defined as before/after artifacts, required to show explicit change surfaces, able to surface the external-requirement basis when review depends on it, and not treated as the default startup artifact for greenfield baseline formation |
emergency-protocol.md |
Crisis response | Fast, safe reactions |
evidence-grounded-burden-of-proof.md |
Evidence-threshold judgment | One first-class authority for burden-of-proof thresholds, contradiction protocol, fact/inference/hypothesis separation, scoped negative-evidence semantics, unresolved governing-basis uncertainty handling, remembered path-matched context as a distinct evidence/claim state, post-compact needs-recheck handling for compacted carry-forward exact detail, and explicit limits on using git-state evidence for disposal conclusions |
external-verification-and-source-trust.md |
External verification and source trust | Proactive web-backed fact checking, source ranking, corroboration, and honest source-conflict handling |
functional-intent-verification.md |
Intent validation | Commands verified before run, with a real destructive delete guard that blocks cleanup/isolation rationale from acting as deletion authorization |
memory-governance-and-session-boundary.md |
Memory governance and session boundary | Treat memory as scoped reusable context rather than active authority, keep root MEMORY.md as an active index only, use global/path/archive semantics, make path the primary applicability key, keep session IDs as provenance only, keep archived memory inactive by default, and keep any optional external recall generic, supplemental, availability-checked, and subordinate to stronger checked execution surfaces |
operational-failure-handling.md |
Operational failure policy | Bounded retry ceilings, honest cooldown guidance, and stop/escalation behavior for technical failures, including inspect-first handling for duplicate-looking or stale team-agent presence |
phase-implementation.md |
Phase planning semantics | First-class /phase + SUMMARY.md model with major/subphase identities, early phase-establishment bridge, explicit default phase posture when staged/governed work is already clearly implied, provisional task alignment to clearly implied staged/phase context even before the exact next phase file exists, current-phase-first but phase-context-aware live task-list linkage, bounded use of already-authored next-phase context from /phase for continuity and draft next-work discovery, explicit phase-to-patch linkage when patch is in scope, same-objective task-list continuity across repeated phase slices, bounded next-work discovery from the active phase workspace, session-aligned wording for phase-linked task entries, and generic receiving-side phase remap guidance when accepted work needs local execution structure |
runtime-topology-control.md |
Runtime topology discipline | Bounded inspect-first, one-authority-at-a-time runtime mutation posture that prevents debug-by-expansion and requires explicit approval for additive or authority-changing topology moves |
technical-snapshot-communication.md |
Technical snapshot communication | First-class owner for bounded technical snapshot wording, exact/partial/inferred separation, scoped local-fact snapshot communication, and concise diagnostic snapshot state reporting |
response-closing-and-action-framing.md |
Response closing and action framing | First-class owner for concise end-of-response synthesis, clear action framing, recommendation-with-reason wording, alternative preservation, closed-topic summary handling, and advisory goal-qualified proposal framing |
recovery-contract.md |
Blocked-response contract | Every constrained/refused path has actionable next steps |
tactical-strategic-programming.md |
Tactical vs strategic doctrine | Tactical entry stays fast, but every tactical move must point toward a declared strategic target and convergence path |
natural-professional-communication.md |
Communication style doctrine | Default to calm, human-readable, non-robotic, non-character-driven professional communication, keep easy explanations in an everyday Thai register when the user asks for simpler wording, reject metaphor-heavy or management-style abstraction when direct wording would be clearer, and front-load the operational purpose when the answer would otherwise bury it behind warm-up framing |
refusal-classification.md |
Deterministic refusal taxonomy | Consistent block decisions and traceable output modes |
refusal-minimization.md |
False-refusal reduction | Prefer recoverable constrained/context paths when authorized |
strict-file-hygiene.md |
File hygiene | Prevent junk files while allowing required governed startup artifacts, and keep hygiene/cleanup wording from acting as deletion authority |
todo-standards.md |
Task management | Durable TODO tracking plus same-objective built-in task-list reuse, append-not-replace behavior, completed-task visibility, current-phase-first but phase-context-aware live execution visibility, required inspection of relevant governed /phase context before shaping task entries when that context exists, task creation aligned to active phase or clearly implied staged context, bounded use of already-authored /phase planning data for continuity and draft next-work discovery, task wording that follows the actual active session language pattern with Thai-led default wording for Thai-led sessions, preserved natural Thai+English mix when that is the real session pattern, and technical labels left in technical form when forced translation would reduce clarity, task-list-first next-work discovery with bounded fallback, explicit required TODO sync as companion work when TODO.md is needed, and deferral of broader shared-board coordination semantics to the external coordination owner when applicable |
project-documentation-standards.md |
Project documentation standards | Standardized docs for all projects plus startup artifact gate, reasserted governed companion status for required design/changelog/TODO/phase/patch surfaces alongside live execution surfaces, phase-shaped task creation alignment when staged repository context is already visible, explicit use of /phase as both current execution structure and bounded already-authored next planned structure, master-surface consultation before junk/disposal classification, explicit live-task-list-vs-durable-TODO distinction, same-objective live task-list continuity, explicit execution-discovery surfaces during active execution, non-default startup patch posture for greenfield baseline formation, portable public onboarding/install guidance, portable-by-default package-local support assets when they are reusable source content, and the boundary that shared-board-specific coordination semantics stay outside Main RULES scope |
portable-implementation-and-hardcoding-control.md |
Portable implementation control | Keep shared artifacts, reusable support/package source artifacts, and public onboarding/install guidance portable by default, bind environment-specific values late, and prevent machine-local hardcoding drift |
execution-continuity-and-mode-selection.md |
Execution continuity and mode selection | Separates discussion mode from execution mode, keeps startup artifact governance as an explicit precondition before execution continuity takes over, keeps work moving when execution mode is active, discovers the next unfinished slice from execution surfaces when that path is already visible, and stops to capture implementation-critical external knowledge into governed artifacts before later multi-step work relies on it |
unified-version-control-system.md |
Unified version governance | Single deterministic UDVC-1 controller |
Improve answer structure, clarity, and visual scanability
| Rule | Purpose | Key Benefit |
|---|---|---|
answer-presentation.md |
Answer presentation standards | Readable and orderly responses with purpose-first framing near the start of diagnosis/test/recommendation/proposal/update answers, more proactive support for light readable tables when side-by-side structure materially improves comprehension without reviving a custom table-format rule, compact titled snapshots, small fact tables, stronger grouped scope-boundary sections, full-set-first / next-stage presentation, natural-flow formatting, compact governing-basis clarification blocks, compact post-compact re-anchor blocks for compacted-session continuation, compact memory-status blocks for remembered path-scoped context, compact variable-role structures for identifier-heavy explanations, compact near-term gloss support for abstract internal phrasing, and compact proposal layouts that distinguish advisory future-work ideas from queued execution |
explanation-quality.md |
Explanation structure quality | Plain-language-first, step-by-step reasoning with a purpose-first explanation step for diagnosis/test/recommendation/proposal/update answers, more proactive support for light tables in diagnostic and multi-field clarification when side-by-side scanability materially improves understanding, stronger what-it-is/what-it-is-not, now-versus-later, user-visible-outcome, short-recap, whole-set-first, stage-progression, good-operator explanation flow, stop-before-overexplaining boundaries, direct translation of architecture-first or metaphor-heavy wording into human-readable action/result language, a governing-basis clarification boundary before deep multi-branch explanation, a compact post-compact re-anchor boundary before explanation resumes after compaction, explicit support for unpacking variables/fields/config keys/internal labels before deeper reasoning, explicit deferral of continuation-vs-option policy to accurate-communication, and goal-qualified proposal framing when future ideas are offered after bounded completion |
flow-diagram-no-frame.md |
Clean ASCII diagrams | Better readability |
high-signal-communication.md |
High-signal response tightening | Removes low-value extra content and repeated wording without replacing the main communication-owner chains |
goal-set-review-and-priority-balance.md |
Goal review and priority balance | Keeps the full active goal set visible so work on A does not crowd out B and C |
Optimize your daily workflow efficiency
| Rule | Purpose | Key Benefit |
|---|---|---|
no-variable-guessing.md |
Read before reference | No wrong assumptions, including keeping git-state file signals as weak local evidence only |
safe-file-reading.md |
Plan-before-read | Efficient file handling |
safe-terminal-output.md |
Output management | No terminal flooding |
📊 Active Runtime Rules: 41
Latest refinement: repo-governed semantic surfaces now outrank git-state cleanup heuristics, and cleanup/isolation rationale no longer reads like deletion authorization for newly encountered files.
The Quick Start block above is still the canonical runtime-only install block. The methods below use the same active 41-rule set and describe when to use each path without repeating the long file list.
Use this when: you want the full active runtime set installed globally.
Fastest path:
- Clone the repository.
- Run the Quick Start block exactly as shown above.
- Run the verification commands below.
If you already cloned the repo earlier, you do not need to repeat the clone step. Just return to the repo root, keep the same Quick Start file list, and rerun only the install portion against ~/.claude/rules/.
Use this when: you only want a small subset of the runtime rules.
# Example: Install just the anti-sycophancy rule
curl -o ~/.claude/rules/anti-sycophancy.md \
https://raw.githubusercontent.com/DarKWinGTM/claude-code-rules/master/anti-sycophancy.mdUse this when: you want the same active runtime set, but only inside the current project.
- Create
./.claude/rules/in the project root. - Reuse the same Quick Start command pattern.
- Change only the destination path from
~/.claude/rules/to./.claude/rules/.
This keeps the install set identical while scoping the rules to one repository.
Source-side note: public commands in this README are expressed from the repo root. Destination/runtime note: installation targets are shown separately as
~/.claude/rules/or./.claude/rules/.
| Location | Scope | Path | Use Case |
|---|---|---|---|
| Global | All projects | ~/.claude/rules/*.md |
Default recommendation |
| Project | Current project only | ./.claude/rules/*.md |
Project-specific needs |
Global install: verify under
~/.claude/rules/. Project-specific install: verify under./.claude/rules/instead.
# Global install check
claude --version
head -20 ~/.claude/rules/anti-sycophancy.md
ls ~/.claude/rules/answer-presentation.md
ls ~/.claude/rules/phase-implementation.md
ls ~/.claude/rules/artifact-initiation-control.md
# Project-specific install check (run from project root)
head -20 ./.claude/rules/anti-sycophancy.md
ls ./.claude/rules/answer-presentation.md
ls ./.claude/rules/phase-implementation.md
ls ./.claude/rules/artifact-initiation-control.md| Location | Purpose | File Type |
|---|---|---|
./design/*.design.md |
Design specifications | Design docs |
*.md (root) |
Active runtime rules | Rules files |
./changelog/changelog.md |
Master repository-wide history | Master changelog |
./changelog/*.changelog.md |
Per-chain authoritative history | Changelogs |
./phase/SUMMARY.md |
Governed summary/index for live phase planning, one-way source-input rollup, and review rollup | Phase summary doc |
./phase/phase-NNN-<phase-name>.md |
Governed major-phase execution detail when a top-level phase needs its own live file | Major phase docs |
./phase/phase-NNN-NN-<subphase-name>.md |
Governed subphase execution detail with design extraction, optional patch extraction, and review state | Subphase docs |
./patch/<context>.patch.md or ./<context>.patch.md |
Governed patch/review artifacts outside live phase planning that may feed phase one-way when relevant | Patch docs |
./phase-implementation-template.md |
Root helper for phased planning | Helper artifact that also exposes active phase family, planned next phase(s), activation boundary, and next checkpoint guidance for future /phase authoring |
💡 Single Source of Truth Principle:
- Design files (
.design.md) define active target state- Per-chain changelogs (
*.changelog.md) are the authority for governed chain historychangelog/changelog.mdrecords repository-level synchronization historyREADME.mdremains overview-only, not chain authority- Older coordination-flavored rollout records in
TODO.md,phase/SUMMARY.md, andchangelog/changelog.mdremain historical context only; current active authority stays in the active runtime rules and design docs
This section defines how design, changelog, runtime rules, TODO, and governed phase-planning artifacts should be updated together.
| Document | Role | Update Trigger |
|---|---|---|
design/*.design.md |
Target behavior/specification | Requirement or policy change |
*.md (root runtime rules) |
Active runtime behavior | Approved design change requires runtime sync |
changelog/changelog.md |
Master repository-wide synchronization history | Repository-level governed sync events |
changelog/*.changelog.md |
Authoritative per-chain version history | Any rule/design update with version impact |
phase/SUMMARY.md |
Governed summary/index for live phased execution | Phased implementation work needs one summary file with a phase map, source-input extraction rollup, review rollup, and global coordination |
phase/phase-NNN-<phase-name>.md and phase/phase-NNN-NN-<subphase-name>.md |
Governed phase-detail layer | Multi-stage execution detail under /phase, including design references, optional patch references, design extraction, optional patch extraction, review flow, reviewer checklist, review outcome, and execution detail |
patch/<context>.patch.md or root <context>.patch.md |
Governed patch/review artifact layer | Patch or review work that is separate from live phase planning but may feed the phase layer one-way when relevant |
phase-implementation-template.md |
Root helper for phased planning readability | Reusable authoring support when staged execution matters, including active phase family, planned next phase(s), activation boundary, and next checkpoint guidance |
TODO.md |
Execution and progress tracking | Work starts/completes or task state changes |
Before meaningful governed work drifts, the repository now expects startup artifact posture to be resolved through artifact-initiation-control.md.
That means design / changelog / TODO / phase / patch should be explicitly resolved as:
- use existing
- create now
- ask now
- not required
Required governed companions should stay visible when the checked work shape still requires them; the live task list helps run the work, but it does not replace required design/changelog/TODO/phase/patch surfaces.
For greenfield startup / baseline formation, patch should normally resolve to not required unless a real existing before/after review surface or explicit user request justifies patch packaging.
Once startup posture is settled and the active path is clear, execution should keep moving without re-pausing over the same gate.
When phased work also uses governed patch artifacts, the live phase workspace should now declare that linkage explicitly in phase/SUMMARY.md and the relevant child phase files.
Change request received
→ resolve startup artifact posture first when the work is meaningfully governed
→ Update design target state
→ Synchronize runtime rule wording
→ Record per-chain changelog version + summary
→ Record repository-level sync in changelog/changelog.md when applicable
→ Update TODO pending/completed/history
→ Verify links, versions, and consistency
- Design file links to the correct changelog file
- Changelog unified row maps to an existing detailed section
- Runtime rule version/header aligns with changelog current version
phase/SUMMARY.mdexists when phased execution is usedphase/SUMMARY.mdincludes:- source-input extraction summary table
- overview flow diagram
- review summary table
- phase map
- child phase files include:
- design references
- patch references when patch-derived work exists
- design extraction
- patch-to-phase extraction when patch-derived work exists
- review flow diagram
- reviewer checklist
- standardized review outcome fields
- TODO pending section contains pending-only items (
- [ ]) - TODO history has a dated entry for completed milestone work
design/recovery-contract.design.md
→ recovery-contract.md
→ changelog/recovery-contract.changelog.md
→ TODO.md (history/progress)
What was synchronized:
- Deterministic response keys were aligned across design and runtime (
decision_output,refusal_class,reason,what_can_be_done_now,how_to_proceed) - Changelog recorded the runtime/design version sync event
- TODO recorded completion in the hardening program history
design/safe-file-reading.design.md + design/safe-terminal-output.design.md
→ safe-file-reading.md + safe-terminal-output.md
→ changelog/safe-file-reading.changelog.md + changelog/safe-terminal-output.changelog.md
→ TODO.md (WS-5 completion)
What was synchronized:
- Shared verification-trigger model applied across related rules
- Deterministic output-cap wording standardized (
head -100 | head -c 5000, risky-file variant) - Changelog and TODO were updated to preserve traceability
TODO.md pending section audit
→ remove completed items from pending block
→ remove duplicate pending headings
→ add closure row in TODO history
What was synchronized:
- Pending section kept pending-only (
- [ ]) - Duplicate heading drift removed
- Program closure logged in dated history row
phase/SUMMARY.md
→ source-input extraction summary table
→ overview flow diagram
→ review summary table
→ phase/phase-NNN-*.md / phase/phase-NNN-NN-*.md
→ TODO.md history
What was synchronized:
/phasebecame the live phase-planning namespaceSUMMARY.mdbecame the required summary/index for live phased execution- child phase files were required to carry design extraction, review flow, reviewer checklist, and standardized review outcomes
SUMMARY.mdwas extended to carry source-input rollup and review rollup views for faster approval- the model gained an explicit Definition of Done and stop rule so governance expansion does not continue by default after completion
- communication rules were narrowed so next-step options are suggested only when genuinely useful rather than treated as a mandatory ending pattern
design/*.design.md + patch/<context>.patch.md or root <context>.patch.md
→ phase/SUMMARY.md
→ phase/phase-NNN-*.md / phase/phase-NNN-NN-*.md
→ TODO.md history
What was synchronized:
phase-implementationwas extended from design-only extraction into one-way source synthesisphase/SUMMARY.mdcan now show both design inputs and patch inputs when patch-derived work matters- child phase files can now carry optional patch references and patch-to-phase extraction alongside design traceability
- patch artifacts remained outside the live phase workspace
- design and patch documents did not gain a reverse-link requirement back to phase
artifact-initiation-control.design.md
→ artifact-initiation-control.md
→ changelog/artifact-initiation-control.changelog.md
→ phase/SUMMARY.md + phase/phase-004-*.md
→ TODO.md history
What was synchronized:
- a new first-class startup-governance owner was created
- startup artifact posture now resolves before meaningful governed work drifts
project-documentation-standards,phase-implementation,todo-standards, andstrict-file-hygienewere aligned to the new startup contract- the rollout itself opened
phase-004from the start instead of being backfilled later
The current phased execution model is now explicitly finalized, bounded, and able to synthesize design plus relevant patch inputs one-way.
phase/
SUMMARY.md
→ source-input extraction summary table
→ overview flow diagram
→ review summary table
→ phase map
phase-001-<phase-name>.md
→ design references
→ optional patch references
→ design extraction
→ optional patch-to-phase extraction
→ review flow diagram
→ reviewer checklist
→ review outcome
What this gives you:
- reviewers can inspect the whole rollout from
SUMMARY.md - reviewers can inspect one phase deeply from the child phase file
- approvers can see sign-off status, severity, disposition, and blocker/follow-up state in one place
- the model can now synthesize target-state design inputs and relevant governed patch inputs without collapsing role boundaries
- the model now has an explicit completion boundary and stop rule, so governance expansion does not continue by default after it is operationally complete
- startup artifact posture can now be resolved before meaningful governed work drifts instead of being backfilled later
- communication rules now treat next-step options as usefulness-based guidance, not as a mandatory ending pattern after already-complete work
Dynamic complexity adjustment based on task requirements
Simple Tasks (Level 0-2) → Minimal Processing
↓
Standard Tasks (Level 3-5) → Balanced Approach
↓
Complex Tasks (Level 6-7) → Deep Analysis
| Metric | Improvement | Impact |
|---|---|---|
| Response Speed | +30-50% | Faster answers |
| Token Efficiency | +40-82% | Lower costs |
| Cost Reduction | -25-35% | Budget-friendly |
Three expert perspectives analyzing every complex problem
Developer ──┐
Security ──┼──→ Unified Recommendation
Architect ──┘
How It Works:
- Developer Agent → Technical feasibility analysis
- Security Agent → Security & privacy evaluation
- Architect Agent → System design considerations
- Synthesis → All perspectives merge into unified recommendation
Result: Comprehensive analysis from multiple angles
Cache and reuse verified reasoning patterns
| Action | Benefit |
|---|---|
| Cache verified patterns | Store successful approaches |
| Reuse for similar tasks | 40% speed improvement |
| Validate before use | Ensure accuracy maintained |
Performance: 82% cache hit rate for recurring patterns
 Anti-Sycophancy Truth over pleasing |
 Anti-Mockup Real systems only |
 Zero Hallucination Verified info only |
 Authority & Scope User authority supreme |
 Emergency Protocol Rapid response |
 Document Consistency Cross-reference check |
 Functional Intent Intent validation |
 Document Changelog Control Version tracking system |
 Document Design Control Design standards |
 Strict File Hygiene Prevent junk files while allowing required governed startup artifacts |
 Project Documentation Standards Standardized docs and startup artifact gate |
|
Artifact Initiation Control Resolve startup artifact posture before meaningful governed work drifts |
Document Patch Control Before/after patch artifacts with explicit change surfaces |
Evidence-Grounded Burden of Proof Fact, inference, and contradiction thresholds stay explicit |
Operational Failure Handling Bounded retries, honest cooldowns, and stop/escalation behavior |
|
Phase Implementation Major/subphase execution model with early `/phase` establishment bridge |
Recovery Contract No dead-end blocked paths; always provide a usable next step |
Refusal Classification Deterministic refusal classes and output modes |
Refusal Minimization Prefer recoverable constrained/context paths over premature refusal |
|
Runtime Topology Control Inspect-first, one-authority-at-a-time runtime mutation discipline |
TODO Standards Simple execution tracking with early TODO establishment when needed |
Dan-Safe Normalization Normalize jailbreak-style wrappers into bounded intent evaluation |
Unified Version-Control System Single deterministic UDVC-1 controller for governance alignment |
 Flow Diagram No frames, clean arrows |
Answer Presentation Active presentation-layer rule for compact snapshots, grouped scope boundaries, and full-set-first / next-stage layouts |
Explanation Quality Active explanation-layer rule for what-it-is/what-it-is-not, now-vs-later, user-visible outcomes, and next-stage progression |
|
Accurate Communication Evidence-honest wording, bounded technical snapshots, and claim-strength discipline |
Natural Professional Communication Calm, human-readable, non-robotic, non-character-driven default communication |
Reserved Placeholder slot for future visual asset parity |
 No Guessing Read before reference |
 Safe File Reading Plan before read |
 Safe Terminal Output management |
|
Tactical Strategic Programming Tactical speed with mandatory strategic target and convergence path |
Reserved Placeholder slot for future visual asset parity |
Reserved Placeholder slot for future visual asset parity |
User: "Set up database connection"
↓
AI: "Here's the connection string:
DATABASE_URL=postgres://localhost:5432/mydb"
Result: ❌ Guessed values
❌ No verification
❌ Potentially wrong
❌ User frustrated
User: "Set up database connection"
↓
AI: "Let me check your .env file first..."
[Reading configuration...]
"Found your existing config:
DATABASE_URL=postgres://prod-server:5432/app_db
Should I use this, or do you want to change it?"
Result: ✅ Verified from actual files
✅ No guessing
✅ User confirmation
✅ Professional interaction
The difference? Professional AI behavior that respects your existing configuration.
| Metric | Target | Status | Impact |
|---|---|---|---|
| Factual Accuracy | 100% | ✅ | Zero hallucinations |
| Constitutional Compliance | 100% | ✅ | User sovereignty maintained |
| Token Efficiency | +40-82% | ✅ | Cost reduction |
| Response Speed | +30-50% | ✅ | Faster delivery |
| User Sovereignty | Absolute | ✅ | User always in control |
| Guarantee | Description |
|---|---|
| No Mock/Stub | Real implementations unless explicitly requested |
| No Guessing | Always verify from actual sources |
| No Hallucinations | 100% fact-based responses |
| No Sycophancy | Truth over agreement, always |
| Constitutional | Principles override everything |
Your safety and accuracy are non-negotiable.
These rules evolve based on real-world usage:
- 🔄 Real-world usage patterns → What actually works
- 💬 User feedback → Your experience matters
- 🔐 Safety considerations → Always improving
- ⚡ Performance optimization → Getting faster
Pull requests welcome! Please ensure:
- New rules follow existing format
- Include clear documentation
- Add visual assets if applicable
- Update changelog
- Respect completion boundaries — do not add new mandatory capability blocks to a completed governance model unless the change is explicitly justified and intentionally approved
We value: Quality over quantity, clarity over complexity, and bounded governance over endless expansion
MIT License - Feel free to adapt for your own use case.
Attribution appreciated but not required.
Personal rule set and configuration framework for Claude Code CLI.
Inspired by:
- Constitutional AI principles (Anthropic)
- Best practices for AI assistant development
- Real-world production experience
- Community feedback and contributions
Built with ❤️ for the Claude Code community
Version: 9.56 | Last Updated: 2026-04-22 | Framework: Sophisticated AI Framework with Constitutional Governance
Made with 💙 by developers who care about AI quality