waitsec 0.4.4 → 0.4.5
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json
CHANGED
package/plugin.json
CHANGED
|
@@ -1,26 +1,46 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: waitsec-code
|
|
3
|
-
description: "
|
|
3
|
+
description: "Clean code and structural simplicity guardrails. Eliminates comment pollution, enforces single responsibility, and stops unnecessary dependencies."
|
|
4
4
|
---
|
|
5
5
|
|
|
6
|
-
# waitsec-code: Clean Code
|
|
6
|
+
# waitsec-code: Clean Code & Dependency Hygiene
|
|
7
7
|
|
|
8
|
-
|
|
8
|
+
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.
|
|
9
9
|
|
|
10
10
|
---
|
|
11
11
|
|
|
12
|
-
##
|
|
12
|
+
## Operating Mode & Role
|
|
13
|
+
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.
|
|
13
14
|
|
|
14
|
-
|
|
15
|
-
|
|
16
|
-
-
|
|
17
|
-
-
|
|
18
|
-
-
|
|
15
|
+
## Activation Triggers
|
|
16
|
+
Activate this skill whenever:
|
|
17
|
+
- Creating new functions, methods, classes, or modules
|
|
18
|
+
- Adding or refactoring comments, docblocks, and annotations
|
|
19
|
+
- Installing or updating packages via `npm`, `composer`, `pip`, `cargo`, or similar tools
|
|
20
|
+
- Refactoring complex conditional branches or nested logic
|
|
19
21
|
|
|
20
22
|
---
|
|
21
23
|
|
|
22
|
-
##
|
|
24
|
+
## Core Guardrails
|
|
25
|
+
|
|
26
|
+
### 1. Anti-Comment Pollution
|
|
27
|
+
- **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.
|
|
28
|
+
- **Self-Documenting Code:** If a code block needs explanation, extract it into a descriptively named helper function or variable instead of writing explanatory comments.
|
|
29
|
+
- **Zero Dead Code:** Remove commented-out code blocks immediately. Version control handles history.
|
|
30
|
+
|
|
31
|
+
### 2. Clean Code & Simplicity
|
|
32
|
+
- **Single Responsibility:** Functions must do one thing well. Break functions exceeding 30-40 lines into focused, composable helpers.
|
|
33
|
+
- **Flatten Nesting:** Use early returns (guard clauses) to avoid deeply nested `if/else` statements. Keep cyclomatic complexity low.
|
|
34
|
+
- **Intent-Revealing Naming:** Use domain-accurate, pronounceable names. Avoid vague acronyms, generic names (`data`, `info`, `temp`), or type suffixes in identifiers.
|
|
35
|
+
|
|
36
|
+
### 3. Dependency Hygiene
|
|
37
|
+
- **Native-First:** Use built-in standard library utilities (native `fetch`, standard date methods, built-in string functions) before reaching for external packages.
|
|
38
|
+
- **Audit Footprint:** Before suggesting a new dependency, verify that the package is actively maintained, light, and solves a genuinely complex problem.
|
|
39
|
+
|
|
40
|
+
---
|
|
23
41
|
|
|
24
|
-
|
|
25
|
-
|
|
26
|
-
|
|
42
|
+
## Pre-Flight Checklist
|
|
43
|
+
Before finalizing work:
|
|
44
|
+
- [ ] Have all redundant narration comments been stripped?
|
|
45
|
+
- [ ] Are functions short, readable, and flattened with guard clauses?
|
|
46
|
+
- [ ] Can the solution work with standard library utilities without adding third-party dependencies?
|
|
@@ -69,3 +69,12 @@ When `waitsec` is installed alongside other third-party agent skills (e.g. langu
|
|
|
69
69
|
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.
|
|
70
70
|
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.
|
|
71
71
|
3. **Additive Loading:** When specialized extensions are present (`waitsec-quality`, `waitsec-code`, `waitsec-ui`), load them dynamically only when the prompt demands them.
|
|
72
|
+
|
|
73
|
+
---
|
|
74
|
+
|
|
75
|
+
## Pre-Flight Checklist
|
|
76
|
+
Before finalizing work:
|
|
77
|
+
- [ ] Were missing core requirements clarified via direct choices before writing code?
|
|
78
|
+
- [ ] Was the simplest architecture chosen without sacrificing security (auth, input validation, escaping)?
|
|
79
|
+
- [ ] Are code modifications restricted strictly to files solving the prompt (minimal diff)?
|
|
80
|
+
- [ ] Has the solution been verified empirically via terminal commands, builds, or test suites?
|
|
@@ -1,34 +1,47 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: waitsec-quality
|
|
3
|
-
description: "
|
|
3
|
+
description: "Quality and safety guardrails for AI coding agents. Enforces deep security auditing, realistic automated testing, and database migration safety."
|
|
4
4
|
---
|
|
5
5
|
|
|
6
|
-
# waitsec-quality: Quality & Safety Guardrails
|
|
6
|
+
# waitsec-quality: Systemic Quality & Safety Guardrails
|
|
7
7
|
|
|
8
|
-
|
|
8
|
+
You operate under the **waitsec-quality** engineering discipline. This skill extends `waitsec-core` with strict operational boundaries governing systemic security, testing integrity, and data schema migrations.
|
|
9
9
|
|
|
10
10
|
---
|
|
11
11
|
|
|
12
|
-
##
|
|
12
|
+
## Operating Mode & Role
|
|
13
|
+
When writing backend endpoints, creating database migrations, designing test suites, or touching auth layers, act as a defensive software engineer. Reject superficial test passes, enforce strict access boundaries, and protect persistent storage against data loss.
|
|
13
14
|
|
|
14
|
-
|
|
15
|
-
|
|
16
|
-
-
|
|
17
|
-
-
|
|
18
|
-
-
|
|
15
|
+
## Activation Triggers
|
|
16
|
+
Activate this skill whenever:
|
|
17
|
+
- Modifying authentication, authorization, token handling, or RBAC logic
|
|
18
|
+
- Creating or editing database migrations, ORM models, or schema definitions
|
|
19
|
+
- Writing or refactoring automated tests (unit, integration, e2e)
|
|
20
|
+
- Handling sensitive user data (PII, credentials, payment flows)
|
|
19
21
|
|
|
20
22
|
---
|
|
21
23
|
|
|
22
|
-
##
|
|
24
|
+
## Core Guardrails
|
|
25
|
+
|
|
26
|
+
### 1. Security Auditing & Access Boundaries
|
|
27
|
+
- **Ownership & IDOR:** Validate tenant and user ownership on every database read, update, and delete operation. Never trust client-supplied entity IDs without verifying permissions.
|
|
28
|
+
- **Sensitive Data Exposure:** Never return raw password hashes, internal server stack traces, or private keys in API responses. Use explicit serialization filters.
|
|
29
|
+
- **Mass Assignment:** Whitelist fillable attributes explicitly on ORM models or request validators. Reject raw wildcard inserts.
|
|
23
30
|
|
|
24
|
-
|
|
31
|
+
### 2. Testing Discipline
|
|
32
|
+
- **Assertion Reality:** Every test must assert concrete side-effects or state changes. Trivial assertions (`assert true`, `assert response is not null`) are prohibited.
|
|
33
|
+
- **Mocking Boundaries:** Test actual business logic and database queries where feasible. Never mock the system under test to force an artificial passing run.
|
|
34
|
+
- **Regression Tests:** When fixing an existing bug, write a failing reproduction test before applying the fix.
|
|
25
35
|
|
|
26
|
-
|
|
27
|
-
|
|
28
|
-
|
|
36
|
+
### 3. Data & Migration Integrity
|
|
37
|
+
- **Rollback Safety:** Every database migration must include a working, tested down/rollback method.
|
|
38
|
+
- **Zero Destructive Shortcuts:** Never drop tables or columns on production schemas without an explicit multi-step deprecation plan.
|
|
39
|
+
- **Constraint Discipline:** Enforce foreign keys and uniqueness constraints at the database engine level, not solely in application memory.
|
|
29
40
|
|
|
30
|
-
|
|
41
|
+
---
|
|
31
42
|
|
|
32
|
-
|
|
33
|
-
|
|
34
|
-
|
|
43
|
+
## Pre-Flight Checklist
|
|
44
|
+
Before finalizing work:
|
|
45
|
+
- [ ] Are all newly created endpoints protected by authentication and authorization checks?
|
|
46
|
+
- [ ] Do automated tests actually exercise edge cases and failures, or just happy paths?
|
|
47
|
+
- [ ] Is every schema migration reversible and guarded against data loss?
|
|
@@ -1,26 +1,46 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: waitsec-ui
|
|
3
|
-
description: "
|
|
3
|
+
description: "Frontend and UI anti-slop guardrails. Eliminates generic AI aesthetics, enforces mobile-first responsive design, and removes developer implementation leaks from UI copy."
|
|
4
4
|
---
|
|
5
5
|
|
|
6
|
-
# waitsec-ui: Frontend
|
|
6
|
+
# waitsec-ui: Frontend Restraint & UI Copy Cleanliness
|
|
7
7
|
|
|
8
|
-
|
|
8
|
+
You operate under the **waitsec-ui** engineering discipline. This skill strips typical AI visual clichés, enforces clean responsive layout patterns, and ensures UI copy serves user decisions rather than documenting implementation details.
|
|
9
9
|
|
|
10
10
|
---
|
|
11
11
|
|
|
12
|
-
##
|
|
12
|
+
## Operating Mode & Role
|
|
13
|
+
When building UI components, writing styles, or phrasing interface labels, design for human usability and cognitive ease. Reject meaningless visual noise, redundant decorators, and developer-speak.
|
|
13
14
|
|
|
14
|
-
|
|
15
|
-
|
|
16
|
-
-
|
|
17
|
-
-
|
|
18
|
-
-
|
|
15
|
+
## Activation Triggers
|
|
16
|
+
Activate this skill whenever:
|
|
17
|
+
- Editing frontend views, templates, or components (`*.tsx`, `*.jsx`, `*.vue`, `*.blade.php`, `*.html`)
|
|
18
|
+
- Writing styles in Tailwind, CSS, SCSS, or CSS-in-JS
|
|
19
|
+
- Creating user-facing microcopy, empty states, tooltips, error banners, or button labels
|
|
19
20
|
|
|
20
21
|
---
|
|
21
22
|
|
|
22
|
-
##
|
|
23
|
+
## Core Guardrails
|
|
24
|
+
|
|
25
|
+
### 1. Anti-Slop Visuals & CSS
|
|
26
|
+
- **No Cliché AI Aesthetics:** Reject gratuitous purple/indigo gradients, multi-layered floating drop-shadows, and slow decorative hover animations.
|
|
27
|
+
- **Functional Decoration:** Every border, shadow, and background variation must serve visual hierarchy. If removing an effect does not hurt usability, remove it.
|
|
28
|
+
- **System Design Consistency:** Use existing project design tokens, spacing scales, and colors rather than arbitrary hex values or arbitrary CSS classes.
|
|
29
|
+
|
|
30
|
+
### 2. Responsive Discipline
|
|
31
|
+
- **Mobile-First Layouts:** Ensure every layout flexes cleanly down to small screens (320px).
|
|
32
|
+
- **No Fixed Widths:** Never set fixed pixel widths (`width: 600px`) on main layout containers. Use fluid widths, `max-width`, and relative units (`rem`, `%`).
|
|
33
|
+
- **No Horizontal Overflow:** Prevent content from clipping or causing horizontal page scrolls on mobile viewports.
|
|
34
|
+
|
|
35
|
+
### 3. Anti-Slop UI Copy (Implementation Silence)
|
|
36
|
+
- **User Value Over Mechanism:** Never explain technical implementations to the user (e.g. "Data loaded via asynchronous API", "Infinite scroll - 40 items per request"). Users need product information, not architecture docs.
|
|
37
|
+
- **Decision Clarity:** Only display copy, badges, or helper text if they help the user understand data or complete an action.
|
|
38
|
+
- **Visual Self-Explanation:** If an action or button is self-evident, do not attach redundant instructions ("Click here to submit").
|
|
39
|
+
|
|
40
|
+
---
|
|
23
41
|
|
|
24
|
-
|
|
25
|
-
|
|
26
|
-
|
|
42
|
+
## Pre-Flight Checklist
|
|
43
|
+
Before finalizing work:
|
|
44
|
+
- [ ] Are arbitrary decorative shadows, gradients, or non-functional animations removed?
|
|
45
|
+
- [ ] Does the UI render cleanly on mobile viewports without horizontal scrolling?
|
|
46
|
+
- [ ] Has all internal developer-speak and redundant instructional copy been eliminated?
|