[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71S2K2B1MEWA1E80K0842V8":3,"skill-same:01M71S2K2B1MEWA1E80K0842V8":71},{"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":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":48,"commitSha":49,"skillDirectory":50,"forksCount":51,"repositoryHtmlUrl":52,"repositoryHomepageUrl":6,"ownerHtmlUrl":53,"ownerBlogUrl":54,"ownerDescription":55,"updatedAt":56,"install":57,"resources":70},"01M71S2K2B1MEWA1E80K0842V8","vigil-graph",null,"Phase G (Graph) — builds the Information Dependency Graph from candidate fault nodes. Distinguishes propagated symptoms from root candidates using information flow, not temporal order; ranks root candidates by descendant count. Use after `fault-surface.md` is schema-valid with ≥1 candidate, before the Intervene phase.","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\u002Fgraph\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"vigil graph","graph","vigil","query","order","candidates","phase","candidate","inspect","with","information","valid","Nodes","dependency graph","schema","use","view","DEP","file","search","2026-11-10 13:02:02",false,"---\nname: vigil-graph\ndescription: Phase G (Graph) — builds the Information Dependency Graph from candidate fault nodes. Distinguishes propagated symptoms from root candidates using information flow, not temporal order; ranks root candidates by descendant count. Use after `fault-surface.md` is schema-valid with ≥1 candidate, before the Intervene phase.\nallowed-tools: view_file, search_symbol, graph_query, dep_graph_query, trace_inspect\nmetadata:\n  methodology: VIGIL\n  phase: G\n---\n\n# SKILL: Graph — build the Information Dependency Graph\n\n## When to use\n\nLoad when `fault-surface.md` has ≤8 candidates. Unload when `idg.md` identifies ≥1 `ROOT_CANDIDATE` or escalates with `[GAP]`.\n\n---\n\n## Contract\n\n| Field | Value |\n|-------|-------|\n| LLM calls permitted | For edge inference when AST\u002Fgraph queries are insufficient — with explicit evidence requirement |\n| Tool budget | ≤15% of mission budget |\n| Output | `idg.md` — schema-valid per `schemas\u002Fidg.v1.json` |\n| Critical rule | Every edge must cite trace evidence or AST-derived fact. Speculative edges are rejected. |\n\n---\n\n## Why Dependency Graph, Not Temporal Order\n\nThe most common attribution error in agentic debugging is treating the **earliest observed symptom** as the root cause. Research is unambiguous here: GraphTracer (arXiv:2510.10581) demonstrated +18.18% attribution accuracy over state-of-the-art temporal methods by using information dependency graphs; CHIEF (NeurIPS 2024) showed that hierarchical causal graphs outperform flat log analysis; the Lifecycle of Failures study (arXiv:2509.23735) quantified the lift at 46.3% → 65.8%.\n\n**The principle:** A failure propagates through a dependency chain. The first node to show the failure is usually downstream of where it originated. Temporal order tells you where to start looking; dependency order tells you where it came from.\n\n---\n\n## Node Construction\n\nEach candidate from `fault-surface.md` becomes a node. Each node records:\n\n```yaml\nid: N-001\ncandidate_ref: C-001           # from fault-surface.md\npath: \"app\u002Fflows\u002Frecord_vote.rb\"\nlines: \"42-78\"\nkind: code                     # code | test | config | schema | data | env | tool_output\nobserved_state: |\n  At the point of failure: ballot.token = nil\nexpected_state: |\n  At the point of failure: ballot.token = valid UUID\nobservation_source: |\n  trace:stack_frame_1 + assertion_message + view_file(record_vote.rb:56)\n```\n\n**Hard rule:** `observed_state` must come from the reproduction trace, stderr, or direct file inspection. `expected_state` comes from the test assertion, spec, or type signature. If either cannot be anchored, the node is not admissible — return to Isolate.\n\n---\n\n## Edge Construction\n\nEdges are **directed**, `A → B`, meaning \"B's state depends on A's state\". An edge requires one of:\n\n| Edge type | Evidence required |\n|-----------|-------------------|\n| **Data flow** | AST\u002Fcall-graph shows A's return value flows to B's input, OR trace shows A writes state that B reads |\n| **Control flow** | A's execution precedes and conditions B's execution within the failing path |\n| **Shared state** | A and B both read\u002Fwrite a named resource (DB table, global, file); trace confirms timing of access |\n| **Contract boundary** | A produces output that B consumes across a boundary (API call, message queue, RPC) |\n\n**Prohibited edges:**\n\n- Edges based on \"probably calls\" inference without AST or trace evidence\n- Edges from proximity alone (same file, same class, similar name)\n- Edges derived from unit test structure (what a test happens to set up is not a dependency)\n- Bidirectional edges (cycles handled separately — see below)\n\n### Edge-building procedure\n\nFor each node `B`:\n\n1. Use `dep_graph_query(readers_of: \u003CB's inputs>)` to find what writes B's state\n2. Use `dep_graph_query(callers_of: \u003CB's entry points>)` to find what triggers B\n3. Check trace for any node A whose output logically precedes B's state\n4. Record only edges with at least one anchor from steps 1-3\n\n---\n\n## Identifying Root Candidates\n\nA **root candidate** is a node in the graph with **zero incoming edges** among other candidate nodes.\n\nFormal procedure:\n\n1. Construct the graph `G` from `NODES` and `EDGES`.\n2. For each node `n`: if `in_degree_within_candidate_set(n) == 0`, mark as `ROOT_CANDIDATE`.\n3. Compute `descendant_count(n)` = number of candidate nodes reachable from `n`.\n4. Rank `ROOT_CANDIDATES` by `descendant_count` descending.\n\n**Interpretation:**\n\n- Top-ranked root candidate = the node whose failure could explain the most symptoms.\n- Low-ranked root candidate = may be real but explains fewer downstream failures; likely a compound-failure co-root.\n- Nodes with incoming edges = `SYMPTOM_NODES`. Mark with `[SYMPTOM]`. These are not root causes — do NOT generate hypotheses for them unless all root candidates are falsified.\n\n---\n\n## Handling Special Graph Shapes\n\n### Cycles\n\nIf the graph contains a cycle, one of two things is happening:\n\n1. **False edge** — one of the edges in the cycle is not evidence-backed. Re-audit; likely an inferred edge that should be removed.\n2. **Genuine feedback loop** — recursion, mutual callbacks, or circular state dependency. In this case: halt, emit `[DISPUTED]`, escalate to human review with the cycle documented. VIGIL does not auto-resolve feedback loops.\n\n### Disconnected subgraphs\n\nIf `fault-surface.md` candidates form 2+ disconnected components, this is a signal for `COMPOUND` failure. Each component has its own root candidate. Classify the mission as compound; the Intervene phase will address each component independently.\n\n### Single-node graph\n\nIf only one candidate survived Isolate, the graph has one node with no edges. It's the root candidate by default. Proceed to Intervene, but note in `idg.md` that no dependency analysis was performed (it was vacuous).\n\n### No root candidates\n\nEvery node has at least one incoming edge → the true root is outside the candidate set. Escalate to Isolate with expanded scope, or emit `[GAP]` and escalate upward.\n\n---\n\n## Writing `idg.md`\n\n```yaml\nmission_id: VIGIL-YYYYMMDD-NNN\nupstream_fault_surface: \u003Cref>\nnodes:\n  - id: N-001\n    candidate_ref: C-001\n    path: \"app\u002Fflows\u002Frecord_vote.rb\"\n    lines: \"42-78\"\n    kind: code\n    observed_state: \"ballot.token = nil at line 56\"\n    expected_state: \"ballot.token = valid UUID\"\n    observation_source: \"trace:stack_frame_1 + view_file\"\n    role: symptom       # symptom | root_candidate | both\n  - id: N-002\n    ...\nedges:\n  - from: N-003\n    to: N-001\n    kind: data_flow\n    evidence: \"dep_graph_query(writers_to: ballot.token) → N-003 at line 24\"\n  - from: N-002\n    to: N-001\n    kind: control_flow\n    evidence: \"trace shows N-002 executes immediately before N-001 within same call\"\nroot_candidates:\n  - node: N-003\n    descendant_count: 2\n    rank: 1\n  - node: N-004\n    descendant_count: 0\n    rank: 2\nsymptom_nodes: [N-001, N-002]\ngraph_shape: normal       # normal | cyclic | disconnected | single_node | no_roots\ndisputed:\n  - null                  # populated if cycles or evidence conflicts\ncompound_components:      # only if disconnected\n  - null\n```\n\n---\n\n## Pitfalls\n\n- **Treating the failing test's location as the root cause.** The test is the observer of failure, rarely its source.\n- **Asserting an edge because \"it makes sense.\"** Makes-sense is not evidence. Cite the AST query or the trace line.\n- **Ranking by suspicion instead of descendant count.** Suspicion is Isolate's job; Graph ranks by structural reach.\n- **Skipping `[SYMPTOM]` marking.** Downstream phases must not waste interventions on symptom nodes; mark them explicitly.\n\n---\n\n*VIGIL Phase G — structure beats sequence for attribution*\n","# SKILL: Graph — build the Information Dependency Graph\n\n## When to use\n\nLoad when `fault-surface.md` has ≤8 candidates. Unload when `idg.md` identifies ≥1 `ROOT_CANDIDATE` or escalates with `[GAP]`.\n\n---\n\n## Contract\n\n| Field | Value |\n|-------|-------|\n| LLM calls permitted | For edge inference when AST\u002Fgraph queries are insufficient — with explicit evidence requirement |\n| Tool budget | ≤15% of mission budget |\n| Output | `idg.md` — schema-valid per `schemas\u002Fidg.v1.json` |\n| Critical rule | Every edge must cite trace evidence or AST-derived fact. Speculative edges are rejected. |\n\n---\n\n## Why Dependency Graph, Not Temporal Order\n\nThe most common attribution error in agentic debugging is treating the **earliest observed symptom** as the root cause. Research is unambiguous here: GraphTracer (arXiv:2510.10581) demonstrated +18.18% attribution accuracy over state-of-the-art temporal methods by using information dependency graphs; CHIEF (NeurIPS 2024) showed that hierarchical causal graphs outperform flat log analysis; the Lifecycle of Failures study (arXiv:2509.23735) quantified the lift at 46.3% → 65.8%.\n\n**The principle:** A failure propagates through a dependency chain. The first node to show the failure is usually downstream of where it originated. Temporal order tells you where to start looking; dependency order tells you where it came from.\n\n---\n\n## Node Construction\n\nEach candidate from `fault-surface.md` becomes a node. Each node records:\n\n```yaml\nid: N-001\ncandidate_ref: C-001           # from fault-surface.md\npath: \"app\u002Fflows\u002Frecord_vote.rb\"\nlines: \"42-78\"\nkind: code                     # code | test | config | schema | data | env | tool_output\nobserved_state: |\n  At the point of failure: ballot.token = nil\nexpected_state: |\n  At the point of failure: ballot.token = valid UUID\nobservation_source: |\n  trace:stack_frame_1 + assertion_message + view_file(record_vote.rb:56)\n```\n\n**Hard rule:** `observed_state` must come from the reproduction trace, stderr, or direct file inspection. `expected_state` comes from the test assertion, spec, or type signature. If either cannot be anchored, the node is not admissible — return to Isolate.\n\n---\n\n## Edge Construction\n\nEdges are **directed**, `A → B`, meaning \"B's state depends on A's state\". An edge requires one of:\n\n| Edge type | Evidence required |\n|-----------|-------------------|\n| **Data flow** | AST\u002Fcall-graph shows A's return value flows to B's input, OR trace shows A writes state that B reads |\n| **Control flow** | A's execution precedes and conditions B's execution within the failing path |\n| **Shared state** | A and B both read\u002Fwrite a named resource (DB table, global, file); trace confirms timing of access |\n| **Contract boundary** | A produces output that B consumes across a boundary (API call, message queue, RPC) |\n\n**Prohibited edges:**\n\n- Edges based on \"probably calls\" inference without AST or trace evidence\n- Edges from proximity alone (same file, same class, similar name)\n- Edges derived from unit test structure (what a test happens to set up is not a dependency)\n- Bidirectional edges (cycles handled separately — see below)\n\n### Edge-building procedure\n\nFor each node `B`:\n\n1. Use `dep_graph_query(readers_of: \u003CB's inputs>)` to find what writes B's state\n2. Use `dep_graph_query(callers_of: \u003CB's entry points>)` to find what triggers B\n3. Check trace for any node A whose output logically precedes B's state\n4. Record only edges with at least one anchor from steps 1-3\n\n---\n\n## Identifying Root Candidates\n\nA **root candidate** is a node in the graph with **zero incoming edges** among other candidate nodes.\n\nFormal procedure:\n\n1. Construct the graph `G` from `NODES` and `EDGES`.\n2. For each node `n`: if `in_degree_within_candidate_set(n) == 0`, mark as `ROOT_CANDIDATE`.\n3. Compute `descendant_count(n)` = number of candidate nodes reachable from `n`.\n4. Rank `ROOT_CANDIDATES` by `descendant_count` descending.\n\n**Interpretation:**\n\n- Top-ranked root candidate = the node whose failure could explain the most symptoms.\n- Low-ranked root candidate = may be real but explains fewer downstream failures; likely a compound-failure co-root.\n- Nodes with incoming edges = `SYMPTOM_NODES`. Mark with `[SYMPTOM]`. These are not root causes — do NOT generate hypotheses for them unless all root candidates are falsified.\n\n---\n\n## Handling Special Graph Shapes\n\n### Cycles\n\nIf the graph contains a cycle, one of two things is happening:\n\n1. **False edge** — one of the edges in the cycle is not evidence-backed. Re-audit; likely an inferred edge that should be removed.\n2. **Genuine feedback loop** — recursion, mutual callbacks, or circular state dependency. In this case: halt, emit `[DISPUTED]`, escalate to human review with the cycle documented. VIGIL does not auto-resolve feedback loops.\n\n### Disconnected subgraphs\n\nIf `fault-surface.md` candidates form 2+ disconnected components, this is a signal for `COMPOUND` failure. Each component has its own root candidate. Classify the mission as compound; the Intervene phase will address each component independently.\n\n### Single-node graph\n\nIf only one candidate survived Isolate, the graph has one node with no edges. It's the root candidate by default. Proceed to Intervene, but note in `idg.md` that no dependency analysis was performed (it was vacuous).\n\n### No root candidates\n\nEvery node has at least one incoming edge → the true root is outside the candidate set. Escalate to Isolate with expanded scope, or emit `[GAP]` and escalate upward.\n\n---\n\n## Writing `idg.md`\n\n```yaml\nmission_id: VIGIL-YYYYMMDD-NNN\nupstream_fault_surface: \u003Cref>\nnodes:\n  - id: N-001\n    candidate_ref: C-001\n    path: \"app\u002Fflows\u002Frecord_vote.rb\"\n    lines: \"42-78\"\n    kind: code\n    observed_state: \"ballot.token = nil at line 56\"\n    expected_state: \"ballot.token = valid UUID\"\n    observation_source: \"trace:stack_frame_1 + view_file\"\n    role: symptom       # symptom | root_candidate | both\n  - id: N-002\n    ...\nedges:\n  - from: N-003\n    to: N-001\n    kind: data_flow\n    evidence: \"dep_graph_query(writers_to: ballot.token) → N-003 at line 24\"\n  - from: N-002\n    to: N-001\n    kind: control_flow\n    evidence: \"trace shows N-002 executes immediately before N-001 within same call\"\nroot_candidates:\n  - node: N-003\n    descendant_count: 2\n    rank: 1\n  - node: N-004\n    descendant_count: 0\n    rank: 2\nsymptom_nodes: [N-001, N-002]\ngraph_shape: normal       # normal | cyclic | disconnected | single_node | no_roots\ndisputed:\n  - null                  # populated if cycles or evidence conflicts\ncompound_components:      # only if disconnected\n  - null\n```\n\n---\n\n## Pitfalls\n\n- **Treating the failing test's location as the root cause.** The test is the observer of failure, rarely its source.\n- **Asserting an edge because \"it makes sense.\"** Makes-sense is not evidence. Cite the AST query or the trace line.\n- **Ranking by suspicion instead of descendant count.** Suspicion is Isolate's job; Graph ranks by structural reach.\n- **Skipping `[SYMPTOM]` marking.** Downstream phases must not waste interventions on symptom nodes; mark them explicitly.\n\n---\n\n*VIGIL Phase G — structure beats sequence for attribution*\n",{"name":5,"metadata":44,"description":7,"allowed-tools":47},{"phase":45,"methodology":46},"G","VIGIL","view_file, search_symbol, graph_query, dep_graph_query, trace_inspect","main","42ce382409178ece647a93f841a86119e8d74a65",".eidolons\u002Fvigil\u002Fskills\u002Fgraph",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":58,"prompt":68,"zipAvailable":69},[59,62,65],{"tool":60,"command":61},"npx","npx skills add Rynaro\u002Fprisma --skill vigil-graph",{"tool":63,"command":64},"bunx","bunx skills add Rynaro\u002Fprisma --skill vigil-graph",{"tool":66,"command":67},"pnpm","pnpm dlx skills add Rynaro\u002Fprisma --skill vigil-graph","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FRynaro\u002Fprisma\u002Fblob\u002Fmain\u002F.eidolons\u002Fvigil\u002Fskills\u002Fgraph\u002FSKILL.md",true,[],[72,99,127,152,182,203],{"skillNo":73,"name":74,"nameZh":6,"description":75,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":76,"categories":77,"keywords":78,"publishedAt":39},"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",[],[79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98],"verify","vivi verify incoming","verify incoming","run","sha-256","json","orchestrator","process","dispatch","back","message","upstream","id","receiver","block","ecl","hand","load","for","when",{"skillNo":100,"name":101,"nameZh":6,"description":102,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":103,"categories":104,"keywords":110,"publishedAt":39},"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",[105],{"categoryNo":106,"categoryName":107,"taxonomyType":108,"taxonomyTypeDesc":109},"01JBSEEDCAT000000000000040","财务","PROFESSION","适用职业",[111,112,113,114,37,115,116,117,118,119,120,121,122,96,123,124,125,126,25,98],"parallel","tracks","parallel tracks","vivi parallel tracks","only","reflection","clean","plan phase","as","verifier","form","multi","worktree isolation","track","gating","single",{"skillNo":128,"name":129,"nameZh":6,"description":130,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":131,"categories":132,"keywords":133,"publishedAt":39},"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",[],[134,135,136,137,138,34,139,140,141,142,143,144,145,146,147,148,149,150,151,98],"methodology","vivi methodology","planning","escalation","Rules","evidence","complexity","delta","task","cycle","feature implementation","brownfield","full","requirements","feature","complete","thresholds","you",{"skillNo":153,"name":154,"nameZh":6,"description":155,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":156,"categories":157,"keywords":163,"publishedAt":39},"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",[158],{"categoryNo":159,"categoryName":160,"taxonomyType":161,"taxonomyTypeDesc":162},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[164,165,166,167,168,169,170,171,172,173,174,175,176,177,178,179,151,180,181,98],"memory","management","memory management","vivi memory management","MCP","commit","tasks","plan","write","never","files","route","across","local","end","session start","standalone","at",{"skillNo":183,"name":184,"nameZh":6,"description":185,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":186,"categories":187,"keywords":188,"publishedAt":39},"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",[],[189,190,191,192,193,194,195,196,197,198,199,34,142,200,119,201,202,96,125,25],"loop","native","vivi loop native","oracle","sandbox","test","core","game","feedback","autonomous","fix","tests","fresh","host",{"skillNo":204,"name":205,"nameZh":6,"description":206,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":207,"categories":208,"keywords":209,"publishedAt":39},"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",[],[210,211,212,137,213,214,34,215,216,150,217,218,219,96,181,220,221,25,98,222],"recovery","vivi failure recovery","debugging","classification","taxonomy","three","pattern","error","retries","random","break","bounded","same"]