[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71S18S297R8N04D8RVDHT8R":3,"skill-same:01M71S18S297R8N04D8RVDHT8R":75},{"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":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":52,"commitSha":53,"skillDirectory":54,"forksCount":55,"repositoryHtmlUrl":56,"repositoryHomepageUrl":6,"ownerHtmlUrl":57,"ownerBlogUrl":58,"ownerDescription":59,"updatedAt":60,"install":61,"resources":74},"01M71S18S297R8N04D8RVDHT8R","gilgamesh-esl-hop",null,"ESL lifecycle hop — in an ESL-enabled project (tonberry MCP available), when a fallthrough mission is authored as an ESL change, Gilgamesh is the MAKER and drives proposed→in_progress→(ready-for-verify). Gilgamesh NEVER self-verifies — maker≠checker is mechanically enforced (C4), so a distinct checker owns the verified transition. Absent tonberry → run the normal GILGAMESH cycle (ESL opt-in); never hard-fail.","Rynaro\u002Fprisma","Rynaro","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F5271543?v=4","01M70CFYFMB316W23THVQAQ42M","Henrique A. Lavezzo","01M71RXA8ZHEPZR3GERY09ERGD",1,"MIT","https:\u002F\u002Fgithub.com\u002FRynaro\u002Fprisma\u002Fblob\u002Fmain\u002F.eidolons\u002Fgilgamesh\u002Fskills\u002Fesl-hop\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"gilgamesh esl hop","hop","esl","as","owns","opt","when","normal","mission","for","checker","MCP","project","maker","self","cycle","ready","never","lifecycle","change","2026-11-10 13:02:02",false,"---\nname: gilgamesh-esl-hop\ndescription: ESL lifecycle hop — in an ESL-enabled project (tonberry MCP available), when a fallthrough mission is authored as an ESL change, Gilgamesh is the MAKER and drives proposed→in_progress→(ready-for-verify). Gilgamesh NEVER self-verifies — maker≠checker is mechanically enforced (C4), so a distinct checker owns the verified transition. Absent tonberry → run the normal GILGAMESH cycle (ESL opt-in); never hard-fail.\nmetadata:\n  methodology: Gilgamesh\n  phase: cross-cutting\n---\n\n# ESL Lifecycle Hop — Gilgamesh (the MAKER)\n\n## When to use\n\nLoad this skill in an **ESL-enabled project** (`mcp__tonberry__*` tools available) when\na fallthrough mission is carried as an ESL change with `acceptance_checks`. Gilgamesh is\nthe **MAKER** — it authors the change and drives it to the point of verification, then\n**hands the verify to a distinct checker**. `maker ≠ checker` is **mechanically\nenforced** (tonberry `verify` check C4). For the full lifecycle and role bindings, see\nthe nexus cortex `methodology\u002Fcortex\u002Fesl-protocol.md`.\n\n## Your hop\n\nYou **make** this change; you do **not** check it. The Excalipoor rule and maker≠checker\npoint the same way: your own signal never certifies your own work.\n\n1. **right-size + propose** — the mission enters ESL as a change. Run the normal\n   GILGAMESH cycle (Gauge → Inventory → Lock → Grind) to author it, applying mutations\n   **sandbox-first** and gating each on its NAMED external oracle (`skills\u002Fgrind\u002FSKILL.md`).\n2. **drive the maker transitions** — `mcp__tonberry__transition --change_id \u003Cid>\n   --to_status in_progress`, then complete the work; leave the change\n   **ready-for-verify**. Set `change.json.maker = gilgamesh`.\n3. **compose the maker artefact** — your result PROPOSE (`skills\u002Fattest\u002FSKILL.md`),\n   `from.eidolon = gilgamesh`. This value populates `change.json.maker`.\n4. **hand the verify to a checker** — you MUST NOT call\n   `mcp__tonberry__transition --to_status verified` yourself. The checker's verify\n   envelope MUST carry `from.eidolon != gilgamesh` (else C4 fails by construction).\n   Emit the change as ready-for-verify; the orchestrator routes the checker.\n5. **on a returned failing check** → treat it as Grind feedback: re-enter the loop\n   under `recover`\u002F`escalate` and fix it as the maker. You never flip your own change\n   green.\n\n## Invariants\n\n- **Maker, not checker.** `change.json.maker = gilgamesh`. Gilgamesh never composes the\n  `verified` transition or the verify envelope — a distinct checker does. Self-verifying\n  would be exactly the maker≠checker violation the gate exists to stop, and exactly the\n  Excalipoor self-attestation the methodology forbids.\n- **External-only verify still holds.** Even as maker, every mutation is gated by a\n  NAMED external oracle before you call the change ready — never self-critique.\n- **Worker, never router.** You do not dispatch the checker; you emit the change\n  ready-for-verify and the orchestrator routes it (`handoffs.downstream: []`). If the\n  change needs a specialist sub-mission, emit a `handoff-request` (`skills\u002Fattest\u002FSKILL.md`).\n- **Graceful skip \u002F fail-open** — if `mcp__tonberry__*` tools are unavailable, run the\n  normal GILGAMESH cycle and **never hard-fail**. ESL is opt-in; Gilgamesh is\n  EIIS-standalone-conformant and works without tonberry.\n\n---\n\n*ESL Lifecycle Hop — Gilgamesh (the MAKER, maker≠checker mechanically enforced, never self-verifies)*\n","# ESL Lifecycle Hop — Gilgamesh (the MAKER)\n\n## When to use\n\nLoad this skill in an **ESL-enabled project** (`mcp__tonberry__*` tools available) when\na fallthrough mission is carried as an ESL change with `acceptance_checks`. Gilgamesh is\nthe **MAKER** — it authors the change and drives it to the point of verification, then\n**hands the verify to a distinct checker**. `maker ≠ checker` is **mechanically\nenforced** (tonberry `verify` check C4). For the full lifecycle and role bindings, see\nthe nexus cortex `methodology\u002Fcortex\u002Fesl-protocol.md`.\n\n## Your hop\n\nYou **make** this change; you do **not** check it. The Excalipoor rule and maker≠checker\npoint the same way: your own signal never certifies your own work.\n\n1. **right-size + propose** — the mission enters ESL as a change. Run the normal\n   GILGAMESH cycle (Gauge → Inventory → Lock → Grind) to author it, applying mutations\n   **sandbox-first** and gating each on its NAMED external oracle (`skills\u002Fgrind\u002FSKILL.md`).\n2. **drive the maker transitions** — `mcp__tonberry__transition --change_id \u003Cid>\n   --to_status in_progress`, then complete the work; leave the change\n   **ready-for-verify**. Set `change.json.maker = gilgamesh`.\n3. **compose the maker artefact** — your result PROPOSE (`skills\u002Fattest\u002FSKILL.md`),\n   `from.eidolon = gilgamesh`. This value populates `change.json.maker`.\n4. **hand the verify to a checker** — you MUST NOT call\n   `mcp__tonberry__transition --to_status verified` yourself. The checker's verify\n   envelope MUST carry `from.eidolon != gilgamesh` (else C4 fails by construction).\n   Emit the change as ready-for-verify; the orchestrator routes the checker.\n5. **on a returned failing check** → treat it as Grind feedback: re-enter the loop\n   under `recover`\u002F`escalate` and fix it as the maker. You never flip your own change\n   green.\n\n## Invariants\n\n- **Maker, not checker.** `change.json.maker = gilgamesh`. Gilgamesh never composes the\n  `verified` transition or the verify envelope — a distinct checker does. Self-verifying\n  would be exactly the maker≠checker violation the gate exists to stop, and exactly the\n  Excalipoor self-attestation the methodology forbids.\n- **External-only verify still holds.** Even as maker, every mutation is gated by a\n  NAMED external oracle before you call the change ready — never self-critique.\n- **Worker, never router.** You do not dispatch the checker; you emit the change\n  ready-for-verify and the orchestrator routes it (`handoffs.downstream: []`). If the\n  change needs a specialist sub-mission, emit a `handoff-request` (`skills\u002Fattest\u002FSKILL.md`).\n- **Graceful skip \u002F fail-open** — if `mcp__tonberry__*` tools are unavailable, run the\n  normal GILGAMESH cycle and **never hard-fail**. ESL is opt-in; Gilgamesh is\n  EIIS-standalone-conformant and works without tonberry.\n\n---\n\n*ESL Lifecycle Hop — Gilgamesh (the MAKER, maker≠checker mechanically enforced, never self-verifies)*\n",{"name":5,"metadata":49,"description":7},{"phase":50,"methodology":51},"cross-cutting","Gilgamesh","main","42ce382409178ece647a93f841a86119e8d74a65",".eidolons\u002Fgilgamesh\u002Fskills\u002Fesl-hop",0,"https:\u002F\u002Fgithub.com\u002FRynaro\u002Fprisma","https:\u002F\u002Fgithub.com\u002FRynaro","https:\u002F\u002Fhlavezzo.me","A Code Alchemist with a passion for weaving tales and inscribing transmutation circles in pure code.","2026-10-18 20:39:25",{"source":8,"skillName":5,"commands":62,"prompt":72,"zipAvailable":73},[63,66,69],{"tool":64,"command":65},"npx","npx skills add Rynaro\u002Fprisma --skill gilgamesh-esl-hop",{"tool":67,"command":68},"bunx","bunx skills add Rynaro\u002Fprisma --skill gilgamesh-esl-hop",{"tool":70,"command":71},"pnpm","pnpm dlx skills add Rynaro\u002Fprisma --skill gilgamesh-esl-hop","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FRynaro\u002Fprisma\u002Fblob\u002Fmain\u002F.eidolons\u002Fgilgamesh\u002Fskills\u002Fesl-hop\u002FSKILL.md",true,[],[76,101,130,155,179,200],{"skillNo":77,"name":78,"nameZh":6,"description":79,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":80,"categories":81,"keywords":82,"publishedAt":44},"01M71S3X05FSJA01D22MH39Y0W","vivi-verify-incoming","Load when reading any upstream artefact handed off to Vivi that carries a sibling .envelope.json. BLOCKING per ECL §6.2.2: the orchestrator MUST have verified the envelope's SHA-256 (eidolons verify-envelope --block \u002F eidolons run --verify) and recorded a verify_pass before dispatch. If no verify_pass exists for the message_id, or a verify_fail is present, REFUSE to process the payload and hand back to the orchestrator. Symmetric receiver gate — every Eidolon enforces it identically.","https:\u002F\u002Fgithub.com\u002FRynaro\u002Fprisma\u002Fblob\u002Fmain\u002F.eidolons\u002Fvivi\u002Fskills\u002Fverify-incoming\u002FSKILL.md",[],[83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,33,30],"verify","vivi verify incoming","verify incoming","run","sha-256","json","orchestrator","process","dispatch","back","message","upstream","id","receiver","block","ecl","hand","load",{"skillNo":102,"name":103,"nameZh":6,"description":104,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":105,"categories":106,"keywords":112,"publishedAt":44},"01M71S3S2E46S6AZEV07AJ75TK","vivi-parallel-tracks","Load ONLY under TRANCE authorization when the Plan phase yields N independent, non-overlapping implementation tracks (disjoint file sets). Operationalizes the TRANCE G4 form — parallel multi-track implementation in mandatory git-worktree isolation, max 5 clean-context tracks, a per-track verifier cascade, a non-fungible per-track ≤3 reflection budget, explicit stop conditions, and a single-threaded merge\u002Faggregation step. Absent TRANCE gating, Vivi runs exactly as today: single-track A→P→I→V→Δ\u002FR.","https:\u002F\u002Fgithub.com\u002FRynaro\u002Fprisma\u002Fblob\u002Fmain\u002F.eidolons\u002Fvivi\u002Fskills\u002Fparallel-tracks\u002FSKILL.md",[107],{"categoryNo":108,"categoryName":109,"taxonomyType":110,"taxonomyTypeDesc":111},"01JBSEEDCAT000000000000040","财务","PROFESSION","适用职业",[113,114,115,116,117,118,119,120,121,27,122,123,124,100,125,126,127,128,129,30],"parallel","tracks","parallel tracks","vivi parallel tracks","file","only","reflection","clean","plan phase","verifier","form","multi","worktree isolation","track","gating","single","phase",{"skillNo":131,"name":132,"nameZh":6,"description":133,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":134,"categories":135,"keywords":136,"publishedAt":44},"01M71S3N09VY1H2QHXXP4SKY2X","vivi-methodology","Full Vivi cycle reference — A(nalyze) → P(lan) → I(mplement) → V(erify) → Δ(Delta)\u002FR(eflect). Use when the task is a non-trivial feature implementation in a brownfield codebase and you need the complete methodology reference: complexity routing, evidence-grounded planning rules, test-anchoring requirements, and failure-escalation thresholds.","https:\u002F\u002Fgithub.com\u002FRynaro\u002Fprisma\u002Fblob\u002Fmain\u002F.eidolons\u002Fvivi\u002Fskills\u002Fmethodology\u002FSKILL.md",[],[137,138,139,140,141,142,143,144,145,146,39,147,148,149,150,151,152,153,154,30],"methodology","vivi methodology","planning","escalation","Rules","use","evidence","complexity","delta","task","feature implementation","brownfield","full","requirements","feature","complete","thresholds","you",{"skillNo":156,"name":157,"nameZh":6,"description":158,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":159,"categories":160,"keywords":162,"publishedAt":44},"01M71S3GT0M84EHZ2SJZKV61N9","vivi-memory-management","Load at Vivi session start, session end, or when you notice a repeating pattern across tasks. CRYSTALIUM-primary memory protocol: when mcp__crystalium__* tools are available, route ALL memory through CRYSTALIUM (recall\u002Fcommit\u002Fingest\u002Fplan_checkpoint\u002Fsession_end). The local agents\u002Fmemories\u002F*.md files are the standalone fallback for when CRYSTALIUM is absent — EIIS conformance. Never write both.","https:\u002F\u002Fgithub.com\u002FRynaro\u002Fprisma\u002Fblob\u002Fmain\u002F.eidolons\u002Fvivi\u002Fskills\u002Fmemory-management\u002FSKILL.md",[161],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[163,164,165,166,35,167,168,169,170,41,171,172,173,174,175,176,154,177,178,30],"memory","management","memory management","vivi memory management","commit","tasks","plan","write","files","route","across","local","end","session start","standalone","at",{"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":15,"licenseFileUrl":6,"sourceHtmlUrl":183,"categories":184,"keywords":185,"publishedAt":44},"01M71S3E067YRRFH7304VYYF32","vivi-loop-native","Load in Vivi's V (Verify) phase. The core capability that distinguishes Vivi from its predecessor APIVR-Δ: drive the closed, autonomous, bounded edit-run-test loop (`eidolons sandbox loop`) as its `--fix-hook`, consuming localized feedback, retrying in fresh context, refusing to game the tests, and gating on pass^k. Use whenever the task has an executable test oracle and a loop-competent host.","https:\u002F\u002Fgithub.com\u002FRynaro\u002Fprisma\u002Fblob\u002Fmain\u002F.eidolons\u002Fvivi\u002Fskills\u002Floop-native\u002FSKILL.md",[],[186,187,188,189,190,191,192,193,194,195,196,142,146,197,27,198,199,100,127,129],"loop","native","vivi loop native","oracle","sandbox","test","core","game","feedback","autonomous","fix","tests","fresh","host",{"skillNo":201,"name":202,"nameZh":6,"description":203,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":204,"categories":205,"keywords":206,"publishedAt":44},"01M71S3AEKYH0JD0CFJ4GHA98E","vivi-failure-recovery","Load when the Vivi Verify phase produces failures — test fails, lint error, build break, or three consecutive unsuccessful attempts at the same category. Provides the failure classification taxonomy, bounded debugging protocol, and escalation thresholds. Use to avoid the 'random retries' anti-pattern.","https:\u002F\u002Fgithub.com\u002FRynaro\u002Fprisma\u002Fblob\u002Fmain\u002F.eidolons\u002Fvivi\u002Fskills\u002Ffailure-recovery\u002FSKILL.md",[],[207,208,209,140,210,211,142,212,213,153,214,215,216,100,178,217,218,129,30,219],"recovery","vivi failure recovery","debugging","classification","taxonomy","three","pattern","error","retries","random","break","bounded","same"]