development-brain

Unity of knowledge and action (development brain)

First automatic update of the day (mandatory, before other actions)

When this Skill is first triggered on each local natural day, first execute:

node <本 Skill 目录>/scripts/ensure-daily-skill-update.mjs --current-skill development-brain

updated: the five Yunxiao lifecycle Skills have been uniformly updated; this must be fully re-read again SKILL.md and the references required for this session before continuing.
skipped-today: the update has already succeeded today, continue directly.
in-progress: another related Skill is executing the same update, continue directly and do not concurrently repeat the update.
failed / unavailable / cooldown: give only one brief prompt and continue the current development pre-check; an update failure must not block development work.
The shared update scope is fixed as YunxiaoPM、yunxiao-development-delivery、development-brain、YunxiaoQA、yunxiao-release-operations user-level global installation; this must not be used to modify project-level Skills, business repositories, Yunxiao data, pipelines, or production environments. The daily success status must not be manually forged or written in advance.

Current version read-back constraint

Whenever reading, judging, referencing, or executing the above five Yunxiao lifecycle Skills, the daily updater must first be run, and then the current SKILL.mdmust be re-located and read from the user-level installation directory; session caches, source worktrees, release notes, or pre-update read results must not be used to impersonate the current version on this machine.
updated Afterward, the current Skill and the references required for this session must be reloaded.skipped-today only proves that the updater ran successfully today; it does not prove that a subsequently released new version has been installed. When fresh evidence exists in this round such as new remote commits, a new release version, inconsistency between source code and the installation directory, or a user report that the version is outdated, immediately run node <本 Skill 目录>/scripts/ensure-daily-skill-update.mjs --current-skill development-brain --force, and do not wait until the next day.
in-progress , the current version must not be reported and Yunxiao lifecycle writes must not begin; wait for the existing update to finish and then read back the installation directory.failed、unavailable or cooldown does not block ordinary local development, but when the installation read-back cannot be completed, it must not be claimed that it is "already the latest version," and new-format lifecycle writes must not be executed with an unverified suite version.
Before externally reporting the current version, read back the Skill installation path actually used in this session, the explicit version number, and the file modification time; only inventory the five Skills when the user requests checking the complete suite installation. The development ledger and completion of development are no longer blocked by missing or version-inconsistent Skills from other roles, and the five-Skill same-version gate is not run; the actual input protocol, handoff, and business evidence must still be verified, and update success must not be claimed solely based on the update command exit code.

"Unity of knowledge and action" requires applying verified knowledge to every development action and feeding execution results back into reusable experience. It independently maintains development constraints and proven pitfalls for reuse during development based on evidence. It does not define business requirements, does not replace repository rules, and does not execute business repository Git, Yunxiao, or production writes; only when knowledge admission passes does it write authoritative knowledge repositories according to release gates. It also does not upgrade one-time observations into long-term rules.

Version:10.2.15. When natural language and the current workspace indicate that development has started, is continuing, or has just completed, first fully read Proactive identification and automatic evolution, without requiring the user to additionally input the Skill name or a fixed passphrase.

Lightweight knowledge index

For ordinary development pre-checks, first run node <本 Skill 目录>/scripts/select-knowledge.mjs --check, then read knowledge index, and filter record IDs by repository, tech stack, action, and risk keywords. Only for matched records run node <本 Skill 目录>/scripts/select-knowledge.mjs --ids <ID[,ID...]> to read the full original text; when there are zero matches, do not load the full knowledge file. The index summary is only for routing and cannot be used directly as a mandatory rule.

When index validation fails, the script is unavailable, or the summary cannot determine the scope, you must fall back to fully reading confirmed constraints and candidate retrospectives, and must not skip knowledge checks to save tokens. If the knowledge source itself is corrupted or rules within the same scope conflict, it is still handled as a safety block. When adding, modifying, confirming, or resolving knowledge conflicts, you must fully read knowledge governance、knowledge admission score and the relevant knowledge source text, and update the index and source file hashes in the same change.

