@monoes/monomindcli 2.15.3 → 2.15.4

package/org-skills/golang-pro/references/testing.md

@@ -0,0 +1,451 @@
+# Testing and Benchmarking
+
+## Table-Driven Tests
+
+```go
+package math
+
+import "testing"
+
+func Add(a, b int) int {
+    return a + b
+}
+
+func TestAdd(t *testing.T) {
+    tests := []struct {
+        name     string
+        a, b     int
+        expected int
+    }{
+        {"positive numbers", 2, 3, 5},
+        {"negative numbers", -2, -3, -5},
+        {"mixed signs", -2, 3, 1},
+        {"zeros", 0, 0, 0},
+        {"large numbers", 1000000, 2000000, 3000000},
+    }
+
+    for _, tt := range tests {
+        t.Run(tt.name, func(t *testing.T) {
+            result := Add(tt.a, tt.b)
+            if result != tt.expected {
+                t.Errorf("Add(%d, %d) = %d; want %d", tt.a, tt.b, result, tt.expected)
+            }
+        })
+    }
+}
+```
+
+## Subtests and Parallel Execution
+
+```go
+func TestParallel(t *testing.T) {
+    tests := []struct {
+        name  string
+        input string
+        want  string
+    }{
+        {"lowercase", "hello", "HELLO"},
+        {"uppercase", "WORLD", "WORLD"},
+        {"mixed", "HeLLo", "HELLO"},
+    }
+
+    for _, tt := range tests {
+        tt := tt // Capture range variable for parallel tests
+        t.Run(tt.name, func(t *testing.T) {
+            t.Parallel() // Run subtests in parallel
+
+            result := strings.ToUpper(tt.input)
+            if result != tt.want {
+                t.Errorf("got %q, want %q", result, tt.want)
+            }
+        })
+    }
+}
+```
+
+## Test Helpers and Setup/Teardown
+
+```go
+func TestWithSetup(t *testing.T) {
+    // Setup
+    db := setupTestDB(t)
+    defer cleanupTestDB(t, db)
+
+    tests := []struct {
+        name string
+        user User
+    }{
+        {"valid user", User{Name: "John", Email: "john@example.com"}},
+        {"empty name", User{Name: "", Email: "test@example.com"}},
+    }
+
+    for _, tt := range tests {
+        t.Run(tt.name, func(t *testing.T) {
+            err := db.SaveUser(tt.user)
+            if err != nil {
+                t.Fatalf("SaveUser failed: %v", err)
+            }
+        })
+    }
+}
+
+// Helper function (doesn't show in stack trace)
+func setupTestDB(t *testing.T) *DB {
+    t.Helper()
+
+    db, err := NewDB(":memory:")
+    if err != nil {
+        t.Fatalf("failed to create test DB: %v", err)
+    }
+    return db
+}
+
+func cleanupTestDB(t *testing.T, db *DB) {
+    t.Helper()
+
+    if err := db.Close(); err != nil {
+        t.Errorf("failed to close DB: %v", err)
+    }
+}
+```
+
+## Mocking with Interfaces
+
+```go
+// Interface to mock
+type EmailSender interface {
+    Send(to, subject, body string) error
+}
+
+// Mock implementation
+type MockEmailSender struct {
+    SentEmails []Email
+    ShouldFail bool
+}
+
+type Email struct {
+    To, Subject, Body string
+}
+
+func (m *MockEmailSender) Send(to, subject, body string) error {
+    if m.ShouldFail {
+        return fmt.Errorf("failed to send email")
+    }
+    m.SentEmails = append(m.SentEmails, Email{to, subject, body})
+    return nil
+}
+
+// Test using mock
+func TestUserService_Register(t *testing.T) {
+    mockSender := &MockEmailSender{}
+    service := NewUserService(mockSender)
+
+    err := service.Register("user@example.com")
+    if err != nil {
+        t.Fatalf("Register failed: %v", err)
+    }
+
+    if len(mockSender.SentEmails) != 1 {
+        t.Errorf("expected 1 email sent, got %d", len(mockSender.SentEmails))
+    }
+
+    email := mockSender.SentEmails[0]
+    if email.To != "user@example.com" {
+        t.Errorf("expected email to user@example.com, got %s", email.To)
+    }
+}
+```
+
+## Benchmarking
+
+```go
+func BenchmarkAdd(b *testing.B) {
+    for i := 0; i < b.N; i++ {
+        Add(100, 200)
+    }
+}
+
+// Benchmark with subtests
+func BenchmarkStringOperations(b *testing.B) {
+    benchmarks := []struct {
+        name  string
+        input string
+    }{
+        {"short", "hello"},
+        {"medium", strings.Repeat("hello", 10)},
+        {"long", strings.Repeat("hello", 100)},
+    }
+
+    for _, bm := range benchmarks {
+        b.Run(bm.name, func(b *testing.B) {
+            for i := 0; i < b.N; i++ {
+                _ = strings.ToUpper(bm.input)
+            }
+        })
+    }
+}
+
+// Benchmark with setup
+func BenchmarkMapOperations(b *testing.B) {
+    m := make(map[string]int)
+    for i := 0; i < 1000; i++ {
+        m[fmt.Sprintf("key%d", i)] = i
+    }
+
+    b.ResetTimer() // Don't count setup time
+
+    for i := 0; i < b.N; i++ {
+        _ = m["key500"]
+    }
+}
+
+// Parallel benchmark
+func BenchmarkConcurrentAccess(b *testing.B) {
+    var counter int64
+
+    b.RunParallel(func(pb *testing.PB) {
+        for pb.Next() {
+            atomic.AddInt64(&counter, 1)
+        }
+    })
+}
+
+// Memory allocation benchmark
+func BenchmarkAllocation(b *testing.B) {
+    b.ReportAllocs() // Report allocations
+
+    for i := 0; i < b.N; i++ {
+        s := make([]int, 1000)
+        _ = s
+    }
+}
+```
+
+## Fuzzing (Go 1.18+)
+
+```go
+func FuzzReverse(f *testing.F) {
+    // Seed corpus
+    testcases := []string{"hello", "world", "123", ""}
+    for _, tc := range testcases {
+        f.Add(tc)
+    }
+
+    f.Fuzz(func(t *testing.T, input string) {
+        reversed := Reverse(input)
+        doubleReversed := Reverse(reversed)
+
+        if input != doubleReversed {
+            t.Errorf("Reverse(Reverse(%q)) = %q, want %q", input, doubleReversed, input)
+        }
+    })
+}
+
+// Fuzz with multiple parameters
+func FuzzAdd(f *testing.F) {
+    f.Add(1, 2)
+    f.Add(0, 0)
+    f.Add(-1, 1)
+
+    f.Fuzz(func(t *testing.T, a, b int) {
+        result := Add(a, b)
+
+        // Properties that should always hold
+        if result < a && b >= 0 {
+            t.Errorf("Add(%d, %d) = %d; result should be >= a when b >= 0", a, b, result)
+        }
+    })
+}
+```
+
+## Test Coverage
+
+```go
+// Run tests with coverage:
+// go test -cover
+// go test -coverprofile=coverage.out
+// go tool cover -html=coverage.out
+
+func TestCalculate(t *testing.T) {
+    tests := []struct {
+        name     string
+        input    int
+        expected int
+    }{
+        {"zero", 0, 0},
+        {"positive", 5, 25},
+        {"negative", -3, 9},
+    }
+
+    for _, tt := range tests {
+        t.Run(tt.name, func(t *testing.T) {
+            result := Calculate(tt.input)
+            if result != tt.expected {
+                t.Errorf("Calculate(%d) = %d; want %d", tt.input, result, tt.expected)
+            }
+        })
+    }
+}
+```
+
+## Race Detector
+
+```go
+// Run with: go test -race
+
+func TestConcurrentAccess(t *testing.T) {
+    var counter int
+    var wg sync.WaitGroup
+
+    // This will fail with -race if not synchronized
+    for i := 0; i < 10; i++ {
+        wg.Add(1)
+        go func() {
+            defer wg.Done()
+            counter++ // Data race!
+        }()
+    }
+
+    wg.Wait()
+}
+
+// Fixed version with mutex
+func TestConcurrentAccessSafe(t *testing.T) {
+    var counter int
+    var mu sync.Mutex
+    var wg sync.WaitGroup
+
+    for i := 0; i < 10; i++ {
+        wg.Add(1)
+        go func() {
+            defer wg.Done()
+            mu.Lock()
+            counter++
+            mu.Unlock()
+        }()
+    }
+
+    wg.Wait()
+
+    if counter != 10 {
+        t.Errorf("expected 10, got %d", counter)
+    }
+}
+```
+
+## Golden Files
+
+```go
+import (
+    "os"
+    "path/filepath"
+    "testing"
+)
+
+func TestRenderHTML(t *testing.T) {
+    data := Data{Title: "Test", Content: "Hello"}
+    result := RenderHTML(data)
+
+    goldenFile := filepath.Join("testdata", "expected.html")
+
+    if *update {
+        // Update golden file: go test -update
+        os.WriteFile(goldenFile, []byte(result), 0644)
+    }
+
+    expected, err := os.ReadFile(goldenFile)
+    if err != nil {
+        t.Fatalf("failed to read golden file: %v", err)
+    }
+
+    if result != string(expected) {
+        t.Errorf("output doesn't match golden file\ngot:\n%s\nwant:\n%s", result, expected)
+    }
+}
+
+var update = flag.Bool("update", false, "update golden files")
+```
+
+## Integration Tests
+
+```go
+// integration_test.go
+// +build integration
+
+package myapp
+
+import (
+    "testing"
+    "time"
+)
+
+func TestIntegration(t *testing.T) {
+    if testing.Short() {
+        t.Skip("skipping integration test in short mode")
+    }
+
+    // Long-running integration test
+    server := startTestServer(t)
+    defer server.Stop()
+
+    time.Sleep(100 * time.Millisecond) // Wait for server
+
+    client := NewClient(server.URL)
+    resp, err := client.Get("/health")
+    if err != nil {
+        t.Fatalf("health check failed: %v", err)
+    }
+
+    if resp.Status != "ok" {
+        t.Errorf("expected status ok, got %s", resp.Status)
+    }
+}
+
+// Run: go test -tags=integration
+// Run short tests only: go test -short
+```
+
+## Testable Examples
+
+```go
+// Example tests that appear in godoc
+func ExampleAdd() {
+    result := Add(2, 3)
+    fmt.Println(result)
+    // Output: 5
+}
+
+func ExampleAdd_negative() {
+    result := Add(-2, -3)
+    fmt.Println(result)
+    // Output: -5
+}
+
+// Unordered output
+func ExampleKeys() {
+    m := map[string]int{"a": 1, "b": 2, "c": 3}
+    keys := Keys(m)
+    for _, k := range keys {
+        fmt.Println(k)
+    }
+    // Unordered output:
+    // a
+    // b
+    // c
+}
+```
+
+## Quick Reference
+
+| Command | Description |
+|---------|-------------|
+| `go test` | Run tests |
+| `go test -v` | Verbose output |
+| `go test -run TestName` | Run specific test |
+| `go test -bench .` | Run benchmarks |
+| `go test -cover` | Show coverage |
+| `go test -race` | Run race detector |
+| `go test -short` | Skip long tests |
+| `go test -fuzz FuzzName` | Run fuzzing |
+| `go test -cpuprofile cpu.prof` | CPU profiling |
+| `go test -memprofile mem.prof` | Memory profiling |

