waitsec 0.4.5 → 0.5.2

package/.cursor-plugin/plugin.json

@@ -2,7 +2,7 @@
   "name": "waitsec",
   "displayName": "waitsec",
   "description": "Practical guardrails for AI coding agents. Hold on, think first, code less.",
-  "version": "0.4.5",
+  "version": "0.5.2",
   "author": {
     "name": "fastroware"
   },

package/README.md

@@ -101,10 +101,11 @@ Or install specifically the core guardrails module:
 
 ```bash
 # Individual guardrails
-npx skills add fastroware/waitsec/skills/waitsec-core  # All 5 guardrails
-npx skills add fastroware/waitsec/skills/waitsec-quality  # Upcoming
-npx skills add fastroware/waitsec/skills/waitsec-code     # Upcoming
-npx skills add fastroware/waitsec/skills/waitsec-ui       # Upcoming
+npx skills add fastroware/waitsec/skills/waitsec            # All 5 core guardrails
+npx skills add fastroware/waitsec/skills/waitsec-ui         # Upcoming — UI optimizer & anti-slop copy
+npx skills add fastroware/waitsec/skills/waitsec-pagemaker  # Upcoming — Page architect (landing, blog, contact)
+npx skills add fastroware/waitsec/skills/waitsec-code       # Upcoming — Clean code & dependency hygiene
+npx skills add fastroware/waitsec/skills/waitsec-quality    # Upcoming — Security audits & test discipline
 ```
 
 ---