Three-part mandatory contract

The caller must provide the current action, work item, or Bug identifier (if none, write 无), known repository/tech stack, modification scope, and available evidence pointers. It is forbidden to pass or read credentials.

Pre-read: first validate and read knowledge index, then based on the current repository and tech stack load only the matched confirmed full records, and generate the "development brain pre-check receipt". Index summaries must not replace full rules; when the index is abnormal, handle it according to the fallback contract of "Lightweight knowledge index". If the matched original text has not been read, the knowledge source is corrupted, or confirmed rules within the same scope conflict, you must not continue writing to code or external systems.
In-execution constraints: only execute rules whose status is confirmed, whose scope matches, and which are not expired/conflicting; record item by item the rule IDs used or "not applicable and the basis".candidate、pending、superseded and unsourced experience never constitute mandatory rules. When repository AGENTS.md, current task materials, or explicit user requirements conflict with safety rules, stop the affected scope and handle it according to governance rules.
End-of-task retrospective: only when the final Git/verification/MR evidence for this task has been formed and the real development node has been completed, first use the knowledge index to exclude identical/similar confirmed and candidate; when matched, load only the corresponding full records. When preparing to add, modify, or confirm knowledge, then fully read candidate retrospectives and governance references. Only when "phenomenon/root cause/fix or workaround/verification/applicable scope" all have traceable evidence, and after passing identical/similar pattern exclusion and GitHub release pre-check, may you add candidate or verify an existing candidate; otherwise output "no candidate worth preserving". You must not evolve just because one reply has ended, work was interrupted, or something is not yet complete, and you must not modify business code, task status, MR, pipeline, or production environment again because of the retrospective.

When defects or external issues are involved, the caller uses the current work item, defect platform, code, and tests as evidence sources; platform lists, status snapshots, or a single issue description are not saved in advance as brain knowledge. Only conclusions that have been abstracted into stable, reusable patterns with complete evidence may enter candidates or confirmed constraints according to governance rules.

Knowledge admission determination

Each call first makes a preliminary determination of the content available in this round, and at the end-of-task retrospective rechecks it against the final evidence. For scoring and hard thresholds, see knowledge admission score. The initial assessment is only used to arrange evidence collection and must not be written in advance; the actual write only occurs in the final retrospective phase.

First, retrieve all confirmed and candidate summaries through the validated index; when a hit or suspected approximation occurs, load the corresponding full records for review. On a hit for confirmed , do not add a new one; on a hit for candidate , do not create a duplicate record, and only judge according to Proactive Identification and Automatic Evolution whether this round constitutes a second independent closed-loop piece of evidence.
Final score 90–100 and all hard gates passed: automatically form a new candidate, then publish according to GitHub Instant Sync ; only output "candidate recorded" if the remote read-back succeeds.
A hit on an existing candidate, final score 95–100, and the same pattern independently reproduced by a second different task/defect and a different set of commits and verifications: only then may it be automatically converted to confirmedwhile retaining the original ID and both sets of evidence. Retries, supplements, continuations, or repeated tests of the same task do not count as a second verification.
Final score 70–89 and no hard exclusion: do not write, explicitly ask He Fei whether to add it as candidate , and display the summary, score, gaps, and scope of applicability. Even after He Fei confirms, it must still pass the same/approximate exclusion and GitHub Instant Sync before it counts as added.
Final score <70 or failure to pass any hard gate: ignore, do not write; the receipt only states a brief reason.
Rules involving destructive operations, privilege expansion, security bypass, production changes/releases, force pushes, handling of sensitive credentials, or lowering approval thresholds must never be automatically promoted and must be explicitly confirmed by He Fei.

Precheck and Degradation

The precheck receipt contains at least:调用关联、已读取知识版本、匹配 confirmed 规则 ID、不适用理由、冲突/过期项、待确认项、写入许可、知识准入初判。

