Project workspace
Fetching the workspace overview, requirements, agents and release status.
Active project
VentureOS Product FactoryProject artifacts
Agent-ready prompts generated from current project context, readiness, review queue, feedback and release state.
Package the current workspace into focused prompts, tool-specific AI build packs and implementation plans for database, API, UI, tests and release readiness.
Recommended prompt
plannedReview prompt
Use this when an agent should review the current project state, UI or implementation for v1 readiness.
Total export size
ready47,741 chars
Across generated prompt packs
Next action
in progressMap dependencies
Release
Prompt quality improves as the project accumulates richer operating evidence.
The exports below package the current product idea, readiness, tasks, feedback and release state into prompts, tool-specific packs and implementation planning packs for coding agents.
Product
Decision state
Template source
Baseline build prompt for the next coherent product increment.
Use this when an agent should implement the next product increment from current project context.
# Build the next Assembly Hangar increment ## Project Context Project: VentureOS Product Factory Description: Demo project that turns a customer idea into an auditable development execution plan. Source type: project_brief Product summary: VentureOS Product Factory is een demo-project dat een klantidee omzet in een controleerbaar ontwikkel- en uitvoeringsplan. De huidige staat is agent_plan en de beschikbare input bestaat vooral uit een projectbrief voor een gestructureerde pipeline van intake tot release, inclusief UAT-feedback en rollback-voorbereiding. Goals: - Definieer een end-to-end workflow van intake, planning, uitvoering, UAT, release en rollback-voorbereiding. - Leg per fase auditable beslismomenten, artefacten en statusovergangen vast. - Neem UAT-feedback expliciet op als stap die releasebeslissingen kan blokkeren of terugsturen naar uitvoering. - Beschrijf rollback-voorbereiding als verplicht onderdeel vóór release. Target users: - Product managers die klantideeën willen vertalen naar uitvoerbare ontwikkelplannen. - Development leads die een gestructureerde delivery-pipeline nodig hebben. - QA- en UAT-stakeholders die feedback en acceptatiecriteria willen vastleggen. - Operations- of release-managers die rollback-voorbereiding moeten borgen. Risks: - De projectbrief bevat nog weinig detail, waardoor scope, datamodel en integratiepunten onvoldoende scherp zijn. - Zonder duidelijke UAT-criteria kan feedback subjectief worden en releases vertragen. - Rollback-voorbereiding kan te laat in het proces worden opgepakt als deze niet als harde release-gate wordt gemodelleerd. - Auditability kan incompleet zijn als beslissingen, feedback en statuswijzigingen niet consequent worden vastgelegd. Assumptions: - De pipeline moet meerdere fasen ondersteunen van eerste intake tot productie-release. - Elke fase heeft eigen outputs, verantwoordelijken en acceptatiecriteria nodig. - UAT-feedback moet traceerbaar gekoppeld zijn aan requirements, taken of releasebeslissingen. - Rollback-plannen moeten vóór release beschikbaar en beoordeeld zijn. Missing information: - Welke rollen en permissies moeten binnen de pipeline worden ondersteund? - Welke artefacten zijn verplicht per fase, zoals intakeformulier, requirements, testresultaten en releaseplan? - Welke criteria bepalen of UAT-feedback blokkerend is voor release? - Moet de pipeline integreren met bestaande tools voor tickets, repositories, CI/CD of incidentmanagement? Requirements: - critical functional: Structured pipeline (open) Agent tasks: - #1 backend: Agent backend should complete "Generate executable task plan". Acceptance criteria: Record is visible and auditable. (ready) Feedback: none recorded Releases: none recorded Readiness: 86% production ready Next constraint: Release: No release registered yet. Next action: Map dependencies Review queue: - high: Draft first release - The project looks delivery-ready, but no release bundle has been registered. - medium: Map dependencies - Work nodes exist, but ordering and blocking risks have not been mapped. Release decision: release blocked: Resolve high-priority review items before approving or registering a production release. ## Instructions 1. Start by reading AGENTS.md, AGENT_STATUS.md, docs/ai/README.md, AI_RULES, AGENT_OPERATING_MANUAL, AGENT_STEP_INSTRUCTIONS, CURRENT_STATE, ROADMAP, PYRAMID_METHOD and STEP_BLUEPRINT. 2. Check in through AGENT_STATUS.md before editing files with expected files, affected modules, goal, impact, sensitive areas, risk level and blockers. 3. When touching code, GitHub PRs, Step 12, release safety, agent ownership or sensitive areas, read docs/architecture/AI_PR_REVIEW_MERGE_GATE.md. 4. Inspect the current repository before editing. 5. Implement the next action with the smallest coherent production-quality change. 6. Preserve tenant safety, auditability and existing UI conventions. 7. Run relevant typecheck, tests and render checks. 8. When checks are green, review evidence is complete and no blockers remain, move or prepare the work for staging as the default test environment; live/production still requires explicit human approval. 9. Update AI operating docs and handoff when changing behavior. 10. Release the AGENT_STATUS.md entry with actual files changed, checks, security/privacy notes, risks and follow-up. ## Required Output - State what changed or what was found. - Include verification performed. - List remaining risks or next recommended step.
Cursor, Codex and Claude Code packs for the agent environment.
Use this to create or refresh Cursor repository rules for Assembly Hangar work.
# Generate Cursor rules for this Assembly Hangar project ## Project Context Project: VentureOS Product Factory Description: Demo project that turns a customer idea into an auditable development execution plan. Source type: project_brief Product summary: VentureOS Product Factory is een demo-project dat een klantidee omzet in een controleerbaar ontwikkel- en uitvoeringsplan. De huidige staat is agent_plan en de beschikbare input bestaat vooral uit een projectbrief voor een gestructureerde pipeline van intake tot release, inclusief UAT-feedback en rollback-voorbereiding. Goals: - Definieer een end-to-end workflow van intake, planning, uitvoering, UAT, release en rollback-voorbereiding. - Leg per fase auditable beslismomenten, artefacten en statusovergangen vast. - Neem UAT-feedback expliciet op als stap die releasebeslissingen kan blokkeren of terugsturen naar uitvoering. - Beschrijf rollback-voorbereiding als verplicht onderdeel vóór release. Target users: - Product managers die klantideeën willen vertalen naar uitvoerbare ontwikkelplannen. - Development leads die een gestructureerde delivery-pipeline nodig hebben. - QA- en UAT-stakeholders die feedback en acceptatiecriteria willen vastleggen. - Operations- of release-managers die rollback-voorbereiding moeten borgen. Risks: - De projectbrief bevat nog weinig detail, waardoor scope, datamodel en integratiepunten onvoldoende scherp zijn. - Zonder duidelijke UAT-criteria kan feedback subjectief worden en releases vertragen. - Rollback-voorbereiding kan te laat in het proces worden opgepakt als deze niet als harde release-gate wordt gemodelleerd. - Auditability kan incompleet zijn als beslissingen, feedback en statuswijzigingen niet consequent worden vastgelegd. Assumptions: - De pipeline moet meerdere fasen ondersteunen van eerste intake tot productie-release. - Elke fase heeft eigen outputs, verantwoordelijken en acceptatiecriteria nodig. - UAT-feedback moet traceerbaar gekoppeld zijn aan requirements, taken of releasebeslissingen. - Rollback-plannen moeten vóór release beschikbaar en beoordeeld zijn. Missing information: - Welke rollen en permissies moeten binnen de pipeline worden ondersteund? - Welke artefacten zijn verplicht per fase, zoals intakeformulier, requirements, testresultaten en releaseplan? - Welke criteria bepalen of UAT-feedback blokkerend is voor release? - Moet de pipeline integreren met bestaande tools voor tickets, repositories, CI/CD of incidentmanagement? Requirements: - critical functional: Structured pipeline (open) Agent tasks: - #1 backend: Agent backend should complete "Generate executable task plan". Acceptance criteria: Record is visible and auditable. (ready) Feedback: none recorded Releases: none recorded Readiness: 86% production ready Next constraint: Release: No release registered yet. Next action: Map dependencies Review queue: - high: Draft first release - The project looks delivery-ready, but no release bundle has been registered. - medium: Map dependencies - Work nodes exist, but ordering and blocking risks have not been mapped. Release decision: release blocked: Resolve high-priority review items before approving or registering a production release. ## Instructions 1. Return markdown suitable for a Cursor rules file. 2. Make the rules repository-aware and specific to the current project state. 3. Include conventions for AGENTS.md, AGENT_STATUS.md, tenant safety, permissions, audit logs, AI operating docs, AI PR review merge gates and v1 console UI quality. 4. Tell Cursor to inspect the repository before editing and to keep changes scoped. 5. Include verification expectations for typecheck, tests, build and browser smoke checks when UI changes. ## Required Output - State what changed or what was found. - Include verification performed. - List remaining risks or next recommended step.
Use this when Codex should take the next scoped implementation step inside the repository.
# Execute the next Assembly Hangar step in Codex ## Project Context Project: VentureOS Product Factory Description: Demo project that turns a customer idea into an auditable development execution plan. Source type: project_brief Product summary: VentureOS Product Factory is een demo-project dat een klantidee omzet in een controleerbaar ontwikkel- en uitvoeringsplan. De huidige staat is agent_plan en de beschikbare input bestaat vooral uit een projectbrief voor een gestructureerde pipeline van intake tot release, inclusief UAT-feedback en rollback-voorbereiding. Goals: - Definieer een end-to-end workflow van intake, planning, uitvoering, UAT, release en rollback-voorbereiding. - Leg per fase auditable beslismomenten, artefacten en statusovergangen vast. - Neem UAT-feedback expliciet op als stap die releasebeslissingen kan blokkeren of terugsturen naar uitvoering. - Beschrijf rollback-voorbereiding als verplicht onderdeel vóór release. Target users: - Product managers die klantideeën willen vertalen naar uitvoerbare ontwikkelplannen. - Development leads die een gestructureerde delivery-pipeline nodig hebben. - QA- en UAT-stakeholders die feedback en acceptatiecriteria willen vastleggen. - Operations- of release-managers die rollback-voorbereiding moeten borgen. Risks: - De projectbrief bevat nog weinig detail, waardoor scope, datamodel en integratiepunten onvoldoende scherp zijn. - Zonder duidelijke UAT-criteria kan feedback subjectief worden en releases vertragen. - Rollback-voorbereiding kan te laat in het proces worden opgepakt als deze niet als harde release-gate wordt gemodelleerd. - Auditability kan incompleet zijn als beslissingen, feedback en statuswijzigingen niet consequent worden vastgelegd. Assumptions: - De pipeline moet meerdere fasen ondersteunen van eerste intake tot productie-release. - Elke fase heeft eigen outputs, verantwoordelijken en acceptatiecriteria nodig. - UAT-feedback moet traceerbaar gekoppeld zijn aan requirements, taken of releasebeslissingen. - Rollback-plannen moeten vóór release beschikbaar en beoordeeld zijn. Missing information: - Welke rollen en permissies moeten binnen de pipeline worden ondersteund? - Welke artefacten zijn verplicht per fase, zoals intakeformulier, requirements, testresultaten en releaseplan? - Welke criteria bepalen of UAT-feedback blokkerend is voor release? - Moet de pipeline integreren met bestaande tools voor tickets, repositories, CI/CD of incidentmanagement? Requirements: - critical functional: Structured pipeline (open) Agent tasks: - #1 backend: Agent backend should complete "Generate executable task plan". Acceptance criteria: Record is visible and auditable. (ready) Feedback: none recorded Releases: none recorded Readiness: 86% production ready Next constraint: Release: No release registered yet. Next action: Map dependencies Review queue: - high: Draft first release - The project looks delivery-ready, but no release bundle has been registered. - medium: Map dependencies - Work nodes exist, but ordering and blocking risks have not been mapped. Release decision: release blocked: Resolve high-priority review items before approving or registering a production release. ## Instructions 1. Start by reading AGENTS.md, AGENT_STATUS.md, docs/ai/README.md, AI_RULES, AGENT_OPERATING_MANUAL, AGENT_STEP_INSTRUCTIONS, CURRENT_STATE, ROADMAP, TODO, PYRAMID_METHOD and STEP_BLUEPRINT. 2. If the task touches code, GitHub PRs, Step 12, release safety, agent ownership or sensitive areas, read docs/architecture/AI_PR_REVIEW_MERGE_GATE.md. 3. Open a focused AGENT_STATUS.md check-in before editing files with expected files, affected modules, goal, impact, sensitive areas, risk level and blockers. 4. Choose the highest-impact safe step from the current blockers and product state. 5. Use existing code patterns, preserve user changes and avoid broad refactors. 6. Treat code PRs as requiring AI Architecture & Risk Review before merge; critical findings block merge and high findings require authorized accepted-risk logging. 7. When checks are green, review evidence is complete and no blockers remain, move or prepare the work for staging as the default test environment; report blockers if staging cannot be reached. 8. After implementation, run relevant checks, update version docs and release the AGENT_STATUS.md entry with actual files changed, checks, security/privacy notes, risks and follow-up. ## Required Output - State what changed or what was found. - Include verification performed. - List remaining risks or next recommended step.
Use this when Claude Code should continue work with strong context and explicit guardrails.
# Continue Assembly Hangar work in Claude Code ## Project Context Project: VentureOS Product Factory Description: Demo project that turns a customer idea into an auditable development execution plan. Source type: project_brief Product summary: VentureOS Product Factory is een demo-project dat een klantidee omzet in een controleerbaar ontwikkel- en uitvoeringsplan. De huidige staat is agent_plan en de beschikbare input bestaat vooral uit een projectbrief voor een gestructureerde pipeline van intake tot release, inclusief UAT-feedback en rollback-voorbereiding. Goals: - Definieer een end-to-end workflow van intake, planning, uitvoering, UAT, release en rollback-voorbereiding. - Leg per fase auditable beslismomenten, artefacten en statusovergangen vast. - Neem UAT-feedback expliciet op als stap die releasebeslissingen kan blokkeren of terugsturen naar uitvoering. - Beschrijf rollback-voorbereiding als verplicht onderdeel vóór release. Target users: - Product managers die klantideeën willen vertalen naar uitvoerbare ontwikkelplannen. - Development leads die een gestructureerde delivery-pipeline nodig hebben. - QA- en UAT-stakeholders die feedback en acceptatiecriteria willen vastleggen. - Operations- of release-managers die rollback-voorbereiding moeten borgen. Risks: - De projectbrief bevat nog weinig detail, waardoor scope, datamodel en integratiepunten onvoldoende scherp zijn. - Zonder duidelijke UAT-criteria kan feedback subjectief worden en releases vertragen. - Rollback-voorbereiding kan te laat in het proces worden opgepakt als deze niet als harde release-gate wordt gemodelleerd. - Auditability kan incompleet zijn als beslissingen, feedback en statuswijzigingen niet consequent worden vastgelegd. Assumptions: - De pipeline moet meerdere fasen ondersteunen van eerste intake tot productie-release. - Elke fase heeft eigen outputs, verantwoordelijken en acceptatiecriteria nodig. - UAT-feedback moet traceerbaar gekoppeld zijn aan requirements, taken of releasebeslissingen. - Rollback-plannen moeten vóór release beschikbaar en beoordeeld zijn. Missing information: - Welke rollen en permissies moeten binnen de pipeline worden ondersteund? - Welke artefacten zijn verplicht per fase, zoals intakeformulier, requirements, testresultaten en releaseplan? - Welke criteria bepalen of UAT-feedback blokkerend is voor release? - Moet de pipeline integreren met bestaande tools voor tickets, repositories, CI/CD of incidentmanagement? Requirements: - critical functional: Structured pipeline (open) Agent tasks: - #1 backend: Agent backend should complete "Generate executable task plan". Acceptance criteria: Record is visible and auditable. (ready) Feedback: none recorded Releases: none recorded Readiness: 86% production ready Next constraint: Release: No release registered yet. Next action: Map dependencies Review queue: - high: Draft first release - The project looks delivery-ready, but no release bundle has been registered. - medium: Map dependencies - Work nodes exist, but ordering and blocking risks have not been mapped. Release decision: release blocked: Resolve high-priority review items before approving or registering a production release. ## Instructions 1. Start by reading AGENTS.md, AGENT_STATUS.md, docs/ai/README.md, AI_RULES, AGENT_OPERATING_MANUAL, AGENT_STEP_INSTRUCTIONS, CURRENT_STATE, ROADMAP, PYRAMID_METHOD and STEP_BLUEPRINT. 2. If the task touches code, GitHub PRs, Step 12, release safety, agent ownership or sensitive areas, read docs/architecture/AI_PR_REVIEW_MERGE_GATE.md. 3. Treat the current project state and AI operating docs as the source of truth. 4. Create an AGENT_STATUS.md check-in before editing files with expected files, affected modules, goal, impact, sensitive areas, risk level and blockers. 5. Summarize the current objective before editing, then implement one coherent step. 6. Keep frontend changes consistent with the quiet operational SaaS console style. 7. Preserve permission checks, tenant filtering, encrypted secret handling and auditability. 8. Treat code PRs as requiring AI Architecture & Risk Review before merge; critical findings block merge and high findings require authorized accepted-risk logging. 9. When checks are green, review evidence is complete and no blockers remain, move or prepare the work for staging as the default test environment; report blockers if staging cannot be reached. 10. Return a concise handoff with files changed, checks performed, risks and next step, then release the AGENT_STATUS.md entry. ## Required Output - State what changed or what was found. - Include verification performed. - List remaining risks or next recommended step.
Database, API and UI plans for turning context into buildable work.
Use this when an agent should design or validate persistence, migrations and tenant isolation.
# Plan the database work for this Assembly Hangar project ## Project Context Project: VentureOS Product Factory Description: Demo project that turns a customer idea into an auditable development execution plan. Source type: project_brief Product summary: VentureOS Product Factory is een demo-project dat een klantidee omzet in een controleerbaar ontwikkel- en uitvoeringsplan. De huidige staat is agent_plan en de beschikbare input bestaat vooral uit een projectbrief voor een gestructureerde pipeline van intake tot release, inclusief UAT-feedback en rollback-voorbereiding. Goals: - Definieer een end-to-end workflow van intake, planning, uitvoering, UAT, release en rollback-voorbereiding. - Leg per fase auditable beslismomenten, artefacten en statusovergangen vast. - Neem UAT-feedback expliciet op als stap die releasebeslissingen kan blokkeren of terugsturen naar uitvoering. - Beschrijf rollback-voorbereiding als verplicht onderdeel vóór release. Target users: - Product managers die klantideeën willen vertalen naar uitvoerbare ontwikkelplannen. - Development leads die een gestructureerde delivery-pipeline nodig hebben. - QA- en UAT-stakeholders die feedback en acceptatiecriteria willen vastleggen. - Operations- of release-managers die rollback-voorbereiding moeten borgen. Risks: - De projectbrief bevat nog weinig detail, waardoor scope, datamodel en integratiepunten onvoldoende scherp zijn. - Zonder duidelijke UAT-criteria kan feedback subjectief worden en releases vertragen. - Rollback-voorbereiding kan te laat in het proces worden opgepakt als deze niet als harde release-gate wordt gemodelleerd. - Auditability kan incompleet zijn als beslissingen, feedback en statuswijzigingen niet consequent worden vastgelegd. Assumptions: - De pipeline moet meerdere fasen ondersteunen van eerste intake tot productie-release. - Elke fase heeft eigen outputs, verantwoordelijken en acceptatiecriteria nodig. - UAT-feedback moet traceerbaar gekoppeld zijn aan requirements, taken of releasebeslissingen. - Rollback-plannen moeten vóór release beschikbaar en beoordeeld zijn. Missing information: - Welke rollen en permissies moeten binnen de pipeline worden ondersteund? - Welke artefacten zijn verplicht per fase, zoals intakeformulier, requirements, testresultaten en releaseplan? - Welke criteria bepalen of UAT-feedback blokkerend is voor release? - Moet de pipeline integreren met bestaande tools voor tickets, repositories, CI/CD of incidentmanagement? Requirements: - critical functional: Structured pipeline (open) Agent tasks: - #1 backend: Agent backend should complete "Generate executable task plan". Acceptance criteria: Record is visible and auditable. (ready) Feedback: none recorded Releases: none recorded Readiness: 86% production ready Next constraint: Release: No release registered yet. Next action: Map dependencies Review queue: - high: Draft first release - The project looks delivery-ready, but no release bundle has been registered. - medium: Map dependencies - Work nodes exist, but ordering and blocking risks have not been mapped. Release decision: release blocked: Resolve high-priority review items before approving or registering a production release. ## Instructions 1. Identify which project data needs persistence and whether existing tables already cover it. 2. Plan migrations with tenant_id, audit fields, indexes and rollback considerations. 3. Preserve explicit tenant filtering and RLS/application tenant context. 4. Define how local-file fallback and Postgres behavior stay aligned. 5. Include repository tests and conditional Postgres integration checks when TEST_DATABASE_URL is available. ## Required Output - State what changed or what was found. - Include verification performed. - List remaining risks or next recommended step.
Use this when an agent should design or review API endpoints, permissions and audit behavior.
# Plan the API work for this Assembly Hangar project ## Project Context Project: VentureOS Product Factory Description: Demo project that turns a customer idea into an auditable development execution plan. Source type: project_brief Product summary: VentureOS Product Factory is een demo-project dat een klantidee omzet in een controleerbaar ontwikkel- en uitvoeringsplan. De huidige staat is agent_plan en de beschikbare input bestaat vooral uit een projectbrief voor een gestructureerde pipeline van intake tot release, inclusief UAT-feedback en rollback-voorbereiding. Goals: - Definieer een end-to-end workflow van intake, planning, uitvoering, UAT, release en rollback-voorbereiding. - Leg per fase auditable beslismomenten, artefacten en statusovergangen vast. - Neem UAT-feedback expliciet op als stap die releasebeslissingen kan blokkeren of terugsturen naar uitvoering. - Beschrijf rollback-voorbereiding als verplicht onderdeel vóór release. Target users: - Product managers die klantideeën willen vertalen naar uitvoerbare ontwikkelplannen. - Development leads die een gestructureerde delivery-pipeline nodig hebben. - QA- en UAT-stakeholders die feedback en acceptatiecriteria willen vastleggen. - Operations- of release-managers die rollback-voorbereiding moeten borgen. Risks: - De projectbrief bevat nog weinig detail, waardoor scope, datamodel en integratiepunten onvoldoende scherp zijn. - Zonder duidelijke UAT-criteria kan feedback subjectief worden en releases vertragen. - Rollback-voorbereiding kan te laat in het proces worden opgepakt als deze niet als harde release-gate wordt gemodelleerd. - Auditability kan incompleet zijn als beslissingen, feedback en statuswijzigingen niet consequent worden vastgelegd. Assumptions: - De pipeline moet meerdere fasen ondersteunen van eerste intake tot productie-release. - Elke fase heeft eigen outputs, verantwoordelijken en acceptatiecriteria nodig. - UAT-feedback moet traceerbaar gekoppeld zijn aan requirements, taken of releasebeslissingen. - Rollback-plannen moeten vóór release beschikbaar en beoordeeld zijn. Missing information: - Welke rollen en permissies moeten binnen de pipeline worden ondersteund? - Welke artefacten zijn verplicht per fase, zoals intakeformulier, requirements, testresultaten en releaseplan? - Welke criteria bepalen of UAT-feedback blokkerend is voor release? - Moet de pipeline integreren met bestaande tools voor tickets, repositories, CI/CD of incidentmanagement? Requirements: - critical functional: Structured pipeline (open) Agent tasks: - #1 backend: Agent backend should complete "Generate executable task plan". Acceptance criteria: Record is visible and auditable. (ready) Feedback: none recorded Releases: none recorded Readiness: 86% production ready Next constraint: Release: No release registered yet. Next action: Map dependencies Review queue: - high: Draft first release - The project looks delivery-ready, but no release bundle has been registered. - medium: Map dependencies - Work nodes exist, but ordering and blocking risks have not been mapped. Release decision: release blocked: Resolve high-priority review items before approving or registering a production release. ## Instructions 1. List the API endpoints or service methods needed for the next product increment. 2. Specify tenant context, user context and permission gates for every mutation. 3. Define safe response shapes that avoid leaking secrets or internal-only fields. 4. Include audit log expectations for settings, integration, release and workflow actions. 5. Add focused API/service tests for success, permission failure and tenant isolation behavior. ## Required Output - State what changed or what was found. - Include verification performed. - List remaining risks or next recommended step.
Use this when an agent should plan or implement the next v1 console screen.
# Plan the v1 UI work for this Assembly Hangar project ## Project Context Project: VentureOS Product Factory Description: Demo project that turns a customer idea into an auditable development execution plan. Source type: project_brief Product summary: VentureOS Product Factory is een demo-project dat een klantidee omzet in een controleerbaar ontwikkel- en uitvoeringsplan. De huidige staat is agent_plan en de beschikbare input bestaat vooral uit een projectbrief voor een gestructureerde pipeline van intake tot release, inclusief UAT-feedback en rollback-voorbereiding. Goals: - Definieer een end-to-end workflow van intake, planning, uitvoering, UAT, release en rollback-voorbereiding. - Leg per fase auditable beslismomenten, artefacten en statusovergangen vast. - Neem UAT-feedback expliciet op als stap die releasebeslissingen kan blokkeren of terugsturen naar uitvoering. - Beschrijf rollback-voorbereiding als verplicht onderdeel vóór release. Target users: - Product managers die klantideeën willen vertalen naar uitvoerbare ontwikkelplannen. - Development leads die een gestructureerde delivery-pipeline nodig hebben. - QA- en UAT-stakeholders die feedback en acceptatiecriteria willen vastleggen. - Operations- of release-managers die rollback-voorbereiding moeten borgen. Risks: - De projectbrief bevat nog weinig detail, waardoor scope, datamodel en integratiepunten onvoldoende scherp zijn. - Zonder duidelijke UAT-criteria kan feedback subjectief worden en releases vertragen. - Rollback-voorbereiding kan te laat in het proces worden opgepakt als deze niet als harde release-gate wordt gemodelleerd. - Auditability kan incompleet zijn als beslissingen, feedback en statuswijzigingen niet consequent worden vastgelegd. Assumptions: - De pipeline moet meerdere fasen ondersteunen van eerste intake tot productie-release. - Elke fase heeft eigen outputs, verantwoordelijken en acceptatiecriteria nodig. - UAT-feedback moet traceerbaar gekoppeld zijn aan requirements, taken of releasebeslissingen. - Rollback-plannen moeten vóór release beschikbaar en beoordeeld zijn. Missing information: - Welke rollen en permissies moeten binnen de pipeline worden ondersteund? - Welke artefacten zijn verplicht per fase, zoals intakeformulier, requirements, testresultaten en releaseplan? - Welke criteria bepalen of UAT-feedback blokkerend is voor release? - Moet de pipeline integreren met bestaande tools voor tickets, repositories, CI/CD of incidentmanagement? Requirements: - critical functional: Structured pipeline (open) Agent tasks: - #1 backend: Agent backend should complete "Generate executable task plan". Acceptance criteria: Record is visible and auditable. (ready) Feedback: none recorded Releases: none recorded Readiness: 86% production ready Next constraint: Release: No release registered yet. Next action: Map dependencies Review queue: - high: Draft first release - The project looks delivery-ready, but no release bundle has been registered. - medium: Map dependencies - Work nodes exist, but ordering and blocking risks have not been mapped. Release decision: release blocked: Resolve high-priority review items before approving or registering a production release. ## Instructions 1. Design the actual operational workspace, not a marketing page or decorative placeholder. 2. Use the existing app shell, panels, badges, metric tiles, action bars and project tabs. 3. Make the first viewport explain the job to be done and the next action. 4. Keep controls compact, permission-aware and scan-first for desktop users. 5. Verify with browser smoke checks for visible version badge, target copy and zero console errors. ## Required Output - State what changed or what was found. - Include verification performed. - List remaining risks or next recommended step.
Test, review, bugfix and release-readiness packs.
Use this when an agent should define or execute verification for the next Assembly Hangar change.
# Create the verification plan for this Assembly Hangar project ## Project Context Project: VentureOS Product Factory Description: Demo project that turns a customer idea into an auditable development execution plan. Source type: project_brief Product summary: VentureOS Product Factory is een demo-project dat een klantidee omzet in een controleerbaar ontwikkel- en uitvoeringsplan. De huidige staat is agent_plan en de beschikbare input bestaat vooral uit een projectbrief voor een gestructureerde pipeline van intake tot release, inclusief UAT-feedback en rollback-voorbereiding. Goals: - Definieer een end-to-end workflow van intake, planning, uitvoering, UAT, release en rollback-voorbereiding. - Leg per fase auditable beslismomenten, artefacten en statusovergangen vast. - Neem UAT-feedback expliciet op als stap die releasebeslissingen kan blokkeren of terugsturen naar uitvoering. - Beschrijf rollback-voorbereiding als verplicht onderdeel vóór release. Target users: - Product managers die klantideeën willen vertalen naar uitvoerbare ontwikkelplannen. - Development leads die een gestructureerde delivery-pipeline nodig hebben. - QA- en UAT-stakeholders die feedback en acceptatiecriteria willen vastleggen. - Operations- of release-managers die rollback-voorbereiding moeten borgen. Risks: - De projectbrief bevat nog weinig detail, waardoor scope, datamodel en integratiepunten onvoldoende scherp zijn. - Zonder duidelijke UAT-criteria kan feedback subjectief worden en releases vertragen. - Rollback-voorbereiding kan te laat in het proces worden opgepakt als deze niet als harde release-gate wordt gemodelleerd. - Auditability kan incompleet zijn als beslissingen, feedback en statuswijzigingen niet consequent worden vastgelegd. Assumptions: - De pipeline moet meerdere fasen ondersteunen van eerste intake tot productie-release. - Elke fase heeft eigen outputs, verantwoordelijken en acceptatiecriteria nodig. - UAT-feedback moet traceerbaar gekoppeld zijn aan requirements, taken of releasebeslissingen. - Rollback-plannen moeten vóór release beschikbaar en beoordeeld zijn. Missing information: - Welke rollen en permissies moeten binnen de pipeline worden ondersteund? - Welke artefacten zijn verplicht per fase, zoals intakeformulier, requirements, testresultaten en releaseplan? - Welke criteria bepalen of UAT-feedback blokkerend is voor release? - Moet de pipeline integreren met bestaande tools voor tickets, repositories, CI/CD of incidentmanagement? Requirements: - critical functional: Structured pipeline (open) Agent tasks: - #1 backend: Agent backend should complete "Generate executable task plan". Acceptance criteria: Record is visible and auditable. (ready) Feedback: none recorded Releases: none recorded Readiness: 86% production ready Next constraint: Release: No release registered yet. Next action: Map dependencies Review queue: - high: Draft first release - The project looks delivery-ready, but no release bundle has been registered. - medium: Map dependencies - Work nodes exist, but ordering and blocking risks have not been mapped. Release decision: release blocked: Resolve high-priority review items before approving or registering a production release. ## Instructions 1. Identify the highest-risk behavior touched by the next change. 2. List unit, service, repository, integration, build and browser smoke checks that prove the behavior. 3. Call out skipped checks that require external credentials or TEST_DATABASE_URL. 4. Include regression cases for permission failures, secret masking, tenant filtering and artifact persistence when relevant. 5. State exact commands to run and the page routes to smoke-test after the change. ## Required Output - State what changed or what was found. - Include verification performed. - List remaining risks or next recommended step.
Use this when an agent should prepare release readiness, approval and rollback evidence.
# Create the release checklist for this Assembly Hangar project ## Project Context Project: VentureOS Product Factory Description: Demo project that turns a customer idea into an auditable development execution plan. Source type: project_brief Product summary: VentureOS Product Factory is een demo-project dat een klantidee omzet in een controleerbaar ontwikkel- en uitvoeringsplan. De huidige staat is agent_plan en de beschikbare input bestaat vooral uit een projectbrief voor een gestructureerde pipeline van intake tot release, inclusief UAT-feedback en rollback-voorbereiding. Goals: - Definieer een end-to-end workflow van intake, planning, uitvoering, UAT, release en rollback-voorbereiding. - Leg per fase auditable beslismomenten, artefacten en statusovergangen vast. - Neem UAT-feedback expliciet op als stap die releasebeslissingen kan blokkeren of terugsturen naar uitvoering. - Beschrijf rollback-voorbereiding als verplicht onderdeel vóór release. Target users: - Product managers die klantideeën willen vertalen naar uitvoerbare ontwikkelplannen. - Development leads die een gestructureerde delivery-pipeline nodig hebben. - QA- en UAT-stakeholders die feedback en acceptatiecriteria willen vastleggen. - Operations- of release-managers die rollback-voorbereiding moeten borgen. Risks: - De projectbrief bevat nog weinig detail, waardoor scope, datamodel en integratiepunten onvoldoende scherp zijn. - Zonder duidelijke UAT-criteria kan feedback subjectief worden en releases vertragen. - Rollback-voorbereiding kan te laat in het proces worden opgepakt als deze niet als harde release-gate wordt gemodelleerd. - Auditability kan incompleet zijn als beslissingen, feedback en statuswijzigingen niet consequent worden vastgelegd. Assumptions: - De pipeline moet meerdere fasen ondersteunen van eerste intake tot productie-release. - Elke fase heeft eigen outputs, verantwoordelijken en acceptatiecriteria nodig. - UAT-feedback moet traceerbaar gekoppeld zijn aan requirements, taken of releasebeslissingen. - Rollback-plannen moeten vóór release beschikbaar en beoordeeld zijn. Missing information: - Welke rollen en permissies moeten binnen de pipeline worden ondersteund? - Welke artefacten zijn verplicht per fase, zoals intakeformulier, requirements, testresultaten en releaseplan? - Welke criteria bepalen of UAT-feedback blokkerend is voor release? - Moet de pipeline integreren met bestaande tools voor tickets, repositories, CI/CD of incidentmanagement? Requirements: - critical functional: Structured pipeline (open) Agent tasks: - #1 backend: Agent backend should complete "Generate executable task plan". Acceptance criteria: Record is visible and auditable. (ready) Feedback: none recorded Releases: none recorded Readiness: 86% production ready Next constraint: Release: No release registered yet. Next action: Map dependencies Review queue: - high: Draft first release - The project looks delivery-ready, but no release bundle has been registered. - medium: Map dependencies - Work nodes exist, but ordering and blocking risks have not been mapped. Release decision: release blocked: Resolve high-priority review items before approving or registering a production release. ## Instructions 1. Summarize release readiness, blockers, approval state and rollback posture. 2. Confirm version, changelog, release notes, prompt snapshot and agent snapshot traceability. 3. Require green typecheck, tests, build and route-specific smoke checks before approval. 4. Treat green checks plus complete review evidence as staging-ready; staging is the default test environment before any live approval. 5. List production blockers separately from safe staging/local validation. 6. Do not approve release while high-priority blockers, missing rollback evidence or unverified tenant isolation remain. ## Required Output - State what changed or what was found. - Include verification performed. - List remaining risks or next recommended step.
Use this when an agent should review the current project state, UI or implementation for v1 readiness.
# Review this project for v1 readiness ## Project Context Project: VentureOS Product Factory Description: Demo project that turns a customer idea into an auditable development execution plan. Source type: project_brief Product summary: VentureOS Product Factory is een demo-project dat een klantidee omzet in een controleerbaar ontwikkel- en uitvoeringsplan. De huidige staat is agent_plan en de beschikbare input bestaat vooral uit een projectbrief voor een gestructureerde pipeline van intake tot release, inclusief UAT-feedback en rollback-voorbereiding. Goals: - Definieer een end-to-end workflow van intake, planning, uitvoering, UAT, release en rollback-voorbereiding. - Leg per fase auditable beslismomenten, artefacten en statusovergangen vast. - Neem UAT-feedback expliciet op als stap die releasebeslissingen kan blokkeren of terugsturen naar uitvoering. - Beschrijf rollback-voorbereiding als verplicht onderdeel vóór release. Target users: - Product managers die klantideeën willen vertalen naar uitvoerbare ontwikkelplannen. - Development leads die een gestructureerde delivery-pipeline nodig hebben. - QA- en UAT-stakeholders die feedback en acceptatiecriteria willen vastleggen. - Operations- of release-managers die rollback-voorbereiding moeten borgen. Risks: - De projectbrief bevat nog weinig detail, waardoor scope, datamodel en integratiepunten onvoldoende scherp zijn. - Zonder duidelijke UAT-criteria kan feedback subjectief worden en releases vertragen. - Rollback-voorbereiding kan te laat in het proces worden opgepakt als deze niet als harde release-gate wordt gemodelleerd. - Auditability kan incompleet zijn als beslissingen, feedback en statuswijzigingen niet consequent worden vastgelegd. Assumptions: - De pipeline moet meerdere fasen ondersteunen van eerste intake tot productie-release. - Elke fase heeft eigen outputs, verantwoordelijken en acceptatiecriteria nodig. - UAT-feedback moet traceerbaar gekoppeld zijn aan requirements, taken of releasebeslissingen. - Rollback-plannen moeten vóór release beschikbaar en beoordeeld zijn. Missing information: - Welke rollen en permissies moeten binnen de pipeline worden ondersteund? - Welke artefacten zijn verplicht per fase, zoals intakeformulier, requirements, testresultaten en releaseplan? - Welke criteria bepalen of UAT-feedback blokkerend is voor release? - Moet de pipeline integreren met bestaande tools voor tickets, repositories, CI/CD of incidentmanagement? Requirements: - critical functional: Structured pipeline (open) Agent tasks: - #1 backend: Agent backend should complete "Generate executable task plan". Acceptance criteria: Record is visible and auditable. (ready) Feedback: none recorded Releases: none recorded Readiness: 86% production ready Next constraint: Release: No release registered yet. Next action: Map dependencies Review queue: - high: Draft first release - The project looks delivery-ready, but no release bundle has been registered. - medium: Map dependencies - Work nodes exist, but ordering and blocking risks have not been mapped. Release decision: release blocked: Resolve high-priority review items before approving or registering a production release. ## Instructions 1. Lead with concrete bugs, regressions and missing tests. 2. Prioritize readiness blockers, release risk and unclear user actions. 3. Reference exact files or UI surfaces when findings are code-related. 4. Keep summary secondary to findings. ## Required Output - State what changed or what was found. - Include verification performed. - List remaining risks or next recommended step.
Use this when feedback or QA identifies a defect that should become a focused fix.
# Fix the highest-impact defect in this project ## Project Context Project: VentureOS Product Factory Description: Demo project that turns a customer idea into an auditable development execution plan. Source type: project_brief Product summary: VentureOS Product Factory is een demo-project dat een klantidee omzet in een controleerbaar ontwikkel- en uitvoeringsplan. De huidige staat is agent_plan en de beschikbare input bestaat vooral uit een projectbrief voor een gestructureerde pipeline van intake tot release, inclusief UAT-feedback en rollback-voorbereiding. Goals: - Definieer een end-to-end workflow van intake, planning, uitvoering, UAT, release en rollback-voorbereiding. - Leg per fase auditable beslismomenten, artefacten en statusovergangen vast. - Neem UAT-feedback expliciet op als stap die releasebeslissingen kan blokkeren of terugsturen naar uitvoering. - Beschrijf rollback-voorbereiding als verplicht onderdeel vóór release. Target users: - Product managers die klantideeën willen vertalen naar uitvoerbare ontwikkelplannen. - Development leads die een gestructureerde delivery-pipeline nodig hebben. - QA- en UAT-stakeholders die feedback en acceptatiecriteria willen vastleggen. - Operations- of release-managers die rollback-voorbereiding moeten borgen. Risks: - De projectbrief bevat nog weinig detail, waardoor scope, datamodel en integratiepunten onvoldoende scherp zijn. - Zonder duidelijke UAT-criteria kan feedback subjectief worden en releases vertragen. - Rollback-voorbereiding kan te laat in het proces worden opgepakt als deze niet als harde release-gate wordt gemodelleerd. - Auditability kan incompleet zijn als beslissingen, feedback en statuswijzigingen niet consequent worden vastgelegd. Assumptions: - De pipeline moet meerdere fasen ondersteunen van eerste intake tot productie-release. - Elke fase heeft eigen outputs, verantwoordelijken en acceptatiecriteria nodig. - UAT-feedback moet traceerbaar gekoppeld zijn aan requirements, taken of releasebeslissingen. - Rollback-plannen moeten vóór release beschikbaar en beoordeeld zijn. Missing information: - Welke rollen en permissies moeten binnen de pipeline worden ondersteund? - Welke artefacten zijn verplicht per fase, zoals intakeformulier, requirements, testresultaten en releaseplan? - Welke criteria bepalen of UAT-feedback blokkerend is voor release? - Moet de pipeline integreren met bestaande tools voor tickets, repositories, CI/CD of incidentmanagement? Requirements: - critical functional: Structured pipeline (open) Agent tasks: - #1 backend: Agent backend should complete "Generate executable task plan". Acceptance criteria: Record is visible and auditable. (ready) Feedback: none recorded Releases: none recorded Readiness: 86% production ready Next constraint: Release: No release registered yet. Next action: Map dependencies Review queue: - high: Draft first release - The project looks delivery-ready, but no release bundle has been registered. - medium: Map dependencies - Work nodes exist, but ordering and blocking risks have not been mapped. Release decision: release blocked: Resolve high-priority review items before approving or registering a production release. ## Instructions 1. Start from the review queue and high-severity feedback. 2. Reproduce or inspect the failing behavior before editing. 3. Keep the fix scoped and add focused tests when practical. 4. Verify the affected route or workflow after the fix. ## Required Output - State what changed or what was found. - Include verification performed. - List remaining risks or next recommended step.
Use this when an agent should prepare or review release metadata and rollback readiness.
# Prepare release review for this project ## Project Context Project: VentureOS Product Factory Description: Demo project that turns a customer idea into an auditable development execution plan. Source type: project_brief Product summary: VentureOS Product Factory is een demo-project dat een klantidee omzet in een controleerbaar ontwikkel- en uitvoeringsplan. De huidige staat is agent_plan en de beschikbare input bestaat vooral uit een projectbrief voor een gestructureerde pipeline van intake tot release, inclusief UAT-feedback en rollback-voorbereiding. Goals: - Definieer een end-to-end workflow van intake, planning, uitvoering, UAT, release en rollback-voorbereiding. - Leg per fase auditable beslismomenten, artefacten en statusovergangen vast. - Neem UAT-feedback expliciet op als stap die releasebeslissingen kan blokkeren of terugsturen naar uitvoering. - Beschrijf rollback-voorbereiding als verplicht onderdeel vóór release. Target users: - Product managers die klantideeën willen vertalen naar uitvoerbare ontwikkelplannen. - Development leads die een gestructureerde delivery-pipeline nodig hebben. - QA- en UAT-stakeholders die feedback en acceptatiecriteria willen vastleggen. - Operations- of release-managers die rollback-voorbereiding moeten borgen. Risks: - De projectbrief bevat nog weinig detail, waardoor scope, datamodel en integratiepunten onvoldoende scherp zijn. - Zonder duidelijke UAT-criteria kan feedback subjectief worden en releases vertragen. - Rollback-voorbereiding kan te laat in het proces worden opgepakt als deze niet als harde release-gate wordt gemodelleerd. - Auditability kan incompleet zijn als beslissingen, feedback en statuswijzigingen niet consequent worden vastgelegd. Assumptions: - De pipeline moet meerdere fasen ondersteunen van eerste intake tot productie-release. - Elke fase heeft eigen outputs, verantwoordelijken en acceptatiecriteria nodig. - UAT-feedback moet traceerbaar gekoppeld zijn aan requirements, taken of releasebeslissingen. - Rollback-plannen moeten vóór release beschikbaar en beoordeeld zijn. Missing information: - Welke rollen en permissies moeten binnen de pipeline worden ondersteund? - Welke artefacten zijn verplicht per fase, zoals intakeformulier, requirements, testresultaten en releaseplan? - Welke criteria bepalen of UAT-feedback blokkerend is voor release? - Moet de pipeline integreren met bestaande tools voor tickets, repositories, CI/CD of incidentmanagement? Requirements: - critical functional: Structured pipeline (open) Agent tasks: - #1 backend: Agent backend should complete "Generate executable task plan". Acceptance criteria: Record is visible and auditable. (ready) Feedback: none recorded Releases: none recorded Readiness: 86% production ready Next constraint: Release: No release registered yet. Next action: Map dependencies Review queue: - high: Draft first release - The project looks delivery-ready, but no release bundle has been registered. - medium: Map dependencies - Work nodes exist, but ordering and blocking risks have not been mapped. Release decision: release blocked: Resolve high-priority review items before approving or registering a production release. ## Instructions 1. Check the release decision, blockers and recommendations first. 2. Confirm version, environment, commit SHA, prompt snapshot and agent snapshot traceability. 3. Do not approve release work while high-priority blockers remain. 4. Generate or verify rollback instructions for the latest release. ## Required Output - State what changed or what was found. - Include verification performed. - List remaining risks or next recommended step.
Prompt exports persisted as first-class build-pack records, linked back to saved artifact snapshots.
No dedicated build-pack records
Save a prompt snapshot to create a first-class build-pack record outside documentation logs.
Saved prompt snapshots are stored in project documentation logs and can be reused as stable agent handoff artifacts.
No saved prompt snapshots
Use Save prompt snapshot on any generated prompt to store a reusable audit record.
Exact duplicate prompt snapshots are grouped by markdown title and content hash so one version can stay active while duplicates are rejected.
No duplicate prompt snapshots
Saved prompt exports are currently unique by markdown title and content hash.
Compare generated prompts against the latest saved snapshot with the same markdown title.
Build prompt
Cursor rules export
Codex execution prompt
Claude Code handoff prompt
Database planning pack
API planning pack
UI planning pack
Test plan pack
Release checklist pack
Review prompt
Bugfix prompt
Release prompt