@ericrisco/rsc 0.1.54 → 0.1.55
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/manifest.json
CHANGED
|
@@ -1,5 +1,5 @@
|
|
|
1
1
|
{
|
|
2
|
-
"version": "0.1.
|
|
2
|
+
"version": "0.1.55",
|
|
3
3
|
"counts": {
|
|
4
4
|
"skills": 258
|
|
5
5
|
},
|
|
@@ -2020,7 +2020,7 @@
|
|
|
2020
2020
|
},
|
|
2021
2021
|
{
|
|
2022
2022
|
"id": "gdpr-privacy",
|
|
2023
|
-
"description": "Use when
|
|
2023
|
+
"description": "Use when producing the GDPR artifacts a product publishes or hands over: a privacy policy true to what it processes, a cookie/consent banner, a lawful basis per purpose, an Art. 28 DPA, an SCC transfer mechanism, or a DSAR flow. Drafts for counsel review. NOT internal retention rules (that is `data-policy`), NOT consumer ToS (that is `terms-conditions`).",
|
|
2024
2024
|
"tags": [
|
|
2025
2025
|
"gdpr",
|
|
2026
2026
|
"privacy",
|
|
@@ -2379,7 +2379,7 @@
|
|
|
2379
2379
|
},
|
|
2380
2380
|
{
|
|
2381
2381
|
"id": "invoicing",
|
|
2382
|
-
"description": "Use when
|
|
2382
|
+
"description": "Use when issuing an invoice, quote, or credit note and moving it draft-to-paid — the legally required VAT fields, gap-free numbering, per-country e-invoicing mandates, dunning overdue ones. NOT recording a paid invoice in the books (that is `bookkeeping`), NOT Stripe SDK plumbing (that is `stripe`), NOT setting the price (that is `pricing`).",
|
|
2383
2383
|
"tags": [
|
|
2384
2384
|
"invoicing",
|
|
2385
2385
|
"billing",
|
|
@@ -3135,7 +3135,7 @@
|
|
|
3135
3135
|
},
|
|
3136
3136
|
{
|
|
3137
3137
|
"id": "no-code-app",
|
|
3138
|
-
"description": "Use when building an app on a no-code/low-code platform (Bubble, Softr, Glide
|
|
3138
|
+
"description": "Use when building an app on a no-code/low-code platform (Bubble, Softr, Glide over Airtable or Xano) — picking the platform, modeling the data, keeping usage-metered cost predictable, and planning the exit before lock-in. NOT a hand-written coded app (that is `nextjs`), NOT wiring SaaS tools together with no app UI (that is `automation-flows`).",
|
|
3139
3139
|
"tags": [
|
|
3140
3140
|
"no-code",
|
|
3141
3141
|
"low-code",
|
|
@@ -3307,7 +3307,7 @@
|
|
|
3307
3307
|
},
|
|
3308
3308
|
{
|
|
3309
3309
|
"id": "performance",
|
|
3310
|
-
"description": "Use when
|
|
3310
|
+
"description": "Use when a page or interaction is slow for one user and the fix starts from a measurement — a failing Core Web Vital (LCP, INP, CLS), a heavy JS bundle, wasted re-renders, an over-broad client boundary: profile, attribute the cost to one phase, fix it, re-measure. NOT surviving concurrent load (that is `scaling`), NOT the slow query (that is `postgresdb`).",
|
|
3311
3311
|
"tags": [
|
|
3312
3312
|
"performance",
|
|
3313
3313
|
"core-web-vitals",
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: gdpr-privacy
|
|
3
|
-
description: "Use when
|
|
3
|
+
description: "Use when producing the GDPR artifacts a product publishes or hands over: a privacy policy true to what it processes, a cookie/consent banner, a lawful basis per purpose, an Art. 28 DPA, an SCC transfer mechanism, or a DSAR flow. Drafts for counsel review. NOT internal retention rules (that is `data-policy`), NOT consumer ToS (that is `terms-conditions`)."
|
|
4
4
|
tags: [gdpr, privacy, data-protection, cookies, consent, lawful-basis, dpa, scc, dsar, ropa, dpia, rgpd]
|
|
5
5
|
recommends: [data-policy, terms-conditions, contracts, compliance, secure-coding, email-deliverability]
|
|
6
6
|
origin: risco
|
|
@@ -128,9 +128,7 @@ Per-right runbook: `references/dsar-and-consent.md`.
|
|
|
128
128
|
- **DPIA (Art. 35):** mandatory *before* any processing "likely to result in a high risk." Trigger checklist — do a DPIA if any apply: large-scale processing of special categories (Art. 9 data), systematic monitoring of a public area, or novel/high-risk technology (e.g. new biometric or AI-driven profiling). When in doubt, do it.
|
|
129
129
|
- **Breach (Art. 33/34):** notify the supervisory authority **within 72 hours** of becoming aware, unless the breach is unlikely to result in risk; notify affected individuals when the risk to them is high. Have the contact and the template ready *before* a breach, not during.
|
|
130
130
|
|
|
131
|
-
##
|
|
132
|
-
|
|
133
|
-
This skill drafts artifacts and flags issues. It is **not legal advice**. Emit the counsel/DPO-review line before anything is published or relied on — every time, no exceptions.
|
|
131
|
+
## Stakes, and what isn't yours
|
|
134
132
|
|
|
135
133
|
The fines make the stakes concrete: up to **€20M or 4% of global annual turnover** (whichever is higher) for the most serious infringements, €10M / 2% for the lesser tier; cumulative GDPR fines already exceed €7.1B. This is not a Big-Tech-only risk.
|
|
136
134
|
|
|
@@ -158,10 +156,4 @@ Hand off what isn't yours:
|
|
|
158
156
|
| "Industry-standard security" with no Art. 32 reference | Cite Article 32 and describe the actual measures |
|
|
159
157
|
| Says it's giving legal advice / the policy is safe to publish unreviewed | Flag for qualified privacy counsel / DPO every time |
|
|
160
158
|
|
|
161
|
-
|
|
162
|
-
|
|
163
|
-
- `references/privacy-policy-blueprint.md` — Art. 13/14 mandatory-disclosure sections as `[BRACKET]` fill-ins, each with a "why required" line.
|
|
164
|
-
- `references/dpa-and-transfers.md` — Art. 28 demand/offer clause table, 2021 SCC module picker, TIA skeleton, DPF note, sub-processor change-notice clause.
|
|
165
|
-
- `references/dsar-and-consent.md` — data-subject-rights runbook, the LIA three-part template, a compliant cookie-banner config shape, and the `verify.sh` banlist rationale.
|
|
166
|
-
|
|
167
|
-
Run `scripts/verify.sh <artifact-file>` over any policy/banner/DPA you emit to catch missing Art. 13/14 tokens, placeholder leftovers, boilerplate-lies, and a banner missing its reject control.
|
|
159
|
+
Run `scripts/verify.sh <artifact-file>` over any policy/banner/DPA you emit to catch missing Art. 13/14 tokens, placeholder leftovers, boilerplate-lies, and a banner missing its reject control (banlist rationale in `references/dsar-and-consent.md`).
|
|
@@ -14,9 +14,9 @@ should_trigger:
|
|
|
14
14
|
- prompt: "Someone emailed asking us to delete all their data — what's our deadline and process?"
|
|
15
15
|
why: DSAR/erasure flow and the one-month statutory clock with exceptions.
|
|
16
16
|
- prompt: "Redacta nuestra política de privacidad conforme al RGPD."
|
|
17
|
-
why:
|
|
17
|
+
why: Drafting the privacy policy under GDPR, asked in Spanish — matched by meaning, not keyword.
|
|
18
18
|
- prompt: "Revisa el banner de cookies del web perquè el rebuig sigui tan fàcil com acceptar."
|
|
19
|
-
why:
|
|
19
|
+
why: Cookie-banner review against the reject-parity rule, asked in Catalan.
|
|
20
20
|
|
|
21
21
|
should_not_trigger:
|
|
22
22
|
- prompt: "Define our internal data retention schedule and data-classification tiers."
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: invoicing
|
|
3
|
-
description: "Use when
|
|
3
|
+
description: "Use when issuing an invoice, quote, or credit note and moving it draft-to-paid — the legally required VAT fields, gap-free numbering, per-country e-invoicing mandates, dunning overdue ones. NOT recording a paid invoice in the books (that is `bookkeeping`), NOT Stripe SDK plumbing (that is `stripe`), NOT setting the price (that is `pricing`)."
|
|
4
4
|
tags: [invoicing, billing, vat-invoice, dunning, accounts-receivable, e-invoicing, quotes, credit-note]
|
|
5
5
|
recommends: [bookkeeping, stripe, pricing, contracts, proposals, e-signature, webhooks, finance-ops]
|
|
6
6
|
origin: risco
|
|
@@ -8,7 +8,7 @@ origin: risco
|
|
|
8
8
|
|
|
9
9
|
# Invoicing — cut the document, run the lifecycle, get paid
|
|
10
10
|
|
|
11
|
-
You
|
|
11
|
+
You own the billing document and its collection lifecycle: what must be on the page for a tax authority to accept it, how it moves from draft to paid, and how to chase money politely-then-firmly without breaking the law.
|
|
12
12
|
|
|
13
13
|
The whole job is three moves: **cut a valid document → run its lifecycle → get it paid.** Skip the validity step and the customer can't deduct the VAT. Skip the lifecycle and you lose track of who owes what. Skip the chase and you work for free.
|
|
14
14
|
|
|
@@ -39,7 +39,7 @@ Before anything, decide which document you are issuing — they use different nu
|
|
|
39
39
|
| Proforma | A "please-pay-this" preview that is not yet a tax document | Not the invoice series | No — not a fiscal invoice |
|
|
40
40
|
| Credit note / corrective (factura rectificativa) | To cancel or reduce an invoice already sent | Its own corrective series, **referencing the original number** | Reduces an existing obligation |
|
|
41
41
|
|
|
42
|
-
|
|
42
|
+
Never delete or renumber a finalized invoice to fix it — issue a corrective that points back at the original (see the lifecycle rule below).
|
|
43
43
|
|
|
44
44
|
## The legally-valid invoice checklist
|
|
45
45
|
|
|
@@ -143,12 +143,3 @@ Quotes follow `draft → finalize (assigns number) → accept`, which auto-gener
|
|
|
143
143
|
| Chasing payment with no statutory basis | Weak, easily ignored | From D+15 cite ECB+8pp interest + EUR 40 fixed cost |
|
|
144
144
|
| Omitting the per-rate VAT breakdown | Customer can't deduct VAT; invalid invoice | Net + rate + VAT amount per rate, plus total |
|
|
145
145
|
| Recording the payment in the books yourself | Wrong skill, double-entry not your job | Hand the paid invoice to `../bookkeeping/SKILL.md` |
|
|
146
|
-
|
|
147
|
-
## Hand-off
|
|
148
|
-
|
|
149
|
-
- Invoice paid → record + reconcile it: `../bookkeeping/SKILL.md`.
|
|
150
|
-
- Need the SDK / webhook plumbing: `../stripe/SKILL.md`, `../webhooks/SKILL.md`.
|
|
151
|
-
- Deciding the amount before you bill: `../pricing/SKILL.md`.
|
|
152
|
-
- The terms the invoice bills against: `../contracts/SKILL.md`.
|
|
153
|
-
- The pre-sale pitch, not the bill: `../proposals/SKILL.md`.
|
|
154
|
-
- Getting it signed: `../e-signature/SKILL.md`.
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: no-code-app
|
|
3
|
-
description: "Use when building an app on a no-code/low-code platform (Bubble, Softr, Glide
|
|
3
|
+
description: "Use when building an app on a no-code/low-code platform (Bubble, Softr, Glide over Airtable or Xano) — picking the platform, modeling the data, keeping usage-metered cost predictable, and planning the exit before lock-in. NOT a hand-written coded app (that is `nextjs`), NOT wiring SaaS tools together with no app UI (that is `automation-flows`)."
|
|
4
4
|
tags: [no-code, low-code, bubble, glide, softr, app-builder, mvp]
|
|
5
5
|
recommends: [nextjs, shopify, wordpress, automation-flows, spreadsheet-ops, notion-connector, stripe]
|
|
6
6
|
origin: risco
|
|
@@ -10,13 +10,9 @@ origin: risco
|
|
|
10
10
|
|
|
11
11
|
You are deciding whether to build an app on a visual platform, which platform, how to model it, and where the wall is. No-code is not "the easy way" — it is a trade: you buy speed-to-first-user and pay it back in logic ceilings and metered cost. Your job is to make that trade with eyes open.
|
|
12
12
|
|
|
13
|
-
|
|
13
|
+
**Decide the exit before you build the entrance.** If you cannot describe how you would leave, you are not building an MVP — you are building a hostage.
|
|
14
14
|
|
|
15
|
-
|
|
16
|
-
|
|
17
|
-
- No-code wins on **speed-to-first-user** — a working app in days, no deploy pipeline. That is the only thing it reliably wins.
|
|
18
|
-
- It dies on **deep conditional logic** and on **scale economics** — many-branch workflows get unmaintainable, and metering turns a $29 bill into a $400 one without warning.
|
|
19
|
-
- ~25-30% of no-code projects get rewritten when they outgrow the tool, at $50K-$250K. ~68% of platforms offer no code export. If you cannot describe how you would leave, you are not building an MVP — you are building a hostage.
|
|
15
|
+
No-code wins on **speed-to-first-user** — a working app in days, no deploy pipeline. That is the only thing it reliably wins. It dies on **deep conditional logic** and on **scale economics**: many-branch workflows get unmaintainable, and metering turns a $29 bill into a $400 one without warning.
|
|
20
16
|
|
|
21
17
|
## Step 0: is no-code even the right tool?
|
|
22
18
|
|
|
@@ -24,9 +20,9 @@ Run this gate before touching any builder. If any line is a clear yes, route out
|
|
|
24
20
|
|
|
25
21
|
| If the user really wants... | Stop and go to |
|
|
26
22
|
| --- | --- |
|
|
27
|
-
| A hand-written app, full control over code | [../nextjs/SKILL.md](../nextjs/SKILL.md) (or react) |
|
|
28
|
-
| A commerce storefront, products + checkout |
|
|
29
|
-
| A content site / blog / CMS |
|
|
23
|
+
| A hand-written app, full control over code | [../nextjs/SKILL.md](../nextjs/SKILL.md) (or [../react/SKILL.md](../react/SKILL.md)) |
|
|
24
|
+
| A commerce storefront, products + checkout | [../shopify/SKILL.md](../shopify/SKILL.md) |
|
|
25
|
+
| A content site / blog / CMS | [../wordpress/SKILL.md](../wordpress/SKILL.md) |
|
|
30
26
|
| To wire SaaS tools together, no app UI | [../automation-flows/SKILL.md](../automation-flows/SKILL.md) |
|
|
31
27
|
| A spreadsheet as the deliverable itself | [../spreadsheet-ops/SKILL.md](../spreadsheet-ops/SKILL.md) |
|
|
32
28
|
| A Notion workspace, not a published app | [../notion-connector/SKILL.md](../notion-connector/SKILL.md) |
|
|
@@ -89,6 +85,8 @@ bookings: { id, customer: ->customers, class: ->classes, status: [pending|paid|
|
|
|
89
85
|
payments: { id, booking: ->bookings, amount, provider_ref } # via stripe
|
|
90
86
|
```
|
|
91
87
|
|
|
88
|
+
Payments in any of these flows: see [../stripe/SKILL.md](../stripe/SKILL.md).
|
|
89
|
+
|
|
92
90
|
## Build logic without footguns
|
|
93
91
|
|
|
94
92
|
The metering model punishes the obvious-but-wrong way of doing things. Build defensively.
|
|
@@ -127,7 +125,7 @@ This is the section everyone skips and everyone regrets. Do it on day 1.
|
|
|
127
125
|
- Logic outgrows the canvas — many-branch conditionals, custom algorithms.
|
|
128
126
|
- Performance — it crawls at real row counts (the 10K-row test).
|
|
129
127
|
- Cost — the metered bill crosses what a real backend + hosting would cost.
|
|
130
|
-
4. **Price the rewrite honestly.**
|
|
128
|
+
4. **Price the rewrite honestly.** ~25-30% of no-code projects get rewritten when they outgrow the tool, at $50K-$250K. Knowing that number is what lets you decide *now* whether to start in code via [../nextjs/SKILL.md](../nextjs/SKILL.md) instead.
|
|
131
129
|
|
|
132
130
|
When two of those triggers fire, stop adding features and start the migration plan — do not keep pouring work into a runtime you are about to leave.
|
|
133
131
|
|
|
@@ -145,9 +143,3 @@ When two of those triggers fire, stop adding features and start the migration pl
|
|
|
145
143
|
| Testing only at demo scale (100 rows) | Load-test at 10x expected rows early | Snappy at 100 can crawl at 10,000 |
|
|
146
144
|
| No export plan, hope you never leave | Export day 1, keep model portable | 68% offer no code export; rewrite is $50K-$250K |
|
|
147
145
|
| Picking Bubble for a simple internal portal | Softr (flat-rate) for portals over data | Predictable cost, no per-write surprise |
|
|
148
|
-
|
|
149
|
-
## References
|
|
150
|
-
|
|
151
|
-
- [references/platform-limits.md](references/platform-limits.md) — 2026 pricing/metering/record-cap cheatsheet (Bubble WU tiers, Glide updates, Softr flat tiers), backend comparison (native/Airtable/Xano), cost-estimation worked examples, and the migrate-off trigger list, with sources and access dates.
|
|
152
|
-
|
|
153
|
-
Payments in any of these flows: see [../stripe/SKILL.md](../stripe/SKILL.md).
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: performance
|
|
3
|
-
description: "Use when
|
|
3
|
+
description: "Use when a page or interaction is slow for one user and the fix starts from a measurement — a failing Core Web Vital (LCP, INP, CLS), a heavy JS bundle, wasted re-renders, an over-broad client boundary: profile, attribute the cost to one phase, fix it, re-measure. NOT surviving concurrent load (that is `scaling`), NOT the slow query (that is `postgresdb`)."
|
|
4
4
|
tags: [performance, core-web-vitals, lcp, inp, cls, bundle-size, profiling, react, web-vitals]
|
|
5
5
|
recommends: [scaling, postgresdb, redis, nextjs, react, observability, monitoring]
|
|
6
6
|
profiles: []
|
|
@@ -15,12 +15,7 @@ The whole job in one line: **measure with a profiler → attribute the cost to o
|
|
|
15
15
|
|
|
16
16
|
**Prime directive: no fix without a profile first.** A waterfall, a flame chart, a bundle treemap, or a field CWV number comes before you touch code. The fix you guess is almost never the fix the measurement points at, and a "fast" change that moves a phase nobody was waiting on is wasted work that you then have to maintain.
|
|
17
17
|
|
|
18
|
-
|
|
19
|
-
|
|
20
|
-
- TTFB is the bottleneck because of a slow query or an N+1 → name it here, fix it in `../postgresdb/SKILL.md`.
|
|
21
|
-
- You decided *what* to cache to cut a phase, now make the cache race-free → `../redis/SKILL.md`.
|
|
22
|
-
- The problem only appears under concurrent load → `../scaling/SKILL.md`.
|
|
23
|
-
- You need the canonical App-Router / component data pattern, not the perf loop → `../nextjs/SKILL.md`, `../react/SKILL.md`.
|
|
18
|
+
Cross-reference, don't duplicate: the last column of the table below names where each deep fix lives. The one case it has no row for — you decided *what* to cache to cut a phase and now need that cache race-free — is `../redis/SKILL.md`.
|
|
24
19
|
|
|
25
20
|
## Decision table — symptom to first move
|
|
26
21
|
|