[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71S23BNKYWP3P2JKAXHPK44":3,"skill-same:01M71S23BNKYWP3P2JKAXHPK44":69},{"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":46,"commitSha":47,"skillDirectory":48,"forksCount":49,"repositoryHtmlUrl":50,"repositoryHomepageUrl":6,"ownerHtmlUrl":51,"ownerBlogUrl":52,"ownerDescription":53,"updatedAt":54,"install":55,"resources":68},"01M71S23BNKYWP3P2JKAXHPK44","ramza-discover",null,"Open-ended requirements & stakeholder\u002Fgoal elicitation BEFORE CLARIFY. Use when the GOAL itself is underspecified (IDEA\u002FSTRATEGIC intent) — distinct from CLARIFY, which disambiguates an already-known goal. Read-only, bounded, mechanically countable coverage gate; produces an elicitation summary, never a plan.","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\u002Framza\u002Fskills\u002Fdiscover\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"ramza discover","discover","intent","the goal","when","which","read-only","strategic","elicitation","requirements","open","gate","goal","only","never","use","coverage","read","clarify","plan","2026-11-10 13:02:02",false,"---\nname: ramza-discover\ndescription: \"Open-ended requirements & stakeholder\u002Fgoal elicitation BEFORE CLARIFY. Use when the GOAL itself is underspecified (IDEA\u002FSTRATEGIC intent) — distinct from CLARIFY, which disambiguates an already-known goal. Read-only, bounded, mechanically countable coverage gate; produces an elicitation summary, never a plan.\"\nmetadata:\n  methodology: RAMZA\n---\n\n# RAMZA — DISCOVER Skill (pre-CLARIFY elicitation)\n\nUse this skill when the request's **objective itself is unknown or latent** — not\nmerely when the spec details are ambiguous. DISCOVER runs BEFORE CLARIFY and hands\nCLARIFY a structured elicitation summary.\n\n## When to run DISCOVER (vs CLARIFY)\n\n| | DISCOVER | CLARIFY |\n|---|---|---|\n| **Precondition** | Goal is unknown \u002F latent | Goal is known; spec details ambiguous |\n| **Intent types** | `IDEA`, `STRATEGIC`, any under-GOALED request | `REQUEST`, `CHANGE`, `BUG_SPEC` |\n| **Question style** | Open-ended discovery of goals, stakeholders, success | ≤3 plan-shape disambiguation questions |\n| **Output** | Elicitation summary → handed to CLARIFY | WHO\u002FWHAT\u002FWHY\u002FCONSTRAINTS parse → Scope |\n\n**Boundary rule:** DISCOVER = \"what are we even trying to achieve, and for whom?\"\nCLARIFY = \"the goal is clear; which of these plan shapes do you want?\" Do NOT run\nDISCOVER on a well-GOALED request — go straight to CLARIFY.\n\nWhy this exists: specification\u002Fsystem-design is the dominant multi-agent failure\ncategory (MAST — ~43.8% of failures), and multi-agent systems collapse toward ~30%\naccuracy when latent stakeholder knowledge is never actively elicited (HiddenBench).\nCLARIFY alone cannot close this — its ≤3 plan-shape contract assumes the goal is\nalready known. This sub-mode is inherited unchanged from SPECTRA (see\n`DESIGN-RATIONALE.md` D2 — the discipline spine is the part the audits praised;\nDISCOVER's failure mode was never its elicitation design).\n\n## Elicitation protocol (bounded, read-only)\n\nSurface, do not assume. For each axis, record what is known and emit a `[GAP]`\nmarker for each unknown rather than inventing an answer:\n\n1. **Stakeholders** — Who requests this? Who is affected? Who approves\u002Freviews?\n   Map the approval chain. `[GAP]` for each unidentified party.\n2. **Latent goals** — What is the underlying outcome (not the surface ask)?\n   What is the \"job to be done\"? Distinguish the stated request from the real goal.\n3. **Success metrics** — How will we know it worked? Target metric + current baseline\n   (e.g. \"p95 \u003C 200ms, currently 800ms\"). `[GAP]` when no measurable criterion exists.\n4. **Hard constraints** — Budget, deadline, tech-stack lock-in, compliance, platform.\n5. **Non-goals** — What is explicitly OUT of scope? Surface these early to prevent\n   scope creep downstream.\n\n## Bound (no unbounded interview loop)\n\nDISCOVER is elicitation + synthesis, NOT an interactive multi-turn interview agent.\n- Produce ONE elicitation summary in a single pass from available context + the host\n  conversation. Do not loop.\n- If coverage is low (≥2 of the 5 axes are `[GAP]` with no resolution path),\n  **escalate to the human** with the gap list — do not fabricate goals to proceed.\n- DISCOVER NEVER produces a plan and NEVER writes code. Its sole output is the\n  elicitation summary handed to CLARIFY.\n\n## Mechanical coverage contract\n\nThe 5 axes are line items a host can count mechanically — no re-reading DISCOVER's\nreasoning required:\n\n- Each axis line in the summary below is exactly one of two states: **resolved**\n  (the line contains no `[GAP]` token) or **unresolved** (the line contains the\n  literal token `[GAP]`).\n- `unresolved_count` = the number of axis lines (Stakeholders \u002F Latent goal \u002F\n  Success metrics \u002F Hard constraints \u002F Non-goals — the first 5 checklist lines\n  only, not the `Open gaps` \u002F `Coverage` lines that restate them) containing\n  `[GAP]`.\n- **Contract:** `unresolved_count >= 2` ⇒ **ESCALATE to human**, do not hand off\n  to CLARIFY. `unresolved_count \u003C= 1` ⇒ hand off to CLARIFY normally.\n- This is a mechanical count (e.g. `grep -c '\\[GAP\\]'` over the 5 checklist\n  lines), not a model self-assessment — a host or lint step can enforce the\n  ≥2-unresolved rule without re-deriving DISCOVER's judgment, exactly the same\n  posture as `ramza-lint`'s grep-level structural checks.\n\n## Output: elicitation summary\n\nA compact structured checklist (lives under `.spectra\u002F` like all RAMZA output).\nEach of the first 5 lines is the mechanically-countable unit described above:\n\n```\n## DISCOVER — Elicitation Summary\n- [ ] Stakeholders: \u003Clist | [GAP]>\n- [ ] Latent goal: \u003Crestated outcome | [GAP]>\n- [ ] Success metrics: \u003Cmetric + baseline | [GAP]>\n- [ ] Hard constraints: \u003Clist>\n- [ ] Non-goals: \u003Clist>\n- Open gaps: [GAP] \u003Ceach unknown, repeated from above for visibility>\n- Coverage: \u003Cn\u002F5 axes resolved> → handing to CLARIFY | ESCALATE to human\n```\n\nCheck the box (`- [x]`) for a resolved axis (no `[GAP]` on that line); leave it\nunchecked (`- [ ]`) when the line still carries `[GAP]`. `unresolved_count` is\nthe number of unchecked boxes, and MUST match the coverage line's arithmetic\n(`5 - n = unresolved_count`).\n\n## Hard constraints (P0)\n\n1. READ-ONLY. No code, no file edits, no mutations.\n2. Bounded — single-pass synthesis, `[GAP]`-and-escalate, never an interview loop.\n3. Emit `[GAP]` for every unknown; never assume latent intent.\n4. DISCOVER hands its summary to CLARIFY; it does not itself produce a plan.\n5. Coverage is mechanically countable: ≥2 unresolved `[GAP]` axes ⇒ escalate,\n   computed from the checklist, never eyeballed.\n6. Every output path lives under `.spectra\u002F` (see `SPEC.md`\n   \"Output discipline\").\n\nSee `SPEC.md` \"## Pre-phases\" for the full methodology section.\n\n---\n\n*RAMZA — DISCOVER sub-mode*\n","# RAMZA — DISCOVER Skill (pre-CLARIFY elicitation)\n\nUse this skill when the request's **objective itself is unknown or latent** — not\nmerely when the spec details are ambiguous. DISCOVER runs BEFORE CLARIFY and hands\nCLARIFY a structured elicitation summary.\n\n## When to run DISCOVER (vs CLARIFY)\n\n| | DISCOVER | CLARIFY |\n|---|---|---|\n| **Precondition** | Goal is unknown \u002F latent | Goal is known; spec details ambiguous |\n| **Intent types** | `IDEA`, `STRATEGIC`, any under-GOALED request | `REQUEST`, `CHANGE`, `BUG_SPEC` |\n| **Question style** | Open-ended discovery of goals, stakeholders, success | ≤3 plan-shape disambiguation questions |\n| **Output** | Elicitation summary → handed to CLARIFY | WHO\u002FWHAT\u002FWHY\u002FCONSTRAINTS parse → Scope |\n\n**Boundary rule:** DISCOVER = \"what are we even trying to achieve, and for whom?\"\nCLARIFY = \"the goal is clear; which of these plan shapes do you want?\" Do NOT run\nDISCOVER on a well-GOALED request — go straight to CLARIFY.\n\nWhy this exists: specification\u002Fsystem-design is the dominant multi-agent failure\ncategory (MAST — ~43.8% of failures), and multi-agent systems collapse toward ~30%\naccuracy when latent stakeholder knowledge is never actively elicited (HiddenBench).\nCLARIFY alone cannot close this — its ≤3 plan-shape contract assumes the goal is\nalready known. This sub-mode is inherited unchanged from SPECTRA (see\n`DESIGN-RATIONALE.md` D2 — the discipline spine is the part the audits praised;\nDISCOVER's failure mode was never its elicitation design).\n\n## Elicitation protocol (bounded, read-only)\n\nSurface, do not assume. For each axis, record what is known and emit a `[GAP]`\nmarker for each unknown rather than inventing an answer:\n\n1. **Stakeholders** — Who requests this? Who is affected? Who approves\u002Freviews?\n   Map the approval chain. `[GAP]` for each unidentified party.\n2. **Latent goals** — What is the underlying outcome (not the surface ask)?\n   What is the \"job to be done\"? Distinguish the stated request from the real goal.\n3. **Success metrics** — How will we know it worked? Target metric + current baseline\n   (e.g. \"p95 \u003C 200ms, currently 800ms\"). `[GAP]` when no measurable criterion exists.\n4. **Hard constraints** — Budget, deadline, tech-stack lock-in, compliance, platform.\n5. **Non-goals** — What is explicitly OUT of scope? Surface these early to prevent\n   scope creep downstream.\n\n## Bound (no unbounded interview loop)\n\nDISCOVER is elicitation + synthesis, NOT an interactive multi-turn interview agent.\n- Produce ONE elicitation summary in a single pass from available context + the host\n  conversation. Do not loop.\n- If coverage is low (≥2 of the 5 axes are `[GAP]` with no resolution path),\n  **escalate to the human** with the gap list — do not fabricate goals to proceed.\n- DISCOVER NEVER produces a plan and NEVER writes code. Its sole output is the\n  elicitation summary handed to CLARIFY.\n\n## Mechanical coverage contract\n\nThe 5 axes are line items a host can count mechanically — no re-reading DISCOVER's\nreasoning required:\n\n- Each axis line in the summary below is exactly one of two states: **resolved**\n  (the line contains no `[GAP]` token) or **unresolved** (the line contains the\n  literal token `[GAP]`).\n- `unresolved_count` = the number of axis lines (Stakeholders \u002F Latent goal \u002F\n  Success metrics \u002F Hard constraints \u002F Non-goals — the first 5 checklist lines\n  only, not the `Open gaps` \u002F `Coverage` lines that restate them) containing\n  `[GAP]`.\n- **Contract:** `unresolved_count >= 2` ⇒ **ESCALATE to human**, do not hand off\n  to CLARIFY. `unresolved_count \u003C= 1` ⇒ hand off to CLARIFY normally.\n- This is a mechanical count (e.g. `grep -c '\\[GAP\\]'` over the 5 checklist\n  lines), not a model self-assessment — a host or lint step can enforce the\n  ≥2-unresolved rule without re-deriving DISCOVER's judgment, exactly the same\n  posture as `ramza-lint`'s grep-level structural checks.\n\n## Output: elicitation summary\n\nA compact structured checklist (lives under `.spectra\u002F` like all RAMZA output).\nEach of the first 5 lines is the mechanically-countable unit described above:\n\n```\n## DISCOVER — Elicitation Summary\n- [ ] Stakeholders: \u003Clist | [GAP]>\n- [ ] Latent goal: \u003Crestated outcome | [GAP]>\n- [ ] Success metrics: \u003Cmetric + baseline | [GAP]>\n- [ ] Hard constraints: \u003Clist>\n- [ ] Non-goals: \u003Clist>\n- Open gaps: [GAP] \u003Ceach unknown, repeated from above for visibility>\n- Coverage: \u003Cn\u002F5 axes resolved> → handing to CLARIFY | ESCALATE to human\n```\n\nCheck the box (`- [x]`) for a resolved axis (no `[GAP]` on that line); leave it\nunchecked (`- [ ]`) when the line still carries `[GAP]`. `unresolved_count` is\nthe number of unchecked boxes, and MUST match the coverage line's arithmetic\n(`5 - n = unresolved_count`).\n\n## Hard constraints (P0)\n\n1. READ-ONLY. No code, no file edits, no mutations.\n2. Bounded — single-pass synthesis, `[GAP]`-and-escalate, never an interview loop.\n3. Emit `[GAP]` for every unknown; never assume latent intent.\n4. DISCOVER hands its summary to CLARIFY; it does not itself produce a plan.\n5. Coverage is mechanically countable: ≥2 unresolved `[GAP]` axes ⇒ escalate,\n   computed from the checklist, never eyeballed.\n6. Every output path lives under `.spectra\u002F` (see `SPEC.md`\n   \"Output discipline\").\n\nSee `SPEC.md` \"## Pre-phases\" for the full methodology section.\n\n---\n\n*RAMZA — DISCOVER sub-mode*\n",{"name":5,"metadata":44,"description":7},{"methodology":45},"RAMZA","main","42ce382409178ece647a93f841a86119e8d74a65",".eidolons\u002Framza\u002Fskills\u002Fdiscover",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":56,"prompt":66,"zipAvailable":67},[57,60,63],{"tool":58,"command":59},"npx","npx skills add Rynaro\u002Fprisma --skill ramza-discover",{"tool":61,"command":62},"bunx","bunx skills add Rynaro\u002Fprisma --skill ramza-discover",{"tool":64,"command":65},"pnpm","pnpm dlx skills add Rynaro\u002Fprisma --skill ramza-discover","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FRynaro\u002Fprisma\u002Fblob\u002Fmain\u002F.eidolons\u002Framza\u002Fskills\u002Fdiscover\u002FSKILL.md",true,[],[70,96,125,149,177,198],{"skillNo":71,"name":72,"nameZh":6,"description":73,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":74,"categories":75,"keywords":76,"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",[],[77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,23],"verify","vivi verify incoming","verify incoming","run","sha-256","json","orchestrator","process","dispatch","back","message","upstream","id","receiver","block","ecl","hand","load","for",{"skillNo":97,"name":98,"nameZh":6,"description":99,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":100,"categories":101,"keywords":107,"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",[102],{"categoryNo":103,"categoryName":104,"taxonomyType":105,"taxonomyTypeDesc":106},"01JBSEEDCAT000000000000040","财务","PROFESSION","适用职业",[108,109,110,111,112,32,113,114,115,116,117,118,119,94,120,121,122,123,124,23],"parallel","tracks","parallel tracks","vivi parallel tracks","file","reflection","clean","plan phase","as","verifier","form","multi","worktree isolation","track","gating","single","phase",{"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":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",[],[132,133,134,135,136,34,137,138,139,140,141,142,143,144,28,145,146,147,148,23],"methodology","vivi methodology","planning","escalation","Rules","evidence","complexity","delta","task","cycle","feature implementation","brownfield","full","feature","complete","thresholds","you",{"skillNo":150,"name":151,"nameZh":6,"description":152,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":153,"categories":154,"keywords":160,"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",[155],{"categoryNo":156,"categoryName":157,"taxonomyType":158,"taxonomyTypeDesc":159},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[161,162,163,164,165,166,167,38,168,33,169,170,171,172,173,174,148,175,176,23],"memory","management","memory management","vivi memory management","MCP","commit","tasks","write","files","route","across","local","end","session start","standalone","at",{"skillNo":178,"name":179,"nameZh":6,"description":180,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":181,"categories":182,"keywords":183,"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",[],[184,185,186,187,188,189,190,191,192,193,194,34,140,195,116,196,197,94,122,124],"loop","native","vivi loop native","oracle","sandbox","test","core","game","feedback","autonomous","fix","tests","fresh","host",{"skillNo":199,"name":200,"nameZh":6,"description":201,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":202,"categories":203,"keywords":204,"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",[],[205,206,207,135,208,209,34,210,211,147,212,213,214,94,176,215,216,124,23,217],"recovery","vivi failure recovery","debugging","classification","taxonomy","three","pattern","error","retries","random","break","bounded","same"]