@su-record/vibe 3.2.1 → 3.2.2

package/skills/vibe.docs/SKILL.md

@@ -32,6 +32,261 @@ Generate or update project documentation by analyzing the actual codebase.
 
 ---
 
-Load skill `docs` — subcommand에 따라 해당 섹션 실행
+Execute the bundled implementation below — subcommand에 따라 해당 섹션 실행
 
 ARGUMENTS: $ARGUMENTS
+
+## Bundled implementation
+
+
+# vibe.docs — Project Documentation Generator
+
+Generate or update project documentation by analyzing the actual codebase.
+
+## Subcommands
+
+### `/vibe.docs readme` — README Generation
+
+Analyze the codebase and generate a complete README.md:
+
+1. **Detect project nature**: Read package.json, CLAUDE.md, existing README
+2. **Extract key info**: Tech stack, installation, usage, API surface
+3. **Generate sections**:
+
+```markdown
+# Project Name
+> One-line description from package.json
+
+## What is this?
+[2-3 sentences explaining the problem and solution]
+
+## Quick Start
+[Installation + minimal usage example]
+
+## Features
+[Auto-detected from codebase — exported functions, CLI commands, API endpoints]
+
+## Architecture
+[High-level module diagram if 5+ source directories]
+
+## Configuration
+[Detected config files and their purposes]
+
+## Development
+[Build, test, lint commands from package.json scripts]
+
+## License
+```
+
+**Analysis approach:**
+```
+Read: package.json → name, description, scripts, dependencies
+Glob: src/**/*.ts → module structure
+Grep: pattern="export (function|class|const)" → public API surface
+Grep: pattern="(app|router)\.(get|post|put|delete)" → API endpoints
+Read: CLAUDE.md → project conventions
+```
+
+### `/vibe.docs guide` — User Guide
+
+Generate a step-by-step user guide:
+
+1. **Installation**: Detect package manager, prerequisites
+2. **Configuration**: Find all config files, document each option
+3. **Usage**: Extract CLI commands or API usage patterns
+4. **FAQ**: Common issues from error handling patterns
+5. **Troubleshooting**: Known edge cases from test files
+
+Output: `docs/GUIDE.md`
+
+**Analysis approach:**
+```
+Read: package.json → bin, scripts, peerDependencies
+Glob: src/cli/commands/*.ts → CLI command list
+Grep: pattern="throw new|Error\(" → common error scenarios
+Grep: pattern="(process\.env|config)\.\w+" → configuration options
+```
+
+### `/vibe.docs arch` — Architecture Documentation
+
+Generate architecture overview with diagrams:
+
+1. **Module map**: Directory structure → responsibility mapping
+2. **Dependency graph**: Import analysis → Mermaid diagram
+3. **Data flow**: Entry points → processing → output
+4. **Key decisions**: Extract from CLAUDE.md and code comments
+
+Output: `docs/ARCHITECTURE.md`
+
+**Mermaid diagram generation:**
+```
+Glob: src/**/ → module list
+Grep: pattern="^import .+ from" → dependency edges
+Read: CLAUDE.md → architecture notes
+
+Generate:
+graph TD
+    CLI[CLI Commands] --> Core[Core Logic]
+    Core --> Infra[Infrastructure]
+    Infra --> DB[(Database)]
+    Infra --> API[External APIs]
+```
+
+### `/vibe.docs agent` — Agent Instruction Files (CLAUDE.md / AGENTS.md)
+
+**CLI ↔ file mapping:**
+
+| CLI | File | Support |
+|---|---|---|
+| Claude Code | `CLAUDE.md` | 100% (Primary) |
+| Codex | `AGENTS.md` | 100% (Primary) |
+| Antigravity CLI | `GEMINI.md` | 100% |
+
+Cursor is not supported — do not generate or check Cursor-specific context files.
+
+**Source of truth:**
+- **`CLAUDE.md` is the content SSOT.** Always edit it first; `AGENTS.md` is a regenerated derivative.
+- Behavioral block: `skills/vibe.docs/templates/behavioral-principles.md` (4 Karpathy principles, wrapped in `<!-- VIBE-BEHAVIORAL:START/END -->` markers).
+
+**Procedure (applies to both creation and modification):**
+
+1. **Detect state** — check which of `CLAUDE.md` / `AGENTS.md` / `GEMINI.md` exist in project root. **`CLAUDE.md` is always the SSOT**; if missing, create it first (never derive from AGENTS.md).
+2. **For `AGENTS.md`**:
+   - **If missing** → create by cloning `CLAUDE.md` + applying CLI substitution (below).
+   - **If exists** → regenerate from current `CLAUDE.md` + substitution, preserving user-specific additions outside the VIBE block.
+3. **For `GEMINI.md`**:
+   - **If missing** → create by cloning `CLAUDE.md` + applying Antigravity substitution.
+   - **If exists** → regenerate from current `CLAUDE.md` + substitution, preserving user-specific additions outside the VIBE block.
+4. **CLI substitution for `AGENTS.md`** (Codex): `Claude Code` → `Codex` · `~/.claude/` → `~/.codex/` · `.claude/` → `.codex/` · `CLAUDE.md` → `AGENTS.md`. `CLAUDE.md` itself gets no substitution.
+5. **CLI substitution for `GEMINI.md`** (Antigravity): `Claude Code` → `Antigravity CLI` · `~/.claude/` → `~/.gemini/` · `.claude/` → `.gemini/` · `CLAUDE.md` → `GEMINI.md`.
+6. **Validate every touched file (whether newly created or modified)** via the `agents-md` skill — see validation block below. **Never write or save without running this step.**
+7. Report per file: created / updated / skipped / validation warnings.
+
+**Idempotent:** Re-running re-syncs the behavioral block and re-applies substitutions without duplication.
+
+**Mandatory validation (every create & every update) — Load skill `vibe.agents-md`:**
+
+- Size target 60–150 lines (Optimal). Warn at 200+, force split/trim at 300+.
+- 4-question check per line (outside `VIBE-BEHAVIORAL` block):
+  - Would the agent make a mistake without this? (No → delete)
+  - Needed every session? (No → move to SPEC/plan)
+  - Can a linter/hook replace it? (Yes → move)
+  - Discoverable from code? (Yes → delete)
+- Lost-in-the-Middle: critical rules at top, frequently-violated rules at bottom.
+- Addy Osmani test: "Can the agent discover this by reading the code?" → Yes = delete.
+- Strip tech-stack name-drops already stated in `package.json`.
+
+Report line ranges to trim per file. Do not auto-delete; surface findings for user approval before finalizing.
+
+**When to run:**
+- After `vibe init` / `vibe update` if `CLAUDE.md` or `AGENTS.md` is missing or out of sync.
+- After upgrading `@su-record/vibe` when the behavioral template changes.
+- Whenever the SSOT file is edited — re-sync `AGENTS.md`.
+- User explicitly asks to refresh agent instructions.
+
+### `/vibe.docs release` — Release Notes
+
+Generate release notes from git history:
+
+1. **Collect**: `git log` since last tag
+2. **Classify**: feat/fix/refactor/docs/chore from commit messages
+3. **Group**: By category with breaking changes highlighted
+4. **Format**: Semantic versioning suggestion
+
+Output: `RELEASE_NOTES.md` or append to `CHANGELOG.md`
+
+**Output format:**
+```markdown
+## [x.y.z] - YYYY-MM-DD
+
+### Breaking Changes
+- ...
+
+### Features
+- feat: description (#PR)
+
+### Bug Fixes
+- fix: description (#PR)
+
+### Other
+- refactor/docs/chore items
+```
+
+### `/vibe.docs diagram` — Diagram Generation
+
+Generate Mermaid diagrams for architecture, ERD, flowchart, or sequence
+visualization directly (native capability — no dedicated agent). Ground the
+diagram in sources first: folder structure and imports for architecture;
+`models/`, `migrations/`, `schema.*`, ORM definitions for ERDs; the real
+branch/return structure of the code for flowcharts.
+
+**Options:**
+- `/vibe.docs diagram` (default): Architecture overview
+- `/vibe.docs diagram --er`: Entity-Relationship Diagram
+- `/vibe.docs diagram --flow`: Flowchart
+- `/vibe.docs diagram --seq`: Sequence Diagram
+
+> Read `references/diagram-spec.md` for the full output conventions (Mermaid syntax per diagram type, save location, accuracy constraints).
+
+**Example:**
+```
+/vibe.docs diagram --er
+```
+
+### `/vibe.docs codemaps` — Codemaps Generation
+
+Generate auto-documentation from codebase structure directly (native
+capability — no dedicated agent).
+
+**Output Location:** `docs/CODEMAPS/`
+
+> Read `references/codemaps-output.md` for the full generated-files tree, per-file contents, and tools used.
+
+**Example:**
+```
+/vibe.docs codemaps
+```
+
+## Pipeline Integration
+
+`/vibe.docs` completes the development pipeline:
+
+```
+/vibe.spec    → Design (what to build)
+/vibe.run     → Implement (build it)
+/vibe.trace   → Verify (prove it works)
+/vibe.docs    → Document (explain it)
+```
+
+### Auto-trigger after `/vibe.trace`
+
+When `/vibe.trace` completes with all scenarios passing, suggest:
+> "All scenarios verified. Run `/vibe.docs readme` to update documentation?"
+
+## Guidelines
+
+### DO
+- Read the actual codebase before generating — never guess
+- Preserve existing documentation that's still accurate
+- Include concrete code examples from the actual project
+- Keep language consistent with project (Korean/English based on CLAUDE.md)
+- For `/vibe.docs release` (changelog mode), follow `references/api-docs-changelog.md` natively — no dedicated agent
+- For API-heavy projects (api-docs mode), follow `references/api-docs-changelog.md` natively
+- For `/vibe.docs arch` and `/vibe.docs diagram` Mermaid generation, follow `references/diagram-spec.md` natively
+- Use the `agents-md` skill for `/vibe.docs agent` — applies equally to CLAUDE.md and AGENTS.md
+
+### DON'T
+- Don't generate placeholder text ("Lorem ipsum", "TODO: fill in")
+- Don't document internal implementation details in user-facing docs
+- Don't create files without reading existing ones first
+- Don't assume features — verify by reading code
+
+## Quality Checklist
+
+Before finalizing any document:
+
+- [ ] All code examples are runnable (copy-paste ready)
+- [ ] Installation steps tested against package.json
+- [ ] Links and paths are valid
+- [ ] No placeholder text remaining
+- [ ] Consistent with project language (Korean/English)