Zero matching rules is not a failure: the receipt states "no matching confirmed rules", and execution still follows the caller's own gates.
When knowledge is unreadable, integrity is abnormal, or confirmed rules conflict with each other within the same scope, this is a safety block: read-only diagnostics may continue, but no code, Git, Yunxiao, pipeline, or production writes may be made; rerun the precheck after fixing the knowledge or obtaining an explicit ruling.
When same/approximate exclusion, GitHub release precheck, or push/read-back fails, do not create or modify brain knowledge; uniformly mark "evolution not persisted", retain the pending content and failure reason, and do not claim it has been accumulated.

Knowledge Boundaries

The current product contract, understanding receipt, engineering decisions, and acceptance evidence of formal Yunxiao development belong to the current task and are verified by the versioned handoff gate of yunxiao-development-delivery ; precheck passing, historical experience, or local clone capabilities cannot replace them, and engineering unknowns must not be filled in as product-confirmed. Only pass formal numbers and evidence links; do not require colleagues to copy the product manager's personal memory/clone. This clause does not change knowledge admission, automatic evolution, or production authorization rules.
Project/tech-stack-specific knowledge must have a precise scope of applicability; when the scope cannot be confirmed, treat it only as a candidate.
The brain stores only cross-task reusable "behavior constraints" or "retrospective patterns" that will not become invalid due to dates, workspaces, or a single operation. Branches/commits, uncommitted counts, current dependency versions, scripts, file lists, platform states, and single-issue snapshots all remain in the target repository, external platform, or the receipt for that occasion.
Modifying a Skill's behavior rules, scripts, validators, or release package is real development, but the target Skill's prompts, versions, paths, script details, and individual failures by default do not generate brain knowledge candidates and remain in the target Skill's repository materials.
Skill development experience may enter only when it independently holds across at least two different Skills, different tasks, different commit or MR evidence sets, and different verification executions, and can be abstracted into a stable cross-Skill development constraint candidate; the scope of applicability must be marked as skill-development or a narrower scope.
development-brain Changes to its own triggering, scoring, admission, evolution, or safety rules must not be written or automatically confirmed through automated evolution; they must be explicitly confirmed by He Fei and implemented and verified as an independent Skill development task; the evidence from this self-modification must not be used to self-prove that the rules are correct.
Repository AGENTS.md, design specifications, POM, package configuration, and CI are the real-time sources of project rules; the brain does not copy the project details within them, and only requires reading and complying with them during pre-checks.
Confirmed rules must provide sources and reviewable evidence, and must not record passwords, tokens, cookies, personal information, or production data.
When rules conflict, evidence becomes invalid, or there is a major upgrade of a repository or dependency, keep the original record traceable and mark it as conflicted or superseded, without silently overwriting.
A candidate may be promoted to confirmed。

Problem retrospective storage

A defect's "fixed" or "closed" status is not evidence of root cause, code changes, or regression verification; without complete evidence, it is not沉淀为大脑知识。
Do not merge issues from different platforms based on titles, module names, or similar wording; when traceability is needed, retain the external ID and minimal evidence location, and do not copy platform snapshots.
Only write into candidates or confirmed constraints the patterns for which "phenomenon—root cause—mitigation/fix—verification—applicable conditions" have been fully closed-loop and can be reused in subsequent similar tasks.
Identical or similar confirmed already exists, do not enter it into the brain again; when it hits candidate , only verify or promote the original record, and never duplicate a second one.

Output

开发大脑：主动识别|预检通过|无匹配规则|安全阻塞|候选已记录|自动确认已完成|进化未落盘
调用关联：
适用 confirmed 规则：
不适用/过期/冲突：
执行中引用：
复盘候选：
知识准入：初判/最终得分、档位、硬门槛、处理结果
GitHub 同步：未触发|已推送 <commit>|未落盘（原因）
待何斐确认：
证据：