暂时没有ui skill trigger。
强调基于证据的建议和分析
Planning Discipline保证继续loop直至遇到blocker。
过三级后分享复杂的git rebase技能，git rebase -i HEAD~50 自动执行
# Rust Development
- Read files before editing
- Run `cargo check` after changes
- Run `cargo test` when modifying logic
- Use `tracing` for logging, not `println!`
- Only modify Cargo.toml when necessary.
- Use rust native async trait, never use async trait from crates.
# Daily Reminders
At local time 20:00 each day reminder use this exact format:
ImportantProjectsNeedFocus:
Time spent:
other project 1: <Nh>
other project 2: <Nh>
Important projects total time spent (Innovation): <Nh>
# Planning Discipline
- Use descriptive plan filenames (e.g., `plan_main_mobile.md`), never generic names like `implementation_plan.md`
- Root document for a major objective must start with `plan_main_`
- Treat plans as living documents: use `Edit` to update specific sections, never overwrite entire plan files with `Write`
- For complex sub-tasks, create linked child plans and reference them from the main plan
- Plan forward rule:
- One active approved plan remains the controlling objective.
- If user interrupt with a different task that does not replace that plan, treat it as a temporary diversion.
- After that diversion finishes or ends, You return to the active approved plan automatically and continue the plan.
- If user ask you to redo an item already in the active plan, you redo it, then resume the remaining plan.
- do not treat a diversion or subplan as a new main objective.
- do not stop at diversion completion.
- a progress report never is an allowed stopping point, only if user ask
you stop.
- You stop only when:
- the active approved plan is fully complete, or
- there is a real blocker with exact evidence, or
- user explicitly replace/cancel the active approved plan.
So the rule is: temporary interruption does not change the active plan unless user explicitly say it does.
# In-place Update Rule
- Never overwrite existing files with full-file rewrites when only a section changed — use targeted edits
- Before editing, always read the file first to get exact current content
# Evidence-Based Suggestions
- Before suggesting a feature/flag/option exists: verify with file search or file read, show evidence (file path, line number, snippet), then suggest
- Never assume a CLI flag, config option, or API exists without checking first
# General Logic Design
- Start with fundamental principles; logic should be general enough
- Only add conditions/limits if there's a specific reason (performance, correctness)
- Arbitrary thresholds are code smells — they need justification
# Skill Usage Rules
## Skill Learning Rule
When reading a skill file (SKILL.md):
- Capture ALL modes/sections in the learning summary, not just the current focus, to internal memory.
- Internal format: "Skill: [name]. Modes: [list]. Triggers: [keywords for each mode]."
- Do not print this full learning summary to the user unless explicitly requested.
## Task-Type Skill Trigger Rule
For any non-trivial task, identify the task type and load the appropriate skill before proceeding:
Non-trivial task classification: A task is non-trivial if any condition is true:
- touches logic/control flow (not pure wording/comments)
- touches more than 1 file
- requires debugging/root-cause analysis
- requires tests/build verification
- changes API/CLI/config behavior
- involves concurrency/performance/security tradeoffs
- requires a multi-step plan to complete safely
Otherwise, classify as trivial (single-step, no logic change, no verification needed).
| Keyword | Task Type | Skill |
|---------|-----------|-------|
| fix, debug, error | TROUBLESHOOTING | tla-brain |
| research, explore | RESEARCH | tla-brain |
| plan | PLAN | tla-brain |
| build, implement | DESIGN/CODING | tla-brain |
| refactor, extract | REFACTORING | refactoring |
## TLA+ Brain Rule
For troubleshooting/design/coding/research/plan tasks, ALWAYS load and follow the TLA+ Brain skill (`~/.codex/skills/tla-brain/SKILL.md`) before proceeding.
## Refactoring Rule
For refactoring/extracting/moving code tasks, ALWAYS load and follow the refactoring skill (`~/.codex/skills/refactoring/SKILL.md`).
## Task Type Transition Protocol
When user reports: error, bug, "doesn't work", "still X", "not working"
OR when recognizing the need to debug/troubleshoot:
1. STOP current approach
2. Re-read global and project AGENTS.md
3. Check: "Is there a skill I must load?" (see Task-Type mapping above)
4. THEN proceed
## Code Explanation Format
When asked to explain how something works in the code, always structure the response as follows:
1. **Relevant snippet** — paste only the lines needed to understand the concept, with file path and line numbers (e.g. `src/utils.py:42-58`)
2. **Summary** — one short paragraph explaining what it does and why it exists
3. **Step-by-step walkthrough** — go through the snippet block by block or line by line, referencing the actual code
4. **Concrete example** — show a real input → output or before → after to make the behavior tangible
5. **Gotchas** — call out any non-obvious behavior, edge cases, or design decisions worth knowing
Do not describe code in the abstract. Always anchor the explanation to the actual snippet so the reader never needs to open a file.
Never only show the code file:linnum, this is meaningless.
## Verified Fix Commit Rule (MUST)
When a bug fix is implemented and verification passes:
1. Create a commit immediately in current branch.
2. Use commit message style consistent with recent branch commits.
3. Stage only relevant files.
4. Include verification status in final report (cargo check/test scope and result).
5. Do not use \n in multiline message, use -m para.
## Execution Gate (MUST)
Before every response:
1. Classify task: trivial/non-trivial.
2. If non-trivial task, must load the required skills from file or memory first and print only the task-specific selection:
"Skill: <selected skills>. Modes: <selected mode for this task>. Triggers: <why this task triggered that skill/those skills>."
3. If user requested a strict format, use that format exactly.
4. No file edits without explicit user approval.
5. If code changed: run cargo check; if logic changed: run cargo test.
6. Run postflight check: verify steps 1-5; if any fail, correct before send.
## Violation Recovery (MUST)
If any required rule/format is missed:
1. Stop.
2. Re-answer in the required format in the same turn.
3. State exactly which rule was missed.
4. Continue only after compliance is restored.
2 个帖子 - 2 位参与者
来源: linux.do查看原文