Release this around a visible outcome: choose a scoped task, watch it run, inspect its evidence, and keep or undo the result. Use the same real desktop in the product page, screenshots, reviewer letter and demonstrations.
Start with Linux developers and technical creators who already use agent tools but need a coherent desktop workflow. The first demonstration should repair a small code defect, run unchanged tests, show the diff and undo the result. A source report and verified media export show that Mission Control serves more than coding.
Present Grok Bot as the featured connected desktop option. Use a prominent capture of the official native app, plus a separate image of Shadowfetch's first-boot choice. Explain its own account and online service requirements next to the installation action. Keep coding-agent account requirements and Ice's offline workspace scope explicit.
Featured launch line: For the first time in Shadowfetch Linux, Grok Bot is an optional choice at startup. Keep this claim specific to Shadowfetch; worldwide priority has not been established. The 30-second Blender promo must give Grok Bot a dedicated 6–8 second scene with real native footage, featured startup setup and a clear voice-over introduction.
Suggested landing-page headline: Agent work you can inspect and undo.
Suggested supporting copy: Shadowfetch Linux 4.0 brings durable missions, scoped project access and featured Grok Bot setup to the KDE desktop. Choose the task, review the evidence, and decide what stays.
| Audience | Demonstration | Call to action |
|---|---|---|
| Linux developers | Repair a small defect, run the project's unchanged tests, inspect the diff, then restore the original files. | Try your first code mission. |
| Technical creators | Export a real audio file, inspect the decode and checksum receipt, then keep or restore the export. | Bring a small project to Mission Control. |
| Agent enthusiasts | Choose the featured official Grok Bot application during setup; show the independent coding-agent choices. | Choose your agent and project. |
Each demonstration should show the real setup requirements and the complete outcome. The release page and reviewer materials must retain the actual vendor connection boundary next to the native screenshot until a real account and cloud task have been verified. In the launch film, show the actual startup choice and Sign in screen with “Optional · Account and internet required”; do not imply a completed cloud task.
Prepare a 60–90 second release walkthrough, three short task clips, the final desktop press kit, a migration article, and a concise comparison of Fire and Ice. Reuse the same verified task outputs across the website, GitHub release, letter and clips. These recordings are campaign assets to produce; the screenshot pack and letter are separate deliverables already being prepared.
| Timing | Action | Evidence or measurement |
|---|---|---|
| Before release | Publish signed artifacts, corresponding source, accepted QA evidence and exact desktop captures. | Website, GitHub and download facts agree. |
| Launch day | Publish the release page and a short recorded code mission from start to reviewed result. Prepare the supplied reviewer letter and screenshot pack. | Public links resolve; no mockup represents a finished task. |
| Days 2 to 7 | The user sends the letter to selected Linux reviewers and existing community contacts. Publish a Grok Bot installation walkthrough and an Ice offline-workspace walkthrough. | Track referred download-page visits and explicit feedback. |
| Week 2 | Publish a troubleshooting article based on real installation feedback and a source-report/media demonstration. | Count reproducible issues, fixes and completed task reports. |
| Weeks 3 to 4 | Share an evidence-led progress note and prioritize the next point release from observed friction. | Compare setup completion, mission completion and recovery usability. |
Outreach is a plan for the user to execute. No email, social post or reviewer message is sent by this release task.
Produce this after the release is shipped and verified. The creative idea is step inside your operating system: a camera travels through a physical, illuminated world of the finished desktop. Use actual Blender geometry, materials, lighting and camera animation, with the exact release screens integrated into the environment. Give the opening a clear silhouette and immediate motion so it reads on a phone before the viewer enables sound.
| Time | Picture and purpose |
|---|---|
| 0–3 seconds | A dark architectural space powers on around the Shadowfetch emblem; the camera passes through the startup portal. Introduce “Shadowfetch Linux 4.0.” |
| 3–7 seconds | Reveal Mission Control as a large, readable surface in the environment. Establish the task, scope and review workflow. |
| 7–15 seconds | The featured Grok Bot startup card becomes the central scene. Move into the real official application capture. Speak the first-in-Shadowfetch startup line; keep optional installation and online account requirements readable. Preserve the actual verified application state. |
| 15–22 seconds | Three purposeful reveals show code with tests, a cited report and a verified media export. A clear review/Undo beat makes the product benefit concrete. |
| 22–26 seconds | Connected Fire and offline-workspace Ice environments divide the space, with accurate labels and restrained motion. |
| 26–30 seconds | Resolve into the Shadowfetch mark, “Your machine. Your missions.” and shadowfetchlinux.org. Hold the destination long enough to read. |
Create a 16:9 master and a separately composed 9:16 social edition, each exactly 30 seconds. Deliver voiced and captioned exports, caption files and the editable Blender project with its required assets. Review representative frames before the full render, then inspect moving transitions, screen legibility, caption placement, voice intelligibility, music balance and the complete decoded exports. Avoid flashes that obscure the product or tiny paragraphs that cannot be read on a phone. A polished film can improve attention; no view count or viral result is guaranteed.
Prepare a launch-post draft, a short pinned reply linking the download and a thumbnail based on the actual Grok startup scene. Adapt the copy for X, YouTube Shorts, Instagram Reels and Linux community posts; retain the same product claims. The release task prepares these assets without posting them. Compare completion rate, qualified visits to the download page and voluntary setup reports. Use the observed drop-off point to choose the next edit, rather than adding effects without evidence.
Use aggregated website and artifact request counts to compare channels. Do not call a download request an installed user. For activation, offer an optional local checklist/export: desktop booted, selected tool set up, first mission completed, result reviewed, and Undo tried. Keep desktop measurement opt-in and separate from the task's private content.
Record issues by stage: download and verification, installation, agent setup, workspace access, task execution and recovery. Measure repeatable completion on documented hardware before using any speed or reliability claim in marketing. Grok desktop launch, account sign-in and a completed cloud task are separate milestones.
Use distinct campaign links for the release letter, installation guide and each demonstration. A useful first cohort is 20 volunteer testers across documented machines, with a proposed target of 15 completing a first mission and 10 successfully trying Undo. These are launch targets, not measured results. Record why anyone stops. Prioritize a setup failure affecting several testers before increasing promotion.
Start with the existing community, GitHub release subscribers, and a small personal reviewer list. Offer reviewers a concrete test project and verification instructions. Reply to substantive feedback with a reproduced result or an issue link. Keep any paid promotion as a later, optional experiment with a fixed budget; do not buy traffic until the installation and first-mission experience is understood.
- Scheduled missions with bounded permissions. Add visible timers, a named project, an expiry and a resource budget. Begin with report refreshes and workspace checks; every run keeps its receipt and review state.
- A reusable mission library. Export task templates with declared inputs, tools, tests and network requirements. Validate templates before importing them, and show the exact effective scope.
- Voice as a task draft. Turn speech into an editable mission proposal, then use the same reviewable task form. Avoid silently converting an ambiguous voice command into a destructive action.
- Proactive system diagnosis. Let a local agent summarize existing health and package diagnostics, with a concrete repair plan and Phoenix recovery point before privileged changes.
- A small fleet view. Allow paired, explicitly authorized computers to report queue status and resource availability. Make the execution computer and data transfer visible for every remote task.
- A measured model adviser. Use actual memory limits and a short local test to suggest suitable models. Add verified hardware profiles over time, distinguishing VM evidence from physical GPU performance.
Prioritize timers and mission templates after the first release feedback. They extend the working queue and scope model with less complexity than a fleet or always-on voice interface.
Scope revision approved by the user: local AI is deferred for4.0. Exclude Buzz and local-model scenes or claims. Code and source-report missions use configured Codex cloud access; media exports and workspaces remain available offline. Preserve the prominent Grok startup choice and actual native sign-in scene.