Give Your Project a Brain with Amazon Quick

Connect AI to a codebase and Slack workspace, investigate an unfamiliar product, and defend a release plan.

Introduction

30 Second Summary

You just joined a new software team and tomorrow is the big planning meeting. There are dozens of open issues, customer complaints, and technical debt items scattered across different documents. You need to synthesize all of it into a clear recommendation before the meeting starts.

In this project, you will connect Amazon Quick to a real GitHub repository and a team Slack workspace, investigate an unfamiliar codebase using AI, and build a shareable Release Command Center app that defends your data-backed release plan to the whole team.

What You'll Build

You will open a polished Release Command Center app in your browser, copy a shareable link, and watch any teammate instantly see which issues ship in v1.1, which are deferred to v2.0, and exactly why each decision was made.

By the end of this project, you'll have:

An AI-powered investigation workflow where you connect Quick to GitHub and Slack, then ask it to cross-reference code, issues, customer feedback, and team conversations to find what matters most.
A prediction-then-evidence loop where you commit to your own priorities first, investigate the data, and discover where your instincts were right and where the evidence says otherwise.
A live, shareable Release Command Center app with prioritized issues, risks, tradeoffs, and a defensible recommendation for the entire team.
Secret Mission: Build a reusable Quick Flow that automates the triage process so the team can regenerate this analysis for v1.2, v1.3, and beyond.

Are there any prerequisites?

None. This project includes full setup for all required tools. You do not need an AWS account or a credit card. Amazon Quick offers a free plan and every new signup includes a 30-day Plus trial with full features.

Before We Start

You are about to join a software team you know nothing about. Before diving in, let's lock in what you're going to deliver by the end of this session and why it matters.

Set Up Your Tools

You need Amazon Quick connected to the CreatorOS repository before you can use AI to investigate the project.

Without these connections, Quick is just a chatbot with no context about your team. In this step, you will create your accounts, clone the repository, run the app locally, and wire up both the GitHub and Slack connectors so Quick can read your code, issues, and team conversations on demand.

In this step, get ready to:

Sign up for Amazon Quick and clone the CreatorOS repository.
Run CreatorOS locally to see the product you are joining.
Connect Amazon Quick to GitHub so it can read your code and issues.
Connect Amazon Quick to Slack so it can search your team's conversations.

Sign up for Amazon Quick and clone the repository

You need three things before you can connect AI to your project: an Amazon Quick account, a GitHub account, and Node.js installed on your machine.

Go to https://aws.amazon.com/quick/ and click to sign up.
Sign up using your email, Google, Apple, Amazon, or GitHub credentials. No AWS account or credit card is required.
Complete the sign-up flow. You will land on a goal selection screen where Quick asks what you want to accomplish.

What about the Plus trial?

Every new signup automatically includes a free 30-day trial of the Plus plan with full features. You do not need to enter payment details. The project completes in a single session, well within the trial period.

Quick's onboarding asks you to pick up to three goals so it can tailor recommendations to your workflow. This is how Quick personalises what it shows you on the Home screen.

Select Build and ship my product as one of your goals. You can pick additional goals if you like.
Click Let's go to continue.

Quick shows a suggestions screen titled "Based on your goals, here are some ways I can help." with pre-built prompt cards like "Build a QBR presentation framework" and "Hand off a design spec to engineering."

Scroll down past the suggestion cards and click Skip at the bottom of the page.

You land on the Amazon Quick Home screen with the chat input and a "Want to try something else?" prompt. This is where you will spend most of your time.

What are these suggestion cards?

Quick uses your goal selection to surface pre-built prompts that match your role. These are shortcuts you can try anytime from the Home screen. You are skipping them now because you will ask Quick your own questions once the GitHub connector is set up.

Next, confirm you have a GitHub account.

✔️ I already have a GitHub account

You are all set. Move on to the Node.js check below.

ⓧ I don't have one yet

Go to https://github.com and click Sign up.
Follow the prompts to create a free account with your email address.
Verify your email when GitHub sends you a confirmation link.

