[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71S1M73T4E2XYTYBB49F401":3,"skill-same:01M71S1M73T4E2XYTYBB49F401":80},{"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":28,"publishedAt":49,"linkOnly":50,"markdownContent":51,"markdownBody":52,"frontMatter":53,"refName":57,"commitSha":58,"skillDirectory":59,"forksCount":60,"repositoryHtmlUrl":61,"repositoryHomepageUrl":6,"ownerHtmlUrl":62,"ownerBlogUrl":63,"ownerDescription":64,"updatedAt":65,"install":66,"resources":79},"01M71S1M73T4E2XYTYBB49F401","idg-composition",null,"Governs how the Scribe transforms context into structured, grounded prose during the Draft phase. Use when starting any document composition, loading templates, applying structural markers, or writing section by section with topological ordering and envelope-aware intake.","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\u002Fidg\u002Fskills\u002Fcomposition\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48],"idg composition","Composition","draft","when","phase","section","with","loading","transforms","markers","structural","writing","prose","document","use","context","how","templates","scribe","intake","2026-11-10 13:02:02",false,"---\nname: idg-composition\ndescription: Governs how the Scribe transforms context into structured, grounded prose during the Draft phase. Use when starting any document composition, loading templates, applying structural markers, or writing section by section with topological ordering and envelope-aware intake.\nmetadata:\n  methodology: IDG\n  phase: D\n---\n\n# Composition Methodology\n\nLoaded during the Draft phase. Governs how the Scribe transforms context into structured prose.\n\n## When to use\n\nLoad this skill when entering the Draft (D) phase of the IDG cycle — specifically when beginning any document composition (session-chronicle, ADR, runbook, change-narrative, or custom). Also load it when applying structural markers, building section skeletons from templates, or checking ECL envelope sidecars during intake. Do NOT load upfront; trigger on demand at Draft entry.\n\n---\n\n## Memory Recall (Phase I — intake entry)\n\nAt the start of Phase I, before classifying the source artefact, execute:\n\n```\nmcp__crystalium__recall(\n  scope    = { project: \u003Ccwd-project>, agent_class_visibility: \"idg\" },\n  query    = \u003Cdocument type + source artifact summary + objective>,\n  k        = 5,\n  layers   = [\"semantic\", \"episodic\", \"procedural\"]\n)\n```\n\nFold any relevant hits (prior terminology conventions, document patterns, structural\ndecisions for this project) into intake context before building the document skeleton.\nThe **semantic** layer is especially valuable for IDG: promoted conventions from past\nchronicles sharpen terminology consistency across documents.\n\n**Graceful skip:** if `mcp__crystalium__*` tools are unavailable (CRYSTALIUM not\ninstalled), proceed without memory — never hard-fail. IDG is EIIS-standalone-\nconformant and works without CRYSTALIUM.\n\n---\n\n## Envelope-Aware Intake (ECL v2.0)\n\nWhen classifying a source artefact during the **I — Intake** phase, check whether the artefact arrived with an ECL sidecar envelope. The four steps below keep the same intake numbering IDG has always used — but validation, integrity, and contract-conformance checks are no longer re-implemented here. They are a single **blocking** gate owned by `skills\u002Fverify-incoming\u002FSKILL.md` (ECL §6.2.2, converged with the canonical shape (Kupo reference implementation)) — **one gate, not two**.\n\n### Step 1 — Detect\n\nLook for a file whose name is `\u003Cpayload-basename>.envelope.json` in the same location as the payload. Examples:\n\n- Payload: `apivr-completion-report.md` → Sidecar: `apivr-completion-report.md.envelope.json`\n- Payload: `root-cause-report.md` → Sidecar: `root-cause-report.md.envelope.json`\n\nIf **no sidecar is found**, proceed normally. In the provenance block note: \"no envelope; ECL verification skipped.\" No CHT score impact.\n\n### Step 2 — Validate\n\nSchema validation of the sidecar against the vendored ECL v2.0 envelope schema (`schemas\u002Fecl-envelope.v2.json`; `schemas\u002Fecl-envelope.v1.json` retained for the ECL §7.3 compatibility window) is owned by `skills\u002Fverify-incoming\u002FSKILL.md`. Load it now — do not validate the sidecar inline here.\n\n### Step 3 — Recompute and compare sha256\n\nsha256 recomputation against `envelope.integrity.value` is likewise owned by `skills\u002Fverify-incoming\u002FSKILL.md`. A mismatch is a **blocking REFUSE** at the gate, not a local `[DISPUTED]` marker — Draft-phase composition never sees a payload whose integrity hasn't already been confirmed.\n\n### Step 4 — Check performative\n\nPerformative and `artifact.kind` conformance against the declared inbound edge (`contracts\u002F\u003Cfrom>-to-idg.yaml`) is validated by `skills\u002Fverify-incoming\u002FSKILL.md`. An out-of-contract hand-off is refused at the gate before Intake classification begins — it never reaches this step as a live payload.\n\n### Record and trace\n\nOnce `skills\u002Fverify-incoming\u002FSKILL.md` has recorded `verify_pass` (a failed gate refuses before Intake starts, so `verify_fail` never reaches this point), carry its outcome into working memory:\n\n```\necl_verification:\n  message_id: \u003Cuuid>\n  thread_id: \u003Cuuid>\n  from: \u003Ceidolon slug>\n  performative: \u003Cvalue>\n  outcome: verify_pass | skipped\n```\n\nThis record surfaces in the Gate phase and populates the chronicle's Communication Lineage section and provenance block. If the verified envelope carries `ise.assertion_grade` (ECL v2.0 §6.5), surface it alongside — the provenance block should let the reader distinguish upstream work that was mechanically `validated` from work that was only `self-attested`. See `skills\u002Fverify-incoming\u002FSKILL.md`.\n\n**IDG does not, and shall not, fetch any envelope referenced via `input_handles`**. P0 forbids retrieval. If a handle resolves to a path already in-context (the requester has explicitly provided the file), reading it is permitted. Otherwise mark `[GAP]`.\n\n---\n\n## Section-Level Composition\n\nWrite one section at a time, in topological order. For each section:\n\n1. **Scope the section** — what question does this section answer for the reader?\n2. **Select context** — pull only the source material relevant to this section. Discard the rest for now.\n3. **Draft** — write the section. Ground every claim.\n4. **Cite** — tag each factual statement with its source artifact (inline or footnote, per template convention).\n5. **Mark** — apply structural markers where appropriate.\n6. **Transition** — write the bridge to the next section if the document type requires narrative flow.\n\n### Context Budget Rule\n\nWhen composing a section, keep injected context to the minimum necessary. If the full source material for a section exceeds ~2,000 tokens, summarize the supporting evidence and keep the original references as citations. This preserves working space for the model to reason about composition rather than drowning in raw material.\n\n### Topological Section Order\n\nWrite sections that establish context before sections that depend on it:\n\n- Background\u002FContext → Decisions → Consequences\n- Problem Statement → Steps Taken → Outcomes → Lessons\n- Summary → Details → Follow-ups\n\nIf sections have no dependency relationship, write them in the template's default order.\n\n---\n\n## Structural Markers Reference\n\nMarkers are the Scribe's primary value-add. They transform passive documentation into actionable intelligence.\n\n### `[DECISION]`\nA choice was made. Always include:\n- **What** was decided\n- **Why** (rationale, even if brief)\n- **Alternatives rejected** (if available in source material; `[GAP]` if not)\n\n```markdown\n[DECISION] Adopted Redis for session caching over Memcached.\nRationale: Redis supports data structures needed for rate-limiting (sorted sets).\nRejected: Memcached (no sorted sets), DynamoDB (latency budget exceeded).\n```\n\n### `[ACTION]`\nSomething needs to happen. Include:\n- **What** needs doing\n- **Owner** (if known; `TBD` if not)\n- **Deadline or trigger** (if known)\n\n```markdown\n[ACTION] Update Terraform modules to provision Redis cluster. Owner: Platform team. Trigger: Before Sprint 14 deployment.\n```\n\n### `[DISPUTED]`\nSource material conflicts. Present both sides neutrally:\n\n```markdown\n[DISPUTED] Load test results disagree on p99 latency.\n- Agent A's benchmark: 12ms p99 under 10k RPS\n- Manual test by engineer: 45ms p99 under 8k RPS\nResolution: Not yet determined. Recommend re-running with standardized methodology.\n```\n\n### `[GAP]`\nExpected information is missing from provided context:\n\n```markdown\n[GAP] Rollback procedure not documented in session artifacts. Requested from Ops team.\n```\n\n---\n\n## Writing Standards\n\n### Grounding Rules\n\n| Rule | Detail |\n|------|--------|\n| **No unsourced claims** | Every factual assertion must trace to a specific source artifact |\n| **Distinguish inference from fact** | If the Scribe infers something (e.g., likely rationale for a decision), prefix with \"Likely:\" or \"Inferred:\" |\n| **Preserve source fidelity** | Do not editorialize or interpret beyond what sources support |\n| **Quote sparingly** | Paraphrase unless exact wording is load-bearing (error messages, commit messages, CLI output) |\n\n### Audience Adaptation\n\n| Audience | Depth | Jargon | Examples |\n|----------|-------|--------|----------|\n| Engineers on the team | Full technical depth | Domain terms OK without definition | Code snippets, file paths, CLI commands |\n| Engineering leadership | Architectural level | Define non-obvious acronyms | Diagrams, trade-off summaries, impact statements |\n| Cross-functional | Business outcomes | Minimal jargon, explain technical terms | User-facing impact, timelines, risk levels |\n\nDetermine audience from the document type default or explicit instruction. When uncertain, default to \"Engineers on the team.\"\n\n### Tone\n\n- **Active voice** preferred (\"The team decided...\" not \"It was decided...\")\n- **Concrete over abstract** (\"Added 3 retry attempts with exponential backoff\" not \"Improved error handling\")\n- **Terse over verbose** — every sentence should earn its place\n- **No hedging without cause** — \"The migration completed successfully\" not \"The migration appears to have completed successfully\" (unless completion is genuinely uncertain)\n\n---\n\n## Section Composition Checklist\n\nBefore moving to the next section, verify:\n\n- [ ] Section answers the question it was scoped to answer\n- [ ] Every factual claim has a source citation\n- [ ] Structural markers applied where appropriate\n- [ ] Tone matches audience level\n- [ ] No information fabricated or assumed without marking\n- [ ] Transition to next section is clear (if applicable)\n\n---\n\n*Scribe — Composition Skill*\n","# Composition Methodology\n\nLoaded during the Draft phase. Governs how the Scribe transforms context into structured prose.\n\n## When to use\n\nLoad this skill when entering the Draft (D) phase of the IDG cycle — specifically when beginning any document composition (session-chronicle, ADR, runbook, change-narrative, or custom). Also load it when applying structural markers, building section skeletons from templates, or checking ECL envelope sidecars during intake. Do NOT load upfront; trigger on demand at Draft entry.\n\n---\n\n## Memory Recall (Phase I — intake entry)\n\nAt the start of Phase I, before classifying the source artefact, execute:\n\n```\nmcp__crystalium__recall(\n  scope    = { project: \u003Ccwd-project>, agent_class_visibility: \"idg\" },\n  query    = \u003Cdocument type + source artifact summary + objective>,\n  k        = 5,\n  layers   = [\"semantic\", \"episodic\", \"procedural\"]\n)\n```\n\nFold any relevant hits (prior terminology conventions, document patterns, structural\ndecisions for this project) into intake context before building the document skeleton.\nThe **semantic** layer is especially valuable for IDG: promoted conventions from past\nchronicles sharpen terminology consistency across documents.\n\n**Graceful skip:** if `mcp__crystalium__*` tools are unavailable (CRYSTALIUM not\ninstalled), proceed without memory — never hard-fail. IDG is EIIS-standalone-\nconformant and works without CRYSTALIUM.\n\n---\n\n## Envelope-Aware Intake (ECL v2.0)\n\nWhen classifying a source artefact during the **I — Intake** phase, check whether the artefact arrived with an ECL sidecar envelope. The four steps below keep the same intake numbering IDG has always used — but validation, integrity, and contract-conformance checks are no longer re-implemented here. They are a single **blocking** gate owned by `skills\u002Fverify-incoming\u002FSKILL.md` (ECL §6.2.2, converged with the canonical shape (Kupo reference implementation)) — **one gate, not two**.\n\n### Step 1 — Detect\n\nLook for a file whose name is `\u003Cpayload-basename>.envelope.json` in the same location as the payload. Examples:\n\n- Payload: `apivr-completion-report.md` → Sidecar: `apivr-completion-report.md.envelope.json`\n- Payload: `root-cause-report.md` → Sidecar: `root-cause-report.md.envelope.json`\n\nIf **no sidecar is found**, proceed normally. In the provenance block note: \"no envelope; ECL verification skipped.\" No CHT score impact.\n\n### Step 2 — Validate\n\nSchema validation of the sidecar against the vendored ECL v2.0 envelope schema (`schemas\u002Fecl-envelope.v2.json`; `schemas\u002Fecl-envelope.v1.json` retained for the ECL §7.3 compatibility window) is owned by `skills\u002Fverify-incoming\u002FSKILL.md`. Load it now — do not validate the sidecar inline here.\n\n### Step 3 — Recompute and compare sha256\n\nsha256 recomputation against `envelope.integrity.value` is likewise owned by `skills\u002Fverify-incoming\u002FSKILL.md`. A mismatch is a **blocking REFUSE** at the gate, not a local `[DISPUTED]` marker — Draft-phase composition never sees a payload whose integrity hasn't already been confirmed.\n\n### Step 4 — Check performative\n\nPerformative and `artifact.kind` conformance against the declared inbound edge (`contracts\u002F\u003Cfrom>-to-idg.yaml`) is validated by `skills\u002Fverify-incoming\u002FSKILL.md`. An out-of-contract hand-off is refused at the gate before Intake classification begins — it never reaches this step as a live payload.\n\n### Record and trace\n\nOnce `skills\u002Fverify-incoming\u002FSKILL.md` has recorded `verify_pass` (a failed gate refuses before Intake starts, so `verify_fail` never reaches this point), carry its outcome into working memory:\n\n```\necl_verification:\n  message_id: \u003Cuuid>\n  thread_id: \u003Cuuid>\n  from: \u003Ceidolon slug>\n  performative: \u003Cvalue>\n  outcome: verify_pass | skipped\n```\n\nThis record surfaces in the Gate phase and populates the chronicle's Communication Lineage section and provenance block. If the verified envelope carries `ise.assertion_grade` (ECL v2.0 §6.5), surface it alongside — the provenance block should let the reader distinguish upstream work that was mechanically `validated` from work that was only `self-attested`. See `skills\u002Fverify-incoming\u002FSKILL.md`.\n\n**IDG does not, and shall not, fetch any envelope referenced via `input_handles`**. P0 forbids retrieval. If a handle resolves to a path already in-context (the requester has explicitly provided the file), reading it is permitted. Otherwise mark `[GAP]`.\n\n---\n\n## Section-Level Composition\n\nWrite one section at a time, in topological order. For each section:\n\n1. **Scope the section** — what question does this section answer for the reader?\n2. **Select context** — pull only the source material relevant to this section. Discard the rest for now.\n3. **Draft** — write the section. Ground every claim.\n4. **Cite** — tag each factual statement with its source artifact (inline or footnote, per template convention).\n5. **Mark** — apply structural markers where appropriate.\n6. **Transition** — write the bridge to the next section if the document type requires narrative flow.\n\n### Context Budget Rule\n\nWhen composing a section, keep injected context to the minimum necessary. If the full source material for a section exceeds ~2,000 tokens, summarize the supporting evidence and keep the original references as citations. This preserves working space for the model to reason about composition rather than drowning in raw material.\n\n### Topological Section Order\n\nWrite sections that establish context before sections that depend on it:\n\n- Background\u002FContext → Decisions → Consequences\n- Problem Statement → Steps Taken → Outcomes → Lessons\n- Summary → Details → Follow-ups\n\nIf sections have no dependency relationship, write them in the template's default order.\n\n---\n\n## Structural Markers Reference\n\nMarkers are the Scribe's primary value-add. They transform passive documentation into actionable intelligence.\n\n### `[DECISION]`\nA choice was made. Always include:\n- **What** was decided\n- **Why** (rationale, even if brief)\n- **Alternatives rejected** (if available in source material; `[GAP]` if not)\n\n```markdown\n[DECISION] Adopted Redis for session caching over Memcached.\nRationale: Redis supports data structures needed for rate-limiting (sorted sets).\nRejected: Memcached (no sorted sets), DynamoDB (latency budget exceeded).\n```\n\n### `[ACTION]`\nSomething needs to happen. Include:\n- **What** needs doing\n- **Owner** (if known; `TBD` if not)\n- **Deadline or trigger** (if known)\n\n```markdown\n[ACTION] Update Terraform modules to provision Redis cluster. Owner: Platform team. Trigger: Before Sprint 14 deployment.\n```\n\n### `[DISPUTED]`\nSource material conflicts. Present both sides neutrally:\n\n```markdown\n[DISPUTED] Load test results disagree on p99 latency.\n- Agent A's benchmark: 12ms p99 under 10k RPS\n- Manual test by engineer: 45ms p99 under 8k RPS\nResolution: Not yet determined. Recommend re-running with standardized methodology.\n```\n\n### `[GAP]`\nExpected information is missing from provided context:\n\n```markdown\n[GAP] Rollback procedure not documented in session artifacts. Requested from Ops team.\n```\n\n---\n\n## Writing Standards\n\n### Grounding Rules\n\n| Rule | Detail |\n|------|--------|\n| **No unsourced claims** | Every factual assertion must trace to a specific source artifact |\n| **Distinguish inference from fact** | If the Scribe infers something (e.g., likely rationale for a decision), prefix with \"Likely:\" or \"Inferred:\" |\n| **Preserve source fidelity** | Do not editorialize or interpret beyond what sources support |\n| **Quote sparingly** | Paraphrase unless exact wording is load-bearing (error messages, commit messages, CLI output) |\n\n### Audience Adaptation\n\n| Audience | Depth | Jargon | Examples |\n|----------|-------|--------|----------|\n| Engineers on the team | Full technical depth | Domain terms OK without definition | Code snippets, file paths, CLI commands |\n| Engineering leadership | Architectural level | Define non-obvious acronyms | Diagrams, trade-off summaries, impact statements |\n| Cross-functional | Business outcomes | Minimal jargon, explain technical terms | User-facing impact, timelines, risk levels |\n\nDetermine audience from the document type default or explicit instruction. When uncertain, default to \"Engineers on the team.\"\n\n### Tone\n\n- **Active voice** preferred (\"The team decided...\" not \"It was decided...\")\n- **Concrete over abstract** (\"Added 3 retry attempts with exponential backoff\" not \"Improved error handling\")\n- **Terse over verbose** — every sentence should earn its place\n- **No hedging without cause** — \"The migration completed successfully\" not \"The migration appears to have completed successfully\" (unless completion is genuinely uncertain)\n\n---\n\n## Section Composition Checklist\n\nBefore moving to the next section, verify:\n\n- [ ] Section answers the question it was scoped to answer\n- [ ] Every factual claim has a source citation\n- [ ] Structural markers applied where appropriate\n- [ ] Tone matches audience level\n- [ ] No information fabricated or assumed without marking\n- [ ] Transition to next section is clear (if applicable)\n\n---\n\n*Scribe — Composition Skill*\n",{"name":5,"metadata":54,"description":7},{"phase":55,"methodology":56},"D","IDG","main","42ce382409178ece647a93f841a86119e8d74a65",".eidolons\u002Fidg\u002Fskills\u002Fcomposition",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":67,"prompt":77,"zipAvailable":78},[68,71,74],{"tool":69,"command":70},"npx","npx skills add Rynaro\u002Fprisma --skill idg-composition",{"tool":72,"command":73},"bunx","bunx skills add Rynaro\u002Fprisma --skill idg-composition",{"tool":75,"command":76},"pnpm","pnpm dlx skills add Rynaro\u002Fprisma --skill idg-composition","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FRynaro\u002Fprisma\u002Fblob\u002Fmain\u002F.eidolons\u002Fidg\u002Fskills\u002Fcomposition\u002FSKILL.md",true,[],[81,107,134,159,187,208],{"skillNo":82,"name":83,"nameZh":6,"description":84,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":85,"categories":86,"keywords":87,"publishedAt":49},"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",[],[88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,32],"verify","vivi verify incoming","verify incoming","run","sha-256","json","orchestrator","process","dispatch","back","message","upstream","id","receiver","block","ecl","hand","load","for",{"skillNo":108,"name":109,"nameZh":6,"description":110,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":111,"categories":112,"keywords":116,"publishedAt":49},"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",[113],{"categoryNo":114,"categoryName":115,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000040","财务",[117,118,119,120,121,122,123,124,125,126,127,128,129,105,130,131,132,133,33,32],"parallel","tracks","parallel tracks","vivi parallel tracks","file","only","reflection","clean","plan phase","as","verifier","form","multi","worktree isolation","track","gating","single",{"skillNo":135,"name":136,"nameZh":6,"description":137,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":138,"categories":139,"keywords":140,"publishedAt":49},"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",[],[141,142,143,144,145,43,146,147,148,149,150,151,152,153,154,155,156,157,158,32],"methodology","vivi methodology","planning","escalation","Rules","evidence","complexity","delta","task","cycle","feature implementation","brownfield","full","requirements","feature","complete","thresholds","you",{"skillNo":160,"name":161,"nameZh":6,"description":162,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":163,"categories":164,"keywords":168,"publishedAt":49},"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",[165],{"categoryNo":166,"categoryName":167,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[169,170,171,172,173,174,175,176,177,178,179,180,181,182,183,184,158,185,186,32],"memory","management","memory management","vivi memory management","MCP","commit","tasks","plan","write","never","files","route","across","local","end","session start","standalone","at",{"skillNo":188,"name":189,"nameZh":6,"description":190,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":191,"categories":192,"keywords":193,"publishedAt":49},"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",[],[194,195,196,197,198,199,200,201,202,203,204,43,149,205,126,206,207,105,132,33],"loop","native","vivi loop native","oracle","sandbox","test","core","game","feedback","autonomous","fix","tests","fresh","host",{"skillNo":209,"name":210,"nameZh":6,"description":211,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":212,"categories":213,"keywords":214,"publishedAt":49},"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",[],[215,216,217,144,218,219,43,220,221,157,222,223,224,105,186,225,226,33,32,227],"recovery","vivi failure recovery","debugging","classification","taxonomy","three","pattern","error","retries","random","break","bounded","same"]