← AegisVita - Brand Builder OSCONTENT HISTORY
WHAT CHANGED
Update to AegisVita - Brand Builder OS
Snapshot Oct 24, 2026 · 13:55 UTC · version 1.0.0
Collection source: downloaded plugin package.
First saved snapshot
No earlier snapshot is available to establish a change.
Save AegisVita - Brand Builder OS and check future changes in Following.
Up to 10 plugins free · no card required.
Compare saved observations
Download comparison JSONFull technical diff · 0 changed fields
Full snapshot data
{
"description": "Build accurate case studies from supplied, permissioned source material and keep illustrative or synthetic cases distinct from real evidence.",
"included_files": [],
"name": "case-study-builder",
"skill_md_contents": "---\nname: case-study-builder\ndescription: Build accurate case studies from supplied, permissioned source material and keep illustrative or synthetic cases distinct from real evidence.\n---\n# Case Study Builder\n\nUse when a user wants to turn a real project, customer experience, or documented result into a case study. A case study is only as strong as its source material and permissions.\n\n## Readiness and source check\n\nBefore drafting, establish:\n\n- Whether this is a real case, anonymized real case, composite, or fictional example.\n- Which source notes, records, metrics, and approvals are available and what the AIOS actually inspected.\n- Whether the subject has agreed to the intended use, naming, quotation, imagery, and channel; minimize sensitive details.\n- What the case can substantiate and what it cannot. A single case does not establish typical performance or causation.\n\nIf real evidence or permission is missing, offer a source-gathering template or a clearly labeled demonstration instead. Never fill gaps with plausible details.\n\n## Case-study structure\n\n1. **Context:** relevant starting conditions and scope.\n2. **Challenge:** the problem as documented or reported, with attribution.\n3. **Approach:** actions actually taken, distinguishing the user's work from other contributors.\n4. **Outcome:** only documented results, with dates, units, denominators, comparison basis, and limitations where applicable.\n5. **Interpretation:** bounded explanation; distinguish correlation, reported perception, and demonstrated causation.\n6. **Applicability:** who might find the approach relevant and what would need to differ in another context.\n\n## Claim and evidence controls\n\n- Preserve exact supplied figures; check arithmetic and units when possible. Label estimates and user-reported metrics. If a figure is unsupported or contradicted, flag it and suggest a sourced correction. Never publish a known-false figure as fact.\n- Do not fabricate testimonials, quotes, customer identity, baseline, method, timeline, or results.\n- Do not imply typical or guaranteed outcomes from one example. Explain selection and survivorship limits when relevant.\n- For regulated or high-stakes claims, recommend qualified review and use only approved, current source material.\n\n## Standard output\n\nDeliver a case outline or draft, a claim-to-source table, permission and privacy status, limitations, and the remaining confirmations needed before publication. Any synthetic sample must be visibly labeled throughout as **EXAMPLE / SYNTHETIC — NOT EVIDENCE**.\n"
}SHA-256 of public snapshot: 6b735096332d0448f08381bc205acaf5d3999798c06e5b3f6d31b17530925935