본문으로 건너뛰기
cccskills
무료GitHub에 공개한국어 소개

HillClimb

측정 실험을 통해 LifeOS의 기술, 워크플로, 프롬프트, 평가 기준이나 코드 지표를 개선합니다. 별도로 보관한 사례로 변경 후보를 비교하고, 결과가 뒷받침하는 변경만 남겨 성공한 수정 사항을 지속 점검 항목으로 등록합니다.

원문원문 설명 보기

Improves anything in LifeOS (a skill, workflow, eval, ISA, prompt, rule or code metric) by experiment: finds its real misses in Errata, Assay and its ISA, draws changes from varied proposers, keeps only what held-out measurement supports until plateau, lands each catch as a standing check, then verifies complaints fell. With no target it climbs the steepest hill. USE WHEN hill climb, hillclimb, climb this, improve X, make X better, optimize, reduce latency, improve a metric, experiment, iterate, hypothesis, evolve ideas, ideate, experiment ideas, this keeps failing fix it for good, what hurts most, what should we improve, turn this miss into a check, did that fix work, before and after, iterate with me, multiple passes, revisit, rework. NOT FOR filing a complaint (Errata), writing or calibrating one eval suite (Assay), editing an ISA (ISA), skill scaffolding or description tuning (CreateSkill), mining outside content (Upgrade), one-pass brainstorming (BeCreative), diagnosis without an experiment (Science).

danielmiessler/LifeOS스타 19,636(GitHub 19,636 + cccskills 0)

실행 점수 미검증

설치 방법 보기

이럴 때 유용합니다

  • 같은 오류를 반복하는 기술 개선
  • 프롬프트 변경 효과 측정
  • 측정 가능한 지연 시간 개선
  • 실패 사례를 지속 점검으로 전환

한국어 소개

할 수 있는 일

HillClimb는 측정 실험을 통해 LifeOS의 기술, 워크플로, 평가 사례와 기준, ISA, 프롬프트, 규칙, 코드 지표를 개선합니다. Errata의 불만 기록이나 Assay의 평가 결과 등에서 실제 실패 사례를 모으고, 서로 다른 관점의 변경안을 비교합니다. 먼저 기준값을 기록한 뒤 학습에 사용하지 않은 사례로 후보를 측정하고, 결과가 뒷받침하는 변경만 유지합니다. 개선이 더 진행되지 않는 시점에 멈추며, 채택한 변경은 같은 실패를 찾아내는 지속 점검 항목으로 등록합니다. 대상을 지정하지 않으면 기존 기록에서 개선할 항목을 찾습니다.

이럴 때 유용합니다

기술이나 규칙이 같은 오류를 반복하거나, 프롬프트 변경이 실제로 효과가 있는지 확인하거나, 지연 시간처럼 측정 가능한 지표를 개선할 때 적합합니다. 발견한 실패를 앞으로의 점검 항목으로 바꾸는 데도 사용할 수 있습니다. 한 번의 아이디어 회의나 실험 없는 원인 분석보다 변경과 측정을 반복하는 작업에 맞습니다.

사용 예시

  • “이 기술이 같은 실수를 반복합니다. 실험을 거쳐 개선해 주세요.”
  • “이 규칙 위반을 다음에 찾아낼 점검 항목으로 만들어 주세요.”
  • “변경 전후 결과를 비교해 개선 여부를 확인해 주세요.”

주의 사항

LifeOS의 Errata, Assay 같은 측정 도구와 관련 기록을 사용합니다. 변경 내용에 따라 테스트 사례나 측정을 추가해야 할 수 있습니다. 시스템 프롬프트나 운영 규칙을 바꾸는 경우 변경 사항을 보여 주고 사용자의 승인을 기다리는 안전 절차가 있습니다.

이 소개문은 공개된 SKILL.md를 바탕으로 AI(OpenAI Codex)가 작성했습니다. 정확한 사양은 아래 원문을 확인하세요.

문서 점검

AI가 SKILL.md의 내용에서 주의가 필요한 작업과 도입 전제를 확인했습니다. 점수는 실제로 실행한 결과(실행 검증)만으로 매깁니다.

