[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6N9R2HRYWKZSP08R6YPD0RY":3,"skill-same:01M6N9R2HRYWKZSP08R6YPD0RY":63},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":37,"linkOnly":38,"markdownContent":39,"markdownBody":40,"frontMatter":41,"refName":42,"commitSha":43,"skillDirectory":44,"forksCount":45,"repositoryHtmlUrl":46,"repositoryHomepageUrl":6,"ownerHtmlUrl":47,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":48,"install":49,"resources":62},"01M6N9R2HRYWKZSP08R6YPD0RY","bubbles-status-transition",null,"Transition a Bubbles spec\u002Fscope\u002Fbug status safely through the framework's gate checks. Use when changing state.json status (`in_progress` → `done`, `done_with_concerns`, `blocked`, `specs_hardened`, etc.), promoting an artifact, or running pre-push checks. Covers the mechanical transition guard and the grandfather clause for historical done specs.","pkirsanov\u002Fsmackerel","pkirsanov","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F138962?v=4","01M6N8NAPD2KXMVC17X6GJ0WZ5","01M6N8NATQ9SAZ00H9D61R0TPV",1,"MIT","https:\u002F\u002Fgithub.com\u002Fpkirsanov\u002Fsmackerel\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fbubbles-status-transition\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36],"status","bubbles status transition","transition","framework","push","guard","json","use","bug","gate","done","artifact","mechanical","progress","scope","with","for","state","spec","2026-11-10 10:12:30",false,"---\nname: bubbles-status-transition\ndescription: Transition a Bubbles spec\u002Fscope\u002Fbug status safely through the framework's gate checks. Use when changing state.json status (`in_progress` → `done`, `done_with_concerns`, `blocked`, `specs_hardened`, etc.), promoting an artifact, or running pre-push checks. Covers the mechanical transition guard and the grandfather clause for historical done specs.\n---\n\n# Bubbles Status Transition\n\n## Goal\nMove a spec or scope through its lifecycle without violating the framework's transition gates, and understand exactly when historical done specs are re-evaluated vs. grandfathered.\n\n## When to use\n- About to edit `state.json` status field\n- About to set a scope's `Status:` line in scopes.md or `scopes\u002F*\u002Fscope.md`\n- Before staging a commit that includes status changes\n- Investigating why `state-transition-guard.sh` rejected a transition\n\n## Status ceiling per workflow mode\nEach workflow mode in `bubbles\u002Fworkflows\u002Fmodes.yaml` declares a `statusCeiling`. The spec cannot transition to a status above this ceiling. Common ceilings:\n\n**v4.1.0:** the new `delivered_pending_activation` ceiling sits between `validated` and `done` for work that ships implementation + tests + audit + docs but defers live-runtime evidence to an external actor (operator commit, third-party approval, cutover window, regulator review). Modes targeting it: `adapter-readiness-to-packet`, `dark-launch-shipped`, `migration-shipped-pending-cutover`. See [`docs\u002Fv4.1.0-delivered-pending-activation.md`](..\u002F..\u002Fdocs\u002Fv4.1.0-delivered-pending-activation.md) for the full opt-in surface (`deliverableFiles[]` manifest, `phaseStubs{}`, lockdown tags, evidence-by-reference).\n\n| Mode family | Ceiling | Meaning |\n|-------------|---------|---------|\n| `brainstorm` | `specs_scoped` | Planning only; no implementation |\n| `plan-only` | `specs_scoped` | Same as brainstorm |\n| `spec-scope-hardening` | `specs_hardened` | Specs and design hardened; no code |\n| `docs-only` | `docs_updated` | Managed docs may change; no source code |\n| `validate-only` | `validated` | Certification check only |\n| `audit-only` | `validated` | Audit-owned findings only |\n| `full-delivery`, `feature`, `bugfix-fastlane`, etc. | `done` | Full implementation permitted |\n\nIf the ceiling is below `done`, the agent MUST refuse to mark the spec `done` even if the work feels complete. Set the ceiling status instead and emit a `route_required` packet for the next-stage workflow.\n\n## Ceiling status is terminal-for-mode (not a backlog item)\n\nWhen a workflow mode has `statusCeiling` other than `done` (e.g., `validate-to-doc` → `validated`, `docs-only` → `docs_updated`, `adapter-readiness-to-packet` → `delivered_pending_activation`), the ceiling status IS the completion signal for that mode. Each such mode also declares `terminalAliases: [\u003Cceiling>]` so that portfolio tooling can treat it as terminal.\n\n- **Terminal-for-mode** means: `status == \"done\"` OR `status == mode.statusCeiling` OR `status ∈ mode.terminalAliases`.\n- Use the helper `bash bubbles\u002Fscripts\u002Fis-terminal-for-mode.sh \u003Cstatus> \u003Cmode>` (exit 0 = terminal) instead of comparing to the literal string `\"done\"`.\n- Promotion past the ceiling is forbidden by `state-transition-guard.sh`. Re-orchestrating a ceiling-bound spec\u002Fbug through `bugfix-fastlane` to force `done` is fake make-work — the actual work already shipped.\n- Portfolio sweeps (`spec-dashboard.sh`, `bubbles.status`, `bubbles.recap`, retro tooling) MUST use `is-terminal-for-mode.sh` so ceiling-bound packets are counted as completed work, not as open items.\n\n## Done is sequential\n- A spec cannot be `done` until ALL scopes show `Status: Done` (Gate G024).\n- A scope cannot be `Done` until ALL DoD items are `[x]` with inline raw-output evidence (Gate G025).\n- A DoD item cannot be `[x]` until executed in the current session (anti-fabrication).\n\n## Mechanical guard (must pass before push)\n```\nbash bubbles\u002Fscripts\u002Fstate-transition-guard.sh specs\u002F\u003CNNN-feature>\n```\nReturns exit 0 only when every relevant check passes.\n\n**The guard does not run itself.** It runs where a repository wires it. Measured\nacross the six consumer repos on 2026-08-12: five carry a pre-push hook, exactly\nONE of those invokes any Bubbles guard, and one carries no hook at all. So on\nfive of six repos the guard was reachable only when someone remembered to type\nit — which, from the outside, is indistinguishable from having no gate.\n\nWire it, or it is not enforcing anything:\n\n```bash\n# in .git\u002Fhooks\u002Fpre-push, or the repo's own pre-push runner\nbash .github\u002Fbubbles\u002Fscripts\u002Fverify-changed-specs.sh --base-ref origin\u002Fmain\n```\n\n`verify-changed-specs` is the generic entry point: it discovers the specs a diff\ntouched AND the certified scenarios a SOURCE-only diff invalidated, then runs the\ngates on each. The guard itself has no bypass flag; what varies between repos is\nwhether it is invoked at all.\n\n## Grandfather clause for historical done specs (PRESERVED)\nThis is the most important rule for framework upgrades:\n\n- **`done-spec-audit.sh` default profile is `advisory`** — read-only historical report, exits 0 even if older specs would fail current policy.\n- **Pre-push uses `--profile changed`** — only re-evaluates specs whose `state.json` actually changed in the diff. Spec 042 that's been `done` since v2.x stays green when v4.0 ships, unless someone edits its `state.json` in the same commit.\n- **Recertification is opt-in only** — requires `--profile recertification --all --reopen-failing`. There is no implicit recertification.\n- **The deprecated `--fix` flag is blocked** without an explicit recertification command.\n\nWhen a historical done spec is reopened (because the work needs to be revisited), the agent MUST apply current-version policy from that point forward. The grandfather only applies while the spec stays untouched.\n\n## Pre-completion mechanical pipeline\nRun all of these and capture raw output into report.md before flipping any status to `done`:\n\n```bash\nbash bubbles\u002Fscripts\u002Fstate-transition-guard.sh specs\u002F\u003CNNN-feature>\nbash bubbles\u002Fscripts\u002Fartifact-lint.sh specs\u002F\u003CNNN-feature>\nbash bubbles\u002Fscripts\u002Fcli.sh framework-validate            # in source repo\nbash .github\u002Fbubbles\u002Fscripts\u002Fcli.sh framework-validate    # in downstream repo\n```\n\n## Status is two mirrors — never write one alone\n`state.json` records the lifecycle status twice: top-level `status` and `certification.status`. They are one fact in two places. `transition-contract-resolver.sh` refuses any spec whose mirrors disagree.\n\nThe refusal is `E009-STATUS-MIRROR` at exit 69. It fires BEFORE the mode registry is read, so the guard then reports `workflowMode`, `auditProfile` and `targetStatus` as `UNRESOLVED`. Those `UNRESOLVED` values are a symptom of the early exit. They are NOT evidence that a status ceiling is unsupported.\n\n`certification.*` is `bubbles.validate`-owned, so every other agent has exactly one legal move:\n\n- Do NOT advance `status` alone. A half-write leaves the spec unresolvable and every later guard run fails.\n- Do NOT hand-edit `certification.status` to match. That forges a certification record.\n- DO emit `route_required` to `bubbles.validate` naming the observed divergence.\n\nThis applies in both directions. A `status` that lags the spec's own scopes and execution record is still a bookkeeping defect that only `bubbles.validate` may correct.\n\n```\nroute_required\n  target: bubbles.validate\n  reason: status-mirror divergence\n  feature: specs\u002F\u003CNNN-feature>\n  observed: status=\u003Ctop-level value> certification.status=\u003Cmirror value>\n  evidence: \u003Cverbatim resolver or guard output showing the disagreement>\n  request: certify the transition the guard already passes, or restate status to match the evidence\n```\n\n### What `bubbles.validate` does with that packet\n`bubbles.validate` owns the repair and runs it through\n[`state-certification-reconcile.sh`](..\u002F..\u002Fbubbles\u002Fscripts\u002Fstate-certification-reconcile.sh),\nwhich is dry-run by default:\n\n```bash\nbash bubbles\u002Fscripts\u002Fstate-certification-reconcile.sh specs\u002F\u003CNNN-feature>\nBUBBLES_AGENT_NAME=bubbles.validate bash bubbles\u002Fscripts\u002Fstate-certification-reconcile.sh specs\u002F\u003CNNN-feature> --apply\n```\n\nThe tool does not edit the mirror on request. It re-runs the transition guard\nagainst a candidate in which the mirrors already agree, and writes\n`certification.status` only on a `PASS` verdict. Exit 3 means the guard refused,\nso the status is genuinely ahead of its evidence and the spec needs the work\nfinished or the status restated. The tool never invents `certifiedAt` and never\nlowers top-level `status`.\n\n## Failure recovery\nIf any guard exits non-zero:\n1. Read the failing check label and the suggested remediation.\n2. Fix the underlying gap in the spec\u002Fartifact\u002Fcode.\n3. Re-run the guard.\n4. Do NOT lower the status target. Do NOT add a bypass flag.\n\nOn `E009-STATUS-MIRROR`, read the detail line before diagnosing. It names both mirror values and the owning agent, and a contract-resolution refusal is never a defect in the framework's ceiling handling.\n\n## Authoritative modules\n- `agents\u002Fbubbles_shared\u002Fstate-gates.md` — state-claim integrity\n- `agents\u002Fbubbles_shared\u002Fcompletion-governance.md` — sequential completion, deferral blocking\n- `agents\u002Fbubbles_shared\u002Fscope-workflow.md` — status ceiling enforcement\n- `bubbles\u002Fworkflows\u002Fmodes.yaml` — per-mode `statusCeiling` definitions\n- `bubbles\u002Fscripts\u002Fstate-transition-guard.sh` — mechanical guard\n- `bubbles\u002Fscripts\u002Fdone-spec-audit.sh` — historical grandfather + recertification\n","# Bubbles Status Transition\n\n## Goal\nMove a spec or scope through its lifecycle without violating the framework's transition gates, and understand exactly when historical done specs are re-evaluated vs. grandfathered.\n\n## When to use\n- About to edit `state.json` status field\n- About to set a scope's `Status:` line in scopes.md or `scopes\u002F*\u002Fscope.md`\n- Before staging a commit that includes status changes\n- Investigating why `state-transition-guard.sh` rejected a transition\n\n## Status ceiling per workflow mode\nEach workflow mode in `bubbles\u002Fworkflows\u002Fmodes.yaml` declares a `statusCeiling`. The spec cannot transition to a status above this ceiling. Common ceilings:\n\n**v4.1.0:** the new `delivered_pending_activation` ceiling sits between `validated` and `done` for work that ships implementation + tests + audit + docs but defers live-runtime evidence to an external actor (operator commit, third-party approval, cutover window, regulator review). Modes targeting it: `adapter-readiness-to-packet`, `dark-launch-shipped`, `migration-shipped-pending-cutover`. See [`docs\u002Fv4.1.0-delivered-pending-activation.md`](..\u002F..\u002Fdocs\u002Fv4.1.0-delivered-pending-activation.md) for the full opt-in surface (`deliverableFiles[]` manifest, `phaseStubs{}`, lockdown tags, evidence-by-reference).\n\n| Mode family | Ceiling | Meaning |\n|-------------|---------|---------|\n| `brainstorm` | `specs_scoped` | Planning only; no implementation |\n| `plan-only` | `specs_scoped` | Same as brainstorm |\n| `spec-scope-hardening` | `specs_hardened` | Specs and design hardened; no code |\n| `docs-only` | `docs_updated` | Managed docs may change; no source code |\n| `validate-only` | `validated` | Certification check only |\n| `audit-only` | `validated` | Audit-owned findings only |\n| `full-delivery`, `feature`, `bugfix-fastlane`, etc. | `done` | Full implementation permitted |\n\nIf the ceiling is below `done`, the agent MUST refuse to mark the spec `done` even if the work feels complete. Set the ceiling status instead and emit a `route_required` packet for the next-stage workflow.\n\n## Ceiling status is terminal-for-mode (not a backlog item)\n\nWhen a workflow mode has `statusCeiling` other than `done` (e.g., `validate-to-doc` → `validated`, `docs-only` → `docs_updated`, `adapter-readiness-to-packet` → `delivered_pending_activation`), the ceiling status IS the completion signal for that mode. Each such mode also declares `terminalAliases: [\u003Cceiling>]` so that portfolio tooling can treat it as terminal.\n\n- **Terminal-for-mode** means: `status == \"done\"` OR `status == mode.statusCeiling` OR `status ∈ mode.terminalAliases`.\n- Use the helper `bash bubbles\u002Fscripts\u002Fis-terminal-for-mode.sh \u003Cstatus> \u003Cmode>` (exit 0 = terminal) instead of comparing to the literal string `\"done\"`.\n- Promotion past the ceiling is forbidden by `state-transition-guard.sh`. Re-orchestrating a ceiling-bound spec\u002Fbug through `bugfix-fastlane` to force `done` is fake make-work — the actual work already shipped.\n- Portfolio sweeps (`spec-dashboard.sh`, `bubbles.status`, `bubbles.recap`, retro tooling) MUST use `is-terminal-for-mode.sh` so ceiling-bound packets are counted as completed work, not as open items.\n\n## Done is sequential\n- A spec cannot be `done` until ALL scopes show `Status: Done` (Gate G024).\n- A scope cannot be `Done` until ALL DoD items are `[x]` with inline raw-output evidence (Gate G025).\n- A DoD item cannot be `[x]` until executed in the current session (anti-fabrication).\n\n## Mechanical guard (must pass before push)\n```\nbash bubbles\u002Fscripts\u002Fstate-transition-guard.sh specs\u002F\u003CNNN-feature>\n```\nReturns exit 0 only when every relevant check passes.\n\n**The guard does not run itself.** It runs where a repository wires it. Measured\nacross the six consumer repos on 2026-08-12: five carry a pre-push hook, exactly\nONE of those invokes any Bubbles guard, and one carries no hook at all. So on\nfive of six repos the guard was reachable only when someone remembered to type\nit — which, from the outside, is indistinguishable from having no gate.\n\nWire it, or it is not enforcing anything:\n\n```bash\n# in .git\u002Fhooks\u002Fpre-push, or the repo's own pre-push runner\nbash .github\u002Fbubbles\u002Fscripts\u002Fverify-changed-specs.sh --base-ref origin\u002Fmain\n```\n\n`verify-changed-specs` is the generic entry point: it discovers the specs a diff\ntouched AND the certified scenarios a SOURCE-only diff invalidated, then runs the\ngates on each. The guard itself has no bypass flag; what varies between repos is\nwhether it is invoked at all.\n\n## Grandfather clause for historical done specs (PRESERVED)\nThis is the most important rule for framework upgrades:\n\n- **`done-spec-audit.sh` default profile is `advisory`** — read-only historical report, exits 0 even if older specs would fail current policy.\n- **Pre-push uses `--profile changed`** — only re-evaluates specs whose `state.json` actually changed in the diff. Spec 042 that's been `done` since v2.x stays green when v4.0 ships, unless someone edits its `state.json` in the same commit.\n- **Recertification is opt-in only** — requires `--profile recertification --all --reopen-failing`. There is no implicit recertification.\n- **The deprecated `--fix` flag is blocked** without an explicit recertification command.\n\nWhen a historical done spec is reopened (because the work needs to be revisited), the agent MUST apply current-version policy from that point forward. The grandfather only applies while the spec stays untouched.\n\n## Pre-completion mechanical pipeline\nRun all of these and capture raw output into report.md before flipping any status to `done`:\n\n```bash\nbash bubbles\u002Fscripts\u002Fstate-transition-guard.sh specs\u002F\u003CNNN-feature>\nbash bubbles\u002Fscripts\u002Fartifact-lint.sh specs\u002F\u003CNNN-feature>\nbash bubbles\u002Fscripts\u002Fcli.sh framework-validate            # in source repo\nbash .github\u002Fbubbles\u002Fscripts\u002Fcli.sh framework-validate    # in downstream repo\n```\n\n## Status is two mirrors — never write one alone\n`state.json` records the lifecycle status twice: top-level `status` and `certification.status`. They are one fact in two places. `transition-contract-resolver.sh` refuses any spec whose mirrors disagree.\n\nThe refusal is `E009-STATUS-MIRROR` at exit 69. It fires BEFORE the mode registry is read, so the guard then reports `workflowMode`, `auditProfile` and `targetStatus` as `UNRESOLVED`. Those `UNRESOLVED` values are a symptom of the early exit. They are NOT evidence that a status ceiling is unsupported.\n\n`certification.*` is `bubbles.validate`-owned, so every other agent has exactly one legal move:\n\n- Do NOT advance `status` alone. A half-write leaves the spec unresolvable and every later guard run fails.\n- Do NOT hand-edit `certification.status` to match. That forges a certification record.\n- DO emit `route_required` to `bubbles.validate` naming the observed divergence.\n\nThis applies in both directions. A `status` that lags the spec's own scopes and execution record is still a bookkeeping defect that only `bubbles.validate` may correct.\n\n```\nroute_required\n  target: bubbles.validate\n  reason: status-mirror divergence\n  feature: specs\u002F\u003CNNN-feature>\n  observed: status=\u003Ctop-level value> certification.status=\u003Cmirror value>\n  evidence: \u003Cverbatim resolver or guard output showing the disagreement>\n  request: certify the transition the guard already passes, or restate status to match the evidence\n```\n\n### What `bubbles.validate` does with that packet\n`bubbles.validate` owns the repair and runs it through\n[`state-certification-reconcile.sh`](..\u002F..\u002Fbubbles\u002Fscripts\u002Fstate-certification-reconcile.sh),\nwhich is dry-run by default:\n\n```bash\nbash bubbles\u002Fscripts\u002Fstate-certification-reconcile.sh specs\u002F\u003CNNN-feature>\nBUBBLES_AGENT_NAME=bubbles.validate bash bubbles\u002Fscripts\u002Fstate-certification-reconcile.sh specs\u002F\u003CNNN-feature> --apply\n```\n\nThe tool does not edit the mirror on request. It re-runs the transition guard\nagainst a candidate in which the mirrors already agree, and writes\n`certification.status` only on a `PASS` verdict. Exit 3 means the guard refused,\nso the status is genuinely ahead of its evidence and the spec needs the work\nfinished or the status restated. The tool never invents `certifiedAt` and never\nlowers top-level `status`.\n\n## Failure recovery\nIf any guard exits non-zero:\n1. Read the failing check label and the suggested remediation.\n2. Fix the underlying gap in the spec\u002Fartifact\u002Fcode.\n3. Re-run the guard.\n4. Do NOT lower the status target. Do NOT add a bypass flag.\n\nOn `E009-STATUS-MIRROR`, read the detail line before diagnosing. It names both mirror values and the owning agent, and a contract-resolution refusal is never a defect in the framework's ceiling handling.\n\n## Authoritative modules\n- `agents\u002Fbubbles_shared\u002Fstate-gates.md` — state-claim integrity\n- `agents\u002Fbubbles_shared\u002Fcompletion-governance.md` — sequential completion, deferral blocking\n- `agents\u002Fbubbles_shared\u002Fscope-workflow.md` — status ceiling enforcement\n- `bubbles\u002Fworkflows\u002Fmodes.yaml` — per-mode `statusCeiling` definitions\n- `bubbles\u002Fscripts\u002Fstate-transition-guard.sh` — mechanical guard\n- `bubbles\u002Fscripts\u002Fdone-spec-audit.sh` — historical grandfather + recertification\n",{"name":5,"description":7},"main","ed893cc338281a0bb9bb9ecf3415716cb242bb3f",".github\u002Fskills\u002Fbubbles-status-transition",0,"https:\u002F\u002Fgithub.com\u002Fpkirsanov\u002Fsmackerel","https:\u002F\u002Fgithub.com\u002Fpkirsanov","2026-11-07 02:54:37",{"source":8,"skillName":5,"commands":50,"prompt":60,"zipAvailable":61},[51,54,57],{"tool":52,"command":53},"npx","npx skills add pkirsanov\u002Fsmackerel --skill bubbles-status-transition",{"tool":55,"command":56},"bunx","bunx skills add pkirsanov\u002Fsmackerel --skill bubbles-status-transition",{"tool":58,"command":59},"pnpm","pnpm dlx skills add pkirsanov\u002Fsmackerel --skill bubbles-status-transition","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fpkirsanov\u002Fsmackerel\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fbubbles-status-transition\u002FSKILL.md",true,[],[64,95,123,148,169,197],{"skillNo":65,"name":66,"nameZh":6,"description":67,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":68,"categories":69,"keywords":75,"publishedAt":37},"01M6N9V5TBHQT20V5SCCJ1VRBC","smackerel-trace-capture","Wire Smackerel's concrete validate-plane stack into the framework trace-driven defect-discovery method. Use when running live-category tests (integration\u002Fe2e\u002Fe2e-ui\u002Fstress) against the ephemeral test stack; capturing SLO or trace evidence; hunting latency\u002Ferror\u002Fperf bugs from spans; querying the test-stack Jaeger or Prometheus; or touching `.specify\u002Fruntime\u002Fobservability`. Concrete smackerel endpoints + the exact `capture-slo.sh` command; do NOT duplicate `bubbles-observability-adapter` — this only adds the wiring.","https:\u002F\u002Fgithub.com\u002Fpkirsanov\u002Fsmackerel\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fsmackerel-trace-capture\u002FSKILL.md",[70],{"categoryNo":71,"categoryName":72,"taxonomyType":73,"taxonomyTypeDesc":74},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[76,77,78,79,80,81,82,83,84,25,85,86,87,88,89,90,91,92,93,94],"trace","capture","smackerel trace capture","perf","observability","prometheus","specify","e2e","discovery","slo","only","evidence","do","latency","runtime","tests","adapter","error","bugs",{"skillNo":96,"name":97,"nameZh":6,"description":98,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":99,"categories":100,"keywords":104,"publishedAt":37},"01M6N9TZDEV26RZ7W34HEFPQE9","smackerel-no-defaults","Enforce Smackerel's NO-DEFAULTS \u002F fail-loud SST policy. Use when editing config, Docker Compose, deploy adapters, docs, instructions, skills, env handling, host bind addresses, or any runtime value that could be hidden by fallback syntax.","https:\u002F\u002Fgithub.com\u002Fpkirsanov\u002Fsmackerel\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fsmackerel-no-defaults\u002FSKILL.md",[101],{"categoryNo":102,"categoryName":103,"taxonomyType":73,"taxonomyTypeDesc":74},"01JBSEEDCAT000000000000011","运维与部署",[105,106,107,108,109,110,111,112,113,25,114,115,90,116,117,118,119,120,121,122],"smackerel no defaults","docker","policy","config","deploy","docker compose","syntax","editing","instructions","compose","enforce","bind","env","host","Adapters","sst","addresses","value",{"skillNo":124,"name":125,"nameZh":6,"description":126,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":127,"categories":128,"keywords":132,"publishedAt":37},"01M6N9TJRS5PF83JH2W4614D4W","bubbles-workflow-mode-resolution","Resolve a Bubbles workflow mode against `bubbles\u002Fworkflows.yaml`, including template inheritance, status ceilings, gate wiring, and decision policy. Use when picking a mode for a request, when a guard reports a mode-related failure, or when extending workflows.yaml with a new mode or template. Covers natural-language intent routing and the workflow registry consistency rules.","https:\u002F\u002Fgithub.com\u002Fpkirsanov\u002Fsmackerel\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fbubbles-workflow-mode-resolution\u002FSKILL.md",[129],{"categoryNo":130,"categoryName":131,"taxonomyType":73,"taxonomyTypeDesc":74},"01JBSEEDCAT000000000000023","Skill与智能体开发",[133,134,135,136,107,137,138,23,139,140,141,25,142,143,144,33,145,146,34,147],"workflow","resolution","mode","bubbles workflow mode resolution","workflows","routing","template","decision","Rules","reports","intent","inheritance","consistency","natural-language","wiring",{"skillNo":149,"name":150,"nameZh":6,"description":151,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":152,"categories":153,"keywords":155,"publishedAt":37},"01M6N9TC98D6DJR0D64SSN0SN3","bubbles-workflow-execution-loops","Run per-round synchronous workflow execution loops correctly. Use when orchestrating a multi-round workflow, dispatching specialist subagents, handling round-based remediation, or interpreting a workflow mode's execution policy. Covers authorized direct execution, dispatch-and-wait, batch-then-summarize prohibition, and mapped-mode execution.","https:\u002F\u002Fgithub.com\u002Fpkirsanov\u002Fsmackerel\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fbubbles-workflow-execution-loops\u002FSKILL.md",[154],{"categoryNo":130,"categoryName":131,"taxonomyType":73,"taxonomyTypeDesc":74},[133,156,157,158,159,107,160,161,162,163,164,25,165,166,167,168,135],"execution","loops","bubbles workflow execution loops","summarize","run","batch","remediation","direct","subagents","dispatch","wait","multi","multi-round",{"skillNo":170,"name":171,"nameZh":6,"description":172,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":173,"categories":174,"keywords":179,"publishedAt":37},"01M6N9SYXQNJDQ1T1YT81JH2BG","bubbles-vscode-agent-constraints","Design agents that fit the VS Code Copilot Chat runtime instead of fighting it. Use when authoring or editing any `*.agent.md`; when adding `tools:`, `agents:`, `handoffs:`, `model:`, `user-invocable:`, or `disable-model-invocation:` frontmatter; when designing an orchestrator that dispatches specialists; when a design implies agent-calls-agent-calls-agent chaining; when a subagent dispatch silently no-ops or an agent cannot be selected in the dropdown; or when writing a governance rule about delegation that the runtime cannot actually enforce. Prevents multi-level-subagent designs, prose-only dispatch laws, and frontmatter\u002Fbody contradictions.","https:\u002F\u002Fgithub.com\u002Fpkirsanov\u002Fsmackerel\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fbubbles-vscode-agent-constraints\u002FSKILL.md",[175,178],{"categoryNo":176,"categoryName":177,"taxonomyType":73,"taxonomyTypeDesc":74},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":130,"categoryName":131,"taxonomyType":73,"taxonomyTypeDesc":74},[180,181,182,183,184,185,186,187,188,189,190,191,112,192,86,90,193,194,195,196],"vscode","constraints","bubbles vscode agent constraints","design","writing","copilot","code","delegation","Tools","subagent","model","chaining","orchestrator","authoring","fit","subagent dispatch","frontmatter",{"skillNo":198,"name":199,"nameZh":6,"description":200,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":201,"categories":202,"keywords":203,"publishedAt":37},"01M6N9SD78SK12PRT9KBRZ6TB3","bubbles-upkeep-cadence","How to schedule, dispatch, and record recurring operational upkeep tasks (backup, restore-drill, BCDR-drill, patch-cycle, secret-rotation, flag-cleanup, compliance-sweep). Use when authoring or modifying `config\u002Fupkeep-calendar.yaml`, when investigating a missed task, when reading the upkeep ledger, or when adding a new task type.","https:\u002F\u002Fgithub.com\u002Fpkirsanov\u002Fsmackerel\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fbubbles-upkeep-cadence\u002FSKILL.md",[],[204,205,206,207,208,209,210,211,25,212,213,214,215,216,217,218,219,220,221,222],"cadence","bubbles upkeep cadence","tasks","cleanup","backup","sweep","schedule","recurring","patch","restore","task","cycle","record","missed","type","drill","how to","new task","rotation"]