cc-switch-web: Skill for Claude Code

Reconcile Xirang artifacts from already-written code (code-first artifact reconciliation, reverse of propose/apply).

Xirang Philosophy

1. Xirang is a structured representation of human intent that an Agent can compile.
2. One Xirang Semantic Model is persisted as a single whole in the four partitions metamodel/, elements/, relationships/, and views/; a Semantic Delta uses the same four partitions and adds operation.
3. A change reconciles a Semantic Delta toward the target steady state. proposal.md, design.md, and tasks.md are compilation scaffolding, not competing sources of truth.
4. The Xirang Semantic Model is complete only when an Agent need not guess decisions that affect element hierarchy, contracts, or relationships.
5. The Agent acts like a compiler and faithfully translates authorized human intent. Existing code is current implementation evidence and MUST NOT silently override the Xirang Semantic Model.

Element Contract Semantics

• Element Contract SHALL 完整表达宿主 Element 在自身抽象层级承担的职责、保证、约束与行为；children 可以进一步精化或共同实现这些承诺，父子 Elements 可以在各自层级表达相互覆盖的完整语义。
• Requirement SHALL 以稳定 identity 表达一项可独立演进的规范承诺。以该承诺能否独立新增、修改或移除判断边界，不得按句子、分句、SHALL 数量或目标条数机械拆分。只复述 Declaration summary 或 sibling Requirements 语义并集且不增加规范承诺的内容不形成 Requirement；独立的不变量、顺序、原子性、一致性或完成条件应保留。
• Scenario SHALL 是具有规范约束力的 Requirement 组成，只具体化宿主 Requirement 在特定条件下的行为，不得引入可独立演进的承诺。Scenarios 不默认穷尽 Requirement 的全部适用情况，Scenario 不作为独立 Semantic Delta Entry，其变化由宿主 Requirement 的完整目标内容表达。

Treat proposal.md, design.md, and the Delta units under {metamodel,elements,relationships,views}/ as conditional artifacts: create them when missing, update them when stale or inconsistent, and leave them unchanged when current.

Input

• Optional <change-name> (kebab-case).
• If omitted, run xirang list --json and reuse the single active change; if multiple or none, ask which change name to target.

Flow

1. Resolve change name and reconcile mode.
   • If .xirang/changes/<name>/ does not exist, run xirang new change "<name>" and create only artifacts required by evidence.
   • Otherwise read the current proposal, design, and Delta units; classify each as missing, stale, inconsistent, or current and preserve unrelated human-authored content.
2. Load the shared Xirang Semantic Model context. Xirang Semantic Model Context

• Resolve the absolute Project Root, then load the Semantic Model from .xirang/model/{metamodel,elements,relationships,views}/ and locate the unique Project Root Element, whose parent is null.
• Use identity as the only way to reference a semantic object. FQN, syntax position, and derived local names are generation artifacts and never appear in a persistent source.
• Read relevant parent and children as abstraction/refinement context. Do not assume a fixed element-kind hierarchy or treat nesting as ownership.
• An Element Contract is the body of its Element unit: one Element has at most one Contract, expressed as ## Requirements, and whether a Contract is required comes from the contract field of its Element Kind.
• Use xirang arch query <identity> --relations --depth <n> --json for parent, children, and incoming/outgoing semantic relationships; add --contract to inline the complete Element Contract.
• Default unit naming is elements/<identity>.md, metamodel/<kind identity>.md, views/<view identity>.md, and relationships/<relationship kind identity>.yaml grouped by Relationship Kind; a change reuses these names under .xirang/changes/<name>/. Directory and file names carry no model semantics: every entry declares its own entity and identity, and loading locates entries by those, never by path.
• Treat code paths, symbols, imports, and calls from CodeGraph or ACE/rg/read as current implementation evidence only; do not promote them to elements or relationships without declared model intent.
• If the model is missing, report Semantic Model unavailable. If it is incomplete or unsupported, identify the root, identity, contract, or relationship gap.
• A read-only exploration MAY degrade to available model and code evidence with the limitation disclosed. Workflows that compile or write semantics MUST stop when required model context is missing or incomplete; never treat a missing collection as complete and empty.

