Back to Details

composable-primitives

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Composable Primitives Skill

可组合Agent原语Skill

Guide design of composable agentic primitives for flexible workflow creation.
指导设计用于灵活工作流创建的可组合Agent原语。

When to Use

适用场景

  • Designing new agentic workflows
  • Customizing SDLC for specific needs
  • Mapping problem classes to primitives
  • Building organization-specific compositions
  • 设计新的Agent工作流
  • 根据特定需求定制SDLC
  • 将问题类别映射到原语
  • 构建组织专属的组合方案

The Secret

核心秘诀

"The secret of tactical agentic coding is that it's not about the software developer lifecycle at all. It's about composable agentic primitives you can use to solve any engineering problem class."
"战术性Agent编码的秘诀根本不在于软件开发生命周期，而在于可组合的Agent原语——你可以用它们解决任何类型的工程问题。"

Core Primitives

核心原语

PrimitivePurposeInputOutput
ClassifyCategorize inputIssue/taskClassification
PlanCreate implementation specIssuePlan file
BuildImplement the planPlan fileCode changes
TestValidate functionalityCode changesPass/fail
ReviewValidate alignmentSpec + codeIssue list
PatchFix specific issuesIssue descriptionTargeted fix
DocumentGenerate documentationCode changesDoc files
ShipDeploy to productionValidated codeDeployed state
BranchCreate isolated contextClassificationBranch name
CommitSave checkpointChangesCommit hash
PrimitivePurposeInputOutput
Classify对输入进行分类需求/任务分类结果
Plan创建实现规范需求计划文件
Build执行计划实现计划文件代码变更
Test验证功能有效性代码变更通过/失败
Review验证一致性规范+代码问题列表
Patch修复特定问题问题描述针对性修复
Document生成文档代码变更文档文件
Ship部署到生产环境已验证代码已部署状态
Branch创建隔离上下文分类结果分支名称
Commit保存检查点变更内容提交哈希值

Composition Workflow

组合工作流步骤

Step 1: Identify Problem Class

步骤1：确定问题类别

What type of work?
  • Chore (simple, low risk)
  • Bug (medium complexity, clear criteria)
  • Feature (complex, full SDLC)
  • Hotfix (urgent, minimal process)
  • Documentation (content only)
工作类型属于哪一类？
  • Chore（简单、低风险）
  • Bug（中等复杂度、标准明确）
  • Feature（复杂、完整SDLC）
  • Hotfix（高优先级、流程最简）
  • Documentation（仅内容创作）

Step 2: Select Primitives

步骤2：选择原语

Based on problem class, choose primitives:
Problem ClassPrimitives
ChoreClassify -> Build -> Test -> Ship
BugClassify -> Plan -> Build -> Test -> Review -> Ship
FeatureFull SDLC
HotfixPatch -> Test -> Ship
DocumentationDocument -> Review -> Ship
根据问题类别选择对应原语：
问题类别原语组合
ChoreClassify -> Build -> Test -> Ship
BugClassify -> Plan -> Build -> Test -> Review -> Ship
Feature完整SDLC流程
HotfixPatch -> Test -> Ship
DocumentationDocument -> Review -> Ship

Step 3: Order by Dependencies

步骤3：按依赖关系排序

Ensure correct sequencing:
  • Plan before Build (Build needs plan)
  • Build before Test (Test needs code)
  • Test before Ship (Ship needs validation)
确保正确的执行顺序：
  • Plan需在Build之前（Build依赖计划文件）
  • Build需在Test之前（Test依赖代码变更）
  • Test需在Ship之前（Ship依赖验证结果）

Step 4: Add Validation Points

步骤4：添加验证节点

Where should failures stop the pipeline?
text
Plan -> Build -> [Test GATE] -> Review -> [Review GATE] -> Ship
哪些环节需要设置失败拦截？
text
Plan -> Build -> [Test GATE] -> Review -> [Review GATE] -> Ship

Step 5: Define Entry/Exit

步骤5：定义入口与出口

  • Entry: What triggers this workflow?
  • Exit: What signals completion?
  • 入口：触发该工作流的条件是什么？
  • 出口：标志工作流完成的信号是什么？

Standard Compositions

标准组合方案

Full SDLC

完整SDLC流程

