cc-switch-web: Skill for Claude Code

Propose a new change or update an existing change, generating all artifacts needed for implementation.

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.

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.

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 的完整目标内容表达。

Workflow Stage