[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M69BTS58A2NGMMP9V5SH1FVE":3,"skill-same:01M69BTS58A2NGMMP9V5SH1FVE":80},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":27,"linkOnly":28,"markdownContent":29,"markdownBody":30,"frontMatter":31,"refName":34,"commitSha":35,"skillDirectory":36,"forksCount":37,"repositoryHtmlUrl":38,"repositoryHomepageUrl":6,"ownerHtmlUrl":39,"ownerBlogUrl":40,"ownerDescription":41,"updatedAt":42,"install":43,"resources":56},"01M69BTS58A2NGMMP9V5SH1FVE","shadow-frog-nap",null,"Generate grounded software feature-task briefs with a small, bounded ideation budget instead of implementing every idea. Read focused source and optional shadow\u002Fdream evidence, grow or resume a persistent proposal tree, and obtain independent shortlist judgments. Run only decision-changing probes of existing behavior. Use mode=coherent to connect each child to its parent's findings or design while encouraging diverse siblings. Use for lightweight ideation, nap runs, or preparing SWE implementation tasks; use shadow-frog-dream for full implementation-backed experiments.","microsoft\u002FShadowFrog","microsoft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6154722?v=4","01M698VYDXZ6JW5WH3CRV650R8","Microsoft","01M69BTFDNCFRDGPJVWET4C0RN",33,"MIT","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FShadowFrog\u002Fblob\u002Fmain\u002Fskills\u002Fshadow-frog-nap\u002FSKILL.md",[],[19,20,21,22,23,24,25,26],"nap","shadow frog nap","design","experiments","tasks","connect","generate","run","2026-11-10 10:12:30",false,"---\nname: shadow-frog-nap\ndescription: >-\n  Generate grounded software feature-task briefs with a small, bounded\n  ideation budget instead of implementing every idea. Read focused source\n  and optional shadow\u002Fdream evidence, grow or resume a persistent proposal\n  tree, and obtain independent shortlist judgments. Run only decision-changing\n  probes of existing behavior. Use mode=coherent to connect each child to\n  its parent's findings or design while encouraging diverse siblings.\n  Use for lightweight ideation, nap runs, or preparing SWE implementation\n  tasks; use shadow-frog-dream for full implementation-backed experiments.\nscripts:\n  - nap.py\n---\n\n# ShadowFrog Nap\n\nNap is **implementation-free feature-task ideation**, not feature development\nor verified dreaming. The host agent generates proposals and delegates an\nindependent judgment. The Python helper manages the persistent tree, binds\njudgments to exact proposal inputs, and exports reviewed contracts. It never\ncalls a model, executes probes, implements features, creates worktrees\u002Fbranches,\npushes, or writes shadow discoveries.\n\n## Inputs and Limits\n\nAccept a user goal or area, optional prior dream\u002Fnap evidence, a mode, and a\nwork budget. A Git repository with a commit is required; a remote and an\ninitialized `.shadow\u002F` are **not** required.\n\n| Setting | Default | Meaning |\n|---------|---------|---------|\n| `mode` | `broad` | Explore distinct opportunities; `coherent` regularizes parent-child connections |\n| `max_nodes` | 7 | Total recorded nodes, including imported seeds and rejected attempts |\n| `max_depth` | unset (`null`) | Optional user-requested maximum parent edges; roots have depth 0 |\n| `max_probes` | 2 | Total executed probes recorded across all nodes, including failures |\n| `max_tasks` | 2 | Maximum selected ready task briefs |\n| `max_reviews` | 2 | Recorded judge batches: one shortlist review plus a bounded re-review |\n\nThese are **ceilings, not quotas**. Zero selected tasks is a valid result.\nUsers can request larger budgets, including ten diverse children of one\nparent. Agree on limits before starting and persist them in the record;\nnever erase rejected work or enlarge limits to disguise an overrun.\nDepth is not a default stopping condition. Omit `max_depth` or set it to\n`null` to leave it uncapped; an explicit nonnegative integer still limits it.\nThe total node budget bounds every run, and parent\u002Fcycle checks always apply.\n\nThe helper enforces **recorded** limits, not actual API spending or unrecorded\ncommands\u002Fmodel calls. Respect the host's token\u002Fcost\u002Ftime limits separately,\nincluding invalid or failed judge responses. Do not install dependencies,\ndebug infrastructure, spawn per-candidate implementation workers, or run full\nsuites automatically. One independent shortlist judge and a bounded re-review\nare allowed within the review budget; do not start a model panel for every node.\nEscalation to a full dream is a separate decision.\n\n## Modes\n\nExamples: `\u002Fshadow-frog-nap` or `\u002Fshadow-frog-nap mode=coherent`.\n\nResolve the requested mode once and carry it through planning, child context,\nthe run's `mode`, and every helper invocation's `--mode` argument. Do not\nsilently fall back to broad mode.\nThe CLI's expected mode defaults to `broad`, just like Dream validation;\na coherent record requires an explicit `--mode coherent`.\n\n**Broad:** propose a few distinct, code-grounded opportunities. With defaults,\nstart with up to three candidates, retain at most two promising directions,\nand refine while useful grounded progress and the total work budget remain.\nDo not impose a fixed number of refinement rounds.\n\n**Coherent:** each child identifies a concrete parent capability, finding,\nlimitation, or design decision and extends, integrates, challenges, replaces,\nsimplifies, or proposes an alternative to it. Use `\u002Fshadow-frog`'s shared\n`parent_connection` format.\n\n- Coherence is **local to an edge**, not one fixed goal for the whole tree.\n- Each child has its own goal. Diverse siblings are encouraged, not constrained\n  to the same subgoal, different files, or a prescribed diversity quota.\n- Technical independence does not disqualify a justified alternative. Explain\n  the parent connection; thematic similarity or a parent ID alone is not enough.\n- Challenges are permitted, not mandatory. Do not manufacture bad designs to\n  increase depth.\n- A parent's proposed API does not exist merely because a nap described it.\n  Parent links express idea provenance, not implemented code dependencies.\n\n## Workflow\n\n```text\npinned source + optional prior evidence\n                  |\n          grounded candidates\n                  |\n      select, challenge, refine\n                  |\n       probe decisive unknowns\n                  |\n       independent shortlist judge\n                  |\n       selected task contracts\n```\n\n## Operational Tree Workflow\n\nUse one persistent record across sessions. The default branch is represented\nby an immutable `base_commit`; `@base` is a virtual code-root selector, not an\ninvented proposal with fake symbol evidence. Root proposals have null\n`parent_id`. Depth counts proposal-parent edges, and the virtual root consumes\nno node budget.\n\nResolve the intended default branch or commit explicitly; do not assume the\ncurrently checked-out feature branch is the intended baseline. Initialize once:\n\n```text\npython .github\u002Fskills\u002Fshadow-frog-nap\u002Fnap.py TREE.json --repo REPO --mode coherent --init --base DEFAULT_REF --max-nodes 20\n```\n\nUse the actual default branch name\u002Fref or full commit instead of `DEFAULT_REF`.\nThe helper resolves it once, creates a version-2 record, and refuses to overwrite\nan existing tree. `--max-depth` is optional; initial `--max-nodes`, `--max-probes`,\n`--max-tasks`, and `--max-reviews` flags are accepted only with `--init`.\n\nTo expand a parent, use `--context @base` for root opportunities or\n`--context n1` for a proposal. The packet supplies the pinned code baseline,\nthe parent's full proposal and review feedback, brief ancestors\u002Fexisting\nchildren, and current usage. Keep actual code and hypothetical design state\nseparate.\n\nGenerate a UTF-8 JSON **list of proposal objects** in a submission file. Each\nobject uses the node fields below except `id`, `parent_id`, and `review_id`;\nthe driver owns those fields. Omit status for a candidate, or explicitly record\na `seed`\u002F`rejected` attempt with its required evidence\u002Freason. Never submit\n`ready`: only a current accepted judgment can grant it.\n\n```text\npython .github\u002Fskills\u002Fshadow-frog-nap\u002Fnap.py TREE.json --repo REPO --mode coherent --add CHILDREN.json --parent n1\n```\n\nThe helper assigns unique IDs and appends the whole batch or nothing. Exact\nsame-parent retries reuse existing IDs without resetting judgment\u002Fstatus or\nconsuming another node. Existing parent\u002Fsibling design payloads are unchanged.\nTo revise or replace a proposal,\nappend a child with its full active contract and appropriate parent connection;\ndo not rewrite its parent. This also permits sibling alternatives and rejected\nideas to motivate a better child.\n\nOne coordinator writes the canonical tree. Workers return proposal\u002Fjudgment\nfiles, not competing edits to `TREE.json`. Mutations use an exclusive adjacent\nlock and atomic replacement, increment `revision`, and validate the complete\nrecord and pinned source before publishing. On a stale lock after interruption,\nconfirm its writer stopped before removing only that lock; never discard the\ntree to bypass contention. Resume by reopening the same tree and selecting a\nparent, not by reconstructing state from chat history.\n\nRecord data is flushed and file-synced before replacement. Unsupported file\nsync is reported explicitly; other sync failures leave the old record intact.\nAtomic publication prevents partial JSON visibility during process interruption,\nbut this helper does not perform a portable directory sync or promise survival\nof the latest update across power loss on every filesystem. Keep required\ndurability\u002Fbackups in the host storage layer. Never infer that a PID-only lock\nis safe to remove merely because it is old.\n\n### 1. Pin and Ground\n\nRead the repository's instructions and, when present, relevant preferences,\nper-file shadows, cross-cutting discoveries, and selected dream reports.\nUse existing indexes to select context; do not read every past report or\ninitialize a full shadow merely to nap.\n\nUse `--init --base` to obtain the full intended baseline commit. Inspect source and\nexisting behavior at that commit. If the working tree differs, inspect the\npinned versions rather than treating uncommitted or newer code as baseline.\nResolve real `file::symbol` anchors; do not invent symbols or copy template\nreferences. The helper checks file existence at the commit, **not symbol\nexistence or the truth of observations**.\n\nFor each candidate, identify a user need, an existing limitation, and an\nintegration point. Search for existing equivalent functionality before\ndeveloping the idea. Generic TODO lists and unrelated standalone add-ons\nare not sufficient motivation.\n\n### 2. Select and Refine\n\nReject weak or duplicate ideas early, without implementing them. Maintain one\ncanonical run record through the managed append operations. Save observations\nand rejected directions as work proceeds so another session can resume.\n\nUse a selected parent's context packet, not its entire conversation history.\nRead cited source\u002Freport details when necessary to check the evidence.\nBrief summaries of existing children help avoid duplicates and inspire\ndifferent directions; siblings' proposed features are **not** inherited code.\n\nEach refinement must add a grounded constraint, useful composition,\ncounterexample, or reasoned alternative. Rephrasing a proposal or adding\nunrelated requirements is not progress. Stop or choose another parent when\nno worthwhile continuation exists. Once a node has children, preserve its\nhistorical goal\u002Fevidence and record revisions as new nodes.\n\nImported dream or nap evidence can be represented by a `seed` node with\n`inherited` evidence and its original reference. Its children use normal\nlocal node IDs. Import only the relevant parent packet, not an entire old\ntree. Recheck stale observations against this run's pinned commit.\nKeep historical commands as inherited evidence references, not new probes\ncharged to this run's execution budget.\n\n### 3. Probe Only Decision-Changing Questions\n\nRun a narrow probe only if its result can change selection, feasibility,\nacceptance criteria, or the choice between alternatives. Probes observe\nexisting behavior; they must not implement or prototype the proposed feature.\nUse the repository's supported runner and isolation appropriate to the command.\nDo not execute experimental mutations in the user's working tree.\n\nRecord the exact command as an argument array, its exit code, the question,\nand the observed result. Failed probes consume budget too. An unexecuted\nprobe belongs in `open_questions`, not the `probes` list. Missing dependencies\nor an exhausted budget are explicit unresolved questions, never evidence of\nsuccess. The helper does not execute or independently attest these commands.\n\n### 4. Independent Judgment and Readiness\n\nBefore selecting tasks, prepare one review packet for the shortlisted paths:\n\n```text\npython .github\u002Fskills\u002Fshadow-frog-nap\u002Fnap.py TREE.json --repo REPO --mode coherent --review-packet n3 n6\n```\n\nCapture its JSON output through the host's tooling. Delegate to a **strong\nreasoning model in a fresh context**, preferably a different backbone from the\ngenerator when the host supports it. Give the judge the packet and read-only\naccess to source at its exact `base_commit`, not the generator's conversation\nor self-assigned confidence. If the host cannot provide an independent context,\nleave proposals as candidates; do not fabricate a review or impersonate a judge.\n\nThe judge assesses grounding, plausible feasibility, user value\u002Fdistinctness,\nscope and acceptance criteria, each parent-child connection, and the final active\ncontract. Siblings need not share a goal. A useful alternative need not call\nparent code, and no hypothetical parent API may be assumed implemented.\n\nFor a selected path, use the packet's concrete `path_questions` in that same\nreview, without requiring another model pass:\n- What worthwhile outcome does the path now describe?\n- Which steps add capability, resolve uncertainty, or change a meaningful tradeoff?\n- Which merely rephrase earlier work, and what actionable refinement would help?\n- Does the final contract stand alone at the pinned baseline?\n\nThis is a path-level planning lens, not a fixed objective for the entire tree.\nChanging direction, revisiting the same files, and learning from a rejected\ndesign are legitimate. Do not turn the history into a requirement to implement\nevery ancestor. Explain useful progression rather than scoring length. If a\ncontinuation merely repeats an existing useful task, keep that task selected\nor append a genuinely revised child; do not rewrite reviewed ancestor payloads\nto follow a suggestion to \"consolidate\" the history.\n\nSeparate binding behavior\u002Fconstraints from suggested implementation choices.\nReplacing a design does not implicitly retire a requirement. Scope changes must\nbe explicit in the active contract and parent connection; user constraints must\nnot disappear under the label of an architectural alternative. Keep blocking\nplanning questions separate from nonblocking implementation risks.\n\nReturn **accept \u002F revise \u002F reject**, with code references, a rationale, and\nblocking issues. Do not produce only a score. The output format is:\n\n```json\n{\n  \"reviewer\": \"\u003Cactual independent model\u002Fcontext identity recorded by the host>\",\n  \"judgments\": [\n    {\n      \"node_id\": \"n3\",\n      \"input_hash\": \"\u003Ccopy exactly from the corresponding packet target>\",\n      \"decision\": \"accept\",\n      \"rationale\": \"\u003Cspecific source-grounded assessment>\",\n      \"blocking_issues\": [],\n      \"evidence\": [\"\u003Creal file>::\u003Creal symbol>\"]\n    }\n  ]\n}\n```\n\nAn accept decision requires no blockers and a complete task with no unresolved\nquestions. Revise\u002Freject decisions require concrete blockers. The host records\nthe real reviewer identity and submits the response, without changing a verdict\nto make the demonstration or quota succeed:\n\n```text\npython .github\u002Fskills\u002Fshadow-frog-nap\u002Fnap.py TREE.json --repo REPO --mode coherent --record-review JUDGMENT.json\npython .github\u002Fskills\u002Fshadow-frog-nap\u002Fnap.py TREE.json --repo REPO --mode coherent --select n3 n6\n```\n\nRecording is atomic and exact retries are idempotent. The helper stores review\nbatches, changes only review\u002Fstatus metadata, and checks SHA-256 bindings over\nthe proposal, its ancestor design payloads, mode, and base commit. Adding a\nsibling does not invalidate an existing approval. Changing reviewed semantics\ndoes; append a revision and obtain a new judgment rather than forging hashes.\nStatus\u002Freview metadata is not implementation state and is not inherited as code.\n\nPermit at most one targeted revision\u002Fre-review under default limits. If a judge\ncannot settle a critical uncertainty without implementation, keep the proposal\nunready and hand that question to Dream. Do not run open-ended debates.\n\nA ready task must:\n\n- Address a project-specific need, with evidence anchored to the pinned source.\n- State observable desired behavior, acceptance criteria, and non-goals.\n- Resolve blocking questions and fit a reasonable implementation scope.\n- Stand alone at `base_commit`, without assuming an idea parent was implemented.\n- In coherent mode, explain a meaningful parent connection and its own delta.\n\n`ready` means **independently judge-reviewed and specified**, not execution-proven.\nIt must reference the latest judgment for that node; an older acceptance cannot\noverride a later rejection.\nReceipts prevent accidental stale approvals but cannot authenticate that an LLM\nactually ran or establish the truth of its conclusions. The host must perform\nthe real independent review; the Python helper is not a semantic oracle.\nViews and exports scope this status to planning: implementation is not assessed\nby Nap, proposed-feature runtime validation has not been performed by Nap, and\nreviewer authenticity is not attested. Do not equate missing risk notes with an\nabsence of implementation risk.\n\nIf a blocking question requires implementing a candidate or prototype, leave\nit unresolved and hand it to `\u002Fshadow-frog-dream` or a downstream implementation\ntask. Do not turn the nap into an implementation loop. A later nap can pin an\nactual, independently validated implementation commit and import its evidence.\nDo not pretend hypothetical dependencies exist. Freeze task definitions and\nparent commits before using them for an offline benchmark.\n\n## Record Format\n\nStore `run.json` and exports under `.shadow\u002F_meta\u002Fnaps\u002F\u003Crun-name>\u002F` **only if\nthe shadow is already initialized**. Otherwise use an agent workspace or\nanother user-approved directory outside `.shadow\u002F`. Do not create a partial\nshadow, `_dreams\u002F` artifacts, or per-file discovery entries for proposals.\n\nThe persisted record is normally created and mutated by the helper, not edited\nby workers. This example illustrates its shape; placeholders must become actual\nsource evidence. Version 1 records do not have judgment provenance; import their\nproposals as unreviewed candidates\u002Fseeds in a new tree rather than inventing\napprovals.\n\n```json\n{\n  \"version\": 2,\n  \"revision\": 0,\n  \"mode\": \"coherent\",\n  \"base_commit\": \"\u003Cfull commit ID>\",\n  \"limits\": {\n    \"max_nodes\": 7,\n    \"max_depth\": null,\n    \"max_probes\": 2,\n    \"max_tasks\": 2,\n    \"max_reviews\": 2\n  },\n  \"nodes\": [\n    {\n      \"id\": \"n1\",\n      \"parent_id\": null,\n      \"title\": \"Cancellable streaming export\",\n      \"goal\": \"Let callers stop an export without buffering all records\",\n      \"status\": \"candidate\",\n      \"parent_connection\": null,\n      \"evidence\": [\n        {\n          \"anchor\": \"src\u002Fexporter.ext::stream\",\n          \"kind\": \"inspection\",\n          \"observation\": \"\u003Cobserved current behavior>\"\n        }\n      ],\n      \"probes\": []\n    }\n  ],\n  \"reviews\": [],\n  \"selected\": []\n}\n```\n\nNode IDs use letters, digits, dots, underscores, and hyphens, start with a\nletter\u002Fdigit, and are at most 80 characters. `parent_id` is null for a root\nor an existing node ID; records may be unordered but must be acyclic.\n\nStatuses: `seed`, `candidate`, `ready`, `rejected`. A rejected node also needs\na nonempty `reason`. Seeds\u002Frejections can motivate a child. A ready node has\na `review_id` pointing to a current accepted judgment in the append-only\n`reviews` list. Preserve historical proposal payloads; supersession is local\nto the child path, not a rewrite of the parent or its other children.\n\nEvery node has at least one evidence entry:\n- `inspection`: an observation checked against source.\n- `probe`: also supply `probe`, the zero-based index of the executed probe\n  in this node's `probes` array.\n- `inherited`: also supply `reference` identifying the prior report\u002Fnode.\n  Inherited evidence does not become verified merely by being reused.\n\nA probe has `question`, `command` (a nonempty argument array), `exit_code`\n(integer), and `result`. No shell pipelines or shell-export handoffs are\nneeded by the helper.\n\nA ready node also contains this complete, **currently active** task contract:\n\n```json\n{\n  \"task\": {\n    \"current_behavior\": \"\u003Cwhat the pinned source currently does>\",\n    \"desired_behavior\": \"\u003Cobservable behavior to implement>\",\n    \"acceptance_criteria\": [\"\u003Cspecific successful and edge-case outcomes>\"],\n    \"non_goals\": [\"\u003Cexplicit boundary>\"],\n    \"open_questions\": [],\n    \"constraints\": [\"\u003Cbinding constraint, when needed>\"],\n    \"design_suggestions\": [\"\u003Coptional implementation approach, not a requirement>\"],\n    \"implementation_risks\": [\"\u003Cnonblocking risk to evaluate during implementation>\"]\n  }\n}\n```\n\nNon-ready nodes may omit `task`. A review packet requires a complete task shape,\nwhich may still have open questions for the judge to identify as blockers.\n`selected` contains unique ready IDs only. Use `--select` with no IDs to clear it.\n\n`constraints`, `design_suggestions`, and `implementation_risks` are optional\nlists of nonempty strings. Binding behavior belongs in `desired_behavior`,\n`acceptance_criteria`, or `constraints`; advice belongs in `design_suggestions`.\nExplicit `parent_connection.preserves` commitments remain required and appear\nin both export audiences. The judge must check that the full active contract\nactually respects them; the helper does not infer semantic preservation.\nAn implementation risk that makes the plan itself ungrounded or infeasible is\ninstead a blocking `open_questions` item and must prevent acceptance.\n\n## Python Helper\n\nLocate `nap.py` in `.github\u002Fskills\u002Fshadow-frog-nap\u002F` or\n`.claude\u002Fskills\u002Fshadow-frog-nap\u002F`. Use a Python 3 interpreter available on the\nhost (`python`, `python3`, or `py -3`); no Bash or Unix utilities are required.\nThe examples below use the Copilot install path and a coherent run:\n\n```text\npython .github\u002Fskills\u002Fshadow-frog-nap\u002Fnap.py RUN.json --repo REPO --mode coherent\npython .github\u002Fskills\u002Fshadow-frog-nap\u002Fnap.py RUN.json --repo REPO --mode coherent --context n1\npython .github\u002Fskills\u002Fshadow-frog-nap\u002Fnap.py RUN.json --repo REPO --mode coherent --export TASKS.md\npython .github\u002Fskills\u002Fshadow-frog-nap\u002Fnap.py RUN.json --repo REPO --mode coherent --export HANDOFF.md --audience implementation\npython .github\u002Fskills\u002Fshadow-frog-nap\u002Fnap.py RUN.json --repo REPO --mode coherent --trajectory n3\n```\n\nValidation checks limits, lineage, evidence shape, commit\u002Ffile existence, and\nreview bindings\u002Freadiness. `--context` emits the parent's full record\u002Freview\nand brief ancestor\u002Fchild summaries; `--context @base` starts from real code.\n`--export` writes UTF-8 Markdown to a **new** file\nand refuses to overwrite existing files. Other outputs are JSON on stdout;\nerrors go to stderr with exit 1 (argument errors use exit 2).\n\nExports have two explicit audiences. The default `planning` brief retains the\nreview rationale, detailed probes, and parent design context for comparing\nalternatives. `--audience implementation` produces a more concise handoff that\nleads with the user problem, required behavior\u002Fconstraints, acceptance criteria,\nnon-goals, suggestions, and implementation risks. Both retain supporting source\nreferences, planning-only readiness, and the **same active requirements**.\nChanging the audience does not change the node or its review.\n\nSuggested implementation is labelled non-binding. Parent history and superseded\ndesigns remain planning context, not additional implementation requirements.\nJSON summaries, parent context, trajectories, and export responses also expose\nscope-qualified readiness; an implementation may exist elsewhere, so Nap says\n`not_assessed`, not that no implementation has ever been started.\n\nThe final export uses selected nodes' active contracts, **not** a union of\nancestor requirements. Replacing A with B must not produce a task requiring\nboth A and B. `--trajectory` returns one root-to-node **idea** path, never a\nconcatenation of siblings or a claim that intermediate code was implemented.\nIndependent siblings require an explicit integration idea before combining\nthem into one long-horizon task.\n\nDo not run dream reconciliation, increment dream counters, or label task\nproposals `verified` in the shadow. Independently established behavioral facts\ncan be captured through the normal shadow workflow separately.\n","# ShadowFrog Nap\n\nNap is **implementation-free feature-task ideation**, not feature development\nor verified dreaming. The host agent generates proposals and delegates an\nindependent judgment. The Python helper manages the persistent tree, binds\njudgments to exact proposal inputs, and exports reviewed contracts. It never\ncalls a model, executes probes, implements features, creates worktrees\u002Fbranches,\npushes, or writes shadow discoveries.\n\n## Inputs and Limits\n\nAccept a user goal or area, optional prior dream\u002Fnap evidence, a mode, and a\nwork budget. A Git repository with a commit is required; a remote and an\ninitialized `.shadow\u002F` are **not** required.\n\n| Setting | Default | Meaning |\n|---------|---------|---------|\n| `mode` | `broad` | Explore distinct opportunities; `coherent` regularizes parent-child connections |\n| `max_nodes` | 7 | Total recorded nodes, including imported seeds and rejected attempts |\n| `max_depth` | unset (`null`) | Optional user-requested maximum parent edges; roots have depth 0 |\n| `max_probes` | 2 | Total executed probes recorded across all nodes, including failures |\n| `max_tasks` | 2 | Maximum selected ready task briefs |\n| `max_reviews` | 2 | Recorded judge batches: one shortlist review plus a bounded re-review |\n\nThese are **ceilings, not quotas**. Zero selected tasks is a valid result.\nUsers can request larger budgets, including ten diverse children of one\nparent. Agree on limits before starting and persist them in the record;\nnever erase rejected work or enlarge limits to disguise an overrun.\nDepth is not a default stopping condition. Omit `max_depth` or set it to\n`null` to leave it uncapped; an explicit nonnegative integer still limits it.\nThe total node budget bounds every run, and parent\u002Fcycle checks always apply.\n\nThe helper enforces **recorded** limits, not actual API spending or unrecorded\ncommands\u002Fmodel calls. Respect the host's token\u002Fcost\u002Ftime limits separately,\nincluding invalid or failed judge responses. Do not install dependencies,\ndebug infrastructure, spawn per-candidate implementation workers, or run full\nsuites automatically. One independent shortlist judge and a bounded re-review\nare allowed within the review budget; do not start a model panel for every node.\nEscalation to a full dream is a separate decision.\n\n## Modes\n\nExamples: `\u002Fshadow-frog-nap` or `\u002Fshadow-frog-nap mode=coherent`.\n\nResolve the requested mode once and carry it through planning, child context,\nthe run's `mode`, and every helper invocation's `--mode` argument. Do not\nsilently fall back to broad mode.\nThe CLI's expected mode defaults to `broad`, just like Dream validation;\na coherent record requires an explicit `--mode coherent`.\n\n**Broad:** propose a few distinct, code-grounded opportunities. With defaults,\nstart with up to three candidates, retain at most two promising directions,\nand refine while useful grounded progress and the total work budget remain.\nDo not impose a fixed number of refinement rounds.\n\n**Coherent:** each child identifies a concrete parent capability, finding,\nlimitation, or design decision and extends, integrates, challenges, replaces,\nsimplifies, or proposes an alternative to it. Use `\u002Fshadow-frog`'s shared\n`parent_connection` format.\n\n- Coherence is **local to an edge**, not one fixed goal for the whole tree.\n- Each child has its own goal. Diverse siblings are encouraged, not constrained\n  to the same subgoal, different files, or a prescribed diversity quota.\n- Technical independence does not disqualify a justified alternative. Explain\n  the parent connection; thematic similarity or a parent ID alone is not enough.\n- Challenges are permitted, not mandatory. Do not manufacture bad designs to\n  increase depth.\n- A parent's proposed API does not exist merely because a nap described it.\n  Parent links express idea provenance, not implemented code dependencies.\n\n## Workflow\n\n```text\npinned source + optional prior evidence\n                  |\n          grounded candidates\n                  |\n      select, challenge, refine\n                  |\n       probe decisive unknowns\n                  |\n       independent shortlist judge\n                  |\n       selected task contracts\n```\n\n## Operational Tree Workflow\n\nUse one persistent record across sessions. The default branch is represented\nby an immutable `base_commit`; `@base` is a virtual code-root selector, not an\ninvented proposal with fake symbol evidence. Root proposals have null\n`parent_id`. Depth counts proposal-parent edges, and the virtual root consumes\nno node budget.\n\nResolve the intended default branch or commit explicitly; do not assume the\ncurrently checked-out feature branch is the intended baseline. Initialize once:\n\n```text\npython .github\u002Fskills\u002Fshadow-frog-nap\u002Fnap.py TREE.json --repo REPO --mode coherent --init --base DEFAULT_REF --max-nodes 20\n```\n\nUse the actual default branch name\u002Fref or full commit instead of `DEFAULT_REF`.\nThe helper resolves it once, creates a version-2 record, and refuses to overwrite\nan existing tree. `--max-depth` is optional; initial `--max-nodes`, `--max-probes`,\n`--max-tasks`, and `--max-reviews` flags are accepted only with `--init`.\n\nTo expand a parent, use `--context @base` for root opportunities or\n`--context n1` for a proposal. The packet supplies the pinned code baseline,\nthe parent's full proposal and review feedback, brief ancestors\u002Fexisting\nchildren, and current usage. Keep actual code and hypothetical design state\nseparate.\n\nGenerate a UTF-8 JSON **list of proposal objects** in a submission file. Each\nobject uses the node fields below except `id`, `parent_id`, and `review_id`;\nthe driver owns those fields. Omit status for a candidate, or explicitly record\na `seed`\u002F`rejected` attempt with its required evidence\u002Freason. Never submit\n`ready`: only a current accepted judgment can grant it.\n\n```text\npython .github\u002Fskills\u002Fshadow-frog-nap\u002Fnap.py TREE.json --repo REPO --mode coherent --add CHILDREN.json --parent n1\n```\n\nThe helper assigns unique IDs and appends the whole batch or nothing. Exact\nsame-parent retries reuse existing IDs without resetting judgment\u002Fstatus or\nconsuming another node. Existing parent\u002Fsibling design payloads are unchanged.\nTo revise or replace a proposal,\nappend a child with its full active contract and appropriate parent connection;\ndo not rewrite its parent. This also permits sibling alternatives and rejected\nideas to motivate a better child.\n\nOne coordinator writes the canonical tree. Workers return proposal\u002Fjudgment\nfiles, not competing edits to `TREE.json`. Mutations use an exclusive adjacent\nlock and atomic replacement, increment `revision`, and validate the complete\nrecord and pinned source before publishing. On a stale lock after interruption,\nconfirm its writer stopped before removing only that lock; never discard the\ntree to bypass contention. Resume by reopening the same tree and selecting a\nparent, not by reconstructing state from chat history.\n\nRecord data is flushed and file-synced before replacement. Unsupported file\nsync is reported explicitly; other sync failures leave the old record intact.\nAtomic publication prevents partial JSON visibility during process interruption,\nbut this helper does not perform a portable directory sync or promise survival\nof the latest update across power loss on every filesystem. Keep required\ndurability\u002Fbackups in the host storage layer. Never infer that a PID-only lock\nis safe to remove merely because it is old.\n\n### 1. Pin and Ground\n\nRead the repository's instructions and, when present, relevant preferences,\nper-file shadows, cross-cutting discoveries, and selected dream reports.\nUse existing indexes to select context; do not read every past report or\ninitialize a full shadow merely to nap.\n\nUse `--init --base` to obtain the full intended baseline commit. Inspect source and\nexisting behavior at that commit. If the working tree differs, inspect the\npinned versions rather than treating uncommitted or newer code as baseline.\nResolve real `file::symbol` anchors; do not invent symbols or copy template\nreferences. The helper checks file existence at the commit, **not symbol\nexistence or the truth of observations**.\n\nFor each candidate, identify a user need, an existing limitation, and an\nintegration point. Search for existing equivalent functionality before\ndeveloping the idea. Generic TODO lists and unrelated standalone add-ons\nare not sufficient motivation.\n\n### 2. Select and Refine\n\nReject weak or duplicate ideas early, without implementing them. Maintain one\ncanonical run record through the managed append operations. Save observations\nand rejected directions as work proceeds so another session can resume.\n\nUse a selected parent's context packet, not its entire conversation history.\nRead cited source\u002Freport details when necessary to check the evidence.\nBrief summaries of existing children help avoid duplicates and inspire\ndifferent directions; siblings' proposed features are **not** inherited code.\n\nEach refinement must add a grounded constraint, useful composition,\ncounterexample, or reasoned alternative. Rephrasing a proposal or adding\nunrelated requirements is not progress. Stop or choose another parent when\nno worthwhile continuation exists. Once a node has children, preserve its\nhistorical goal\u002Fevidence and record revisions as new nodes.\n\nImported dream or nap evidence can be represented by a `seed` node with\n`inherited` evidence and its original reference. Its children use normal\nlocal node IDs. Import only the relevant parent packet, not an entire old\ntree. Recheck stale observations against this run's pinned commit.\nKeep historical commands as inherited evidence references, not new probes\ncharged to this run's execution budget.\n\n### 3. Probe Only Decision-Changing Questions\n\nRun a narrow probe only if its result can change selection, feasibility,\nacceptance criteria, or the choice between alternatives. Probes observe\nexisting behavior; they must not implement or prototype the proposed feature.\nUse the repository's supported runner and isolation appropriate to the command.\nDo not execute experimental mutations in the user's working tree.\n\nRecord the exact command as an argument array, its exit code, the question,\nand the observed result. Failed probes consume budget too. An unexecuted\nprobe belongs in `open_questions`, not the `probes` list. Missing dependencies\nor an exhausted budget are explicit unresolved questions, never evidence of\nsuccess. The helper does not execute or independently attest these commands.\n\n### 4. Independent Judgment and Readiness\n\nBefore selecting tasks, prepare one review packet for the shortlisted paths:\n\n```text\npython .github\u002Fskills\u002Fshadow-frog-nap\u002Fnap.py TREE.json --repo REPO --mode coherent --review-packet n3 n6\n```\n\nCapture its JSON output through the host's tooling. Delegate to a **strong\nreasoning model in a fresh context**, preferably a different backbone from the\ngenerator when the host supports it. Give the judge the packet and read-only\naccess to source at its exact `base_commit`, not the generator's conversation\nor self-assigned confidence. If the host cannot provide an independent context,\nleave proposals as candidates; do not fabricate a review or impersonate a judge.\n\nThe judge assesses grounding, plausible feasibility, user value\u002Fdistinctness,\nscope and acceptance criteria, each parent-child connection, and the final active\ncontract. Siblings need not share a goal. A useful alternative need not call\nparent code, and no hypothetical parent API may be assumed implemented.\n\nFor a selected path, use the packet's concrete `path_questions` in that same\nreview, without requiring another model pass:\n- What worthwhile outcome does the path now describe?\n- Which steps add capability, resolve uncertainty, or change a meaningful tradeoff?\n- Which merely rephrase earlier work, and what actionable refinement would help?\n- Does the final contract stand alone at the pinned baseline?\n\nThis is a path-level planning lens, not a fixed objective for the entire tree.\nChanging direction, revisiting the same files, and learning from a rejected\ndesign are legitimate. Do not turn the history into a requirement to implement\nevery ancestor. Explain useful progression rather than scoring length. If a\ncontinuation merely repeats an existing useful task, keep that task selected\nor append a genuinely revised child; do not rewrite reviewed ancestor payloads\nto follow a suggestion to \"consolidate\" the history.\n\nSeparate binding behavior\u002Fconstraints from suggested implementation choices.\nReplacing a design does not implicitly retire a requirement. Scope changes must\nbe explicit in the active contract and parent connection; user constraints must\nnot disappear under the label of an architectural alternative. Keep blocking\nplanning questions separate from nonblocking implementation risks.\n\nReturn **accept \u002F revise \u002F reject**, with code references, a rationale, and\nblocking issues. Do not produce only a score. The output format is:\n\n```json\n{\n  \"reviewer\": \"\u003Cactual independent model\u002Fcontext identity recorded by the host>\",\n  \"judgments\": [\n    {\n      \"node_id\": \"n3\",\n      \"input_hash\": \"\u003Ccopy exactly from the corresponding packet target>\",\n      \"decision\": \"accept\",\n      \"rationale\": \"\u003Cspecific source-grounded assessment>\",\n      \"blocking_issues\": [],\n      \"evidence\": [\"\u003Creal file>::\u003Creal symbol>\"]\n    }\n  ]\n}\n```\n\nAn accept decision requires no blockers and a complete task with no unresolved\nquestions. Revise\u002Freject decisions require concrete blockers. The host records\nthe real reviewer identity and submits the response, without changing a verdict\nto make the demonstration or quota succeed:\n\n```text\npython .github\u002Fskills\u002Fshadow-frog-nap\u002Fnap.py TREE.json --repo REPO --mode coherent --record-review JUDGMENT.json\npython .github\u002Fskills\u002Fshadow-frog-nap\u002Fnap.py TREE.json --repo REPO --mode coherent --select n3 n6\n```\n\nRecording is atomic and exact retries are idempotent. The helper stores review\nbatches, changes only review\u002Fstatus metadata, and checks SHA-256 bindings over\nthe proposal, its ancestor design payloads, mode, and base commit. Adding a\nsibling does not invalidate an existing approval. Changing reviewed semantics\ndoes; append a revision and obtain a new judgment rather than forging hashes.\nStatus\u002Freview metadata is not implementation state and is not inherited as code.\n\nPermit at most one targeted revision\u002Fre-review under default limits. If a judge\ncannot settle a critical uncertainty without implementation, keep the proposal\nunready and hand that question to Dream. Do not run open-ended debates.\n\nA ready task must:\n\n- Address a project-specific need, with evidence anchored to the pinned source.\n- State observable desired behavior, acceptance criteria, and non-goals.\n- Resolve blocking questions and fit a reasonable implementation scope.\n- Stand alone at `base_commit`, without assuming an idea parent was implemented.\n- In coherent mode, explain a meaningful parent connection and its own delta.\n\n`ready` means **independently judge-reviewed and specified**, not execution-proven.\nIt must reference the latest judgment for that node; an older acceptance cannot\noverride a later rejection.\nReceipts prevent accidental stale approvals but cannot authenticate that an LLM\nactually ran or establish the truth of its conclusions. The host must perform\nthe real independent review; the Python helper is not a semantic oracle.\nViews and exports scope this status to planning: implementation is not assessed\nby Nap, proposed-feature runtime validation has not been performed by Nap, and\nreviewer authenticity is not attested. Do not equate missing risk notes with an\nabsence of implementation risk.\n\nIf a blocking question requires implementing a candidate or prototype, leave\nit unresolved and hand it to `\u002Fshadow-frog-dream` or a downstream implementation\ntask. Do not turn the nap into an implementation loop. A later nap can pin an\nactual, independently validated implementation commit and import its evidence.\nDo not pretend hypothetical dependencies exist. Freeze task definitions and\nparent commits before using them for an offline benchmark.\n\n## Record Format\n\nStore `run.json` and exports under `.shadow\u002F_meta\u002Fnaps\u002F\u003Crun-name>\u002F` **only if\nthe shadow is already initialized**. Otherwise use an agent workspace or\nanother user-approved directory outside `.shadow\u002F`. Do not create a partial\nshadow, `_dreams\u002F` artifacts, or per-file discovery entries for proposals.\n\nThe persisted record is normally created and mutated by the helper, not edited\nby workers. This example illustrates its shape; placeholders must become actual\nsource evidence. Version 1 records do not have judgment provenance; import their\nproposals as unreviewed candidates\u002Fseeds in a new tree rather than inventing\napprovals.\n\n```json\n{\n  \"version\": 2,\n  \"revision\": 0,\n  \"mode\": \"coherent\",\n  \"base_commit\": \"\u003Cfull commit ID>\",\n  \"limits\": {\n    \"max_nodes\": 7,\n    \"max_depth\": null,\n    \"max_probes\": 2,\n    \"max_tasks\": 2,\n    \"max_reviews\": 2\n  },\n  \"nodes\": [\n    {\n      \"id\": \"n1\",\n      \"parent_id\": null,\n      \"title\": \"Cancellable streaming export\",\n      \"goal\": \"Let callers stop an export without buffering all records\",\n      \"status\": \"candidate\",\n      \"parent_connection\": null,\n      \"evidence\": [\n        {\n          \"anchor\": \"src\u002Fexporter.ext::stream\",\n          \"kind\": \"inspection\",\n          \"observation\": \"\u003Cobserved current behavior>\"\n        }\n      ],\n      \"probes\": []\n    }\n  ],\n  \"reviews\": [],\n  \"selected\": []\n}\n```\n\nNode IDs use letters, digits, dots, underscores, and hyphens, start with a\nletter\u002Fdigit, and are at most 80 characters. `parent_id` is null for a root\nor an existing node ID; records may be unordered but must be acyclic.\n\nStatuses: `seed`, `candidate`, `ready`, `rejected`. A rejected node also needs\na nonempty `reason`. Seeds\u002Frejections can motivate a child. A ready node has\na `review_id` pointing to a current accepted judgment in the append-only\n`reviews` list. Preserve historical proposal payloads; supersession is local\nto the child path, not a rewrite of the parent or its other children.\n\nEvery node has at least one evidence entry:\n- `inspection`: an observation checked against source.\n- `probe`: also supply `probe`, the zero-based index of the executed probe\n  in this node's `probes` array.\n- `inherited`: also supply `reference` identifying the prior report\u002Fnode.\n  Inherited evidence does not become verified merely by being reused.\n\nA probe has `question`, `command` (a nonempty argument array), `exit_code`\n(integer), and `result`. No shell pipelines or shell-export handoffs are\nneeded by the helper.\n\nA ready node also contains this complete, **currently active** task contract:\n\n```json\n{\n  \"task\": {\n    \"current_behavior\": \"\u003Cwhat the pinned source currently does>\",\n    \"desired_behavior\": \"\u003Cobservable behavior to implement>\",\n    \"acceptance_criteria\": [\"\u003Cspecific successful and edge-case outcomes>\"],\n    \"non_goals\": [\"\u003Cexplicit boundary>\"],\n    \"open_questions\": [],\n    \"constraints\": [\"\u003Cbinding constraint, when needed>\"],\n    \"design_suggestions\": [\"\u003Coptional implementation approach, not a requirement>\"],\n    \"implementation_risks\": [\"\u003Cnonblocking risk to evaluate during implementation>\"]\n  }\n}\n```\n\nNon-ready nodes may omit `task`. A review packet requires a complete task shape,\nwhich may still have open questions for the judge to identify as blockers.\n`selected` contains unique ready IDs only. Use `--select` with no IDs to clear it.\n\n`constraints`, `design_suggestions`, and `implementation_risks` are optional\nlists of nonempty strings. Binding behavior belongs in `desired_behavior`,\n`acceptance_criteria`, or `constraints`; advice belongs in `design_suggestions`.\nExplicit `parent_connection.preserves` commitments remain required and appear\nin both export audiences. The judge must check that the full active contract\nactually respects them; the helper does not infer semantic preservation.\nAn implementation risk that makes the plan itself ungrounded or infeasible is\ninstead a blocking `open_questions` item and must prevent acceptance.\n\n## Python Helper\n\nLocate `nap.py` in `.github\u002Fskills\u002Fshadow-frog-nap\u002F` or\n`.claude\u002Fskills\u002Fshadow-frog-nap\u002F`. Use a Python 3 interpreter available on the\nhost (`python`, `python3`, or `py -3`); no Bash or Unix utilities are required.\nThe examples below use the Copilot install path and a coherent run:\n\n```text\npython .github\u002Fskills\u002Fshadow-frog-nap\u002Fnap.py RUN.json --repo REPO --mode coherent\npython .github\u002Fskills\u002Fshadow-frog-nap\u002Fnap.py RUN.json --repo REPO --mode coherent --context n1\npython .github\u002Fskills\u002Fshadow-frog-nap\u002Fnap.py RUN.json --repo REPO --mode coherent --export TASKS.md\npython .github\u002Fskills\u002Fshadow-frog-nap\u002Fnap.py RUN.json --repo REPO --mode coherent --export HANDOFF.md --audience implementation\npython .github\u002Fskills\u002Fshadow-frog-nap\u002Fnap.py RUN.json --repo REPO --mode coherent --trajectory n3\n```\n\nValidation checks limits, lineage, evidence shape, commit\u002Ffile existence, and\nreview bindings\u002Freadiness. `--context` emits the parent's full record\u002Freview\nand brief ancestor\u002Fchild summaries; `--context @base` starts from real code.\n`--export` writes UTF-8 Markdown to a **new** file\nand refuses to overwrite existing files. Other outputs are JSON on stdout;\nerrors go to stderr with exit 1 (argument errors use exit 2).\n\nExports have two explicit audiences. The default `planning` brief retains the\nreview rationale, detailed probes, and parent design context for comparing\nalternatives. `--audience implementation` produces a more concise handoff that\nleads with the user problem, required behavior\u002Fconstraints, acceptance criteria,\nnon-goals, suggestions, and implementation risks. Both retain supporting source\nreferences, planning-only readiness, and the **same active requirements**.\nChanging the audience does not change the node or its review.\n\nSuggested implementation is labelled non-binding. Parent history and superseded\ndesigns remain planning context, not additional implementation requirements.\nJSON summaries, parent context, trajectories, and export responses also expose\nscope-qualified readiness; an implementation may exist elsewhere, so Nap says\n`not_assessed`, not that no implementation has ever been started.\n\nThe final export uses selected nodes' active contracts, **not** a union of\nancestor requirements. Replacing A with B must not produce a task requiring\nboth A and B. `--trajectory` returns one root-to-node **idea** path, never a\nconcatenation of siblings or a claim that intermediate code was implemented.\nIndependent siblings require an explicit integration idea before combining\nthem into one long-horizon task.\n\nDo not run dream reconciliation, increment dream counters, or label task\nproposals `verified` in the shadow. Independently established behavioral facts\ncan be captured through the normal shadow workflow separately.\n",{"name":5,"scripts":32,"description":7},[33],"nap.py","main","42c6c9f7251ec110ba426e14f09cab159a6714d3","skills\u002Fshadow-frog-nap",9,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FShadowFrog","https:\u002F\u002Fgithub.com\u002Fmicrosoft","https:\u002F\u002Fopensource.microsoft.com","Open source projects and samples from Microsoft","2026-11-05 10:56:08",{"source":8,"skillName":5,"commands":44,"prompt":54,"zipAvailable":55},[45,48,51],{"tool":46,"command":47},"npx","npx skills add microsoft\u002FShadowFrog --skill shadow-frog-nap",{"tool":49,"command":50},"bunx","bunx skills add microsoft\u002FShadowFrog --skill shadow-frog-nap",{"tool":52,"command":53},"pnpm","pnpm dlx skills add microsoft\u002FShadowFrog --skill shadow-frog-nap","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FShadowFrog\u002Fblob\u002Fmain\u002Fskills\u002Fshadow-frog-nap\u002FSKILL.md",true,[57,62,68,72,76],{"path":33,"resourceType":58,"resourceTypeDesc":59,"sizeBytes":60,"sourceHtmlUrl":61},"SCRIPT","脚本",40268,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FShadowFrog\u002Fblob\u002Fmain\u002Fskills\u002Fshadow-frog-nap\u002Fnap.py",{"path":63,"resourceType":64,"resourceTypeDesc":65,"sizeBytes":66,"sourceHtmlUrl":67},"references\u002Findex.md","REFERENCE","参考文档",98,"https:\u002F\u002Fgithub.com\u002Fdavila7\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fai-research\u002Ffine-tuning-unsloth\u002Freferences\u002Findex.md",{"path":69,"resourceType":64,"resourceTypeDesc":65,"sizeBytes":70,"sourceHtmlUrl":71},"references\u002Fllms-full.md",1077228,"https:\u002F\u002Fgithub.com\u002Fdavila7\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fai-research\u002Ffine-tuning-unsloth\u002Freferences\u002Fllms-full.md",{"path":73,"resourceType":64,"resourceTypeDesc":65,"sizeBytes":74,"sourceHtmlUrl":75},"references\u002Fllms-txt.md",813092,"https:\u002F\u002Fgithub.com\u002Fdavila7\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fai-research\u002Ffine-tuning-unsloth\u002Freferences\u002Fllms-txt.md",{"path":77,"resourceType":64,"resourceTypeDesc":65,"sizeBytes":78,"sourceHtmlUrl":79},"references\u002Fllms.md",12507,"https:\u002F\u002Fgithub.com\u002Fdavila7\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fai-research\u002Ffine-tuning-unsloth\u002Freferences\u002Fllms.md",[81,106,116,136,144,159],{"skillNo":82,"name":83,"nameZh":6,"description":84,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":85,"categories":86,"keywords":87,"publishedAt":27},"01M69BTYQ2DPDT4ZDMD52GJVEJ","shadow-frog","Use a shadow knowledge base to understand any codebase. The .shadow\u002F directory mirrors the source tree with markdown files containing behavioral insights — known bugs, edge cases, implicit contracts, and user preferences. Always check the shadow before editing, debugging, or investigating code. When the user shares important context, write it to the shadow immediately. Invoke shadow-frog-init to create it, shadow-frog-update to refresh it, shadow-frog-dream for autonomous experiments, shadow-frog-nap for lightweight feature-task ideation, shadow-frog-meditate for shadow hygiene, or shadow-frog-viewer for user-facing browsing and visualization.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FShadowFrog\u002Fblob\u002Fmain\u002Fskills\u002Fshadow-frog\u002FSKILL.md",[],[88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,19,105,22],"shadow frog","Shadow","debugging","markdown","meditate","insights","knowledge base","files","autonomous","write","knowledge","dream","directory","code","visualization","update","create","init",{"skillNo":107,"name":108,"nameZh":6,"description":109,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":110,"categories":111,"keywords":112,"publishedAt":27},"01M69BTX451Y89BYJ36DEYJQPA","shadow-frog-viewer","Help users browse and visualize the shadow knowledge base: overview, search for files or symbols or text, view preferences, or see recent discoveries. Invoke when the user wants to see what's in the shadow, get an overview, or find specific knowledge.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FShadowFrog\u002Fblob\u002Fmain\u002Fskills\u002Fshadow-frog-viewer\u002FSKILL.md",[],[113,114,115],"shadow frog viewer","visualize","help",{"skillNo":117,"name":118,"nameZh":6,"description":119,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":120,"categories":121,"keywords":122,"publishedAt":27},"01M69BTVF2EGFP9RDPPKWMS3V6","shadow-frog-update","Update the shadow knowledge base after code changes and from conversational insights. Detects what changed via git diff, refreshes per-file shadows, captures knowledge shared by the user during the session, and updates cross-cutting discoveries. Invoke manually with \u002Fshadow-frog-update; the preToolUse hook will remind the agent when the shadow is behind HEAD.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FShadowFrog\u002Fblob\u002Fmain\u002Fskills\u002Fshadow-frog-update\u002FSKILL.md",[],[103,123,88,89,124,125,126,127,94,93,128,129,130,131,132,101,133,98,134,135],"shadow frog update","via","with","head","shared","updates","base","changes","file","diff","git","remind","session",{"skillNo":137,"name":138,"nameZh":6,"description":139,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":140,"categories":141,"keywords":142,"publishedAt":27},"01M69BTQ4VYJ5TEYGJ0JT6AYYS","shadow-frog-meditate","Clean and consolidate the shadow knowledge base. Scans all shadow files for duplicate discoveries (same claim, different wording), near-duplicates (one extends another), and conflicting entries (contradicting claims). Merges duplicates, resolves conflicts by investigating the code, and asks the user only when resolution is unclear. Invoke periodically to keep the shadow focused and free of noise.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FShadowFrog\u002Fblob\u002Fmain\u002Fskills\u002Fshadow-frog-meditate\u002FSKILL.md",[],[143,101],"shadow frog meditate",{"skillNo":145,"name":146,"nameZh":6,"description":147,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":148,"categories":149,"keywords":150,"publishedAt":27},"01M69BTN77C5G6REERWK8G4FB6","shadow-frog-init","Initialize a shadow knowledge base for any codebase. Creates a .shadow\u002F directory that mirrors the source tree with markdown files for AI-discovered insights. Run this once per repo before using other shadow-frog skills. Refuses to overwrite an existing .shadow\u002F unless --reset is passed.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FShadowFrog\u002Fblob\u002Fmain\u002Fskills\u002Fshadow-frog-init\u002FSKILL.md",[],[105,89,88,151,95,152,153,98,91,26,100,129,94,154,125,93,155,156,157,158],"shadow frog init","initialize","repo","reset","tree","for","codebase","Existing",{"skillNo":160,"name":161,"nameZh":6,"description":162,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":163,"categories":164,"keywords":170,"publishedAt":27},"01M69BTHHMPCWRRG66A846XZ06","shadow-frog-dream","Run autonomous experimentation while the user is AFK. Uses 6 investigation categories (investigation, bug hunting, feature design, refactoring, optimization, security audit) to systematically discover non-obvious behaviors. Every task is an experiment — implement in worktrees, commit to persistent dream branches, and push to the configured remote. Dreams compound across sessions: future experiments branch from prior dream branches, building a tree of progressively deeper work. Invoke when the user is AFK or asks for a dream run. Use mode=coherent to ground each child in its parent while encouraging diverse siblings, challenges, and alternatives.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FShadowFrog\u002Fblob\u002Fmain\u002Fskills\u002Fshadow-frog-dream\u002FSKILL.md",[165],{"categoryNo":166,"categoryName":167,"taxonomyType":168,"taxonomyTypeDesc":169},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",[171,172,26,173,174,175,176,22,177,178,21],"shadow frog dream","cleanup","setup","validate","commit","sessions","implement","security"]