[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6BXJ86EP64TND1NAHC9MHSS":3,"skill-same:01M6BXJ86EP64TND1NAHC9MHSS":52},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":25,"linkOnly":26,"markdownContent":27,"markdownBody":28,"frontMatter":29,"refName":30,"commitSha":31,"skillDirectory":32,"forksCount":33,"repositoryHtmlUrl":34,"repositoryHomepageUrl":6,"ownerHtmlUrl":35,"ownerBlogUrl":36,"ownerDescription":6,"updatedAt":37,"install":38,"resources":51},"01M6BXJ86EP64TND1NAHC9MHSS","checkpoint-placement",null,"Select a core-proven metadata checkpoint for same-dataset parameter feedback. Use after recipe validation and semantic critique, before authoritative smoke, when the user expects to tune a declared downstream decision after seeing results.","NVIDIA-NeMo\u002FCurator","NVIDIA-NeMo","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F213689629?v=4","01M6BXH6HS4CXMTZ8GCBQTKPAP","01M6BXH6PD7DSNJ54NXBQ577TR",1857,"Apache-2.0","https:\u002F\u002Fgithub.com\u002FNVIDIA-NeMo\u002FCurator\u002Fblob\u002Fmain\u002Fnemo_curator\u002Fstages\u002Faudio\u002Faudio_agent\u002Fskills\u002Fcheckpoint-placement\u002FSKILL.md",[],[18,19,20,21,22,23,24],"checkpoint","checkpoint placement","core","validation","metadata","critique","feedback","2026-11-10 10:12:30",false,"---\nname: checkpoint-placement\ndescription: Select a core-proven metadata checkpoint for same-dataset parameter feedback. Use after recipe validation and semantic critique, before authoritative smoke, when the user expects to tune a declared downstream decision after seeing results.\n---\n\n# Checkpoint placement\n\nUse this skill only for an unchanged dataset and an iterative scalar or atomic compound\ndecision that a capability card declares separable from its annotation producer.\n\nReplacing a stage, metric, acceptance criterion, or checkpoint topology is a\nmid-workflow recipe branch, not threshold feedback, delta work, or continuation.\nReturn to the audio-curation skill's full branch-reset sequence. A scalar or\ncompound condition change also invalidates prior recipe validation, critique,\nsmoke, and approval, even when this skill can reuse its producer.\n\n## Procedure\n\n1. Start from the exact validated recipe. Do not edit stage modes, score keys, selectors,\n   residency, thresholds, or paths yourself.\n2. Call `plan-checkpoint` with `--data` and without `--output-path` to inspect core-proven\n   options. The core derives the checkpoint location itself; a path is never yours to invent.\n3. Offer at most one non-dominated option, and only when:\n   - the user explicitly or strongly implies they will inspect output and tune a decision;\n   - the result has `status: needs_decision`, `needs_output_path`, or `ready`;\n   - meaningful expensive\u002Fmodel work is listed above the decision; and\n   - no existing checkpoint already covers it.\n4. Show the candidate's concise benefit, cost, checkpoint effect, and baseline trade-off\n   through the host's structured AskQuestion UI. The earlier soft curation-mode choice is\n   not this recipe-specific accept\u002Fdecline decision. Never call `plan-checkpoint --choice\n   baseline`, `--choice checkpoint`, `--output-path`, or an equivalent MCP choice on the\n   user's behalf; wait for and use only the selected response.\n5. If the user declines, only then call `plan-checkpoint --choice baseline` and use only\n   its returned baseline recipe. The core binds that explicit choice to the exact recipe\n   and option set. Do not offer again in this workflow.\n6. If they accept, call `plan-checkpoint --choice checkpoint` and use only the returned\n   complete recipe. Do NOT ask the user for a path: a checkpoint is recomputable cache,\n   addressed by the step key it belongs to, and asking makes them name a file they have no\n   reason to care about. Pass `--output-path` only when the user has asked, unprompted, to\n   keep the metadata somewhere of their own. On `status: needs_output_path` the core could\n   not derive a location -- confirm `--data` was supplied and names a readable source\n   before falling back to asking.\n7. Re-run validation and the full host semantic critique. Any transformed recipe has a new\n   `config_hash`.\n8. Run `reuse-scan`, then authoritative smoke on that exact final recipe. Smoke\n   isolates its writes in temporary storage; never create or pre-clean the real\n   checkpoint path.\n9. At the approval gate disclose:\n   - checkpoint path and overwrite\u002Fcollision behavior;\n   - rows and bytes measured by smoke, projected full size and confidence;\n   - measured prefix work the checkpoint can save;\n   - cumulative trust\u002FTTL and any non-deterministic prefix;\n   - retention seconds and who owns deletion.\n   Immediately before asking, inspect deterministic `output_targets`, the checkpoint\n   writer's resolved output-path contract, the continuation\u002Freuse card when applicable,\n   and safe read-only current path facts. If the checkpoint or another execution target\n   is occupied and proven to be replaced\u002Foverwritten, name its exact path and remind the\n   user to copy or save work they need first. Never copy, delete, rename, clean, truncate,\n   or pre-create it. Do not warn for new targets, infer overwrite from an append contract\n   (or append from a replace contract), or guess when behavior is unproven—say so and ask.\n10. Present those facts and ask for post-smoke execution approval, then end the response.\n    Run only after a subsequent user answer, exact-hash approval, and a smoke token\n    for this candidate, plus the reminder when applicable. A hash\u002Ftoken proves artifact\n    identity, not AskQuestion provenance or consent.\n11. After a successful run, include the checkpoint under **Intermediate\u002Fcheckpoint\n    files** in the final **Saved files** block, separate from terminal deliverables and\n    existing reused\u002Fserved artifacts. Claim it was saved only from returned\n    `output_paths`\u002F`output_targets`, published lineage\u002Fartifacts, the report, deterministic\n    stage-path discovery plus a safe read-only existence check, or run-record recipe\n    metadata. Never list the smoke-isolated checkpoint or a planned-but-unexecuted path as\n    durable; if the core did not report a requested path, say so rather than guessing.\n\nAuthoritative smoke and full run refuse a recipe with a recommended expensive checkpoint\nuntil it contains either the checkpoint or the exact baseline-decline attestation returned\nby `plan-checkpoint`. Never bypass that refusal by rebuilding or hand-editing the recipe.\n\n## Pipeline policy\n\n- Keep paths plus offsets when audio can be recreated from source.\n- Carry a waveform only across adjacent consumers that need it.\n- Never write intermediate audio merely to make a checkpoint.\n- Persist complete serializable row metadata before the first declared destructive decision.\n- Explicit UTMOS\u002FSIGMOS segment decisions are eligible only when the card and core bind the\n  generic selector `items_key` to the producer's exact `segments_key`, preserve every enabled\n  threshold with explicit `condition_logic='and'`, drop missing scores and empty parents, and\n  carry no waveform. Generic OR is valid for non-reuse pipelines but is not exact native-filter\n  separation. Path plus offset metadata is serializable and may be checkpointed.\n- Keep native filters when scope is `auto`, nesting is recursive, a segment list carries a\n  waveform, or decisions are private-metadata-dependent, batch\u002Fcorpus-dependent, or not\n  card-declared as separable.\n- Never place more than one new checkpoint.\n\n## Feedback after a completed run\n\nCall `plan-checkpoint --from-run RUN_ID --data DATA --decision-stage PRODUCER\n--decision-value VALUE`. The core adopts the exact recipe and changes only the declared\nscalar selector. For a card-declared compound decision, use\n`--decision-conditions '\u003CJSON>'` instead. It is a complete replacement, not a patch:\nname each enabled configured score key once, use finite numeric targets and `ge`, and\nomit a dimension to disable it. The core keeps AND logic, missing-score drop behavior,\nand nested `items_key`\u002Fempty-parent policy fixed, and refuses enabling a score not proven\npresent in the retained annotation checkpoint.\n\nThat returned selector change is a new recipe hash: retain still-valid same-chat\ncontext\u002Fprofile\u002Fpreference, but follow the branch reset from validate -> host critique ->\ncheckpoint decision (if any) -> reuse scan -> authoritative smoke -> presentation ->\nsubsequent approval before executing. If the dataset key changed, stop this flow and follow\nthe returned `delta_run` route. For unchanged data, use `reuse-scan` and `continue` only\nafter those recipe-level gates; do not execute a hand-edited suffix. Validation may inspect\nan occupied checkpoint only when its exact dataset\u002Fprefix artifact and content digest prove\nit complete; direct full execution still refuses to recreate or overwrite that path.\n\nTightening may be possible from a retained final subset, but loosening needs rows a prior\nfilter discarded. Do not claim final-manifest reuse unless the core proves it; the dedicated\npre-gate checkpoint is the supported evidence.\n","# Checkpoint placement\n\nUse this skill only for an unchanged dataset and an iterative scalar or atomic compound\ndecision that a capability card declares separable from its annotation producer.\n\nReplacing a stage, metric, acceptance criterion, or checkpoint topology is a\nmid-workflow recipe branch, not threshold feedback, delta work, or continuation.\nReturn to the audio-curation skill's full branch-reset sequence. A scalar or\ncompound condition change also invalidates prior recipe validation, critique,\nsmoke, and approval, even when this skill can reuse its producer.\n\n## Procedure\n\n1. Start from the exact validated recipe. Do not edit stage modes, score keys, selectors,\n   residency, thresholds, or paths yourself.\n2. Call `plan-checkpoint` with `--data` and without `--output-path` to inspect core-proven\n   options. The core derives the checkpoint location itself; a path is never yours to invent.\n3. Offer at most one non-dominated option, and only when:\n   - the user explicitly or strongly implies they will inspect output and tune a decision;\n   - the result has `status: needs_decision`, `needs_output_path`, or `ready`;\n   - meaningful expensive\u002Fmodel work is listed above the decision; and\n   - no existing checkpoint already covers it.\n4. Show the candidate's concise benefit, cost, checkpoint effect, and baseline trade-off\n   through the host's structured AskQuestion UI. The earlier soft curation-mode choice is\n   not this recipe-specific accept\u002Fdecline decision. Never call `plan-checkpoint --choice\n   baseline`, `--choice checkpoint`, `--output-path`, or an equivalent MCP choice on the\n   user's behalf; wait for and use only the selected response.\n5. If the user declines, only then call `plan-checkpoint --choice baseline` and use only\n   its returned baseline recipe. The core binds that explicit choice to the exact recipe\n   and option set. Do not offer again in this workflow.\n6. If they accept, call `plan-checkpoint --choice checkpoint` and use only the returned\n   complete recipe. Do NOT ask the user for a path: a checkpoint is recomputable cache,\n   addressed by the step key it belongs to, and asking makes them name a file they have no\n   reason to care about. Pass `--output-path` only when the user has asked, unprompted, to\n   keep the metadata somewhere of their own. On `status: needs_output_path` the core could\n   not derive a location -- confirm `--data` was supplied and names a readable source\n   before falling back to asking.\n7. Re-run validation and the full host semantic critique. Any transformed recipe has a new\n   `config_hash`.\n8. Run `reuse-scan`, then authoritative smoke on that exact final recipe. Smoke\n   isolates its writes in temporary storage; never create or pre-clean the real\n   checkpoint path.\n9. At the approval gate disclose:\n   - checkpoint path and overwrite\u002Fcollision behavior;\n   - rows and bytes measured by smoke, projected full size and confidence;\n   - measured prefix work the checkpoint can save;\n   - cumulative trust\u002FTTL and any non-deterministic prefix;\n   - retention seconds and who owns deletion.\n   Immediately before asking, inspect deterministic `output_targets`, the checkpoint\n   writer's resolved output-path contract, the continuation\u002Freuse card when applicable,\n   and safe read-only current path facts. If the checkpoint or another execution target\n   is occupied and proven to be replaced\u002Foverwritten, name its exact path and remind the\n   user to copy or save work they need first. Never copy, delete, rename, clean, truncate,\n   or pre-create it. Do not warn for new targets, infer overwrite from an append contract\n   (or append from a replace contract), or guess when behavior is unproven—say so and ask.\n10. Present those facts and ask for post-smoke execution approval, then end the response.\n    Run only after a subsequent user answer, exact-hash approval, and a smoke token\n    for this candidate, plus the reminder when applicable. A hash\u002Ftoken proves artifact\n    identity, not AskQuestion provenance or consent.\n11. After a successful run, include the checkpoint under **Intermediate\u002Fcheckpoint\n    files** in the final **Saved files** block, separate from terminal deliverables and\n    existing reused\u002Fserved artifacts. Claim it was saved only from returned\n    `output_paths`\u002F`output_targets`, published lineage\u002Fartifacts, the report, deterministic\n    stage-path discovery plus a safe read-only existence check, or run-record recipe\n    metadata. Never list the smoke-isolated checkpoint or a planned-but-unexecuted path as\n    durable; if the core did not report a requested path, say so rather than guessing.\n\nAuthoritative smoke and full run refuse a recipe with a recommended expensive checkpoint\nuntil it contains either the checkpoint or the exact baseline-decline attestation returned\nby `plan-checkpoint`. Never bypass that refusal by rebuilding or hand-editing the recipe.\n\n## Pipeline policy\n\n- Keep paths plus offsets when audio can be recreated from source.\n- Carry a waveform only across adjacent consumers that need it.\n- Never write intermediate audio merely to make a checkpoint.\n- Persist complete serializable row metadata before the first declared destructive decision.\n- Explicit UTMOS\u002FSIGMOS segment decisions are eligible only when the card and core bind the\n  generic selector `items_key` to the producer's exact `segments_key`, preserve every enabled\n  threshold with explicit `condition_logic='and'`, drop missing scores and empty parents, and\n  carry no waveform. Generic OR is valid for non-reuse pipelines but is not exact native-filter\n  separation. Path plus offset metadata is serializable and may be checkpointed.\n- Keep native filters when scope is `auto`, nesting is recursive, a segment list carries a\n  waveform, or decisions are private-metadata-dependent, batch\u002Fcorpus-dependent, or not\n  card-declared as separable.\n- Never place more than one new checkpoint.\n\n## Feedback after a completed run\n\nCall `plan-checkpoint --from-run RUN_ID --data DATA --decision-stage PRODUCER\n--decision-value VALUE`. The core adopts the exact recipe and changes only the declared\nscalar selector. For a card-declared compound decision, use\n`--decision-conditions '\u003CJSON>'` instead. It is a complete replacement, not a patch:\nname each enabled configured score key once, use finite numeric targets and `ge`, and\nomit a dimension to disable it. The core keeps AND logic, missing-score drop behavior,\nand nested `items_key`\u002Fempty-parent policy fixed, and refuses enabling a score not proven\npresent in the retained annotation checkpoint.\n\nThat returned selector change is a new recipe hash: retain still-valid same-chat\ncontext\u002Fprofile\u002Fpreference, but follow the branch reset from validate -> host critique ->\ncheckpoint decision (if any) -> reuse scan -> authoritative smoke -> presentation ->\nsubsequent approval before executing. If the dataset key changed, stop this flow and follow\nthe returned `delta_run` route. For unchanged data, use `reuse-scan` and `continue` only\nafter those recipe-level gates; do not execute a hand-edited suffix. Validation may inspect\nan occupied checkpoint only when its exact dataset\u002Fprefix artifact and content digest prove\nit complete; direct full execution still refuses to recreate or overwrite that path.\n\nTightening may be possible from a retained final subset, but loosening needs rows a prior\nfilter discarded. Do not claim final-manifest reuse unless the core proves it; the dedicated\npre-gate checkpoint is the supported evidence.\n",{"name":5,"description":7},"main","8a9a217c90127d424a8f503cb948698d7203002a","nemo_curator\u002Fstages\u002Faudio\u002Faudio_agent\u002Fskills\u002Fcheckpoint-placement",371,"https:\u002F\u002Fgithub.com\u002FNVIDIA-NeMo\u002FCurator","https:\u002F\u002Fgithub.com\u002FNVIDIA-NeMo","https:\u002F\u002Fnvidia.com\u002F","2026-11-11 08:35:27",{"source":8,"skillName":5,"commands":39,"prompt":49,"zipAvailable":50},[40,43,46],{"tool":41,"command":42},"npx","npx skills add NVIDIA-NeMo\u002FCurator --skill checkpoint-placement",{"tool":44,"command":45},"bunx","bunx skills add NVIDIA-NeMo\u002FCurator --skill checkpoint-placement",{"tool":47,"command":48},"pnpm","pnpm dlx skills add NVIDIA-NeMo\u002FCurator --skill checkpoint-placement","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FNVIDIA-NeMo\u002FCurator\u002Fblob\u002Fmain\u002Fnemo_curator\u002Fstages\u002Faudio\u002Faudio_agent\u002Fskills\u002Fcheckpoint-placement\u002FSKILL.md",true,[],[53,82,96,109,124,130],{"skillNo":54,"name":55,"nameZh":6,"description":56,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":57,"categories":58,"keywords":75,"publishedAt":25},"01M6BXJ4WRPMMBPADDY22KS3RG","audio-stage-authoring","Make a new or existing NeMo Curator audio stage agent-ready so the audio agent can discover, configure and chain it. Use when adding an audio stage, writing or fixing its describe() contract or StageContract, adding *_key fields or semantic roles, writing a capability card, or when card conformance or assert_agent_ready fails. This is for authoring stage code in a Curator checkout, not for curating a dataset - use the audio-curation skill for that.","https:\u002F\u002Fgithub.com\u002FNVIDIA-NeMo\u002FCurator\u002Fblob\u002Fmain\u002Fnemo_curator\u002Fstages\u002Faudio\u002Faudio_agent\u002Fskills\u002Faudio-stage-authoring\u002FSKILL.md",[59,64,67,70],{"categoryNo":60,"categoryName":61,"taxonomyType":62,"taxonomyTypeDesc":63},"01JBSEEDCAT000000000000016","图像与多媒体","SCENARIO","使用场景",{"categoryNo":65,"categoryName":66,"taxonomyType":62,"taxonomyTypeDesc":63},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":68,"categoryName":69,"taxonomyType":62,"taxonomyTypeDesc":63},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":71,"categoryName":72,"taxonomyType":73,"taxonomyTypeDesc":74},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[76,77,78,79,80,81],"audio stage authoring","Audio","configure","NeMo","code","writing",{"skillNo":83,"name":84,"nameZh":6,"description":85,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":86,"categories":87,"keywords":90,"publishedAt":25},"01M6BXJ1FTZZ76B6E79ZCJP2Q6","audio-curation","Build and run a NeMo Curator audio curation pipeline from a natural-language goal (host-driven planner over the audio_agent tool core). Use for any audio, speech or audio-dataset task - quality filtering, transcription, WER filtering, VAD, diarization, ALM windowing, resampling, channel conversion, or inspecting an audio corpus. Route such work through this skill rather than writing ad-hoc ffprobe, librosa or soundfile scripts.","https:\u002F\u002Fgithub.com\u002FNVIDIA-NeMo\u002FCurator\u002Fblob\u002Fmain\u002Fnemo_curator\u002Fstages\u002Faudio\u002Faudio_agent\u002Fskills\u002Faudio-curation\u002FSKILL.md",[88,89],{"categoryNo":60,"categoryName":61,"taxonomyType":62,"taxonomyTypeDesc":63},{"categoryNo":68,"categoryName":69,"taxonomyType":62,"taxonomyTypeDesc":63},[91,77,92,93,94,79,95,20,81],"audio curation","run","tool","pipeline","speech",{"skillNo":97,"name":98,"nameZh":6,"description":99,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":100,"categories":101,"keywords":102,"publishedAt":25},"01M6BXHYGV7VCDAMVQXPJ1CMDE","nemo-curator-docs","Maintain the NeMo Curator Fern docs site — add, update, move, or remove pages under fern\u002F. Use for any documentation changes.","https:\u002F\u002Fgithub.com\u002FNVIDIA-NeMo\u002FCurator\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fnemo-curator-docs\u002FSKILL.md",[],[103,79,104,105,106,107,108],"nemo curator docs","docs","docs site","site","update","documentation",{"skillNo":110,"name":111,"nameZh":6,"description":112,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":113,"categories":114,"keywords":116,"publishedAt":25},"01M6BXHT5YPZDFEMBJD7HRW5TB","getting-started","Set up NeMo Curator for data curation (text, image, video, audio)","https:\u002F\u002Fgithub.com\u002FNVIDIA-NeMo\u002FCurator\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fgetting-started\u002FSKILL.md",[115],{"categoryNo":60,"categoryName":61,"taxonomyType":62,"taxonomyTypeDesc":63},[117,118,77,79,119,120,121,122,123],"getting started","image","data","SET","Video","data curation","text",{"skillNo":125,"name":84,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":126,"categories":127,"keywords":129,"publishedAt":25},"01M6BXHQ573S6BCYDZ224MEX9K","https:\u002F\u002Fgithub.com\u002FNVIDIA-NeMo\u002FCurator\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Faudio-curation\u002FSKILL.md",[128],{"categoryNo":60,"categoryName":61,"taxonomyType":62,"taxonomyTypeDesc":63},[77,91],{"skillNo":131,"name":5,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":132,"categories":133,"keywords":134,"publishedAt":25},"01M6BXHM5EPNGD9S4ED7P7KEYS","https:\u002F\u002Fgithub.com\u002FNVIDIA-NeMo\u002FCurator\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fcheckpoint-placement\u002FSKILL.md",[],[19,18]]