package/org-skills/harness-engineering/LICENSE.txt

@@ -0,0 +1,22 @@
+MIT License
+
+Copyright (c) 2025 Context Engineering Agent Skills Contributors
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.
+

package/org-skills/harness-engineering/SKILL.md

@@ -0,0 +1,239 @@
+---
+name: harness-engineering
+description: "This skill should be used when designing autonomous agent harnesses: research loops, evaluation scaffolds, locked and editable surfaces, durable logs, novelty gates, pruning, rollback, PR preparation, and human approval boundaries."
+tags: ["ai-ml","engineering"]
+tools: []
+license: MIT
+source: https://github.com/muratcankoylan/Agent-Skills-for-Context-Engineering
+source_path: "skills/harness-engineering"
+source_commit: 6dbe1a1d868eab51a3bc9011b0f55e2891513e40
+---
+# Harness Engineering
+
+Harness engineering designs the control system around an agent: what it may edit, how it receives feedback, where it writes state, how failures recover, and who can approve irreversible actions. The harness is the difference between a helpful agent session and an autonomous loop that can run for days without corrupting its objective.
+
+## When to Activate
+
+Activate this skill when:
+
+- Building autonomous research or experimentation loops
+- Designing an agent environment with locked metrics and editable code or content
+- Creating PR-producing or background agents
+- Evaluating whether an agent can safely run without frequent human prompts
+- Adding novelty, ablation, pruning, rollback, or durable logging to an agent workflow
+- Preventing agents from gaming benchmarks, weakening rubrics, or losing state across compaction
+
+Do not activate this skill for adjacent work owned by other skills:
+- General quality gates, regression suites, or outcome metrics without autonomous control surfaces: `evaluation`.
+- Tool schemas, response formats, and recovery errors for harness tools: `tool-design`.
+- Project-level task-model fit, pipeline shape, and cost planning: `project-development`.
+- Remote sandbox, warm-pool, and hosted session infrastructure: `hosted-agents`.
+
+## Core Concepts
+
+### Harness Boundary
+
+Separate the agent from the environment it operates inside. The agent proposes actions; the harness defines allowed surfaces, feedback, persistence, and promotion rules.
+
+Use four surface classes:
+
+| Surface | Examples | Rule |
+| --- | --- | --- |
+| Locked | Eval metric, rubric, validation script, merge policy | Agent may read and propose changes, but cannot score itself with modified rules |
+| Editable | Skill draft, experiment file, prompt, config under test | Agent may mutate during the loop |
+| Append-only | Results log, research thread, rejected ideas | Agent may append, not rewrite |
+| Human-controlled | Merge, production deploy, credentials, destructive operations | Requires explicit human approval |
+
+### Tight Feedback Loops
+
+Autonomy works when feedback is fast, unambiguous, and hard to game. Karpathy's `autoresearch` is the minimal pattern: one editable file, one locked evaluation file, fixed wall-clock budget, one scalar metric, git rollback, and a durable results log. The lesson is not that every harness needs one metric; it is that ambiguous feedback creates ambiguous autonomy.
+
+For open-ended research-to-skill work, replace the scalar metric with locked rubrics, deterministic structure checks, source traceability, and human review thresholds.
+
+### Durable State
+
+Long-running agents must externalize state. Store plans, source queues, results, failures, and handoffs in files so future agents can resume without relying on chat history. Prime Intellect's autonomous nanoGPT work showed the value of durable scratchpads and `THREAD.md`-style logs for recovery, monitoring, and audit.
+
+Use append-only logs for:
+
+- What was tried
+- What improved or failed
+- Why a candidate was kept, discarded, or routed to review
+- Which upstream sources were checked
+- What the next agent should do
+
+### Search Discipline
+
+Agents tend to exploit the nearest surface, stack complexity, and under-run pruning. Add explicit search rules:
+
+1. Refresh upstream sources on a schedule.
+2. Require novelty checks before spending large budgets.
+3. Preserve rejected attempts to avoid rediscovery.
+4. Run leave-one-out pruning when a stack has multiple additions.
+5. Reward simplification when quality is equal.
+6. Use separate verification before promotion.
+
+### Mechanism Registry
+
+For research-to-skill systems, track accepted mechanisms separately from prose. A mechanism record should include a stable `mechanism_id`, `owning_skill`, `status`, activation scenario, behavior change, evidence, and failure modes. Novelty gates should compare against this registry before using broader corpus overlap, because keyword overlap catches stale phrasing while mechanism comparison catches real duplication.
+
+### Governance
+
+Autonomous agents may prepare PRs, but governance must be explicit. They can draft changes, run checks, and write PR summaries. They should not merge, deploy, or push without human approval unless the user has explicitly granted that permission for the specific action.
+
+## Detailed Topics
+
+### Autoresearch-Style Loop
+
+Use this pattern when optimizing an artifact against a stable evaluator:
+
+```text
+read locked context -> choose hypothesis -> edit allowed surface -> commit/checkpoint
+-> run evaluator -> log result -> keep if better -> discard or rollback if worse
+-> repeat
+```
+
+Required properties:
+
+- The evaluator is outside the editable surface.
+- The feedback cadence is fixed enough to compare attempts.
+- Failed attempts leave an audit trail.
+- Rollback is cheap.
+- The agent has a policy for crashes and timeouts.
+
+### Research-To-Skill Loop
+
+Use this pattern when sources become skill changes:
+
+```text
+discover -> retrieve -> gate -> score -> extract mechanism
+-> map to existing or new skill -> draft proposal -> validate structure
+-> prepare PR -> human review
+```
+
+The locked evaluator is a combination of source rubrics, skill-change rubrics, structure checks, and reviewer approval. The editable artifact is the proposed skill delta.
+
+### Metric Gaming Resistance
+
+Assume an optimizing agent will learn the harness. Guard against:
+
+- Editing evaluation code or rubrics and then using the new version for self-approval
+- Adding verbose content that pleases a judge but harms skill activation
+- Citing unretrieved sources
+- Optimizing aggregate scores while failing a critical dimension
+- Avoiding failed results in the log
+
+Mitigation: lock rubrics per run, report per-dimension scores, require source retrieval evidence, preserve rejected attempts, and route governance changes to human review.
+
+### Monitoring Agents
+
+Use monitoring agents for long runs, but restrict them to read-only reporting unless explicitly tasked otherwise. Monitoring output should report:
+
+- Best current candidate
+- Active jobs or drafts
+- Last upstream refresh
+- Failed or stale loops
+- Disagreements between logs and claimed state
+- Next action and blocker
+
+## Practical Guidance
+
+### Harness Design Checklist
+
+1. Define the objective in one sentence.
+2. Identify locked, editable, append-only, and human-controlled surfaces.
+3. Choose the feedback mechanism: scalar metric, rubric, deterministic tests, human review, or combination.
+4. Define keep, discard, crash, timeout, and review states.
+5. Create a durable thread log before the loop starts.
+6. Add source refresh, mechanism-registry novelty, and pruning rules for long-running loops.
+7. Define what the agent may do without asking and what requires approval.
+8. Validate the harness on one known good and one known bad artifact.
+
+### File Layout
+
+```text
+research-run/
+  THREAD.md
+  sources/
+    queue.md
+    evaluations/
+  proposals/
+  logs/
+    results.tsv
+    rejected.md
+  drafts/
+```
+
+Use TSV or JSONL for append-only machine-readable logs. Use Markdown for handoffs and reviewer-facing summaries.
+
+## Examples
+
+**Example 1: Locked metric**
+
+An agent optimizes `train.py`, but `prepare.py` owns data loading and evaluation. The agent can edit the model but cannot change the metric. Failed experiments are logged and rolled back.
+
+**Example 2: Locked rubric**
+
+An agent evaluates a new Anthropic or OpenAI engineering post, but the source curation rubric is locked for the run. If the source passes, the agent drafts a skill proposal. It cannot lower the rubric threshold to admit the source.
+
+**Example 3: Auto-PR without auto-merge**
+
+An agent prepares a branch and PR body after passing source, skill, and structure checks. The PR states unresolved risks and waits for human merge approval.
+
+## Guidelines
+
+1. Lock evaluators before starting the loop.
+2. Keep editable surfaces narrow enough for reliable diffs.
+3. Write durable logs before context compaction can erase state.
+4. Report per-dimension scores instead of only aggregate scores.
+5. Require source retrieval before citation.
+6. Add novelty gates for broad search and pruning gates for complex stacks.
+7. Prefer simplification when quality is equal.
+8. Separate PR preparation from merge authority.
+9. Revalidate harness changes with old and new evaluators.
+10. Treat stopped autonomous loops as harness failures, not agent personality quirks.
+
+## Gotchas
+
+1. **Mutable evaluator**: If the agent can edit the metric, it may optimize the benchmark instead of the task. Keep rubrics and eval code locked during the run.
+2. **Chat-only memory**: Long runs fail after compaction when plans live only in conversation history. Write thread logs and result files from the start.
+3. **No discard record**: Without rejected-attempt logs, agents repeat failed ideas. Preserve failures with enough detail to avoid rediscovery.
+4. **Complexity accretion**: Agents stack changes and rarely remove them. Require pruning rounds and reward equal-quality simplification.
+5. **Premature novelty claims**: Agents label recombinations as novel. Compare against existing repo skills, source queue, and rejected logs before claiming novelty.
+6. **Monitor misreporting**: Monitoring agents can summarize stale or inconsistent state. Require them to cite the files or logs behind claims.
+7. **Human approval ambiguity**: "Prepare a PR" is not "merge a PR." Make approval boundaries explicit in the harness.
+8. **Volatile source drift**: Fast-moving lab claims age quickly. Put dated evidence in references and schedule revalidation.
+
+## Integration
+
+This skill connects to:
+
+- evaluation - Rubrics and quality gates provide the locked feedback surface
+- advanced-evaluation - Pairwise comparison and bias mitigation improve proposal review
+- filesystem-context - Durable logs, scratchpads, and thread files preserve state
+- multi-agent-patterns - Researcher, verifier, monitor, and writer agents need isolated contexts
+- tool-design - Harness tools must expose clear contracts and recovery errors
+- project-development - File-based pipelines and task-model fit analysis keep loops simple
+- hosted-agents - Background execution needs sandbox, snapshot, and approval boundaries
+
+## References
+
+Internal references:
+- `researcher/README.md` - Read when implementing the repo-native research-to-skill operating system
+- `researcher/rubrics/harness-change.md` - Read when evaluating changes to an agent harness
+- `researcher/runbooks/autonomous-research-loop.md` - Read when running a source-to-skill loop
+
+External resources:
+- Karpathy `autoresearch` - Constrained autonomous experiment loop with locked evaluation
+- Prime Intellect autonomous nanoGPT speedrun - Durable scratchpads, handoffs, monitoring, and autonomy failure modes
+- AlphaEvolve and FunSearch - LLM-generated candidates paired with systematic evaluators
+- HELM and LM Evaluation Harness - Transparent, reproducible evaluation infrastructure
+
+---
+
+## Skill Metadata
+
+**Created**: 2026-05-14
+**Last Updated**: 2026-05-15
+**Author**: Agent Skills for Context Engineering Contributors
+**Version**: 1.1.0