Now confirm Node.js is installed at version 18 or higher.

Open your terminal. Press Cmd+Space (macOS) or the Windows key (Windows) to open your search bar.
Type Terminal (macOS) or PowerShell (Windows) and press Enter to open it.
Open Check your version by running this command:

node --version

✔️ I see version 18 or higher

If you see v18.x.x or any higher number (v20, v22, v24, etc.), you are good to go. Move on to cloning the repository below.

ⓧ I see an older version

Your installed version is too old. You need v18 or later to run CreatorOS.

Go to https://nodejs.org and download the LTS installer for your operating system.
Run the installer and accept the default settings.
Close and reopen your terminal, then run node --version again to confirm the new version.

macOS default version conflicts

If your system still shows an old version after installing, the old Node binary may shadow the new one. Use the full path to the new install, or use a version manager like fnm or nvm to switch.

ⓧ Command not found

Node.js is not installed on your machine yet.

Go to https://nodejs.org and download the LTS installer for your operating system.
Run the installer and accept the default settings. On Windows, make sure the option to add Node to your PATH is checked.
Close and reopen your terminal after installation completes.
Run node --version to confirm you see v18 or higher.

Now clone the CreatorOS repository to your machine.

Open your terminal. Press Cmd+Space (macOS) or the Windows key (Windows) to open your search bar.
Type Terminal (macOS) or PowerShell (Windows) and press Enter to open it.
Move to your Desktop by running this command:

cd ~/Desktop

Clone the repository and move into it by running these commands:

git clone https://github.com/Nik-1019/creator-os.git
cd creator-os

Confirm you are inside the project by running:

ls

You should see folders like backend, frontend, docs, customer-feedback, and engineering in the output.

Seeing 'repository not found' or 'git not found'?

If you see a 'not found' error, double-check the URL is exactly https://github.com/Nik-1019/creator-os.git. If git itself is not found, install it from https://git-scm.com and reopen your terminal.

help me fix a git clone error

Run CreatorOS locally

CreatorOS has a separate backend (Express + SQLite) and frontend (React + Vite). You will start both, but first, open the project in your IDE so you can browse the code alongside the terminal.

Press Cmd+Space (macOS) or the Windows key (Windows) to open your search bar.
Type Kiro or Visual Studio Code and press Enter to open your IDE.

Click Open project or File in the top menu bar.
Click Open Folder.
Select the creator-os folder on your Desktop, then click Open.

You should see the project's file tree in the left sidebar with folders like backend, frontend, docs, and engineering. This is the codebase you will investigate with Amazon Quick.

