From geopol-sim
One-time setup of a persistent archive for all simulation runs across workspaces and templates. Use when the user wants to "set up a runs archive", "configure where runs are stored", or asks where their forecasts are kept. Creates the runstore directory, persists the path via the plugin-data-storage convention so it survives plugin updates, and registers existing workspaces.
npx claudepluginhub danielrosehill/claude-code-plugins --plugin geopol-simThis skill is limited to using the following tools:
Without this, runs live scattered inside each workspace's `reports/` dir. With it, every run across every template is archived in one place — making `grade-run` aggregate stats meaningful, and making bundling / browsing / cross-run comparison possible.
Provides UI/UX resources: 50+ styles, color palettes, font pairings, guidelines, charts for web/mobile across React, Next.js, Vue, Svelte, Tailwind, React Native, Flutter. Aids planning, building, reviewing interfaces.
Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.
Analyzes multiple pages for keyword overlap, SEO cannibalization risks, and content duplication. Suggests differentiation, consolidation, and resolution strategies when reviewing similar content.
Share bugs, ideas, or general feedback.
Without this, runs live scattered inside each workspace's reports/ dir. With it, every run across every template is archived in one place — making grade-run aggregate stats meaningful, and making bundling / browsing / cross-run comparison possible.
~/geopol-runs/. Suggest somewhere under ~/Documents/ or ~/repos/ (this is user-owned data, not plugin-owned — it shouldn't live under ~/.claude/).symlink (default, zero-copy) or copy (snapshot at registration time). Symlink is right for almost everyone; copy is for users who want the archive to be fully portable.PLUGIN_DATA="${CLAUDE_USER_DATA:-${XDG_DATA_HOME:-$HOME/.local/share}/claude-plugins}/geopol-sim"
mkdir -p "$PLUGIN_DATA"
mkdir -p <runstore_root>/{by-date,by-template,by-workspace}. These are organisational views — actual run dirs live under by-date/YYYY/MM/DD/<workspace>-<run-id>/ and are reachable via symlinks from the other two views.<PLUGIN_DATA>/config.json:
{
"runstore_root": "<absolute path>",
"mirror_mode": "symlink",
"registered_workspaces": []
}
~/repos/**/.template-id (depth-limited) for any pre-existing scaffolded workspaces. Ask the user which (if any) to register.<workspace>/reports/<run-id>/, link it into the runstore:
ln -s <workspace>/reports/<run-id> <runstore_root>/by-date/<YYYY>/<MM>/<DD>/<workspace-slug>-<run-id>
ln -s <workspace>/reports/<run-id> <runstore_root>/by-template/<template-id>/<workspace-slug>-<run-id>
ln -s <workspace>/reports/<run-id> <runstore_root>/by-workspace/<workspace-slug>/<run-id>
registered_workspaces in the config.After setup, scaffold-simulation will register new workspaces automatically, and run-simulation should link new run dirs into the store on completion (extension to that skill — when the runstore exists, it links; when it doesn't, it just leaves runs in <workspace>/reports/).
$CLAUDE_USER_DATA. The config under $CLAUDE_USER_DATA only stores the pointer to the runstore.update-templates could grow a lint pass for this; for v1 just warn the user.