[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6K7RDCHN1ZF6SWXN1Y9JDWE":3,"skill-same:01M6K7RDCHN1ZF6SWXN1Y9JDWE":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":24,"linkOnly":25,"markdownContent":26,"markdownBody":27,"frontMatter":28,"refName":29,"commitSha":30,"skillDirectory":31,"forksCount":32,"repositoryHtmlUrl":33,"repositoryHomepageUrl":34,"ownerHtmlUrl":35,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":36,"install":37,"resources":50},"01M6K7RDCHN1ZF6SWXN1Y9JDWE","estimate",null,"Estimate story points for epics, stories, and tasks using Fibonacci scale","tbeack\u002Ffsad_playbook","tbeack","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F206807984?v=4","01M6K7Q3C3VRTCVC55T71A1SY9","Theo Beack","01M6K7Q3GDY8TXRQEH984SEE5W",8,"MIT","https:\u002F\u002Fgithub.com\u002Ftbeack\u002Ffsad_playbook\u002Fblob\u002Fmain\u002Fskills\u002Festimate\u002FSKILL.md",[],[5,19,20,21,22,23],"tasks","Story","scale","for","stories","2026-11-10 10:12:30",false,"---\ndescription: Estimate story points for epics, stories, and tasks using Fibonacci scale\n---\n\n# Story Point Estimator\n\nEstimate story points for work items using a Fibonacci scale (1, 2, 3, 5, 8, 13, 21) and a three-factor rubric: Complexity, Effort, and Risk.\n\n## Asking the user\n\nThis rule covers every question this skill asks the user: a confirmation, a choice, a missing value, a numbered decision list, or a stop-and-ask. It applies even where a later step says \"ask the user\" or \"ask exactly once\". The user may watch the decisions pane rather than the chat, so a question that only goes to chat can go unanswered.\n\n- **When `mcp__decision-tracker__decision` is in your tool list** (loaded, or named as a deferred tool; load a deferred one with `ToolSearch` first), log each question before you ask it:\n  1. Call it with `action: \"open\"`, the question (ending in `?`), and `options` when the answers are a closed set. Set `required: false` when the work can go on without an answer. A numbered list of questions opens one decision per item. Keep each returned `id`.\n  2. Ask the question in chat as this skill says. The open call does not replace the chat question.\n  3. When the user answers, in chat or as a `Decision Dn: \u003Canswer>` message from the plugin, call the tool with `action: \"close\"`, the `id` and the answer.\n  4. When the change the answer asked for is in place, call it with `action: \"implement\"`, the `id` and a `path:line`.\n- **When the tool is absent**, ask in chat only.\n- An `AskUserQuestion` call is logged on its own. Do not open it again.\n- This rule changes where a question is logged. It does not change when this skill asks, or how many times.\n\n## Goal\n\nThe point of an estimation pass is **relative consistency within the batch**, not absolute accuracy against some external truth. Two comparably-scoped items should land on comparable point values, and the process should surface — not hide — the cases where that's genuinely hard to call. Everything below (the judge panel, the spread flag, the adversarial consistency pass) exists in service of that one goal.\n\n## Input\n\nThe user provides work items after invoking `\u002Ffsad-harness:estimate`. Items can be in any format:\n- Bullet list\n- Numbered list\n- Paragraphs\n- Mixed formats\n\nEach item needs at minimum a title. Descriptions are optional but improve accuracy.\n\nIf no work items are provided after the command, ask the user to provide them.\n\nOptional flag: `--show-factors` — surface the per-factor Complexity\u002FEffort\u002FRisk breakdown for each item (see Output Format). Omit for the default, concise output.\n\n## Estimation Rubric\n\nFor each work item, evaluate three factors independently:\n\n| Points | Complexity | Effort | Risk |\n|--------|-----------|--------|------|\n| 1 | Trivial, well-understood | \u003C 1 hour of focused work | Near-zero unknowns |\n| 2 | Simple, minor logic | A few hours | Minimal unknowns |\n| 3 | Moderate, some moving parts | Half a day to a day | Some unknowns, manageable |\n| 5 | Significant, multiple components | 1-3 days | Notable unknowns or dependencies |\n| 8 | Complex, cross-cutting concerns | 3-5 days | Significant unknowns or external dependencies |\n| 13 | Very complex, architectural impact | 1-2 weeks | High uncertainty, consider breaking down |\n| 21 | Extremely complex, system-wide | 2+ weeks | Very high uncertainty, must break down |\n\n**Scoring method:** The highest individual factor score becomes an item's point value from that pass. The riskiest\u002Fhardest dimension dominates.\n\n## Process\n\n### 1. Determine batch size\n\nCount the distinct work items. This determines which estimation mode to use:\n\n- **≤ 5 items** — single-pass mode (step 2a).\n- **> 5 items** — 3-judge panel mode (step 2b). The extra passes are worth the cost once there's enough of a batch to actually need cross-item consistency.\n\n### 2a. Single-pass mode (batches of ≤5 items)\n\nFor each item, silently evaluate Complexity, Effort, and Risk against the rubric and assign the highest factor score as the point value. Retain the per-factor scores internally (needed for `--show-factors`; see Output Format). No panel, no spread flag — skip straight to step 3.\n\n### 2b. 3-judge panel mode (batches of >5 items)\n\nDispatch **three independent `Agent` tool calls**, each scoring the full item list fresh against the rubric using step 2a's method. This is what makes the judges genuinely independent rather than a same-context roleplay: each spawned agent's context contains only the item list (titles + descriptions) and the Estimation Rubric — never the other judges' scores, never this conversation's history — so a judge's numbers can't be anchored on another judge's numbers, and correlated bias across \"judges\" isn't left to an instruction to imagine independence. Send all three `Agent` calls in a **single message** so they run concurrently.\n\nEach agent's prompt:\n> Score each of the following work items against this rubric. For each item, evaluate Complexity, Effort, and Risk independently and assign the highest factor score as its point value — the riskiest\u002Fhardest dimension dominates. If an item is ambiguous, make a reasonable assumption and score it anyway; don't ask questions back. Return, for each item: `{item_name, complexity, effort, risk, points}`.\n>\n> [paste the Estimation Rubric table]\n>\n> Items:\n> [paste the item list — titles and descriptions, nothing else from this conversation]\n\nCollect the three structured returns (`judge_1`, `judge_2`, `judge_3`). For each item:\n- Record all three judges' point values (and their underlying Complexity\u002FEffort\u002FRisk scores, for `--show-factors`).\n- **Final point value = the median of the three judge scores.** (For three values, median is the middle value once sorted — not the mean, so it isn't pulled toward outliers.)\n- **Spread = max judge score − min judge score**, measured in Fibonacci steps (position in the 1,2,3,5,8,13,21 sequence, not raw arithmetic difference). If spread ≥ 2 steps, flag the item as **low-confidence** in the output — the judges genuinely disagreed and that disagreement is signal, not noise to be silently averaged away.\n- If one agent's return doesn't parse as the expected structure for a given item (missing, malformed, or the agent call itself failed), treat that judge's score for that item as missing: use the average of the two remaining valid scores, rounded to the nearest Fibonacci step, as the final value, and flag the item as **low-confidence** regardless of spread — a missing judge is itself a confidence-reducing event, not something to silently paper over by falling back to single-pass scoring.\n\n### 3. Adversarial consistency pass\n\nAfter the estimate table is finalized (median values assigned, low-confidence flags set), run one more pass that reads **only the finished table** — item names\u002Fdescriptions and their final point values, not the scoring conversation or intermediate judge numbers. Compare items pairwise for comparable scope (similar description length, similar keywords, similar apparent surface area) and flag any pair that landed 5+ points apart (by sequence position, e.g. one at 3 and another comparably-scoped one at 13) with no stated reason in either item's description. Report flagged pairs as a note below the table: \"Possible inconsistency: '[Item A]' (N pts) vs '[Item B]' (M pts) — comparable scope, no stated reason for the gap.\"\n\nThis pass runs regardless of batch size or which mode (2a\u002F2b) produced the table — it's a check on the output, not on how the output was produced.\n\n### 4. Handle 13+ point items — offer, don't just note\n\nIf any item's final point value is 13 or higher, don't just print a suggestion and move on. Ask the user directly: \"[Item name] scored [N] — that's high enough to suggest breaking it down. Want me to split it into sub-items and re-estimate each?\"\n\n- If the user accepts: work with them to break the item into smaller sub-items, then estimate each sub-item using the mode (2a\u002F2b) determined by the *sub-item* count, and replace the original item's row with the sub-items' rows in the output table.\n- If the user declines or doesn't respond: keep the item as-is in the table with the original note (\"Consider breaking this down into smaller stories.\") and move on. Don't ask again for the same item in this session.\n\n## Output Format\n\nDefault output — a simple markdown table:\n\n| Item | Points |\n|------|--------|\n| [Item name] | [N] |\n| [Item name] | [N] |\n| **Total** | **[sum]** |\n\nAdd a low-confidence marker (e.g. `⚠` next to the point value, or a `Confidence` column) for any item flagged in step 2b. Add adversarial-pass notes (step 3) below the table.\n\nWith `--show-factors`, add a per-item factor breakdown beneath the table (or as extra columns — pick whichever stays readable for the batch size):\n\n| Item | Points | Complexity | Effort | Risk | Judges (panel mode only) |\n|------|--------|-----------|--------|------|----------------------------|\n| [Item name] | [N] | [score] | [score] | [score] | [j1, j2, j3] |\n\nIn panel mode, the `Complexity`\u002F`Effort`\u002F`Risk` columns show the factors from the judge pass that produced the median point value.\n\n## Rules\n\n- If any item scores 13 or higher, follow the offer-and-loop in Process step 4 — do not just print advice and stop.\n- If an item is too vague to estimate (e.g., \"improve performance\" with no context), ask the user to clarify before estimating that specific item. Estimate the rest normally.\n- Treat epics, stories, and tasks the same — estimate whatever is provided regardless of hierarchy labels.\n- Per-factor Complexity\u002FEffort\u002FRisk scores are always computed and retained internally, never discarded — they're required for `--show-factors` and for the panel's median\u002Fspread logic. Only the default *output* stays terse; the underlying evidence stays available on request.\n- Without `--show-factors`, keep output concise — final point value (plus confidence flag \u002F adversarial notes where applicable), no lengthy justifications.\n","# Story Point Estimator\n\nEstimate story points for work items using a Fibonacci scale (1, 2, 3, 5, 8, 13, 21) and a three-factor rubric: Complexity, Effort, and Risk.\n\n## Asking the user\n\nThis rule covers every question this skill asks the user: a confirmation, a choice, a missing value, a numbered decision list, or a stop-and-ask. It applies even where a later step says \"ask the user\" or \"ask exactly once\". The user may watch the decisions pane rather than the chat, so a question that only goes to chat can go unanswered.\n\n- **When `mcp__decision-tracker__decision` is in your tool list** (loaded, or named as a deferred tool; load a deferred one with `ToolSearch` first), log each question before you ask it:\n  1. Call it with `action: \"open\"`, the question (ending in `?`), and `options` when the answers are a closed set. Set `required: false` when the work can go on without an answer. A numbered list of questions opens one decision per item. Keep each returned `id`.\n  2. Ask the question in chat as this skill says. The open call does not replace the chat question.\n  3. When the user answers, in chat or as a `Decision Dn: \u003Canswer>` message from the plugin, call the tool with `action: \"close\"`, the `id` and the answer.\n  4. When the change the answer asked for is in place, call it with `action: \"implement\"`, the `id` and a `path:line`.\n- **When the tool is absent**, ask in chat only.\n- An `AskUserQuestion` call is logged on its own. Do not open it again.\n- This rule changes where a question is logged. It does not change when this skill asks, or how many times.\n\n## Goal\n\nThe point of an estimation pass is **relative consistency within the batch**, not absolute accuracy against some external truth. Two comparably-scoped items should land on comparable point values, and the process should surface — not hide — the cases where that's genuinely hard to call. Everything below (the judge panel, the spread flag, the adversarial consistency pass) exists in service of that one goal.\n\n## Input\n\nThe user provides work items after invoking `\u002Ffsad-harness:estimate`. Items can be in any format:\n- Bullet list\n- Numbered list\n- Paragraphs\n- Mixed formats\n\nEach item needs at minimum a title. Descriptions are optional but improve accuracy.\n\nIf no work items are provided after the command, ask the user to provide them.\n\nOptional flag: `--show-factors` — surface the per-factor Complexity\u002FEffort\u002FRisk breakdown for each item (see Output Format). Omit for the default, concise output.\n\n## Estimation Rubric\n\nFor each work item, evaluate three factors independently:\n\n| Points | Complexity | Effort | Risk |\n|--------|-----------|--------|------|\n| 1 | Trivial, well-understood | \u003C 1 hour of focused work | Near-zero unknowns |\n| 2 | Simple, minor logic | A few hours | Minimal unknowns |\n| 3 | Moderate, some moving parts | Half a day to a day | Some unknowns, manageable |\n| 5 | Significant, multiple components | 1-3 days | Notable unknowns or dependencies |\n| 8 | Complex, cross-cutting concerns | 3-5 days | Significant unknowns or external dependencies |\n| 13 | Very complex, architectural impact | 1-2 weeks | High uncertainty, consider breaking down |\n| 21 | Extremely complex, system-wide | 2+ weeks | Very high uncertainty, must break down |\n\n**Scoring method:** The highest individual factor score becomes an item's point value from that pass. The riskiest\u002Fhardest dimension dominates.\n\n## Process\n\n### 1. Determine batch size\n\nCount the distinct work items. This determines which estimation mode to use:\n\n- **≤ 5 items** — single-pass mode (step 2a).\n- **> 5 items** — 3-judge panel mode (step 2b). The extra passes are worth the cost once there's enough of a batch to actually need cross-item consistency.\n\n### 2a. Single-pass mode (batches of ≤5 items)\n\nFor each item, silently evaluate Complexity, Effort, and Risk against the rubric and assign the highest factor score as the point value. Retain the per-factor scores internally (needed for `--show-factors`; see Output Format). No panel, no spread flag — skip straight to step 3.\n\n### 2b. 3-judge panel mode (batches of >5 items)\n\nDispatch **three independent `Agent` tool calls**, each scoring the full item list fresh against the rubric using step 2a's method. This is what makes the judges genuinely independent rather than a same-context roleplay: each spawned agent's context contains only the item list (titles + descriptions) and the Estimation Rubric — never the other judges' scores, never this conversation's history — so a judge's numbers can't be anchored on another judge's numbers, and correlated bias across \"judges\" isn't left to an instruction to imagine independence. Send all three `Agent` calls in a **single message** so they run concurrently.\n\nEach agent's prompt:\n> Score each of the following work items against this rubric. For each item, evaluate Complexity, Effort, and Risk independently and assign the highest factor score as its point value — the riskiest\u002Fhardest dimension dominates. If an item is ambiguous, make a reasonable assumption and score it anyway; don't ask questions back. Return, for each item: `{item_name, complexity, effort, risk, points}`.\n>\n> [paste the Estimation Rubric table]\n>\n> Items:\n> [paste the item list — titles and descriptions, nothing else from this conversation]\n\nCollect the three structured returns (`judge_1`, `judge_2`, `judge_3`). For each item:\n- Record all three judges' point values (and their underlying Complexity\u002FEffort\u002FRisk scores, for `--show-factors`).\n- **Final point value = the median of the three judge scores.** (For three values, median is the middle value once sorted — not the mean, so it isn't pulled toward outliers.)\n- **Spread = max judge score − min judge score**, measured in Fibonacci steps (position in the 1,2,3,5,8,13,21 sequence, not raw arithmetic difference). If spread ≥ 2 steps, flag the item as **low-confidence** in the output — the judges genuinely disagreed and that disagreement is signal, not noise to be silently averaged away.\n- If one agent's return doesn't parse as the expected structure for a given item (missing, malformed, or the agent call itself failed), treat that judge's score for that item as missing: use the average of the two remaining valid scores, rounded to the nearest Fibonacci step, as the final value, and flag the item as **low-confidence** regardless of spread — a missing judge is itself a confidence-reducing event, not something to silently paper over by falling back to single-pass scoring.\n\n### 3. Adversarial consistency pass\n\nAfter the estimate table is finalized (median values assigned, low-confidence flags set), run one more pass that reads **only the finished table** — item names\u002Fdescriptions and their final point values, not the scoring conversation or intermediate judge numbers. Compare items pairwise for comparable scope (similar description length, similar keywords, similar apparent surface area) and flag any pair that landed 5+ points apart (by sequence position, e.g. one at 3 and another comparably-scoped one at 13) with no stated reason in either item's description. Report flagged pairs as a note below the table: \"Possible inconsistency: '[Item A]' (N pts) vs '[Item B]' (M pts) — comparable scope, no stated reason for the gap.\"\n\nThis pass runs regardless of batch size or which mode (2a\u002F2b) produced the table — it's a check on the output, not on how the output was produced.\n\n### 4. Handle 13+ point items — offer, don't just note\n\nIf any item's final point value is 13 or higher, don't just print a suggestion and move on. Ask the user directly: \"[Item name] scored [N] — that's high enough to suggest breaking it down. Want me to split it into sub-items and re-estimate each?\"\n\n- If the user accepts: work with them to break the item into smaller sub-items, then estimate each sub-item using the mode (2a\u002F2b) determined by the *sub-item* count, and replace the original item's row with the sub-items' rows in the output table.\n- If the user declines or doesn't respond: keep the item as-is in the table with the original note (\"Consider breaking this down into smaller stories.\") and move on. Don't ask again for the same item in this session.\n\n## Output Format\n\nDefault output — a simple markdown table:\n\n| Item | Points |\n|------|--------|\n| [Item name] | [N] |\n| [Item name] | [N] |\n| **Total** | **[sum]** |\n\nAdd a low-confidence marker (e.g. `⚠` next to the point value, or a `Confidence` column) for any item flagged in step 2b. Add adversarial-pass notes (step 3) below the table.\n\nWith `--show-factors`, add a per-item factor breakdown beneath the table (or as extra columns — pick whichever stays readable for the batch size):\n\n| Item | Points | Complexity | Effort | Risk | Judges (panel mode only) |\n|------|--------|-----------|--------|------|----------------------------|\n| [Item name] | [N] | [score] | [score] | [score] | [j1, j2, j3] |\n\nIn panel mode, the `Complexity`\u002F`Effort`\u002F`Risk` columns show the factors from the judge pass that produced the median point value.\n\n## Rules\n\n- If any item scores 13 or higher, follow the offer-and-loop in Process step 4 — do not just print advice and stop.\n- If an item is too vague to estimate (e.g., \"improve performance\" with no context), ask the user to clarify before estimating that specific item. Estimate the rest normally.\n- Treat epics, stories, and tasks the same — estimate whatever is provided regardless of hierarchy labels.\n- Per-factor Complexity\u002FEffort\u002FRisk scores are always computed and retained internally, never discarded — they're required for `--show-factors` and for the panel's median\u002Fspread logic. Only the default *output* stays terse; the underlying evidence stays available on request.\n- Without `--show-factors`, keep output concise — final point value (plus confidence flag \u002F adversarial notes where applicable), no lengthy justifications.\n",{"description":7},"main","bf3a412c985273327682c956ca35341c64ce9f8c","skills\u002Festimate",4,"https:\u002F\u002Fgithub.com\u002Ftbeack\u002Ffsad_playbook","https:\u002F\u002Ffsad-playbook.vercel.app","https:\u002F\u002Fgithub.com\u002Ftbeack","2026-11-13 22:07:09",{"source":8,"skillName":5,"commands":38,"prompt":48,"zipAvailable":49},[39,42,45],{"tool":40,"command":41},"npx","npx skills add tbeack\u002Ffsad_playbook --skill estimate",{"tool":43,"command":44},"bunx","bunx skills add tbeack\u002Ffsad_playbook --skill estimate",{"tool":46,"command":47},"pnpm","pnpm dlx skills add tbeack\u002Ffsad_playbook --skill estimate","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Ftbeack\u002Ffsad_playbook\u002Fblob\u002Fmain\u002Fskills\u002Festimate\u002FSKILL.md",true,[],[52,73,105,124,144,173],{"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":24},"01M6K7W5RTRMRQMWAGXNSX8DM6","sync","Pre-flight sync check for registered projects. Fetches from remote, reports uncommitted changes, and handles four states — up-to-date, ahead, behind (warns + pulls), or diverged (warns, no pull). Supports single-project (cwd detection), named-project (fsad-harness:sync key1 key2), and full-sync (fsad-harness:sync ALL) modes.","https:\u002F\u002Fgithub.com\u002Ftbeack\u002Ffsad_playbook\u002Fblob\u002Fmain\u002Fskills\u002Fsync\u002FSKILL.md",[],[54,59,60,61,62,63,64,65,66,67,68,69,22,70,71,72],"pull","harness","detection","projects","check","up","reports","project","full","remote","states","changes","modes","single",{"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":84,"publishedAt":24},"01M6K7VY55SWBDD379T9JZVF16","spec-review","Run a detailed, adversarial multi-agent review of a written proposal or specification (spec.md, PRD, RFC, design doc, architecture proposal, business case) — reviews the document, not code. Runs a steelman\u002Finventory pass, then up to 10 specialist lenses (logic, assumptions, evidence, completeness, feasibility, alternatives, consistency, stakeholders, testability, risk), then adversarial validation that defaults to refuting each finding unless it survives, then a loop-until-dry completeness pass. Writes a single severity-ranked SPEC-REVIEW.md next to the document. Use when the user says \"review this spec\", \"adversarial review\", \"poke holes in this proposal\", \"red team this PRD\", \"critique this design doc\", \"what's wrong with this RFC\", \"stress test this plan\", or similar. Review-only — never edits the document.","https:\u002F\u002Fgithub.com\u002Ftbeack\u002Ffsad_playbook\u002Fblob\u002Fmain\u002Fskills\u002Fspec-review\u002FSKILL.md",[79],{"categoryNo":80,"categoryName":81,"taxonomyType":82,"taxonomyTypeDesc":83},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[85,86,87,88,89,90,91,92,93,94,95,64,96,97,98,99,100,101,102,103,104],"review","spec","spec review","design","architecture","code","inventory","team","loop","never","only","specification","poke","deep","dry","proposal","lens","quick","reviews","when",{"skillNo":106,"name":107,"nameZh":6,"description":108,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":109,"categories":110,"keywords":111,"publishedAt":24},"01M6K7VVD3B0SM3VKJ5W26QPPV","ship","Short alias for \u002Ffsad-harness:ship-it. Wrap up finished work, cut a version, commit, push, and open a PR.","https:\u002F\u002Fgithub.com\u002Ftbeack\u002Ffsad_playbook\u002Fblob\u002Fmain\u002Fskills\u002Fship\u002FSKILL.md",[],[107,112,113,60,114,115,116,117,118,119,64,120,121,122,123,22],"commit","pr","push","open","wrap up","work","short","version","wrap","alias","cut","it",{"skillNo":125,"name":126,"nameZh":6,"description":127,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":128,"categories":129,"keywords":130,"publishedAt":24},"01M6K7VP2QDRNX57KP2RH10FAW","ship-it","Wrap up a finished round of work — verify README and CHANGELOG are current, cut a version if warranted, move completed task files into the completed\u002F folder, then create a feature branch if needed, commit, push, and open a PR. Run after `\u002Ffsad-harness:do-task` has marked one or more tasks done. Takes no arguments.","https:\u002F\u002Fgithub.com\u002Ftbeack\u002Ffsad_playbook\u002Fblob\u002Fmain\u002Fskills\u002Fship-it\u002FSKILL.md",[],[107,131,123,112,19,132,115,133,134,117,135,136,64,137,138,139,140,141,68,142,143],"ship it","create","Bash","gh pr","branch","fetch","log","files","done","checkout","move","ls","parse",{"skillNo":145,"name":146,"nameZh":6,"description":147,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":148,"categories":149,"keywords":150,"publishedAt":24},"01M6K7VEK1C0MK5BNDHV8S6HCA","set-context","Gather codebase and initiative context before planning starts — runs a graphify build or query when graphify is available locally, falls back to a manual repo sweep otherwise, then asks targeted questions and writes a single context.md. Invocable standalone or as fsad-harness:plan's mandatory Phase 0. Use when the user says \"set context\", \"gather context\", or as the first step of fsad-harness:plan.","https:\u002F\u002Fgithub.com\u002Ftbeack\u002Ffsad_playbook\u002Fblob\u002Fmain\u002Fskills\u002Fset-context\u002FSKILL.md",[],[151,152,153,154,60,155,156,157,158,159,160,161,162,163,164,165,166,167,168,169,170,72,171,172,104],"SET","context","set context","planning","first","graphify","plan","sweep","repo","user","use","build","back","query","as","questions","manual","standalone","path","codebase","phase","gather",{"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":183,"publishedAt":24},"01M6K7V17M3MQ92QZ99G294RYM","sec-review-team","Run a multi-agent security review TEAM over a codebase or recent diff. Picks a specialist roster based on detected stack signals (webapp \u002F desktop \u002F iac \u002F llm-agent \u002F container \u002F backend \u002F mobile \u002F etc.) from a library of 13 specialists. Each specialist writes structured JSONL + prose findings in parallel; input-validation-auditor and auth-authz-auditor run a loop-until-dry consensus fan-out (2-8 passes); every deduped finding is adversarially verified by a dedicated validator agent before it can appear in the report. Orchestrator consolidates into a single severity-ranked REPORT.md with deduped root issues, archived per-run under a known-findings.jsonl ledger that drives auto re-review. Distinct from the built-in `\u002Fsecurity-review` (which is a single-pass branch review). Use when the user says \"multi-agent security review\", \"security review team\", \"sec-review team\", \"audit this branch with a team\", \"pre-release hardening team pass\", or similar. Review-only — no fixes.","https:\u002F\u002Fgithub.com\u002Ftbeack\u002Ffsad_playbook\u002Fblob\u002Fmain\u002Fskills\u002Fsec-review-team\u002FSKILL.md",[179,182],{"categoryNo":180,"categoryName":181,"taxonomyType":82,"taxonomyTypeDesc":83},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":80,"categoryName":81,"taxonomyType":82,"taxonomyTypeDesc":83},[85,92,184,185,186,187,188,189,190,93,191,135,192,193,194,99,195,196,197,198,199],"sec review team","review team","agent security","security review","run","release","security-review","stack","consensus","auto","mobile","input","re","jsonl","which","verified"]