[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71S2GJ0M3GWSCQ6X86197V1":3,"skill-same:01M71S2GJ0M3GWSCQ6X86197V1":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},"01M71S2GJ0M3GWSCQ6X86197V1","vigil-esl-hop",null,"ESL lifecycle hop — in an ESL-enabled project (tonberry MCP available), VIGIL owns the FAILURE PATH: on a verify_fail or spec-vs-impl drift, transition the change back to the maker (in_progress) and emit an ESCALATE envelope carrying root-cause attribution. You are the failure-path checker, distinct from the maker (maker ≠ checker). Absent tonberry → run the normal V→I→G→I→L cycle (ESL opt-in).","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\u002Fvigil\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],"vigil esl hop","hop","esl","vigil","project","owns","opt","normal","checker","you","impl","MCP","maker","drift","cycle","back","root-cause","lifecycle","attribution","change","2026-11-10 13:02:02",false,"---\nname: vigil-esl-hop\ndescription: \"ESL lifecycle hop — in an ESL-enabled project (tonberry MCP available), VIGIL owns the FAILURE PATH: on a verify_fail or spec-vs-impl drift, transition the change back to the maker (in_progress) and emit an ESCALATE envelope carrying root-cause attribution. You are the failure-path checker, distinct from the maker (maker ≠ checker). Absent tonberry → run the normal V→I→G→I→L cycle (ESL opt-in).\"\nmetadata:\n  methodology: VIGIL\n  phase: post-L\n---\n\n# VIGIL — ESL Lifecycle Hop (Failure Path)\n\nUse this skill in an **ESL-enabled project** (`mcp__tonberry__*` tools available)\nwhen a verify **FAILS** or the implementation **diverges from the spec** (your\nroot-cause domain). You own the **failure path** of the Eidolons Spec Lifecycle\n(ESL) — a checker distinct from the maker.\n\nFor the full lifecycle, stage definitions, and role bindings, see the nexus\ncortex `methodology\u002Fcortex\u002Fesl-protocol.md`.\n\n## Your hop\n\n1. **On `verify_fail`** — call\n   `mcp__tonberry__transition --change_id \u003Cid> --to_status in_progress` to route\n   the change back to the **maker**, then emit an `ESCALATE` envelope carrying\n   your root-cause attribution (`[ROOT-CAUSE]` + evidence anchor from the V→I→G→I→L\n   cycle). The maker re-implements against your finding, not against the symptom.\n2. **When the implementation outran the spec** — run\n   `mcp__tonberry__drift_check --change_id \u003Cid> --checker vigil` **before** archive.\n   A mismatch (impl asserts behavior the Semantic spec never specified, or\n   vice-versa) is a `verify_fail` → transition back + `ESCALATE`.\n3. **You are the failure-path checker** — a distinct identity from the maker.\n   Your verify\u002Fdrift envelopes carry `from.eidolon = vigil`, never the maker's\n   identity.\n\n## Invariants\n\n- **maker ≠ checker** — VIGIL is the checker on the failure path; the change's\n  `maker` (e.g. Vivi) is always a distinct identity. Self-verified changes\n  violate the ESL C4 gate.\n- **Tonberry composes artifacts; you supply signals.** You provide the\n  root-cause attribution, the drift verdict, and the `verify_fail` reason;\n  tonberry writes the `change.json` transition and records enforcement.\n- **Graceful skip** — if `mcp__tonberry__*` tools are unavailable, run your\n  normal **V → I → G → I → L** cycle and emit findings\u002Fescalations the standard\n  way; **never hard-fail**. ESL is opt-in; VIGIL is EIIS-standalone-conformant\n  and works without tonberry.\n\n## Pending: ECL 2.1 verification-attestation (not yet implemented)\n\nECL v2.1 (Draft, adoption-gated — `spec\u002Fecl-2.1.md` §6.5.8) defines an\nOPTIONAL `ise.verification` sub-block: `{fresh_context, checker,\ntranscript_access}`, the wire-shape footprint of an independent verify pass.\nVIGIL is exactly the kind of distinct-identity checker that sub-block is\nbuilt to describe — you are the maker≠checker on this failure path already\n(ESL C4, above). Once ECL 2.1 is cut to Published (the gate: ≥3 shipped\nEidolons emitting the `ise` block) and VIGIL adopts it, your `ESCALATE`\nenvelope on this hop would carry `ise.verification = {fresh_context: true,\nchecker: \"vigil\", transcript_access: \"artifact-only\"}` (or `\"none\"`,\ndepending on what you were handed) alongside `ise.assertion_grade` — the\nMUST-level pairing rule that a `validated` grade actually has a\nfresh-context, different-checker verification behind it is owned by **ESL\n1.1 C8**, not ECL (ECL only shape-checks the sub-block, per §6.5.8.3).\n\n**This is documented as pending, not emitted.** ECL 2.1 is Draft; `ECL_VERSION`\nstays `2.0` and VIGIL's emitted envelopes do not carry `ise.verification` yet.\nNo code or template change accompanies this note — it exists so the next\nsweep that adopts 2.1 has the mapping already worked out.\n\n---\n\n*VIGIL — ESL Lifecycle Hop (failure path)*\n","# VIGIL — ESL Lifecycle Hop (Failure Path)\n\nUse this skill in an **ESL-enabled project** (`mcp__tonberry__*` tools available)\nwhen a verify **FAILS** or the implementation **diverges from the spec** (your\nroot-cause domain). You own the **failure path** of the Eidolons Spec Lifecycle\n(ESL) — a checker distinct from the maker.\n\nFor the full lifecycle, stage definitions, and role bindings, see the nexus\ncortex `methodology\u002Fcortex\u002Fesl-protocol.md`.\n\n## Your hop\n\n1. **On `verify_fail`** — call\n   `mcp__tonberry__transition --change_id \u003Cid> --to_status in_progress` to route\n   the change back to the **maker**, then emit an `ESCALATE` envelope carrying\n   your root-cause attribution (`[ROOT-CAUSE]` + evidence anchor from the V→I→G→I→L\n   cycle). The maker re-implements against your finding, not against the symptom.\n2. **When the implementation outran the spec** — run\n   `mcp__tonberry__drift_check --change_id \u003Cid> --checker vigil` **before** archive.\n   A mismatch (impl asserts behavior the Semantic spec never specified, or\n   vice-versa) is a `verify_fail` → transition back + `ESCALATE`.\n3. **You are the failure-path checker** — a distinct identity from the maker.\n   Your verify\u002Fdrift envelopes carry `from.eidolon = vigil`, never the maker's\n   identity.\n\n## Invariants\n\n- **maker ≠ checker** — VIGIL is the checker on the failure path; the change's\n  `maker` (e.g. Vivi) is always a distinct identity. Self-verified changes\n  violate the ESL C4 gate.\n- **Tonberry composes artifacts; you supply signals.** You provide the\n  root-cause attribution, the drift verdict, and the `verify_fail` reason;\n  tonberry writes the `change.json` transition and records enforcement.\n- **Graceful skip** — if `mcp__tonberry__*` tools are unavailable, run your\n  normal **V → I → G → I → L** cycle and emit findings\u002Fescalations the standard\n  way; **never hard-fail**. ESL is opt-in; VIGIL is EIIS-standalone-conformant\n  and works without tonberry.\n\n## Pending: ECL 2.1 verification-attestation (not yet implemented)\n\nECL v2.1 (Draft, adoption-gated — `spec\u002Fecl-2.1.md` §6.5.8) defines an\nOPTIONAL `ise.verification` sub-block: `{fresh_context, checker,\ntranscript_access}`, the wire-shape footprint of an independent verify pass.\nVIGIL is exactly the kind of distinct-identity checker that sub-block is\nbuilt to describe — you are the maker≠checker on this failure path already\n(ESL C4, above). Once ECL 2.1 is cut to Published (the gate: ≥3 shipped\nEidolons emitting the `ise` block) and VIGIL adopts it, your `ESCALATE`\nenvelope on this hop would carry `ise.verification = {fresh_context: true,\nchecker: \"vigil\", transcript_access: \"artifact-only\"}` (or `\"none\"`,\ndepending on what you were handed) alongside `ise.assertion_grade` — the\nMUST-level pairing rule that a `validated` grade actually has a\nfresh-context, different-checker verification behind it is owned by **ESL\n1.1 C8**, not ECL (ECL only shape-checks the sub-block, per §6.5.8.3).\n\n**This is documented as pending, not emitted.** ECL 2.1 is Draft; `ECL_VERSION`\nstays `2.0` and VIGIL's emitted envelopes do not carry `ise.verification` yet.\nNo code or template change accompanies this note — it exists so the next\nsweep that adopts 2.1 has the mapping already worked out.\n\n---\n\n*VIGIL — ESL Lifecycle Hop (failure path)*\n",{"name":5,"metadata":49,"description":7},{"phase":50,"methodology":51},"post-L","VIGIL","main","42ce382409178ece647a93f841a86119e8d74a65",".eidolons\u002Fvigil\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 vigil-esl-hop",{"tool":67,"command":68},"bunx","bunx skills add Rynaro\u002Fprisma --skill vigil-esl-hop",{"tool":70,"command":71},"pnpm","pnpm dlx skills add Rynaro\u002Fprisma --skill vigil-esl-hop","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FRynaro\u002Fprisma\u002Fblob\u002Fmain\u002F.eidolons\u002Fvigil\u002Fskills\u002Fesl-hop\u002FSKILL.md",true,[],[76,102,132,156,181,202],{"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,39,92,93,94,95,96,97,98,99,100,101],"verify","vivi verify incoming","verify incoming","run","sha-256","json","orchestrator","process","dispatch","message","upstream","id","receiver","block","ecl","hand","load","for","when",{"skillNo":103,"name":104,"nameZh":6,"description":105,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":106,"categories":107,"keywords":113,"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",[108],{"categoryNo":109,"categoryName":110,"taxonomyType":111,"taxonomyTypeDesc":112},"01JBSEEDCAT000000000000040","财务","PROFESSION","适用职业",[114,115,116,117,118,119,120,121,122,123,124,125,126,99,127,128,129,130,131,101],"parallel","tracks","parallel tracks","vivi parallel tracks","file","only","reflection","clean","plan phase","as","verifier","form","multi","worktree isolation","track","gating","single","phase",{"skillNo":133,"name":134,"nameZh":6,"description":135,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":136,"categories":137,"keywords":138,"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",[],[139,140,141,142,143,144,145,146,147,148,38,149,150,151,152,153,154,155,33,101],"methodology","vivi methodology","planning","escalation","Rules","use","evidence","complexity","delta","task","feature implementation","brownfield","full","requirements","feature","complete","thresholds",{"skillNo":157,"name":158,"nameZh":6,"description":159,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":160,"categories":161,"keywords":163,"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",[162],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[164,165,166,167,35,168,169,170,171,172,173,174,175,176,177,178,33,179,180,101],"memory","management","memory management","vivi memory management","commit","tasks","plan","write","never","files","route","across","local","end","session start","standalone","at",{"skillNo":182,"name":183,"nameZh":6,"description":184,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":185,"categories":186,"keywords":187,"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",[],[188,189,190,191,192,193,194,195,196,197,198,144,148,199,123,200,201,99,129,131],"loop","native","vivi loop native","oracle","sandbox","test","core","game","feedback","autonomous","fix","tests","fresh","host",{"skillNo":203,"name":204,"nameZh":6,"description":205,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":206,"categories":207,"keywords":208,"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",[],[209,210,211,142,212,213,144,214,215,155,216,217,218,99,180,219,220,131,101,221],"recovery","vivi failure recovery","debugging","classification","taxonomy","three","pattern","error","retries","random","break","bounded","same"]