text
Classify -> Plan -> Build -> Test -> Review -> Document -> Ship
text
Classify -> Plan -> Build -> Test -> Review -> Document -> Ship

ZTE (Zero-Touch)

ZTE（零接触）流程

text
Classify -> Plan -> Build -> Test -> Review -> Document -> Ship
                              | |
                          [GATE]         [GATE]
text
Classify -> Plan -> Build -> Test -> Review -> Document -> Ship
                              | |
                          [GATE]         [GATE]

Quick Fix

快速修复流程

text
Classify -> Patch -> Test -> Ship
text
Classify -> Patch -> Test -> Ship

Review-Driven

评审驱动流程

text
Review -> Patch -> Test -> Ship
text
Review -> Patch -> Test -> Ship

Custom Composition Design

自定义组合设计

Organization Factors

组织需考虑因素

Consider:
  • Testing requirements (mandatory E2E?)
  • Review processes (who reviews?)
  • Documentation standards (auto-generated?)
  • Deployment pipelines (manual approval?)
  • Compliance needs (audit trails?)
需考量：
  • 测试要求（是否强制端到端测试？）
  • 评审流程（由谁负责评审？）
  • 文档标准（是否自动生成？）
  • 部署流水线（是否需要人工审批？）
  • 合规需求（是否需要审计追踪？）

Example: Compliance-Heavy

示例：高合规要求场景

text
Classify -> Plan -> [Compliance Review] -> Build -> Test ->
[Security Scan] -> Review -> Document -> [Approval] -> Ship
text
Classify -> Plan -> [Compliance Review] -> Build -> Test ->
[Security Scan] -> Review -> Document -> [Approval] -> Ship

Example: Rapid Iteration

示例：快速迭代场景

text
Build -> Test -> Ship (no planning for small changes)
text
Build -> Test -> Ship (小型变更无需规划)

Key Memory References

关键参考文档

  • @composable-primitives.md - Detailed primitives documentation
  • @template-engineering.md - Templates as primitive definitions
  • @adw-anatomy.md - ADW as composition framework
  • @composable-primitives.md - 原语详细文档
  • @template-engineering.md - 作为原语定义的模板
  • @adw-anatomy.md - 作为组合框架的ADW

Output Format

输出格式

Provide composition design:
markdown
undefined
请按以下格式提供组合设计：
markdown
undefined

Workflow Composition

工作流组合方案

Problem Class: {type} Entry Trigger: {trigger} Exit Criteria: {criteria}
问题类别: {type} 触发条件: {trigger} 完成标准: {criteria}

Primitives Selected

选定的原语

  1. Classify - Categorize the task
  2. Plan - Create implementation spec
  3. Build - Implement changes
  4. Test - Validate functionality
  5. Ship - Deploy to production
  1. Classify - 对任务进行分类
  2. Plan - 创建实现规范
  3. Build - 执行变更实现
  4. Test - 验证功能有效性
  5. Ship - 部署到生产环境

Composition Flow

组合流程


Classify -> Plan -> Build -> Test -> Ship
                              |
                          [GATE: Must pass]

```markdown

Classify -> Plan -> Build -> Test -> Ship
                              |
                          [GATE: 必须通过]

```markdown

Validation Gates

验证节点

  • After Test: Abort if tests fail
  • After Review: Optional based on confidence
  • 测试完成后：若测试失败则终止流程
  • 评审完成后：可根据置信度选择是否跳过

Customizations

自定义调整

  • [Organization-specific additions]
undefined
  • [组织专属的新增环节]
undefined

Anti-Patterns

反模式

  • Rigid SDLC thinking (must do all steps)
  • Over-composition (too many primitives)
  • Under-composition (missing critical steps)
  • Ignoring failure paths (no gates)
  • One-size-fits-all (same for all problem classes)
  • 僵化的SDLC思维（必须执行所有步骤）
  • 过度组合（使用过多原语）
  • 组合不足（遗漏关键步骤）
  • 忽略失败路径（未设置验证节点）
  • 一刀切方案（所有问题类别使用相同流程）

Version History

版本历史

  • v1.0.0 (2025-12-26): Initial release
  • v1.0.0 (2025-12-26): 初始版本

Last Updated

最后更新

Date: 2025-12-26 Model: claude-opus-4-5-20251101
日期: 2025-12-26 模型: claude-opus-4-5-20251101