Use FIRST when someone asks for a new feature or a change to an existing one — before any schema, code or test. Works out what is actually being asked for, whether to build it or integrate a third party (Trustpilot, Stripe, Calendly and the like), where the data lives, who may do what, and what happens when the vendor is down. Produces a decision, then hands to feature-schema.
The English summary is being prepared. Showing the original description.
See how to installReview the instructions the agent will receive before you install.
Most wasted work is not badly built. It is built correctly after nobody asked the second question. This skill is the second question.
Run it before feature-schema. It takes minutes and it is the difference between "add
testimonials" meaning a table and meaning a Trustpilot widget — two different products, two
different costs, and the person asking usually has not distinguished them because they had no
reason to.
A feature request is already a proposed solution. Find out what it is solving, because the solution may be wrong even when the problem is real.
"I want a testimonials section."
1. What goes wrong today without it? "Prospects ask for references and I paste them into email." — that is the actual problem, and it might be solved by a page of static quotes rather than an approval workflow.
2. Who is it for — you, or a visitor? An internal tool and a public page have almost nothing in common except the word.
3. How many, how often? Six quotes edited twice a year is a content page. Six hundred arriving weekly is a moderation queue. Same words, different build.
4. What does done look like? In their words, so you can both tell when you are finished.
Stop asking once the answers stop changing what you would build. Three good questions beat eight thorough ones.
Default to neither, then integrate, then build — in that order, because that is increasing order of what you own forever.
Neither. A page of quotes in the CMS needs no table, no moderation, no vendor. If the real answer is six quotes that change twice a year, say so. The best version of some features is the one you do not build.
Integrate when the value is in the other party's network, not their software. Trustpilot matters because reviews on Trustpilot are trusted by people who do not trust your website. You cannot self-host that. Same for Google Reviews.
Build when the value is in your data and workflow. Testimonials you solicit and approve yourself carry no third-party trust — so a vendor adds a dependency and a bill in exchange for a form you could have built.
The test: would a visitor treat this differently because of whose logo is on it? If yes, integrate. If no, you are paying for a form.
These are the questions people skip, and each one has bitten a real deployment.
Where does the data live? Theirs means you cannot query it, join it, or take it with you. Every reporting question becomes an export. Ask directly: "in a year, do you need to answer questions about this data alongside your own?"
What happens when they are down? Decide now, not during the outage. Cache the last good response and serve it stale? Hide the section? Show an error? A page that half-renders because a widget timed out is the worst of the three, and it is what you get by default.
What does it cost at ten times the volume? Per-review, per-seat and per-call pricing all look free at demo scale.
Whose data are you sending them? If a customer's name or email leaves the building, that is a processor relationship with consent and DPDP/GDPR consequences. It belongs in the privacy policy before it ships, not after.
Can you leave? Export format, and whether the content is yours. Reviews collected on a platform usually stay on that platform.
Does it load in the browser or on the server? A third-party script in the page sees your visitors and can slow every page it touches. Server-side keeps the key private and the blast radius small.
Do not add a second vendor for a job one of these already does:
| Used for | |
|---|---|
| Resend | transactional email |
| Razorpay | payments |
| WhatsApp (Meta) | messaging, OTP |
| Notion | gated content pages |
| n8n | webhook relays and automation |
n8n in particular absorbs a lot of "we need an integration" requests without new code.
Once build-vs-integrate is settled, these decide the tables. feature-schema needs all five.
publish capability, which is enforced separately from edit.docs/PUBLIC_TEMPLATE.md has the rule; record it in work-units/session-state.json. Nothing
SaaS, tenancy or branding-shaped crosses.A rough shape, and the parts that are not obvious:
"Testimonials, built rather than integrated — the trust value is not there for self-solicited quotes. One table, an admin screen with approve/reject, a home-page section. Roughly a day.
Two things worth knowing: approved quotes are public, so anyone who submits one needs to be told that at the point of submission. And if you later want Trustpilot as well, these are separate systems — this does not become that."
Then get a yes. A one-line estimate that turns out wrong is recoverable; three days of silence is not.
feature-schema — tables, capabilities, RLS, the migrationfeature-testing — the browser pass, and the checks that outlive itsite-bootstrap — only if this changed branding or company identityNo reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Apply this site's visual identity — colours, type, logo files and fixed brand strings. Use for any page, component, social asset or document that should look like the site.
The English summary is being prepared. Showing the original description.
Use when a new feature needs a table, column or capability — evolving the schema so the new thing joins the permission, audit and RLS contract instead of sitting outside it. Covers the DDL/DML split, the resource/capability wiring, and the self-verifying migration.
The English summary is being prepared. Showing the original description.
Use after building a feature — explore it in a real browser to find what nobody predicted, then turn each finding into a deterministic test that guards it forever. Covers the agentic pass, what to generate vs hand-write, and how to skip honestly when a capability is missing.
The English summary is being prepared. Showing the original description.
Publishing content or deploying site-os — what caches exist, what refreshes them, and how to prove a change is actually live. Use when publishing a post or product, launching a page, deploying, or when someone says a change "isn't showing".
The English summary is being prepared. Showing the original description.
Handling secrets, keys and credentials for site-os — reading vigyan-secrets.md safely, moving keys into app_secrets, rotating, and responding to an exposure. Use whenever a task touches a key, token, password, .env file, app_secrets, encryption, or the secrets document.
The English summary is being prepared. Showing the original description.
Audit a page or the whole yoursite site (or a new site) for indexing readiness — cache headers, sitemap, robots, canonical, JSON-LD, internal links — and check the publish pipeline (Cloudflare purge/warm, IndexNow, GSC, Bing). Use before/after publishing content or launching a site.
The English summary is being prepared. Showing the original description.