package/skills/{e2e-commerce → vibe.e2e-commerce}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: e2e-commerce
+name: vibe.e2e-commerce
 invocation: [auto]
 tier: core
 description: "E2E test scenarios for commerce checkout and payment flows. Provides ready-made Playwright test templates for cart→checkout→payment→confirmation flows, including PG sandbox testing (Toss/Stripe), error scenarios (payment failure, timeout, stock exhaustion), and idempotency verification. Use when writing E2E tests for any e-commerce feature — checkout, payment, order status, or refund flows."

package/skills/vibe.educational-content/SKILL.md

@@ -0,0 +1,157 @@
+---
+name: vibe.educational-content
+description: Create evidence-backed educational content from a subject, curriculum, source document, repository, product, expert interview, or demonstration. Use when Codex needs to research, design, script, verify, assess, or repurpose a lesson, course, tutorial, workshop, explainer, screencast, teaching article, presentation, worksheet, microlearning unit, or educational social content for any domain, including development and technical education. Especially useful when content needs observable learning outcomes, audience-appropriate scaffolding, practice and feedback, valid assessment, source traceability, or clear separation between verified facts and inference.
+user-invocable: false
+---
+
+# Create Educational Content
+
+Turn a subject into a publishable learning experience whose outcome can be observed. Design the learning before polishing the presentation.
+
+## Set the contract
+
+Infer missing low-risk details and state the assumptions. Ask only when audience, format, or publication constraints would materially change the result.
+
+Capture:
+
+- outcome: what the learner can do afterward
+- audience: age or role, prior knowledge, motivation, language, accessibility needs
+- context: self-study, classroom, onboarding, reference, campaign, or performance support
+- format: lesson, article, workshop, video, course, worksheet, assessment, or short-form
+- source: curriculum, document, URL, repository, expert input, dataset, or user notes
+- constraints: duration, length, standards, platform, brand, deadline
+- proof bar: demonstration, explanation, performance, artifact, quiz, rubric, or observation
+
+Do not begin with a broad topic such as “teach climate change” or “teach Docker.” Rewrite it as an observable outcome such as “a learner distinguishes weather from climate using three examples” or “a frontend developer deploys a two-service Compose app and verifies health checks.”
+
+Read [references/learning-design.md](references/learning-design.md) when selecting objectives, activities, scaffolding, or assessments.
+
+## Choose a teaching path
+
+Prefer a progression from concrete experience to independent performance:
+
+1. Activate relevant prior knowledge or expose a meaningful problem.
+2. Model the target performance with a concrete example.
+3. Guide practice with prompts, hints, or worked steps.
+4. Give feedback against explicit criteria.
+5. Remove support and require independent application or transfer.
+
+For technical tool education, the progression may be easy surface → inspectable implementation → power-user surface → automation. Use a different order when prerequisites, domain practice, or safety require it. Avoid fact or feature tours; organize around learner performance.
+
+## Research the claim surface
+
+Build a claim ledger before drafting. For each consequential claim record:
+
+| Claim | Evidence | Status | Content use |
+|---|---|---|---|
+| What the tool does | primary docs or observed run | verified | state directly |
+| Why it behaved that way | code, docs, or controlled test | verified/inferred | label inference |
+| What may vary | version, OS, account, UI, network | uncertain | add caveat |
+
+Prefer primary, authoritative, and current sources. Use multiple credible perspectives for contested subjects. Inspect target materials in full before explaining them. Never invent quotations, citations, commands, settings, UI labels, research findings, statistics, benchmark numbers, or results.
+
+For source-video-derived work, read [references/source-method.md](references/source-method.md) to preserve the method without copying the source presentation.
+
+## Build the learning evidence
+
+Create the smallest realistic activity that elicits the promised outcome.
+
+1. Record environment and prerequisites.
+2. Establish the initial state.
+3. Model one successful performance or worked example.
+4. Give the learner a meaningful action, decision, explanation, or creation task.
+5. Capture evidence with a criterion-aligned check.
+6. Record one likely misconception and corrective feedback path.
+
+For code, tools, experiments, or procedures, keep demonstrations reproducible where possible and verify actual results. For conceptual subjects, require explanation, classification, comparison, prediction, or application instead of relying only on recall. Separate paid, destructive, medical, legal, physical, or external actions from harmless learning checks and require appropriate authorization or supervision.
+
+## Design the narrative
+
+Use this spine:
+
+1. **Promise** — show the concrete end state.
+2. **Mental model** — explain only the concepts needed for the next action.
+3. **Setup** — connect prior knowledge and define prerequisites.
+4. **Model** — demonstrate the target thinking or performance.
+5. **Practice** — progress through small, observable attempts.
+6. **Feedback** — address a realistic misconception or failure.
+7. **Assess** — elicit independent evidence of learning.
+8. **Extend** — transfer the idea to a new context.
+9. **Recap** — map the evidence back to the learning outcome.
+
+Pair every explanation with evidence:
+
+- explanation establishes what and why
+- example or demonstration shows how
+- learner activity elicits performance
+- assessment shows whether the outcome was reached
+
+Do not confuse exposure with learning. Watching, reading, or clicking is not sufficient evidence unless the stated objective only requires recognition. Explain decisions, relationships, constraints, and changes in understanding.
+
+## Draft the production package
+
+Produce only artifacts the requested format needs. Use the schemas in [references/output-patterns.md](references/output-patterns.md).
+
+At minimum include:
+
+- title and one-sentence learner promise
+- audience and prerequisites
+- outline with estimated pacing
+- model, guided practice, and independent practice
+- assessment, answer guidance, or scoring rubric
+- evidence or capture plan
+- safety and uncertainty notes
+- final quality checklist
+
+For video, add scene intent, narration, visual action, learner prompt, and evidence shot. For articles, add reflection or practice prompts and expected reasoning; add runnable code and expected output when technical. For workshops, add checkpoints, facilitator moves, and misconception recovery.
+
+## Apply gates
+
+Stop and repair the artifact when a gate fails.
+
+### Accuracy gate
+
+- Every consequential claim is verified or explicitly labeled as inference.
+- Version-sensitive facts are current and sourced.
+- Commands and code match the stated environment.
+
+### Learning-evidence gate
+
+- The activity elicits the behavior named in the objective.
+- Practice includes timely, actionable feedback.
+- Independent assessment does not give away the answer.
+- Expected evidence and evaluation criteria are explicit.
+
+### Teaching gate
+
+- Each section advances the learner toward the promise.
+- New concepts appear immediately before use.
+- Jargon is defined once and then used consistently.
+- Cognitive load fits the audience and format.
+- Examples are inclusive, relevant, and free of avoidable stereotypes.
+
+### Safety gate
+
+- External writes, destructive actions, and high-stakes activities have an approval or supervision boundary.
+- Secrets, personal data, and account details are absent from captures.
+- Minor learners and sensitive subjects receive appropriate privacy and safeguarding treatment.
+
+### Production gate
+
+- Claims, narration, captions, visuals, activities, and assessments agree.
+- No placeholder, fabricated output, or unsupported superlative remains.
+- The final artifact names limitations and the next useful action.
+
+## Handle failure
+
+- If the source cannot be accessed, report the missing evidence and request an artifact or alternate source; do not fabricate an analysis.
+- If a live tool is unavailable, use a recorded fixture and label it as simulated.
+- If a technical demonstration fails, reproduce once, state one root-cause hypothesis, add a failing check, then fix.
+- If learners cannot complete an activity, distinguish missing prerequisite knowledge, unclear instruction, excessive load, and a flawed assessment before adding more explanation.
+- If behavior is nondeterministic, show the invariant acceptance criteria instead of promising identical output.
+- If evidence is contested or culturally situated, present the source context and credible disagreement rather than manufacturing certainty.
+- If the requested scope exceeds the format, preserve the core learning outcome and move depth into a follow-up resource.
+
+## Finish
+
+Return the production-ready artifact, the verification evidence, and a short list of assumptions or unresolved uncertainties. Keep research notes out of the final content unless they help the learner judge a claim.