Press Ctrl+` (the backtick key above Tab) to open the integrated terminal. This shortcut works on both macOS and Windows.
Set up and start the backend by running these commands:

cd backend
npm install
cp .env.example .env
mkdir data
npm run db:seed
npm run dev

What do these commands do?

cd backend moves into the backend folder. npm install downloads the project's dependencies.

cp .env.example .env creates your local environment config from the template. npm run db:seed populates the SQLite database with sample data.

npm run dev starts the backend server. This command takes over your terminal and keeps running. You will see output indicating the server is listening on port 3001.

Leave that terminal tab running. The backend needs to stay active while you work.

Click the split terminal icon at the top-right of the terminal panel to open a second terminal.

Navigate to the frontend folder and start it by running these commands:

cd ~/Desktop/creator-os/frontend
npm install
npm run dev

What does the frontend do?

npm install downloads the React frontend dependencies. npm run dev starts the Vite development server on port 5173. This also takes over the terminal.

Open http://localhost:5173 in your browser.

You should see the CreatorOS application. This is the content creator workspace with features for content planning, campaigns, and analytics.

Seeing a blank page or connection error?

Make sure both terminal windows are still running (the backend on port 3001 and the frontend on port 5173). If either crashed, re-run npm run dev in the appropriate folder.

If port 5173 is already in use, Vite may pick a different port and show it in the terminal output. Use that URL instead.

help me troubleshoot CreatorOS not loading in the browser

Connect Amazon Quick to GitHub

Amazon Quick reads code and issues on demand through its GitHub connector. This uses OAuth to authorize Quick to access your repositories.

In Amazon Quick, click Connectors in the navigation pane.

Choose the Create for your team tab.

Before you fill in this form, you need to create a GitHub OAuth App to get a Client ID. Keep this Amazon Quick tab open and open a new browser tab for GitHub.

Why do I need a GitHub OAuth App?

Amazon Quick needs permission to read your GitHub repositories, issues, and pull requests. A GitHub OAuth App is the secure handshake that grants this access. Instead of giving Quick your GitHub password, the OAuth App creates a trust relationship: GitHub verifies your identity, and you choose exactly which repositories Quick can see.

The Client ID you generate is like a public name tag for this connection. When Quick asks GitHub for data, GitHub checks that Client ID to confirm the request is coming from an app you authorized.

In a new tab, go to https://github.com/settings/developers
Click OAuth Apps in the left sidebar.
Click New OAuth App.

In Application name, type Amazon Quick Connector.
In Homepage URL, type https://aws.amazon.com/quick.
In Application description, type Connects Amazon Quick to GitHub repositories. This field is optional but helps you identify the app later.
In Authorization callback URL, type https://quick.aws.com/sn/oauthcallback.
leave Enable Device Flow unchecked.
Click Register application.

GitHub shows your new app's details page. Copy the Client ID value at the top of the page.

Click Generate a new client secret.
GitHub displays the secret once. Copy it immediately — you will not be able to see it again.

Now switch back to the Amazon Quick tab to fill in the connector form.

In the Name field, replace the default text with CreatorOS GitHub.
Leave Connection type set to Public network.
Leave Auth configuration set to Custom OAuth app.
Leave Public OAuth client unchecked.
Paste the Client ID you copied from GitHub into the Client ID field.
Paste the Client Secret you copied from GitHub into the Client secret field.
Leave all pre-filled URL fields (Base URL, Token URL, Authorization URL, Redirect URL) unchanged.

Click Next to proceed to step 2: Manage Tools & Permissions.
Review the available actions (read files, list issues, list pull requests, etc.) and click Next again.

On step 3: Publish, click Publish to save the connector.
After publishing, click Sign in on the connector details page.
This opens a GitHub OAuth window where you grant Quick access to your repositories.

What can Quick do with GitHub?

The GitHub connector gives Quick tools to read files, list issues, list pull requests, search repositories, and more. It reads your code on demand when you ask about it. It does not automatically index your entire repository.

This means you will need to explicitly ask Quick to read specific files rather than expecting it to already know everything.

Before you test the connection, what do you think Quick will return if you ask it to list the issues in the CreatorOS repo? Will it know about the repository, or will something go wrong?

Click try it.

List the issues in the https://github.com/Nik-1019/creator-os repository.

Quick should return a list of GitHub issues from the CreatorOS repository. You will see issue titles, numbers, and labels. This confirms the connector is working.

Quick says it cannot access the repository?

Go back to Connectors and confirm the GitHub connector status shows as connected. If it says 'Not signed in', click Sign in again.

Also confirm you authorized access to the correct GitHub account that can see the Nik-1019/creator-os repository. Since it is a public repository, any authenticated GitHub account should work.

help me fix my Amazon Quick GitHub connector

Connect Amazon Quick to Slack

The CreatorOS team has been discussing the v1.1 release in Slack for the past two weeks. Engineers, support, and product have all weighed in. You need Quick connected to Slack so it can search those conversations during your investigation.

First, join the CreatorOS team Slack workspace by opening this invite link:

https://join.slack.com/t/creatorosinternal/shared_invite/zt-45itb1xaq-91q7atp~p5Jou_E2i435nQ

Accept the invitation and join the workspace. You should see three channels: #engineering, #support-escalations, and #release-planning.

Now connect Quick to this workspace the same way you connected GitHub.

In Amazon Quick, click Connectors in the navigation pane.
Choose the Create for your team tab.
Find and select Slack from the list of available connectors.
In the Name field, type CreatorOS Slack.
Leave Auth configuration set to Default OAuth app. This uses AWS-managed credentials so you do not need to create your own Slack app.
Click Next to review the available Slack actions (send messages, search messages, get conversation history, etc.).

Click Next again, then click Publish.
After publishing, click Sign in on the connector details page.
Authorize Quick to access the CreatorOS team workspace when the Slack OAuth window appears.

What can Quick do with Slack?

The Slack connector gives Quick tools to search messages, read conversation history, list channels, and send messages. You will use it to search for engineering discussions, support escalations, and planning conversations that reveal context no document can capture.

Verify the Slack connector is working by asking Quick to search for messages.

In Amazon Quick chat, test the connection by entering this prompt:

Search Slack messages in the creatorosinternal workspace mentioning "v1.1" and tell me what channels are discussing it.

Quick should return messages from the team discussing v1.1 planning. You should see references to the #release-planning and #engineering channels.

Quick not returning Slack messages?

Go back to Connectors and confirm the Slack connector shows a signed-in status. If it says 'Not signed in', click Sign in again and make sure you authorize access to the CreatorOS team workspace (not a different workspace).

help me fix my Amazon Quick Slack connector

Your environment is ready. Amazon Quick is connected to both the CreatorOS repository and the team's Slack workspace. It can read code, issues, documentation, and team conversations on demand. Next up, you will meet CreatorOS as both a user and an engineer.

Meet CreatorOS

Your tools are ready and Amazon Quick has a live connection to the CreatorOS repository. Now comes the real question: what is this product, and how does it work?

You cannot make release decisions about a product you do not understand. Normally, onboarding to an unfamiliar codebase takes days of reading documentation and tracing code paths. With Quick connected to the repo, you can build that mental model in minutes.

In this step, get ready to:

Explore CreatorOS as a user to understand what it does.
Ask Quick to read architecture documentation and explain the system design.
Survey the open issue backlog to understand the volume of work ahead.

Explore the product as a user

Before you ask AI anything, you need to experience the product like a real user would. Your goal is to identify what a content creator can do inside CreatorOS.

Switch to your browser tab showing http://localhost:5173.

Click through the sidebar navigation and visit each main section of the app.
For each section, note what a creator would use it for: planning ideas, scheduling posts, managing brand deals, tracking campaigns, or reviewing analytics.

You should see a workspace with sections for content ideas, a publishing calendar, campaigns, brand deals, analytics, and settings. This is the product your team ships to content creators.

What is CreatorOS?

CreatorOS is an AI-powered workspace that helps content creators manage their entire workflow. Creators use it to capture ideas, schedule posts across platforms, track sponsorship deals, run campaigns, and monitor performance analytics.

The product shipped v1.0 in May 2026 and is now planning v1.1. That release planning is your job today.

Ask Quick to explain the architecture

Now that you know what CreatorOS does from a user perspective, you need to understand how it is built. Instead of reading documentation files yourself, you will ask Quick to read them and summarize.

Return to Amazon Quick chat.
Ask Quick to read the architecture documentation by pasting this prompt:

Read the file docs/architecture.md in the https://github.com/Nik-1019/creator-os repository and give me a summary of the system architecture.

Quick responds with a summary of the system design. You should see it describe a React frontend, an Express backend, and a SQLite database.

How does Quick read files from GitHub?

When you ask Quick to read a file, it uses the get_file_contents action from the GitHub connector you set up in Step 1. Quick fetches the file contents on demand and processes them to answer your question.

This is different from a full-text search index. Quick reads specific files when you ask, so you need to tell it which files to look at.

🙋‍♀️ Quick says it cannot find the file?

Make sure you include the full repository path Nik-1019/creator-os in your prompt. Quick needs both the owner and repository name to locate files.

If Quick still cannot access the file, return to Connectors and confirm your GitHub connector shows Signed in status.

help me troubleshoot why Amazon Quick cannot read files from my GitHub repository

Understand the current state of the project

You know what the product does and how it is built. The final piece of context is the backlog: how much work is piling up, and what kinds of problems are people reporting?

In Amazon Quick chat, ask it to list the issues by pasting this prompt:

List all open issues in the https://github.com/Nik-1019/creator-os repository.

Quick returns a list of 20+ open issues. Scan the titles to get a feel for the variety of work: bugs, feature requests, and infrastructure concerns.

Now ask Quick to break down the labels by pasting this prompt:

How many issues are labeled 'bug' vs 'enhancement' vs 'tech-debt'?

You should see the issues distributed across different categories. This is the raw backlog you need to triage for v1.1. Do not try to prioritize yet. Just observe the volume and variety.

Why not prioritize right now?

A list of issues tells you what exists, not what matters most. Prioritization requires cross-referencing this list against customer feedback, support tickets, and technical debt documentation. That investigation comes in the next step.

You now have a mental model of what CreatorOS does, how it is built, and how much work is piling up. Next, you will make a bold call: if you had to pick 5 items to ship in v1.1 right now, based only on what you have seen so far, what would they be?

Investigate the Friction

Make Your Call

You have seen the product running, explored the architecture, and scanned 20+ open issues. That is more context than most engineers get on day one.

Now comes the real test. If the release planning meeting were in 10 minutes and you had to pick 5 things to ship in v1.1, what would they be? In this step, you commit to a position BEFORE asking AI for help. Then you investigate the evidence and find out where you were right and where you were wrong.

In this step, get ready to:

Make your own release recommendation based on what you have seen so far.
Investigate customer feedback, support tickets, and tech debt using Amazon Quick.
Compare your prediction against the evidence and identify where you were wrong.

Commit to your top 5

You have seen the issue titles, the labels, and the product itself. That is enough to form a gut-level opinion. Before you ask Quick for any analysis, commit to your position.

✔️ I'll make my own call

Write down your top 5 priorities for v1.1 based on what you have seen so far. No AI. No hints. Just your judgment about what matters most to ship. Consider the issue titles, their labels, and what you saw when you used the product.

You will compare this against the evidence in a moment.

ⓧ Help me think through this

Look at the issue backlog from Step 2. Ask yourself three questions:

Which issues are labeled high priority?
Which issues appear as both a bug AND a customer complaint?

Which category has the most open issues: bugs, features, or tech-debt?
Based on your answers, write down the 5 issues you think should ship in v1.1.

Test your judgment against the evidence

You have committed to a position. Now let's see if the data supports it. You are going to ask Amazon Quick to read the customer feedback and support tickets, then cross-reference everything to find where multiple data sources converge on the same problem.

Ask Quick to analyze customer pain by entering this prompt:

Read the file customer-feedback/feature-requests.md and support/tickets.csv in the https://github.com/Nik-1019/creator-os repository. What are the top 5 customer pain points based on both sources combined?

Quick returns a ranked list of what customers are asking for and complaining about most. Compare this against YOUR top 5. How many of your picks match?

Now ask Quick to check the engineering side by entering this prompt:

Read engineering/tech-debt.md and docs/roadmap.md in the https://github.com/Nik-1019/creator-os repository. Which items are marked as high priority or critical? Which are blocked or deferred?

Quick returns the engineering perspective: what is technically urgent and what is blocked. Notice anything that contradicts your initial picks?

What is convergence?

Convergence means the same problem appears across multiple independent sources. An issue that shows up in customer feedback AND support tickets AND tech debt is a much stronger signal than one that appears in only a single source.

The more sources a problem appears in, the more likely it genuinely matters. Single-source issues might be noise. Multi-source issues are almost always worth fixing.

Ask Quick to find the convergence patterns by entering this prompt:

Based on the GitHub issues, customer-feedback/feature-requests.md, support/tickets.csv, engineering/tech-debt.md, and docs/roadmap.md in https://github.com/Nik-1019/creator-os, which problems appear in 3 or more of these sources? For each one, tell me exactly which sources mention it.

Quick identifies the strongest signals. These are the issues with the most evidence behind them.

Quick giving vague results?

If Quick returns a generic answer without naming specific issues, try breaking the question into two parts. First ask it to list issues from each source separately, then ask which ones overlap.

Quick is not cross-referencing my repository files properly

Score your prediction

Look at Quick's convergence results. Compare them against the top 5 you wrote down earlier.

How many of your picks appear in Quick's top convergence items?
Did you miss anything that the data strongly supports?
Did you include anything that turned out to be single-source (weak signal)?

This is not about being right or wrong. It is about understanding how gut instinct compares to data-backed evidence. The gaps between your prediction and the data are where the real learning happens.

You now have a data-backed view of what should ship. But there is something the documents cannot tell you: what is actually happening on the team right now. In the next step, you will read the room and discover context that changes your recommendation.

Hit the Dependency Wall

Read the Room

Your convergence analysis gave you a solid evidence-based recommendation. But documents are snapshots. They tell you what was planned or reported, not what is actually happening right now.

The CreatorOS team has been discussing v1.1 in Slack for the past two weeks. Engineers, support, and product have all weighed in. In this step, you will ask Quick to search those conversations and discover context that changes your recommendation.

In this step, get ready to:

Search team Slack conversations to discover what the documents cannot tell you.
Find at least 3 insights that change how you would prioritize v1.1.
Revise your release recommendation based on what you learned.

Check engineering readiness

Your Step 3 analysis told you WHAT should ship. Slack will tell you what is actually READY to ship. There is a difference between a priority and a finished PR.

Ask Quick to search the engineering channel for status updates by entering this prompt:

Search Slack messages in the #engineering channel for discussions about auth, calendar timezone, CSV export, and Instagram carousel. Summarize the status of each one.

Read Quick's response carefully. You should discover some surprises:

Is auth still in progress, or is it already done?
What does the team say about Instagram carousel?
Does anyone flag any risks with CSV export?

Why does Slack change things?

Documents tell you what is planned. Slack tells you what is actually happening. A roadmap might say 'auth improvements: Sprint 3' but Slack reveals 'auth PR merged yesterday.' That is the difference between a priority and a done deal.

Pay special attention to anything that contradicts what you saw in the documents. Those contradictions are where your recommendation needs to change.

Check the urgency

The support tickets told you what customers complain about. Slack tells you how urgently those complaints are hitting the team right now.

Ask Quick to search for recent support escalations by entering this prompt:

Search Slack messages in the #support-escalations channel for the most recent customer escalations. What problems are actively hurting customers this week?

Quick returns recent escalations from the support team. Look for patterns: is any single issue causing immediate revenue damage? Has anything gotten worse recently?

Now check the release planning channel to see how the PM is framing priorities by entering this prompt:

Search Slack messages in the #release-planning channel. What has the team decided about v1.1 priorities and what format does the PM want for the recommendation?

This tells you what the meeting expects. Marcus has specific requirements for how the recommendation should be presented.

Quick not finding relevant Slack messages?

If Quick returns no results or irrelevant messages, try narrowing your search to specific keywords. Instead of a broad search, ask about one topic at a time: 'Search #engineering for messages about auth PR status.'

Quick is not returning useful results from my Slack workspace

Identify what changed

Based on what you found in Slack, at least 3-4 items in your recommendation should change. Think about:

Is anything you thought was "in progress" actually already done?
Is anything you thought was "deferred" actually permanently dead?
Is any issue more urgent than the documents suggested?
Does any "easy win" have a hidden risk the team flagged?

These are the four questions that separate a document-based recommendation from a team-aware recommendation. The best release managers check informal channels before making final decisions.

You now have the full picture: data-backed priorities from the repo AND real-time context from the team. In the next step, you will combine everything into a release recommendation you can defend.

Build the Release Command Center

Defend Your Release Plan

You have a recommendation backed by repository evidence and team context from Slack. But a recommendation that lives in your head is not useful to anyone else.

The planning meeting is Monday morning. Marcus asked for three things: what you are shipping, what you are deferring, and WHY for each decision. Data-backed, not opinions. In this step, you build the artifact that walks into that meeting for you.

In this step, get ready to:

Generate a structured Markdown release recommendation using Amazon Quick.
Build an interactive Release Command Center app in Amazon Quick.
Publish the app and verify it is shareable.

Generate your release recommendation

First, ask Quick to synthesize everything you have learned into a structured release document. This becomes your thinking artifact before you build the polished app.

In Amazon Quick chat, ask it to produce your release recommendation by entering this prompt:

Based on everything we have discussed about the https://github.com/Nik-1019/creator-os repository (GitHub issues, customer feedback, tech debt, roadmap, and the Slack conversations), generate a v1.1 Release Recommendation in Markdown format with these sections:

1. SHIP in v1.1 - items that are high-priority, unblocked, and supported by multiple sources. Include a one-sentence reason for each.
2. DEFER to v2.0 - items that are blocked by infrastructure or external dependencies. Include why each is blocked.
3. RISKS - any hidden dependencies or caveats for the items we are shipping.
4. EVIDENCE - which sources supported each decision (GitHub issues, customer feedback, support tickets, Slack conversations).
5. RECOMMENDATION - a 2-3 sentence executive summary of the v1.1 strategy.

Quick generates a structured document. Review it carefully against what you learned in Steps 3 and 4.

Check that items you know are blocked (from Slack) appear in the DEFER section, not the SHIP section.
Check that the RISKS section mentions any hidden couplings you discovered.
If anything is wrong, tell Quick what to fix. For example: 'Move Instagram carousel from Defer to permanently removed. The team confirmed Meta will not approve the API.'

Why review AI output?

Quick synthesizes information well but it does not make judgment calls. You are the release manager. If Quick puts CSV export in the SHIP section without mentioning the schema coupling risk, that is YOUR job to catch and add. AI assists the decision. You own the decision.

Build the Release Command Center app

Your Markdown doc is the thinking. The app is the presentation. You are turning your verified recommendation into something the whole team can open in a browser and react to.

In Amazon Quick, in the left side bar
Select Apps from the menu.

You will see the Apps page with a prompt area. Describe your Release Command Center in one detailed prompt.

Go back to your Quick chat tab and copy the entire Markdown release recommendation it generated (from the title down to the RECOMMENDATION section).

In the Apps prompt area, paste the following instruction first, then paste your full Markdown below it:

Turn the following release recommendation into an interactive Release Command Center app with:
1) A summary header showing the release name, total issues shipping, and a one-sentence status.
2) A styled table of issues shipping in v1.1.
3) A Deferred to v2.0 section showing what was cut and why.
4) A Risks section with key dependencies and caveats.
5) Sections for each department: Engineering, Product, and Marketing.

Here is the recommendation:

[PASTE YOUR FULL MARKDOWN DOCUMENT HERE]

Enter or click Generate.

Watch as Quick builds the app in real time. You will see code being written and a live preview appearing.

Review the live preview once generation completes.
If any section is missing data or looks incorrect, use the chat panel below the preview to refine it.

App not generating?

If the prompt triggers a content policy warning, close the editor, wait 15-20 minutes for the session to reset, then try again. If the agent produces an incomplete app, use follow-up messages to add the missing sections one at a time.

help me troubleshoot my Amazon Quick app not generating

Publish and share your app

Your Release Command Center is ready for the team. Publishing creates a shareable URL that anyone can open without an Amazon Quick account.

Review each section of your app against your investigation findings to confirm the data is accurate.

Click Publish when you are satisfied with the app.
Copy the shareable URL from the confirmation dialog that appears.
Open the URL in a new browser tab to verify it loads correctly.

You should see your Release Command Center displaying your prioritized v1.1 issues, deferred items with reasons, risks, and department sections.

App not loading at the URL?

Make sure you chose Publish (not just Share). If you see a login prompt, go back to the app editor, choose Share, set the access level to Public, then choose Publish again.

help me publish my Amazon Quick app so it is publicly accessible

💡 Why defend, not just present?

In real release planning, there is no perfect answer. Engineering wants to fix tech debt. Support wants the timezone bug fixed yesterday. Marketing wants a splashy feature to announce. Your job as release manager is not to make everyone happy. It is to make the best tradeoff and explain why.

The strength of your plan is not what you included. It is how clearly you can explain what you excluded and why.

You now have a live artifact that proves you joined an unfamiliar project, connected AI to the codebase and team conversations, investigated the business context, and produced a shareable, defensible release plan. All in under an hour.

Secret mission

Build a Release Triage Flow

You built the v1.1 recommendation through conversation. But v1.2 is coming. And v1.3. Can you turn that manual investigation into an automated flow that any teammate can run to triage the next release, without you being in the loop?

Clean Up Your Resources

This project runs entirely on the Amazon Quick Free plan and local processes, so there are no ongoing costs. Decide whether to keep your resources running, pause them to come back later, or delete them entirely.

Resources you used:

Amazon Quick account (Free plan, no ongoing charges).
GitHub connector in Amazon Quick (no cost).
Release Command Center app in Amazon Quick (no cost).
Release Triage Quick Flow in Amazon Quick (no cost).
Local clone of creator-os repository (disk space only).
Running backend process (port 3001) and frontend process (port 5173).

Keep everything running

No action needed. Choose this if you are still actively building or want to keep experimenting with Amazon Quick.

Your Amazon Quick account, app, flow, and GitHub connector remain available at no cost on the Free plan.
After the 30-day Plus trial ends, you retain access to chat, apps, flows, and integrations on the Free tier.
Your local creator-os clone stays on your machine until you delete it manually.
The backend and frontend processes continue running in your terminal windows until you close them or press Ctrl+C.

Pause - I'll come back to this later

Shut down running processes to free up your terminal. Your Amazon Quick resources persist at no cost and will be there when you return.

In the terminal running the backend, press Ctrl+C to stop the backend server.
In the terminal running the frontend, press Ctrl+C to stop the frontend dev server.
Your Amazon Quick account, Release Command Center app, Release Triage flow, and GitHub connector all remain available at no cost. No action needed for those.
The local creator-os folder stays on your Desktop. You can restart the servers later by running npm run dev in each directory.

Delete - I don't want to use this again

Remove all project resources and start fresh. Follow each step below to clean up everything.

In the terminal running the backend, press Ctrl+C to stop the server. Do the same for the frontend terminal.
Remove the local repository by running this command from your Desktop:

rm -rf creator-os

To delete your Amazon Quick account (which removes your connector, app, and flow): sign in to Amazon Quick, click your profile icon, and choose Manage account. From the Manage Account page, select Account settings, then choose Manage to open the Account termination screen. Toggle off Account termination protection, then type the confirmation word shown on screen to complete the deletion.

What about GitHub?

Your GitHub account is a general-purpose tool you will likely use for other projects. This guide does not include instructions to delete it. The creator-os repository belongs to the original author, not your account, so there is nothing to remove on GitHub.

Nice Work!

You joined an unfamiliar codebase, connected AI to both the repository and the team's Slack workspace, made your own call before the data was in, discovered where you were wrong, and delivered a defensible release plan. All in under an hour.

You've learned how to:

Connect Amazon Quick to both a GitHub repository and a Slack workspace, then use AI to investigate an unfamiliar codebase's architecture, issues, and team conversations in minutes.
Form your own release priorities, test them against multi-source evidence (customer feedback, support tickets, tech debt, and team Slack conversations), and revise your thinking based on what the data reveals.
Build and publish a shareable Release Command Center app that presents a defensible v1.1 release plan with tradeoffs any team member can understand.
Secret Mission: Built a reusable Quick Flow that automates the triage process so the team can regenerate the analysis for future releases.

Ready to quiz yourself?