v2

[cremich]

Motivation

With Promptz v2, I want to initiate the next evolution of managing and sharing resources for Amazon Q Developer. While running promptz.dev for almost a year now, I learned how the product is used, perceived, and where I spend effort in maintaining it. That led to a few assumptions:

1. Community is Key: Promptz can only provide value if users are encouraged and motivated to contribute content continuously.
2. Git-Based Content Management: Users want to manage their content using git-based workflows, including collaboration and versioning.
3. Integrations: Users prefer deep integrations into their local environments with a high degree of automation. A website is great for education and organic traffic, but it does not provide a good developer experience.

Vision

The vision of v2 is centered around a customer quote I received in the early days.

"promptz.dev is like Github but for Amazon Q Developer".

Execution

Following that vision, and taking the mentioned assumptions as guidelines, will lead to major changes:

1. Content Management: Content Management will move from the website to GitHub. With v2, users will be able to commit, review, and improve prompts, project rules, and custom agent configurations using git-based workflows and pull-requests. That will increase the potential userbase of promptz to all users that have a GitHub account. Users will work in their well-known ecoystem that is already deeply integrated into their local environments.
2. Website: The main purpose of the website will be education and content rendering to drive organic traffic. The backend of the website can be reduced to just the hosting relevant parts. Authentication will be handled via Github as content management is happening there. The API will be only responsible to provide mutations to track anonymous installations of content.
3. CLI: A new developed Promptz CLI will close the gap of automation and content management. With the CLI, users will be able to sync content from promptz into their local environment and run sensitive local operations such as content evaluations.

User Journeys

This is a draft of typical user journeys for v2

journey
    title Discovering and Using Content
    section Discovery
      Visit promptz.dev: 5: Developer
      Search for specific use case: 5: Developer
      Browse by tags/categories: 5: Developer
      Find relevant prompt: 5: Developer
    section Usage
      Read content details: 5: Developer
      Copy CLI command to install content: 5: Developer
      Run install command: 5: Developer
      Download content in local environment CLI: 5: Developer
      Use content in Amazon Q Developer: 5: User

Loading

journey
    title Creating and Sharing Content
    section Content Creation
      Fork promptz.dev repository: 5: Developer
      Add new content: 5: Developer
      Create pull request: 5: Developer
      Auto-Review and Approval of PR: 5: GitHub

Loading

journey
    title Contributing changes to existing Content
    section Content Creation
      Fork promptz.dev repository: 5: Developer
      Update existing content: 5: Developer
      Create pull request: 5: Developer
      Automatically assign author for review 5: GitHub
      Review PR: 5: Author
      Merge changes: 5: Author

Loading

[awsdataarchitect]

prompt poisoning, prompt injection is the biggest security threat with 3P mcp servers. if promptz.dev can solve this problem with a security layer it would be a game changer @cremich

[cremich]

That was one aspect I want to bring into the CLI or the PR based reviews. However not an easy task to solve 🙂

The security layer can either have some automated evaluations when submitting content. Or a it can be based on human reviews and evaluations. Github has a huge community and If I get to manage to drive a group of supporters and contributors, we have more eyes on contributed content compared to how it works today.

[cremich]

Implementation Options

Based on a discussion I had with Q Developer, here is my preferred option to setup a git-based content management :

Single Repository Approach

The promptz.dev repository will contain both the website application and a new content folder that contains markdown files + frontmatter for user-submitted prompts, custom agents, and project rules. On a long-term the repository will be renamed to just promptz for easier discovery.

Content Format: Markdown with JSON Codeblocks ✅

For custom agents, use markdown with JSON codeblocks instead of separate JSON files:

---
title: "AWS Lambda Development Agent"
category: "serverless"
tags: ["aws", "lambda", "python"]
---

# AWS Lambda Development Agent

This agent helps with AWS Lambda development...

\`\`\`json
{
  "name": "aws-lambda-dev",
  "description": "Specialized agent for AWS Lambda development",
  "instructions": "You are an expert in AWS Lambda...",
  "tools": ["aws-cli", "sam-cli"],
  "model": "claude-3-5-sonnet"
}
\`\`\`

For prompts and project rules, we will use plain markdown with defined metadata in the front matter header. Required metadata will be derived from the current common data attributes schema defined in amplify/data/types/definitions.ts

Content Repository Structure

Following our architecture discussion, here is a draft for the content repository:

Repository Structure

• Content will be stored in a content folder. This folder will be used for rendering
• Templates folder will contain base tempaltes for new prompts, project rules and agent configurations including frontmatter with default values.
• The content in the .github folder will be enhance for content publishing and moderation related workflows

promptz.dev/
├── content/
│   ├── prompts/
│   │   ├── aws/
│   │   ├── nextjs/
│   │   └── general/
│   ├── project-rules/
│   └── agents/
├── templates/
│   ├── prompt-template.md
│   ├── project-rule-template.md
│   └── agent-template.md
├── .github/
│   ├── workflows/
│   │   ├── validate-content.yml
│   │   ├── auto-assign-reviewers.yml
│   │   └── trigger-website-build.yml
│   ├── ISSUE_TEMPLATE/
│   │   ├── new-prompt.yml              # Issue template for prompt requests
│   │   ├── new-agent.yml               # Issue template for agent requests
│   │   └── bug-report.yml              # Bug report template
│   ├── PULL_REQUEST_TEMPLATE.md
│   └── CODEOWNERS