搜索

PythonReactSEOPDF
GitHub Skill

composable-primitives

Design composable agentic primitives for flexible workflows. Use when creating reusable workflow building blocks, designing SDLC primitives, or building agent operations that can be combined in different ways.

melodic-software☆ 21 仓库 Stars4 仓库 Forks

安装与使用

请根据来源仓库和你的 AI 工具说明安装此技能。先阅读技能文件和依赖要求,再添加到工作流。

查看来源 ↗使用指南

技能说明

Composable Primitives Skill

Guide design of composable agentic primitives for flexible workflow creation.

When to Use

  • Designing new agentic workflows
  • Customizing SDLC for specific needs
  • Mapping problem classes to primitives
  • Building organization-specific compositions

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."

Core Primitives

Primitive Purpose Input Output
Classify Categorize input Issue/task Classification
Plan Create implementation spec Issue Plan file
Build Implement the plan Plan file Code changes
Test Validate functionality Code changes Pass/fail
Review Validate alignment Spec + code Issue list
Patch Fix specific issues Issue description Targeted fix
Document Generate documentation Code changes Doc files
Ship Deploy to production Validated code Deployed state
Branch Create isolated context Classification Branch name
Commit Save checkpoint Changes Commit hash

Composition Workflow

Step 1: Identify Problem Class

What type of work?

  • Chore (simple, low risk)
  • Bug (medium complexity, clear criteria)
  • Feature (complex, full SDLC)
  • Hotfix (urgent, minimal process)
  • Documentation (content only)
Step 2: Select Primitives

Based on problem class, choose primitives:

Problem Class Primitives
Chore Classify -> Build -> Test -> Ship
Bug Classify -> Plan -> Build -> Test -> Review -> Ship
Feature Full SDLC
Hotfix Patch -> Test -> Ship
Documentation Document -> Review -> Ship
Step 3: Order by Dependencies

Ensure correct sequencing:

  • Plan before Build (Build needs plan)
  • Build before Test (Test needs code)
  • Test before Ship (Ship needs validation)
Step 4: Add Validation Points

Where should failures stop the pipeline?

Plan -> Build -> [Test GATE] -> Review -> [Review GATE] -> Ship
Step 5: Define Entry/Exit
  • Entry: What triggers this workflow?
  • Exit: What signals completion?

Standard Compositions

Full SDLC
Classify -> Plan -> Build -> Test -> Review -> Document -> Ship
ZTE (Zero-Touch)
Classify -> Plan -> Build -> Test -> Review -> Document -> Ship
                              | |
                          [GATE]         [GATE]
Quick Fix
Classify -> Patch -> Test -> Ship
Review-Driven
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
Classify -> Plan -> [Compliance Review] -> Build -> Test ->
[Security Scan] -> Review -> Document -> [Approval] -> Ship
Example: Rapid Iteration
Build -> Test -> Ship (no planning for small changes)

Key Memory References

  • @composable-primitives.md - Detailed primitives documentation
  • @template-engineering.md - Templates as primitive definitions
  • @adw-anatomy.md - ADW as composition framework

Output Format

Provide composition design:

## Workflow Composition

**Problem Class:** {type}
**Entry Trigger:** {trigger}
**Exit Criteria:** {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

### Composition Flow

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


### Validation Gates

- After Test: Abort if tests fail
- After Review: Optional based on confidence

### Customizations

- [Organization-specific additions]

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)

Version History

  • v1.0.0 (2025-12-26): Initial release

Last Updated

Date: 2025-12-26 Model: claude-opus-4-5-20251101

使用示例

查看来源仓库中的使用示例与配置说明。

查看来源 ↗

来源历史

收录时间
2026-01-20
索引更新时间
2026-02-04
Branch
main

收录与同步日期属于本站记录。源码修改历史请查看来源仓库。

GitHub ↗

chat Comments (0)

chat_bubble_outline

No comments yet. Be the first to share your thoughts!