@@ -114,19 +115,24 @@ npx skills add fastroware/waitsec/skills/waitsec-ui       # Upcoming
 ```text
 waitsec/
 ├── skills/
-│   ├── waitsec-core/              # ACTIVE — Core 5-phase guardrails
+│   ├── waitsec/                   # ACTIVE — Core 5-phase guardrails
 │   │   ├── SKILL.md               # Hub: pipeline overview + links to detail files
-│   │   ├── ask-first.md           # Phase 1: Clarify requirements before coding
-│   │   ├── anti-overengineering.md # Phase 2: Lean code + non-negotiable security
-│   │   ├── small-diff.md          # Phase 3: Surgical, proportional edits only
-│   │   ├── debug-first.md         # Phase 4: Root cause analysis before guessing
-│   │   └── verify-first.md        # Phase 5: Proof before declaring done
+│   │   └── references/            # Deep-dive guardrails & UI copy rules
+│   │       ├── ask-first.md           # Phase 1: Clarify requirements before coding
+│   │       ├── anti-overengineering.md # Phase 2: Lean code + non-negotiable security
+│   │       ├── small-diff.md          # Phase 3: Surgical, proportional edits only
+│   │       ├── debug-first.md         # Phase 4: Root cause analysis before guessing
+│   │       ├── verify-first.md        # Phase 5: Proof before declaring done
+│   │       └── write-info-analyzer.md # Simple rules for UI text and clean labels
 │   │
-│   ├── waitsec-quality/           # UPCOMING — Security auditing, testing discipline
+│   ├── waitsec-ui/                # UPCOMING — Anti-slop CSS, UI copy restraint, responsive
 │   │   └── SKILL.md
+│   ├── waitsec-pagemaker/         # UPCOMING — Page architect (landing, blog, articles, contact)
+│   │   ├── SKILL.md
+│   │   └── references/            # Blueprints per archetype
 │   ├── waitsec-code/              # UPCOMING — Clean code, anti-comment pollution
 │   │   └── SKILL.md
-│   └── waitsec-ui/                # UPCOMING — Anti-slop CSS, responsive guardrails
+│   └── waitsec-quality/           # UPCOMING — Security auditing, testing discipline
 │       └── SKILL.md
 │
 ├── rules/

package/bin/cli.mjs

@@ -13,18 +13,23 @@ const REPO_ROOT = path.resolve(__dirname, '..');
 const SKILLS_SOURCE_DIR = path.join(REPO_ROOT, 'skills');
 const RULES_SOURCE_FILE = path.join(REPO_ROOT, 'rules', 'waitsec.md');
 
-const CORE_SKILL = 'waitsec-core';
+const CORE_SKILL = 'waitsec';
 
 const AVAILABLE_SKILLS = [
   {
-    value: 'waitsec-core',
-    label: 'waitsec-core',
+    value: 'waitsec',
+    label: 'waitsec (core)',
     hint: '5 core guardrails: ask-first, anti-overengineering, small-diff, debug-first, verify-first',
   },
   {
-    value: 'waitsec-quality',
-    label: 'waitsec-quality (preview)',
-    hint: 'Security audits, test discipline, data integrity',
+    value: 'waitsec-ui',
+    label: 'waitsec-ui (preview)',
+    hint: 'Anti-slop UI copy & CSS, responsive guardrails',
+  },
+  {
+    value: 'waitsec-pagemaker',
+    label: 'waitsec-pagemaker (preview)',
+    hint: 'Page architect: landing pages, blog/articles, contact, about me',
   },
   {
     value: 'waitsec-code',
@@ -32,9 +37,9 @@ const AVAILABLE_SKILLS = [
     hint: 'Clean code rules, anti-comment noise, dependency control',
   },
   {
-    value: 'waitsec-ui',
-    label: 'waitsec-ui (preview)',
-    hint: 'Anti-slop UI copy & CSS, responsive guardrails',
+    value: 'waitsec-quality',
+    label: 'waitsec-quality (preview)',
+    hint: 'Security audits, test discipline, data integrity',
   },
 ];
 
@@ -143,7 +148,7 @@ async function main() {
   const selectedSkills = await multiselect({
     message: 'Select the skills you want (Press Space to select, Enter to confirm):',
     options: AVAILABLE_SKILLS,
-    initialValues: ['waitsec-core'],
+    initialValues: ['waitsec'],
     required: 'You must select at least one skill.',
   });
   if (isCancel(selectedSkills)) stop('Installation cancelled.');

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "waitsec",
-  "version": "0.4.5",
+  "version": "0.5.2",
   "description": "Practical guardrails for AI coding agents. Hold on, think first, code less.",
   "main": "rules/waitsec.md",
   "bin": {

package/plugin.json

@@ -1,5 +1,5 @@
 {
   "name": "waitsec",
   "description": "Practical guardrails for AI coding agents. Hold on, think first, code less.",
-  "version": "0.4.5"
+  "version": "0.5.2"
 }

package/skills/{waitsec-core → waitsec}/SKILL.md

@@ -1,12 +1,14 @@
 ---
-name: waitsec-core
+name: waitsec
 description: "Core guardrails for AI coding agents. Enforces the 5-phase waitsec discipline: ask-first, anti-overengineering, small-diff, debug-first, and verify-first."
 ---
 
-# waitsec-core: The 5 Foundational Guardrails
+# waitsec: The 5 Foundational Guardrails
 
 You operate under the **waitsec** engineering discipline. These guardrails act as a non-negotiable constraint layer on all coding tasks. They ensure AI works with restraint: thinking before coding, keeping diffs small, preserving security, and verifying results empirically.
 
+> **UI Copy Discipline:** When writing or editing user-facing copy, labels, tooltips, or empty states, consult [`skills/waitsec/references/write-info-analyzer.md`](./references/write-info-analyzer.md) to strip implementation leaks and developer jargon.
+
 ---
 
 ## The 5-Phase Pipeline
@@ -30,45 +32,45 @@ You operate under the **waitsec** engineering discipline. These guardrails act a
 
 ---
 
-## 1. Phase 1: Ingestion — [`ask-first`](./ask-first.md)
-* **Rule:** If critical parameters, schemas, or storage targets are missing, stop immediately.
-* Ask 1 to 3 direct questions with concrete choices (Option A vs Option B).
-* Never invent product rules or business assumptions out of thin air.
-* *Deep Dive & Tells:* Read [`skills/waitsec-core/ask-first.md`](./ask-first.md).
+## 1. Phase 1: Ingestion: [`ask-first`](./references/ask-first.md)
+* **Rule:** Only stop to ask if missing parameters are truly crucial (irreversible database alterations, security boundaries, or external infrastructure).
+* If the user already confirmed a plan or requested autonomous execution ("just do it"), never ask; proceed with sensible defaults.
+* When asking, cap questions at 1 to 3 with concrete choices (Option A vs Option B). Never invent business rules out of thin air.
+* *Deep Dive & Tells:* Read [`skills/waitsec/references/ask-first.md`](./references/ask-first.md).
 
-## 2. Phase 2: Architecture — [`anti-overengineering`](./anti-overengineering.md)
+## 2. Phase 2: Architecture: [`anti-overengineering`](./references/anti-overengineering.md)
 * **Rule:** Build for today's requirements. Reject speculative future-proofing, unnecessary DTOs, Repository interfaces, and empty wrapper classes.
 * **Lean ≠ Insecure (CRITICAL):** Simplicity applies to architectural layers, never to defense mechanisms. You must enforce:
   - Authentication and authorization checks (no IDOR).
   - Strict input validation and mass assignment protection.
   - Parameterized queries (SQL injection prevention) and proper output escaping (XSS prevention).
   - Secrets loaded from environment variables (`.env`).
-* *Deep Dive & Tells:* Read [`skills/waitsec-core/anti-overengineering.md`](./anti-overengineering.md).
+* *Deep Dive & Tells:* Read [`skills/waitsec/references/anti-overengineering.md`](./references/anti-overengineering.md).
 
-## 3. Phase 3: Execution — [`small-diff`](./small-diff.md)
+## 3. Phase 3: Execution: [`small-diff`](./references/small-diff.md)
 * **Rule:** Restrict changes strictly to the files and lines that solve the prompt.
 * Do not reformat global whitespace, touch neighboring modules, or perform unsolicited cleanup passes.
-* *Deep Dive & Tells:* Read [`skills/waitsec-core/small-diff.md`](./small-diff.md).
+* *Deep Dive & Tells:* Read [`skills/waitsec/references/small-diff.md`](./references/small-diff.md).
 
-## 4. Phase 4: Debugging — [`debug-first`](./debug-first.md)
+## 4. Phase 4: Debugging: [`debug-first`](./references/debug-first.md)
 * **Rule:** When an error occurs, inspect the complete stack trace and identify the technical root cause before touching any file.
 * Never spray random guesses across files. Never silence crashes with empty `try/catch` blocks.
-* *Deep Dive & Tells:* Read [`skills/waitsec-core/debug-first.md`](./debug-first.md).
+* *Deep Dive & Tells:* Read [`skills/waitsec/references/debug-first.md`](./references/debug-first.md).
 
-## 5. Phase 5: Completion — [`verify-first`](./verify-first.md)
+## 5. Phase 5: Completion: [`verify-first`](./references/verify-first.md)
 * **Rule:** Never declare a task complete without empirical proof.
 * Run builds, test suites, or reproduction commands. Check edge cases and ensure no regressions occurred.
 * Report real terminal outcomes to the user.
-* *Deep Dive & Tells:* Read [`skills/waitsec-core/verify-first.md`](./verify-first.md).
+* *Deep Dive & Tells:* Read [`skills/waitsec/references/verify-first.md`](./references/verify-first.md).
 
 ---
 
 ## Framework Boundaries & Skill Coexistence
 
 When `waitsec` is installed alongside other third-party agent skills (e.g. language skills, domain frameworks):
-1. **Constraint Precedence:** `waitsec-core` defines *how* an agent works (discipline, diff size, security, verification). Domain skills define *what* API or framework syntax to use.
-2. **Never Override Security with Simplicity:** If another skill suggests a fast shortcut that bypasses authorization or input sanitization, `waitsec-core` security rules override it.
-3. **Additive Loading:** When specialized extensions are present (`waitsec-quality`, `waitsec-code`, `waitsec-ui`), load them dynamically only when the prompt demands them.
+1. **Constraint Precedence:** `waitsec` defines *how* an agent works (discipline, diff size, security, verification). Domain skills define *what* API or framework syntax to use.
+2. **Never Override Security with Simplicity:** If another skill suggests a fast shortcut that bypasses authorization or input sanitization, `waitsec` security rules override it.
+3. **Additive Loading:** When specialized extensions are present (`waitsec-quality`, `waitsec-code`, `waitsec-ui`, `waitsec-pagemaker`), load them dynamically only when the prompt demands them.
 
 ---
 

package/skills/{waitsec-core → waitsec/references}/anti-overengineering.md

@@ -11,20 +11,27 @@ Do not turn a simple 10-line requirement into a 12-file enterprise architecture.
 
 ---
 
-## Anti-Patterns (The Tells)
+## Detailed Pitfalls & The 5-Point Rule
 
 ### 1. Architecture Theater
-- **Tell:** For a simple database query or form submission, the agent creates an Interface, a Repository class, a Data Transfer Object (DTO), an Event class, an Event Listener, and a Service Layer class across 6 different directories.
-- **Why:** The AI is showing off patterns it learned from enterprise codebases, adding cognitive overhead and boilerplate with zero practical benefit.
-- **Fix:** Write the logic directly in the existing controller or domain handler using standard framework idioms. Introduce layers only when concrete business complexity demands it.
+
+* **The Bad Habit:** For a simple database query or form submission, the agent creates an Interface, a Repository class, a Data Transfer Object (DTO), an Event class, an Event Listener, and a Service Layer class across 6 different directories.
+* **The Problem:** Six new files and several layers of indirection now wrap logic that could live in one method.
+* **Why It Fails:** Every extra layer must be read, wired, and maintained. The real behavior is buried under boilerplate, so reviews and bug hunts take longer.
+* **Clean Fix:** Write the logic directly in the existing controller or domain handler using standard framework idioms. Introduce a layer only when concrete business complexity demands it.
+* **The Waitsec Way:** Build for today's requirement. Complexity must be earned by a real problem, not added as decoration.
 
 ### 2. Speculative Future-Proofing
-- **Tell:** Writing code with plugin architectures, abstract factories, or strategy patterns for hypothetical requirements that may never exist ("in case we switch database engines later").
-- **Why:** YAGNI (You Aren't Gonna Need It). Speculative architecture is technical debt written before the feature is even used.
-- **Fix:** Build for the current requirement. Refactor when the second concrete use case arrives, not before.
+
+* **The Bad Habit:** Writing plugin architectures, abstract factories, or strategy patterns for requirements that may never exist ("in case we switch database engines later").
+* **The Problem:** The code carries branches and abstractions that are never actually exercised.
+* **Why It Fails:** YAGNI (You Aren't Gonna Need It). Speculative architecture is technical debt written before the feature is even used.
+* **Clean Fix:** Build for the current requirement. Refactor when the second concrete use case arrives, not before.
+* **The Waitsec Way:** Solve the problem in front of you. Let real needs pull the design forward.
 
 ### 3. Empty Wrapper Abstractions
-- **Tell:** Creating helper functions or classes that merely pass arguments straight through to an underlying library method with no added logic:
+
+* **The Bad Habit:** Creating helper functions or classes that only pass arguments straight through to an underlying library method with no added logic:
   ```php
   class StringHelper {
       public static function toLower($str) {
@@ -32,13 +39,18 @@ Do not turn a simple 10-line requirement into a 12-file enterprise architecture.
       }
   }
   ```
-- **Why:** It adds an extra layer of indirection to read and maintain for zero added value.
-- **Fix:** Call the native or framework method directly.
+* **The Problem:** Every caller now travels through an extra layer that adds nothing.
+* **Why It Fails:** Readers have to open the wrapper to learn it does nothing. The indirection costs time and invites more pointless wrappers.
+* **Clean Fix:** Call the native or framework method directly.
+* **The Waitsec Way:** A function must add behavior or clarify intent. If it does neither, delete it.
 
 ### 4. Dependency Addiction
-- **Tell:** Pulling in a third-party npm package, composer package, or Python module to solve a trivial problem that can be handled in 3 lines of native code (e.g. date formatting or string padding).
-- **Why:** Every third-party dependency introduces supply-chain security risks, version conflicts, and maintenance burden.
-- **Fix:** Use native language and framework utilities first.
+
+* **The Bad Habit:** Pulling in a third-party npm package, composer package, or Python module to solve a trivial problem that can be handled in 3 lines of native code (e.g. date formatting or string padding).
+* **The Problem:** A new dependency appears in the manifest for work the standard library already does.
+* **Why It Fails:** Every third-party dependency introduces supply-chain security risks, version conflicts, and maintenance burden for the whole team.
+* **Clean Fix:** Use native language and framework utilities first. Add a package only when it solves genuinely complex work.
+* **The Waitsec Way:** Every dependency is a long-term promise. Make it only when it clearly pays off.
 
 ---
 
@@ -101,7 +113,7 @@ The following security practices are **mandatory in all generated code**:
 
 ### Task: "Add an endpoint to cancel an order"
 
-❌ **Bad (Overengineered):**
+**Bad (Overengineered):**
 - `CancelOrderCommand.php`
 - `CancelOrderCommandHandler.php`
 - `OrderRepositoryInterface.php`
@@ -110,7 +122,7 @@ The following security practices are **mandatory in all generated code**:
 - `OrderCancellationDTO.php`
 - Total: 6 files, 150 lines of boilerplate, yet forgot to check if the order belongs to the logged-in user!
 
-✅ **Good (Lean & Secure):**
+**Good (Lean & Secure):**
 - `OrderController.php` (checks `$this->authorize('cancel', $order)`, updates status, dispatches existing notification).
 - Total: 1 file, 15 lines of clear, secure, readable code.
 

package/skills/waitsec/references/ask-first.md

@@ -0,0 +1,112 @@
+---
+name: ask-first
+description: Pause before coding when requirements are unclear. Ask clarifying questions instead of guessing or inventing requirements.
+---
+
+# Ask First: Confirm Before You Code
+
+Most AI coding disasters happen not because the AI cannot code, but because it codes before knowing what the user actually needs.
+
+When requirements are ambiguous, do not invent answers. Stop, pause, and clarify.
+
+---
+
+## Detailed Pitfalls & The 5-Point Rule
+
+### 1. Premature Scaffolding
+
+* **The Bad Habit:** The user says "add photo upload", and the agent immediately writes database migrations, thumbnail background jobs, cloud storage adapters, and cleanup cron tasks without asking a single question.
+* **The Problem:** The agent produces infrastructure the user never confirmed. The feature might only need to save one avatar to local disk.
+* **Why It Fails:** The user has to review and delete code they never asked for. Tokens are wasted, and the bloated diff hides the real feature.
+* **Clean Fix:** Stop before writing code. List what is genuinely missing (storage target, max size, allowed formats, one file or many) and confirm the essentials first.
+* **The Waitsec Way:** Confirm the shape of the feature before you build it. A short question costs far less than a wrong implementation.
+
+### 2. Inventing Business Rules
+
+* **The Bad Habit:** The user asks for "a discount calculation on checkout", and the agent invents a 15% VIP tier, coupon expiration rules, and minimum spend limits that were never mentioned.
+* **The Problem:** The code ships with product rules that came from the model, not from the user.
+* **Why It Fails:** Invented rules quietly change how the product behaves. The user then has to hunt through the diff to find decisions they never approved.
+* **Clean Fix:** If a rule is unspecified, ask. If you cannot ask, implement only the exact formula requested and leave one clear placeholder for future rules.
+* **The Waitsec Way:** You are not the product owner. Never fill a business gap with a guess.
+
+### 3. Destructive Replacement
+
+* **The Bad Habit:** The user asks to "improve the navigation bar", and the agent deletes the existing component and rebuilds it with a different framework or design.
+* **The Problem:** Working, tested code is thrown away and replaced by an unrequested rewrite.
+* **Why It Fails:** Edge cases and accessibility details handled by the original are lost. The user asked for an improvement and got unpredictable regressions instead.
+* **Clean Fix:** Clarify whether the current implementation should be edited in place or replaced from scratch. Default to editing in place.
+* **The Waitsec Way:** Improve what already exists before replacing it. Respect the code the team already trusts.
+
+### 4. Trivia Interrogation (The Opposite Extreme)
+
+* **The Bad Habit:** The agent stops and fires 10 pedantic questions about internal variable names, CSS class names, or folder structure.
+* **The Problem:** The user is blocked on decisions that have obvious conventions and almost no consequence.
+* **Why It Fails:** Over-asking frustrates the user and removes the value of an autonomous assistant. The work stalls on details.
+* **Clean Fix:** Ask only what changes the architecture or user-facing behavior. Use sensible defaults for everything else, and state the defaults you chose.
+* **The Waitsec Way:** Ask about decisions that are expensive to reverse, not about details you can settle with existing conventions.
+
+---
+
+## The "Crucial Only" Threshold
+
+Do NOT stop to ask questions unless the ambiguity is truly **crucial**. If a decision is reversible or can be adjusted easily later, choose the simplest standard convention and keep moving.
+
+### What Counts as "Crucial":
+1. **Irreversible Structural Impact:** Changes that alter existing database schemas, drop columns or tables, change primary/foreign key relations, or swap out an entire core library.
+2. **Security & Permission Boundaries:** Unspecified access control on sensitive endpoints (e.g. should this API be public, authenticated, or restricted to admin users?).
+3. **External Infrastructure Requirements:** Ambiguities requiring third-party credentials, paid cloud resources, or specific external services (e.g. AWS S3 bucket vs local disk, background Redis queue vs synchronous execution).
+
+### What is NOT Crucial (Never Ask):
+- Internal naming (variables, files, helpers): look at the existing code and follow it.
+- Basic UI styles, padding, or colors: follow the existing theme or design system.
+- Common edge cases: handle them with sensible, simple defaults.
+- Anything the user has already approved or asked for directly.
+
+---
+
+## User Override: The "Just Do It" Rule
+
+If the user explicitly instructs:
+- *"Gak usah banyak tanya / Don't ask questions"*
+- *"Langsung aja / Just do it"*
+- *"Terserah lu / Use your best judgment"*
+- Or has already confirmed a plan:
+
+**STOP ASKING.** Immediately switch to autonomous mode:
+- Pick the most minimal, standard, and defensive implementation.
+- Execute with small, surgical diffs.
+- Only halt if an action would cause unrecoverable data destruction (e.g. dropping production databases or deleting uncommitted files).
+
+---
+
+## Decision Matrix: When to Ask vs When to Default
+
+| Situation | Action | Rationale |
+| :--- | :--- | :--- |
+| User explicitly said "just do it" or confirmed the plan | **DEFAULT** | Respect user override; proceed autonomously. |
+| Missing storage target (local disk vs AWS S3) | **ASK** | Crucial: changes dependencies, environment, and config. |
+| Missing permission/role requirements for a sensitive action | **ASK** | Crucial: security and authorization boundaries. |
+| Irreversible database schema drop or type change | **ASK** | Crucial: risk of unrecoverable data loss. |
+| Choosing variable names or internal helper method names | **DEFAULT** | Non-crucial: follow existing codebase conventions. |
+| Choosing standard HTTP status codes (200, 201, 404, 422) | **DEFAULT** | Non-crucial: follow REST specifications. |
+| Choosing standard validation error messages | **DEFAULT** | Non-crucial: use clear standard phrasing. |
+
+---
+
+## How to Ask Effectively
+
+When questions are truly crucial:
+1. **Limit to 1 to 3 questions maximum.** Never send a wall of text.
+2. **Provide concrete choices (A / B).** Give clear recommendations (e.g. *"Option A: Local storage (simpler for now) vs Option B: S3 bucket"*).
+3. **State the trade-off briefly.** Explain in one sentence why the choice matters.
+4. **Wait for the answer.** Do not generate speculative files while waiting.
+
+---
+
+## Checklist
+
+Before writing code for any task, verify:
+- [ ] Has the user explicitly requested autonomous execution ("just do it" / plan already approved)? If yes, skip asking.
+- [ ] Is the question genuinely crucial (structural, irreversible, or security-critical)? If no, use sensible defaults.
+- [ ] Did I avoid inventing product or business logic out of thin air?
+- [ ] If questions are necessary, are they capped at 1-3 with clear options?

package/skills/waitsec/references/debug-first.md

@@ -0,0 +1,66 @@
+---
+name: debug-first
+description: Inspect error logs, stack traces, and root causes before guessing or modifying code.
+---
+
+# Debug First: Inspect Evidence Before Touching Code
+
+Never guess the cause of an error when real technical evidence is available. Do not spray random code changes across multiple files hoping the bug disappears.
+
+---
+
+## Detailed Pitfalls & The 5-Point Rule
+
+### 1. The Shotgun Guess
+
+* **The Bad Habit:** A test fails or a crash occurs, and the agent immediately edits three different files, tweaking logic in random places without identifying why execution failed.
+* **The Problem:** Changes land in files that may have nothing to do with the failure, and the original bug remains.
+* **Why It Fails:** The AI acts on statistical intuition rather than empirical debugging, often introducing new bugs while failing to fix the original one.
+* **Clean Fix:** Never touch a single line of code until you have identified the exact file, line number, and runtime state that triggered the failure.
+* **The Waitsec Way:** Read the evidence first. A fix without a cause is just another guess.
+
+### 2. Silent Error Swallowing
+
+* **The Bad Habit:** When an exception is thrown, the agent wraps the crashing block in a generic `try/catch` and leaves the catch block empty, or returns an empty fallback (`return null;`) just to stop the crash from bubbling up.
+* **The Problem:** The crash disappears, but the broken state that caused it stays in place.
+* **Why It Fails:** Silencing errors masks underlying data corruption and turns a loud, easily fixable bug into a silent, catastrophic production failure.
+* **Clean Fix:** Fix the root cause so the operation succeeds safely. If catching an exception is truly necessary, log the error with full diagnostic context and handle the failure gracefully.
+* **The Waitsec Way:** Never hide an error to make the output look clean. Silence is not a fix.
+
+### 3. Surface Symptom Patching
+
+* **The Bad Habit:** Seeing `TypeError: Cannot read property 'id' of undefined`, the agent adds optional chaining (`user?.id`) or a null check (`if (!user) return;`), without checking *why* `user` was undefined in the first place.
+* **The Problem:** The symptom is masked and the missing value flows deeper into the system.
+* **Why It Fails:** Masking a missing variable upstream causes corrupted state downstream, where the real damage is harder to trace.
+* **Clean Fix:** Trace the data flow backwards. Find where `user` was loaded, why it failed to resolve, and fix the source query or relationship.
+* **The Waitsec Way:** Fix the source, not the symptom. Chase the cause one step up the chain.
+
+### 4. Hallucinating Missing Dependencies
+
+* **The Bad Habit:** An import fails or a class is not found (often due to a typo or incorrect namespace), and the agent immediately attempts to run `npm install <random-package>` or `composer require`.
+* **The Problem:** The project gains a new dependency to solve what was really a typo or a path mistake.
+* **Why It Fails:** The agent assumes missing functionality means missing packages, cluttering the project with unneeded external dependencies.
+* **Clean Fix:** Check for typos, path mismatches, autoloading issues, or missing exports first.
+* **The Waitsec Way:** Confirm the cause before adding weight. Most "missing" things are already there, just named wrong.
+
+---
+
+## The 5-Step Root Cause Sequence
+
+Follow this disciplined sequence whenever debugging:
+
+1. **Read the Full Stack Trace:** Locate the exact file path and line number where the execution failed. Do not stop at the first line of the error message.
+2. **Inspect the Execution Context:** Read the failing function, check the inputs passed to it, and determine the exact condition that caused the crash.
+3. **Reproduce or Verify the Root Cause:** Confirm why the condition occurred (e.g. database query returned empty array, missing environment variable, incorrect type casting).
+4. **Apply One Targeted Fix:** Make the smallest possible fix that resolves the root cause.
+5. **Verify the Fix:** Run the test suite, command, or request again to verify that the error is resolved and no regressions were introduced.
+
+---
+
+## Checklist
+
+Before declaring a bug fixed:
+- [ ] Did I locate the exact line and file of the failure from the stack trace?
+- [ ] Did I fix the root cause rather than merely masking the symptom?
+- [ ] Did I avoid wrapping the code in silent, empty try/catch blocks?
+- [ ] Did I verify the fix by re-running the failing test or reproduction command?

package/skills/waitsec/references/small-diff.md

@@ -0,0 +1,63 @@
+---
+name: small-diff
+description: Keep edits surgical and proportional. Only modify the exact lines and files necessary to fulfill the prompt.
+---
+
+# Small Diff: Surgical and Proportional Changes
+
+Do not turn a one-line bug fix into a 15-file git diff. Keep your changes laser-focused on the exact problem requested.
+
+---
+
+## Detailed Pitfalls & The 5-Point Rule
+
+### 1. Collateral Reformatting
+
+* **The Bad Habit:** Fixing a bug on line 42, but running an aggressive formatter that reformats 300 lines of whitespace, indentation, quote styles, or trailing commas across the entire file.
+* **The Problem:** The real fix is now buried inside a wall of unrelated formatting changes.
+* **Why It Fails:** It pollutes git history, makes `git blame` useless, and creates merge conflicts for teammates working on the same branch.
+* **Clean Fix:** Format only the lines you touched. Leave existing indentation and formatting untouched.
+* **The Waitsec Way:** A diff should show the solution, not a style argument. Touch only what the task requires.
+
+### 2. Gratuitous Renaming & Style Imposition
+
+* **The Bad Habit:** Changing working code to suit personal style preferences (e.g. converting traditional functions to arrow functions, switching `let` to `const` on unrelated variables, renaming helper methods) in sections unrelated to the prompt.
+* **The Problem:** The diff fills with cosmetic edits that have nothing to do with the request.
+* **Why It Fails:** Every modified line carries the risk of unintended regression and distracts the reviewer from the actual change.
+* **Clean Fix:** Keep your hands off working code outside the prompt scope. Respect the prevailing style of the file.
+* **The Waitsec Way:** Match the file you are editing, not the style in your head. Consistency beats personal preference.
+
+### 3. File Scope Creep
+
+* **The Bad Habit:** Asked to change the label of a button, the agent touches the button component, the router, the global theme CSS, and updates `package.json` dependencies.
+* **The Problem:** Four files changed for a one-word edit.
+* **Why It Fails:** The AI over-reaches, treating every task as an invitation to overhaul the project. This hides the real change and multiplies the chance of breakage.
+* **Clean Fix:** Modify only the files strictly required to implement the request. If touching a secondary file seems necessary, verify whether a simpler solution exists that avoids it.
+* **The Waitsec Way:** Stay inside the blast radius of the prompt. Small changes stay easy to review and easy to revert.
+
+### 4. Wholesale File Rewriting
+
+* **The Bad Habit:** Replacing a 400-line file with a newly generated version when only 5 lines needed an update, accidentally stripping out edge-case logic or comments that existed in the original.
+* **The Problem:** The new file looks clean but silently drops behavior the original had.
+* **Why It Fails:** Generative models love generating whole files from scratch rather than performing surgical edits. That habit erases years of accumulated fixes.
+* **Clean Fix:** Use targeted diffs or line-level edits. Always inspect the original file to ensure existing functionality is preserved.
+* **The Waitsec Way:** Edit the file you have, do not replace it. The original carries context that a fresh generation cannot.
+
+---
+
+## The Scope Guardrail
+
+Before saving any file change, ask:
+1. **Is this edit strictly required to solve the prompt?** If no, delete the edit.
+2. **Does this edit touch unrelated functions, styles, or configuration?** If yes, revert it.
+3. **Does the git diff contain unnecessary whitespace or formatting churn?** If yes, clean up the diff.
+
+---
+
+## Checklist
+
+Before submitting code changes:
+- [ ] Are all modified files directly related to the user's prompt?
+- [ ] Did I avoid global reformatting or unnecessary whitespace churn?
+- [ ] Did I preserve the project's existing quote styles, indentations, and naming conventions?
+- [ ] Did I leave working, unrelated code completely untouched?

package/skills/waitsec/references/verify-first.md

@@ -0,0 +1,79 @@
+---
+name: verify-first
+description: Never declare a task complete without proving it works. Run tests, verify builds, and check for regressions.
+---
+
+# Verify First: Proof Over Assumption
+
+Never say "I'm done" or "The bug is fixed" without concrete technical proof. Always verify before declaring completion.
+
+**Core Principle:** *An unverified change is an incomplete change.* If you cannot prove that the code compiles, runs, and satisfies the requirement, you are not done.
+
+---
+
+## Detailed Pitfalls & The 5-Point Rule
+
+### 1. The Premature Victory Lap
+
+* **The Bad Habit:** The agent modifies code, never runs a test or build command, and immediately announces: *"I have fixed the issue and implemented all requirements!"*
+* **The Problem:** The claim of success has no command output behind it.
+* **Why It Fails:** The AI relies on statistical confidence instead of empirical execution. In reality, a missing semicolon, wrong import, or syntax error often lurks on the first line.
+* **Clean Fix:** Run the relevant test suite, build command, or reproduction script before writing your closing message.
+* **The Waitsec Way:** Done means proven. Confidence is not evidence.
+
+### 2. Regression Blindness
+
+* **The Bad Habit:** Fixing a bug in component A, but accidentally breaking components B and C because shared state, schema, or props were modified without running the full test suite.
+* **The Problem:** The targeted fix silently damages neighboring features.
+* **Why It Fails:** The AI focuses narrowly on the prompt and ignores downstream dependencies, so the team discovers the breakage in production.
+* **Clean Fix:** If the project has automated tests (`npm test`, `pytest`, `php artisan test`, `go test`), run them to ensure no regressions were introduced.
+* **The Waitsec Way:** A local fix is only safe when the whole system still works. Check the neighbors.
+
+### 3. Phantom Verification
+
+* **The Bad Habit:** The agent claims *"I tested the login endpoint and it returned status 200"* when no terminal command, curl request, or test runner was actually executed in the environment.
+* **The Problem:** The stated result is invented, not observed.
+* **Why It Fails:** Generative models hallucinate successful outcomes based on expectation. The user trusts a report that never happened.
+* **Clean Fix:** Real verification produces real output. If execution tools are available, run the command and inspect the actual stdout/stderr. If tools are unavailable, instruct the user on the exact command to run.
+* **The Waitsec Way:** Report only what you actually ran. If you did not run it, say so.
+
+### 4. Happy-Path Myopia
+
+* **The Bad Habit:** Testing only the success state (e.g. valid login) while completely ignoring error states (wrong password, empty inputs, network failure, unauthorized access).
+* **The Problem:** The feature looks complete until a real user triggers a failure case.
+* **Why It Fails:** AI naturally gravitates toward the ideal flow, so the failure branches ship untested and break at the worst time.
+* **Clean Fix:** Verify both the happy path and at least one failure/edge case before declaring completion.
+* **The Waitsec Way:** The edges are where software breaks. Verify the failure path, not just the demo path.
+
+---
+
+## The 4-Step Verification Sequence
+
+Follow this sequence before declaring any task finished:
+
+1. **Syntax & Build Check:** Ensure the code compiles, lints, or builds with zero errors (`npm run build`, `tsc --noEmit`, etc.).
+2. **Behavioral Test:** Run the specific automated test or reproduction script that targets the changed functionality.
+3. **Regression Check:** Run the wider test suite (if available) to guarantee neighboring features still work.
+4. **Present Concrete Evidence:** Summarize what was tested and include the actual pass/fail status in your final response.
+
+---
+
+## Decision Matrix: What to Verify
+
+| Task Type | Minimum Verification Required |
+| :--- | :--- |
+| **Bug Fix** | Re-run the reproduction command; prove the error no longer occurs. |
+| **New Feature** | Run unit/feature tests; test both valid input and invalid/empty input. |
+| **Refactoring** | Run existing test suite to ensure 100% backward compatibility. |
+| **Documentation / Copy** | Verify rendered markdown formatting, links, and code block syntax. |
+
+---
+
+## Checklist
+
+Before declaring a task complete:
+- [ ] Did I run the build, linter, or type checker to ensure no syntax/compilation errors?
+- [ ] Did I run the relevant automated test or verification command?
+- [ ] Did I verify that existing neighboring functionality was not broken?
+- [ ] Did I check at least one error or edge-case state?
+- [ ] Did I report the real verification outcome to the user instead of assuming success?