@maggit/claude-workspace 0.1.1

package/assets/skills/readme/SKILL.md

@@ -0,0 +1,55 @@
+---
+name: readme
+description: "Generate or update a README.md for a project. Use when the user says /readme, asks to create a README, update project documentation, or add a project overview. Triggers: readme, README, project docs, project documentation, getting started guide, how to use."
+---
+
+# README Generator
+
+Generate a comprehensive, well-structured README for any project.
+
+## Workflow
+
+1. **Analyze the project:**
+   - Read `package.json`, `pyproject.toml`, `Cargo.toml`, `go.mod`, `Makefile`, or similar.
+   - Scan directory structure for major components.
+   - Check for existing README to update rather than replace.
+   - Identify the language, framework, and project type.
+
+2. **Gather information:**
+   - Project name and description from manifest files.
+   - Installation steps from lockfiles and config.
+   - Available scripts/commands from `package.json scripts`, `Makefile` targets, etc.
+   - Environment variables from `.env.example`, `.env.template`, or code references.
+   - License from `LICENSE` file.
+   - CI/CD configuration for badges.
+
+3. **Generate the README with these sections:**
+
+### Required Sections
+
+- **Title** — Project name, one-line description, badges (CI, coverage, license, version).
+- **Overview** — 2-3 sentences on what the project does and why it exists.
+- **Getting Started** — Prerequisites, installation, and first-run instructions.
+- **Usage** — Key commands, API examples, or configuration.
+
+### Optional Sections (include if relevant)
+
+- **Architecture** — High-level diagram or description for larger projects.
+- **Configuration** — Environment variables, config files.
+- **Development** — How to set up a dev environment, run tests, lint, build.
+- **Deployment** — How to deploy (if applicable).
+- **Contributing** — Guidelines for contributors.
+- **License** — License type and link.
+
+4. **If updating an existing README:**
+   - Preserve custom content the user has written.
+   - Update auto-detectable sections (install steps, commands, env vars).
+   - Flag sections that may be outdated.
+
+## Guidelines
+
+- Write for a developer who has never seen the project before.
+- Include copy-pasteable commands (with proper shell syntax).
+- Use real values from the project, not placeholder text.
+- Keep it concise — a README is a quick-start guide, not full documentation.
+- Match the tone and style of the existing project documentation.

package/assets/skills/rebase/SKILL.md

@@ -0,0 +1,59 @@
+---
+name: rebase
+description: "Help with git rebase operations, including squashing, reordering, and cleaning up commit history. Use when the user says /rebase, asks to rebase a branch, squash commits, clean up history, fixup commits, or reorganize their git log. Triggers: rebase, squash, fixup, clean up commits, reorder commits, interactive rebase."
+---
+
+# Rebase Assistant
+
+Guide and execute git rebase operations safely.
+
+## Workflow
+
+1. Assess the current state:
+   - `git status` — ensure working tree is clean (stash if needed).
+   - `git log --oneline -20` — show recent history.
+   - `git branch -vv` — identify tracking branch.
+2. Determine the rebase target:
+   - If user says "squash last N commits" → use `HEAD~N`.
+   - If user says "rebase onto main" → use `main` (or `master`).
+   - If user says "clean up" → find the merge base with the default branch.
+3. Plan the rebase:
+   - Show the user exactly which commits will be affected.
+   - Propose a plan (pick, squash, fixup, reword, drop).
+   - Get user confirmation before executing.
+4. Execute:
+   - For squashing: use `git rebase` with the appropriate flags.
+   - For rebase onto branch: `git rebase <target>`.
+   - IMPORTANT: never use `-i` flag as it requires interactive input. Instead use `git rebase` with `--autosquash`, environment variables like `GIT_SEQUENCE_EDITOR`, or sequential cherry-pick operations.
+5. Handle conflicts:
+   - Show conflicting files with `git diff --name-only --diff-filter=U`.
+   - Show each conflict with context.
+   - Suggest resolutions and apply with user approval.
+   - `git add <file>` then `git rebase --continue`.
+6. Verify the result:
+   - `git log --oneline` to show the new history.
+   - `git diff <original-ref>..HEAD` to confirm no content was lost.
+
+## Safety Rules
+
+- Always create a backup ref: `git branch backup-<branch>-<date>` before rebasing.
+- Never force-push without explicit user permission.
+- Warn if rebasing commits that are already pushed to a shared branch.
+- If rebase goes wrong, guide recovery with `git rebase --abort` or the backup branch.
+
+## Common Patterns
+
+**Squash last N into one:**
+```bash
+git reset --soft HEAD~N && git commit
+```
+
+**Rebase onto updated main:**
+```bash
+git fetch origin && git rebase origin/main
+```
+
+**Fixup a specific commit:**
+```bash
+git commit --fixup=<sha> && GIT_SEQUENCE_EDITOR=: git rebase --autosquash <sha>~1
+```

