home / skills / plurigrid / asi / pijul

pijul skill

/skills/pijul

This skill helps manage patch-based version control inspired by categorical patch theory to ensure correct merges and sparse, lazy storage.

npx playbooks add skill plurigrid/asi --skill pijul

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
4.5 KB
---
name: pijul
description: Pijul patch-based VCS with categorical patch theory for skill versioning
version: 1.0.0
trit: -1
role: MINUS
color: "#4393DE"
source: flox install pijul
---

# pijul

Patch-based version control with mathematically sound commutative patch theory.

**Trit**: -1 (MINUS) - Validator role for patch verification and merge correctness

---

## Overview

Pijul is a distributed VCS where patches are first-class citizens that commute when independent. This maps directly to:
- **GF(3) skill derivation chains**: patches as morphisms between skill states
- **Pushouts = merges**: categorical semantics for conflict resolution
- **Sparsity preservation**: changes stored as morphisms, not materialized states

---

## Installation via flox-mcp

```bash
# Using flox CLI
flox install pijul

# Via MCP (flox_install tool)
{"name": "flox_install", "arguments": {"package": "pijul"}}
```

---

## Core Commands

### Repository Operations

```bash
# Initialize
pijul init

# Clone (partial clone supported!)
pijul clone https://nest.pijul.com/user/repo
pijul clone --partial https://nest.pijul.com/user/repo  # sparse clone

# Record changes (creates patch)
pijul record -m "Add feature"

# Push/Pull
pijul push
pijul pull
```

### Patch Operations

```bash
# List patches (changes)
pijul log

# Show patch contents
pijul diff

# Apply specific patch
pijul apply <hash>

# Unapply (revert) patch
pijul unrecord <hash>

# Fork (branch)
pijul fork <name>

# Switch channel (branch)
pijul channel switch <name>
```

### Sparse Operations

```bash
# Partial clone - only fetch needed patches
pijul clone --partial <url>

# Fetch specific patches
pijul pull --from-channel <channel>

# Lazy evaluation - patches fetched on demand
pijul reset --lazy
```

---

## Categorical Patch Theory

### Patches as Morphisms

```
State_A --patch_1--> State_B --patch_2--> State_C
                                    
If patch_1 ⊥ patch_2 (independent):
  patch_1 ; patch_2 = patch_2 ; patch_1
```

### Pushout for Merges

```
     State_A
      /   \
   p_1     p_2
    /       \
State_B    State_C
    \       /
     p_2'  p_1'
      \   /
     State_D (pushout)
```

When patches are independent, their pushout is unique and well-defined.

---

## GF(3) Integration

### Sparse Mode (Default)

```
trit == -1 or +1: Store as morphism (patch)
  - No materialization
  - Lazy evaluation
  - Minimal storage
```

### Projection Mode (ERGODIC Gate)

```
trit == 0: Force materialization
  - Coordination point
  - Full state snapshot
  - Archive checkpoint
```

### Projection Triggers

1. `--materialize` flag explicit
2. `trit == 0` (ERGODIC coordination)
3. Explicit archive command
4. Conflict resolution requiring full state

---

## Skill Versioning Pattern

### Record Skill Change

```bash
cd .agents/skills/my-skill
pijul record -m "Add GF(3) frontmatter"
```

### Sync with Upstream

```bash
# Sparse pull - only new patches
pijul pull --partial

# Check for conflicts
pijul log --pending
```

### Fork for Experimentation

```bash
pijul fork experiment
pijul channel switch experiment
# ... make changes ...
pijul record -m "Experimental patch"

# Merge back if successful
pijul channel switch main
pijul pull --from-channel experiment
```

---

## Integration with flox

### Install via flox Environment

```toml
# manifest.toml
[install]
pijul.pkg-path = "pijul"
```

### Activate and Use

```bash
flox activate
pijul --version
```

### MCP Tool Call

```json
{
  "name": "flox_install",
  "arguments": {"package": "pijul"}
}
```

---

## References

- [Pijul Manual](https://pijul.org/manual/)
- [Nest (Pijul Forge)](https://nest.pijul.com)
- Mimram/Di Giusto: Categorical Patch Theory
- Delta-State CRDTs / Merkle Search Trees
- [flox-mcp skill](../flox-mcp/SKILL.md)
- [structured-decomp skill](../structured-decomp/SKILL.md)

---

## Triadic Composition

```
pijul (-1)  + flox-mcp (0)  + skill-creator (+1) = 0 ✓
Validator     Coordinator     Generator
```

Pijul validates patch correctness, flox-mcp coordinates environment, skill-creator generates new skills.

## SDF Interleaving

This skill connects to **Software Design for Flexibility** (Hanson & Sussman, 2021):

### Primary Chapter: 10. Adventure Game Example

**Concepts**: autonomous agent, game, synthesis

### GF(3) Balanced Triad

```
pijul (+) + SDF.Ch10 (+) + [balancer] (+) = 0
```

**Skill Trit**: 1 (PLUS - generation)

### Secondary Chapters

- Ch5: Evaluation
- Ch4: Pattern Matching

### Connection Pattern

Adventure games synthesize techniques. This skill integrates multiple patterns.

Overview

This skill integrates the Pijul patch-based version control model for managing skill source as commutative, categorical patches. It treats changes as morphisms, preserving sparsity and enabling lazy evaluation, partial clones, and mathematically grounded merges. The skill is optimized for sparse skill repositories and workflows that benefit from patch algebra and GF(3)-informed coordination.

How this skill works

The skill records changes as patches (morphisms) that commute when independent, allowing merges to be computed as categorical pushouts rather than state diffs. Sparse mode stores only patches and performs lazy evaluation; projection mode materializes full state snapshots when coordination or conflict resolution requires it. Commands support recording, applying, listing, partial cloning, and channel-based workflows to enable experimental forks and reproducible synchronizations.

When to use it

  • When you need fine-grained, commute-aware versioning of skill artifacts instead of whole-state snapshots
  • When working with large skill trees where sparse storage and lazy fetching reduces bandwidth and disk use
  • When experimental branching and reproducible merges are common and mathematical merge semantics are desired
  • When integrating with flox environments or automated MCP flows that install or activate toolchains
  • When you need deterministic conflict handling using categorical pushouts and occasional full-state projections

Best practices

  • Record small, focused patches (one logical change per patch) to maximize commutativity and merge clarity
  • Use sparse clones for CI agents and edge environments; materialize only for archives or complex conflict resolution
  • Fork and switch channels for experiments; merge back using pull --from-channel after verification
  • Trigger projection deliberately (--materialize or archival commands) to create checkpoints and coordination points
  • Use pijul log and pijul log --pending to inspect pending patches before synchronizing with upstream

Example use cases

  • Versioning individual skill modules in an agent repository where changes are frequent and orthogonal
  • Lightweight CI runners that fetch only required patches on demand to run tests or builds
  • Experiment branches for feature synthesis: fork a channel, record experimental patches, and merge if validated
  • Coordination points in multi-agent workflows where GF(3) trit == 0 forces a full snapshot for auditing
  • Repairing or reverting a specific logical change via pijul unrecord without touching unrelated history

FAQ

How does sparse mode affect storage and fetch behavior?

Sparse mode stores patches as morphisms and lazily fetches material only when needed, reducing storage and network use; full snapshots occur only with explicit materialize triggers or conflict resolution.

When should I force a projection (materialize)?

Force projection when creating archives, coordinating across many agents (trit == 0), or when resolving complex conflicts that require a concrete full-state view.