[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6C6N801YG3PVBHJCQPB911F":3,"skill-same:01M6C6N801YG3PVBHJCQPB911F":68},{"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":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":44,"commitSha":45,"skillDirectory":46,"forksCount":47,"repositoryHtmlUrl":48,"repositoryHomepageUrl":49,"ownerHtmlUrl":50,"ownerBlogUrl":51,"ownerDescription":52,"updatedAt":53,"install":54,"resources":67},"01M6C6N801YG3PVBHJCQPB911F","polish-pr",null,"Finish BarefootJS PRs by addressing CI failures and Pullfrog reviews through current-head verification and one final human notification. Use for PR polish or blocker removal, not a read-only review or status request.","piconic-ai\u002Fbarefootjs","piconic-ai","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F248307881?v=4","01M6C6MWCHP3XFVX9N9BB6NA08","01M6C6MWH6SQWFMBKQ0JV4TPQ3",26,"MIT","https:\u002F\u002Fgithub.com\u002Fpiconic-ai\u002Fbarefootjs\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fpolish-pr\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"pr","polish","polish pr","finish","prs","request","for","notification","reviews","read-only","head","human","barefootjs","review","only","use","read","ci","pr polish","verification","status","2026-11-10 10:12:30",false,"---\nname: polish-pr\ndescription: Finish BarefootJS PRs by addressing CI failures and Pullfrog reviews through current-head verification and one final human notification. Use for PR polish or blocker removal, not a read-only review or status request.\n---\n\n# Polish a PR\n\nDrive the requested PR to verified readiness, not merely \"ready for review\".\nThis is a shared, instruction-only skill for Claude and Codex. Both follow this\nsame file; it does not require Codex app tools or a Claude Workflow runtime.\nRead root `AGENTS.md` and `.github\u002Fpullfrog\u002Freview.md` completely before acting.\nUse available GitHub tools or `gh`; no particular harness or model is required.\nA status-only or read-only review request authorizes inspection, not this skill's\nmutations. Finishing does not authorize merging or unrelated fixes.\n\n## Host capabilities\n\n- Read\u002Fedit files and run commands using the current agent's own tools. For\n  GitHub operations use an available connector\u002FMCP tool or authenticated `gh`\n  through its shell tool; the required evidence and completion gates are identical.\n- PR attachment to a chat is optional UI bookkeeping. If the host has no such\n  tool, retain the PR URL in working notes; attachment is never a completion gate.\n- Use review\u002Fsimplification skills when available (including Claude's existing\n  skills), otherwise perform those passes inline using the repository rubric.\n  Do not depend on a particular tool name, agent launcher, or model setting.\n- Use event\u002Fwait tools when available, otherwise inspect GitHub with `gh` and\n  poll with backoff. If later monitoring is requested but the host cannot schedule\n  it, disclose that limitation; do not pretend a persistent monitor was started.\n\n## Establish ownership and state\n\nResolve the PR, actual base branch, remote head SHA, and local checkout. Record\nthe PR URL and optionally attach it if supported. Preserve unrelated work. For a\nstack, process bottom-up and propagate lower-layer fixes before reviewing upper diffs.\n\nKeep a compact evidence record in working notes: PR\u002Fbase\u002Fhead, local validation\ncommands and results, latest Pullfrog-reviewed SHA, findings\u002Fthreads, applicable\nCI and drift checks, mergeability, and whether the final mention was posted.\nRefresh it after every push; never combine results from different heads.\n\n## Review, simplify, and trigger review\n\n- Read the cumulative diff against the PR's actual base. Review correctness and\n  the repository design\u002Ftesting contracts from a fresh context: against the\n  acceptance contract and implement-issues' sibling-shape list, not against your\n  memory of why the code is written that way. A self-assessment of \"clean\" is not\n  independent evidence. Available review skills may help, but inline review is\n  a valid fallback. Do not spawn agents or switch models without authorization.\n- Simplify only changed code: shared decisions, clarity, and unnecessary work.\n  Avoid unrelated cleanup. Verify real entry-point assumptions and meaningful\n  tests, changesets, limitation graduation, and generated-artifact diffs.\n- Run the affected full layer suites plus targeted regressions. When a local\n  failure appears unrelated, reproduce it on the base before calling it\n  pre-existing. Missing tools or a skipped runtime are not a passing runtime\n  test; obtain evidence from that backend's CI and disclose local limitations.\n- Push fixes and update the PR description to the actual diff. Undraft when the\n  initial review pass is complete so Pullfrog can run asynchronously. Undrafting\n  is a trigger, not the final completion gate; do not mention the human yet.\n\n## Own the CI and Pullfrog loop\n\nUse the host's event\u002Fwait mechanism when available; otherwise poll with backoff.\nKeep waits bounded and give concise progress updates without narrating unchanged\npolls. Long-running adapter jobs are expected, not evidence of a blocker. Use\nthe provided scheduling mechanism if the user requests later monitoring.\n\nFor each actionable CI\u002Freview finding:\n\n1. Re-diff against the current head and verify the finding is still applicable.\n   Inspect failed job logs, not only the summary or an older run's failure.\n   Confirm a review finding the way implement-issues' \"Open and finish\" step 3\n   does:\n   - A claimed output defect needs an executable repro. When it does not\n     reproduce, reply with that evidence instead of changing code.\n   - A design or testing-contract finding is must-address on code-and-rule evidence,\n     even when the output is correct today.\n\n   When a round brings several findings, fix the most severe first, in the order\n   that step gives.\n2. Add a repro at the correct layer, fix the root decision, verify, commit, and\n   push. New divergences found during this work need executable evidence, not\n   speculative registry entries or broad late-stage cleanup. A finding that names\n   one missed shape usually has siblings: check the list in implement-issues\n   step 3 and cover them in the same push. A drift failure in a fixture ledger\n   (`expectedHtml`, coverage map, data points, compat or support-matrix lock)\n   is fixed by `bun run fixtures:regen`, never by regenerating one file by hand.\n   Verify with `bun run fixtures:smoke \u003Cfixture>` before pushing.\n3. Reply with the fix and verification; resolve an inline thread only after its\n   finding is addressed or a reasoned disagreement is documented. Check review\n   bodies as well as threads: a blocking finding can exist without an inline thread.\n4. Wait for review of the NEW head and all applicable checks again. Every push,\n   rebase, or lower-stack fix invalidates stale approval and CI evidence.\n\nWatch for a loop that does not converge. If a third round of findings lands on the\nsame decision, stop patching instance by instance. The usual cause is a decision\nthat is still made in more than one place, or a sibling class the list in\nimplement-issues step 3 missed. Re-derive the decision, fix it at its single source,\nadd the missed class to that list, and say in the PR that the approach changed and\nwhy.\n\nDo not blindly rerun failures. If the failure is infrastructure-related, verify\nthat diagnosis, retry the affected job, and inspect the result. Do not weaken\ntests, alter expectations to match a defect, or silently skip failed checks.\nIf a permission, dependency, product decision, or external coordination is needed,\nreport the precise blocker and ask for direction; persistence does not expand scope.\n\n## Final gate — same immutable head\n\nBefore notifying the human, establish ALL of the following on the current SHA:\n\n- Pullfrog has actually reviewed this SHA, with no unresolved blocking findings.\n  A green `pullfrog` check alone, old review, undraft event, or bot launch comment\n  is not sufficient. \"No new issues\" also requires earlier blockers to be addressed.\n- All applicable latest CI checks pass. Distinguish intentional path-filter\u002Fopt-in\n  skips from missing validation; check job names together with their workflows\n  because many adapters have a job called `test`.\n- For changes covered by fixture drift, `update-expected-html` succeeds **by name**\n  on this head. Green unrelated jobs or a missing applicable drift job are not a\n  substitute. Use the local generator procedure in `AGENTS.md` if needed.\n- For a `main`-based PR, `heavy-ci-ran` succeeds. A stacked PR's light CI is not\n  evidence that it is ready to merge into `main` after retargeting.\n- There is no merge conflict. Inspect `mergeStateStatus` as well as `mergeable`.\n  If `UNSTABLE` remains despite green latest checks, inspect every rollup entry:\n  duplicate cancelled runs may survive concurrency. Verify a successful run at\n  the same SHA\u002Fworkflow; rerun the affected cancelled gate if appropriate, then\n  recheck. Never assume the aggregate means either success or a code defect.\n- Personally reread the FINAL cumulative diff after all fixups. Confirm it matches\n  the requested contract, with real pipeline tests, correct changesets\u002Fregistry\n  pointers, and no unreported silent gap. The intended work is committed\u002Fpushed;\n  no uncommitted exploratory change is being presented as part of the verified PR.\n- Re-fetch the remote head before posting. No push has landed since the reviewed\n  SHA or verified checks. If it changed, repeat the invalidated gates.\n\n## Notify once and hand off\n\nCheck existing PR comments and task notes before posting to avoid a duplicate\nready notification after a resumed session. Only after the final gate, post ONE\ncomment starting with `@kfly8` (or the maintainer explicitly requested by the user):\n\n- **What:** actual changes and any remaining scoped limitations.\n- **How to verify:** exact runnable commands\u002Fmanual repro, including what review\n  and simplification changed.\n- **Expected result:** concrete output or behavior, not \"it works\".\n\nAmend a previously drafted comment when fixups changed the diff or commands.\nDo not request the PR author as their own reviewer. Avoid duplicating an\nattribution footer automatically added by a tool. If attribution is used, name\nthe actual executing agent; do not copy another host's signature. Commit author\nand co-author rules are defined once in `AGENTS.md`, for both Claude and Codex.\nReport the PR link, current-head CI\u002Freview outcome, and whether it was merged.\nLeave merging to the user unless explicitly requested.\n\n## Code-scanning follow-through\n\nFor code-scanning fixes, record alert numbers, affected refs, and the analysis\ncommit. A green CodeQL workflow alone does not prove the alerts closed: inspect\nthe PR alert results on the current head. If merging is authorized, verify the\nmerged commit's default-branch analysis succeeds, the target alerts become\n`fixed`, and no new open alerts replace them. Alert numbers can change after a\ncode move; compare the rule and source location too. If merging is not authorized,\nreport this default-branch verification as pending instead of claiming closure.\n\nFor a suspected false positive, inspect the reported data flow, establish whether\nthe sink is reachable, identify every output context, and reproduce the behavior\nby executing generated code or rendering it in the target runtime. Record that\nevidence with the dismissal when dismissal is authorized; do not broadly disable\na query or add escaping merely to silence it. A test-only finding outside a\nproduction boundary is a scoped risk decision, not automatically a false positive.\n\n## Reusable task prompt\n\n> Follow the shared polish-pr skill for \u003CPR URL>. Address CI and Pullfrog findings\n> until the current head passes all applicable checks, has no review blockers or\n> conflicts, and the final cumulative diff is verified. Notify the maintainer once\n> after those gates; do not merge. Report any blocker requiring my decision.\n","# Polish a PR\n\nDrive the requested PR to verified readiness, not merely \"ready for review\".\nThis is a shared, instruction-only skill for Claude and Codex. Both follow this\nsame file; it does not require Codex app tools or a Claude Workflow runtime.\nRead root `AGENTS.md` and `.github\u002Fpullfrog\u002Freview.md` completely before acting.\nUse available GitHub tools or `gh`; no particular harness or model is required.\nA status-only or read-only review request authorizes inspection, not this skill's\nmutations. Finishing does not authorize merging or unrelated fixes.\n\n## Host capabilities\n\n- Read\u002Fedit files and run commands using the current agent's own tools. For\n  GitHub operations use an available connector\u002FMCP tool or authenticated `gh`\n  through its shell tool; the required evidence and completion gates are identical.\n- PR attachment to a chat is optional UI bookkeeping. If the host has no such\n  tool, retain the PR URL in working notes; attachment is never a completion gate.\n- Use review\u002Fsimplification skills when available (including Claude's existing\n  skills), otherwise perform those passes inline using the repository rubric.\n  Do not depend on a particular tool name, agent launcher, or model setting.\n- Use event\u002Fwait tools when available, otherwise inspect GitHub with `gh` and\n  poll with backoff. If later monitoring is requested but the host cannot schedule\n  it, disclose that limitation; do not pretend a persistent monitor was started.\n\n## Establish ownership and state\n\nResolve the PR, actual base branch, remote head SHA, and local checkout. Record\nthe PR URL and optionally attach it if supported. Preserve unrelated work. For a\nstack, process bottom-up and propagate lower-layer fixes before reviewing upper diffs.\n\nKeep a compact evidence record in working notes: PR\u002Fbase\u002Fhead, local validation\ncommands and results, latest Pullfrog-reviewed SHA, findings\u002Fthreads, applicable\nCI and drift checks, mergeability, and whether the final mention was posted.\nRefresh it after every push; never combine results from different heads.\n\n## Review, simplify, and trigger review\n\n- Read the cumulative diff against the PR's actual base. Review correctness and\n  the repository design\u002Ftesting contracts from a fresh context: against the\n  acceptance contract and implement-issues' sibling-shape list, not against your\n  memory of why the code is written that way. A self-assessment of \"clean\" is not\n  independent evidence. Available review skills may help, but inline review is\n  a valid fallback. Do not spawn agents or switch models without authorization.\n- Simplify only changed code: shared decisions, clarity, and unnecessary work.\n  Avoid unrelated cleanup. Verify real entry-point assumptions and meaningful\n  tests, changesets, limitation graduation, and generated-artifact diffs.\n- Run the affected full layer suites plus targeted regressions. When a local\n  failure appears unrelated, reproduce it on the base before calling it\n  pre-existing. Missing tools or a skipped runtime are not a passing runtime\n  test; obtain evidence from that backend's CI and disclose local limitations.\n- Push fixes and update the PR description to the actual diff. Undraft when the\n  initial review pass is complete so Pullfrog can run asynchronously. Undrafting\n  is a trigger, not the final completion gate; do not mention the human yet.\n\n## Own the CI and Pullfrog loop\n\nUse the host's event\u002Fwait mechanism when available; otherwise poll with backoff.\nKeep waits bounded and give concise progress updates without narrating unchanged\npolls. Long-running adapter jobs are expected, not evidence of a blocker. Use\nthe provided scheduling mechanism if the user requests later monitoring.\n\nFor each actionable CI\u002Freview finding:\n\n1. Re-diff against the current head and verify the finding is still applicable.\n   Inspect failed job logs, not only the summary or an older run's failure.\n   Confirm a review finding the way implement-issues' \"Open and finish\" step 3\n   does:\n   - A claimed output defect needs an executable repro. When it does not\n     reproduce, reply with that evidence instead of changing code.\n   - A design or testing-contract finding is must-address on code-and-rule evidence,\n     even when the output is correct today.\n\n   When a round brings several findings, fix the most severe first, in the order\n   that step gives.\n2. Add a repro at the correct layer, fix the root decision, verify, commit, and\n   push. New divergences found during this work need executable evidence, not\n   speculative registry entries or broad late-stage cleanup. A finding that names\n   one missed shape usually has siblings: check the list in implement-issues\n   step 3 and cover them in the same push. A drift failure in a fixture ledger\n   (`expectedHtml`, coverage map, data points, compat or support-matrix lock)\n   is fixed by `bun run fixtures:regen`, never by regenerating one file by hand.\n   Verify with `bun run fixtures:smoke \u003Cfixture>` before pushing.\n3. Reply with the fix and verification; resolve an inline thread only after its\n   finding is addressed or a reasoned disagreement is documented. Check review\n   bodies as well as threads: a blocking finding can exist without an inline thread.\n4. Wait for review of the NEW head and all applicable checks again. Every push,\n   rebase, or lower-stack fix invalidates stale approval and CI evidence.\n\nWatch for a loop that does not converge. If a third round of findings lands on the\nsame decision, stop patching instance by instance. The usual cause is a decision\nthat is still made in more than one place, or a sibling class the list in\nimplement-issues step 3 missed. Re-derive the decision, fix it at its single source,\nadd the missed class to that list, and say in the PR that the approach changed and\nwhy.\n\nDo not blindly rerun failures. If the failure is infrastructure-related, verify\nthat diagnosis, retry the affected job, and inspect the result. Do not weaken\ntests, alter expectations to match a defect, or silently skip failed checks.\nIf a permission, dependency, product decision, or external coordination is needed,\nreport the precise blocker and ask for direction; persistence does not expand scope.\n\n## Final gate — same immutable head\n\nBefore notifying the human, establish ALL of the following on the current SHA:\n\n- Pullfrog has actually reviewed this SHA, with no unresolved blocking findings.\n  A green `pullfrog` check alone, old review, undraft event, or bot launch comment\n  is not sufficient. \"No new issues\" also requires earlier blockers to be addressed.\n- All applicable latest CI checks pass. Distinguish intentional path-filter\u002Fopt-in\n  skips from missing validation; check job names together with their workflows\n  because many adapters have a job called `test`.\n- For changes covered by fixture drift, `update-expected-html` succeeds **by name**\n  on this head. Green unrelated jobs or a missing applicable drift job are not a\n  substitute. Use the local generator procedure in `AGENTS.md` if needed.\n- For a `main`-based PR, `heavy-ci-ran` succeeds. A stacked PR's light CI is not\n  evidence that it is ready to merge into `main` after retargeting.\n- There is no merge conflict. Inspect `mergeStateStatus` as well as `mergeable`.\n  If `UNSTABLE` remains despite green latest checks, inspect every rollup entry:\n  duplicate cancelled runs may survive concurrency. Verify a successful run at\n  the same SHA\u002Fworkflow; rerun the affected cancelled gate if appropriate, then\n  recheck. Never assume the aggregate means either success or a code defect.\n- Personally reread the FINAL cumulative diff after all fixups. Confirm it matches\n  the requested contract, with real pipeline tests, correct changesets\u002Fregistry\n  pointers, and no unreported silent gap. The intended work is committed\u002Fpushed;\n  no uncommitted exploratory change is being presented as part of the verified PR.\n- Re-fetch the remote head before posting. No push has landed since the reviewed\n  SHA or verified checks. If it changed, repeat the invalidated gates.\n\n## Notify once and hand off\n\nCheck existing PR comments and task notes before posting to avoid a duplicate\nready notification after a resumed session. Only after the final gate, post ONE\ncomment starting with `@kfly8` (or the maintainer explicitly requested by the user):\n\n- **What:** actual changes and any remaining scoped limitations.\n- **How to verify:** exact runnable commands\u002Fmanual repro, including what review\n  and simplification changed.\n- **Expected result:** concrete output or behavior, not \"it works\".\n\nAmend a previously drafted comment when fixups changed the diff or commands.\nDo not request the PR author as their own reviewer. Avoid duplicating an\nattribution footer automatically added by a tool. If attribution is used, name\nthe actual executing agent; do not copy another host's signature. Commit author\nand co-author rules are defined once in `AGENTS.md`, for both Claude and Codex.\nReport the PR link, current-head CI\u002Freview outcome, and whether it was merged.\nLeave merging to the user unless explicitly requested.\n\n## Code-scanning follow-through\n\nFor code-scanning fixes, record alert numbers, affected refs, and the analysis\ncommit. A green CodeQL workflow alone does not prove the alerts closed: inspect\nthe PR alert results on the current head. If merging is authorized, verify the\nmerged commit's default-branch analysis succeeds, the target alerts become\n`fixed`, and no new open alerts replace them. Alert numbers can change after a\ncode move; compare the rule and source location too. If merging is not authorized,\nreport this default-branch verification as pending instead of claiming closure.\n\nFor a suspected false positive, inspect the reported data flow, establish whether\nthe sink is reachable, identify every output context, and reproduce the behavior\nby executing generated code or rendering it in the target runtime. Record that\nevidence with the dismissal when dismissal is authorized; do not broadly disable\na query or add escaping merely to silence it. A test-only finding outside a\nproduction boundary is a scoped risk decision, not automatically a false positive.\n\n## Reusable task prompt\n\n> Follow the shared polish-pr skill for \u003CPR URL>. Address CI and Pullfrog findings\n> until the current head passes all applicable checks, has no review blockers or\n> conflicts, and the final cumulative diff is verified. Notify the maintainer once\n> after those gates; do not merge. Report any blocker requiring my decision.\n",{"name":5,"description":7},"main","5cd8ab284f7f3de6ee2d32c50864168e51f94c80",".agents\u002Fskills\u002Fpolish-pr",0,"https:\u002F\u002Fgithub.com\u002Fpiconic-ai\u002Fbarefootjs","https:\u002F\u002Fbarefootjs.dev","https:\u002F\u002Fgithub.com\u002Fpiconic-ai","https:\u002F\u002Fpiconic.ai\u002F","Baby steps to Giant strides.","2026-11-12 20:40:33",{"source":8,"skillName":5,"commands":55,"prompt":65,"zipAvailable":66},[56,59,62],{"tool":57,"command":58},"npx","npx skills add piconic-ai\u002Fbarefootjs --skill polish-pr",{"tool":60,"command":61},"bunx","bunx skills add piconic-ai\u002Fbarefootjs --skill polish-pr",{"tool":63,"command":64},"pnpm","pnpm dlx skills add piconic-ai\u002Fbarefootjs --skill polish-pr","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fpiconic-ai\u002Fbarefootjs\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fpolish-pr\u002FSKILL.md",true,[],[69,99,118,123],{"skillNo":70,"name":30,"nameZh":6,"description":71,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":72,"categories":73,"keywords":79,"publishedAt":39},"01M6C6NAJSHPWEGBNZB6R96GEK","Build, inspect, and debug UI components using @barefootjs\u002Fcli. Use when: creating\u002Fediting\u002Freviewing components, investigating signal dependencies, debugging reactive updates, scaffolding new components, or looking up component APIs.","https:\u002F\u002Fgithub.com\u002Fpiconic-ai\u002Fbarefootjs\u002Fblob\u002Fmain\u002Fplugins\u002Fbarefootjs\u002Fskills\u002Fbarefootjs\u002FSKILL.md",[74],{"categoryNo":75,"categoryName":76,"taxonomyType":77,"taxonomyTypeDesc":78},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[30,80,81,82,83,84,85,86,87,33,88,89,90,91,92,93,94,95,96,97,98],"debug","ui","component","components","cli","debugging","development","editing","up","scaffolding","debug ui","ui components","component development","inspect","updates","reactive","signal","when","new",{"skillNo":100,"name":101,"nameZh":6,"description":102,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":103,"categories":104,"keywords":105,"publishedAt":39},"01M6C6N57NJYRAZQ5BZ106B6XF","implement-issues","Implement BarefootJS GitHub issues or tracked limitations through tested pull requests. Use for issue-to-PR work; use polish-pr for an existing PR's CI and review follow-up.","https:\u002F\u002Fgithub.com\u002Fpiconic-ai\u002Fbarefootjs\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fimplement-issues\u002FSKILL.md",[],[106,107,108,109,24,110,111,30,112,88,35,33,31,113,114,18,115,116,19,117],"implement issues","issues","implement","Existing","follow-up","requests","issue","github","pull requests","github issues","pull","work",{"skillNo":119,"name":30,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":120,"categories":121,"keywords":122,"publishedAt":39},"01M6C6N2XR6ZDBYYK5R99XFZ2W","https:\u002F\u002Fgithub.com\u002Fpiconic-ai\u002Fbarefootjs\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fbarefootjs\u002FSKILL.md",[],[30],{"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":129,"publishedAt":39},"01M6C6MZG1XE06HSCKM02SN2TG","add-adapter","Playbook for adding a new BarefootJS template adapter package (IR → target template language + native runtime). Use when: adding an adapter for a new template engine or backend language, porting the bf helpers \u002F ParsedExpr evaluator to a new language, or wiring an adapter into conformance, compat, CI, release, and docs.","https:\u002F\u002Fgithub.com\u002Fpiconic-ai\u002Fbarefootjs\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fadd-adapter\u002FSKILL.md",[],[130,131,132,24,133,134,35,135,136,137,138,33,139,30,140,141,142,143,144,145,97,146,98,147],"add","adapter","add adapter","release","package","playbook","template","engine","template engine","backend","runtime","end","native","conformance","wiring","porting","helpers","docs"]