[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6MQV67E2BDKY2JB0V1RGTP7":3,"skill-same:01M6MQV67E2BDKY2JB0V1RGTP7":64},{"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":37,"linkOnly":38,"markdownContent":39,"markdownBody":40,"frontMatter":41,"refName":43,"commitSha":44,"skillDirectory":45,"forksCount":46,"repositoryHtmlUrl":47,"repositoryHomepageUrl":6,"ownerHtmlUrl":48,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":49,"install":50,"resources":63},"01M6MQV67E2BDKY2JB0V1RGTP7","index-repo-docs",null,"Use when you need to create or update a reference doc from a repo's wiki, docs, and issues. Fetches and distills into a focused reference.","higherorderfunctor\u002Fnix-agentic-tools","higherorderfunctor","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F34926636?v=4","01M6MQT3TQS16N1CBRZJYR2EMB","Christopher Aubut","01M6MQT419AF9ERC87M87NRXQV",2,"Unlicense","https:\u002F\u002Fgithub.com\u002Fhigherorderfunctor\u002Fnix-agentic-tools\u002Fblob\u002Fmain\u002Fdev\u002Fskills\u002Findex-repo-docs\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36],"index repo docs","index","repo docs","repo","docs","use","when","you","URL","name","false","reference","wiki","doc","issues","git","update","create","2026-11-10 10:12:30",false,"---\nname: index-repo-docs\ndescription: >-\n  Use when you need to create or update a reference doc from a repo's wiki,\n  docs, and issues. Fetches and distills into a focused reference.\nargument-hint: \"\u003Cname-or-url|all> (e.g. git-branchless, git-absorb, all)\"\ndisable-model-invocation: false\n---\n\nFetch documentation from a repository and distill it into a practical reference\ndoc with concrete recipes and patterns. The output goes to `references\u002F` in the\nrepo root.\n\n## Known Repos\n\nUse this lookup table to resolve short names to repos. If `$ARGUMENTS` doesn't\nmatch a known name, treat it as a GitHub URL or `owner\u002Frepo`.\n\n| Name             | Repo                     | Focus                                 |\n| ---------------- | ------------------------ | ------------------------------------- |\n| `git-branchless` | `arxanas\u002Fgit-branchless` | Wiki, README, key issues on workflows |\n| `git-absorb`     | `tummychow\u002Fgit-absorb`   | README, man page, usage patterns      |\n| `git-revise`     | `mystor\u002Fgit-revise`      | README, docs, interactive usage       |\n\nIf `$ARGUMENTS` is `all` or empty (no arguments), iterate through every entry in\nthe table above and run the full indexing process for each one, skipping repos\nthat are up to date.\n\n## Output\n\nWrite to: `references\u002F\u003Cname>.md` in the repo root.\n\n`\u003Cname>` is the short name from the lookup table or the repo name from the URL.\n\n## Incremental Updates\n\nThe generated reference doc includes frontmatter with per-source indexing\nmetadata. Each source tracks its own date so partial re-indexing is possible and\nso it's clear which sources have actually been fetched:\n\n```yaml\n---\nrepo: owner\u002Frepo\nrepo-head: \u003Ccommit-sha>\nrepo-indexed: 2026-03-21\nwiki-head: \u003Ccommit-sha or null>\nwiki-indexed: 2026-03-21\nissues-indexed: 2026-03-21 # null if never fetched\ndiscussions-indexed: 2026-03-21 # null if repo has no Discussions or never fetched\nlabels-indexed: 2026-03-21\nlabel-head: \u003Csha256 of sorted label name list>\ndoc-sources: # discovered doc files and external links\n  - path: \"Documentation\u002Fgit-absorb.adoc\"\n    type: repo-file\n    relevance: \"man page with authoritative flag\u002Foption reference\"\n  - path: \"docs\u002FARCHITECTURE.md\"\n    type: repo-file\n    relevance: \"internal design docs for understanding behavior\"\n  - url: \"https:\u002F\u002Fgit-branchless.readthedocs.io\u002F\"\n    type: external\n    relevance: \"official hosted documentation site\"\n    reachable: true\nexclude-issue-patterns:\n  - \"renovate\"\n  - \"dependabot\"\n  - \"bump version\"\nvalue-labels:\n  - name: \"answered\"\n    reason: \"confirmed solutions from maintainers\"\n  - name: \"has workaround\"\n    reason: \"practical alternatives users can follow\"\n---\n```\n\nA `null` date means that source has never been properly indexed — treat it as\nneeding a full fetch regardless of other source states.\n\nOn re-run:\n\n1. **Read the existing reference doc** (if it exists) and parse its frontmatter\n2. **Check remote HEADs** for both the repo and wiki:\n   ```bash\n   repo_head=$(gh api \"repos\u002F${owner}\u002F${repo}\u002Fcommits?per_page=1\" --jq '.[0].sha')\n   wiki_head=$(git ls-remote \"https:\u002F\u002Fgithub.com\u002F${owner}\u002F${repo}.wiki.git\" HEAD 2>\u002Fdev\u002Fnull | cut -f1 || echo \"\")\n   ```\n3. **Re-assess labels** (every run — see Label Discovery below). Compare the\n   computed `label-head` against frontmatter to detect label changes.\n4. **Compare each source independently:**\n   - `repo-head` changed → re-fetch README\u002Fdocs, re-discover doc tree, full\n     regeneration\n   - `wiki-head` changed → re-fetch wiki, full regeneration\n   - `issues-indexed` is null or new issues exist since that date → fetch issues\n   - `discussions-indexed` is null or new discussions since that date → fetch\n     discussions\n   - `label-head` changed → re-assess labels, may trigger issue re-fetch\n   - `doc-sources` entries with `reachable: false` → re-check, prune if stale 3+\n     runs\n   - `doc-sources` external URLs → spot-check reachability on full regeneration\n5. **Check for new issues** updated since `issues-indexed`:\n   ```bash\n   gh api \"search\u002Fissues?q=repo:${owner}\u002F${repo}+type:issue+updated:>=${issues_indexed}T00:00:00Z&per_page=1\" \\\n     --jq '.total_count'\n   ```\n6. **Check for new discussions** (if enabled) since `discussions-indexed`\n7. If ALL sources are up to date, report \"already up to date\" and skip\n8. Otherwise, fetch only the stale sources and **merge** insights into the\n   existing doc. Only do a **full regeneration** if `repo-head` or `wiki-head`\n   changed (the prose\u002Fstructure source material changed). When only\n   `issues-indexed` or `discussions-indexed` is stale, the existing doc text is\n   the baseline — add new gotchas, recipes, and anti-patterns from issues\n   without rewriting or condensing existing sections. Never drop existing\n   content to make room; the 500-line limit applies to the final result, so if\n   the doc is already near the limit, integrate only the highest-value issue\n   insights.\n\n### Exclude Patterns\n\nThe `exclude-issue-patterns` list in frontmatter filters out noise from\nissues\u002Fdiscussions. On the first run, initialize it with common bot patterns:\n`renovate`, `dependabot`, `bump version`, `release v`.\n\nDuring indexing, if an issue title matches any pattern (case-insensitive), skip\nit. If you encounter a new category of noise issues during distillation, add the\npattern to `exclude-issue-patterns` for future runs.\n\n### Label Discovery\n\nEvery repo has different labels. Instead of hardcoding which labels matter,\ndiscover and assess them dynamically.\n\n**Fetch all labels** (runs every time, even on incremental updates):\n\n```bash\ngh api \"repos\u002F${owner}\u002F${repo}\u002Flabels\" --paginate \\\n  --jq '.[] | \"\\(.name)\\t\\(.description \u002F\u002F \"\")\\t\\(.color)\"'\n```\n\n**Compute `label-head`** — a hash of sorted label names to detect changes:\n\n```bash\nlabel_head=$(gh api \"repos\u002F${owner}\u002F${repo}\u002Flabels\" --paginate \\\n  --jq '[.[].name] | sort | join(\"\\n\")' | sha256sum | cut -d' ' -f1)\n```\n\n**Assess which labels have value** by classifying each into one of:\n\n- **High value** — labels indicating resolved questions, workarounds, recipes,\n  or confirmed patterns (e.g., \"answered\", \"has workaround\", \"good first issue\",\n  \"question\", \"howto\", \"cookbook\", \"workflow\", \"solved\")\n- **Medium value** — labels indicating feature discussions or design decisions\n  that reveal capabilities (e.g., \"enhancement\", \"feature request\", \"rfc\",\n  \"design\", \"discussion\")\n- **Noise** — labels for project management, CI, or bot-generated content (e.g.,\n  \"dependencies\", \"stale\", \"wontfix\", \"duplicate\", \"invalid\")\n\nDo NOT hardcode label names. Read the actual label names and descriptions, then\nuse judgment to classify them. Every repo is different — `git-branchless` has\n\"has workaround\" and \"answered\", another repo might have \"solved\" or \"recipe\".\n\n**Cache the assessment** in the `value-labels` frontmatter field, recording ONLY\nlabels classified High value. Each entry records the label name and a short\nreason why it's valuable. Step 5b fetches every issue carrying each cached\nlabel, so caching a Medium-value label such as `enhancement` turns a targeted\nfetch into a near-full enumeration; Medium and Noise are not recorded and drive\nno fetch. On subsequent runs, if `label-head` hasn't changed, reuse the cached\nassessment. If labels changed, re-assess and update the cache.\n\n## Steps\n\n1. **Resolve the repo** from `$ARGUMENTS` using the lookup table above, or parse\n   as `owner\u002Frepo` or full URL.\n\n2. **Check for incremental update** as described above. If up to date, skip.\n\n3. **Fetch the wiki** (if it exists):\n\n   ```bash\n   tmp_dir=$(mktemp -d \"${TMPDIR:-\u002Ftmp}\u002Fclaude-repo-index.XXXXXX\")\n   git clone --depth 1 \"https:\u002F\u002Fgithub.com\u002F${owner}\u002F${repo}.wiki.git\" \"$tmp_dir\u002Fwiki\" 2>\u002Fdev\u002Fnull || true\n   ```\n\n4. **Discover and fetch documentation**:\n\n   Documentation lives in different places across repos. Use a multi-pass\n   discovery approach and track what was found in `doc-sources` frontmatter.\n\n   #### 4a. Fetch README (always)\n\n   ```bash\n   gh api \"repos\u002F${owner}\u002F${repo}\u002Freadme\" --jq '.content | @base64d' > \"$tmp_dir\u002FREADME.md\"\n   ```\n\n   #### 4b. Scan repo tree for doc-like files\n\n   Fetch the repo tree and filter for documentation files. Don't hardcode\n   directory names — search broadly: First, get the default branch:\n\n   ```bash\n   default_branch=$(gh api \"repos\u002F${owner}\u002F${repo}\" --jq '.default_branch')\n   ```\n\n   ```bash\n   gh api \"repos\u002F${owner}\u002F${repo}\u002Fgit\u002Ftrees\u002F${default_branch}?recursive=1\" \\\n     --jq '.tree[] | select(.type==\"blob\") | .path' \\\n     | grep -iE '\\.(md|adoc|rst|txt)$' \\\n     | grep -iE '^(docs?\u002F|documentation\u002F|man\u002F|guide|readme|contributing|changelog|faq|usage|tutorial)' \\\n     > \"$tmp_dir\u002Fdoc-paths.txt\"\n   ```\n\n   Also catch top-level doc files that aren't README:\n\n   ```bash\n   gh api \"repos\u002F${owner}\u002F${repo}\u002Fgit\u002Ftrees\u002F${default_branch}?recursive=1\" \\\n     --jq '.tree[] | select(.type==\"blob\") | .path' \\\n     | grep -iE '^[^\u002F]*\\.(adoc|rst)$' \\\n     >> \"$tmp_dir\u002Fdoc-paths.txt\"\n   ```\n\n   Fetch each discovered file:\n\n   ```bash\n   while read -r doc_path; do\n     encoded=$(printf '%s' \"$doc_path\" | jq -sRr @uri)\n     gh api \"repos\u002F${owner}\u002F${repo}\u002Fcontents\u002F${encoded}\" --jq '.content | @base64d' \\\n       > \"$tmp_dir\u002Frepo-$(echo \"$doc_path\" | tr '\u002F' '-')\" 2>\u002Fdev\u002Fnull || true\n   done \u003C \"$tmp_dir\u002Fdoc-paths.txt\"\n   ```\n\n   #### 4c. Follow external documentation links\n\n   Scan the README and any fetched docs for links to external documentation\n   sites (readthedocs, GitHub Pages, gitbook, wiki URLs, etc.):\n\n   ```bash\n   grep -ohE 'https?:\u002F\u002F[^ )\">]+' \"$tmp_dir\"\u002F*.md \"$tmp_dir\"\u002F*.adoc 2>\u002Fdev\u002Fnull \\\n     | grep -iE '(readthedocs|gitbook|github\\.io|wiki|docs\\.)' \\\n     | sort -u > \"$tmp_dir\u002Fexternal-links.txt\"\n   ```\n\n   For each external link, fetch the page content if it's reachable and appears\n   to be documentation (HTML or markdown). Use `WebFetch` for HTML pages. Record\n   each in `doc-sources` with `type: external`.\n\n   #### 4d. Reconcile with previous doc-sources\n\n   If the existing frontmatter has `doc-sources`, compare:\n   - **New paths not in previous run** → fetch and flag as new discovery\n   - **Previous paths missing from tree** → mark `reachable: false`, keep the\n     entry but note it's gone (the content may still be relevant if the file was\n     moved or renamed)\n   - **Previous external URLs** → re-check reachability, update status\n   - **Prune** entries marked `reachable: false` for 3+ consecutive runs\n\n   The `doc-sources` list persists across runs as the \"memory\" of what\n   documentation exists for this repo. Each entry includes a `relevance` note\n   explaining why it matters — this helps future runs prioritize.\n\n5. **Discover and fetch issues\u002Fdiscussions** using multiple search signals.\n\n   The goal is a thorough sample of usage-relevant content — not just the\n   top 10. Fetch greedily, deduplicate, and only prompt the user if volume is\n   unmanageable.\n\n   #### 5a. Count total issues to determine strategy\n\n   Use the search API to get accurate issue counts (the REST issues endpoint and\n   `open_issues_count` both include pull requests):\n\n   ```bash\n   total_open=$(gh api \"search\u002Fissues?q=repo:${owner}\u002F${repo}+type:issue+state:open&per_page=1\" \\\n     --jq '.total_count')\n   total_closed=$(gh api \"search\u002Fissues?q=repo:${owner}\u002F${repo}+type:issue+state:closed&per_page=1\" \\\n     --jq '.total_count')\n   total_issues=$((total_open + total_closed))\n   ```\n\n   - **\u003C 500 total** (open + closed): Fetch all, paginating fully. Filter out\n     excludes during distillation.\n   - **500–2000**: Fetch all from value-label and keyword searches (below), plus\n     top 100 most-reacted. This gives broad coverage without full enumeration.\n   - **> 2000**: Prompt the user with the counts and ask how to proceed. Suggest\n     a strategy like: \"There are ~3400 issues. I can fetch all labeled\n     'answered'\u002F'has workaround' (~180), keyword matches (~250), and top 100\n     most-reacted. Or I can paginate through everything (~35 API calls). Which\n     do you prefer?\"\n\n   #### 5b. Label-based fetches\n\n   For each label in the cached `value-labels` list, fetch all matching issues:\n\n   ```bash\n   # Paginate to get all issues with this label, filtering out PRs\n   encoded_label=$(printf '%s' \"$label_name\" | jq -sRr @uri)\n   gh api \"repos\u002F${owner}\u002F${repo}\u002Fissues?labels=${encoded_label}&state=all&per_page=100${since_param}\" \\\n     --paginate --jq '.[] | select(has(\"pull_request\") | not) | \"## Issue #\\(.number): \\(.title)\\n\\(.body)\\n\"'\n   ```\n\n   #### 5c. Keyword searches\n\n   Search issues\u002Fdiscussions for usage-pattern keywords. These surface \"how do\n   I...?\" and \"can I...?\" questions that reveal practical workflows:\n\n   **Important:** `gh search issues` returns a JSON array per call. Pipe each\n   call through `jq` individually to emit JSONL — do NOT append raw arrays with\n   `>>` (creates invalid JSON when concatenated).\n\n   ```bash\n   keywords=(\"how\" \"can I\" \"workflow\" \"workaround\" \"example\" \"recipe\" \"pattern\")\n\n   for kw in \"${keywords[@]}\"; do\n     gh search issues \"${kw}\" --repo \"${owner}\u002F${repo}\" --sort reactions \\\n       --json number,title,body,labels,reactions --limit 50 2>\u002Fdev\u002Fnull \\\n       | jq -c '.[] | {number, title, body: (.body \u002F\u002F \"\" | .[0:2000]), labels: [.labels[].name]}' \\\n       >> \"$tmp_dir\u002Fkeyword-issues.jsonl\" 2>\u002Fdev\u002Fnull || true\n   done\n   ```\n\n   For repos with Discussions enabled, also search discussions:\n\n   ```bash\n   for kw in \"${keywords[@]}\"; do\n     gh api graphql -f query='\n       query {\n         search(query: \"repo:'\"${owner}\u002F${repo}\"' \\\"'\"${kw}\"'\\\" is:discussion\",\n                type: DISCUSSION, first: 50) {\n           nodes {\n             ... on Discussion {\n               number title body url\n               answer { body }\n               labels(first:10) { nodes { name } }\n             }\n           }\n         }\n       }' --jq '.data.search.nodes[] | @json' >> \"$tmp_dir\u002Fkeyword-discussions.jsonl\" 2>\u002Fdev\u002Fnull || true\n   done\n   ```\n\n   #### 5d. Reaction-sorted fallback\n\n   Also fetch top most-reacted issues as a catch-all for popular content that\n   keyword and label searches might miss:\n\n   ```bash\n   gh search issues --repo \"${owner}\u002F${repo}\" --sort reactions --order desc --state all \\\n     --limit 100 --json number,title,body,labels,reactions \\\n     --jq '.[] | {number, title, body: (.body \u002F\u002F \"\" | .[0:2000]), labels: [.labels[].name], reactions: .reactions.total_count}'\n   ```\n\n   #### 5e. Deduplicate and filter\n\n   Merge all fetched issues\u002Fdiscussions by number. Remove duplicates. Apply\n   `exclude-issue-patterns` to titles (case-insensitive). The final set is what\n   gets distilled into the reference doc.\n\n   For each issue\u002Fdiscussion, capture: number, title, body, labels, and reaction\n   count. Issues with answers (from Discussions) or resolution comments from\n   maintainers are especially valuable — note the resolution.\n\n6. **Extract Local Notes** from the existing reference doc (if it exists). Parse\n   all lines from the one that starts with `\u003C!-- BEGIN LOCAL NOTES` through the\n   one that starts with `\u003C!-- END LOCAL NOTES` (inclusive of those full marker\n   lines, which may include trailing text and the closing `-->`). Store this\n   block verbatim — it must be spliced back into the regenerated doc unchanged.\n\n7. **Read all fetched content** and distill into a reference doc with this\n   structure:\n\n   ```markdown\n   ---\n   repo: owner\u002Frepo\n   repo-head: \u003Csha>\n   repo-indexed: \u003Cdate>\n   wiki-head: \u003Csha or null>\n   wiki-indexed: \u003Cdate or null>\n   issues-indexed: \u003Cdate or null>\n   discussions-indexed: \u003Cdate or null>\n   labels-indexed: \u003Cdate>\n   label-head: \u003Csha256 of sorted label names>\n   doc-sources:\n     - path: \"\u003Crelative path in repo>\"\n       type: repo-file\n       relevance: \"\u003Cwhy this file matters>\"\n     - url: \"\u003Cexternal URL>\"\n       type: external\n       relevance: \"\u003Cwhy this link matters>\"\n       reachable: true\n   exclude-issue-patterns:\n     - \"renovate\"\n     - \"dependabot\"\n     - \"bump version\"\n     - \"release v\"\n   value-labels:\n     - name: \"\u003Clabel>\"\n       reason: \"\u003Cwhy this label surfaces useful content>\"\n   issue-stats:\n     total-fetched: \u003Cn>\n     from-labels: \u003Cn>\n     from-keywords: \u003Cn>\n     from-reactions: \u003Cn>\n     after-dedup: \u003Cn>\n   ---\n\n   # \u003CTool Name> Reference\n\n   Distilled from \u003Crepo URL>, updated \u003Cdate>.\n\n   ## Overview\n\n   \u003C1-2 paragraph summary of what the tool does and why>\n\n   ## Installation & Setup\n\n   \u003CHow to install, configure, prerequisites>\n\n   ## Core Concepts\n\n   \u003CKey mental models needed to use the tool effectively>\n\n   ## Command Reference\n\n   \u003CCommands with practical examples, grouped by workflow>\n\n   ## Recipes\n\n   \u003CConcrete step-by-step patterns for common tasks, written as numbered\n   procedures. These should be copy-pasteable workflows, not abstract\n   descriptions. Focus on:\n\n   - The happy path for each common operation\n   - How to recover from mistakes\n   - Integration with other tools (git-branchless + git-absorb, etc.)>\n\n   ## Anti-Patterns\n\n   \u003CCommon mistakes and what to do instead>\n\n   ## Integration\n\n   \u003CHow this tool works with the other stacked workflow tools>\n\n   \u003C!-- BEGIN LOCAL NOTES — preserved across regeneration -->\n\n   ## Local Notes\n\n   Hard-won lessons, workarounds, and patterns discovered through actual usage.\n   This section is never overwritten by index-repo-docs. Add entries here when\n   you solve a pain point or discover undocumented behavior.\n\n   \u003C!-- END LOCAL NOTES -->\n   ```\n\n8. **Write the draft to a temp file** — never directly to the reference doc.\n\n   ```bash\n   # e.g. ${tmp_dir}\u002Fdraft.md\n   ```\n\n9. **Present a change summary for user review.** Do NOT write the final doc\n   until the user approves. Show, in this order:\n   1. **Additions** — new sections, recipes, gotchas, anti-patterns\n   2. **Changes** — modified sections (briefly describe what changed)\n   3. **Removals** — any sections, recipes, or gotchas from the old doc that are\n      absent in the draft (flag these prominently — removals need justification)\n   4. **Stats** — line count old vs new, recipe count old vs new, issue-ref\n      (`#NNN`) count old vs new\n\n   If there are removals, explain why each one was dropped. The user may reject\n   the draft or ask for revisions. Only proceed to step 10 after explicit\n   approval.\n\n10. **Write the approved doc** to the reference file path.\n\n11. **Clean up**:\n\n    ```bash\n    rm -rf \"$tmp_dir\"\n    ```\n\n12. **Report** what was generated (full\u002Fincremental\u002Fskipped), how many source\n    files were read, and the output path.\n\n## Guidelines\n\n- Focus on PRACTICAL recipes over theoretical documentation\n- Every recipe should be a numbered procedure someone can follow\n- Include the exact commands, not just descriptions\n- Call out gotchas and edge cases from issues\u002Fdiscussions\n- Aim for under 500 lines — this is a reference, not a textbook. But never drop\n  existing content to hit the target. If a doc grows past 500 due to issue\n  insights, that's acceptable. Condense prose, not information.\n- If the wiki has workflow guides, prioritize those over API docs\n- Preserve and extend `exclude-issue-patterns` across runs — never shrink it\n- Preserve and extend `value-labels` across runs — only remove a label if it no\n  longer exists in the repo\n- Always re-check labels every run (they're cheap API calls), even if everything\n  else is up to date\n- When distilling issues, prioritize those with answers or maintainer responses\n  — these are confirmed patterns, not just questions\n- The `issue-stats` in frontmatter help the user understand coverage on future\n  runs — always keep them accurate\n- **Local Notes are sacred** — never modify, reorder, or omit content between\n  the marker lines that start with `\u003C!-- BEGIN LOCAL NOTES` and\n  `\u003C!-- END LOCAL NOTES` during regeneration. Extract before rewriting, then\n  splice the original block back verbatim.\n- When you solve a pain point or discover undocumented behavior for a tool that\n  has a reference doc, add it to that doc's Local Notes section. Format each\n  entry as a `### \u003Cshort title>` with the problem, solution, and context.\n- If a Local Notes entry is later confirmed by upstream docs (e.g., after a\n  re-index pulls it into a generated section), keep the local note too — it may\n  have context the upstream version lacks\n","Fetch documentation from a repository and distill it into a practical reference\ndoc with concrete recipes and patterns. The output goes to `references\u002F` in the\nrepo root.\n\n## Known Repos\n\nUse this lookup table to resolve short names to repos. If `$ARGUMENTS` doesn't\nmatch a known name, treat it as a GitHub URL or `owner\u002Frepo`.\n\n| Name             | Repo                     | Focus                                 |\n| ---------------- | ------------------------ | ------------------------------------- |\n| `git-branchless` | `arxanas\u002Fgit-branchless` | Wiki, README, key issues on workflows |\n| `git-absorb`     | `tummychow\u002Fgit-absorb`   | README, man page, usage patterns      |\n| `git-revise`     | `mystor\u002Fgit-revise`      | README, docs, interactive usage       |\n\nIf `$ARGUMENTS` is `all` or empty (no arguments), iterate through every entry in\nthe table above and run the full indexing process for each one, skipping repos\nthat are up to date.\n\n## Output\n\nWrite to: `references\u002F\u003Cname>.md` in the repo root.\n\n`\u003Cname>` is the short name from the lookup table or the repo name from the URL.\n\n## Incremental Updates\n\nThe generated reference doc includes frontmatter with per-source indexing\nmetadata. Each source tracks its own date so partial re-indexing is possible and\nso it's clear which sources have actually been fetched:\n\n```yaml\n---\nrepo: owner\u002Frepo\nrepo-head: \u003Ccommit-sha>\nrepo-indexed: 2026-03-21\nwiki-head: \u003Ccommit-sha or null>\nwiki-indexed: 2026-03-21\nissues-indexed: 2026-03-21 # null if never fetched\ndiscussions-indexed: 2026-03-21 # null if repo has no Discussions or never fetched\nlabels-indexed: 2026-03-21\nlabel-head: \u003Csha256 of sorted label name list>\ndoc-sources: # discovered doc files and external links\n  - path: \"Documentation\u002Fgit-absorb.adoc\"\n    type: repo-file\n    relevance: \"man page with authoritative flag\u002Foption reference\"\n  - path: \"docs\u002FARCHITECTURE.md\"\n    type: repo-file\n    relevance: \"internal design docs for understanding behavior\"\n  - url: \"https:\u002F\u002Fgit-branchless.readthedocs.io\u002F\"\n    type: external\n    relevance: \"official hosted documentation site\"\n    reachable: true\nexclude-issue-patterns:\n  - \"renovate\"\n  - \"dependabot\"\n  - \"bump version\"\nvalue-labels:\n  - name: \"answered\"\n    reason: \"confirmed solutions from maintainers\"\n  - name: \"has workaround\"\n    reason: \"practical alternatives users can follow\"\n---\n```\n\nA `null` date means that source has never been properly indexed — treat it as\nneeding a full fetch regardless of other source states.\n\nOn re-run:\n\n1. **Read the existing reference doc** (if it exists) and parse its frontmatter\n2. **Check remote HEADs** for both the repo and wiki:\n   ```bash\n   repo_head=$(gh api \"repos\u002F${owner}\u002F${repo}\u002Fcommits?per_page=1\" --jq '.[0].sha')\n   wiki_head=$(git ls-remote \"https:\u002F\u002Fgithub.com\u002F${owner}\u002F${repo}.wiki.git\" HEAD 2>\u002Fdev\u002Fnull | cut -f1 || echo \"\")\n   ```\n3. **Re-assess labels** (every run — see Label Discovery below). Compare the\n   computed `label-head` against frontmatter to detect label changes.\n4. **Compare each source independently:**\n   - `repo-head` changed → re-fetch README\u002Fdocs, re-discover doc tree, full\n     regeneration\n   - `wiki-head` changed → re-fetch wiki, full regeneration\n   - `issues-indexed` is null or new issues exist since that date → fetch issues\n   - `discussions-indexed` is null or new discussions since that date → fetch\n     discussions\n   - `label-head` changed → re-assess labels, may trigger issue re-fetch\n   - `doc-sources` entries with `reachable: false` → re-check, prune if stale 3+\n     runs\n   - `doc-sources` external URLs → spot-check reachability on full regeneration\n5. **Check for new issues** updated since `issues-indexed`:\n   ```bash\n   gh api \"search\u002Fissues?q=repo:${owner}\u002F${repo}+type:issue+updated:>=${issues_indexed}T00:00:00Z&per_page=1\" \\\n     --jq '.total_count'\n   ```\n6. **Check for new discussions** (if enabled) since `discussions-indexed`\n7. If ALL sources are up to date, report \"already up to date\" and skip\n8. Otherwise, fetch only the stale sources and **merge** insights into the\n   existing doc. Only do a **full regeneration** if `repo-head` or `wiki-head`\n   changed (the prose\u002Fstructure source material changed). When only\n   `issues-indexed` or `discussions-indexed` is stale, the existing doc text is\n   the baseline — add new gotchas, recipes, and anti-patterns from issues\n   without rewriting or condensing existing sections. Never drop existing\n   content to make room; the 500-line limit applies to the final result, so if\n   the doc is already near the limit, integrate only the highest-value issue\n   insights.\n\n### Exclude Patterns\n\nThe `exclude-issue-patterns` list in frontmatter filters out noise from\nissues\u002Fdiscussions. On the first run, initialize it with common bot patterns:\n`renovate`, `dependabot`, `bump version`, `release v`.\n\nDuring indexing, if an issue title matches any pattern (case-insensitive), skip\nit. If you encounter a new category of noise issues during distillation, add the\npattern to `exclude-issue-patterns` for future runs.\n\n### Label Discovery\n\nEvery repo has different labels. Instead of hardcoding which labels matter,\ndiscover and assess them dynamically.\n\n**Fetch all labels** (runs every time, even on incremental updates):\n\n```bash\ngh api \"repos\u002F${owner}\u002F${repo}\u002Flabels\" --paginate \\\n  --jq '.[] | \"\\(.name)\\t\\(.description \u002F\u002F \"\")\\t\\(.color)\"'\n```\n\n**Compute `label-head`** — a hash of sorted label names to detect changes:\n\n```bash\nlabel_head=$(gh api \"repos\u002F${owner}\u002F${repo}\u002Flabels\" --paginate \\\n  --jq '[.[].name] | sort | join(\"\\n\")' | sha256sum | cut -d' ' -f1)\n```\n\n**Assess which labels have value** by classifying each into one of:\n\n- **High value** — labels indicating resolved questions, workarounds, recipes,\n  or confirmed patterns (e.g., \"answered\", \"has workaround\", \"good first issue\",\n  \"question\", \"howto\", \"cookbook\", \"workflow\", \"solved\")\n- **Medium value** — labels indicating feature discussions or design decisions\n  that reveal capabilities (e.g., \"enhancement\", \"feature request\", \"rfc\",\n  \"design\", \"discussion\")\n- **Noise** — labels for project management, CI, or bot-generated content (e.g.,\n  \"dependencies\", \"stale\", \"wontfix\", \"duplicate\", \"invalid\")\n\nDo NOT hardcode label names. Read the actual label names and descriptions, then\nuse judgment to classify them. Every repo is different — `git-branchless` has\n\"has workaround\" and \"answered\", another repo might have \"solved\" or \"recipe\".\n\n**Cache the assessment** in the `value-labels` frontmatter field, recording ONLY\nlabels classified High value. Each entry records the label name and a short\nreason why it's valuable. Step 5b fetches every issue carrying each cached\nlabel, so caching a Medium-value label such as `enhancement` turns a targeted\nfetch into a near-full enumeration; Medium and Noise are not recorded and drive\nno fetch. On subsequent runs, if `label-head` hasn't changed, reuse the cached\nassessment. If labels changed, re-assess and update the cache.\n\n## Steps\n\n1. **Resolve the repo** from `$ARGUMENTS` using the lookup table above, or parse\n   as `owner\u002Frepo` or full URL.\n\n2. **Check for incremental update** as described above. If up to date, skip.\n\n3. **Fetch the wiki** (if it exists):\n\n   ```bash\n   tmp_dir=$(mktemp -d \"${TMPDIR:-\u002Ftmp}\u002Fclaude-repo-index.XXXXXX\")\n   git clone --depth 1 \"https:\u002F\u002Fgithub.com\u002F${owner}\u002F${repo}.wiki.git\" \"$tmp_dir\u002Fwiki\" 2>\u002Fdev\u002Fnull || true\n   ```\n\n4. **Discover and fetch documentation**:\n\n   Documentation lives in different places across repos. Use a multi-pass\n   discovery approach and track what was found in `doc-sources` frontmatter.\n\n   #### 4a. Fetch README (always)\n\n   ```bash\n   gh api \"repos\u002F${owner}\u002F${repo}\u002Freadme\" --jq '.content | @base64d' > \"$tmp_dir\u002FREADME.md\"\n   ```\n\n   #### 4b. Scan repo tree for doc-like files\n\n   Fetch the repo tree and filter for documentation files. Don't hardcode\n   directory names — search broadly: First, get the default branch:\n\n   ```bash\n   default_branch=$(gh api \"repos\u002F${owner}\u002F${repo}\" --jq '.default_branch')\n   ```\n\n   ```bash\n   gh api \"repos\u002F${owner}\u002F${repo}\u002Fgit\u002Ftrees\u002F${default_branch}?recursive=1\" \\\n     --jq '.tree[] | select(.type==\"blob\") | .path' \\\n     | grep -iE '\\.(md|adoc|rst|txt)$' \\\n     | grep -iE '^(docs?\u002F|documentation\u002F|man\u002F|guide|readme|contributing|changelog|faq|usage|tutorial)' \\\n     > \"$tmp_dir\u002Fdoc-paths.txt\"\n   ```\n\n   Also catch top-level doc files that aren't README:\n\n   ```bash\n   gh api \"repos\u002F${owner}\u002F${repo}\u002Fgit\u002Ftrees\u002F${default_branch}?recursive=1\" \\\n     --jq '.tree[] | select(.type==\"blob\") | .path' \\\n     | grep -iE '^[^\u002F]*\\.(adoc|rst)$' \\\n     >> \"$tmp_dir\u002Fdoc-paths.txt\"\n   ```\n\n   Fetch each discovered file:\n\n   ```bash\n   while read -r doc_path; do\n     encoded=$(printf '%s' \"$doc_path\" | jq -sRr @uri)\n     gh api \"repos\u002F${owner}\u002F${repo}\u002Fcontents\u002F${encoded}\" --jq '.content | @base64d' \\\n       > \"$tmp_dir\u002Frepo-$(echo \"$doc_path\" | tr '\u002F' '-')\" 2>\u002Fdev\u002Fnull || true\n   done \u003C \"$tmp_dir\u002Fdoc-paths.txt\"\n   ```\n\n   #### 4c. Follow external documentation links\n\n   Scan the README and any fetched docs for links to external documentation\n   sites (readthedocs, GitHub Pages, gitbook, wiki URLs, etc.):\n\n   ```bash\n   grep -ohE 'https?:\u002F\u002F[^ )\">]+' \"$tmp_dir\"\u002F*.md \"$tmp_dir\"\u002F*.adoc 2>\u002Fdev\u002Fnull \\\n     | grep -iE '(readthedocs|gitbook|github\\.io|wiki|docs\\.)' \\\n     | sort -u > \"$tmp_dir\u002Fexternal-links.txt\"\n   ```\n\n   For each external link, fetch the page content if it's reachable and appears\n   to be documentation (HTML or markdown). Use `WebFetch` for HTML pages. Record\n   each in `doc-sources` with `type: external`.\n\n   #### 4d. Reconcile with previous doc-sources\n\n   If the existing frontmatter has `doc-sources`, compare:\n   - **New paths not in previous run** → fetch and flag as new discovery\n   - **Previous paths missing from tree** → mark `reachable: false`, keep the\n     entry but note it's gone (the content may still be relevant if the file was\n     moved or renamed)\n   - **Previous external URLs** → re-check reachability, update status\n   - **Prune** entries marked `reachable: false` for 3+ consecutive runs\n\n   The `doc-sources` list persists across runs as the \"memory\" of what\n   documentation exists for this repo. Each entry includes a `relevance` note\n   explaining why it matters — this helps future runs prioritize.\n\n5. **Discover and fetch issues\u002Fdiscussions** using multiple search signals.\n\n   The goal is a thorough sample of usage-relevant content — not just the\n   top 10. Fetch greedily, deduplicate, and only prompt the user if volume is\n   unmanageable.\n\n   #### 5a. Count total issues to determine strategy\n\n   Use the search API to get accurate issue counts (the REST issues endpoint and\n   `open_issues_count` both include pull requests):\n\n   ```bash\n   total_open=$(gh api \"search\u002Fissues?q=repo:${owner}\u002F${repo}+type:issue+state:open&per_page=1\" \\\n     --jq '.total_count')\n   total_closed=$(gh api \"search\u002Fissues?q=repo:${owner}\u002F${repo}+type:issue+state:closed&per_page=1\" \\\n     --jq '.total_count')\n   total_issues=$((total_open + total_closed))\n   ```\n\n   - **\u003C 500 total** (open + closed): Fetch all, paginating fully. Filter out\n     excludes during distillation.\n   - **500–2000**: Fetch all from value-label and keyword searches (below), plus\n     top 100 most-reacted. This gives broad coverage without full enumeration.\n   - **> 2000**: Prompt the user with the counts and ask how to proceed. Suggest\n     a strategy like: \"There are ~3400 issues. I can fetch all labeled\n     'answered'\u002F'has workaround' (~180), keyword matches (~250), and top 100\n     most-reacted. Or I can paginate through everything (~35 API calls). Which\n     do you prefer?\"\n\n   #### 5b. Label-based fetches\n\n   For each label in the cached `value-labels` list, fetch all matching issues:\n\n   ```bash\n   # Paginate to get all issues with this label, filtering out PRs\n   encoded_label=$(printf '%s' \"$label_name\" | jq -sRr @uri)\n   gh api \"repos\u002F${owner}\u002F${repo}\u002Fissues?labels=${encoded_label}&state=all&per_page=100${since_param}\" \\\n     --paginate --jq '.[] | select(has(\"pull_request\") | not) | \"## Issue #\\(.number): \\(.title)\\n\\(.body)\\n\"'\n   ```\n\n   #### 5c. Keyword searches\n\n   Search issues\u002Fdiscussions for usage-pattern keywords. These surface \"how do\n   I...?\" and \"can I...?\" questions that reveal practical workflows:\n\n   **Important:** `gh search issues` returns a JSON array per call. Pipe each\n   call through `jq` individually to emit JSONL — do NOT append raw arrays with\n   `>>` (creates invalid JSON when concatenated).\n\n   ```bash\n   keywords=(\"how\" \"can I\" \"workflow\" \"workaround\" \"example\" \"recipe\" \"pattern\")\n\n   for kw in \"${keywords[@]}\"; do\n     gh search issues \"${kw}\" --repo \"${owner}\u002F${repo}\" --sort reactions \\\n       --json number,title,body,labels,reactions --limit 50 2>\u002Fdev\u002Fnull \\\n       | jq -c '.[] | {number, title, body: (.body \u002F\u002F \"\" | .[0:2000]), labels: [.labels[].name]}' \\\n       >> \"$tmp_dir\u002Fkeyword-issues.jsonl\" 2>\u002Fdev\u002Fnull || true\n   done\n   ```\n\n   For repos with Discussions enabled, also search discussions:\n\n   ```bash\n   for kw in \"${keywords[@]}\"; do\n     gh api graphql -f query='\n       query {\n         search(query: \"repo:'\"${owner}\u002F${repo}\"' \\\"'\"${kw}\"'\\\" is:discussion\",\n                type: DISCUSSION, first: 50) {\n           nodes {\n             ... on Discussion {\n               number title body url\n               answer { body }\n               labels(first:10) { nodes { name } }\n             }\n           }\n         }\n       }' --jq '.data.search.nodes[] | @json' >> \"$tmp_dir\u002Fkeyword-discussions.jsonl\" 2>\u002Fdev\u002Fnull || true\n   done\n   ```\n\n   #### 5d. Reaction-sorted fallback\n\n   Also fetch top most-reacted issues as a catch-all for popular content that\n   keyword and label searches might miss:\n\n   ```bash\n   gh search issues --repo \"${owner}\u002F${repo}\" --sort reactions --order desc --state all \\\n     --limit 100 --json number,title,body,labels,reactions \\\n     --jq '.[] | {number, title, body: (.body \u002F\u002F \"\" | .[0:2000]), labels: [.labels[].name], reactions: .reactions.total_count}'\n   ```\n\n   #### 5e. Deduplicate and filter\n\n   Merge all fetched issues\u002Fdiscussions by number. Remove duplicates. Apply\n   `exclude-issue-patterns` to titles (case-insensitive). The final set is what\n   gets distilled into the reference doc.\n\n   For each issue\u002Fdiscussion, capture: number, title, body, labels, and reaction\n   count. Issues with answers (from Discussions) or resolution comments from\n   maintainers are especially valuable — note the resolution.\n\n6. **Extract Local Notes** from the existing reference doc (if it exists). Parse\n   all lines from the one that starts with `\u003C!-- BEGIN LOCAL NOTES` through the\n   one that starts with `\u003C!-- END LOCAL NOTES` (inclusive of those full marker\n   lines, which may include trailing text and the closing `-->`). Store this\n   block verbatim — it must be spliced back into the regenerated doc unchanged.\n\n7. **Read all fetched content** and distill into a reference doc with this\n   structure:\n\n   ```markdown\n   ---\n   repo: owner\u002Frepo\n   repo-head: \u003Csha>\n   repo-indexed: \u003Cdate>\n   wiki-head: \u003Csha or null>\n   wiki-indexed: \u003Cdate or null>\n   issues-indexed: \u003Cdate or null>\n   discussions-indexed: \u003Cdate or null>\n   labels-indexed: \u003Cdate>\n   label-head: \u003Csha256 of sorted label names>\n   doc-sources:\n     - path: \"\u003Crelative path in repo>\"\n       type: repo-file\n       relevance: \"\u003Cwhy this file matters>\"\n     - url: \"\u003Cexternal URL>\"\n       type: external\n       relevance: \"\u003Cwhy this link matters>\"\n       reachable: true\n   exclude-issue-patterns:\n     - \"renovate\"\n     - \"dependabot\"\n     - \"bump version\"\n     - \"release v\"\n   value-labels:\n     - name: \"\u003Clabel>\"\n       reason: \"\u003Cwhy this label surfaces useful content>\"\n   issue-stats:\n     total-fetched: \u003Cn>\n     from-labels: \u003Cn>\n     from-keywords: \u003Cn>\n     from-reactions: \u003Cn>\n     after-dedup: \u003Cn>\n   ---\n\n   # \u003CTool Name> Reference\n\n   Distilled from \u003Crepo URL>, updated \u003Cdate>.\n\n   ## Overview\n\n   \u003C1-2 paragraph summary of what the tool does and why>\n\n   ## Installation & Setup\n\n   \u003CHow to install, configure, prerequisites>\n\n   ## Core Concepts\n\n   \u003CKey mental models needed to use the tool effectively>\n\n   ## Command Reference\n\n   \u003CCommands with practical examples, grouped by workflow>\n\n   ## Recipes\n\n   \u003CConcrete step-by-step patterns for common tasks, written as numbered\n   procedures. These should be copy-pasteable workflows, not abstract\n   descriptions. Focus on:\n\n   - The happy path for each common operation\n   - How to recover from mistakes\n   - Integration with other tools (git-branchless + git-absorb, etc.)>\n\n   ## Anti-Patterns\n\n   \u003CCommon mistakes and what to do instead>\n\n   ## Integration\n\n   \u003CHow this tool works with the other stacked workflow tools>\n\n   \u003C!-- BEGIN LOCAL NOTES — preserved across regeneration -->\n\n   ## Local Notes\n\n   Hard-won lessons, workarounds, and patterns discovered through actual usage.\n   This section is never overwritten by index-repo-docs. Add entries here when\n   you solve a pain point or discover undocumented behavior.\n\n   \u003C!-- END LOCAL NOTES -->\n   ```\n\n8. **Write the draft to a temp file** — never directly to the reference doc.\n\n   ```bash\n   # e.g. ${tmp_dir}\u002Fdraft.md\n   ```\n\n9. **Present a change summary for user review.** Do NOT write the final doc\n   until the user approves. Show, in this order:\n   1. **Additions** — new sections, recipes, gotchas, anti-patterns\n   2. **Changes** — modified sections (briefly describe what changed)\n   3. **Removals** — any sections, recipes, or gotchas from the old doc that are\n      absent in the draft (flag these prominently — removals need justification)\n   4. **Stats** — line count old vs new, recipe count old vs new, issue-ref\n      (`#NNN`) count old vs new\n\n   If there are removals, explain why each one was dropped. The user may reject\n   the draft or ask for revisions. Only proceed to step 10 after explicit\n   approval.\n\n10. **Write the approved doc** to the reference file path.\n\n11. **Clean up**:\n\n    ```bash\n    rm -rf \"$tmp_dir\"\n    ```\n\n12. **Report** what was generated (full\u002Fincremental\u002Fskipped), how many source\n    files were read, and the output path.\n\n## Guidelines\n\n- Focus on PRACTICAL recipes over theoretical documentation\n- Every recipe should be a numbered procedure someone can follow\n- Include the exact commands, not just descriptions\n- Call out gotchas and edge cases from issues\u002Fdiscussions\n- Aim for under 500 lines — this is a reference, not a textbook. But never drop\n  existing content to hit the target. If a doc grows past 500 due to issue\n  insights, that's acceptable. Condense prose, not information.\n- If the wiki has workflow guides, prioritize those over API docs\n- Preserve and extend `exclude-issue-patterns` across runs — never shrink it\n- Preserve and extend `value-labels` across runs — only remove a label if it no\n  longer exists in the repo\n- Always re-check labels every run (they're cheap API calls), even if everything\n  else is up to date\n- When distilling issues, prioritize those with answers or maintainer responses\n  — these are confirmed patterns, not just questions\n- The `issue-stats` in frontmatter help the user understand coverage on future\n  runs — always keep them accurate\n- **Local Notes are sacred** — never modify, reorder, or omit content between\n  the marker lines that start with `\u003C!-- BEGIN LOCAL NOTES` and\n  `\u003C!-- END LOCAL NOTES` during regeneration. Extract before rewriting, then\n  splice the original block back verbatim.\n- When you solve a pain point or discover undocumented behavior for a tool that\n  has a reference doc, add it to that doc's Local Notes section. Format each\n  entry as a `### \u003Cshort title>` with the problem, solution, and context.\n- If a Local Notes entry is later confirmed by upstream docs (e.g., after a\n  re-index pulls it into a generated section), keep the local note too — it may\n  have context the upstream version lacks\n",{"name":5,"description":7,"argument-hint":42,"disable-model-invocation":38},"\u003Cname-or-url|all> (e.g. git-branchless, git-absorb, all)","main","a33b4e70efef03fe75378fad9c847b73ea142c46","dev\u002Fskills\u002Findex-repo-docs",0,"https:\u002F\u002Fgithub.com\u002Fhigherorderfunctor\u002Fnix-agentic-tools","https:\u002F\u002Fgithub.com\u002Fhigherorderfunctor","2026-11-13 03:39:17",{"source":8,"skillName":5,"commands":51,"prompt":61,"zipAvailable":62},[52,55,58],{"tool":53,"command":54},"npx","npx skills add higherorderfunctor\u002Fnix-agentic-tools --skill index-repo-docs",{"tool":56,"command":57},"bunx","bunx skills add higherorderfunctor\u002Fnix-agentic-tools --skill index-repo-docs",{"tool":59,"command":60},"pnpm","pnpm dlx skills add higherorderfunctor\u002Fnix-agentic-tools --skill index-repo-docs","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fhigherorderfunctor\u002Fnix-agentic-tools\u002Fblob\u002Fmain\u002Fdev\u002Fskills\u002Findex-repo-docs\u002FSKILL.md",true,[],[65,94,120,139,158,173],{"skillNo":66,"name":67,"nameZh":6,"description":68,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":69,"categories":70,"keywords":76,"publishedAt":37},"01M6MQXHSDNFXSN7TT5FFWPF3X","stack-test","Use when you need to run tests or formatters across commits in a stack. Use INSTEAD of manual git test run or looping git checkout + test. Prevents: testing every commit when only the tip has to pass, unbounded parallel jobs exhausting memory, cache misunderstandings.","https:\u002F\u002Fgithub.com\u002Fhigherorderfunctor\u002Fnix-agentic-tools\u002Fblob\u002Fmain\u002Fpackages\u002Fstacked-workflows\u002Fskills\u002Fstack-test\u002FSKILL.md",[71],{"categoryNo":72,"categoryName":73,"taxonomyType":74,"taxonomyTypeDesc":75},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[77,78,79,80,81,82,83,84,85,86,87,88,89,24,29,26,90,91,92,93,25],"test","stack","stack test","parallel","TIP","checkout","commits","memory","manual","testing","fix","tests","only","cache","commit","across","command",{"skillNo":95,"name":96,"nameZh":6,"description":97,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":98,"categories":99,"keywords":100,"publishedAt":37},"01M6MQXAXVWG1RY9H2116G4SVX","stack-summary","Use when you need to audit, analyze, or review stack quality before restructuring. Produces a structured summary with per-commit classification, philosophy audit, and violation flags. Output feeds directly into \u002Fstack-plan restructure mode. Use INSTEAD of manual git log inspection.","https:\u002F\u002Fgithub.com\u002Fhigherorderfunctor\u002Fnix-agentic-tools\u002Fblob\u002Fmain\u002Fpackages\u002Fstacked-workflows\u002Fskills\u002Fstack-summary\u002FSKILL.md",[],[78,101,102,103,104,105,85,106,107,24,29,26,108,91,109,110,111,112,113,114,115,25,116,117,118,119,34],"stack summary","summary","feeds","review stack","for","mode","classification","git log","log","review","output","analyze","with","philosophy","inspection","plan","worktree","audit","flags",{"skillNo":121,"name":122,"nameZh":6,"description":123,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":124,"categories":125,"keywords":126,"publishedAt":37},"01M6MQX62HMQR5CSN4FSC95ZJC","stack-submit","Use when you need to push, submit, or create pull requests for a commit stack. Rebases only the current stack onto upstream main, validates, and pushes INSTEAD of manual git sync + git submit + PR\u002FMR creation. Handles branch creation, stacked PR\u002FMR creation with correct base branches.","https:\u002F\u002Fgithub.com\u002Fhigherorderfunctor\u002Fnix-agentic-tools\u002Fblob\u002Fmain\u002Fpackages\u002Fstacked-workflows\u002Fskills\u002Fstack-submit\u002FSKILL.md",[],[127,78,128,129,130,131,132,133,105,85,134,135,136,89,43,24,29,137,138,25],"submit","stack submit","pull","branch","push","pr","creation","correct","upstream","branches","git sync","mr",{"skillNo":140,"name":141,"nameZh":6,"description":142,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":143,"categories":144,"keywords":145,"publishedAt":37},"01M6MQX2BNQ4MAV9KCV0RZ734G","stack-split","Use when you need to break up, split, or decompose a large commit into smaller atomic commits. Use INSTEAD of manual git rebase -i + edit or git reset HEAD^. Prevents: non-working intermediate commits, wrong split ordering, missed downstream restack.","https:\u002F\u002Fgithub.com\u002Fhigherorderfunctor\u002Fnix-agentic-tools\u002Fblob\u002Fmain\u002Fpackages\u002Fstacked-workflows\u002Fskills\u002Fstack-split\u002FSKILL.md",[],[146,78,147,148,83,85,149,24,29,150,26,91,151,152,153,154,155,156,34,157,25],"split","stack split","decompose","up","atomic commits","reset","head","missed","break","atomic","edit","rebase",{"skillNo":159,"name":160,"nameZh":6,"description":161,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":162,"categories":163,"keywords":164,"publishedAt":37},"01M6MQWWM5P7FVQSF7EWHJ70C6","stack-plan","Use when you need to plan commits, restructure a stack, or commit uncommitted work as organized atomic commits. Builds a stack from a description, uncommitted work, or existing commits INSTEAD of dumping everything into one monolithic commit with git add -A && git commit, or manual git rebase -i, git reset --soft, or ad-hoc git move sequences. Prevents: wrong commit ordering, forward references, git move -F panics, untested intermediates.","https:\u002F\u002Fgithub.com\u002Fhigherorderfunctor\u002Fnix-agentic-tools\u002Fblob\u002Fmain\u002Fpackages\u002Fstacked-workflows\u002Fskills\u002Fstack-plan\u002FSKILL.md",[],[78,116,165,166,167,83,105,168,85,169,24,170,29,150,26,91,171,151,113,172,25],"stack plan","tree","as","move","git commit","Existing","git move","references",{"skillNo":174,"name":175,"nameZh":6,"description":176,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":177,"categories":178,"keywords":179,"publishedAt":37},"01M6MQWP7CKTM5NF72MED1H8NS","stack-fix","Use when you need to fix, correct, or update content in an earlier commit — line-level edits, content moves, or structural changes. Absorbs staged changes into correct stack commits INSTEAD of running git absorb or git commit --fixup via Bash, or hand-running git prev + edit + git amend + git restack --merge. Prevents: missed dry-run preview, leftover staged changes going unnoticed, forgetting to restack. Falls back to guided manual amend when absorb cannot route hunks.","https:\u002F\u002Fgithub.com\u002Fhigherorderfunctor\u002Fnix-agentic-tools\u002Fblob\u002Fmain\u002Fpackages\u002Fstacked-workflows\u002Fskills\u002Fstack-fix\u002FSKILL.md",[],[87,78,180,181,83,85,134,182,169,24,29,26,183,184,91,185,186,187,188,25],"stack fix","back","structural","Bash","preview","hand","dry","route","running"]