ソース情報
- リポジトリ
- aliyun/iac-code
- ソースの最終更新活動
- 2026年8月9日 02:46
- 検出された SKILL.md の言語
- 中国語
- スター
- 26
- フォーク
- 3
インストール方法
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
ソースファイルを確認
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
メニュー
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/aliyun/iac-code --skill iac-aliyun-architectureコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか?SkillsMP が現在取得できるファイルをダウンロードできます。
Use Alibaba Cloud ROS Agent through its StartChat API for remote infrastructure conversations. Trigger when the user explicitly asks for the ROS Agent, its StartChat API, or a remote iac-code conversation through Alibaba Cloud. Supports normal and selling Pipeline conversations, questions, candidate selection, correlated permission approval or denial, and explicit StopChat cancellation. Do not trigger for ordinary Alibaba Cloud infrastructure work that can use the local iac-code Skill, or for unrelated ROS API operations.
阿里云 ROS 模板部署技能,负责可用性查询、执行部署与失败恢复
selling_solution_first 的阿里云 ROS 模板部署技能,负责可用性查询、执行部署与失败恢复
SOC 職業分類に基づく
SKILL.md を表示中
| name | iac-aliyun-architecture |
| description | 根据用户意图生成差异化候选架构方案,简单需求直接给出唯一方案 |
| conclusion_schema | {"type":"object","required":["candidates"],"additionalProperties":false,"properties":{"candidates":{"type":"array","minItems":1,"items":"[Truncated]"}}} |
根据前一步提取的用户意图,设计阿里云架构方案供用户选择。
方案数量取决于需求复杂度,而非固定出 2-3 个凑数:
判断标准:如果你需要添加用户完全没提到的产品来"制造"差异,那就不该有多个方案。
若用户要求在 ECS 上部署 iac-code Agent(包括将其称为 iac-code Web),按 iac-code Web 方案处理:只生成一个单 ECS + EIP 候选,安全组仅开放 8766,不得增加其他入口资源;
将其 candidate.name 固定为 iac-code-web-single-ecs。
当需求确实存在设计取舍时,根据场景从以下维度中选择最相关的来构建差异方案:
| 维度 | 适用场景 | 示例 |
|---|---|---|
| 成本梯度 | 用户未明确预算,需求可高可低配 | 开发环境 vs 生产环境规格 |
| 可用性级别 | 业务关键程度不明确 | 单可用区 vs 多可用区冗余 |
| 托管 vs 自建 | 同一能力有托管服务和自建方案 | RDS vs 自建 MySQL on ECS |
| 架构模式 | 业务规模和演进方向不确定 | 单体 vs 微服务、同步 vs 异步 |
| Serverless vs 传统 | 流量模式不确定 | FC + API Gateway vs ECS + SLB |
| 弹性策略 | 负载是否可预测 | 固定规格 vs 弹性伸缩组 |
| 数据方案 | 数据量级/访问模式不明确 | 单实例 RDS vs 读写分离 vs PolarDB |
不要机械地套用上表。选维度的依据是用户意图中实际存在的不确定性——哪里有取舍,就在哪里提供选择。
resource_intents如果 intent 中存在 resource_intents,它是架构设计的硬约束:
action=create 的资源可以作为本方案要新建的资源。不要把 action=use_existing 或 action=reference 的资源设计成新建资源。action=use_existing/reference 必须作为已有资源引用,后续模板中应通过参数(如 VpcId)或用户提供 ID 引用,不得生成对应的新建资源。换句话说,use_existing/reference 必须作为已有资源引用。action=forbid 的资源不得出现在候选方案的新增资源里,也不得作为“顺手补齐”的依赖加入。resource_intents 原样或按方案收窄后写入每个 candidate,供模板生成步骤继续执行同一约束。示例:intent 表示“已有 VPC 中创建安全组”时,candidate 应包含 resource_intents: [{"product": "VPC", "action": "use_existing"}, {"product": "SecurityGroup", "action": "create"}]。不得生成 VSwitch,也不得设计成“创建 VPC + VSwitch + SecurityGroup”。
以 intent.hard_constraints 为起点,并应用用户在进入或执行本步骤后明确提出的修改,将当前有效的完整约束快照写入每个 candidate 的 hard_constraints,包括 verification_mode。同一约束被用户修改时保留稳定 id 并更新其它字段;用户明确删除约束时从快照中删除。不得把推断规格或本方案推荐值新增为用户硬约束。方案差异只能发生在当前硬约束允许的空间内;某方案无法满足时不要生成该方案。
调用 complete_step 提交结论。字段定义见 tool schema。
templates/{index}-{英文简写}.ymltemplates/1-simple-nginx.yml、templates/2-high-availability-slb.yml当只有 1 个方案时,candidates 只有 1 个元素。