Sharing my CLAUDE.md for the Second Brain project. # Second Brain A personal system that reads my material and tells me what's in it. Right now it reads documents from the `inbox/` folder and prints a one-line summary of each (Claude or Gemini, selectable in `config/`). See `README.md` for the broader goal and roadmap. ## How to engineer this project ### 1. Think before coding State your assumptions out loud instead of acting on them silently. If a request could be read multiple ways, lay out the options and let me choose — don't pick one on your own. If a simpler approach exists, say so before building the complex one. When something is unclear, stop and ask rather than guess. ### 2. Simplicity first Write the least code that solves the problem. No features I didn't ask for, no abstractions for something used once, no configuration I didn't request, no error handling for cases that can't happen. If it's 200 lines and 50 would do, write the 50. ### 3. Surgical changes Change only what the task requires. Don't tidy nearby code, don't reformat, don't refactor what isn't broken. Match the existing style even where you'd write it differently. If you spot unrelated dead code, mention it — don't delete it. Every line you change should trace back to something I asked for. ### 4. Goal-driven execution Turn each task into a verifiable goal before you start. "Add validation" means "write tests for the invalid inputs, then make them pass." For anything with more than one step, give me a short plan with a check against each step, then work until every check passes. ## Project structure - `inbox/` — source material to read - `config/` — settings (YAML) - `lib/` — reusable logic (LLM provider calls, etc.) - `scripts/` — entry points (executors) - `docs/` — specs - `.venv/` — Python dependencies. Record new ones in `requirements.txt` Add new structure or abstractions only when needed (don't extract something used only once).

Terminal output from the front door script — it reads each file in my inbox and prints a one-line summary. Note: I couldn't get the Claude API billing set up, so I ran it with the Gemini model I have configured instead. Same script, just a different provider. ai_strategy_1.txt: AI is primarily creating "red ocean" markets, characterized by intense competition and differentiation challenges, rather than the "blue ocean" opportunities of previous tech shifts, because AI often accelerates existing products, lacks a new distribution channel (so far), and favors capital-richincumbents who are responding quickly. ai_strategy_2.txt: AI is fundamentally altering competitive dynamics by decreasing switching costs, increasing the importance of proprietary data, introducing new platform risks, accelerating product imitation, and making go-to-market and distribution paramount. ai_strategy_3.txt: AI is rapidly transforming customer expectations by enabling products to be more personalized, automated, immediate, and context-aware, fundamentally rewriting the rules of product-market fit. ai_strategy_4.txt: The accelerating pace of AI innovation requires product leaders to abandon annual strategic planning in favor of more frequent, agile reassessments to stay competitive. ai_strategy_5.txt: The AI Strategy Compass is a framework designed to help navigate AI strategy chaos by focusing on four key elements: current location, market strategy, product strategy, and execution strategy.

**Product Name: GitHub Copilot** **1. What is the real job this product solves?** Not what the AI does technically, but what the user actually needs. The real job this product solves is increasing the speed of code generation during the coding (implementation) phase. Focusing on engineers: When users move from code design to implementation, they spend a significant amount of time on: - How to use frameworks (React, Next.js, FastAPI, etc.) - Language syntax - Coding best practices - Algorithm selection and implementation details Although engineers may understand these concepts when reading documentation, they still need to constantly refer back to docs while actually writing code. This is one of the most time-consuming parts of coding. Keeping all these rules in mind while coding quickly is difficult even for senior engineers. This is where GitHub Copilot comes in. GitHub Copilot understands common coding patterns, best practices, and algorithms, and assists engineers during implementation. As a result, engineers can write code significantly faster. In this way, GitHub Copilot improves engineer productivity by accelerating code generation during the coding phase. **2. How does the system stay grounded?** GitHub Copilot is a coding assistance tool and is trained on a large corpus of publicly available code on GitHub. It is primarily designed to handle coding-related tasks and does not aim to provide strong grounding guarantees. In practice, grounding is relatively weak: all judgment and validation of the generated code is delegated to the user. The engineer is responsible for deciding whether the output is correct, appropriate, or safe to use. **3. What context does the model receive?** The model receives context such as: - The current code - The folder / repository structure - User prompts - Code learned during pre-training from GitHub Additionally, when users explicitly describe how they are trying to solve a problem, this information further improves the relevance and quality of the generated code.

