[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6H5YVPQFMCHAAT86FKSF548":3,"skill-same:01M6H5YVPQFMCHAAT86FKSF548":64},{"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":32,"linkOnly":33,"markdownContent":34,"markdownBody":35,"frontMatter":36,"refName":41,"commitSha":42,"skillDirectory":43,"forksCount":44,"repositoryHtmlUrl":45,"repositoryHomepageUrl":6,"ownerHtmlUrl":46,"ownerBlogUrl":47,"ownerDescription":48,"updatedAt":49,"install":50,"resources":63},"01M6H5YVPQFMCHAAT86FKSF548","diagnose-forge",null,"Diagnose forge gaps from E2E diagnostics, file improvement proposals, and implement approved changes. Used by Big Pickle in the unattended forge improvement loop.","8007342\u002Ftillandsias","8007342","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F162944123?v=4","01M6H5SFAKAV1RH8MY0C9X2SZZ","Tlatoāni","01M6H5SFF2BBW9HGM3DXAZ84TG",6,"MIT","https:\u002F\u002Fgithub.com\u002F8007342\u002Ftillandsias\u002Fblob\u002Fmain\u002Fskills\u002Fdiagnose-forge\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31],"diagnose","forge","diagnose forge","implement","diagnostics","file","e2e","loop","proposals","pickle","improvement loop","improvement","changes","2026-11-10 10:12:30",false,"---\nname: diagnose-forge\ndescription: Diagnose forge gaps from E2E diagnostics, file improvement proposals, and implement approved changes. Used by Big Pickle in the unattended forge improvement loop.\nlicense: MIT\nmetadata:\n  author: tillandsias\n  version: \"1.0\"\n  invokedBy: \u002Fdiagnose-forge\n---\n\nYou are loading the **diagnose-forge** skill — the iterative forge improvement workflow for Big Pickle.\n\nThis skill is designed for both unattended loop execution (`opencode run --command diagnose-forge`) and interactive TUI sessions (`\u002Fdiagnose-forge`).\n\n## Vision\n\nThe forge should be a **fully-loaded development environment** — a new user with zero skills should be able to prompt \"I want a web app with this and that\" and every tool, compiler, SDK, and runtime should be ready inside the forge container. No install steps, no investigation, no environment setup.\n\nTarget toolset includes: Flutter, React\u002FAngular toolchains, Dart, TypeScript, Rust, Go, Python, Node.js, Java\u002FKotlin, compilers (gcc, clang), builders (make, cmake, cargo, npm, maven), monitoring tools, and everything needed to build any web app from scratch.\n\nAll enhancements remain inside the existing forge privacy and isolation\nenvelope. Proposals may add pre-installed tools and configuration, but must not\nrequest broader host mounts, host credentials, privileged containers, raw host\nsockets, or proxy\u002Frouter\u002Fenclave bypasses.\n\n## File Layout\n\n- `plan\u002Fforge-improvements\u002Fproposals\u002F` — one `.md` file per proposed gap\n- `plan\u002Fforge-improvements\u002F.diagnose-state` — tracks last processed diagnostics file\n- `target\u002Fforge-diagnostics\u002Fdiagnostics_*.log` — raw diagnostics from E2E runs (host-local, gitignored). Present only on the host that ran the annex.\n- `plan\u002Fdiagnostics\u002Fdiagnostics_*-summary.md` — distilled summaries (durable, committed). Cross-host fallback input — see step 3 of the `\u002Fdiagnose-forge` command.\n- `images\u002Fdefault\u002FContainerfile` — forge image definition (main target for changes)\n- `images\u002Fdefault\u002Fentrypoint-forge-opencode.sh` — runtime env setup (main target for changes)\n\n## State Machine for Proposals\n\nEach proposal goes through these states:\n\n```\nproposed → reviewed → approved → implemented\n     ↓          ↓\n  stale     rejected\n```\n\n- **proposed**: Filed by Big Pickle based on diagnostics analysis\n- **reviewed**: ORCHESTRATOR has read it but not yet decided\n- **approved**: ORCHESTRATOR has approved with privacy\u002Fisolation rationale —\n  ready for implementation\n- **implemented**: Changes applied and committed\n- **rejected**: ORCHESTRATOR declined (with reason)\n- **stale**: Diagnostics no longer show this gap (capability was added by other means)\n\n## Diagnostic Categories\n\n| Category | Examples |\n|---|---|\n| `env-var` | PATH missing entries, RUSTUP_HOME, FLUTTER_ROOT, ANDROID_HOME, JAVA_HOME |\n| `runtime-tool` | gcc, rustc, javac, dart, python3, node, deno, flutter, cargo |\n| `sdk` | Flutter SDK, Android SDK, .NET SDK, Go, Rust toolchain |\n| `cache` | .cache\u002F mounts, homedir layout, layer ordering |\n| `network` | Access to crates.io, npm, pub.dev, pypi from inside forge |\n| `shell-tool` | git, curl, jq, yq, unzip, tar, podman |\n\n## Implementation Guidelines\n\nWhen implementing an approved proposal:\n\n1. **Containerfile changes**: Add packages via `dnf install` in the correct layer. Group related tools. Order matters for layer caching.\n2. **Entrypoint changes**: Export env vars, set up paths, install SDKs that need runtime initialization.\n3. **Commit each implementation separately** so the ORCHESTRATOR can review per-proposal.\n4. **Update the proposal** frontmatter with `implemented_at` and `evidence` (commit SHA or summary).\n\n## Safety Rules\n\n- **Never remove** existing capabilities — only add\n- **Every change must cite diagnostics evidence** — no speculative additions\n- **One gap per proposal** — keeps review tractable\n- **Privacy-first**: No telemetry, no cloud callbacks, no data exfiltration\n- **Zero-trust**: Changes must not open new network egress or reduce container isolation\n- Do not self-approve proposals. In unattended mode, file proposals with\n  `status: proposed` and wait for the orchestrator to mark `status: approved`.\n- If unsure about a change's safety, mark the proposal as `needs_review` and explain the risk\n","You are loading the **diagnose-forge** skill — the iterative forge improvement workflow for Big Pickle.\n\nThis skill is designed for both unattended loop execution (`opencode run --command diagnose-forge`) and interactive TUI sessions (`\u002Fdiagnose-forge`).\n\n## Vision\n\nThe forge should be a **fully-loaded development environment** — a new user with zero skills should be able to prompt \"I want a web app with this and that\" and every tool, compiler, SDK, and runtime should be ready inside the forge container. No install steps, no investigation, no environment setup.\n\nTarget toolset includes: Flutter, React\u002FAngular toolchains, Dart, TypeScript, Rust, Go, Python, Node.js, Java\u002FKotlin, compilers (gcc, clang), builders (make, cmake, cargo, npm, maven), monitoring tools, and everything needed to build any web app from scratch.\n\nAll enhancements remain inside the existing forge privacy and isolation\nenvelope. Proposals may add pre-installed tools and configuration, but must not\nrequest broader host mounts, host credentials, privileged containers, raw host\nsockets, or proxy\u002Frouter\u002Fenclave bypasses.\n\n## File Layout\n\n- `plan\u002Fforge-improvements\u002Fproposals\u002F` — one `.md` file per proposed gap\n- `plan\u002Fforge-improvements\u002F.diagnose-state` — tracks last processed diagnostics file\n- `target\u002Fforge-diagnostics\u002Fdiagnostics_*.log` — raw diagnostics from E2E runs (host-local, gitignored). Present only on the host that ran the annex.\n- `plan\u002Fdiagnostics\u002Fdiagnostics_*-summary.md` — distilled summaries (durable, committed). Cross-host fallback input — see step 3 of the `\u002Fdiagnose-forge` command.\n- `images\u002Fdefault\u002FContainerfile` — forge image definition (main target for changes)\n- `images\u002Fdefault\u002Fentrypoint-forge-opencode.sh` — runtime env setup (main target for changes)\n\n## State Machine for Proposals\n\nEach proposal goes through these states:\n\n```\nproposed → reviewed → approved → implemented\n     ↓          ↓\n  stale     rejected\n```\n\n- **proposed**: Filed by Big Pickle based on diagnostics analysis\n- **reviewed**: ORCHESTRATOR has read it but not yet decided\n- **approved**: ORCHESTRATOR has approved with privacy\u002Fisolation rationale —\n  ready for implementation\n- **implemented**: Changes applied and committed\n- **rejected**: ORCHESTRATOR declined (with reason)\n- **stale**: Diagnostics no longer show this gap (capability was added by other means)\n\n## Diagnostic Categories\n\n| Category | Examples |\n|---|---|\n| `env-var` | PATH missing entries, RUSTUP_HOME, FLUTTER_ROOT, ANDROID_HOME, JAVA_HOME |\n| `runtime-tool` | gcc, rustc, javac, dart, python3, node, deno, flutter, cargo |\n| `sdk` | Flutter SDK, Android SDK, .NET SDK, Go, Rust toolchain |\n| `cache` | .cache\u002F mounts, homedir layout, layer ordering |\n| `network` | Access to crates.io, npm, pub.dev, pypi from inside forge |\n| `shell-tool` | git, curl, jq, yq, unzip, tar, podman |\n\n## Implementation Guidelines\n\nWhen implementing an approved proposal:\n\n1. **Containerfile changes**: Add packages via `dnf install` in the correct layer. Group related tools. Order matters for layer caching.\n2. **Entrypoint changes**: Export env vars, set up paths, install SDKs that need runtime initialization.\n3. **Commit each implementation separately** so the ORCHESTRATOR can review per-proposal.\n4. **Update the proposal** frontmatter with `implemented_at` and `evidence` (commit SHA or summary).\n\n## Safety Rules\n\n- **Never remove** existing capabilities — only add\n- **Every change must cite diagnostics evidence** — no speculative additions\n- **One gap per proposal** — keeps review tractable\n- **Privacy-first**: No telemetry, no cloud callbacks, no data exfiltration\n- **Zero-trust**: Changes must not open new network egress or reduce container isolation\n- Do not self-approve proposals. In unattended mode, file proposals with\n  `status: proposed` and wait for the orchestrator to mark `status: approved`.\n- If unsure about a change's safety, mark the proposal as `needs_review` and explain the risk\n",{"name":5,"license":15,"metadata":37,"description":7},{"author":38,"version":39,"invokedBy":40},"tillandsias","1.0","\u002Fdiagnose-forge","main","bf1668fd1df1b3363b826d083f060234cd2e1d0c","skills\u002Fdiagnose-forge",0,"https:\u002F\u002Fgithub.com\u002F8007342\u002Ftillandsias","https:\u002F\u002Fgithub.com\u002F8007342","https:\u002F\u002Ftlatoani.net","I used to be a software engineer.","2026-11-15 01:25:25",{"source":8,"skillName":5,"commands":51,"prompt":61,"zipAvailable":62},[52,55,58],{"tool":53,"command":54},"npx","npx skills add 8007342\u002Ftillandsias --skill diagnose-forge",{"tool":56,"command":57},"bunx","bunx skills add 8007342\u002Ftillandsias --skill diagnose-forge",{"tool":59,"command":60},"pnpm","pnpm dlx skills add 8007342\u002Ftillandsias --skill diagnose-forge","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002F8007342\u002Ftillandsias\u002Fblob\u002Fmain\u002Fskills\u002Fdiagnose-forge\u002FSKILL.md",true,[],[65,92,125,144,167,179],{"skillNo":66,"name":67,"nameZh":6,"description":68,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":69,"categories":70,"keywords":71,"publishedAt":32},"01M6H60M8Y949GNECQVKAYFNH3","start-a-new-project","Use when the user wants to start a new project, asks how to begin, or is in an empty or nearly empty repository (\"how do I start?\", \"I want to build an app\", \"help me set up a new project\"). Guides them, in plain language, to describe the app as specs first (spec-driven development with OpenSpec), recommends Flutter (and the Flame engine for games and graphics), and sets up specs, a plan folder for longer work, and a README. Works for any project, not only Tillandsias.","https:\u002F\u002Fgithub.com\u002F8007342\u002Ftillandsias\u002Fblob\u002Fmain\u002Fskills\u002Fstart-a-new-project\u002FSKILL.md",[],[72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91],"start","new project","project","start a new project","development","SET","flutter","README","use","only","up","openspec","do","as","app","how to","flame","games","spec-driven","for",{"skillNo":93,"name":94,"nameZh":6,"description":95,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":96,"licenseFileUrl":6,"sourceHtmlUrl":97,"categories":98,"keywords":107,"publishedAt":32},"01M6H60EXYDCPSD1QGC89HM0ZC","smoke-curl-install-and-test-e2e","Clean-room end-to-end smoke test of a PUBLISHED release. Curl-installs the latest release binary from GitHub, does a full `podman system reset --force`, runs `tillandsias --debug --init` from a pristine state, and (if init is clean) launches `tillandsias --cloud 8007342\u002Ftillandsias --opencode` with ONE short fixed smoke prompt (run the credential guard, reply with a fixed token; never the \u002Fmeta-orchestration loop, 1941-smkp). Every issue observed — by this skill's agent during install\u002Freset\u002Finit, or by the agent's one turn inside the forge — is filed as a plan\u002Fissues work packet for later pickup by \u002Fadvance-work-from-plan.","GPL-3.0","https:\u002F\u002Fgithub.com\u002F8007342\u002Ftillandsias\u002Fblob\u002Fmain\u002Fskills\u002Fsmoke-curl-install-and-test-e2e\u002FSKILL.md",[99,104],{"categoryNo":100,"categoryName":101,"taxonomyType":102,"taxonomyTypeDesc":103},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":105,"categoryName":106,"taxonomyType":102,"taxonomyTypeDesc":103},"01JBSEEDCAT000000000000023","Skill与智能体开发",[108,25,109,110,111,112,113,114,115,116,20,117,26,118,119,120,121,122,123,124],"test","curl","install","smoke","smoke curl install and test e2e","orchestration","init","podman","issues","Meta","plan","work","short","never","clean","end","reset",{"skillNo":126,"name":127,"nameZh":6,"description":128,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":129,"categories":130,"keywords":131,"publishedAt":32},"01M6H609K8BAW74S59C68QRKC3","project-discipline","How THIS project wants its branches and pushes shaped — read its branch-discipline level (0 push to main freely; 1 integration branch + pull requests; 2 work refs into the integration branch), the drift between what it declares and what its history shows, which hooks it has installed, how to raise it, and the work format each hook refusal asks for. Every refusal that says \"use \u002Fproject-discipline for instructions\" resolves here. Works for any project in a Tillandsias forge, not only Tillandsias.","https:\u002F\u002Fgithub.com\u002F8007342\u002Ftillandsias\u002Fblob\u002Fmain\u002Fskills\u002Fproject-discipline\u002FSKILL.md",[],[132,74,133,134,135,136,20,137,119,138,80,81,139,41,140,141,87,142,143,91],"discipline","project discipline","pull requests","pull","push","history","branch","hooks","branches","drift","requests","which",{"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":96,"licenseFileUrl":6,"sourceHtmlUrl":148,"categories":149,"keywords":150,"publishedAt":32},"01M6H605G5NAKPP1RE10T3716W","probe-macos-tray-on-windows","Daily cross-platform health probe — compiles the macos-tray crate from the local Windows host. Expected to succeed as a stub (the crate is fully cfg-gated for non-macOS); a build failure here means a shared module or crate broke for everyone. Files structured findings to plan\u002Fissues\u002Fprobe-macos-tray-on-windows-findings-\u003CDATE>.md.","https:\u002F\u002Fgithub.com\u002F8007342\u002Ftillandsias\u002Fblob\u002Fmain\u002Fskills\u002Fprobe-macos-tray-on-windows\u002FSKILL.md",[],[151,152,153,154,116,155,156,118,157,158,159,160,161,162,163,164,85,165,91,166],"macos","windows","probe","probe macos tray on windows","CFG","health","daily","files","build","gated","local","shared","platform","module","host","expected",{"skillNo":168,"name":169,"nameZh":6,"description":170,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":96,"licenseFileUrl":6,"sourceHtmlUrl":171,"categories":172,"keywords":173,"publishedAt":32},"01M6H603KPFQJNC7WWD6X5Q4AA","multihost-orchestration","Compatibility alias for the canonical coordinate-multihost-work skill.","https:\u002F\u002Fgithub.com\u002F8007342\u002Ftillandsias\u002Fblob\u002Fmain\u002Fskills\u002Fmultihost-orchestration\u002FSKILL.md",[],[113,174,119,175,176,177,178,91],"multihost orchestration","compatibility","coordinate","alias","canonical",{"skillNo":180,"name":181,"nameZh":6,"description":182,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":96,"licenseFileUrl":6,"sourceHtmlUrl":183,"categories":184,"keywords":187,"publishedAt":32},"01M6H5ZXRBC66CSA5N28HP2BY7","meta-orchestration","Host-aware Tillandsias recurring runtime loop: sync remote state, drain claimable plan work, run eligible e2e smoke gates, coordinate integrations on mutable Linux, release when warranted, update plan, commit, and push before exit.","https:\u002F\u002Fgithub.com\u002F8007342\u002Ftillandsias\u002Fblob\u002Fmain\u002Fskills\u002Fmeta-orchestration\u002FSKILL.md",[185,186],{"categoryNo":100,"categoryName":101,"taxonomyType":102,"taxonomyTypeDesc":103},{"categoryNo":105,"categoryName":106,"taxonomyType":102,"taxonomyTypeDesc":103},[113,117,188,189,190,191,192,193,194,136,26,118,195,119,196,111,197,176,165,198],"meta orchestration","commit","sync","run","update","release","state","integrations","recurring","exit","remote"]