waitsec 0.4.4 → 0.5.0

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.4",
+  "version": "0.5.0",
   "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.4",
+  "version": "0.5.0",
   "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.4"
+  "version": "0.5.0"
 }

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,42 +32,51 @@ 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.
+
+---
+
+## Pre-Flight Checklist
+Before finalizing work:
+- [ ] Were missing core requirements clarified via direct choices before writing code?
+- [ ] Was the simplest architecture chosen without sacrificing security (auth, input validation, escaping)?
+- [ ] Are code modifications restricted strictly to files solving the prompt (minimal diff)?
+- [ ] Has the solution been verified empirically via terminal commands, builds, or test suites?

package/skills/{waitsec-core → waitsec/references}/ask-first.md

@@ -35,22 +35,55 @@ When requirements are ambiguous, do not invent answers. Stop, pause, and clarify
 
 ---
 
+## 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 |
 | :--- | :--- | :--- |
-| Missing storage location, file size limit, or format | **ASK** | Materially changes packages, disk, and schema. |
-| Missing permission/role requirements for a sensitive action | **ASK** | Critical security and authorization impact. |
-| Multiple valid architectures (e.g. queue worker vs synchronous) | **ASK** | Affects hosting environment and dependencies. |
-| Choosing variable names or internal helper method names | **DEFAULT** | Follow existing codebase conventions silently. |
-| Choosing standard HTTP status codes (200, 201, 404, 422) | **DEFAULT** | Follow standard REST / web specifications. |
-| Choosing standard validation error messages | **DEFAULT** | Use clear, standard phrasing. |
+| 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 asking questions:
+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.
@@ -60,8 +93,8 @@ When asking questions:
 
 ## Checklist
 
-Before writing code for any new feature, verify:
-- [ ] Are all critical requirements and constraints known?
+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 needed, are they capped at 1-3 with clear options?
-- [ ] Did I avoid asking trivial questions about things the codebase already answers?
+- [ ] If questions are necessary, are they capped at 1-3 with clear options?

package/skills/waitsec/references/write-info-analyzer.md

@@ -0,0 +1,117 @@
+# Write Info Analyzer: UI Copy & Text Cleaner
+
+You are an AI agent that checks every piece of text on the user interface. Your job is to decide whether each word is genuinely useful for the user or just extra noise.
+
+---
+
+## Main Principle
+
+**Do not assume that every single element needs a label, a tooltip, or an explanation.**
+
+A good user interface does not explain itself over and over. People come to use your app, not to read documentation about how the interface works behind the scenes.
+
+Always put **information that helps users make decisions or finish their tasks** first.
+
+---
+
+## When to Delete Text
+
+Delete any text if it meets any of these points:
+
+1. It only explains how the interface works from a coding perspective.
+2. It talks about code mechanisms like infinite scroll, pagination, lazy loading, rendering, caching, or background fetching.
+3. It repeats info that is already 100% obvious from the visual design.
+4. It does not help the user make a choice or take action.
+5. It does not provide context that the user actually needs.
+6. It sounds like a programmer talking to another programmer through the UI.
+7. It feels like helper text added just because an empty spot on the screen looked lonely.
+8. It uses technical words that normal users never need to hear.
+9. It displays internal stats or database numbers that give zero real value to the user.
+10. It clutters the screen and makes the app harder to look at without improving usability.
+
+---
+
+## Detailed Examples
+
+### Bad Example: Infinite Scroll Narration
+Text:
+> "Scroll for infinite • 53 total"
+> "Infinite scroll: 4,000 newest items, adds 40 items every time you scroll down."
+
+**Decision: REMOVE.**
+
+*Reason:*
+The user does not need to know that the app uses infinite scroll. The user can simply look at the list and scroll down. Explaining details like "adds 40 items every scroll" is developer documentation, not useful product information for regular people.
+
+---
+
+### Other Common Examples
+
+* Text: *"Data is loaded asynchronously"*
+  * **Decision: REMOVE.**
+  * *Reason:* Users do not need to know how the server talks to the browser.
+
+* Text: *"Showing 40 items per request"*
+  * **Decision: REMOVE.**
+  * *Reason:* Technical implementation detail.
+
+* Text: *"Total 53 active members"*
+  * **Decision: KEEP.**
+  * *Reason:* This number helps the user understand how big the group is.
+
+* Text: *"No results found"*
+  * **Decision: KEEP.**
+  * *Reason:* Crucial feedback so the user knows their search had zero matches.
+
+* Text: *"Last updated 5 minutes ago"*
+  * **Decision: KEEP.**
+  * *Reason:* Useful if data freshness matters for this specific task.
+
+* Text: *"Click the button below to continue"*
+  * **Decision: REMOVE.**
+  * *Reason:* The button label already tells the user what to do.
+
+---
+
+## 4 Decision Rules to Ask Every Time
+
+For each piece of text you review, ask yourself these 4 questions:
+
+1. Does the user actually need to know this information?
+2. Does this text help the user understand the data, make a decision, or finish a task?
+3. Is this text still useful if the user knows nothing about how the software was coded?
+4. Is the action or meaning already clear visually without any extra text?
+
+If the answer is **NO**, remove the text.
+
+---
+
+## Important Mindset
+
+**Clear does not mean more text.**
+
+Never add words just to make the interface feel "explained".
+
+If the visual design is already clear on its own, **staying quiet is much better than adding copy**.
+
+* Do not put a label on every single icon or card.
+* Do not describe every button click or screen change.
+* Do not explain how the code works under the hood.
+* Do not treat every number like it needs a paragraph of explanation.
+* Do not add "helpful text" by default.
+
+---
+
+## Output Format
+
+When analyzing any UI text, give your verdict using these three tags:
+
+* `KEEP` : When the text is truly useful and gives real value to the user.
+* `REMOVE` : When the text is UI slop, redundant words, or technical implementation talk.
+* `REWRITE` : When the information is genuinely useful, but the phrasing is too long, awkward, or too technical.
+
+Give a **short and concrete reason** for each decision.
+
+Focus on **user value**, not on explaining every single detail.
+
+If you are torn between keeping or deleting, **choose REMOVE**, unless the text is something the user truly cannot live without.

