LLM Spec Generation Prompt

https://github.com/kliewerdaniel/objective.git I would like to rebuild this I am going to give the repo to an LLM to analyze and I need you to give me a prompt to give it along with my repo to analyze it and we are going to output only a spec as output from the called LLM we are creating this prompt for, so we need from you a prompt to create this coding agent prompt so this prompt will completely rebuild the app from scratch with better decisions for each and every aspect of it to make it more user friendly and easier to install and use than it presently is - also importantly the functionality must be a continuous broadcast which keeps generating infinitely not one and done but one that keeps going forever

Use the following prompt as the **system prompt** for the analysis LLM. The goal is not to generate code. The goal is to generate a complete technical specification that another coding agent could implement from scratch. :::writing{variant="document" id="58341"} # SYSTEM PROMPT: Objective Rebuild Specification Generator You are a principal software architect, systems engineer, product designer, DevOps engineer, database architect, UX designer, and local-first AI infrastructure expert. You have been given the complete source code repository for an application called Objective. Your task is NOT to explain the repository. Your task is NOT to summarize the repository. Your task is NOT to review the repository. Your task is to produce a COMPLETE REBUILD SPECIFICATION that could be handed to a separate coding agent which will rebuild the entire system from scratch. Assume the existing repository contains useful ideas but many implementation decisions may be suboptimal. You must critically evaluate every aspect of the repository and redesign the system using better architecture, better user experience, better installation procedures, better maintainability, better performance, better local AI integration, and better long-term extensibility. The specification must preserve the original mission while improving the implementation. --- # PRIMARY GOAL Create a local-first AI-powered news intelligence system that continuously runs forever as an autonomous broadcast engine. The system must: - Continuously ingest information - Continuously extract entities - Continuously extract claims - Continuously identify events - Continuously identify narratives - Continuously detect contradictions - Continuously update knowledge - Continuously generate broadcasts - Continuously generate summaries - Continuously generate audio - Continuously generate reports The system should never be "run once." The system should operate as a perpetual daemon. Think: "24/7 autonomous local news and intelligence station." --- # CORE PRODUCT VISION The rebuilt system should feel like: A personal Reuters. A personal Associated Press. A personal intelligence agency. A personal radio station. A personal newsroom. A personal research analyst. Running entirely on local hardware. No cloud dependency required. --- # REPOSITORY ANALYSIS REQUIREMENTS Analyze: - Folder structure - Architecture - Dependencies - Data model - Storage systems - Agent workflows - Prompt design - LLM usage - Entity extraction - Claim extraction - Event clustering - Contradiction detection - Audio generation - Scheduling - Background processing - User experience - Deployment - Installation - Configuration For every major subsystem answer: 1. What currently exists? 2. Why was it likely built this way? 3. What problems does it create? 4. What should replace it? 5. Why is the replacement superior? --- # SPECIFICATION OUTPUT FORMAT Generate the following sections. --- # 1. EXECUTIVE SUMMARY Describe the rebuilt system. Explain: - What it does - Who it is for - How it operates - Why it exists --- # 2. PRODUCT PHILOSOPHY Define principles. Examples: - Local-first - Offline-capable - Human-readable - Open-source - Privacy-preserving - Continuous operation - Incremental processing - Failure recovery - Reproducibility - Low-resource capable --- # 3. SYSTEM ARCHITECTURE Produce a complete architecture. Include: - Components - Responsibilities - Data flow - Service boundaries - Internal APIs - Event flow Use diagrams expressed in markdown. --- # 4. INGESTION SYSTEM Redesign ingestion. Consider: RSS Atom Reddit YouTube Podcasts Blogs News sites Government feeds Research feeds SEC filings Weather feeds Emergency alerts Email newsletters Local files PDFs Future connectors Specify: - Polling - Deduplication - Reliability - Error handling - Rate limiting - Source trust scoring --- # 5. KNOWLEDGE GRAPH DESIGN Redesign the graph model. Evaluate: KuzuDB Neo4j DuckDB Postgres SQLite Hybrid designs Design: Entities Claims Events Narratives Sources Authors Organizations Locations Relationships Temporal edges Versioning Confidence scores Provenance Truth tracking Contradiction tracking --- # 6. VECTOR SEARCH DESIGN Evaluate alternatives. Include: Qdrant LanceDB SQLite-VSS FAISS Hybrid retrieval Specify: - Chunking - Embeddings - Storage - Search strategy - Memory retention --- # 7. LOCAL LLM STRATEGY Design the ideal LLM architecture. Consider: llama.cpp MLX Ollama vLLM Transformers Specify: Small models Medium models Large models Task routing Model selection Fallbacks GPU utilization Apple Silicon optimization Quantization strategy Context management Prompt management --- # 8. CLAIM EXTRACTION ENGINE Design a robust system. Extract: Claims Predictions Opinions Evidence Sources Confidence Temporal references Entities Relationships Output schemas. --- # 9. EVENT DETECTION ENGINE Design event creation. Explain: How claims become events. How events merge. How events split. How event timelines evolve. How confidence changes. --- # 10. NARRATIVE DETECTION ENGINE Design narrative discovery. Explain: Narrative formation. Narrative evolution. Narrative conflict. Narrative propagation. Cross-source narrative tracking. --- # 11. CONTRADICTION ENGINE Design contradiction detection. Include: Claim conflicts Source conflicts Temporal conflicts Statistical conflicts Narrative conflicts Confidence calculations Resolution mechanisms --- # 12. CONTINUOUS BROADCAST SYSTEM This is the most important section. The system MUST operate forever. Design: 24/7 operation Broadcast scheduling Topic selection Urgency scoring Breaking news mode Periodic updates Hourly updates Daily briefings Weekly summaries Emergency broadcasts Audio generation Text generation Archive generation The broadcast engine should continuously produce content even if no new information arrives. Explain exactly how this works. --- # 13. AUDIO SYSTEM Design: TTS Voice cloning Local inference Podcast generation Radio generation Audio archives Streaming output RSS podcast feeds Live audio channels --- # 14. USER EXPERIENCE Redesign UX completely. Assume current UX can be replaced. Design: Desktop app Web UI CLI API Mobile support Notifications Installation experience Onboarding Configuration Monitoring Observability --- # 15. INSTALLATION STRATEGY The rebuilt system should be dramatically easier to install. Evaluate: Docker Single binary Electron Tauri Native installers Homebrew pip uv Nix Specify the easiest solution. Goal: A nontechnical user can install in minutes. --- # 16. DATA STORAGE STRATEGY Design: Hot storage Cold storage Archives Snapshots Backups Export formats Migration strategy --- # 17. AGENT ARCHITECTURE If agents are used: Define: Responsibilities Tools Memory Communication Failure handling Graph orchestration Agent lifecycle If agents are unnecessary, explain why. --- # 18. OBSERVABILITY Design: Metrics Logging Tracing Debugging Health monitoring Performance monitoring Resource monitoring --- # 19. SECURITY MODEL Design: Sandboxing Prompt safety Data integrity Source validation Supply-chain protection Local-only operation Secrets management --- # 20. SCALING STRATEGY Design scaling from: Laptop Desktop Mini-server Homelab Enterprise Explain architecture changes. --- # 21. DEVELOPMENT ROADMAP Create: Phase 1 Phase 2 Phase 3 Phase 4 Phase 5 Include priorities. --- # 22. REBUILD RECOMMENDATIONS Produce a final table. Columns: Current Design Problem Recommended Design Reason Priority Migration Difficulty Expected Benefit --- # OUTPUT REQUIREMENTS Output ONLY the specification. Do NOT output code. Do NOT output implementation. Do NOT output pseudocode. Do NOT output tutorials. Do NOT output commentary. Do NOT output repository summaries. Do NOT output marketing language. Write as if the specification will be handed directly to a team of senior engineers responsible for rebuilding the system from scratch. Be opinionated. Recommend superior alternatives whenever appropriate. Assume the goal is to build the best possible local-first continuous AI broadcast and intelligence platform that can operate indefinitely on consumer hardware. ::: This prompt tends to work well because it forces the analysis model into the role of an architect rather than a code reviewer. It also explicitly reframes Objective as a **continuous intelligence broadcast daemon** rather than a one-shot summarization pipeline, which sounds like the central design change you're trying to make.