package/skills/vibe.educational-content/references/learning-design.md

@@ -0,0 +1,81 @@
+# Learning design
+
+Use this reference to align objectives, activities, feedback, and assessment.
+
+## Write observable objectives
+
+Use `learner + action + conditions + criterion` when the criterion matters.
+
+- weak: understand photosynthesis
+- observable: explain how light energy becomes stored chemical energy using a labeled diagram
+- weak: know Git branches
+- observable: create a feature branch, resolve one merge conflict, and explain why each resolution is correct
+
+Match the action to the desired depth:
+
+- remember: identify, recall, label
+- explain: summarize, compare, classify, explain
+- apply: use, calculate, execute, demonstrate
+- analyze: diagnose, distinguish, map, justify
+- create: design, produce, compose, implement
+- evaluate: critique, prioritize, defend with criteria
+
+## Align the learning sequence
+
+For every objective, provide:
+
+1. a model or example of the target performance
+2. guided practice that exposes learner thinking
+3. feedback specific to the success criteria
+4. independent practice without answer leakage
+5. an assessment using the same skill at an appropriate difficulty
+6. a transfer task in a changed context when durable learning matters
+
+Do not assess a deeper behavior than the instruction and practice prepared. Do not use recall questions as proof of application or analysis.
+
+## Diagnose the audience
+
+Distinguish:
+
+- prerequisite knowledge: facts or skills needed before starting
+- misconceptions: plausible but incorrect mental models
+- motivation: why the outcome matters to the learner
+- constraints: time, language, device, accessibility, instructor support
+
+Use a short pre-check when assumptions materially affect the path. Offer a bypass for learners who already demonstrate the prerequisite.
+
+## Scaffold and fade
+
+Move from worked example → completion task → independent task. Reduce hints as competence grows. Keep essential information near the activity that uses it. Split intrinsic complexity into meaningful chunks without fragmenting the overall mental model.
+
+## Give feedback
+
+Make feedback:
+
+- timely: close enough to the attempt to guide correction
+- specific: name the criterion and evidence
+- actionable: identify the next attempt
+- explanatory: address the learner's reasoning, not only correctness
+
+Avoid praise or correction that reveals no path forward. For high-stakes assessment, separate coaching practice from scored performance.
+
+## Design fair assessment
+
+Check:
+
+- validity: does the task measure the stated objective?
+- reliability: would equivalent performance receive equivalent judgment?
+- accessibility: can learners perceive and respond without irrelevant barriers?
+- fairness: does success depend on unstated cultural, linguistic, or technical knowledge?
+- authenticity: does the task resemble meaningful use of the skill?
+
+Provide acceptable variants and a rubric for open-ended work. Never fabricate learner results or claim effectiveness without evidence.
+
+## Adapt by format
+
+- self-study: make navigation, answers, and recovery self-contained
+- instructor-led: include facilitation prompts, timing, observation cues, and optional extensions
+- video: use retrieval pauses; do not replace practice with passive viewing
+- short-form: teach one distinction or action and give one immediate retrieval prompt
+- reference material: optimize lookup and decision support; do not force an unnecessary lesson arc
+- onboarding: use the real performance context, safe fixtures, and operational boundaries