package/skills/waitsec-code/SKILL.md

@@ -1,26 +1,46 @@
 ---
 name: waitsec-code
-description: "[Coming Soon] Code quality extension for waitsec. Covers clean code patterns, anti-comment pollution, and dependency hygiene."
+description: "Clean code and structural simplicity guardrails. Eliminates comment pollution, enforces single responsibility, and stops unnecessary dependencies."
 ---
 
-# waitsec-code: Clean Code Guardrails
+# waitsec-code: Clean Code & Dependency Hygiene
 
-> **Status: Work in Progress.** This module is not yet active. Check [github.com/fastroware/waitsec](https://github.com/fastroware/waitsec) for release updates.
+You operate under the **waitsec-code** engineering discipline. This skill ensures source code remains readable, maintainable, and free from AI-generated boilerplate and comment pollution.
 
 ---
 
-## Planned Guardrails
+## Operating Mode & Role
+When generating, refactoring, or reviewing source code, maintain minimal cognitive load. Write self-documenting logic, respect idiomatic language conventions, and resist adding third-party packages for routine tasks.
 
-This extension targets the internal quality of the code itself:
-
-- **Anti-Comment Pollution** — No redundant inline comments that restate what the code already says. Comments explain *why*, not *what*.
-- **Clean Code Patterns** — Naming clarity, function length limits, single responsibility.
-- **Dependency Hygiene** — Avoid pulling in packages for trivial problems. Audit transitive dependencies before adding them.
+## Activation Triggers
+Activate this skill whenever:
+- Creating new functions, methods, classes, or modules
+- Adding or refactoring comments, docblocks, and annotations
+- Installing or updating packages via `npm`, `composer`, `pip`, `cargo`, or similar tools
+- Refactoring complex conditional branches or nested logic
 
 ---
 
-## How to Use When Released
+## Core Guardrails
+
+### 1. Anti-Comment Pollution
+- **Explain Why, Never What:** Do not write comments that narrate what the next line of code does (`// Loop through users`, `// Return response`). Code should read like plain English.
+- **Self-Documenting Code:** If a code block needs explanation, extract it into a descriptively named helper function or variable instead of writing explanatory comments.
+- **Zero Dead Code:** Remove commented-out code blocks immediately. Version control handles history.
+
+### 2. Clean Code & Simplicity
+- **Single Responsibility:** Functions must do one thing well. Break functions exceeding 30-40 lines into focused, composable helpers.
+- **Flatten Nesting:** Use early returns (guard clauses) to avoid deeply nested `if/else` statements. Keep cyclomatic complexity low.
+- **Intent-Revealing Naming:** Use domain-accurate, pronounceable names. Avoid vague acronyms, generic names (`data`, `info`, `temp`), or type suffixes in identifiers.
+
+### 3. Dependency Hygiene
+- **Native-First:** Use built-in standard library utilities (native `fetch`, standard date methods, built-in string functions) before reaching for external packages.
+- **Audit Footprint:** Before suggesting a new dependency, verify that the package is actively maintained, light, and solves a genuinely complex problem.
+
+---
 
-```bash
-npx waitsec --skill waitsec-core --skill waitsec-code
-```
+## Pre-Flight Checklist
+Before finalizing work:
+- [ ] Have all redundant narration comments been stripped?
+- [ ] Are functions short, readable, and flattened with guard clauses?
+- [ ] Can the solution work with standard library utilities without adding third-party dependencies?