个人作者
Henrique A. Lavezzo
A Code Alchemist with a passion for weaving tales and inscribing transmutation circles in pure code.
- Skills
- 190
- 仓库
- 2
- 职业覆盖
- 3
- 场景覆盖
- 3
- Stars
- ★ 2
Henrique A. Lavezzo 的 Skills 190
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 / 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.
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/aggregation step. Absent TRANCE gating, Vivi runs exactly as today: single-track A→P→I→V→Δ/R.
vivi-methodology
Full Vivi cycle reference — A(nalyze) → P(lan) → I(mplement) → V(erify) → Δ(Delta)/R(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.
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/commit/ingest/plan_checkpoint/session_end). The local agents/memories/*.md files are the standalone fallback for when CRYSTALIUM is absent — EIIS conformance. Never write both.
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.
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.
vivi-esl-hop
ESL lifecycle hop — when the cortex routes a non-trivial change to Vivi in an ESL-enabled project (tonberry MCP available), Vivi owns the in_progress (implement) hop as the MAKER: declare has_code, run the loop-native A→P→I→V→Δ/R cycle in an isolated worktree, hand off to the CHECKER (never self-verify). Absent tonberry → implement normally (ESL opt-in).
vivi-context-engineering
Load at the start of the Vivi Analyze phase. Techniques for building a repo map, running progressive disclosure, and maximising context relevance for coding tasks. Use whenever you need to understand unfamiliar code before editing it, or when an existing Discovery Report feels under-grounded.
vigil-verify
Phase V (Verify) — establishes a reproducible failure. Deterministic-first; on two failed deterministic attempts, switches to statistical replay with confidence bands. No attribution begins without this phase passing. Use when starting any VIGIL mission, on mission intake, before any isolation or intervention work.
verify-incoming
暂无简介
vigil-learn
Phase L (Learn) — emits verified root-cause finding with evidence chain, walks the cause back to its originating decision, persists failure signature to semantic memory for future de-duplication, routes handoff to the correct downstream Eidolon. Use after `intervention-log.md` has a SURVIVOR to produce the primary deliverable.
vigil-isolate
Phase I (Isolate) — narrows the fault surface to ≤8 candidate nodes via delta-debugging-style reduction. Preserves failure throughout reduction; records ruled-out evidence. Use after `reproduction.md` is stable and `DETERMINISM_VERDICT ≠ intermittent`, before the Graph phase.
vigil-intervene
Phase I (Intervene) — falsifies hypotheses via counterfactual replay. Designs minimal interventions for each root candidate; runs in sandbox; root cause is the candidate whose intervention flips failure→success. Hard cap 5 interventions. Use after `idg.md` identifies ≥1 ROOT_CANDIDATE, before emitting the root-cause report.
vigil-graph
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.
vigil-esl-hop
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).
ramza-verify-incoming
Load when reading any upstream artefact handed off to RAMZA 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 / 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.
ramza-parallel-spec
TRANCE-only G3 evaluator-optimizer mode: fan out 2-4 perspective-diverse clean-context candidate specs, score with a bias-hardened evaluator anchored on ramza-score, judge-merge into ONE spec, terminate at confidence ≥85% or hard cap 3 iterations. Read-only; never the default — runs ONLY when the cortex authorizes TRANCE.
ramza-methodology
Decision-ready, tamper-evident specifications via the RAMZA cycle. RS right-sizing runs first — every downstream gate (score, lint, freeze, drift, emit) is a bin/ramza-* tool call, never self-policed arithmetic. Use for any task needing a spec before implementation; ceremony scales with the RS tier (trivial/lite/full), never a fixed complexity threshold. Produces a plan .md + plan-state.json audit trail (+ YAML/JSON block, + ECL envelope when ECL_VERSION is present), never code.