Follow the evidence to its source.
Articles link the research, engineering documentation, and practitioner material used in their reasoning. The source list names the publisher and identifies the kind of evidence. A vendor announcement, an engineering guide, and a controlled study answer different questions.
We distinguish a source’s reported result from our interpretation. A result measured on one codebase or task set does not establish the same result for your organization. Check study conditions, sample size, publication date, and limitations before using a number in a decision.
Treat examples as proposals to test.
Flowcharts, task contracts, review checklists, and evaluation thresholds are proposed ways to organize work. They need adaptation to the product, data, risks, and people involved. Illustrative examples are not customer case studies.
The same applies to downloadable skills. They are instruction templates, not executable guarantees, credentials, or permission to make changes. Your existing review and release authority still applies.
Use dates to understand what was checked.
Each article shows its publication date and the date its sources were reviewed. A separate update date is used when a substantive revision is recorded. An unchanged article does not become newly researched because the website was rebuilt.
Drafts are excluded from the public blog, feeds, Markdown, and MCP tools. Published articles and their machine-readable versions come from the same content files.
Reuse the work with context.
You may use and adapt the original templates and workflows with attribution to Vibe Haus. Third-party sources retain their own terms. Link the canonical article when sharing a method so readers can inspect the source list and any later revisions.
The Data / MCP / Skills page explains the public JSON feed, Markdown articles, and read-only MCP tools. None of these endpoints accepts private repository data or executes work for you.