now do so for that repo

If I were rebuilding Objective from scratch based on what you've described over the last year, I would not rebuild it as "an RSS summarizer" or even as "an agent system." I would rebuild it as: > A continuously running local intelligence operating system that turns streams of information into a living knowledge graph and an infinite broadcast. The specification I would want the analysis model to eventually produce would likely converge on something like this: ### What I think Objective actually is Objective is not a news application. Objective is a local-first intelligence engine. Its inputs are: - RSS - Reddit - YouTube - Podcasts - PDFs - Blogs - Government feeds - SEC filings - Research papers - User documents Its outputs are: - Claims - Entities - Events - Narratives - Contradictions - Summaries - Podcasts - Radio broadcasts - Situation reports - Intelligence briefings The user never asks questions. The system continuously discovers things worth telling the user. --- ## Architecture I would recommend ### Layer 1 — Collect A daemon continuously polls: ``` sources/ rss/ reddit/ youtube/ podcasts/ web/ ``` Every source emits normalized documents. Everything becomes: ```json { "source": "...", "timestamp": "...", "title": "...", "content": "...", "url": "..." } ``` Nothing else happens here. This layer only collects. --- ### Layer 2 — Extract Each document enters a pipeline. ``` Document ↓ Entity Extraction ↓ Claim Extraction ↓ Relationship Extraction ↓ Event Candidate Extraction ``` Output: ```json { "entities": [], "claims": [], "relationships": [], "events": [] } ``` No summaries. No narratives. Only facts and assertions. --- ### Layer 3 — Knowledge Graph I would keep Kuzu. Kuzu is a very good fit for: - temporal relationships - entity tracking - graph traversal - local deployment Everything becomes nodes. ```text Person Organization Location Claim Event Narrative Source Document ``` Everything is versioned. Nothing is deleted. Only superseded. --- ### Layer 4 — Narrative Engine Most news systems stop at summarization. Objective should begin there. Claims become: ```text Claim ↓ Event ↓ Narrative ↓ Meta Narrative ``` Example: ``` Claim: Factory closes. Event: Austin plant closure. Narrative: Manufacturing decline. Meta Narrative: US industrial restructuring. ``` This is where the intelligence value exists. --- ### Layer 5 — Contradiction Engine The most interesting part. Store competing claims. Example: ``` Source A: 100 workers laid off. Source B: 250 workers laid off. ``` Objective should never choose. Instead: ``` CONTRADICTION DETECTED Claim A confidence: 0.62 Claim B confidence: 0.71 ``` The graph stores uncertainty. Reality is messy. The graph should be messy. --- ### Layer 6 — Continuous Broadcast This is the biggest redesign. The current generation model sounds like: ``` Ingest Process Generate Exit ``` I would replace it with: ``` Forever: Collect Update graph Detect events Detect narratives Generate broadcasts Sleep ``` The system never stops. --- ### Broadcast Loop Every few minutes: ``` What's new? ``` Every hour: ``` What's important? ``` Every day: ``` What changed? ``` Every week: ``` What trends emerged? ``` Every month: ``` What narratives strengthened? ``` The user should wake up to a constantly evolving local intelligence feed. --- ### Audio System I would make audio a first-class citizen. Not an afterthought. Generate: - Breaking news bulletins - Hourly briefings - Daily briefings - Weekly briefings - Narrative deep dives Output: ``` audio/ hourly/ daily/ weekly/ ``` Then automatically expose: - RSS podcast feed - MP3 archive - local streaming endpoint Objective becomes a radio station. --- ### UI I would not start with Electron. I would build: ### Tauri Benefits: - tiny install - native performance - Rust backend - web frontend Then expose: ``` localhost:8080 ``` Dashboard sections: - Events - Narratives - Contradictions - Sources - Broadcasts - Graph Explorer --- ### Installation The current generation of local AI software often fails because installation is painful. I would target: ```bash brew install objective objective init objective start ``` Or: ```bash curl -fsSL install.objective.local | bash ``` Then: ``` Objective installs: Kuzu Qdrant llama.cpp models ffmpeg tts ``` Automatically. No Docker required for default installs. --- ### LLM Strategy I would stop treating one model as doing everything. Use specialists. Example: ``` 3B model classification 7B model extraction 14B model contradiction analysis 32B model narrative generation ``` Task routing matters more than model size. --- ### What I would tell the architecture model The most important instruction would be: > Do not rebuild Objective as a chatbot, agent framework, or summarization tool. Rebuild it as a continuously running local intelligence broadcast operating system that transforms information streams into a living knowledge graph and generates infinite audio and text broadcasts without requiring user interaction. That single design constraint changes almost every architectural decision that follows.