안전성전송·삭제·명령 실행 등을 명시하고 있는가
A양호시스템 프롬프트나 운영 규칙 변경은 차이를 보여 주고 승인을 기다립니다.
도입의 용이성필요한 도구나 API 키가 적고 적혀 있는가
B일부 부족LifeOS와 Errata, Assay 등의 도구가 필요하지만 설정 절차는 자료에 없습니다.

점수에는 넣지 않았습니다. 2026년 10월 28일 기준으로 AI(OpenAI Codex)가 판정했습니다. 참고용이므로 설치 전에 원문도 확인해 주세요.

평가가 다르다고 생각되면 재검토를 요청하기

어느 항목이 왜 다르다고 생각하는지 적어 주세요. 로그인은 필요 없습니다. SKILL.md와 대조해 평가를 다시 만들고 이곳에 반영합니다.

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

포함된 파일(26)

  • SKILL.md19.1 KB
  • Intents/Eval.md3.4 KB
  • Intents/Ideate.md16.7 KB
  • Intents/IsaClimb.md2.1 KB
  • Intents/Loop.md3.8 KB
  • Intents/Metric.md3.5 KB
  • Intents/Miss.md2.1 KB
  • Intents/Prompt.md3.5 KB
  • Intents/Skill.md3.8 KB
  • Intents/Survey.md1.9 KB
  • Intents/Verify.md2.0 KB
  • Intents/Workflow.md2.0 KB
  • References/CritiqueClimb.md829 B
  • References/Experiments.md8.9 KB
  • References/Instruments.md1.0 KB
  • Setup.md2.4 KB
  • Tools/fixtures/film-30s-r2-a-round-1.json1.7 KB
  • Tools/fixtures/film-30s-r2-a-round-2.json1.7 KB
  • Tools/fixtures/film-30s-r3-a-round-1.json1.7 KB
  • Tools/fixtures/film-30s-r3-a-round-2.json1.7 KB
  • Tools/fixtures/film-30s-r4-a-round-1.json1.7 KB
  • Tools/fixtures/film-30s-r4-a-round-2.json1.7 KB
  • Tools/fixtures/film-30s-r4-a-round-3.json1.7 KB
  • Tools/HillClimb.ts127.8 KB
  • Tools/Population.help.md7.8 KB
  • Tools/Population.ts43.8 KB

