Skip to content
Back to skills

Ct Contribution

ASecurity

Guided workflow for multi-agent consensus contributions. Use when user says "/contribution", "contribution protocol", "submit contribution", "consensus workflow", "multi-agent decision", "create contribution", "contribution start", "contribution submit", "detect conflicts", "weighted consensus", "decision tracking", "conflict resolution".

  • 160 stars
  • 0 votes
  • 0 copies
  • 2 views
  • Added May 28, 2026
toolsgobashnodetestingdocumentation

Works with

  • cursor
  • terminal
  • cli

Security analysis

A100/100

Pro scans all 2 files and shows the line behind each finding

Scanned October 1, 2026

npx -y skills add kryptobaseddev/cleo --skill ct-contribution --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Ct Contribution?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Ct Contribution
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/kryptobaseddev-ct-contribution/badge)](https://www.skillsdirectory.com/skills/kryptobaseddev-ct-contribution)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: ct-contribution
description: >-
  Guided workflow for multi-agent consensus contributions.
  Use when user says "/contribution", "contribution protocol", "submit contribution",
  "consensus workflow", "multi-agent decision", "create contribution",
  "contribution start", "contribution submit", "detect conflicts",
  "weighted consensus", "decision tracking", "conflict resolution".
version: 1.0.2
protocol: contribution
adrRefs:
  - ADR-015
  - ADR-053
dependencies: []
sharedResources:
  - subagent-protocol-base
compatibility:
  - claude-code
  - cursor
  - windsurf
  - gemini-cli
license: MIT
metadata:
  version: 1.0.2
  tier: on-demand
  install: harness
  covers:
    - packages/core/src/validation/protocols/cant/contribution.cant
    - packages/core/src/validation/protocols/protocols-markdown/contribution.md
  loomStage: contribution
  lastReviewed: 2026-09-28
  stability: stable
---

# Contribution Protocol Skill

You are a contribution protocol agent. Your role is to guide multi-agent consensus workflows through structured decision documentation, conflict detection, and consensus computation using JSON-first formats.

## Overview

The Contribution Protocol enables:
- **Machine-parseable decisions** with confidence scores
- **Evidence-based rationale** with traceable references
- **Automated conflict detection** across parallel sessions
- **Weighted consensus computation** for multi-agent agreement

### When to Use

| Scenario | Use Contribution Protocol? | Rationale |
|----------|---------------------------|-----------|
| Multi-agent research (2+ sessions) | **Yes** | Structured conflict detection |
| Consensus-building on architecture | **Yes** | Weighted voting, evidence tracking |
| RCASD-IVTR+C pipeline integration | **Yes** | JSON format enables automation |
| Single-agent research | No | Simpler research manifest sufficient |
| Quick decision with no alternatives | No | Protocol overhead not justified |

---

## Commands

### `/contribution start <epic-id>`

Initialize contribution tracking for an epic.

**Usage**:
```
/contribution start T2204
/contribution start T2204 --label rcsd-contrib
```

**Workflow**:
1. Verify epic exists and is active
2. Create contribution task under epic
3. Initialize contribution directories
4. Generate contribution ID
5. Return task ID and setup instructions

**Parameters**:
| Parameter | Description | Default |
|-----------|-------------|---------|
| `<epic-id>` | Parent epic task ID | Required |
| `--label` | Marker label for discovery | `consensus-source` |
| `--agent` | Agent identifier | Current agent |

### `/contribution submit`

Validate and submit the current contribution.

**Usage**:
```
/contribution submit
/contribution submit --task T2215
```

**Workflow**:
1. Validate contribution JSON against schema
2. Compute checksum for integrity
3. Append entry to CONTRIBUTIONS.jsonl manifest
4. Update task notes with contribution reference
5. Mark contribution status as `complete`
6. Return submission confirmation

**Parameters**:
| Parameter | Description | Default |
|-----------|-------------|---------|
| `--task` | Contribution task ID | Current focused task |
| `--dry-run` | Validate without submitting | false |

### `/contribution conflicts [epic-id]`

Detect conflicts between contributions for an epic.

**Usage**:
```
/contribution conflicts T2204
/contribution conflicts --severity high
```

**Workflow**:
1. Load all contributions for epic
2. Group decisions by questionId
3. Compare answers for semantic conflicts
4. Classify conflict type and severity
5. Return conflict report with resolution suggestions

**Parameters**:
| Parameter | Description | Default |
|-----------|-------------|---------|
| `[epic-id]` | Epic to analyze | Current scope |
| `--severity` | Filter by severity | all |

**Output**:
```json
{
  "epicId": "T2204",
  "conflictCount": 2,
  "conflicts": [
    {
      "questionId": "ARCH-001",
      "severity": "high",
      "positions": [
        {"agentId": "opus-1", "answer": "Position A", "confidence": 0.85},
        {"agentId": "sonnet-1", "answer": "Position B", "confidence": 0.75}
      ]
    }
  ]
}
```

### `/contribution status [epic-id]`

Show contribution progress and consensus status.

**Usage**:
```
/contribution status
/contribution status T2204
```

**Workflow**:
1. Query manifest for epic contributions
2. Calculate completion statistics
3. Identify pending conflicts
4. Show consensus progress per question
5. Return status summary

**Output**:
```json
{
  "epicId": "T2204",
  "totalContributions": 3,
  "complete": 2,
  "partial": 1,
  "blocked": 0,
  "conflictsPending": 2,
  "questionsAnswered": 5,
  "consensusReady": false
}
```

---

## Workflow Guides

### Starting a New Contribution

```bash
# 1. Verify epic exists
ct show T2204

# 2. Initialize contribution
/contribution start T2204 --label rcsd-contrib

# 3. Create contribution task (if not auto-created)
ct add "Session B: Architecture Analysis" \
  --parent T2204 \
  --labels consensus-source,research \
  --phase core

# 4. Start task
ct start T2215

# 5. Create contribution directory
mkdir -p .cleo/contributions

# 6. Generate contribution ID
source lib/contribution-protocol.sh
CONTRIB_ID=$(contribution_generate_id)
echo "Contribution ID: $CONTRIB_ID"
```

### Writing a Contribution

Create `.cleo/contributions/T2215.json`:

```json
{
  "$schema": "https://cleo-dev.com/schemas/v2/contribution.schema.json",
  "_meta": {
    "contributionId": "contrib_a1b2c3d4",
    "protocolVersion": "2.0.0",
    "createdAt": "2026-01-26T14:00:00Z",
    "agentId": "opus-1",
    "consensusReady": false
  },
  "sessionId": "session_20260126_140000_abc123",
  "epicId": "T2204",
  "taskId": "T2215",
  "markerLabel": "consensus-source",
  "researchOutputs": [],
  "decisions": [
    {
      "questionId": "ARCH-001",
      "question": "Single file or split file architecture?",
      "answer": "Single JSON file with internal sections",
      "confidence": 0.85,
      "rationale": "Simplifies atomic updates and validation",
      "evidence": [
        {
          "file": "lib/file-ops.sh",
          "section": "atomic_write function",
          "type": "code"
        }
      ]
    }
  ],
  "conflicts": [],
  "status": "draft"
}
```

### Submitting a Contribution

```bash
# 1. Validate contribution
/contribution submit --dry-run

# 2. Submit contribution
/contribution submit --task T2215

# 3. Complete task
ct complete T2215
```

### Detecting and Resolving Conflicts

```bash
# 1. Check for conflicts
/contribution conflicts T2204

# 2. Review conflict details
jq '.conflicts[] | select(.severity == "high")' .cleo/contributions/CONTRIBUTIONS.jsonl

# 3. Add conflict resolution to contribution
# Edit .cleo/contributions/T2215.json to add:
{
  "conflicts": [
    {
      "questionId": "ARCH-001",
      "conflictId": "conflict_b2c3d4e5",
      "severity": "high",
      "conflictType": "contradiction",
      "thisSession": {
        "position": "Single file architecture",
        "confidence": 0.85,
        "evidence": [...]
      },
      "otherSession": {
        "sessionId": "session_...",
        "position": "Split file architecture",
        "confidence": 0.75,
        "evidence": [...]
      },
      "rationale": "Different priorities: simplicity vs parallelism",
      "resolution": {
        "status": "proposed",
        "resolutionType": "merge",
        "proposal": "Single file with future split option"
      },
      "requiresConsensus": true
    }
  ]
}

# 4. Re-submit with conflict documentation
/contribution submit
```

---

## JSON Format Reference

> **Authoritative Specification**: [CONTRIBUTION-FORMAT-SPEC.md](../../docs/specs/CONTRIBUTION-FORMAT-SPEC.md)
>
> **JSON Schema**: [contribution.schema.json](../../schemas/contribution.schema.json)

### Decision Object

```json
{
  "questionId": "RCSD-001",
  "question": "The decision question being answered",
  "answer": "Concrete, actionable decision (no hedging)",
  "confidence": 0.85,
  "rationale": "Reasoning with evidence references",
  "evidence": [
    {
      "file": "lib/file-ops.sh",
      "section": "atomic_write function",
      "quote": "temp file -> validate -> backup -> rename",
      "line": 142,
      "type": "code"
    }
  ],
  "uncertaintyNote": "Required if confidence < 0.7",
  "alternatives": [
    {
      "option": "Alternative considered",
      "reason": "Why not chosen"
    }
  ]
}
```

### Confidence Score Semantics

| Range | Level | Requirements |
|-------|-------|--------------|
| 0.90-1.00 | Very High | MUST have 2+ independent evidence sources |
| 0.70-0.89 | High | MUST have at least 1 evidence source |
| 0.50-0.69 | Medium | SHOULD include `uncertaintyNote` |
| 0.30-0.49 | Low | MUST include `uncertaintyNote` |
| 0.00-0.29 | Tentative | MUST include `uncertaintyNote`, SHOULD NOT use for critical decisions |

### Conflict Severity

| Severity | Definition | Action |
|----------|------------|--------|
| `critical` | Mutually exclusive positions | MUST resolve before merge |
| `high` | Significant implementation impact | SHOULD resolve before merge |
| `medium` | Both approaches viable | MAY defer resolution |
| `low` | Minor preference differences | MAY accept either |

---

## Library Integration

The skill uses functions from `lib/contribution-protocol.sh`:

### contribution_generate_id()

Generate unique contribution ID.

```bash
source lib/contribution-protocol.sh
id=$(contribution_generate_id)
echo "$id"  # contrib_a1b2c3d4
```

### contribution_validate_task()

Validate task against contribution protocol requirements.

```bash
source lib/contribution-protocol.sh
result=$(contribution_validate_task "T2215" "T2204" "consensus-source")
echo "$result" | jq '.valid'
```

### contribution_get_injection()

Get injection block for subagent prompts.

```bash
source lib/contribution-protocol.sh
injection=$(contribution_get_injection "T2204" ".cleo/agent-outputs/protocol.md")
```

### contribution_create_manifest_entry()

Create a contribution manifest entry.

```bash
source lib/contribution-protocol.sh
entry=$(contribution_create_manifest_entry \
  "$CLEO_SESSION" \
  "T2204" \
  "T2215" \
  "opus-1"
)
echo "$entry" | jq '.'
```

---

## Task System Integration

@skills/_shared/task-system-integration.md

### Execution Sequence

1. Read task: `{{TASK_SHOW_CMD}} {{TASK_ID}}`
2. Start task: `{{TASK_START_CMD}} {{TASK_ID}}` (if not already started)
3. Create/load contribution JSON
4. Document decisions with evidence
5. Check for conflicts with baseline
6. Submit contribution to manifest
7. Complete task: `{{TASK_COMPLETE_CMD}} {{TASK_ID}}`
8. Return summary message

---

## Directory Structure

```
.cleo/contributions/
├── CONTRIBUTIONS.jsonl      # Append-only manifest
├── T2204.json              # Individual contribution files
├── T2205.json
└── archive/                # Completed epic contributions
    └── T1000/
        ├── CONTRIBUTIONS.jsonl
        └── *.json
```

---

## Manifest Query Patterns

### All contributions for an epic

```bash
jq -s '[.[] | select(.epicId == "T2204")]' .cleo/contributions/CONTRIBUTIONS.jsonl
```

### Contributions with conflicts

```bash
jq -s '[.[] | select(.conflictCount > 0)]' .cleo/contributions/CONTRIBUTIONS.jsonl
```

### Latest contribution for a task

```bash
jq -s '[.[] | select(.taskId == "T2215")] | sort_by(.updatedAt) | .[-1]' .cleo/contributions/CONTRIBUTIONS.jsonl
```

### Summary statistics

```bash
jq -s '{
  total: length,
  complete: [.[] | select(.status == "complete")] | length,
  partial: [.[] | select(.status == "partial")] | length,
  blocked: [.[] | select(.status == "blocked")] | length,
  totalConflicts: [.[].conflictCount] | add
}' .cleo/contributions/CONTRIBUTIONS.jsonl
```

---

## Completion Checklist

- [ ] Epic exists and is active
- [ ] Contribution task created with correct parent and label
- [ ] Task started
- [ ] Contribution JSON created with valid schema
- [ ] All decisions include rationale and evidence
- [ ] Low confidence decisions include uncertainty notes
- [ ] Conflicts with baseline documented
- [ ] Contribution submitted to manifest
- [ ] Task completed

---

## Error Handling

### Validation Errors

| Error Code | Message | Fix |
|------------|---------|-----|
| `CONTRIB-001` | Session ID mismatch | Use active CLEO session |
| `CONTRIB-002` | Missing marker label | Add label to task |
| `CONTRIB-005` | Missing decisions | Document all key questions |
| `CONTRIB-007` | Missing rationale/evidence | Complete decision objects |
| `CONTRIB-011` | Vague answer language | Use concrete, unambiguous answers |

### Recovery Patterns

**Checksum mismatch**:
```bash
# Recompute checksum
jq 'del(._meta.checksum)' .cleo/contributions/T2215.json | sha256sum | cut -c1-16
```

**Missing baseline reference**:
```bash
# Query for prior contributions
jq -s '[.[] | select(.epicId == "T2204")] | .[0]' .cleo/contributions/CONTRIBUTIONS.jsonl
```

---

## Related Documentation

| Document | Relationship |
|----------|--------------|
| [CONTRIBUTION-FORMAT-SPEC.md](../../docs/specs/CONTRIBUTION-FORMAT-SPEC.md) | **Authoritative** for JSON format |
| [contribution.schema.json](../../schemas/contribution.schema.json) | **Authoritative** for JSON Schema |
| [CONTRIBUTION-PROTOCOL-GUIDE.md](../../docs/guides/CONTRIBUTION-PROTOCOL-GUIDE.md) | Usage guide with examples |
| [CONSENSUS-FRAMEWORK-SPEC.md](../../docs/specs/CONSENSUS-FRAMEWORK-SPEC.md) | Consensus voting thresholds |

---

## LOOM Stage Binding (T9670)

`ct-contribution` is bound to LOOM lifecycle stage **`contribution`** — the terminal node of the RCASD-IVTR+C pipeline. Use this skill to formalize an Epic's contribution back to canon after its work has converged.

### Stage-Transition Contract

The contribution stage is entered from one of two upstream stages depending on the Epic's `kind`:

| Upstream stage | Epic kind | Entry condition |
|---|---|---|
| **`release`** | most epics (work, bug, experiment) | Release tag pushed; release manifest recorded |
| **`testing`** | epics whose `kind` is `release` or that gate on IVTR | IVT loop converged; `ivtLoopConverged: true` recorded |
| **`specification`** | spec-only epics (no code) | Specification accepted; HITL signoff recorded |

```
research → consensus → architecture_decision → specification → decomposition
                                                                   ↓
                                                            implementation
                                                                   ↓
                                                              validation
                                                                   ↓
                                                                testing  ← (some epics return here)
                                                                   ↓
                                                                release
                                                                   ↓
                                                            contribution  ← (this skill)
```

The transition is enforced by the playbook runtime defined in **ADR-053**. The runtime is a deterministic state machine; `contribution` is its terminal accepting state. Once entered, the Epic is closed in canon.

### Acceptance-Gate Evidence

The contribution stage's completion gate is satisfied by emitting **at least one** of the following ADR-051 evidence atoms, recorded via `cleo verify <epicId> --gate contribution --evidence "<atoms>"`:

| Atom kind | Format | Meaning |
|---|---|---|
| `decision:` | `decision:D-<slug>` | A BRAIN decision id that records the contribution outcome. |
| `files:` | `files:path/a.md,path/b.md` | A list of contribution-format JSON / markdown deliverables produced by `/contribution submit`. |
| `note:` | `note:<freeform>` | Owner-attested closure rationale; preferred when the contribution is non-textual (e.g. a tag push referenced by SHA in the note). |

Example:

```bash
cleo verify T9568 --gate contribution \
  --evidence "decision:D-loom-coverage-001;files:.cleo/contributions/T9568-final.json"
cleo complete T9568
```

The gate validator (ADR-051 §2.4) rejects an empty evidence string with `E_EVIDENCE_MISSING`. Stale evidence (modified files after `verify` but before `complete`) fails with `E_EVIDENCE_STALE`.

### Open Follow-Up

A future ADR dedicated to the contribution stage's lifecycle gates (covering automated rollup signals from `cleo saga rollup`, multi-Epic contribution aggregation, and the contribution → "saga close" promotion path) is on the roadmap. File via:

```bash
cleo add --kind work --type task --severity P2 \
  --title "T-LOOM-GAP-ADR-CONTRIBUTION: dedicated ADR for contribution stage gates" \
  --relates T9670 \
  --acceptance "ADR drafted under .cleo/adrs/|Cross-referenced from ct-contribution SKILL.md|Validator gate updated"
```

Until that ADR lands, contribution gates derive from ADR-015 (multi-contributor architecture) and ADR-053 (playbook runtime) — both already referenced in this skill's `adrRefs`.

---

## See also / References

This skill binds to the **contribution** LOOM lifecycle stage (the final stage of the RCASD-IVTR+C pipeline). Governing ADRs:

- [ADR-015 — multi-contributor architecture](../../../../.cleo/adrs/ADR-015-multi-contributor-architecture.md) — defines the multi-contributor consensus mechanics that this stage formalizes for an Epic's downstream return path.
- [ADR-053 — playbook runtime](../../../../.cleo/adrs/ADR-053-playbook-runtime.md) — defines the lifecycle state machine; contribution is its terminal node.

LOOM coverage matrix: [docs/skills/loom-coverage-matrix.md](../../../../docs/skills/loom-coverage-matrix.md).

Files in this skill

  • SKILL.md17.2 KB
  • templates/contribution-init.json548 B

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.