package/assets/skills/release/SKILL.md

@@ -0,0 +1,64 @@
+---
+name: release
+description: "Create release notes, prepare releases, and manage versioning. Use when the user says /release, asks to prepare a release, draft release notes, bump a version, create a git tag, or publish a GitHub release. Triggers: release, version bump, tag, release notes, ship it, cut a release."
+---
+
+# Release Manager
+
+Prepare releases with proper versioning, tags, and release notes.
+
+## Workflow
+
+1. Detect the current version:
+   - Check `package.json`, `pyproject.toml`, `Cargo.toml`, `version.txt`, or latest git tag.
+   - If no version found, ask the user.
+2. Determine the bump type:
+   - Analyze commits since last release using conventional commits.
+   - `BREAKING CHANGE` or `!` → major
+   - `feat` → minor
+   - `fix`, `perf`, `refactor` → patch
+   - Allow user override.
+3. Generate release notes:
+   - Group commits by category (same as changelog skill).
+   - Highlight breaking changes prominently at the top.
+   - Include contributor list via `git shortlog -sne <range>`.
+4. Prepare the release:
+   - Update version in manifest files (package.json, pyproject.toml, etc.).
+   - Update CHANGELOG.md if it exists.
+   - Create a git tag with `git tag -a v<version> -m "Release v<version>"`.
+5. Optionally create a GitHub release via `gh release create` if `gh` CLI is available.
+
+## Version Format
+
+Follow [Semantic Versioning](https://semver.org/): `MAJOR.MINOR.PATCH`
+
+- Pre-release: `v1.2.3-beta.1`
+- Build metadata: `v1.2.3+build.123`
+
+## Release Notes Template
+
+```markdown
+## v<version> - YYYY-MM-DD
+
+### Breaking Changes
+- Description
+
+### Features
+- Description
+
+### Bug Fixes
+- Description
+
+### Other Changes
+- Description
+
+### Contributors
+- @name (N commits)
+```
+
+## Guidelines
+
+- Always confirm the version bump with the user before making changes.
+- Never push tags or create GitHub releases without explicit permission.
+- If CI/CD config exists (`.github/workflows/`, `.gitlab-ci.yml`), mention relevant release pipelines.
+- Support `--dry-run` style behavior: show what would change before changing it.

package/assets/skills/release-plan/SKILL.md

@@ -0,0 +1,107 @@
+---
+name: release-plan
+description: "Create a release plan. Use when the user says /release-plan, asks to plan a release, create a rollout strategy, or document a deployment plan. Triggers: release-plan, release plan, rollout plan, deployment plan, launch plan, ship plan."
+---
+
+# Release Plan
+
+## Purpose
+
+Create a structured release plan that documents what is shipping, how to deploy it safely, and how to communicate changes to users. The plan serves as an operational checklist for the release process.
+
+## When to Use
+
+- Preparing a software release for deployment
+- Coordinating a launch across engineering, product, and marketing
+- Documenting the rollout strategy for a significant feature or version
+
+## Inputs
+
+- **Release name/version**: Identifier for this release
+- **Features and changes**: List of what is included
+- **Target release date**: When this should ship (optional)
+- **Audience**: Internal tool, B2B, B2C, open source, etc. (optional)
+- **Risk level**: Low, medium, or high based on scope of changes (optional)
+
+## Output Format
+
+Produce a markdown document with the following sections:
+
+### Header Block
+
+```
+# Release Plan: [Name / Version]
+**Target date**: [Date]
+**Release owner**: [Name or TBD]
+**Risk level**: [Low / Medium / High]
+**Status**: [Draft / In Review / Approved / Released]
+```
+
+### 1. Release Summary
+2-3 sentences describing the release at a high level. What is the headline?
+
+### 2. Features Included
+Bulleted list of features and changes, grouped by category:
+- **New features**: Entirely new capabilities
+- **Improvements**: Enhancements to existing functionality
+- **Bug fixes**: Issues resolved
+- **Internal changes**: Refactors, dependency updates, tooling
+
+### 3. Breaking Changes
+List any changes that will break existing behavior, APIs, or integrations. For each:
+- What changed
+- Who is affected
+- What they need to do
+
+If there are no breaking changes, state that explicitly.
+
+### 4. Migration Steps
+Step-by-step instructions for users or operators to transition:
+1. Pre-migration checklist (backups, notifications)
+2. Migration procedure
+3. Post-migration verification
+
+### 5. Rollout Strategy
+Define how the release will be deployed:
+- **Rollout method**: Big bang, percentage rollout, feature flags, canary
+- **Rollout phases**: Who gets it first and on what timeline
+- **Success criteria**: What signals confirm the release is healthy
+- **Monitoring**: What dashboards and alerts to watch
+
+### 6. Rollback Plan
+- Trigger conditions: What signals indicate a rollback is needed
+- Rollback procedure: Step-by-step instructions
+- Data considerations: Any data changes that complicate rollback
+- Communication: Who to notify if a rollback occurs
+
+### 7. Communication Plan
+| Audience | Channel | Message | Timing |
+|----------|---------|---------|--------|
+| Internal team | Slack | Release notification | Day of |
+| Users | Email / Changelog | What's new | Day of |
+| Affected users | Direct outreach | Breaking change notice | 1 week before |
+
+### 8. Pre-Release Checklist
+- [ ] All features code-complete and merged
+- [ ] QA sign-off obtained
+- [ ] Staging environment validated
+- [ ] Documentation updated
+- [ ] Changelog written
+- [ ] Rollback procedure tested
+- [ ] Stakeholder approval received
+- [ ] Monitoring and alerts configured
+
+## Example
+
+**Input**: "Plan the release for v2.4.0 which includes the new search feature, three bug fixes, and a database migration. Medium risk."
+
+**Output**: A release plan documenting the search feature and bug fixes, noting the database migration as the primary risk factor, defining a phased rollout (internal first, then 10% of users, then full), rollback steps that account for the migration (reverse migration script prepared), communication plan targeting both internal teams and end users, and a pre-release checklist tailored to the database migration requirements.
+
+## Guidelines
+
+- Scale the plan to the risk level -- a low-risk patch needs less ceremony than a major version
+- Always include a rollback plan, even for low-risk releases
+- Be specific about migration steps -- vague instructions cause incidents
+- Communication timing matters: notify about breaking changes well before the release
+- The pre-release checklist should be treated as a gate, not a formality
+- Include monitoring expectations so the team knows what "healthy" looks like post-release

package/assets/skills/requirements/SKILL.md

@@ -0,0 +1,77 @@
+---
+name: requirements
+description: "Gather and structure requirements from raw input. Use when the user says /requirements, asks to extract requirements, organize requirements from notes, or formalize feature requirements. Triggers: requirements, gather requirements, extract requirements, requirements doc, formalize requirements."
+---
+
+# Requirements Gathering
+
+## Purpose
+
+Extract, organize, and formalize requirements from unstructured conversations, notes, or rough ideas. Produce a clean requirements document that can feed into PRDs, engineering specs, or project plans.
+
+## When to Use
+
+- Processing raw meeting notes or stakeholder interviews into structured requirements
+- Consolidating scattered feedback into a single source of truth
+- Validating completeness of requirements before starting design or engineering
+
+## Inputs
+
+- **Raw material**: Conversation transcript, meeting notes, brainstorm output, or rough feature description
+- **Domain context**: What product or system this relates to (optional)
+- **Existing requirements**: Any previously documented requirements to build on (optional)
+
+## Output Format
+
+Produce a markdown document with the following sections:
+
+### 1. Summary
+A 2-3 sentence overview of what the requirements cover and their scope.
+
+### 2. Functional Requirements
+Numbered list of what the system must do. Each requirement should:
+- Start with "The system shall..." or "Users shall be able to..."
+- Be specific enough to test
+- Include a priority tag: `[P0]` `[P1]` `[P2]`
+
+### 3. Non-Functional Requirements
+Cover relevant quality attributes:
+- **Performance**: Response times, throughput targets
+- **Scalability**: Growth expectations
+- **Reliability**: Uptime, recovery objectives
+- **Security**: Access control, data protection
+- **Usability**: Accessibility standards, device support
+- **Compliance**: Regulatory or policy requirements
+
+### 4. Constraints
+List technical, business, or organizational constraints that limit solution options. Examples: must use existing database, must ship before Q3, budget cap of $X.
+
+### 5. Assumptions
+Explicitly state assumptions made while interpreting the raw input. Flag any that need stakeholder validation.
+
+### 6. Dependencies
+Identify external dependencies:
+- Other teams or services
+- Third-party APIs or tools
+- Prerequisite work that must complete first
+
+### 7. Acceptance Criteria
+For each major functional requirement, define clear pass/fail criteria using the format:
+- **Given** [context], **when** [action], **then** [expected result]
+
+### 8. Gaps and Open Questions
+List areas where the raw input was ambiguous, contradictory, or incomplete. Frame each as a question that needs an answer before requirements are final.
+
+## Example
+
+**Input**: A pasted Slack thread where a PM, designer, and engineer discuss adding team billing to a SaaS product.
+
+**Output**: A structured requirements document extracting: functional requirements (team admin can add seats, billing rolls up to a single invoice, prorated charges for mid-cycle changes), non-functional requirements (PCI compliance, 99.9% uptime for billing operations), constraints (must integrate with Stripe, cannot change existing individual billing flow), assumptions (teams are capped at 500 seats based on PM's comment), dependencies (Stripe Connect API, identity service for role management), acceptance criteria for each requirement, and flagged gaps (no mention of how to handle downgrades or what happens to data when a team is deleted).
+
+## Guidelines
+
+- Preserve the intent of the original input even when restructuring
+- Do not invent requirements -- if something is unclear, put it in Gaps
+- Distinguish between what was explicitly stated and what was inferred
+- Use consistent language and numbering for traceability
+- When the input contains conflicting statements, flag the conflict rather than picking a side

package/assets/skills/seo-brief/SKILL.md

@@ -0,0 +1,88 @@
+---
+name: seo-brief
+description: "Generate an SEO content brief. Use when the user says /seo-brief, asks to create an SEO brief, plan content for search, or optimize content strategy. Triggers: seo-brief, seo brief, seo content, content brief, keyword targeting, search optimization, content strategy."
+---
+
+# SEO Content Brief
+
+## Purpose
+
+Create a comprehensive content brief that guides a writer to produce a piece of content optimized for search engines while delivering genuine value to readers. The brief ensures content is strategically targeted and well-structured before writing begins.
+
+## When to Use
+
+- Planning a new blog post, article, or landing page targeting organic search
+- Briefing a content writer or freelancer on what to produce
+- Auditing existing content for SEO improvements
+
+## Inputs
+
+- **Target keyword or topic**: The primary search term to target
+- **Content type**: Blog post, guide, landing page, comparison, etc. (optional)
+- **Target audience**: Who this content is for (optional)
+- **Business goal**: What action the reader should take (optional)
+- **Competitors or references**: URLs of competing content to consider (optional)
+
+## Output Format
+
+Produce a markdown document with the following sections:
+
+### 1. Target Keyword
+- **Primary keyword**: The main keyword to optimize for
+- **Secondary keywords**: 3-5 related terms to incorporate naturally
+- **Long-tail variations**: 3-5 longer, more specific search queries
+
+### 2. Search Intent
+Identify the dominant search intent:
+- **Intent type**: Informational, navigational, transactional, or commercial investigation
+- **What the searcher wants**: One sentence describing the searcher's goal
+- **Content format expectation**: What format searchers expect (how-to guide, list, comparison table, etc.)
+
+### 3. Content Specifications
+- **Recommended title**: A working title (include primary keyword, under 60 characters)
+- **Meta description**: 150-160 characters summarizing the page for search results
+- **Recommended word count**: Based on the topic's depth requirements
+- **Tone**: Formal, conversational, technical, etc.
+
+### 4. Content Outline
+A detailed H2/H3 heading structure for the article:
+```
+## H2: Section Title
+   ### H3: Subsection
+   ### H3: Subsection
+## H2: Section Title
+```
+Include brief notes under each heading about what to cover.
+
+### 5. Key Points to Cover
+Bulleted list of specific facts, arguments, or angles the content must address. These are non-negotiable elements that make the content comprehensive.
+
+### 6. Internal Linking Suggestions
+- Pages on the site to link from this content
+- Pages on the site to link to from this content
+- Suggested anchor text for each link
+
+If site structure is unknown, provide guidance on types of pages to link (e.g., "link to your pricing page when mentioning plans").
+
+### 7. Call to Action
+- Primary CTA: What the reader should do after reading
+- CTA placement: Where in the content to position it
+- Supporting CTAs: Secondary actions (newsletter signup, related content)
+
+### 8. Competitive Notes
+Brief observations on what competing content does well and where this piece can differentiate. If no competitors were provided, suggest what to look for.
+
+## Example
+
+**Input**: "SEO brief for the keyword 'how to write a project proposal'"
+
+**Output**: A brief targeting the primary keyword with secondary keywords (project proposal template, proposal writing tips, project proposal example), informational intent analysis, a recommended title ("How to Write a Project Proposal: A Step-by-Step Guide"), a content outline covering (what a project proposal is, when you need one, step-by-step writing process, common mistakes, template/example), key points (include real examples, address both internal and client-facing proposals, cover budget and timeline sections), internal linking suggestions (link to project management tools, templates page), and CTA (download a project proposal template).
+
+## Guidelines
+
+- Prioritize search intent over keyword density -- the content must answer what the searcher is looking for
+- Keep the outline actionable: a writer should be able to produce the content from this brief alone
+- Include secondary keywords naturally in the outline -- do not force them
+- The meta description should compel clicks, not just contain keywords
+- Base word count recommendations on topic complexity, not arbitrary targets
+- Focus on creating content that is genuinely more useful than existing results

package/assets/skills/standup/SKILL.md

@@ -0,0 +1,48 @@
+---
+name: standup
+description: "Generate a standup report from recent git activity. Use when the user says /standup, asks for a standup update, daily summary, what they worked on yesterday, or a status report based on recent commits. Triggers: standup, daily update, what did I do, status report, yesterday's work, daily summary."
+---
+
+# Standup Report Generator
+
+Generate a concise standup report from recent git activity.
+
+## Workflow
+
+1. Identify the user:
+   - `git config user.name` and `git config user.email`.
+2. Determine the time range:
+   - Default: since last business day (skip weekends).
+   - Monday → since Friday.
+   - Other days → since yesterday.
+   - Allow user override (e.g., "last 3 days", "this week").
+3. Gather activity:
+   - Commits: `git log --author="<email>" --since="<date>" --pretty=format:"%h %s (%ar)" --all`
+   - Branches touched: `git branch --sort=-committerdate --format="%(refname:short) %(committerdate:relative)" | head -10`
+   - If multiple repos, offer to scan them.
+4. Summarize into standup format.
+
+## Output Format
+
+```markdown
+## Standup — YYYY-MM-DD
+
+### Yesterday
+- Worked on <feature/area>: <concise summary of commits>
+- Fixed <bug>: <summary>
+
+### Today
+- Plan to continue <work in progress>
+- [Suggested based on open branches and recent context]
+
+### Blockers
+- [Any merge conflicts, failing CI, or stale PRs detected]
+```
+
+## Guidelines
+
+- Group related commits into logical work items rather than listing each commit.
+- Use natural language, not commit hashes.
+- Keep it concise — a real standup is 30 seconds.
+- If `gh` CLI is available, include open PRs authored by the user.
+- Detect and mention any unfinished work (branches with no PR, uncommitted stashes).

package/assets/skills/storecontext/SKILL.md

@@ -0,0 +1,76 @@
+---
+name: storecontext
+description: "Store a context summary of the current session to ContextDB. Use when the user says /storecontext, asks to save context, log the session, store a summary, checkpoint the conversation, or persist what was discussed. Triggers: storecontext, store context, save context, log session, checkpoint, save progress, session summary."
+---
+
+# Store Context
+
+Capture a summary of the current conversation session and persist it as a Markdown file in `ContextDB/context/` for future reference by humans and LLM tools.
+
+## Workflow
+
+1. **Determine the summary window:**
+   - Check `ContextDB/context/` for the most recent existing summary file.
+   - If a previous summary exists, this new summary should cover everything **since that summary was written** (avoid duplicating what was already captured).
+   - If no previous summary exists, summarize the **entire session from the beginning**.
+
+2. **Gather what happened in the window:**
+   - What did the user ask for?
+   - What decisions were made?
+   - What was built, changed, or configured?
+   - What files were created, modified, or deleted?
+   - What problems were encountered and how were they resolved?
+   - Any open questions, next steps, or TODOs that remain?
+
+3. **Create the summary file:**
+   - **Directory:** `ContextDB/context/`
+   - **Filename:** `YYYY-MM-DD-HHMMSS-summary.md` using the current timestamp.
+     - Example: `2026-02-07-143022-summary.md`
+     - Include time (HHMMSS) so multiple summaries on the same day don't collide.
+   - Get the current timestamp via `date "+%Y-%m-%d-%H%M%S"` in bash.
+
+4. **Write the file using this structure:**
+
+```markdown
+# Session Summary — YYYY-MM-DD HH:MM
+
+## Overview
+<1-3 sentence high-level summary of what this session accomplished.>
+
+## What Was Done
+- <Concise bullet for each meaningful action, grouped logically.>
+- <Include file paths for anything created or modified.>
+
+## Decisions Made
+- <Any technical or design decisions, with brief rationale.>
+
+## Key Files
+| File | Action | Description |
+|------|--------|-------------|
+| `path/to/file` | created / modified / deleted | Brief note |
+
+## Open Items
+- <Anything unfinished, deferred, or flagged for follow-up.>
+- <Known issues or blockers.>
+
+## Context for Next Session
+<Paragraph aimed at a future Claude or human picking up where this left off. What should they know? What's the current state of things? What was the user's intent or direction?>
+```
+
+5. **Confirm to the user:**
+   - Show the filename and path.
+   - Give a one-line summary of what was captured.
+
+## Guidelines
+
+- Write for a future reader (human or LLM) who has **zero context** about this session.
+- Be specific: include file paths, command names, config values — not vague descriptions.
+- Keep it concise but complete. Aim for a summary that can be scanned in under 60 seconds.
+- Use the project's actual file paths relative to the repo root.
+- Do NOT include sensitive data (API keys, secrets, passwords) in the summary.
+- Do NOT duplicate content already captured in a previous summary — reference it instead (e.g., "Continued from `2026-02-07-100000-summary.md`").
+- Respect ContextDB conventions: plain Markdown, no proprietary formats, append-friendly.
+
+## For LLM Tools Reading Context
+
+When starting a new session or needing project context, read the files in `ContextDB/context/` in chronological order. The most recent summary represents the latest known state. Combine with `CLAUDE.md` and `ContextLoom.md` for full project understanding.

package/assets/skills/summary/SKILL.md

@@ -0,0 +1,72 @@
+---
+name: summary
+description: "Generate a summary or recap of content. Use when the user says /summary, asks to summarize a document, recap a session, create an executive summary, or distill information. Triggers: summary, recap, summarize, executive summary, tldr, distill, key takeaways."
+---
+
+# Summary / Recap
+
+## Purpose
+
+Produce a concise, well-structured summary of a document, conversation, work session, or any body of content. Capture what matters without burying the reader in details.
+
+## When to Use
+
+- Summarizing a long document or thread for stakeholders
+- Recapping a work session or sprint
+- Creating an executive summary from detailed material
+- Distilling a conversation into its essential outcomes
+
+## Inputs
+
+- **Source material**: The document, transcript, conversation, or notes to summarize
+- **Audience**: Who will read this summary (e.g., executives, engineers, full team) (optional)
+- **Focus area**: Any specific aspect to emphasize (optional)
+- **Length preference**: Brief (1 paragraph), standard (half page), or detailed (full page) (optional, defaults to standard)
+
+## Output Format
+
+Produce a markdown document with the following sections:
+
+### 1. TL;DR
+2-3 sentences capturing the absolute essence. A reader who only reads this should understand the core message.
+
+### 2. Key Points
+Bulleted list of the 3-7 most important facts, findings, or themes. Each point should be one concise sentence. Order by importance, not chronology.
+
+### 3. Decisions Made
+List any decisions that were reached, along with brief rationale. If no decisions were made, note that explicitly. Format:
+- **Decision**: What was decided
+- **Rationale**: Why (one sentence)
+
+### 4. Action Items
+List concrete next steps with owners (if known) and deadlines (if stated):
+- [ ] Action item description -- **Owner** (by Date)
+
+If no action items exist, state "No action items identified."
+
+### 5. Open Questions
+List unresolved questions or topics that need further discussion. These are loose threads the reader should be aware of.
+
+### 6. Context and Detail
+Optional section for readers who want more depth. Include relevant background, nuances, or supporting details that did not fit in the sections above. Keep this section to 1-3 short paragraphs.
+
+## Example
+
+**Input**: A 45-minute product team meeting transcript discussing the Q2 roadmap.
+
+**Output**:
+- TL;DR: The team aligned on three Q2 priorities (search improvements, onboarding redesign, API v2) and deferred the mobile app to Q3 due to resource constraints.
+- Key Points: search is the top revenue driver, onboarding drop-off is at 40%, API v2 has two enterprise customers waiting, mobile deferred but design work can start
+- Decisions: Committed to search as the #1 priority; chose incremental API migration over big-bang rewrite
+- Action Items: PM to draft search PRD by Friday, engineering lead to scope API v2 migration, design to start mobile exploration
+- Open Questions: Hiring timeline for the second frontend engineer, whether to build or buy the search indexing layer
+
+## Guidelines
+
+- Lead with the most important information -- do not bury the headline
+- Be faithful to the source material; do not add opinions or inferences
+- Use the audience context to calibrate the level of technical detail
+- Keep bullet points to one sentence each; elaborate only in the Context section
+- If the source material is contradictory, note the contradiction rather than resolving it
+- Attribute action items to specific people when that information is available
+- Distinguish between decisions (settled) and open questions (unsettled)