[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6KKVWQC5725PCXXAMNNEWVG":3,"skill-same:01M6KKVWQC5725PCXXAMNNEWVG":86},{"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":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":59,"commitSha":60,"skillDirectory":61,"forksCount":62,"repositoryHtmlUrl":63,"repositoryHomepageUrl":6,"ownerHtmlUrl":64,"ownerBlogUrl":6,"ownerDescription":65,"updatedAt":66,"install":67,"resources":79},"01M6KKVWQC5725PCXXAMNNEWVG","ns-flow-gs-autoslot",null,"Experimentally move dirty work onto a github\u002Fgh-stack child, checkpoint it, then move the child into an ns Slot through the explicit `\u002Fns:flow:gs:autoslot` Skill-Backed Command.","nseng-ai\u002Fns","nseng-ai","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F273792438?v=4","01M6KKN105A07WPV2TZKZXZGQF","nseng.ai","01M6KKN14MDSR9VF9739AWXG8M",2,"MIT","https:\u002F\u002Fgithub.com\u002Fnseng-ai\u002Fns\u002Fblob\u002Fmaster\u002Fskills\u002Fincubating\u002Fflow\u002Fns-flow-gs-autoslot\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"ns flow gs autoslot","flow","view","ns flow cp","child","move","add","checkout","origin","show","switch","init","command","short","branch","work","stack","Bash","git","status","2026-11-10 10:12:30",false,"---\nname: ns-flow-gs-autoslot\ndisable-model-invocation: true\ndescription: \"Experimentally move dirty work onto a github\u002Fgh-stack child, checkpoint it, then move the child into an ns Slot through the explicit `\u002Fns:flow:gs:autoslot` Skill-Backed Command.\"\nallowed-tools:\n  - \"Bash(git status --porcelain=v1*)\"\n  - \"Bash(git symbolic-ref --quiet --short HEAD)\"\n  - \"Bash(git symbolic-ref --quiet --short refs\u002Fremotes\u002Forigin\u002FHEAD)\"\n  - \"Bash(git rev-parse --verify*)\"\n  - \"Bash(git show-ref --verify --quiet*)\"\n  - \"Bash(git check-ref-format --branch*)\"\n  - \"Bash(git switch -c*)\"\n  - \"Bash(gh stack --version)\"\n  - \"Bash(gh stack view --json)\"\n  - \"Bash(gh stack add*)\"\n  - \"Bash(gh stack init*)\"\n  - \"Bash(ns flow cp*)\"\n  - \"Bash(ns slot checkout --current)\"\n---\n\n# ns-flow-gs-autoslot\n\nExperimental dirty-work autoslot for the official `github\u002Fgh-stack` provider (`gs`). Invocation explicitly selects GS and authorizes the scoped local mutations below. This skill contains the complete autobranch procedure; do not invoke, delegate to, or assume execution of `\u002Fns:flow:gs:autobranch`. Only after that procedure has verified provider state, created a durable checkpoint, and proved a clean worktree does it compose `ns slot checkout --current`. This workflow can create a branch and commit, change gh-stack metadata, and move the child into a managed Slot. It does **not** delegate to an `ns flow gs` CLI.\n\n## Scope and hard boundaries\n\nSupport exactly two paths:\n\n1. dirty Git trunk → ordinary child → durable checkpoint → initialize that child as the first gh-stack branch → managed Slot checkout;\n2. dirty non-trunk already tracked as the current stack top → native `gh stack add` child → durable checkpoint → managed Slot checkout.\n\nNever extract the latest commit, initialize an existing non-trunk branch, access `.git\u002Fgh-stack`, fetch, push, submit, retry, roll back, delete a branch, run `gh stack unstack`, or attempt a Slot checkout before the branch\u002Fprovider\u002Fcheckpoint postconditions are proven. Do not describe this prompt-driven workflow as atomic or transactional. Refuse before mutation unless every applicable preflight check passes.\n\n## Common preflight\n\n1. Run `gh stack --version`; require exit status zero and output that reports version `0.1.0`. Refuse before any mutation on command failure, a missing version, version drift, or help output.\n2. Run bounded probes and retain their exact facts:\n   - `git symbolic-ref --quiet --short HEAD` for the attached current branch; refuse detached HEAD.\n   - `git rev-parse --verify HEAD` for the source SHA.\n   - `git status --porcelain=v1 --untracked-files=all` for staged, unstaged, and untracked work; refuse empty output.\n   - `git symbolic-ref --quiet --short refs\u002Fremotes\u002Forigin\u002FHEAD`; refuse if missing, then remove the `origin\u002F` prefix from its short output to obtain cached Git trunk.\n3. Accept an explicit child slug from the initial request or derive one semantic, conservative slug from the pending change. Validate it with `git check-ref-format --branch \u003Cchild>`. Refuse invalid names.\n4. Require `git show-ref --verify --quiet refs\u002Fheads\u002F\u003Cchild>` to report absence. Refuse an existing child ref.\n5. Classify only by current branch versus cached trunk. Invocation is the provider selection; never infer provider choice from metadata.\n6. Before the first mutation, show the user: path, source\u002Ftrunk SHA, concise dirty-status summary, child name, intended commands including the final conditional Slot checkout, and the forward-only failure boundary.\n\nA clean invocation is refused. If the user selected Graphite, direct them to `\u002Fns:flow:gt:autoslot` for ordinary autoslot behavior or `\u002Fns:flow:gt:branch-latest-commit` for latest-commit extraction; do not offer or simulate GS latest-commit extraction.\n\n## Path A: dirty trunk bootstrap\n\n1. Record trunk SHA and porcelain status. Run `git switch -c \u003Cchild>`.\n2. Re-probe current branch, `refs\u002Fheads\u002F\u003Ctrunk>`, `refs\u002Fheads\u002F\u003Cchild>`, and porcelain status. Continue only when the child is current, trunk and child both equal the recorded source SHA, and dirty work remains observable. Otherwise inspect and stop without cleanup.\n3. Run `ns flow cp`. Verify the child advanced, trunk did not, and `git status --porcelain=v1 --untracked-files=all` is empty. If checkpointing fails or cleanliness is unproven, preserve and report the dirty or ambiguously checkpointed child; do not initialize or run Slots.\n4. Only after that durable clean checkpoint, run `gh stack init \u003Cchild>`.\n5. Run `gh stack view --json`. Require valid JSON with expected `trunk`, `currentBranch === \u003Cchild>`, and exactly one matching current child in `branches`. If init fails or the view is malformed\u002Finconsistent, preserve the committed child and stop. Do not move work back, delete anything, or run Slots.\n6. Re-probe the child SHA and clean porcelain status. Continue only if the verified provider child remains current at the checkpoint SHA and the worktree remains clean.\n7. Run exactly `ns slot checkout --current` and observe its exit status and bounded output. On success, report the returned Slot name, worktree path, checked-out branch, and navigation instruction when present; distinguish the original worktree from the destination. Do not infer absent facts. On failure, preserve the committed provider child and report a partial failure without undoing it.\n\n## Path B: dirty tracked-top extension\n\n1. Before mutation run `gh stack view --json`. Require valid JSON with `trunk`, `currentBranch`, and ordered `branches` records containing `name`, `base`, and `isCurrent`.\n2. Require the current Git branch to occur exactly once, be marked current, equal provider `currentBranch`, and be the last\u002Ftopmost branch. Refuse an untracked non-trunk or tracked non-top branch; report the observed top. Never initialize either state.\n3. Record source SHA and porcelain status, then run exactly `gh stack add \u003Cchild>` without `-A`, `-u`, or `-m`.\n4. Regardless of exit status, re-probe current branch, source ref SHA, child ref SHA, porcelain status, and `gh stack view --json`. Continue only if observations prove: source unchanged; child exists at the recorded source SHA; child is current; source and child are adjacent in the ordered provider branch list with the child directly above source and topmost; dirty work remains observable on the child.\n5. If the command rejected the work or any fact is absent or ambiguous, stop. Do not retry, initialize, delete, unstack, edit metadata, improvise rollback, or run Slots.\n6. On verified attachment run `ns flow cp`. Verify child advanced, source did not, and `git status --porcelain=v1 --untracked-files=all` is empty. If checkpointing fails or cleanliness is unproven, preserve and report the attached dirty or ambiguously checkpointed child; do not run Slots.\n7. Re-run `gh stack view --json` and re-probe current branch, source and child SHAs, and porcelain status. Require the same direct topmost provider relationship, the source unchanged, the child at the durable checkpoint SHA, and a clean worktree.\n8. Run exactly `ns slot checkout --current` and observe its exit status and bounded output. On success, report the returned Slot name, worktree path, checked-out branch, and navigation instruction when present; distinguish the original worktree from the destination. Do not infer absent facts. On failure, preserve the committed attached child and report a partial failure without undoing it.\n\n## Invocation report and lesson feedback\n\nAfter **every** outcome, proactively give one terminal report with exactly these eight labeled fields:\n\n1. **Outcome:** `refused`, `completed`, `partial failure`, or `ambiguous failure`. Any Slot failure after verified provider\u002Fcheckpoint success is `partial failure`; record ambiguous Slot observations without undoing or downgrading the verified child\u002Fprovider\u002Fcheckpoint facts.\n2. **Path:** `trunk bootstrap` or `tracked-top extension`.\n3. **Mutations performed:** only observed branches, commits, provider operations, and Slot operations.\n4. **Preserved state:** source\u002Ftrunk SHA, child SHA\u002Fcurrent branch, dirty\u002Fclean state, recovery location, and—when observed—Slot name, destination worktree path, checked-out branch, original worktree, and navigation instruction.\n5. **Error\u002Fobservation:** failing step and bounded relevant evidence; do not dump logs. For completion, include the verified Slot\u002Fworktree\u002Fnavigation facts.\n6. **Recovery guidance:** safest next inspection\u002Faction; separate verified facts from hypotheses. A Slot failure must start from the preserved committed provider child, not repeat autobranching.\n7. **Potential improvements:** concrete skill or future implementation improvements, including friction on success and Slot-composition evidence.\n8. **Lesson disposition:** `new-generalizable`, `already-covered`, or `environment-specific`, with one reason.\n\nSafety comes before lesson editing. After state is resolved and reported, turn a new evidence-backed general lesson into a compact normative change when repository mutation is authorized. Shared autobranch lessons must be synchronized in both canonical skills:\n\n- `skills\u002Fincubating\u002Fflow\u002Fns-flow-gs-autobranch\u002FSKILL.md`\n- `skills\u002Fincubating\u002Fflow\u002Fns-flow-gs-autoslot\u002FSKILL.md`\n\nAutoslot-only Slot lessons belong only here. Sharpen checks, failure classes, recovery guidance, version caveats, Slot composition, or promotion requirements; do not add incident chronology, raw logs, secrets, branch-specific names, or speculation. If the effective skill is external or editing is not authorized, report a ready-to-apply proposed change and its authoritative path or paths instead of editing silently.\n\n## Known operational lessons\n\n### Preflight\n\n- Cached trunk and child-ref absence are required facts; provider metadata never substitutes for explicit GS selection.\n- `gh stack --version` is the verified version probe; `gh stack version` is invalid in the verified 0.1.0 surface and may show help, which is never version evidence.\n- Slot composition does not relax autobranch eligibility. A clean invocation remains a refusal rather than becoming a latest-commit Slot move.\n\n### Dirty-state transfer\n\n- An ordinary Git branch switch carries trunk work without a stash; native dirty `gh stack add` remains empirical and requires post-command inspection even after nonzero exit.\n\n### Provider ambiguity\n\n- Command exit is not authoritative. Preserve observed state and stop when Git and `gh stack view --json` do not jointly prove postconditions.\n\n### Checkpointing\n\n- Checkpoint only after the work is observed on the child; initialize a trunk child only after its commit is durable.\n- Slot checkout is eligible only after the checkpoint SHA, provider relationship, current child, and clean porcelain status are all reverified.\n\n### Slot composition\n\n- `ns slot checkout --current` is a final composition step, not part of provider preparation. Its failure cannot invalidate or roll back the already durable child\u002Fprovider state.\n- Slot output is the authority for destination name, worktree path, checked-out branch, and navigation guidance. Report missing or ambiguous output as such rather than constructing paths or commands.\n- Keep original-worktree and destination-worktree facts distinct: a successful Slot move changes where continued work should occur, while the committed branch remains the recovery anchor.\n\n### Recovery\n\n- Forward-only preservation is safer than guessed repair because gh-stack offers no safe remove-one-layer rollback and owns private metadata.\n- After Slot failure, inspect or retry only the Slot operation from the preserved clean child when safe; never rerun branch creation, provider initialization\u002Faddition, or checkpointing.\n\n## Prototype status and promotion\n\nThis skill is a temporary imperative executable specification and evidence collector for provider-specific Flow TypeScript. Happy paths are insufficient. Promotion requires evidence across staged, unstaged, untracked, and mixed dirtiness for both paths; stable typed eligibility\u002Frefusal and absent-versus-ambiguous mutation outcomes; bounded recovery data; verified Slot success, refusal, failure, and ambiguous-output scenarios; fake-driven tests for every retained autobranch and Slot-composition lesson; CLI danger-tier and machine-result review; and migration of command ownership without duplicate surfaces. Future GS orchestration may compose proven Git\u002Fprovider\u002FSlot mechanisms but must not create a universal GT\u002FGS transaction, add a GS CLI route prematurely, or change GT behavior. Retain a thin skill only for guidance that still adds value after deterministic mutation moves into Flow.\n","# ns-flow-gs-autoslot\n\nExperimental dirty-work autoslot for the official `github\u002Fgh-stack` provider (`gs`). Invocation explicitly selects GS and authorizes the scoped local mutations below. This skill contains the complete autobranch procedure; do not invoke, delegate to, or assume execution of `\u002Fns:flow:gs:autobranch`. Only after that procedure has verified provider state, created a durable checkpoint, and proved a clean worktree does it compose `ns slot checkout --current`. This workflow can create a branch and commit, change gh-stack metadata, and move the child into a managed Slot. It does **not** delegate to an `ns flow gs` CLI.\n\n## Scope and hard boundaries\n\nSupport exactly two paths:\n\n1. dirty Git trunk → ordinary child → durable checkpoint → initialize that child as the first gh-stack branch → managed Slot checkout;\n2. dirty non-trunk already tracked as the current stack top → native `gh stack add` child → durable checkpoint → managed Slot checkout.\n\nNever extract the latest commit, initialize an existing non-trunk branch, access `.git\u002Fgh-stack`, fetch, push, submit, retry, roll back, delete a branch, run `gh stack unstack`, or attempt a Slot checkout before the branch\u002Fprovider\u002Fcheckpoint postconditions are proven. Do not describe this prompt-driven workflow as atomic or transactional. Refuse before mutation unless every applicable preflight check passes.\n\n## Common preflight\n\n1. Run `gh stack --version`; require exit status zero and output that reports version `0.1.0`. Refuse before any mutation on command failure, a missing version, version drift, or help output.\n2. Run bounded probes and retain their exact facts:\n   - `git symbolic-ref --quiet --short HEAD` for the attached current branch; refuse detached HEAD.\n   - `git rev-parse --verify HEAD` for the source SHA.\n   - `git status --porcelain=v1 --untracked-files=all` for staged, unstaged, and untracked work; refuse empty output.\n   - `git symbolic-ref --quiet --short refs\u002Fremotes\u002Forigin\u002FHEAD`; refuse if missing, then remove the `origin\u002F` prefix from its short output to obtain cached Git trunk.\n3. Accept an explicit child slug from the initial request or derive one semantic, conservative slug from the pending change. Validate it with `git check-ref-format --branch \u003Cchild>`. Refuse invalid names.\n4. Require `git show-ref --verify --quiet refs\u002Fheads\u002F\u003Cchild>` to report absence. Refuse an existing child ref.\n5. Classify only by current branch versus cached trunk. Invocation is the provider selection; never infer provider choice from metadata.\n6. Before the first mutation, show the user: path, source\u002Ftrunk SHA, concise dirty-status summary, child name, intended commands including the final conditional Slot checkout, and the forward-only failure boundary.\n\nA clean invocation is refused. If the user selected Graphite, direct them to `\u002Fns:flow:gt:autoslot` for ordinary autoslot behavior or `\u002Fns:flow:gt:branch-latest-commit` for latest-commit extraction; do not offer or simulate GS latest-commit extraction.\n\n## Path A: dirty trunk bootstrap\n\n1. Record trunk SHA and porcelain status. Run `git switch -c \u003Cchild>`.\n2. Re-probe current branch, `refs\u002Fheads\u002F\u003Ctrunk>`, `refs\u002Fheads\u002F\u003Cchild>`, and porcelain status. Continue only when the child is current, trunk and child both equal the recorded source SHA, and dirty work remains observable. Otherwise inspect and stop without cleanup.\n3. Run `ns flow cp`. Verify the child advanced, trunk did not, and `git status --porcelain=v1 --untracked-files=all` is empty. If checkpointing fails or cleanliness is unproven, preserve and report the dirty or ambiguously checkpointed child; do not initialize or run Slots.\n4. Only after that durable clean checkpoint, run `gh stack init \u003Cchild>`.\n5. Run `gh stack view --json`. Require valid JSON with expected `trunk`, `currentBranch === \u003Cchild>`, and exactly one matching current child in `branches`. If init fails or the view is malformed\u002Finconsistent, preserve the committed child and stop. Do not move work back, delete anything, or run Slots.\n6. Re-probe the child SHA and clean porcelain status. Continue only if the verified provider child remains current at the checkpoint SHA and the worktree remains clean.\n7. Run exactly `ns slot checkout --current` and observe its exit status and bounded output. On success, report the returned Slot name, worktree path, checked-out branch, and navigation instruction when present; distinguish the original worktree from the destination. Do not infer absent facts. On failure, preserve the committed provider child and report a partial failure without undoing it.\n\n## Path B: dirty tracked-top extension\n\n1. Before mutation run `gh stack view --json`. Require valid JSON with `trunk`, `currentBranch`, and ordered `branches` records containing `name`, `base`, and `isCurrent`.\n2. Require the current Git branch to occur exactly once, be marked current, equal provider `currentBranch`, and be the last\u002Ftopmost branch. Refuse an untracked non-trunk or tracked non-top branch; report the observed top. Never initialize either state.\n3. Record source SHA and porcelain status, then run exactly `gh stack add \u003Cchild>` without `-A`, `-u`, or `-m`.\n4. Regardless of exit status, re-probe current branch, source ref SHA, child ref SHA, porcelain status, and `gh stack view --json`. Continue only if observations prove: source unchanged; child exists at the recorded source SHA; child is current; source and child are adjacent in the ordered provider branch list with the child directly above source and topmost; dirty work remains observable on the child.\n5. If the command rejected the work or any fact is absent or ambiguous, stop. Do not retry, initialize, delete, unstack, edit metadata, improvise rollback, or run Slots.\n6. On verified attachment run `ns flow cp`. Verify child advanced, source did not, and `git status --porcelain=v1 --untracked-files=all` is empty. If checkpointing fails or cleanliness is unproven, preserve and report the attached dirty or ambiguously checkpointed child; do not run Slots.\n7. Re-run `gh stack view --json` and re-probe current branch, source and child SHAs, and porcelain status. Require the same direct topmost provider relationship, the source unchanged, the child at the durable checkpoint SHA, and a clean worktree.\n8. Run exactly `ns slot checkout --current` and observe its exit status and bounded output. On success, report the returned Slot name, worktree path, checked-out branch, and navigation instruction when present; distinguish the original worktree from the destination. Do not infer absent facts. On failure, preserve the committed attached child and report a partial failure without undoing it.\n\n## Invocation report and lesson feedback\n\nAfter **every** outcome, proactively give one terminal report with exactly these eight labeled fields:\n\n1. **Outcome:** `refused`, `completed`, `partial failure`, or `ambiguous failure`. Any Slot failure after verified provider\u002Fcheckpoint success is `partial failure`; record ambiguous Slot observations without undoing or downgrading the verified child\u002Fprovider\u002Fcheckpoint facts.\n2. **Path:** `trunk bootstrap` or `tracked-top extension`.\n3. **Mutations performed:** only observed branches, commits, provider operations, and Slot operations.\n4. **Preserved state:** source\u002Ftrunk SHA, child SHA\u002Fcurrent branch, dirty\u002Fclean state, recovery location, and—when observed—Slot name, destination worktree path, checked-out branch, original worktree, and navigation instruction.\n5. **Error\u002Fobservation:** failing step and bounded relevant evidence; do not dump logs. For completion, include the verified Slot\u002Fworktree\u002Fnavigation facts.\n6. **Recovery guidance:** safest next inspection\u002Faction; separate verified facts from hypotheses. A Slot failure must start from the preserved committed provider child, not repeat autobranching.\n7. **Potential improvements:** concrete skill or future implementation improvements, including friction on success and Slot-composition evidence.\n8. **Lesson disposition:** `new-generalizable`, `already-covered`, or `environment-specific`, with one reason.\n\nSafety comes before lesson editing. After state is resolved and reported, turn a new evidence-backed general lesson into a compact normative change when repository mutation is authorized. Shared autobranch lessons must be synchronized in both canonical skills:\n\n- `skills\u002Fincubating\u002Fflow\u002Fns-flow-gs-autobranch\u002FSKILL.md`\n- `skills\u002Fincubating\u002Fflow\u002Fns-flow-gs-autoslot\u002FSKILL.md`\n\nAutoslot-only Slot lessons belong only here. Sharpen checks, failure classes, recovery guidance, version caveats, Slot composition, or promotion requirements; do not add incident chronology, raw logs, secrets, branch-specific names, or speculation. If the effective skill is external or editing is not authorized, report a ready-to-apply proposed change and its authoritative path or paths instead of editing silently.\n\n## Known operational lessons\n\n### Preflight\n\n- Cached trunk and child-ref absence are required facts; provider metadata never substitutes for explicit GS selection.\n- `gh stack --version` is the verified version probe; `gh stack version` is invalid in the verified 0.1.0 surface and may show help, which is never version evidence.\n- Slot composition does not relax autobranch eligibility. A clean invocation remains a refusal rather than becoming a latest-commit Slot move.\n\n### Dirty-state transfer\n\n- An ordinary Git branch switch carries trunk work without a stash; native dirty `gh stack add` remains empirical and requires post-command inspection even after nonzero exit.\n\n### Provider ambiguity\n\n- Command exit is not authoritative. Preserve observed state and stop when Git and `gh stack view --json` do not jointly prove postconditions.\n\n### Checkpointing\n\n- Checkpoint only after the work is observed on the child; initialize a trunk child only after its commit is durable.\n- Slot checkout is eligible only after the checkpoint SHA, provider relationship, current child, and clean porcelain status are all reverified.\n\n### Slot composition\n\n- `ns slot checkout --current` is a final composition step, not part of provider preparation. Its failure cannot invalidate or roll back the already durable child\u002Fprovider state.\n- Slot output is the authority for destination name, worktree path, checked-out branch, and navigation guidance. Report missing or ambiguous output as such rather than constructing paths or commands.\n- Keep original-worktree and destination-worktree facts distinct: a successful Slot move changes where continued work should occur, while the committed branch remains the recovery anchor.\n\n### Recovery\n\n- Forward-only preservation is safer than guessed repair because gh-stack offers no safe remove-one-layer rollback and owns private metadata.\n- After Slot failure, inspect or retry only the Slot operation from the preserved clean child when safe; never rerun branch creation, provider initialization\u002Faddition, or checkpointing.\n\n## Prototype status and promotion\n\nThis skill is a temporary imperative executable specification and evidence collector for provider-specific Flow TypeScript. Happy paths are insufficient. Promotion requires evidence across staged, unstaged, untracked, and mixed dirtiness for both paths; stable typed eligibility\u002Frefusal and absent-versus-ambiguous mutation outcomes; bounded recovery data; verified Slot success, refusal, failure, and ambiguous-output scenarios; fake-driven tests for every retained autobranch and Slot-composition lesson; CLI danger-tier and machine-result review; and migration of command ownership without duplicate surfaces. Future GS orchestration may compose proven Git\u002Fprovider\u002FSlot mechanisms but must not create a universal GT\u002FGS transaction, add a GS CLI route prematurely, or change GT behavior. Retain a thin skill only for guidance that still adds value after deterministic mutation moves into Flow.\n",{"name":5,"description":7,"allowed-tools":44,"disable-model-invocation":58},[45,46,47,48,49,50,51,52,53,54,55,56,57],"Bash(git status --porcelain=v1*)","Bash(git symbolic-ref --quiet --short HEAD)","Bash(git symbolic-ref --quiet --short refs\u002Fremotes\u002Forigin\u002FHEAD)","Bash(git rev-parse --verify*)","Bash(git show-ref --verify --quiet*)","Bash(git check-ref-format --branch*)","Bash(git switch -c*)","Bash(gh stack --version)","Bash(gh stack view --json)","Bash(gh stack add*)","Bash(gh stack init*)","Bash(ns flow cp*)","Bash(ns slot checkout --current)",true,"master","44a56f0d543f274b42239091b35fe4d23855f6b3","skills\u002Fincubating\u002Fflow\u002Fns-flow-gs-autoslot",0,"https:\u002F\u002Fgithub.com\u002Fnseng-ai\u002Fns","https:\u002F\u002Fgithub.com\u002Fnseng-ai","Keeping the clankers in check: Nonslop Engineering for AI","2026-10-02 12:48:53",{"source":8,"skillName":5,"commands":68,"prompt":78,"zipAvailable":58},[69,72,75],{"tool":70,"command":71},"npx","npx skills add nseng-ai\u002Fns --skill ns-flow-gs-autoslot",{"tool":73,"command":74},"bunx","bunx skills add nseng-ai\u002Fns --skill ns-flow-gs-autoslot",{"tool":76,"command":77},"pnpm","pnpm dlx skills add nseng-ai\u002Fns --skill ns-flow-gs-autoslot","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fnseng-ai\u002Fns\u002Fblob\u002Fmaster\u002Fskills\u002Fincubating\u002Fflow\u002Fns-flow-gs-autoslot\u002FSKILL.md",[80],{"path":81,"resourceType":82,"resourceTypeDesc":83,"sizeBytes":84,"sourceHtmlUrl":85},"agents\u002Fopenai.yaml","REFERENCE","参考文档",43,"https:\u002F\u002Fgithub.com\u002Fnseng-ai\u002Fns\u002Fblob\u002Fmaster\u002Fskills\u002Fincubating\u002Fflow\u002Fns-flow-gs-autoslot\u002Fagents\u002Fopenai.yaml",[87,110,141,164,187,197],{"skillNo":88,"name":89,"nameZh":6,"description":90,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":91,"categories":92,"keywords":93,"publishedAt":39},"01M6KM3VZ7JC4S6R4KATJ368EH","pr-make-accountable","Interview a PR author to establish shared understanding of intent and design decisions, then co-author the What \u002F Why \u002F Changes PR body with opt-in Requested reviewer focus.","https:\u002F\u002Fgithub.com\u002Fnseng-ai\u002Fns\u002Fblob\u002Fmaster\u002Fskills\u002Fpublic\u002Fprs\u002Fpr-make-accountable\u002FSKILL.md",[],[94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109],"pr","make","pr make accountable","design","why","reviewer","decisions","interview","intent","focus","shared","co","with","true","changes","pr body",{"skillNo":111,"name":112,"nameZh":6,"description":113,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":114,"categories":115,"keywords":121,"publishedAt":39},"01M6KM3NZCZ86VJ91RSVTRGTJW","typescript-style","Opinionated style guide for strict, portable TypeScript. Use when writing, designing, or reviewing TypeScript: type design, boundary validation, error handling, module architecture, and review discipline.","https:\u002F\u002Fgithub.com\u002Fnseng-ai\u002Fns\u002Fblob\u002Fmaster\u002Fskills\u002Finternal\u002Ftypescript\u002Ftypescript-style\u002FSKILL.md",[116],{"categoryNo":117,"categoryName":118,"taxonomyType":119,"taxonomyTypeDesc":120},"01JBSEEDCAT000000000000010","后端与接口","SCENARIO","使用场景",[122,123,124,97,125,126,127,128,129,130,131,132,133,134,135,136,137,138,139,140],"typescript","style","typescript style","writing","review","architecture","core","error handling","system","Rules","README","use","error-handling","study","module","error","case-study","style guide","for",{"skillNo":142,"name":143,"nameZh":6,"description":144,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":145,"categories":146,"keywords":150,"publishedAt":39},"01M6KM3HNY4WY42KMYRPS6KEJZ","typescript-fake-driven-testing","TypeScript fake-driven testing architecture. Use when writing or reviewing TS code with external dependencies, gateway interfaces, real adapters, in-memory fakes, or CLI scenario tests.","https:\u002F\u002Fgithub.com\u002Fnseng-ai\u002Fns\u002Fblob\u002Fmaster\u002Fskills\u002Finternal\u002Ftypescript\u002Ftypescript-fake-driven-testing\u002FSKILL.md",[147],{"categoryNo":148,"categoryName":149,"taxonomyType":119,"taxonomyTypeDesc":120},"01JBSEEDCAT000000000000008","测试与质量",[151,122,152,153,154,125,155,156,127,157,158,133,159,160,161,162,106,163],"testing","driven","fake driven testing","typescript fake driven testing","cli","memory","code","gateway","dependencies","tests","scenario","Adapters","in-memory",{"skillNo":165,"name":166,"nameZh":6,"description":167,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":168,"categories":169,"keywords":170,"publishedAt":39},"01M6KM3AXC2539PENYVZJYKCP9","ns-typescript","TypeScript overlay for ns-style projects. Use when editing or reviewing TS in this repo: tsconfig baseline, pnpm\u002FVitest\u002Foxlint\u002Foxfmt\u002Fnative tsc commands, relative .ts imports, workspace subpath exports, and the exactOptionalPropertyTypes spread idiom. Repo-specific enforcement (test lanes, time seams, style guard) lives in the host repo's AGENTS.md.","https:\u002F\u002Fgithub.com\u002Fnseng-ai\u002Fns\u002Fblob\u002Fmaster\u002Fskills\u002Finternal\u002Ftypescript\u002Fns-typescript\u002FSKILL.md",[],[122,171,172,173,174,175,176,177,133,178,179,180,181,123,182,183,184,140,185,186],"ns typescript","test","guard","vitest","projects","editing","repo","enforcement","references","time","host","oxlint","import","native","alternatives","imports",{"skillNo":188,"name":189,"nameZh":6,"description":190,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":191,"categories":192,"keywords":193,"publishedAt":39},"01M6KM36Y5KZ5V48M58MT42AHM","ns-typescript-style-tripwire","Invoke the ns TypeScript style Tripwire against a supplied diff or current branch.","https:\u002F\u002Fgithub.com\u002Fnseng-ai\u002Fns\u002Fblob\u002Fmaster\u002Fskills\u002Finternal\u002Ftypescript\u002Fns-typescript-style-tripwire\u002FSKILL.md",[],[122,194,123,195,33,196,107],"tripwire","ns typescript style tripwire","diff",{"skillNo":198,"name":199,"nameZh":6,"description":200,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":201,"categories":202,"keywords":206,"publishedAt":39},"01M6KM313HANS0AV181X37ZM45","skill-management","Manage skills with `npx skills`: add, edit, remove, rename, update, or list skills (local or GitHub), and the nested `skills\u002F\u003Cdisposition>\u002F...\u002F\u003Cname>\u002F` \u002F flat `.agents\u002Fskills\u002F` layout conventions.","https:\u002F\u002Fgithub.com\u002Fnseng-ai\u002Fns\u002Fblob\u002Fmaster\u002Fskills\u002Finternal\u002Fskill-system\u002Fskill-management\u002FSKILL.md",[203],{"categoryNo":204,"categoryName":205,"taxonomyType":119,"taxonomyTypeDesc":120},"01JBSEEDCAT000000000000023","Skill与智能体开发",[207,208,209,36,210,196,211,212,70,213,214,106,215,216,217,218,219,220,107,221],"management","skill management","github","remove","nested","manage","local","cat","ln","ls","mkdir","mv","readlink","rg","lock"]