tune-system

southgateai's avatarfrom southgateai

Review automation system operation and make conservative adjustments to cadences and thresholds when clearly warranted. Monthly maintenance task.

0stars🔀0forks📁View on GitHub🕐Updated Jan 10, 2026

When & Why to Use This Skill

The tune-system skill is a sophisticated meta-review tool designed for autonomous agents to perform self-optimization and maintenance. It analyzes operational data, execution history, and failure patterns to make evidence-based, conservative adjustments to system parameters like task cadences and priority thresholds, ensuring long-term stability and efficiency in complex automation workflows.

Use Cases

  • Monthly System Maintenance: Automatically reviews system health and operational metrics every 30 days to prevent performance drift and ensure all maintenance tasks are running on schedule.
  • Failure Pattern Analysis: Identifies recurring error types across multiple sessions to distinguish between transient API issues and systemic environmental failures, triggering necessary threshold adjustments.
  • Workflow Cadence Optimization: Analyzes task execution frequency against defined targets to fine-tune 'overdue' triggers, ensuring the agent focuses on the right tasks at the right time.
  • Convergence Tracking: Monitors project progress and quality metrics to provide a high-level overview of system health and recommend manual interventions when progress stalls.
nametune-system
descriptionReview automation system operation and make conservative adjustments to cadences and thresholds when clearly warranted. Monthly maintenance task.

Tune System

A meta-review skill that analyzes the automation system's own operation and makes conservative, evidence-based adjustments. Mirrors The Unfinishable Map's "Minimal Quantum Interaction" tenet: small, precise interventions with clear justification.

When to Use

  • Monthly maintenance: Runs on 30-day cadence (injected when 45 days overdue)
  • Post-milestone: After reaching convergence milestones (50%, 75%, etc.)
  • Manual invocation: When you notice operational issues
  • After significant failures: If failed_tasks count exceeds 5 in a session

Instructions

1. Load Data Sources

Read these files to gather operational data:

obsidian/workflow/evolution-state.yaml  # Primary metrics
obsidian/workflow/changelog.md          # Execution history
obsidian/workflow/todo.md               # Task patterns
obsidian/reviews/                       # Recent review outputs
obsidian/project/project-brief.md       # Project goals (reference)

2. Check Abort Conditions

STOP and escalate to human if any of these are true:

  • More than 50% of recent tasks (last 10) failed
  • Convergence has regressed for 3+ consecutive sessions
  • quality.critical_issues > 0
  • Any file read errors during analysis

If aborting, create a minimal report explaining why and skip to step 8.

3. Check Locked Settings

Read evolution-state.yaml for locked_settings section. These settings cannot be modified automatically—note them for the report.

4. Analyze Five Categories

A. Cadence Analysis

Compare last_runs timestamps against cadences settings:

  • Calculate days between actual runs for each maintenance task
  • Identify tasks frequently overdue (pattern: overdue in >60% of opportunities)
  • Identify tasks never reaching cadence (always run early)

Evidence required: 5+ data points (sessions) showing consistent pattern

B. Failure Pattern Analysis

Examine failed_tasks and recent_tasks:

  • Count failures by task type
  • Look for common error patterns
  • Identify environmental issues (missing files, API errors)

Evidence required: 3+ failures of same type or pattern

C. Queue Health Analysis

Examine queue_status and replenishment_source_counts:

  • Compare task sources (chain, research, gap, staleness) to execution rates
  • Check if certain sources produce tasks that never get executed
  • Monitor P3 promotion rate

Evidence required: 5+ sessions of queue data

D. Review Finding Patterns

Scan recent files in reviews/:

  • Identify issues raised multiple times but never addressed
  • Track issue resolution rate
  • Note recurring themes across pessimistic reviews

Evidence required: 3+ reviews showing same pattern

E. Convergence Progress

Analyze progress and quality metrics:

  • Calculate convergence rate (% change per session)
  • Identify stalled areas (no progress in 3+ sessions)
  • Compare current state to convergence_targets

Evidence required: 5+ sessions of convergence data

5. Generate Findings

For each finding, determine the tier:

Tier 1 — Automatic Changes (max 3 per session)

Small, safe adjustments with clear evidence. Apply directly:

Change Type Limits Example
Cadence adjustment ±2 days pessimistic-review: 7 → 5 days
Overdue threshold ±2 days validate-all overdue: 2 → 3 days
Replenishment weight ±20% chain source weight: 50 → 60

Before applying, verify:

  • Setting is not in locked_settings
  • Setting hasn't changed in last 60 days (check changelog)
  • Clear directional pattern (not random variation)

Tier 2 — Recommendations (log for human approval)

Medium-impact changes:

  • New task suggestions (add to todo.md as P3)
  • Cadence changes >2 days
  • Replenishment mode changes (conservative ↔ aggressive)
  • Convergence target adjustments

Tier 3 — Report Only (never automatic)

Changes requiring human judgment:

  • Skill instruction modifications
  • New skill creation
  • Tenet-related adjustments
  • Removing vetoed task constraints
  • Priority level promotions