**Product Link** https://www.skool.com/justanotherpm/week-1-activity-2-personal-inventory?p=72733c15 **Total Score: 11 / 15** While this product does not rely on proprietary training data, it has a clear justification for using AI because it focuses on interpretation rather than prediction or automation. **Score Breakdown** 1. Data Readiness – 1 / 5 At this stage, there is not enough historical or labeled data to train or improve a model. Therefore, a score of 1 is appropriate under the standard definition of Data Readiness. However, this product does not assume an AI system that learns from examples to optimize accuracy. Instead, it leverages the LLM’s existing knowledge of human cognition, reflection, and learning behavior to interpret user-generated text in real time. User journals are not treated as training data. They function as contextual input for joint interpretation, enabling deeper and more personalized introspection rather than model improvement. 2. Output Type – 5 / 5 The output is inherently subjective and judgment-based, with no single correct answer. The value lies in surfacing patterns, points of tension, and meaningful questions from journal entries. This is an “it depends” type of problem, where interpretation and perspective matter more than deterministic correctness. This aligns strongly with the strengths of LLMs. 3. Error Tolerance – 5 / 5 The AI serves only to provide interpretations and suggestions. It does not execute actions or enforce decisions. All final decisions and actions remain with the user. As a result, even if an interpretation is imperfect, it can be ignored, revised, or reinterpreted, and the risk of causing serious harm is low. Compared to rule-based or autonomous systems, the impact of errors is highly limited.

**Product Link** https://www.skool.com/justanotherpm/week-1-activity-2-personal-inventory?p=1a246f12 **LLMs** LLMs are essential for this product. User journals are written in free-form text or voice and contain strong contextual, emotional, and intentional signals. These characteristics make rule-based processing insufficient. Core functionalities such as daily summarization, theme extraction, weekly reflection report generation, and the creation of reflective questions all require semantic understanding and flexible interpretation of language. In addition, the product needs to organize how daily journal entries relate to user-defined goals. This requires interpreting text as contextual meaning rather than applying fixed rules or keyword matching, making an LLM a fundamental building block. **RAG** RAG is also an important building block. All generated outputs are based on the user’s own past and present journal data rather than general or external knowledge. To achieve this, the system must retrieve relevant information such as historical journal entries, recent summaries, and currently defined goals from a database and inject them into the generation process. This ensures that reflections are grounded in the user’s actual history and current context. Because retrieval and generation are tightly coupled in this workflow, a retrieval-augmented generation architecture is well suited to the product’s requirements. **Embeddings** Embeddings play an important role as well. Users often express similar thoughts, emotions, or ideas using different wording across days or weeks. To detect recurring themes and longer-term patterns, the system must capture semantic similarity instead of relying on exact keyword matches. Embeddings enable meaning-based comparison across differently worded journal entries, allowing related content to be grouped and analyzed even when surface-level expressions vary. This semantic layer is essential for identifying trends and shifts over time.

@Sid Arora Based on your advice, we revisited both the **feature set** and the **KPIs**, and simplified the structure. **On the feature side**, the product is organized as follows: * **Daily** * Text or voice journaling to capture daily thoughts and actions * Free-form goal setting, shown alongside daily entries as a reference point * **Weekly / Monthly** * Aggregation of journal entries over time * Organization and summarization of recurring themes and trends * Visibility into how thinking and behavior patterns change across periods * **Insights** * Lightweight insights focused on repeated themes and patterns * No recommendations or prescriptive elements in the initial phase Overall, the flow is intentionally simple: **daily capture → periodic organization → lightweight pattern visibility**. **On the KPI side**, we avoid directly scoring growth or success. Instead, we look at minimal proxy signals to confirm two things: whether the product is being used consistently, and whether the output resonates at all. * Usage-related indicators: * Access frequency * Journal entry rate * Streaks * Weekly reflection open rate * For AI output specifically: * A simple reaction to weekly reflections indicating whether there was a realization or not The goal here is not to judge awareness or behavior, nor to have the AI determine growth, but to confirm that the reflection experience itself is functioning and sustainable. This structure keeps the MVP lightweight, avoids heavy assumptions around data collection or integrations, and stays close to the reflective-mirror role you described.

Here’s a concrete view of the **product functionality we’re currently considering**, focusing purely on *what the product does*. --- ## Product Features (Functionality Only) ### 1. Daily Journaling (Text / Voice) * Users can freely capture thoughts and actions via text or voice * No scoring, evaluation, or judgment * Designed for low-friction, everyday use --- ### 2. Goal Setting (Optional, Flexible) * Users can define goals in free text * Numeric or measurable goals are optional * Goals can be updated or redefined at any time --- ### 3. AI-Based Organization & Summarization * AI summarizes daily journal entries * Extracts and organizes themes over time * Focuses on structuring, not advising --- ### 4. Weekly Reflection Reports * Automatically generated weekly summaries * Highlights: * Recurring themes * Patterns in thinking and behavior * Differences from previous weeks * Includes reflective questions (no recommendations) --- ### 5. Monthly Reflection Summaries * Aggregation of weekly reflections * Long-term theme visualization * Supports optional goal redefinition --- ### 6. Lightweight User Feedback Signal * Simple reaction to weekly reports (e.g. “I had a realization”) * No comments or ratings required --- ### 7. Progressive Insight Depth (Phased) * Initial focus: capture → summarize → reflect * Insights remain descriptive * Recommendations intentionally deferred to later phases