VibeRaven: Production Context
Repo context says what exists. Production context says what is dangerous.
Hard Rule
Keep memory small enough to reuse in the next agent action. Do not create a report dump.
File
Maintain:
.viberaven/production-context.md
Create it when allowed and missing. Otherwise propose the exact entry.
Loop
read -> isolate risk -> fix/propose -> verify -> record -> open action
- Read the current file before production-sensitive work.
- Identify one relevant boundary: release, auth, data/RLS, provider dashboard, deploy/env, job/webhook, billing, storage, or customer path.
- Use repo evidence first: git status, tags, changelog, PR links, diffs, migrations, env examples, tests.
- Use VibeRaven/provider MCP evidence when available for provider state, release history, and dashboard-adjacent receipts.
- Record only what changes the next decision.
- Separate repo fixes from provider/human actions.
When the output names Next skill:, continue with that VibeRaven skill unless user input, auth, or provider proof is required.
Use Next skill: go-live when context is recorded and the next step is deploy/live proof. Use Next skill: what-broke when context shows a version/release regression. Use Next skill: architecture-context when the risk reveals an unclear product boundary.
File Shape
# VibeRaven Production Context
## Current Release / Change Window
## Recent Changes
## Architecture Boundaries
## Provider Boundaries
## Migration And Data History
## Incidents And Rollback Notes
## Fragile Customer Paths
## Verification Receipts
## Open Provider Or Human Actions
Entry Shape
### YYYY-MM-DD - short label
- Change:
- Evidence:
- Boundary:
- Danger:
- Repo fix:
- Verification:
- Provider/MCP proof:
- Open action:
Use unknown from repo when provider state is not proven.
Output
Context read:
Context updated/proposed:
Boundary:
Repo action:
Provider/MCP action:
Next skill:
Next:
Mistakes
- Copying long logs instead of linking commands, files, PRs, screenshots, or receipts.
- Claiming provider dashboards are fixed by repo edits.
- Asking for passwords, tokens, cookies, private keys, signing secrets, or raw env values.
- Recording generic notes that will not change a future agent decision.
1---2name: production-context3description: Use when changing, reviewing, debugging, deploying, or documenting production-sensitive work involving providers, releases, migrations, auth, billing, webhooks, env vars, incidents, rollback notes, fragile customer paths, or architecture boundaries.4---56# VibeRaven: Production Context78Repo context says what exists. Production context says what is dangerous.910## Hard Rule1112Keep memory small enough to reuse in the next agent action. Do not create a report dump.1314## File1516Maintain:1718```text19.viberaven/production-context.md20```2122Create it when allowed and missing. Otherwise propose the exact entry.2324## Loop2526```text27read -> isolate risk -> fix/propose -> verify -> record -> open action28```29301. Read the current file before production-sensitive work.312. Identify one relevant boundary: release, auth, data/RLS, provider dashboard, deploy/env, job/webhook, billing, storage, or customer path.323. Use repo evidence first: git status, tags, changelog, PR links, diffs, migrations, env examples, tests.334. Use VibeRaven/provider MCP evidence when available for provider state, release history, and dashboard-adjacent receipts.345. Record only what changes the next decision.356. Separate repo fixes from provider/human actions.3637When the output names `Next skill:`, continue with that VibeRaven skill unless user input, auth, or provider proof is required.3839Use `Next skill: go-live` when context is recorded and the next step is deploy/live proof. Use `Next skill: what-broke` when context shows a version/release regression. Use `Next skill: architecture-context` when the risk reveals an unclear product boundary.4041## File Shape4243```md44# VibeRaven Production Context4546## Current Release / Change Window47## Recent Changes48## Architecture Boundaries49## Provider Boundaries50## Migration And Data History51## Incidents And Rollback Notes52## Fragile Customer Paths53## Verification Receipts54## Open Provider Or Human Actions55```5657## Entry Shape5859```md60### YYYY-MM-DD - short label6162- Change:63- Evidence:64- Boundary:65- Danger:66- Repo fix:67- Verification:68- Provider/MCP proof:69- Open action:70```7172Use `unknown from repo` when provider state is not proven.7374## Output7576```text77Context read:78Context updated/proposed:79Boundary:80Repo action:81Provider/MCP action:82Next skill:83Next:84```8586## Mistakes8788- Copying long logs instead of linking commands, files, PRs, screenshots, or receipts.89- Claiming provider dashboards are fixed by repo edits.90- Asking for passwords, tokens, cookies, private keys, signing secrets, or raw env values.91- Recording generic notes that will not change a future agent decision.
ohad6k