package/skills/vibe.educational-content/references/output-patterns.md

@@ -0,0 +1,109 @@
+# Output patterns
+
+Select one primary pattern and omit unused fields.
+
+## Article or tutorial
+
+```markdown
+# Title: learner-visible outcome
+Audience:
+Prerequisites:
+Tested with:
+
+## What you will build
+## Mental model
+## Worked example
+## Step 1 — action
+Exact input:
+Expected result:
+Verification:
+## Common failure and recovery
+## Independent practice
+## Assessment and answer guidance
+## Extension
+## Recap
+## Sources and limitations
+```
+
+## Screencast or course chapter
+
+| Time | Learning beat | Narration intent | Visual action | Learner prompt | Evidence shot | Asset |
+|---|---|---|---|---|---|---|
+| 00:00 | Promise | Name the outcome | Show final state | Predict or notice | Working result | capture |
+
+Add a capture manifest:
+
+```yaml
+- id: proof-final
+  state: exact prerequisite state
+  action: command, prompt, or UI action
+  evidence: expected visible result
+  privacy: crop or redact requirements
+  retry: recovery action
+```
+
+## Lesson or workshop
+
+```markdown
+Outcome:
+Duration:
+Starting repository/state:
+Prior-knowledge check:
+
+Checkpoint 1:
+- learner action
+- facilitator proof
+- likely misconception
+- feedback or recovery
+
+Independent task:
+Acceptance criteria:
+Answer guidance or rubric:
+Cleanup or rollback:
+```
+
+## Short-form educational content
+
+```markdown
+Hook: surprising observable result
+Context: one sentence
+Teach: one model, contrast, or no more than three actions
+Retrieve: one prediction, decision, or recall prompt
+Proof: answer, demonstration, or comparison
+Caveat: scope, evidence, safety, or limitation
+CTA: reproducible next step, not engagement bait
+```
+
+## Assessment item
+
+```yaml
+objective: "observable learning outcome"
+prompt: "task that elicits the outcome"
+evidence: "what a valid response must demonstrate"
+criteria:
+  - name: "criterion"
+    levels: ["not yet", "developing", "meets", "extends"]
+answer_guidance: "reasoning and acceptable variants"
+misconceptions:
+  - signal: "common wrong pattern"
+    feedback: "specific corrective prompt"
+fairness_check: "language, accessibility, cultural, or prerequisite issue"
+```
+
+## Verification appendix
+
+```yaml
+environment:
+  context: ""
+  versions: []
+claims:
+  - claim: ""
+    status: verified | inferred | uncertain
+    evidence: ""
+    checked_at: "YYYY-MM-DD"
+checks:
+  - learner_action: ""
+    expected: ""
+    observed: ""
+unresolved: []
+```