SKILL.md(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

HillClimb

Contents: Ideal State · Intent Routing · The loop (every workflow runs it) · Targets at a glance · Data & Config · Safety gates · Gotchas · Examples

The climber for the one loop LifeOS runs (LIFEOS/DOCUMENTATION/LifeOs/HillClimbing.md), and LifeOS's one place to improve something by experiment: collect ideas, vary and combine them, test them, and feed the results back as raw material for the next ideas. The instruments already exist: Errata is the pain signal, Assay the altimeter, its judgment layer and labels the fast sense, the ISA the hill, Upgrades the queue. HillClimb points them at one named thing and climbs it. The experiment discipline inside each climb comes from Anthropic's eval hill-climbing guide (Claude Code's bundled /claude-api hillclimb), enforced here in code against our own instruments.

Ideal State

  • Before anything changed, the target's ideal state was located (its ISA criteria, its standing checks, or the ask it serves), and a baseline was measured by an existing instrument and recorded in the climb ledger with how it was measured.
  • The misses behind the climb are real: Errata complaints, false passes, failing cases, broken-rule exemplars. None are invented.
  • A climb the principal asked for runs in one go from baseline through experiments to its stop: a stated target, a budget stated when the climb opened (start --budget <n experiments>, optionally --budget-reads <n candidate reads>), after which exp and screen refuse, or, with neither given, a plateau that plateau confirms. plateau counts experiments in a single-proposer climb and generations once the climb runs Ideate's population. While the reverts since the last keep span fewer than three kinds of change, plateau answers widen and the climb tries other kinds rather than stopping. It never halts after the baseline to ask for a budget; it stops early only at a safety gate, at a stop its intent names (IsaClimb's restate, Prompt's suite review, Eval's restart decision), or at an abort: continuing would cross an ethical line, the climb has failed with no path to recovery, or its resources are better spent elsewhere.
  • Across a climb, proposals come from varied minds: proposers that differ in background, vendor and reach (careful to dreamy), drawn in code, whose changes span the kinds the ledger records (knob, wording, rule, structure, delete, add, import). Each experiment row carries its kind, origin and parent, so the close can say which kinds and which proposers earned keeps. A recombination names the earlier experiments it draws on.
  • Each change rests on behaviours named on train cases, with how many cases show each, and its size is free: one word or a new stage. A kept change with several parts credits a part with the gain only after a variant without that part was measured; until then the gain is reported as unattributed.
  • No proposer's context ever held test, screen or holdout cases or their scores. Proposers read train case transcripts from the run file under MEMORY/STATE/Evals-Results/<suite>/<run>/ and the climb's history through digest <id> --train-only; the session that decides keeps sees scores only, and the target under test never sees the suite's expected outputs or rubric.
  • Only held-out measurement keeps a change, and the keep rule lives in code: the test score clears the noise floor, at a significance corrected for every candidate read on test since the last keep, the instrument and served model are unchanged, and standing checks did not drop. A tie inside the noise is kept only when it removes material (--simpler). A judge's opinion of a proposal decides at most which proposals get measured, never which are kept. Every experiment, kept or reverted, is in the ledger, and a revert that gained on train stays in the climb's archive as material for recombination.
  • When many candidates compete, a screen split cuts them down so test reads stay few; the ledger counts every test read, and a declared holdout is scored once, at close, beside the test delta.
  • When plateau asks for it (two reverts in a row, or in population mode the run of generations without a keep that plateau counts), a stall categorization (artifact, grader, harness, structural, variance) is recorded before any further content change, and each category goes to the system that fixes it.
  • Every kept win is landed as a standing check (a suite case, a judgment-layer question, a bunker miss, a sharper criterion, a fixed tool or a Gotcha) so the same miss cannot recur. What a climb learned is never landed as a longer prompt.
  • A climb closes with baseline, best and delta plus the diff that produced them, the holdout delta when one was declared, the test-read count and the keep rate by kind and origin. close --stop records why it stopped (plateau, target, budget, abort, or reviewed for a Loop) and refuses a close with no reason or one the ledger contradicts: plateau needs plateau to answer plateaued, budget a spent budget, target a keep, abort a --reason, reviewed a climb with no exp rows and a --reason carrying the measured delta. It lists every baseline a baseline --force --reason replaced, with that reason; it files an Upgrades record naming the climb, and is marked verified only when Errata shows its complaint rate fell.
  • With no target, the survey ranks real hills from Errata, Assay and Upgrades and reports any unreadable source as unavailable, never as zero pain.
  • A Loop run puts the principal's review between full Algorithm passes in place of the code keep rule, opens and closes in the same climb ledger, and still ends on a measured delta against baseline.

The Bunker CLI is maintainer-private and not in the public release; run code rows with bun test ./<path> and suite rows with bun skills/Assay/Tools/EvalRunner.ts.

Intent Routing

IntentTargetTriggerFile
Surveynothing given"hill climb", "what hurts most", "what should we improve"Intents/Survey.md
Skilla skill"hill climb the X skill", "make X better", "X keeps getting it wrong"Intents/Skill.md
Workflowa Workflows v2 definition or a skill intent"improve the X workflow", "this workflow keeps failing"Intents/Workflow.md
Evala suite, judge, judgment-layer question or standing check"improve the eval", "this judge is wrong", "fix the failing suite", "retire dead checks"Intents/Eval.md
IsaClimban ISA"hill climb this ISA", "sharpen the criteria", "the ISA is drifting"Intents/IsaClimb.md
Prompta prompt, agent file, system-prompt section or doctrine rule"optimize this prompt", "improve the agent", "this rule keeps getting broken"Intents/Prompt.md
Metriccode with a measurable number"reduce latency", "shrink the bundle", "optimize this metric"Intents/Metric.md
Missone caught miss"turn this miss into a check", "never let this happen again"Intents/Miss.md
Verifya closed climb or an applied upgrade"did that fix work", "before and after", "verify the climbs"Intents/Verify.md
Loopany target the principal wants to review between passes"iterate on this with me", "multiple passes", "revisit", "rework"Intents/Loop.md
Ideatethe candidate changes for any climb's experiments"ideate", "id8", "breakthrough ideas", "explore", "get creative on this climb", "evolve experiments", "evolve ideas", "experiment ideas", "generate hypotheses", "design an experiment", "iterate on an experiment"Intents/Ideate.md

References

FileRead when
References/Instruments.mdChoosing which system supplies a climb's hill, top, altimeter, judge check, experiment rules or record
References/CritiqueClimb.mdThe climb is measured by ArtDirection critique readings (a film or image)
References/Experiments.mdFraming hypotheses, designing a measurement, or reading results
Setup.mdFirst-time setup: the optional USER PREFERENCES.md and History.md, and proving the install

The loop (every workflow runs it)

These are the loop's verbs, and order matters only where evidence depends on it: a baseline before any experiment, a whole generation persisted before any of it is screened or measured, and every win landed before close. The intent's own tool contract has the full flags.

open        HillClimb.ts start [--budget <n>] [--budget-reads <n>]   # type, target, metric, direction, budget
locate      the target's ISA, IsaLadder.ts
baseline    HillClimb.ts baseline --from-run [--screen-frac <f>] [--holdout-frac <f>]   # raw per-case rows, seeded train/screen/test split, noise floor; other instruments per Targets at a glance
preflight   HillClimb.ts preflight                   # noise floor below the headroom and the smallest win worth having, else add cases or trials first
misses      Errata.ts, Proof.ts, suite transcripts, FailureToCase.ts
ideate      Intents/Ideate.md, HillClimb.ts digest, HillClimb.ts archive   # candidate changes from varied proposers, fed as the Ideal State says
experiment  HillClimb.ts exp --from-run --kind <k> --origin <id> [--parent <n>] [--generation <g>] [--simpler --before <f> --after <f>] --keep|--revert
stall       HillClimb.ts stall                       # when plateau asks for it
stop        HillClimb.ts plateau                     # plateaued, widen or climbing; a spent budget, a reached target or an abort also stops, named at close
land        bunker miss, Assay suites, judgment questions, the target's Gotchas
close       HillClimb.ts close --stop plateau|target|budget|abort|reviewed [--reason "<text>"] [--holdout-run <run.json>]   # before/after report, stop reason, replaced baselines, holdout delta, the Upgrades record

HillClimb.ts status <id> shows the keep rate by kind and by origin, the test-read count and what is left of the budget at any point.

Targets at a glance

TypeIdeal state lives inAltimeterWhat changes
skillits ISA or done-bar, its standing checksErrata rate, receipts, its suite's pass^kSKILL.md, intents, tools (through CreateSkill)
workflowthe definition's output schema, its run ledgerrun success rate, output checksthe definition or workflow file
evalthe ISA criterion it measures, principal labelsagreement and kappa, adversarial catch, residuesuite cases, anchors, judgment-layer questions
isathe ladder and the principal's stated goalIsaLadder.ts drift, Rate, manual-row countthe ISA's criteria and Test Strategy
prompt / rulethe doctrine's intentsuite pass^k, recall on the rule's past failuresthe prompt, or a check that enforces the rule
metrica stated target numberthe measure commandthe target files
missthe brief the output missedProof on the same artifacta standing check

Data & Config

  • Climb ledger: $HILLCLIMB_DIR, else <configRoot>/LIFEOS/MEMORY/STATE/HillClimb/<climb-id>/ (climb.json, experiments.jsonl, reads.jsonl, archive/, and ideate/ for Ideate's draws and generations). This is HillClimb's only store. Complaints, receipts, labels, suites and upgrades stay in their own systems.
  • Tools: Tools/HillClimb.ts (usage in its header and help) and Tools/Population.ts, the code-drawn proposer roster, pairs, tail picks, measurement allotment and generation record behind Ideate (flags in Tools/Population.help.md). Survey sources: LIFEOS/ERRATA/Errata.ts, the latest LIFEOS/USER/ERRATA/v4/report-*.md, skills/Assay/Tools/SuiteManager.ts, LIFEOS/TOOLS/Upgrades.ts.
  • Install history: <configRoot>/LIFEOS/USER/CUSTOMIZATIONS/SKILLS/HillClimb/History.md, when present, holds the full stories behind the dated gotchas below (which climb, which repos, which scores). Read it when a climb looks like one of them; the skill runs the same without it. A PREFERENCES.md beside it, when present, holds the install's preferences that switch on optional behaviour in Intents/Ideate.md (for example, the DA ideates first) with the principal's own words behind them; read it before running Ideate.

Safety gates

  • Doctrine hold. A change to the system prompt, the Algorithm, CLAUDE.md, the operational-rules file or the identity files is shown to the principal as a diff and held for a yes, even inside a requested climb. A self-initiated or scheduled climb or loop recommends and never changes the system on its own. A climb the principal asked for may edit its named target, and touches hooks, skills or doctrine outside that target only as a held diff. A Loop holds more: when its named --target is itself a hook, a skill or one of those doctrine files, each pass's change to it is shown as a diff and held for a yes (Intents/Loop.md). Long-running work started without the principal's ask needs their yes before it launches. Every intent defers to this gate.
  • Shared tree. Revert an experiment by restoring only the paths it touched, after git diff shows only your hunks. Never git stash and never git checkout .. Commit each kept change with explicit paths, in the same command that stages it.

Gotchas

  • The survey is a ranking, not a measurement. Its weights put a false pass first because a false pass names a check that is missing or wrong. A hill's score says where to look, and the climb's own baseline says how bad it is.
  • Output lines started 2026-09-30, so per-skill complaint rates read zero before that date. Until complaints join to outputs, the skill hills come mostly from suites and the Errata v4 broken-rule table, and verify returns insufficient-data on older climbs.
  • A train set unlike the keep split hides the hill. Train-blind proposers can only climb what train shows. In a 2026-10-12 climb, train was mostly the cases the rules were fitted to (high on one class) while the keep split's fresh cases sat far lower on it, so every proposal barely moved train and moved the keep split by small amounts with no way to tell which was real. Compare the incumbent's per-decision train and keep-split baselines before ideation, and grow train toward the keep split when they disagree (Intents/Ideate.md § Ideal State).
  • A scripted climb needs a reader before any big keep. A Workflow whose recorder only runs commands will revert every large win, because exp --keep refuses one without --spot-checked (the full refusal list is below): a 2026-10-11 climb lost several real gains that way and reported a false plateau. Put a spot-check agent (train-half flips only, toward or away from gold, for real reasons) between the keep decision and the recorder.
  • A scorer that prints the test score spends the test half. In a 2026-10-11 climb, proposers were handed such a scorer and many sweeps picked weights against test. Give proposers a scorer that prints the train half alone, keep the test and validation scorer in the orchestrator's own lane, and audit the run directories for test runs inside proposer windows.
  • What exp --keep refuses. A gain inside the noise floor, Bonferroni-corrected for the candidates read on test since the last keep (unless --simpler and the change removes material), a proposal --generation names that its persisted generation does not hold, a screened-out candidate, a --generation origin that is off that generation's roster or is not the measured proposal's own, a changed instrument (suite, judge prompt, grader), a different served model (a model named on only one side counts as different), a drop in standing checks or a keep with no --checks once a count stands, and a jump over three times the noise without --spot-checked. A run read on a --field other than the one the baseline scored is refused before it is measured. Once the budget is spent, exp refuses any row and screen any read (budget spent: …), except that a screened-out candidate, which reads nothing, still records while only reads are spent. A refused keep is recorded with --revert. Arguing past the tool is the failure it exists for.
  • Most of our suites are small. Under ten cases, the split is directional: every case is scored, there is no held-out set, and the noise floor is wide. Preflight will usually say the suite cannot see a modest win. The fix is more cases from real misses (FailureToCase.ts) or more trials, before round 1.
  • No lane exposes a temperature (checked 2026-10-11: rg temperature finds nothing in LIFEOS/TOOLS/Inference.ts or BeCreative). How dreamy a proposer is comes from its persona, how far a change it is invited to make, far-domain inputs and Verbalized Sampling's tail.
  • A film or image climb keeps on paired critique readings, never on one median. Its baseline and exp flags and what the keep refuses are in References/CritiqueClimb.md; read it before that baseline.
  • Compare.ts is the stricter keep test for judged suites. When its paired CI excludes zero, record it as --noise <half-width> --noise-source "Compare paired CI" at baseline, so the code gate uses it.

Examples

User: "hill climb"
→ Survey: ranks hills from Errata, Assay, Upgrades and the climb ledger, then climbs the top one the principal picks

User: "the research skill keeps citing secondary sources, hill climb it"
→ Skill: baseline from its suite and complaints, cases from the real misses, candidate changes from Ideate, experiments until plateau, a standing check

User: "the classifier judge is stuck nudging weights, get creative on this climb"
→ Ideate: proposers of differing reach and vendor propose structural, deletion and import changes from train misses; the climb measures them

User: "the verification rule keeps getting broken"
→ Prompt (rule): measures a check's recall on the rule's past failures, proposes the enforcing check, verifies the break count fell

User: "did the Art climb work?"
→ Verify: before and after complaint rate from Errata, marks the upgrade verified only if it fell

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

AnnualReports

무료요약 있음

여러 업체와 공공기관의 사이버 보안 보고서를 검색하고 가져와 위협, 랜섬웨어, 침해 통계 등의 추세를 비교합니다. 분석에는 출처별 업체, 연도, 보고서를 표시하고 자료 간 차이도 따로 다룹니다.

  • 분류별 위협 보고서를 찾을 때
  • 특정 업체의 보고서를 가져올 때
  • 여러 업체의 랜섬웨어 동향을 비교할 때
danielmiessler/LifeOS2만2026년 10월 28일 업데이트

ApertureOscillation

무료요약 있음

기능이나 구성 요소 자체의 설계 요구와 시스템 전체의 목표를 세 단계로 비교합니다. 설계상의 충돌과 적절한 구현 범위를 정리하고, 제안한 설계가 전체 방향과 맞는지 평가합니다.

  • 서비스나 라이브러리를 분리할지 판단하기
  • 기능 요구와 제품 방향 비교하기
  • 새 구성 요소와 기존 시스템의 정합성 확인하기
danielmiessler/LifeOS2만2026년 10월 28일 업데이트

Aphorisms

무료요약 있음

글의 주제에 맞는 격언과 인용문을 찾아 저자와 선정 이유를 함께 제안합니다. 출처가 있는 인용문을 추가하고, 사상가의 말을 주제별로 조사하며, 사용 기록을 관리해 같은 인용문을 반복하지 않도록 돕습니다.

  • 뉴스레터에 어울리는 인용문 찾기
  • 출처와 함께 중복 없이 인용문 저장하기
  • 주제별로 사상가의 말 조사하기
danielmiessler/LifeOS2만2026년 10월 28일 업데이트

Art

무료요약 있음

블로그 삽화, 기술 도표, 비교 그림, 만화, 아이콘 등을 용도에 맞는 절차로 제작합니다. 구도와 색상, 이미지 모델을 정하고 검토용 이미지를 출력합니다.

  • 블로그 제목 이미지를 만들 때
  • 시스템 구조를 그림으로 설명할 때
  • 비교나 연대표를 시각화할 때
danielmiessler/LifeOS2만2026년 10월 28일 업데이트

ArtDirection

무료요약 있음

브리프와 제작 기준에 따라 이미지, 영상, 슬라이드, 사이트 화면 캡처의 시각 품질을 평가합니다. 두 비전 심사자가 점수와 결함 우선순위를 제시하고, 정해진 횟수 안에서 수정을 돕습니다. 평가를 통과한 결과물만 전달할 수 있으며, 사람의 점수와 의견은 별도 기록해 심사 보정에 활용합니다.

  • 이미지 수정 항목의 우선순위 정리
  • 기준에 따라 영상이나 슬라이드 평가
  • 공개 전 시각 품질 점검
danielmiessler/LifeOS2만2026년 10월 28일 업데이트

ArXiv

무료요약 있음

주제, 연구 분야, 논문 ID로 arXiv 논문을 찾고 제목, 저자, 초록, 링크를 정리합니다. 새 논문을 확인하고, 제공되는 경우 AlphaXiv의 AI 생성 개요도 가져옵니다.

  • AI·머신러닝 분야의 새 논문 확인
  • 특정 주제의 논문 검색
  • 논문 ID나 arXiv 주소로 조회
danielmiessler/LifeOS2만2026년 10월 28일 업데이트

danielmiessler의 스킬 모두 보기

이 스킬의 문제 신고