6. Apply Tier 1 Changes

For each approved Tier 1 change:

  1. Record the previous value
  2. Apply the change to the appropriate file
  3. Add a comment noting the change date and rationale

Example change to evolution-state.yaml:

cadences:
  pessimistic-review: 5  # Changed from 7 by tune-system 2026-01-08 (overdue 4/5 sessions)

7. Update Evolution State

Add/update these fields in evolution-state.yaml:

last_runs:
  tune-system: [current ISO timestamp]

# Track what was changed for cooldown enforcement
tune_system_history:
  last_run: [ISO timestamp]
  changes_applied:
    - setting: cadences.pessimistic-review
      old_value: 7
      new_value: 5
      date: [ISO date]
      rationale: "Overdue in 4 of 5 recent sessions"

8. Generate Report

Create report at obsidian/reviews/system-tune-YYYY-MM-DD.md:

---
title: "System Tuning Report - YYYY-MM-DD"
created: YYYY-MM-DD
modified: YYYY-MM-DD
human_modified: null
ai_modified: [ISO timestamp]
draft: false
topics: []
concepts: []
related_articles:
  - "[[todo]]"
  - "[[changelog]]"
ai_contribution: 100
author: null
ai_system: [current model]
ai_generated_date: YYYY-MM-DD
last_curated: null
---

# System Tuning Report

**Date**: YYYY-MM-DD
**Sessions analyzed**: N (sessions X to Y)
**Period covered**: [date range]

## Executive Summary

[2-3 sentences on overall system health and key findings]

## Metrics Overview

| Metric | Current | Previous | Trend |
|--------|---------|----------|-------|
| Session count | N | N-X | +X |
| Avg tasks/session | X.X | X.X | ↑/↓/→ |
| Failure rate | X% | X% | ↑/↓/→ |
| Convergence | X% | X% | +X% |
| Queue depth (P0-P2) | X | X | ↑/↓/→ |

## Findings

### Cadence Analysis

[Findings with evidence and recommendations]

### Failure Pattern Analysis

[Findings with evidence and recommendations]

### Queue Health Analysis

[Findings with evidence and recommendations]

### Review Finding Patterns

[Findings with evidence and recommendations]

### Convergence Progress

[Findings with evidence and recommendations]

## Changes Applied (Tier 1)

| File | Setting | Old | New | Rationale |
|------|---------|-----|-----|-----------|
| evolution-state.yaml | cadences.X | Y | Z | [reason] |

*No changes applied* — if none were warranted

## Recommendations (Tier 2)

### [Recommendation Title]
- **Proposed change**: [specific change]
- **Rationale**: [why this helps]
- **Risk**: Low/Medium
- **To approve**: [how human can apply]

## Items for Human Review (Tier 3)

### [Item Title]
- **Issue observed**: [description]
- **Why human needed**: [explanation]
- **Suggested action**: [what human might do]

## Next Tuning Session

- **Recommended**: [date, 30 days out]
- **Focus areas**: [what to watch]

9. Log to Changelog

Add entry to obsidian/workflow/changelog.md:

### HH:MM - tune-system
- **Status**: Success/Partial/Failed
- **Sessions analyzed**: N
- **Findings**: X cadence, Y failure, Z queue, W review, V convergence
- **Tier 1 changes**: N applied
- **Tier 2 recommendations**: N logged
- **Output**: `reviews/system-tune-YYYY-MM-DD.md`

Safeguards

Evidence Thresholds

Analysis Type Minimum Data Points
Cadence patterns 5 sessions
Failure patterns 3 occurrences
Queue patterns 5 sessions
Review patterns 3 reviews
Convergence trends 5 sessions

Change Cooldowns

After a Tier 1 change, that setting cannot be changed again for:

  • 2 tune-system sessions, OR
  • 60 days

Check tune_system_history.changes_applied before making any change.

Magnitude Limits

  • Cadence: ±2 days maximum
  • Threshold: ±2 days maximum
  • Weight: ±20 percentage points maximum
  • Maximum 3 Tier 1 changes per session

Locked Settings

Human can prevent automatic changes by adding to evolution-state.yaml:

locked_settings:
  cadences.check-tenets: "Locked 2026-01-10 - monthly cadence is intentional"

Important

DO NOT:

  • Modify skill instruction files (SKILL.md files)
  • Change priority levels (P0-P3) of existing tasks
  • Remove items from vetoed tasks
  • Modify anything related to tenets
  • Make changes without clear evidence (no speculative "improvements")
  • Exceed magnitude limits even if evidence seems strong
  • Change locked settings
  • Run more frequently than monthly (unless manually invoked)

DO:

  • Be conservative — when in doubt, recommend rather than apply
  • Document everything — all findings, all changes, all rationale
  • Respect cooldowns — no rapid oscillation of settings
  • Focus on operational parameters — cadences, thresholds, weights
  • Generate actionable recommendations for Tier 2/3 items