modificacion-segura-taimbox

Name: modificacion-segura-taimbox
Availability: InStock
Author: peypons

Guide safe modifications to shared frontend/backend contracts using repository documentation.

Updated Dec 13, 2025

Search Tags:#documentation #context #safety #types #modification #codesafety

Ready to run

npx skills add https://github.com/PeyPons/Timeboxing --skill modificacion-segura-taimbox

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: modificacion-segura-taimbox
Source: https://github.com/PeyPons/Timeboxing/tree/main/.cursor/skills/modificacion-segura-taimbox
Command: npx skills add https://github.com/PeyPons/Timeboxing --skill modificacion-segura-taimbox

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Reducing regressions when touching shared types, AppContext, capacity/date utilities, permissions, Realtime, RLS, or contracts between frontend and Supabase. This guide helps ensure changes are scoped, well-documented, and validated against the repo's guidance.

Core Features & Use Cases

Guided, scoped changes: apply this skill to a small set of known files rather than sweeping edits.
Safe exploration when impact is uncertain: use a Task explore approach to locate usages in src/, supabase/, and docs/ without loading the entire tree.
Documentation-driven governance: consult DOCUMENTACION.md and the relevant docs sections (docs/08 and docs/09) before making changes that touch critical areas.

Quick Start

Open the relevant docs (docs/08 and docs/09) and apply changes only after confirming impact.

Frequently Asked Questions about modificacion-segura-taimbox

High-intent search queries and answers about installing and using this skill.

FAQPage Schema

How do I safely modify shared types between frontend and backend without causing regressions?▼

Safely modifying shared types requires scoping edits to known files, exploring usages in src/ and supabase/ directories, and consulting repository documentation like DOCUMENTACION.md before committing changes to minimize regressions.

What is the safest way to update AppContext and permissions in a shared codebase?▼

The safest way to update AppContext and permissions is through guided, scoped changes rather than sweeping edits, ensuring you check relevant docs sections like docs/08 and docs/09 to validate the impact on Realtime and RLS policies.

When should I consult documentation before changing capacity or date utilities?▼

You should always consult documentation like docs/08, docs/09, and DOCUMENTACION.md before changing capacity or date utilities, because these are shared contracts where unvalidated modifications can easily introduce frontend or backend regressions.

How do I check the impact of modifying Supabase RLS policies and Realtime contracts?▼

To check the impact of modifying Supabase RLS policies and Realtime contracts, use a Task explore approach to locate usages across src/, supabase/, and docs/ without loading the entire tree, then apply checklist-based governance before committing.

Can I make sweeping exploratory edits to shared contracts if the impact is uncertain?▼

No, you should not make sweeping exploratory edits when the impact is uncertain. Instead, use a Task explore approach to safely locate usages in src/, supabase/, and docs/ first, applying changes only after confirming the impact.

What are the limitations of making broad changes to shared frontend and Supabase contracts?▼

The main limitation of making broad changes to shared contracts is the high risk of regressions. Changes touching shared types, AppContext, or RLS require documentation-driven governance and checklist validation to ensure alignment and prevent issues.