feat: conversation starters

[Patrick-Erichsen]

• Adds prompt Conversation Starts with Bookmarks feature
• Support @contextProvider references in v2 prompt files
• Add prompt contents to slash command description
• Removes tutorial card and prompt files context provider

[netlify]

✅ Deploy Preview for continuedev canceled.

Name	Link
🔨 Latest commit	4c030c1
🔍 Latest deploy log	https://app.netlify.com/sites/continuedev/deploys/67de2b50d75a2f00087ff3d8

[RomneyDa]

nice tests + analytics!

[RomneyDa]

stylistically prefer old way, not important

[Patrick-Erichsen]

Submitted this to the @tomasz-stefaniak oracle (e.g. Clean Code assistant)

Prompt

    slashCommands: final.slashCommands?.map(
      ({ run, ...slashCommandDescription }) => slashCommandDescription,
    ),

slashCommands: final.slashCommands?.map((s) => ({
name: s.name,
description: s.description,
params: s.params, // TODO: is this why params aren't referenced properly by slash commands?
}))

which version is cleaner?

---

Response
The first version using destructuring is cleaner and more maintainable for several reasons:

slashCommands: final.slashCommands?.map(
  ({ run, ...slashCommandDescription }) => slashCommandDescription,
),

Advantages of the first version:

1. It uses object destructuring with rest parameters (...) to explicitly show we're removing the run property while keeping everything else
2. It's more maintainable - if new properties are added to slash commands in the future, they'll automatically be included without modifying this code
3. It follows the Open/Closed Principle better - the code is open for extension (new properties) but closed for modification
4. It's more concise and has less repetition

The second version:

slashCommands: final.slashCommands?.map((s) => ({
  name: s.name,
  description: s.description,
  params: s.params,
}))

Has these drawbacks:

1. It explicitly lists every property that needs to be copied
2. It's more brittle - if new properties are added, this code needs to be updated
3. More verbose and repetitive
4. Higher chance of human error when maintaining the property list

The first version is the better choice as it's more maintainable, flexible, and follows SOLID principles better. It also makes it very clear that we're intentionally excluding the run property while preserving everything else.

---

I made the update mostly stylistically but I think I agree with the points made by the model.

[RomneyDa]

Sounds good!

[RomneyDa]

😮😮😮😮

[Patrick-Erichsen]

Yeah this is a good callout - my thought was that the card was mostly redundant at this point when our tooltip UI has improved for cmd+I/cmd+L and more visible configurations through Nate's toolbar updates.

Lmk what your thoughts are though, I don't feel particularly strongly.

[RomneyDa]

was just excited

[RomneyDa]

🤯🤯🤯🤯🤯

[Patrick-Erichsen]

I think this is valid since all prompt files are now rendered as slash commands.

[RomneyDa]

this was just excitement hahaha

[RomneyDa]

consider renaming/moving file/function to reflect v2 support

[RomneyDa]

"auth" slice or similar might be nice since orgs ~= profiles but nitpick

[Patrick-Erichsen]

Good callout - I created a new organizations slice to make this clearer 👍 the reason I don't think auth would have been clear is that we have all the preference logic (e.g. bookmarks) in the profile slice. Using an org slice is also more similar to what we have on the Hub.

[RomneyDa]

I meant auth slice with both orgs and profiles