| name | add-project |
| description | Use when the user wants to add a new project to their Bentofolio portfolio, types /add-project, asks to "ajouter un projet", "créer un projet", or "nouveau projet". Also use when the user describes a project they built and mentions showcasing it or adding it to their portfolio. Do NOT use for editing existing projects — that's a different workflow. |
Add Project to Bentofolio
Conversational workflow to gather project metadata, validate it, and write the files via a standalone script.
Core principle
Never write files directly. The workflow is: ask questions → confirm with user → run the script. The script handles validation, file paths, and format. You doing it manually leads to invalid categories, missing fields, and fabricated content.
When NOT to use
- The user says "modifier", "update", "edit", "changer" an existing project
- The project already exists in
content/projects/<id>/ — the user means to update it
Workflow
Follow this step-by-step. After each step, confirm before moving on.
Step 1: Name → derive ID
Ask: "Quel est le nom du projet ?"
Derive the ID: lowercase, no accents, spaces → hyphens, strip special chars. Show the derived ID to the user immediately:
→ ID généré : "mon-projet"
If the ID already exists in content/projects/, warn the user: "Ce projet existe déjà. Tu veux le mettre à jour ou en créer un nouveau ?"
Step 2: Categories
Ask: "Dans quelle(s) catégorie(s) ?"
Valid categories (exactly these): dev, webdesign, 3d, animation, logo, tooling, devops, ai, tools.
Show the list to the user if they're unsure. Accept 1 or more.
Step 3: Role
Ask: "Quel était ton rôle ?" (optional). Examples: "Solo", "Binôme", "Équipe (3)".
Step 4: Dates
Ask: "Quand as-tu commencé ?" → derive startDate as YYYY-MM-DD. If user only gives a year, use YYYY-01-01.
Ask: "Quand as-tu fini ?" → derive endDate as YYYY-MM-DD or null if ongoing.
Show: startDate: "2025-03-15" → endDate: null ("En cours").
Period and duration are computed automatically — do NOT ask for them.
Step 5: Tech stack
Ask: "Quelles technos ?"
For each tech the user names, look it up in config.json → skillPalette. A match gives you the tech key, label, and color. Use those. If not in the palette, use { label: "Name", tech: "default", color: "#888888" }.
Show the resolved techs with their colors.
Step 6: Description and highlights
Ask for a one-sentence description (required, under 150 chars).
Ask for up to 3 highlights (optional). Show a preview. Keep them short, factual, no emojis (the list already uses bullet points).
NEVER auto-generate highlights. NEVER silently empty existing highlights. If the user doesn't provide any, ask again: "Pas de highlights du tout ?" before leaving the array empty.
Step 7: URLs
Ask: "Une démo en ligne ?" (demoUrl, optional).
Ask: "Un repo GitHub ?" (repoUrl, optional).
Step 8: Case study
Ask: "Tu veux une étude de cas ? (oui/non)"
If yes, ask the user for EACH section they want to include (Contexte, Process, Difficultés, Fiertés, Si c'était à refaire). Wait for them to provide the content — you are a scribe formatting their words, not the author.
NEVER write case study content yourself. NEVER fabricate. NEVER empty existing content without explicit approval. If the user says no, set caseStudy to "".
Format as markdown with ## headings. Do NOT include a ## Stack section — the stack is rendered via tech pills separately.
Step 9: Final review
Show a summary of ALL gathered data in this format:
Projet : AppStore Scraper (appstore-scraper)
Catégories : dev, tools
Rôle : Solo
Dates : 2025-01-01 → 2025-09-04
Technos : Python (python, #3776ab)
Description : Scraper Python de l'App Store Apple...
Highlights :
• Scrape 36 storefronts Apple
• ...
Demo : https://...
Repo : https://...
Case study : oui (1942 caractères)
Ask: "Tout est bon ? Je lance le script ?"
Step 10: Run the script
Build the JSON payload with ALL fields and run:
bun run .opencode/skills/add-project/scripts/add-project.ts '<JSON>'
The caseStudy field goes in the JSON as a string, not a separate file. The script handles writing both project.json and case-study.md, and updating order.json.
Step 11: Verify
Run bun run test to confirm nothing broke. Tell the user: "Projet ajouté. Lance bun dev pour voir le résultat."
JSON payload format
{
"name": "My Project",
"categories": ["dev"],
"role": "Solo",
"featured": false,
"startDate": "2025-01-01",
"endDate": null,
"description": "Short description.",
"highlights": ["Point 1", "Point 2", "Point 3"],
"techs": [
{ "label": "React", "tech": "react", "color": "#61dafb" }
Important:
startDate is YYYY-MM-DD, never a bare yearendDate is YYYY-MM-DD or null- Do NOT include
period or duration — they are computed at runtime
color comes from the skill palette in config.json- The script writes
content/projects/<id>/project.json and case-study.md, and appends to order.json
- The script does NOT rebuild
index.json — Vite HMR handles that
Anti-patterns (from baseline failures)
| Don't | Why | Do instead |
|---|
Write project.json directly with writeFileSync | You'll use wrong fields, invalid categories, miss the schema | Use the script |
| Fabricate highlights or case study content | User may not agree, facts may be wrong | Ask the user, leave empty if they skip |
Include ## Stack in case study | Stack is rendered via tech pills, duplication is noise | Skip it |
| Use category names that aren't in the valid list | "tools" is not valid, only "tooling" is | Validate against the list |
| Empties highlights without asking | User may want to keep existing content | Ask the user what highlights they want, show a preview before finalizing |
| Writes case study content without user input | User may not agree with fabricated story | Ask for EACH section, wait for content, format only |
| Overwrite existing project without warning | Existing data may be correct | Check if ID exists first, warn the user |
Build the JSON manually in a writeFileSync | Wrong structure, missing validation | Use the script — it validates everything |
Pipeline Integration
This skill is the terminal step (10) of the portfolio-polish pipeline. When invoked from that pipeline, the project has already been polished, deployed, and screenshotted. The image field should receive the deployed-site screenshot (<project-path>/docs/assets/screenshot.png), copied into public/media/projects/<id>/. The demoUrl is the GitHub Pages URL and repoUrl is the project repo.
