スキル一覧に戻る
DataDog

lading-optimize-rescue

by DataDog

lading-optimize-rescueは、other分野における実用的なスキルです。複雑な課題への対応力を強化し、業務効率と成果の質を改善します。

92🍴 13📅 2026年1月22日
GitHubで見るManusで実行

SKILL.md


name: lading-optimize-rescue description: Salvages optimization work lacking benchmarks. Generates missing evidence, validates claims. Bugs discovered during rescue are valuable - invoke /lading-optimize-validate.

Optimization Rescue

Salvage optimization work done without proper benchmarks. Generate evidence, validate claims, and discover bugs hiding in "optimizations."

Valuable Outcomes

OutcomeValueAction
Change validatedReal improvement provenKEEP, include in rescued branch
Change invalidatedNo improvementDISCARD, record lesson
Bug discoveredCorrectness issue foundInvoke /lading-optimize-validate

Bugs found during rescue are SUCCESS, not failure.


Phase 0: Pre-flight

Run /lading-preflight first.


Phase 1: Audit

git diff --name-only origin/main...HEAD | grep '\.rs$'

For each change, categorize:

  • Preallocation (Vec::with_capacity, String::with_capacity)
  • Avoiding clones (borrowing instead of owned)
  • Moving allocations out of loops
  • Data structure changes
  • Potential bug (suspicious patterns)

Phase 2: Triage

Hot Path?Decision
Yes (profiled, top 10%)INVESTIGATE
Warm (suspected hot, 10-25%)SKEPTICAL
Cold (no profile evidence)LIKELY DISCARD
Looks buggyINVESTIGATE for correctness

Bug Warning Signs in Rust

PatternRisk
.unwrap() or .expect() addedPanic path (lading MUST NOT panic)
unsafe block addedMemory safety risk
Changed return typeSemantic change
Removed bounds checksCorrectness risk
Clone removed without lifetime analysisUse-after-move risk
mem::transmute or mem::forgetUndefined behavior risk

Phase 3: Generate Evidence

CRITICAL: Use Separate Worktree for Baseline

NEVER use git stash/git checkout to switch between baseline and optimized. This causes confusion and errors. Instead, use a separate git worktree:

# One-time setup: create a baseline worktree (do this once per repo)
git worktree add ../lading-baseline main

# The baseline worktree is at ../lading-baseline
# Your optimization work stays in the current directory

For payloadtool (end-to-end):

# Choose a config file (e.g., ci/fingerprints/json/lading.yaml)
CONFIG=ci/fingerprints/json/lading.yaml

# In baseline worktree
cd ../lading-baseline
cargo build --release --bin payloadtool
hyperfine --warmup 3 --runs 30 --export-json /tmp/baseline.json \
  "./target/release/payloadtool $CONFIG"
./target/release/payloadtool "$CONFIG" --memory-stats 2>&1 | tee /tmp/baseline-mem.txt

# In optimization worktree
cd /path/to/your/optimization/branch
cargo build --release --bin payloadtool
hyperfine --warmup 3 --runs 30 --export-json /tmp/optimized.json \
  "./target/release/payloadtool $CONFIG"
./target/release/payloadtool "$CONFIG" --memory-stats 2>&1 | tee /tmp/optimized-mem.txt

For inner loops (criterion):

Use cargo criterion for micro-benchmarks. Run in each worktree and compare output:

# In baseline worktree
cd ../lading-baseline
cargo criterion 2>&1 | tee /tmp/criterion-baseline.log

# In optimization worktree
cd /path/to/your/optimization/branch
cargo criterion 2>&1 | tee /tmp/criterion-optimized.log

# Compare results manually - look for "change:" lines showing improvement/regression

Note: Criterion automatically compares against the last run in that worktree and reports percentage changes.

Create Benchmarks If Missing

If no benchmark exists for the changed code, create one:

// In lading_payload/benches/<name>.rs
use criterion::{criterion_group, criterion_main, Criterion, Throughput};

fn benchmark_function(c: &mut Criterion) {
    let mut group = c.benchmark_group("function_name");
    group.throughput(Throughput::Bytes(1024));

    group.bench_function("baseline", |b| {
        b.iter(|| {
            function_under_test()
        })
    });

    group.finish();
}

criterion_group!(benches, benchmark_function);
criterion_main!(benches);

Phase 4: Validate

Decision Matrix

ResultDecision
Time improved >=5%KEEP
Memory reduced >=10%KEEP
Allocations reduced >=20%KEEP
No significant changeDISCARD
RegressionDISCARD
ci/validate failsPossible BUG -> /lading-optimize-validate
Determinism brokenPossible BUG -> /lading-optimize-validate
Panic path addedBUG -> /lading-optimize-validate

Verify Determinism

Determinism is verified via fingerprints. The same config (with fixed seed) must produce identical output:

CONFIG=ci/fingerprints/json/lading.yaml
./target/release/payloadtool "$CONFIG" --fingerprint > /tmp/run1.txt
./target/release/payloadtool "$CONFIG" --fingerprint > /tmp/run2.txt
diff /tmp/run1.txt /tmp/run2.txt  # Must be identical

Note: Seed is specified in the config file, not as a CLI flag.


Phase 5: Handle Bug Discovery

If rescue uncovers a bug instead of an optimization:

/lading-optimize-validate

After validation:

  1. Bug recorded in validate's assets/db.yaml (via /lading-optimize-validate)
  2. Record rescue as BUG_FOUND in Phase 7
  3. The bug fix becomes part of rescued branch (with tests!)

Phase 6: Reconstruct

git checkout main
git checkout -b opt/<name>-rescued

Apply only:

  • KEEP changes (validated optimizations with benchmark proof)
  • BUG_FOUND changes (with tests from /lading-optimize-validate)

Discard everything else.

Mandatory Before Finishing

ci/validate

No exceptions. Rescued branch must pass ci/validate.


Phase 7: Record

MANDATORY: Update db.yaml

  1. Add entry to assets/db.yaml index
  2. Create detailed file in assets/db/ directory

assets/db.yaml entry:

entries:
  - original_branch: <opt/original-branch>
    rescued_as: <opt/original-branch-rescued>
    status: <rescued|partial|bug_found>
    file: assets/db/<branch-name>.yaml

assets/db/.yaml:

original_branch: <opt/original-branch>
rescued_as: <opt/original-branch-rescued>
date: <YYYY-MM-DD>
statistics:
  audited: <N>
  kept: <N>
  discarded: <N>
  bugs_found: <N>
kept_changes:
  - file: <file>
    technique: <technique>
    time: <delta>
    memory: <delta>
discarded_changes:
  - file: <file>
    reason: <reason>
bugs_found:
  - file: <file>
    validation_file: <path to validate db entry>
lessons: |
  <pattern learned>

Usage

/lading-optimize-rescue

スコア

総合スコア

65/100

リポジトリの品質指標に基づく評価

SKILL.md

SKILL.mdファイルが含まれている

+20
LICENSE

ライセンスが設定されている

+10
説明文

100文字以上の説明がある

0/10
人気

GitHub Stars 100以上

0/15
最近の活動

3ヶ月以内に更新がある

0/10
フォーク

10回以上フォークされている

+5
Issue管理

オープンIssueが50未満

+5
言語

プログラミング言語が設定されている

+5
タグ

1つ以上のタグが設定されている

0/5

レビュー

💬

レビュー機能は近日公開予定です