Main review #7
Main review #7
Conversation
Includes: - wasp-claude-tools plugin with documentation caching hooks and setup skills - 3 skills: setup-wizard, deploying-app, adding-wasp-knowledge-claude - Hooks for automatic doc caching and WebFetch interception Documentation is cached dynamically at runtime via SessionStart hook.
Introduces wasp-version-cache.js to cache installed Wasp CLI version and available documentation versions, improving performance and reliability of version matching. Updates wasp-llms-version-redirect.js to use the cache for determining the correct documentation URL, and enhances user messaging for version mismatches. Also updates help.md to clarify versioned documentation URLs and removes the unused plugin.json.
Improved Wasp plugin descriptions and documentation for better clarity and LLM optimization. Updated installation and initialization instructions in both root and plugin READMEs. Enhanced the /wasp:init command to provide more user guidance and changed the knowledge import path to .claude/wasp/knowledge. Added .mcp.json for chrome-devtools integration.
Replaces the help command logic with a new help skill, centralizing help content in plugins/wasp/skills/help/SKILL.md. Updates the init command to simplify initialization steps and directory structure. Refactors check-wasp-init.js to detect initialization via CLAUDE.md import and adds opt-out support. Updates general-wasp-knowledge.md with improved dev server instructions and clarifies configure-wasp skill usage.
Added documentation for the 'start-dev-server' skill in the Wasp plugin README. Improved guidance and descriptions for starter templates in general-wasp-knowledge.md to help users select appropriate templates and understand their features.
Improved and clarified documentation for the Wasp plugin, including more accurate descriptions of features, skills, and background hooks. Enhanced guidance for starting the dev server, emphasizing the choice between background tasks and external terminals, and updated best practices for accessing Wasp documentation.
Clarified the development workflow in general-wasp-knowledge.md, emphasizing the importance of checking and starting the dev server before development tasks. Expanded the configure-wasp skill description to include app branding, meta tags, SEO, and more detailed setup options.
Introduced the /wasp:expert-advice command for app improvement suggestions by a Wasp expert. Updated README and help skill documentation to reference the new command and improved example prompts formatting.
Added missing skills to the permissions list in README.md. Updated the init command to use AskUserQuestion for user confirmation and clarified instructions to not amend the general-wasp-knowledge.md file, but to amend CLAUDE.md for custom rules. Minor cleanup in expert-advice.md.
Revised guidance in general-wasp-knowledge.md and start-dev-server/SKILL.md to prompt users to choose a tool for checking browser console errors, offering both mcp__plugin_wasp_chrome-devtools and Claude Code's built-in Chrome browser function. This clarifies the process and tool options for verifying client app issues.
Martinsos
left a comment
Martinsos
left a comment
There was a problem hiding this comment.
So far I reviewed approx half or a bit less of it, I am submitting comments I have so far, and will continue reviewing after this.
I stopped at the block-wasp-html-docs.js currently (that one I need to review next).
| "description": "Official Wasp framework plugins for Claude Code", | ||
| "version": "1.0.0" | ||
| }, | ||
| "plugins": [ |
There was a problem hiding this comment.
Aha so we directly deifne plugins here.
Beacuse I saw also that you can define plugin manifesto in /plugins/wasp/.claude-plugin/plugin.json. That is how they do it in their official plugins, I also saw that in the plugins docs. Maybe that is a better method, so it is not all grouped here in this file?
Hm actually it is weird, I see now in their repo that they do it in both places, basically duplicating the information. How does that make any sense, why would they do that?
| "url": "https://wasp.sh" | ||
| }, | ||
| "metadata": { | ||
| "description": "Official Wasp framework plugins for Claude Code", |
There was a problem hiding this comment.
Would it be more correct to say "Official Claude Code plugins for Wasp framework"?
Because they are Claude Code plugins, not Wasp framework plugins, right?
| # OS files | ||
| .DS_Store | ||
| Thumbs.db | ||
|
|
There was a problem hiding this comment.
I would kick these out, these should really go into your global user gitignore on your machine, not in the repo here, since they are OS specific.
| # Local development | ||
| .env | ||
| .env.local |
There was a problem hiding this comment.
What are we using these for? Are we using any .env or .env.local files in this repo? If not maybe remove then for now.
| { | ||
| "name": "wasp", | ||
| "source": "./plugins/wasp", | ||
| "description": "Give Claude optimized access to Wasp's documentation, features, workflows, and best practices to help you build full-stack React, NodeJS, and Prisma apps even faster.\n\n━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━\n⚡️ QUICK START\n━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━\n\n🧠 /wasp:init - initial setup (run this first!)\n📖 /wasp:help - view all plugin features", |
There was a problem hiding this comment.
Enhances Claude to give you the optimal experience while developing full-stack web apps with Wasp (React, NodeJS, Prisma, ...).
It does so by providing Claude with curated access to docs, workflows and best practices.
Ok I tried sometihng different here because I thought "Give Claude optimized access" is a bit weird, but I am not sure if this is better, do with it as you like, which can also be nothing.
| - ⚠️ Call actions directly using `async/await`. DO NOT use Wasp's `useAction` hook unless optimistic updates are needed. | ||
|
|
||
| **In main.wasp:** | ||
| - ✅ `fn: import { getTasks } from "@src/tasks/operations.ts"` |
There was a problem hiding this comment.
I think we also recommend maybe not using .ts extensions? Or do we? I can't remember, but I would confirm it by checking the example apps and following what they do.
|
|
||
| When errors occur: | ||
| 1. Check server terminal for backend errors (localhost:3001) | ||
| 2. Check client terminal for frontend build errors (localhost:3000) |
There was a problem hiding this comment.
Hm client terminal, what is that :D. Aha ok, for frontend build errors. But localhost:3000 is the app, not client terminal. So this is wrong.
I would say: check the wasp start output for logs and errors from the api server / backend, and for the logs and errors from the client dev server (client building). Also check the browser for client runtime logs and errors, those are not printed by the wasp start.
|
|
||
| ### Import Conventions | ||
|
|
||
| **In TypeScript files:** |
There was a problem hiding this comment.
How did we pick these, why are they so important to be mentioned here?
| - the `mcp__plugin_wasp_chrome-devtools` | ||
| - Claude Code's built-in Chrome browser function | ||
|
|
||
| ### Common Mistakes |
There was a problem hiding this comment.
Main thoughts for this file are: what can be moved to docs and referenced from there? But on the other hand, yeah, I get it, this needs to be here and not in docs, so it is more on top of mind of LLM. Ok yeah. Still, I would maybe like this to be also captured somewhere in the docs, kind of like "Wasp overview" or "Wasp AI overview" or something, so we remember to maintain it, and then just copied over here when we are publising the plugin, otehrwise I think we will forget to maintain this properly.
We dont' have to figur ethat out right now, but let's create a GH issue in this repo that is focused exactly on that -> how do we ensure maintainability of this plugin. I tihnk likely solution will be:
- linking to real docs as much as we can
- what we can't link, we should copy from the docs in the "build step", and if needed we can even add custom parts to docs aimed for AI
- if none of those because it is specific for claude / claude code plugin, then it goes here.
This is a makeshift PR made so I can more easily review the main branch.
I made new empty-branch with one empty commit + main-review branch that I branched off main and then rebased it on top of empty-branch.