[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M7BMM3MCMFYAFZ4RG3SF6KJB":3,"skill-same:01M7BMM3MCMFYAFZ4RG3SF6KJB":51},{"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":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":25,"commitSha":26,"skillDirectory":27,"forksCount":14,"repositoryHtmlUrl":28,"repositoryHomepageUrl":29,"ownerHtmlUrl":30,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":31,"install":32,"resources":44},"01M7BMM3MCMFYAFZ4RG3SF6KJB","issue-summary",null,"Add a Chinese nav summary + HITL checklist to a ready-for-agent Gitee issue.","kipyin\u002Fkstack","kipyin","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F28321392?v=4","01M7BMGXGJYY2NYKEDBA4NQET4","Kip","01M7BMGXHMYJVHMS0TF8B1M2SV",0,"MIT","https:\u002F\u002Fgithub.com\u002Fkipyin\u002Fkstack\u002Fblob\u002Fmain\u002Flighthouse\u002Fissue-summary\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: issue-summary\ndescription: Add a Chinese nav summary + HITL checklist to a ready-for-agent Gitee issue.\ndisable-model-invocation: true\n---\n\n# Issue Summary\n\nAdd a navigation comment on a `ready-for-agent` Gitee issue: where it sits in the plan, and how a human verifies the implementation agent's output. Audience is the accepting human (often actuarial). The summary *is* the verification checklist — not a tutorial.\n\n## When\n\nOpen issues only, once labeled `ready-for-agent`, before the implementer starts.\n\n**Gate — is it actually ready?** Read the body plus parent \u002F blockers. Confirm enough contract to write a concrete HITL list: logic\u002Falgorithm, verification expectation (golden or observable), change scope, entrypoint, interfaces. If a checklist step would need invented commands or goldens, switch the label to `needs-info`, list what is missing, and stop. Do not invent a summary.\n\n## Steps\n\n### 1. Standalone or child ticket\n\nRead the body. Child: has `## Parent` or belongs to a sliced feature set. Standalone: no parent.\n\n**Done when**: one sentence names which kind it is.\n\n### 2. Place in the plan\n\n**Child**: one mermaid dependency graph for the whole slice (`graph TD` \u002F `flowchart` \u002F `sequenceDiagram` only — Gitee's engine). Node ids = issue numbers (`IK3MES`). No custom themes or click handlers. Below the diagram, one locator line:\n\n```\n本 issue：\u003C编号>  \u003C-- YOU ARE HERE（方位词）\n```\n\n**Standalone**: no diagram. List blockers and known dependents.\n\n**Done when**: a reader can say where they are, what blocks them, and what they unlock.\n\n### 3. Background and goal\n\nThree beats in plain language:\n\n- **大任务**: what the epic\u002Fparent is doing (from parent problem\u002Fsolution; no jargon dump).\n- **这个 ticket 是 …**: stage inside that epic (setup, deepen, finish).\n- **这个 ticket 的目标**: what becomes usable after delivery. Cite frozen field names from the parent contract; skip implementation detail.\n\nPrefer the words「这个 ticket」over「这张／本票」.\n\n**Done when**: without reading acceptance criteria, a reader can state epic background, this ticket's stage, and post-delivery capability.\n\n### 4. HITL section\n\nFollow「HITL 怎么写」below.\n\n**Done when**: a human can execute each step and mark pass or fail without guessing.\n\n### 5. Publish on Gitee\n\nChinese throughout. Edit an existing comment or create one:\n\n```bash\ngitee api -X PATCH repos\u002F\u003Cowner>\u002F\u003Crepo>\u002Fissues\u002Fcomments\u002F\u003Ccomment_id> -F body=\u003C新内容>\n```\n\n**Done when**: the comment is on the issue and mermaid\u002Fcode fences render on Gitee.\n\n## HITL 怎么写\n\nHITL raises human *comfort*. It does not re-run unit tests. Ask first: which behaviors do automated checks already cover? Leave those out.\n\nCover only what needs a human: end-to-end product use, actuarial judgment of numbers, UX\u002Fsensory checks, human-readable docs.\n\nEach HITL item has three parts: **做什么** + **操作或命令** + **expectation**.\n\n- **可照做**: full commands (args + where values come from) or explicit UI\u002Fagent steps. If the entrypoint is this ticket's job and still undefined → `needs-info`, do not placeholder. If it waits on an upstream ticket → placeholder plus「等 #XXX 确定后替换」. Bare `\u003C触发 X 的命令>` is not allowed.\n- **看得到对错**: expectation states pass vs fail *and* what the human should see (status\u002Ffields, golden magnitude, UI reaction, answer must-include, doc wording). Prefer a short example when possible.\n- **无教学，也不论证**: no「这验证了…」「test 覆盖不了…」. Fail cases in plain failure language.\n\n### Vehicle\n\nPick the form from the verification object (not a fixed template):\n\n| 验证对象 | vehicle | expectation |\n| --- | --- | --- |\n| HTTP \u002F API | hit the endpoint | status + field names |\n| 精算 \u002F 数值 | input scenario vs computed numbers | golden or boundary |\n| 大模型 \u002F 流程 | run the flow | contract points met |\n| 工具 \u002F CLI | run the command | output shape |\n| UI | open app + checklist | visible reaction |\n| 构建 \u002F 部署 | build or deploy | artifact + doc wording |\n\n### Golden\n\nPrecise expectations only where an independent correct answer exists. LLM prose, animation, timing stay descriptive. Wrong precision is noise.\n\nHumans supply golden *data*; the implementer owns test *code*.\n\n### Format\n\n- Commands in fenced blocks; UI as numbered lists.\n- Python via `uv run` (do not assume an open venv).\n- Gitee issue refs in prose use `#IK3MES`; mermaid node ids stay bare.\n- Placeholders `\u003CNAME>` always say where the value comes from.\n- Preconditions (server up, env, task id) at the top of that HITL block.\n\nSamples for six vehicles: [EXAMPLES.md](EXAMPLES.md). Reuse the writing shape; re-pick the vehicle for this ticket.\n","# Issue Summary\n\nAdd a navigation comment on a `ready-for-agent` Gitee issue: where it sits in the plan, and how a human verifies the implementation agent's output. Audience is the accepting human (often actuarial). The summary *is* the verification checklist — not a tutorial.\n\n## When\n\nOpen issues only, once labeled `ready-for-agent`, before the implementer starts.\n\n**Gate — is it actually ready?** Read the body plus parent \u002F blockers. Confirm enough contract to write a concrete HITL list: logic\u002Falgorithm, verification expectation (golden or observable), change scope, entrypoint, interfaces. If a checklist step would need invented commands or goldens, switch the label to `needs-info`, list what is missing, and stop. Do not invent a summary.\n\n## Steps\n\n### 1. Standalone or child ticket\n\nRead the body. Child: has `## Parent` or belongs to a sliced feature set. Standalone: no parent.\n\n**Done when**: one sentence names which kind it is.\n\n### 2. Place in the plan\n\n**Child**: one mermaid dependency graph for the whole slice (`graph TD` \u002F `flowchart` \u002F `sequenceDiagram` only — Gitee's engine). Node ids = issue numbers (`IK3MES`). No custom themes or click handlers. Below the diagram, one locator line:\n\n```\n本 issue：\u003C编号>  \u003C-- YOU ARE HERE（方位词）\n```\n\n**Standalone**: no diagram. List blockers and known dependents.\n\n**Done when**: a reader can say where they are, what blocks them, and what they unlock.\n\n### 3. Background and goal\n\nThree beats in plain language:\n\n- **大任务**: what the epic\u002Fparent is doing (from parent problem\u002Fsolution; no jargon dump).\n- **这个 ticket 是 …**: stage inside that epic (setup, deepen, finish).\n- **这个 ticket 的目标**: what becomes usable after delivery. Cite frozen field names from the parent contract; skip implementation detail.\n\nPrefer the words「这个 ticket」over「这张／本票」.\n\n**Done when**: without reading acceptance criteria, a reader can state epic background, this ticket's stage, and post-delivery capability.\n\n### 4. HITL section\n\nFollow「HITL 怎么写」below.\n\n**Done when**: a human can execute each step and mark pass or fail without guessing.\n\n### 5. Publish on Gitee\n\nChinese throughout. Edit an existing comment or create one:\n\n```bash\ngitee api -X PATCH repos\u002F\u003Cowner>\u002F\u003Crepo>\u002Fissues\u002Fcomments\u002F\u003Ccomment_id> -F body=\u003C新内容>\n```\n\n**Done when**: the comment is on the issue and mermaid\u002Fcode fences render on Gitee.\n\n## HITL 怎么写\n\nHITL raises human *comfort*. It does not re-run unit tests. Ask first: which behaviors do automated checks already cover? Leave those out.\n\nCover only what needs a human: end-to-end product use, actuarial judgment of numbers, UX\u002Fsensory checks, human-readable docs.\n\nEach HITL item has three parts: **做什么** + **操作或命令** + **expectation**.\n\n- **可照做**: full commands (args + where values come from) or explicit UI\u002Fagent steps. If the entrypoint is this ticket's job and still undefined → `needs-info`, do not placeholder. If it waits on an upstream ticket → placeholder plus「等 #XXX 确定后替换」. Bare `\u003C触发 X 的命令>` is not allowed.\n- **看得到对错**: expectation states pass vs fail *and* what the human should see (status\u002Ffields, golden magnitude, UI reaction, answer must-include, doc wording). Prefer a short example when possible.\n- **无教学，也不论证**: no「这验证了…」「test 覆盖不了…」. Fail cases in plain failure language.\n\n### Vehicle\n\nPick the form from the verification object (not a fixed template):\n\n| 验证对象 | vehicle | expectation |\n| --- | --- | --- |\n| HTTP \u002F API | hit the endpoint | status + field names |\n| 精算 \u002F 数值 | input scenario vs computed numbers | golden or boundary |\n| 大模型 \u002F 流程 | run the flow | contract points met |\n| 工具 \u002F CLI | run the command | output shape |\n| UI | open app + checklist | visible reaction |\n| 构建 \u002F 部署 | build or deploy | artifact + doc wording |\n\n### Golden\n\nPrecise expectations only where an independent correct answer exists. LLM prose, animation, timing stay descriptive. Wrong precision is noise.\n\nHumans supply golden *data*; the implementer owns test *code*.\n\n### Format\n\n- Commands in fenced blocks; UI as numbered lists.\n- Python via `uv run` (do not assume an open venv).\n- Gitee issue refs in prose use `#IK3MES`; mermaid node ids stay bare.\n- Placeholders `\u003CNAME>` always say where the value comes from.\n- Preconditions (server up, env, task id) at the top of that HITL block.\n\nSamples for six vehicles: [EXAMPLES.md](EXAMPLES.md). Reuse the writing shape; re-pick the vehicle for this ticket.\n",{"name":5,"description":7,"disable-model-invocation":24},true,"main","3e2ae0890f16fe2dfef9ecac09bdbb79b70035c5","lighthouse\u002Fissue-summary","https:\u002F\u002Fgithub.com\u002Fkipyin\u002Fkstack","https:\u002F\u002Forigin.cursor.com\u002Fkipyin\u002Fkstack","https:\u002F\u002Fgithub.com\u002Fkipyin","2026-11-14 23:09:00",{"source":8,"skillName":5,"commands":33,"prompt":43,"zipAvailable":24},[34,37,40],{"tool":35,"command":36},"npx","npx skills add kipyin\u002Fkstack --skill issue-summary",{"tool":38,"command":39},"bunx","bunx skills add kipyin\u002Fkstack --skill issue-summary",{"tool":41,"command":42},"pnpm","pnpm dlx skills add kipyin\u002Fkstack --skill issue-summary","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fkipyin\u002Fkstack\u002Fblob\u002Fmain\u002Flighthouse\u002Fissue-summary\u002FSKILL.md",[45],{"path":46,"resourceType":47,"resourceTypeDesc":48,"sizeBytes":49,"sourceHtmlUrl":50},"EXAMPLES.md","REFERENCE","参考文档",5405,"https:\u002F\u002Fgithub.com\u002Fkipyin\u002Fkstack\u002Fblob\u002Fmain\u002Flighthouse\u002Fissue-summary\u002FEXAMPLES.md",[52,59,66,73,80,87],{"skillNo":53,"name":54,"nameZh":6,"description":55,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":56,"categories":57,"keywords":58,"publishedAt":19},"01M7BMMEZ4VVAGVZM0GQFDR382","solvency-agent-playbook","solvency playbook: use at the start of any solvency\u002F work — develop, debug, test, refactor, or query. Covers edits under solvency\u002F, solvency pytest, Postgres reads\u002Fwrites for solvency tables, and solvency diffs.","https:\u002F\u002Fgithub.com\u002Fkipyin\u002Fkstack\u002Fblob\u002Fmain\u002Flighthouse\u002Fsolvency-agent-playbook\u002FSKILL.md",[],[],{"skillNo":60,"name":61,"nameZh":6,"description":62,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":63,"categories":64,"keywords":65,"publishedAt":19},"01M7BMMBMAK765Y8AQRG3RRXTJ","pr-debrief","给 PR 出一份业务验收 debrief：在做什么 \u002F 做对了吗 \u002F 真人要验什么，人话，贴到 Gitee。","https:\u002F\u002Fgithub.com\u002Fkipyin\u002Fkstack\u002Fblob\u002Fmain\u002Flighthouse\u002Fpr-debrief\u002FSKILL.md",[],[],{"skillNo":67,"name":68,"nameZh":6,"description":69,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":70,"categories":71,"keywords":72,"publishedAt":19},"01M7BMM7H9JABR5RD2N4M1262D","issue-title-convention","Lint and autofix open Gitee issue titles to the four team prefixes.","https:\u002F\u002Fgithub.com\u002Fkipyin\u002Fkstack\u002Fblob\u002Fmain\u002Flighthouse\u002Fissue-title-convention\u002FSKILL.md",[],[],{"skillNo":74,"name":75,"nameZh":6,"description":76,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":77,"categories":78,"keywords":79,"publishedAt":19},"01M7BMKTBPDW3N19J3YBWQE5DN","gitee-pr-workflow","End-to-end workflow for landing a change on both Gitee and GitHub using the `gitee` Rust CLI. Delegates commit + PR creation to `gitee-pr-submit` (plain-language body, HITL verification, `Linked: #IKxxxx`), then approves it, squash-merges with `--no-close-issue`, adds an evidence comment and closes the linked issue, syncs Gitee main back to local, pushes local main to GitHub, then watches GitHub Actions Build py_total and replaces artifacts\u002Fpy_total.exe. Post-land CI failures use a hotfix PR; never push new commits directly to main. Trigger: \"gitee pr workflow\", \"commit and pr to gitee\", \"land changes on gitee and github\", \"create gitee pr\", \"approve and merge gitee pr\", \"watch py_total\", \"download py_total artifact\".","https:\u002F\u002Fgithub.com\u002Fkipyin\u002Fkstack\u002Fblob\u002Fmain\u002Flighthouse\u002Fgitee-pr-workflow\u002FSKILL.md",[],[],{"skillNo":81,"name":82,"nameZh":6,"description":83,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":84,"categories":85,"keywords":86,"publishedAt":19},"01M7BMKJXX2DP9CYGZWZVSJFPY","gitee-pr-submit","Commit local changes in logical chunks, push a feature branch to Gitee, and open a PR whose body is plain language: what we did, what we verified, with human-in-the-loop (HITL) verification called out explicitly. Links the related issue with `#IKxxxx` in the body (the # is mandatory; without it Gitee neither links nor autocloses the issue). Submit only: do not approve, merge, or sync here. Trigger: \"submit pr\", \"提交 PR\", \"create gitee pr\", \"开个 PR\", \"commit and pr\", \"提交评审\".","https:\u002F\u002Fgithub.com\u002Fkipyin\u002Fkstack\u002Fblob\u002Fmain\u002Flighthouse\u002Fgitee-pr-submit\u002FSKILL.md",[],[],{"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":19},"01M7BMK96T4JBNG0VE4T8EYS7E","gitee-pr-review","Adversarial two-axis review of a Gitee PR, then post ONE PR-level review comment. Sets up an isolated worktree off main, delegates the Standards+Spec review to the code-review skill, explains findings two ways (CEO = plain user-facing value; intern = file:line mechanics assuming no codebase familiarity), drafts the comment in the PR's language, shows it for approval, then posts via the gitee CLI after a --preview dry run. Never attempts inline\u002Fdiff line comments (broken in this toolchain, see Pitfalls). Review-only: never approve or merge. Trigger: \"review gitee pr\", \"评审 PR\", \"adversarial review pr\", \"pr review\", \"review PR \u003Cnumber>\", \"review this branch\".","https:\u002F\u002Fgithub.com\u002Fkipyin\u002Fkstack\u002Fblob\u002Fmain\u002Flighthouse\u002Fgitee-pr-review\u002FSKILL.md",[],[]]