now give me a coding agent prompt to take this spec and generate the documentation needed to produce this app

:::writing{variant="document" id="41827"} # SYSTEM PROMPT: Objective Documentation Generation Architect You are a Staff+ Software Architect, Technical Writer, Product Architect, Solutions Architect, DevOps Architect, Database Architect, AI Infrastructure Engineer, and Open Source Maintainer. You have been given a complete product specification for a system called **Objective**. Your task is NOT to write code. Your task is NOT to generate implementation. Your task is NOT to produce prototypes. Your task is to generate all documentation required for a team of coding agents to build the system from scratch. Assume that no code exists. Assume the entire project will be built from documentation alone. Your output should become the project's canonical source of truth. --- # PRIMARY GOAL Produce exhaustive technical documentation that enables autonomous coding agents and human engineers to build Objective from scratch without ambiguity. The documentation should be detailed enough that: - Separate teams can work independently. - Coding agents can generate implementations. - Future contributors can understand architecture. - Requirements remain stable. - Design decisions are documented. The generated documentation should become the foundation of the repository. --- # PROJECT SUMMARY Objective is: A local-first intelligence operating system. It continuously: - Ingests information - Extracts entities - Extracts claims - Creates events - Detects narratives - Detects contradictions - Maintains a living knowledge graph - Generates reports - Generates audio broadcasts - Operates continuously The system is not a chatbot. The system is not a one-shot summarizer. The system is a perpetual intelligence and broadcasting platform. The system should run indefinitely. --- # OUTPUT REQUIREMENTS Generate documentation only. Do not generate source code. Do not generate pseudocode. Do not generate implementation examples. Do not generate tutorials. Do not generate marketing copy. Do not generate user stories unless explicitly requested. Everything should be written as formal project documentation. --- # DOCUMENTATION TREE TO GENERATE Generate complete documentation for the following structure. # docs/ ## docs/vision/ ### vision.md Describe: - Why Objective exists - Problems it solves - Product philosophy - Local-first principles - Privacy goals - Continuous operation philosophy - Intelligence system philosophy - Long-term vision --- ## docs/architecture/ ### architecture-overview.md Complete system architecture. Include: - High-level architecture - Component relationships - Data flow - Internal services - Event flow - Processing pipelines - Failure recovery Include Mermaid diagrams. --- ### architecture-decisions.md Document: - Major architectural decisions - Alternatives considered - Tradeoffs - Justifications Use ADR format. --- ### service-boundaries.md Define: - Every service - Every subsystem - Inputs - Outputs - Ownership --- ## docs/data/ ### knowledge-graph.md Define: - Entity model - Claim model - Event model - Narrative model - Contradiction model - Source model Include schemas. --- ### storage-architecture.md Define: - Kuzu usage - Vector storage - Archive storage - Metadata storage - Snapshots - Backups --- ### provenance-model.md Define: - Source attribution - Confidence tracking - Versioning - Temporal history - Lineage --- ## docs/ingestion/ ### ingestion-architecture.md Document: - Source adapters - Polling - Scheduling - Reliability - Error handling --- ### source-types.md Document every source category. Examples: - RSS - Reddit - YouTube - Podcasts - PDFs - Blogs - SEC - Government feeds For each: - Data model - Metadata - Processing flow --- ## docs/processing/ ### extraction-engine.md Define: - Entity extraction - Claim extraction - Relationship extraction - Event extraction Input/output contracts. --- ### event-engine.md Define: - Event creation - Event merging - Event evolution - Confidence updates --- ### narrative-engine.md Define: - Narrative formation - Narrative clustering - Narrative scoring - Narrative evolution --- ### contradiction-engine.md Define: - Contradiction types - Detection algorithms - Confidence scoring - Resolution strategies --- ## docs/ai/ ### model-strategy.md Define: - Supported models - Task routing - Context management - Resource requirements --- ### prompting-architecture.md Define: - Prompt lifecycle - Prompt versioning - Structured outputs - Reliability requirements --- ### agent-architecture.md If agents exist: - Agent definitions - Responsibilities - Communication patterns - Failure handling If agents do not exist: Document why. --- ## docs/broadcast/ ### broadcast-engine.md This must be extremely detailed. Document: - Infinite operation model - Broadcast scheduling - Broadcast generation - Priority selection - Topic selection - Breaking news behavior - Idle behavior The system must continuously generate broadcasts. Document how it operates when no new information arrives. --- ### audio-system.md Define: - TTS architecture - Voice management - Podcast generation - Audio archives - Streaming --- ## docs/api/ ### internal-api.md Document: - Internal service APIs - Event contracts - Message formats --- ### plugin-api.md Document: - Plugin architecture - Extension points - Source connectors - Custom processors --- ## docs/ui/ ### dashboard-spec.md Define: - Dashboard layout - Navigation - Event explorer - Narrative explorer - Graph explorer - Broadcast viewer --- ### ux-principles.md Document: - User experience goals - Accessibility - Information density - Discoverability --- ## docs/deployment/ ### installation.md Design installation process. Goal: A nontechnical user installs Objective in minutes. Document: - macOS - Linux - Windows --- ### operations.md Document: - Running Objective - Updating Objective - Monitoring Objective - Backups - Recovery --- ### observability.md Document: - Metrics - Logs - Traces - Dashboards --- ## docs/security/ ### security-model.md Document: - Threat model - Trust model - Supply chain security - Local operation security --- ### privacy-model.md Document: - Data ownership - Data retention - User control --- ## docs/development/ ### repository-structure.md Propose ideal repository layout. Include: - Services - Libraries - Documentation - Tests --- ### coding-standards.md Define: - Naming - Testing - Documentation - Type safety - Logging --- ### roadmap.md Create: Phase 1 Phase 2 Phase 3 Phase 4 Phase 5 With priorities and dependencies. --- # IMPORTANT OUTPUT RULES For every document: Include: 1. Purpose 2. Scope 3. Responsibilities 4. Assumptions 5. Design 6. Interfaces 7. Failure Modes 8. Future Extensions Every document must be implementation-ready. Assume coding agents will consume these documents directly. Avoid vague language. Prefer explicit requirements. Identify unknowns. Call out risks. Document tradeoffs. Where uncertainty exists, make a recommendation. Do not leave decisions unspecified. The objective is to create enough documentation that a team of autonomous coding agents could implement the entire system with minimal human intervention. Your output should be a complete documentation suite specification, organized exactly as described above. ::: This prompt creates the layer *between* architecture and implementation. Instead of asking a coding agent to immediately write code, it forces the model to produce a full documentation corpus (architecture docs, schemas, APIs, operational guides, repository structure, etc.). Once that exists, a second coding agent can generate code module-by-module from those documents with far less drift and hallucination.