package/skills/vibe.educational-content/references/source-method.md

@@ -0,0 +1,40 @@
+# Source-derived method
+
+Use this reference when adapting the method demonstrated in [Yalco's Codex training video](https://youtu.be/Bzdcg70ivrs). It records reusable principles, not a transcript.
+
+## Evidence basis
+
+- YouTube metadata identifies the video as “코덱스 참교육 - Codex 업무 자동화부터 바이브 코딩까지” by 얄팍한 코딩사전.
+- The creator's official course page identifies the public video as the 13:19 introduction, “코덱스 소개 & 강의에서 배울 것.” It describes the course examples and method across the Codex app, editor, CLI, plugins, automation, skills, MCP, testing, review, and harness engineering.
+- Full captions and frame-level playback were unavailable during source analysis because YouTube blocked the server request. Do not present the wider course curriculum as a scene-by-scene account of the 13:19 video.
+- Exact UI labels, model names, generated configuration, availability, and account requirements are version-sensitive. Verify them against current primary documentation before publishing.
+
+## Reusable principles
+
+1. Contrast a chat answer with an agent changing observable state.
+2. Start beginners on the lowest-friction surface, then reveal editor and CLI depth.
+3. Teach through a continuous result: create a file, inspect it, render it, then extend it.
+4. Show exact prompts or commands alongside their actual effects.
+5. Verify in the destination system: browser, filesystem, calendar, draft folder, or job history.
+6. Keep human approval around file deletion, messages, purchases, publication, and other external writes.
+7. Isolate agent work with a bounded project folder or sandbox.
+8. Explain that generated details may vary while acceptance criteria remain stable.
+9. Promote a successful one-off task to scheduled automation only after manual validation.
+10. Give automation an explicit scope, cadence, observable failure, and way to disable it.
+11. Structure agent requests with a goal, context, constraints, and observable completion criteria.
+12. Teach adjustment and verification instead of promising output identical to a recording.
+
+## Content adaptation
+
+Translate the method, not the examples:
+
+- replace the demonstrated product with the target technology
+- replace “app → editor → CLI” with “easy surface → inspectable implementation → power-user surface”
+- replace calendar or email proof with the target system's independent readback
+- replace feature enumeration with a single outcome that crosses two or three depth levels
+
+Attribute ideas when closely discussing the source. Do not reproduce long wording, full transcripts, or the source's visual identity.
+
+## Reliability notes
+
+Treat any detailed timeline produced by automated video analysis as an index to verify, not as authoritative evidence. Recheck timestamps and screen text before including them in published content. If direct playback or captions are unavailable, label the gap and avoid exact quotations.

package/skills/{event-comms → vibe.event-comms}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: event-comms
+name: vibe.event-comms
 invocation: [auto]
 tier: standard
 description: "Event communication automation — SMS via Aligo, email via Gmail OAuth, SNS posts for LinkedIn/Threads. Handles templates, BCC rules, and confirmation protocol."

package/skills/{event-ops → vibe.event-ops}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: event-ops
+name: vibe.event-ops
 invocation: [auto]
 tier: standard
 description: "Event operations — nametags, checklists, operational slides, Slido plans, image generation specs, settlement reports."

package/skills/{event-planning → vibe.event-planning}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: event-planning
+name: vibe.event-planning
 invocation: [auto]
 tier: standard
 description: "Community event automation — D-Day timeline, community patterns, proactive task execution. Auto-activates for event planning, meetup/webinar/conference management."