From memex
Interactively build a custom Memex profile tailored to a project's actual folder shape. Surveys the project with Glob/Grep, classifies the project type, asks the user targeted questions about taxonomy and gating, and writes a complete memex.config.json + .memex/ tree + CLAUDE.md + AGENTS.md. Invoked by /memex:init-profile, or when the user says "help me build a profile", "make a memex profile for this project", or "none of the profiles fit".
How this skill is triggered — by the user, by Claude, or both
Slash command
/memex:profile-builderThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Interactive. The goal is to produce a complete, hook-valid scaffold in one session — not a patch-kit the user has to finish by hand. Work the steps in order.
Interactive. The goal is to produce a complete, hook-valid scaffold in one session — not a patch-kit the user has to finish by hand. Work the steps in order.
Refuse to run if the current project already has a Memex wiki:
[ -d ".memex" ] && echo "has .memex/"
[ -f "memex.config.json" ] && echo "has memex.config.json"
If either exists, list what's there and stop. Suggest /memex:lint to audit the existing wiki, or hand-editing per docs/profile-authoring.md. Do not overwrite.
Use Glob + Read to build a mental model of what this project is. Collect:
Top-level folders (depth 1):
# via Glob with pattern "*" in project root
Type markers — language / framework:
| Marker | Signal |
|---|---|
package.json | Node / TypeScript / JS project |
pyproject.toml, requirements.txt, setup.py | Python |
Cargo.toml | Rust |
go.mod | Go |
Gemfile, *.gemspec | Ruby |
pom.xml, build.gradle | JVM |
composer.json | PHP |
Type markers — project shape:
| Marker | Signal |
|---|---|
src/, app/, pages/, components/ | Codebase |
supabase/, prisma/, migrations/, sql/ | SaaS with database |
functions/, workers/, edge/ | Serverless / edge |
terraform/, infra/, .github/workflows/ | Infra / ops surface |
research/, papers/, notes/, .obsidian/ | Research |
hypotheses*, roadmap*, architecture/, evaluation/ | Planning-phase research |
chapters/, draft/, manuscript/ | Writing / book |
journal/, entries/, reflections/ | Personal / journaling |
docs/, mkdocs.yml, docusaurus.config.js | Documentation site |
Existing files at root (depth 1): note any top-level markdown files that hint at existing docs conventions (ARCHITECTURE.md, ROADMAP.md, METHODOLOGY.md, CONTRIBUTING.md …).
Print a terse summary to the user: "This looks like a <classification> project. Top-level folders: <a, b, c>. Marker files: <x, y>."
Based on the survey (or the [base-profile] argument if the user supplied one), pick the closest built-in profile as a base:
engineering-opsresearch-projectresearch-wikibook-companionpersonal-journalgenericRead the chosen profile's memex.config.json and .memex/ tree from ${CLAUDE_PLUGIN_ROOT}/templates/profiles/<base>/. These give you the shape you'll customise.
Announce the pick and rationale. Offer the user the choice to switch to a different base before continuing.
Use AskUserQuestion when available. Ask in this order, one question per turn unless grouping saves time:
One sentence: what is this project for? (Offer 3–4 options derived from the survey, plus free-text.)
One of: planning, research, active development, maintenance, multiple. This affects which surfaces should be required vs optional. A planning-phase project needs research/, architecture/, experiments/; a maintenance-phase project needs runbooks/, processes/, .incidents/.
Present the surveyed top-level folders as a multi-select. For each one: should this become a top-level wiki surface (with its own <slug>/README.md pattern)? Some folders (e.g. node_modules/, .git/, dist/) are obviously not wiki surfaces; filter those out before asking.
For each chosen folder, ask what type: values belong there (open-ended — default to the folder name singular-ised).
Free-text. Are there content types this project needs that the base profile doesn't have? Common ones:
runbooks/, processes/, environments/ (ops)planning/prds/, planning/rfcs/, planning/decisions/ (product / design)research/hypotheses/, research/experiments/, research/methodology/ (research)benchmarks/, evaluation/ (research / ML)contracts/, policies/ (legal / compliance)Default: every top-level slug folder with a 1:many shape (entities/*, platform/features/* …) gets README-gated. Confirm or override.
Optional. Ask: "Are there code paths that should require a linked wiki page? For example, every edge function under supabase/functions/<name>/ requires platform/systems/<name>/README.md." If yes, collect one or more (codePattern, requiresDoc, severity) triples. If unsure, leave codeToDocMapping: [] — it can be added later via docs/cookbook.md.
Assemble from the interview answers:
allowedTopLevel — always includes README.md AGENTS.md index.md log.md .open-questions .rules .state plus every custom top-level from the interviewreadmeRequired — the slug patterns from Q5frontmatter.enum.type — derived from Q3 and Q4; always include open-question and ruleindex.sections — one per content type, always trailing with Open Questions and Recent ActivitydatedFolders.paths — any surface like .audits, .research, .incidents the user selectedcodeToDocMapping — from Q6 (or empty)Cross-check before printing: every pattern in readmeRequired must have its top-level slot in allowedTopLevel. This is the pitfall flagged in docs/profile-authoring.md — catch it here, not at hook time.
Print the full proposed config + the folder tree to the user. Ask for confirmation or edits. Loop until confirmed.
Once confirmed, write in this order:
memex.config.json — from the draft.memex/README.md — folder map table, one row per top-level slot.memex/AGENTS.md — binding contract; fill in the "Required artifacts" table from the interview; use templates/shared/agents.md.tmpl as the skeleton.memex/index.md — one section per index.sections entry with the standard *No X yet. Create <path> to add one.* placeholder.memex/log.md — seed with ## [YYYY-MM-DD] init | <profile-slug> profile scaffolded via /memex:init-profile.memex/.open-questions/README.md — copy from the base profile.memex/.rules/README.md — index of rule docs; carry forward any rules from the base profile that still apply.memex/.state/ — create empty (hook-managed).keep files for every empty folder in the taxonomyCLAUDE.md — use templates/shared/claude.md.tmpl with {{ProjectName}} = the current folder name and {{Profile}} = the custom slug. If ./CLAUDE.md already exists, print the template and ask the user to splice it manually rather than overwriting.Substitute dates: created: / updated: use today's ISO date. owner: defaults to unassigned — the user will edit it.
Optional — skip if the user is not inside the plugin repo. Ask: "Save this profile as a reusable template in the Memex plugin so /memex:init <slug> works from other projects?" If yes, print the full path where it should live (templates/profiles/<slug>/) and the one-line PR entries needed in README.md, docs/README.md, commands/memex-init.md. Do NOT write into the plugin repo automatically — the user should submit the PR themselves.
Print a compact summary:
Created:
memex.config.json
.memex/README.md .memex/AGENTS.md .memex/index.md .memex/log.md
.memex/<custom-folders>/.keep
CLAUDE.md
Next 3 actions:
1. Review .memex/AGENTS.md and set owner: fields
2. Review memex.config.json#/codeToDocMapping — empty by default; add project-specific mappings
3. Run /memex:log to verify hooks are active
Optional: pip install -e ".[docsite]" && memex-docsite serve to browse the new wiki
Docs: docs/concepts.md, docs/cookbook.md, docs/docsite.md
Write one line to .memex/log.md documenting the taxonomy choices, so the rationale survives into the project's history. Format:
## [YYYY-MM-DD] init | custom profile scaffolded — top-levels: <a, b, c>; based on <base-profile>
allowedTopLevel / readmeRequired mismatch. Every pattern in readmeRequired must have its top-level slot in allowedTopLevel. Cross-check before writing.frontmatter.enum.type too narrow. If the user later adds a content type, every page of that type will fail frontmatter-check. Enum it broader than the interview strictly required — when in doubt, add it..keep — cheaper than retrofitting./memex:init-profile is idempotent. It is not. The safety check at step 1 is load-bearing.npx claudepluginhub johnoconnor0/claude-memex --plugin memexProvides 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.