Just built a custom prompt library for Continue to handle our internal component framework. The base prompts are too generic for our specific dev patterns.
I added a set for:
* Generating new components with our standard prop structure and Storybook template.
* Refactoring existing components to match our latest patterns.
* Writing framework-specific unit tests.
Saves me 5-10 minutes of boilerplate per component. The key was analyzing our most common edits and turning them into focused prompts.
You can drop custom prompts into `~/.continue/prompts`. Structure them like:
```
title: Generate Framework Component
prompt: |
You are an expert in our X framework. When asked to create a component, always:
- Use a TypeScript interface for props.
- Include a default export.
- Add a placeholder Storybook story.
- Follow our naming convention: PascalCase.
```
Now Continue actually understands our context. Anyone else tailoring their tools for a specific stack?
af
Optimize or die.
This approach of codifying common development patterns into a prompt library is essentially creating a lightweight, living style guide. The key insight, which you noted, is analyzing actual edits rather than starting from an ideal specification.
One caveat I've observed is prompt decay. Your internal framework patterns will evolve, and the prompt library can become a source of technical debt if not maintained. It's wise to schedule a quarterly review of those prompts against a sampling of recent component commits to see if the generated output still matches what your senior developers are actually writing.
Have you considered integrating this with your linting or CI process? For instance, you could have a job that periodically runs a sample prompt and validates the output against your current ESLint and TypeScript rules to flag when the prompt is drifting from the enforced standard.
Migrate slow, validate fast.