1. Collect code-change evidence from conversation context plus git diff --cached, git diff HEAD, other available working-tree/staged diffs, and user-selected commit/range diffs. git diff is one evidence source among several and MUST NOT be treated as the only valid source. Treat natural-language commit/range selectors as agent-parsed evidence selectors, not Xirang CLI flags. Mark conflicts or uncertainty [REVIEW NEEDED].
2. Map changed symbols/files to current Semantic Model context.
   • Use Element identity values, refinement, Element Contracts, and relationships.
   • CodeGraph MAY accelerate symbol/call/import discovery; otherwise use ACE, rg, and read. Never read .codegraph/codegraph.db.
   • Treat code locations and call/import edges as implementation evidence, not as proof that the Xirang Semantic Model must change. Do not create elements from uncertain file-name inference.
3. Determine Element Contract impact.
   • Run xirang arch query <identity> --contract --json for each candidate Element and keep its current Requirements.
   • Add an identity to Modified Specs only when the observable requirements of its Element Contract change. Add it to New Specs only for genuinely new observable behavior not governed by an existing Element Contract.
   • An optional-contract Element without a Contract does not by itself require a new one; mark missing coverage [REVIEW NEEDED].
   • Behavior-preserving refactors create no Contract delta; later Checks use Preserves: against formal Element Contracts.
4. Determine structural impact.
   • Declare impact only when Element Declarations, refinement, Relationships, Kinds, or Views change.
   • Implementation-only movement, symbol renaming, helper extraction, and mechanical call/import changes do not by themselves change the structure.
   • If no structural fact changes, set the compatible Architecture Source scope to None. If impact remains unresolved, stop and ask one focused question; do not write structural Delta units or claim reconciliation complete.
5. Reconcile the Contract and structural scopes as one Semantic Delta; both address the same Element identity space.
6. Reconcile proposal.md.
   • Run xirang instructions proposal --change "<name>" --json. For each response, follow the authoring order in the returned instruction. Keep definition, dependencies, currentState, configProjection, and template as separate inputs; do not copy non-artifact inputs into the artifact.
   • Reconcile ## Source Impact from the Contract and structural scopes of one Semantic Delta. Keep the compatible Behavior Source and Architecture Source headings and reference Elements by identity.
   • Reuse the confirmed Contract scope as the Element Contract delta input; preserve ## Why, ## What Changes, ## Source Impact, and ## Impact.
   • If the proposal already matches evidence and source impact, leave it unchanged.
7. Reconcile Element Contract deltas in elements/<identity>.md.
   • Run xirang instructions specs --change "<name>" --json. For each response, follow the authoring order in the returned instruction. Keep definition, dependencies, currentState, configProjection, and template as separate inputs; do not copy non-artifact inputs into the artifact.
   • Create or update only the identities declared by the Contract scope. The default unit name is <identity>.md; a file name expresses nothing, so deviating from the default changes no model semantics.
   • Follow returned ## ADDED Requirements, ## MODIFIED Requirements, and ## REMOVED Requirements rules with exact title matching and canonical unlabeled Requirement/Scenario syntax. Express a rename as REMOVED old Requirement plus ADDED new complete Requirement. Preserve unrelated current delta content.
8. Reconcile simplified design.md.

• Run xirang instructions design --change "<name>" --json. For each response, follow the authoring order in the returned instruction. Keep definition, dependencies, currentState, configProjection, and template as separate inputs; do not copy non-artifact inputs into the artifact.
• Preserve Context, Goals / Non-Goals, Decisions, and Risks / Trade-offs. Mark inferred content [INFERRED FROM CODE] and unresolved decisions [REVIEW NEEDED].

1. Reconcile the structural Delta units only after structural impact is resolved. Leave those partitions empty when the structure is confirmed unchanged; author validated Entries otherwise. Write the Semantic Delta: