Fulcra Dashboard#

This skill provides the automated setup for a lightweight, build-less web dashboard. It relies entirely on Alpine.js for state management and Vanilla CSS for styling. It eschews complex frameworks (like SvelteKit) and utility-class libraries in favor of a "Single-Scroll Artifact" or a "Static Triad".

View Locally or Publish Publicly#

This dashboard is designed to present the user's Fulcra data, which can be viewed locally or published publicly. By default, it runs on localhost using a simple Python static server. Please note that the dashboard includes and relies on scripts fetched from public CDNs (such as Alpine.js, D3.js, Plotly, etc.) for visualizing and presenting the data.

Important: The local working application root must never be published to the public internet directly, as it often contains intermediate files and full datasets. If the user wishes to share a dashboard, you must deploy only the isolated public/ directory that contains only the specific data and files intended for publication.

Reliable Delivery & Intent#

The primary and preferred method for delivering this view is generating a robust HTML application locally (via the static triad) and optionally publishing it (e.g., via Surge). Our goal is to make something impressive.

However, you must be aware of the user's intent:

• High-Fidelity Goal: If the user is specifically trying to build a high-quality dashboard, you should spend more time troubleshooting and trying to make the static triad, localhost server, or public deployment work.
• Fast Visibility (e.g., Onboarding): If the user is just trying to view things for the first time (such as during the fulcra-get-started flow), give faster delivery more weight.

If the primary static triad and deployment routes are truly not viable in the current environment, you must gracefully fall back to alternative delivery mechanisms. Alternative options include (but are not limited to):

• Prefab ( https://gofastmcp.com/apps/prefab): Using an external rapid-UI generator if configured.
• Custom HTML/Image Generation: Generating a simpler bespoke HTML file or using Python (e.g., matplotlib) to render a static image chart summarizing the data.
• ASCII Charts & Markdown: As a last resort, or for extremely fast inline updates, render the data directly in the chat using Markdown tables and ASCII visualizations.

Architecture Decrees#

When constructing this dashboard, you must follow these strict architectural rules to prevent the file from becoming a tangled, unmaintainable monolith:

1. Monumental Landmarks (Banner Comments): Divide the HTML file into distinct provinces using highly visible comments. This ensures you (the agent) can navigate and edit surgical blocks safely. html

   <!-- ========================================== -->
   <!-- 🏛️ PROVINCE: DASHBOARD LAYOUT & UI         -->
   <!-- ========================================== -->
   <main> ... </main>
   
   <!-- ========================================== -->
   <!-- 🧠 PROVINCE: ALPINE.JS STATE & LOGIC       -->
   <!-- ========================================== -->
   <script> ... </script>
   
   <!-- ========================================== -->
   <!-- 🎨 PROVINCE: D3.js VISUALIZATIONS          -->
   <!-- ========================================== -->
   <script> ... </script>
   
   

2. The Separation of Domains: Do not write massive inline Alpine logic (e.g., x-data="{ huge object }"). You must use Alpine.data() within the "Alpine.js State & Logic" province to extract the logic into a clean script block. The HTML should only contain the bindings ( x-data="dashboard()", x-text, x-show, etc.).

3. The Static Triad (Escape Hatch): While a single index.html is preferred, if the dashboard grows too vast, you may split it into three files:

   • index.html (Structure & Semantic HTML)
   • app.js (Alpine Alpine.data() and D3 functions)
   • styles.css (Custom overriding aesthetics) No build step is allowed.

Adding Advanced Visualizations#

When the user requests more complex or varied visualizations, you have two primary avenues:

1. Frontend: Multi-Dimensional & Interactive Charts (D3.js, Plotly, etc.)#

The default template includes basic charts, but the "Static Triad" architecture gracefully supports highly advanced, multi-dimensional visualizations—including interactive 3D WebGL scenes—without ever needing a build step.

• Workflow: Include the required CDN library (e.g., d3.js, plotly.js, d3-cloud) in index.html. Add a new rendering method inside the Alpine.data() block (or the script tag) to bind the .jsonl timeline data to the DOM.

• Supported Paradigms & Chart Types: You can expand the dashboard with various chart types tailored to the user's data. Do not restrict yourself to these examples; you are encouraged to pull in any chart type or lightweight CDN library that best fits the specific data. Examples include:

  • Temporal & Milestones: Implement Timeline or Gantt charts using D3 or Plotly to visualize spans of time, project milestones, or overlapping events.
  • Textual & Frequency: Use Word Clouds (via d3-cloud or similar lightweight libraries) or Tag Clouds to show the frequency of text terms, keywords, or activity logs natively in the browser.
  • Progress & Completion: Build Gauges, Progress Bars, or Burn-down charts to track completion status, quotas, or project progression against a defined goal.
  • Advanced Correlations: Heatmaps for daily frequency, 2D D3 scatter plots, or fully interactive 3D WebGL scatter plots (e.g., mapping Sleep on X, Focus on Y, and Steps on Z) to explore complex relationships.

• Styling Integration: Ensure advanced charting libraries blend seamlessly with the user's chosen theme. Explicitly configure library backgrounds and grid lines to be transparent or translucent so the CSS glassmorphism, gradients, and custom themes shine through. Increase container dimensions (e.g., .chart-tall { height: 400px; }) to give 3D scenes enough physical space to be comfortably rotated by the user.

• Constraint: Keep the rendering code clean and modular. Isolate chart rendering functions so they can be easily re-rendered on window resize or data updates.

2. Backend: Python-Generated Visualizations#

For highly complex, compute-intensive, or specialized visual outputs (like word clouds, network graphs, or composite rasterized images), leverage the Python backend.

• Workflow: Modify server.py (or create a secondary Python worker script) to read the local Fulcra .jsonl data, process it using libraries like matplotlib, seaborn, or networkx, and output a static image (e.g., .png, .svg) or pre-calculated JSON structure into the dashboard directory.
• Integration: Update index.html to reference the generated image (e.g., <img src="/generated-network.png">) or have the Alpine state fetch the advanced JSON artifact.
• Constraint: Ensure the Python generation step can be run independently or triggered reliably, so the dashboard always reflects the latest data without breaking the simple local server paradigm.

Permissions & Consent#

Before proceeding with the initial dashboard generation, you must explicitly declare your intentions and request the user's permission for the following actions:

1. Fetch Fulcra Data: Permission to query the Fulcra API to download their personal data.
2. Use Third-Party Scripts: Permission to include and rely on external scripts fetched from public CDNs (such as Alpine.js, D3.js, Plotly, etc.) to visualize the data.
3. Use Other Data Sources: Permission to use other external tools (like image generation) to enhance the dashboard's theme.

Wait for the user's explicit consent before proceeding with data ingestion or dashboard scaffolding. Once consent is granted for a specific project or workspace, you do not need to ask again for subsequent data updates or regenerations.

Usage#

When a user requests to "set up the web app" or "create a dashboard for the Fulcra skills" (or if they are transitioning from the fulcradynamics/agent-skills/fulcra-get-started skill), you should execute the setup script provided by this skill.

bash

# Run the setup script to scaffold the Alpine dashboard
./scripts/setup-dashboard.sh <target-directory>

If no <target-directory> is provided, it defaults to creating a fulcra-dashboard folder in the current working directory.

Workflow#

Contextual Awareness (Standalone vs. Post-Onboarding): Do not assume this skill is always run immediately after fulcra-get-started.

• If transitioning from Onboarding: The user has likely just seen a static HTML preview of their data. Acknowledge this transition and frame this step as building out and upgrading their existing preview into a live, interactive web app. Leverage the context of the annotations they just built, skip redundant discovery, and carry over their preferred theme.
• If running Standalone: You must first discover what data the user wants to visualize (run uv tool run fulcra-api catalog to check for user annotations and discuss options before proceeding).

1. Scaffold: The script copies a clean, un-styled Alpine.js dashboard template into the target directory.

2. Data Ingestion: Automatically fetch the user's relevant Fulcra data using the fulcra-api CLI (after securing the permissions mentioned above).

   • Run uv tool run fulcra-api catalog to discover available data. Note: Prioritize user-configured data over passive metrics (like step count). Explicitly filter for items where categories includes "user_configured", or where the id follows the format *Annotation/<UUID> (e.g., ScaleAnnotation/1234-abcd...).
   • Fetch records for the user's custom annotations (e.g., uv tool run fulcra-api get-records "ScaleAnnotation/<UUID>" "30 days" > timeline_name.jsonl).
   • Agent Visibility Package: If the user previously enabled the Universal Agent Visibility Package (or if you see "Agent Tasks Completed" and "Current Agent Work" in their catalog), you must fetch these agent annotations as well and explicitly include them in the data.json timelines array so your background work is visualized alongside their personal data.
   • Data Updates: You must run the data-updates CLI command for the timeline (e.g., uv tool run fulcra-api data-updates "30 days" > data_updates.json), explicitly move it to public/data_updates.json, and link it as "recordsProcessed": "data_updates.json" in your config to populate the "Your data" chart. Do not skip this step.
   • Keep the raw dumps in the root directory, and move ONLY the approved, final .jsonl and .json files to the public/ directory so the frontend can read them.
   • The public/data.json config file acts as a manifest. It should map your layout to the .jsonl files in the public/ directory, and you must include the annotation description in the timeline block, like this: {"summary": "An entertaining, thematic overview of the current data...", "timelines": [{"id": "...", "title": "...", "description": "The description from the catalog...", "icon": "...", "color": "...", "data": "timeline_name.jsonl"}], "recordsProcessed": "records_processed.jsonl"}. Crucial: For the "summary" field, you must read the downloaded .jsonl data and write an interesting, entertaining, and highly thematic text summary of the actual real-world activity. Adopt the persona of the dashboard's theme (e.g., an observatory log, a captain's entry, a baker's notes) to make the data narrative fun and engaging. Do not write boring meta-descriptions or dry analytical text.
   • You do not need to write an aggregation script; the dashboard will automatically parse .jsonl files and aggregate records for the charts natively on init().

3. Theming & Visualization:

   • Theme Discovery: Ask the user what "theme" or "vibe" they want (e.g., minimalist dark mode, cyberpunk, a retro diner, a space station, a cozy bakery).
   • Embrace the Theme (HTML & Copy): Do not leave default boilerplate intact! Modify index.html directly to rewrite the main title, subtitle, and all component headers to fit the theme (e.g., change "Fulcra Dashboard" to "The Cybernetic Core" and "Records Processed" to "Baguettes Baked"). Replace all default emojis (like 📊 or 🛰️) with theme-appropriate icons.
   • Preserve the Layout Container: The base HTML and CSS files use a .layout-container for spacing. Keep this structure intact. Limit your CSS edits to colors (by updating the root variables), fonts, borders, box-shadows, and backgrounds.
   • Original Art (Required): Generate one piece of highly creative thematic art using the image_generate tool. Save it to the folder and reference it via an <img> tag in the dashboard header. Style Directive: The image must be extremely high-quality and perfectly cohesive with the user's chosen theme. Whether the vibe calls for retro 2D pixel art, a minimalist vector illustration, or a sleek 3D render, ensure the specific art style, color palette, and lighting strictly match the CSS variables and overall aesthetic you are building.
   • Hero Image Prominence & Legibility: Ensure the generated thematic art does not get lost behind the dashboard title. Instead of blindly overlaying text across the entire image, use creative layouts like a split-panel hero (text on one side, unobstructed art on the other), a bento-style hero block, or a targeted gradient mask that leaves the primary subject of the art perfectly visible. Keep the overall header compact enough (e.g., min-height: 250px to 350px) so the core telemetry data remains visible "above the fold."
   • Dynamic Animated Elements: Do not settle for a simple moving dot or static icon. Create highly engaging, fun, and thematic animations. You are encouraged to pull in lightweight CDN libraries (e.g., tsparticles for rich particle systems like starfields or embers) or author complex, multi-layered CSS/SVG animations that genuinely delight the user.

4. Git Repository Initialization:

   • Once scaffolded, you must prompt the user to initialize a git repository.
   • Check if git is installed. Suggest 1 or 2 fun repository names based on their theme.
   • Initialize locally ( git init && git add . && git commit -m "Initial commit"). Do not push to GitHub yet.

5. Run & Verify:

   • Start the local Python server to preview the dashboard: bash

     cd <target-directory>
     python3 server.py 8081 > dev.log 2>&1 &
     
     

   • Provide the user with the localhost link.

6. Public Publication (Requires Consent & Preview):

   • The user may wish to publish a version of their dashboard to the public internet.

   • The built-in public directory: Because the dashboard is already structured with a public/ directory that only contains the UI and explicitly copied data files, you do not need to create a new folder from scratch.

     1. Ask the user to verify in the local preview that the data shown is exactly what they want to share.
     2. Ensure that public/ contains only the specific data files needed by the frontend, and that any raw data dumps, dev.log, or python scripts remain safely outside it in the root directory.

   • Crucial Warning & Confirmation: Directly at the point of publishing (before running any deployment tools), you must present a clear warning to the user. State exactly which data files are inside the public/ directory and will be made public, and explicitly ask for their final confirmation to proceed with the deployment.

   • Wait for their explicit confirmation before proceeding.

   • If they agree, offer them three deployment options, ordered by ease of use:

     • Option 1: Surge (Secure & Easiest, No Git Required)
       • Installation: npm install -g surge
       • Security Prep: Before deploying, ensure you insert <meta name="robots" content="noindex, nofollow"> into the <head> of public/index.html to prevent search engine indexing. (Surge subdomains are not publicly indexed or discoverable by default, so this combination provides security through obscurity and explicit opt-out).
       • Deployment: Generate a random 6-character alphanumeric suffix and run surge . <project-name>-<random-suffix>.surge.sh inside the public/ directory.
       • UX: The user will be prompted in the terminal for an email/password to create a free account on the fly (if not already authenticated). The folder will instantly deploy to the unguessable subdomain. You must present the final link to the user explicitly as an https:// URL.
     • Option 2: GitHub Pages (Best for Version Control)
       • Installation: Ensure gh (GitHub CLI) is installed and authenticated ( gh auth status).
       • Deployment: Navigate into the public/ directory, initialize git, create the repository, and push ( git init && git add . && git commit -m "Initial public export" && gh repo create <name> --public --source=. --remote=origin --push).
       • Enable Pages: gh api repos/{owner}/{repo}/pages -X POST -f "source[branch]=main" -f "source[path]=/".
       • UX: Creates a standard GitHub repository and publishes to https://<username>.github.io/<repo>/.
     • Option 3: Vercel (No Git Required, Professional Hosting)
       • Installation: npm i -g vercel
       • Deployment: Run vercel deploy --prod inside the public/ directory.
       • UX: Opens a browser for authentication if needed, then asks a few interactive setup questions in the terminal before uploading the folder directly to Vercel's edge network.

   • Execute the chosen deployment path and provide the user with the final public URL.

7. Handoff & Next Steps:

   • Once the user has seen the live local dashboard, do not just stop. Outline possible next directions to keep the momentum going:
     • Enrich the Data: Pull in passive data from the Fulcra Context app (e.g., location, heart rate) or ingest data from other external sources to correlate with their custom annotations.
     • Advanced Visualizations: Build more complex D3.js charts or specific data rollups.
     • Python Data Analysis: Set up scripts on the Python backend ( server.py) to analyze their data before sending it to the frontend.