diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
new file mode 100644
index 0000000..355c403
--- /dev/null
+++ b/CONTRIBUTING.md
@@ -0,0 +1,75 @@
+# Contributing to Claude Code Community Patterns
+
+First off, thank you for considering contributing! This repository is built on the belief that **sharing agentic workflows multiplies our collective productivity.**
+
+Whether you're fixing a typo, adding a new slash command, or documenting a complex multi-agent workflow, your help is appreciated.
+
+## 🌟 What We're Looking For
+
+We specifically encourage contributions in these three areas:
+
+### 1. Custom Commands (`/commands`)
+Have you written a custom command that automates a tedious task?
+* **Examples:** Automated test runners, documentation generators, code style fixers, or security scanners.
+* **Requirement:** Commands must be generic enough to be useful to others (or easily adaptable).
+
+### 2. Context Templates (`CLAUDE.md`)
+Have you cracked the code on how to prompt Claude for a specific tech stack?
+* **Examples:** A `CLAUDE.md` optimized for Next.js 14, a Python/Django context that prevents circular import errors, or a Unity C# setup.
+* **Requirement:** Include comments explaining *why* certain rules are included.
+
+### 3. Workflows & Guides
+Have you found a reliable process for "pair programming" with Claude?
+* **Examples:** "How to use Claude to refactor legacy code safely" or "A workflow for writing comprehensive unit tests."
+
+---
+
+## 🚀 How to Contribute
+
+### Step 1: Fork & Branch
+1.  Fork the repository to your own GitHub account.
+2.  Create a new branch for your feature:
+    ```bash
+    git checkout -b feature/your-command-name
+    ```
+
+### Step 2: Add Your Content
+Please follow our directory structure:
+
+* **Commands** go in `commands/{category}/your-command.md`
+* **Templates** go in `templates/{stack}/CLAUDE.md`
+* **Workflows** go in `workflows/your-workflow-guide.md`
+
+#### Style Guide for Commands
+When adding a new command, please include a **metadata header** at the top of the file so users know what it does.
+
+**Example Format:**
+```markdown
+(Your prompt content goes here...)
+
+```
+
+### Step 3: Submit a Pull Request
+
+1. Push your branch to GitHub.
+2. Open a Pull Request (PR) against the `main` branch of this repository.
+3. **In your PR description, please answer:**
+* What problem does this solve?
+* How have you tested it? (e.g., "Used this on a React project for 2 weeks")
+
+
+
+---
+
+## 🧪 Testing Your Contributions
+
+Before submitting, please **test your command or template** in a fresh environment if possible.
+
+* **For Commands:** Does it work if the project structure is slightly different?
+* **For Templates:** Does it consume too many tokens unnecessarily?
+
+## 📜 License
+
+By contributing, you agree that your contributions will be licensed under the MIT License defined in the `LICENSE` file of this repository.
+
+Thank you for helping us build the ultimate manual for Claude Code!
diff --git a/LICENSE b/LICENSE
new file mode 100644
index 0000000..b77bf2a
--- /dev/null
+++ b/LICENSE
@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2025
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.
diff --git a/README.md b/README.md
index f13665c..e712746 100644
--- a/README.md
+++ b/README.md
@@ -1 +1,89 @@
-# claude-code
\ No newline at end of file
+# Claude Code: Community Patterns, Commands & Context
+
+[![Contributions Welcome](https://img.shields.io/badge/contributions-welcome-brightgreen.svg)](CONTRIBUTING.md)
+[![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](LICENSE)
+
+**A curated library of efficient slash commands, `CLAUDE.md` templates, and agentic workflows for software engineering with Claude Code.**
+
+## 📖 About This Repository
+
+Claude Code is a powerful agentic interface that acts as an AI development team member. However, its true power "multiplies when we share proven patterns."
+
+This repository serves as a centralized knowledge base for:
+* **Custom Commands (`/commands`):** Reusable prompts that automate complex tasks like testing, documentation, or refactoring.
+* **Context Templates (`CLAUDE.md`):** Best-practice structures for teaching Claude about your project's architecture and rules.
+* **Process Documentation:** Guides on how to "pair program" effectively with AI agents to solve specific engineering challenges.
+
+The goal is to help developers skip the trial-and-error phase and jump straight to productive, AI-assisted development.
+
+---
+
+## 📂 Repository Structure
+
+The repository is organized by resource type:
+
+```text
+.
+├── commands/           # Custom slash commands (e.g., /test, /doc, /refactor)
+│   ├── testing/        # Commands for running and fixing tests
+│   ├── docs/           # Commands for generating documentation
+│   └── architecture/   # Commands for analyzing code structure
+├── templates/          # CLAUDE.md templates for different project types
+│   ├── react/          # Context templates for React apps
+│   ├── python/         # Context templates for Python/Django/Flask
+│   └── generic/        # Universal project context structures
+└── workflows/          # Guides on multi-step agentic processes
+
+```
+
+---
+
+## 🚀 How to Use These Resources
+
+### 1. Using Custom Commands
+
+Claude Code allows you to create custom "slash commands" by placing markdown files in a `.claude/commands` directory in your project.
+
+1. Navigate to the `commands/` directory in this repo.
+2. Choose a command (e.g., `document-feature.md`).
+3. Copy the file into your local project: `.claude/commands/document-feature.md`.
+4. Run it in Claude Code by typing `/document-feature`.
+
+### 2. Adopting a `CLAUDE.md` Template
+
+The `CLAUDE.md` file is the "brain" of your project's context.
+
+1. Navigate to `templates/` and find a stack that matches yours.
+2. Copy the content into a file named `CLAUDE.md` at the root of your project.
+3. **Customize it:** Fill in your specific build commands, linting rules, and architectural constraints.
+
+---
+
+## 🤝 How to Contribute
+
+We welcome contributions! If you have developed a workflow that saves you time or improves code quality, please share it.
+
+### What we're looking for:
+
+* **High-Leverage Commands:** Scripts that turn 30 minutes of work into 30 seconds.
+* **Robust Contexts:** `CLAUDE.md` files that effectively prevent hallucinations or style errors.
+* **Novel Workflows:** Creative ways to use Claude for design, debugging, or planning.
+
+### Submission Guidelines
+
+1. **Fork** this repository.
+2. **Create a branch** for your contribution (`git checkout -b feature/amazing-test-command`).
+3. **Add your file** to the appropriate directory.
+* *Naming:* Use clear, descriptive filenames (e.g., `generate-unit-tests.md` rather than `tests.md`).
+
+
+4. **Add Metadata:** If possible, include a short comment block at the top of your file describing what it does and any prerequisites.
+5. **Submit a Pull Request** with a description of the problem your contribution solves.
+
+---
+
+## ⚖️ License
+
+This project is licensed under the MIT License - see the [LICENSE](https://www.google.com/search?q=LICENSE) file for details.
+
+> **Note:** This is a community-driven resource. Always review commands and prompts to ensure they align with your specific project requirements and security standards before running them.
diff --git a/commands/docs/document-feature.md b/commands/docs/document-feature.md
new file mode 100644
index 0000000..11f7ff4
--- /dev/null
+++ b/commands/docs/document-feature.md
@@ -0,0 +1,305 @@
+# Document Feature Command
+
+Generate comprehensive documentation for a new feature: $ARGUMENTS
+
+## Overview
+This command creates both technical developer documentation and user-friendly guides for the specified feature. It automatically detects the feature type (frontend/backend/full-stack) and adapts documentation accordingly.
+
+## Process
+
+### Phase 1: Discovery & Analysis
+
+1. **Locate Feature Files**
+   - Search codebase for files related to "$ARGUMENTS"
+   - Use glob patterns: `**/*$ARGUMENTS*`, `**/*{kebab-case}*`, `**/*{camelCase}*`
+   - Check common locations: `src/`, `api/`, `components/`, `services/`, `routes/`
+
+2. **Classify Feature Type**
+   - **Frontend**: Contains React/Vue components, UI elements, styling
+   - **Backend**: Contains API routes, controllers, database models, services
+   - **Full-stack**: Contains both frontend and backend elements
+   - Document the classification for context
+
+3. **Analyze Existing Documentation Patterns**
+   - Read 2-3 existing files from `docs/dev/` to understand:
+     - Structure and formatting conventions
+     - Section organization
+     - Code example patterns
+     - Cross-reference style
+   - Read 2-3 existing files from `docs/user/` to understand:
+     - Tone and language level
+     - Step-by-step instruction format
+     - Screenshot placement and captioning
+     - Troubleshooting patterns
+
+### Phase 2: Generate Developer Documentation
+
+Create file: `docs/dev/{feature-name}-implementation.md`
+
+**Required Sections:**
+
+```markdown
+# {Feature Name} - Technical Implementation
+
+## Overview
+[Brief technical description of what the feature does and why it was built]
+
+## Architecture
+[High-level architecture diagram or description]
+
+## Component Structure (if Frontend)
+- Component hierarchy
+- Key props and state
+- Event handlers and callbacks
+- Styling approach
+
+## API Endpoints (if Backend)
+### POST /api/{endpoint}
+- **Purpose**: [Description]
+- **Request Body**:
+  ```json
+  {
+    "field": "value"
+  }
+  ```
+- **Response**:
+  ```json
+  {
+    "result": "data"
+  }
+  ```
+- **Authentication**: [Requirements]
+- **Authorization**: [Permissions needed]
+
+## Data Models (if Backend)
+[Database schema, relationships, indexes]
+
+## Implementation Details
+- Key algorithms or business logic
+- Third-party integrations
+- Configuration requirements
+- Environment variables needed
+
+## Code Examples
+[Actual code snippets from implementation showing key patterns]
+
+## Testing
+- Unit test coverage
+- Integration test approach
+- E2E test scenarios
+- How to run tests: `npm test {feature-tests}`
+
+## Security Considerations
+[Authentication, authorization, data validation, etc.]
+
+## Performance Considerations
+[Caching, optimization, scalability notes]
+
+## Related Documentation
+- User Guide: [Link to user documentation]
+- Related Features: [Links to related dev docs]
+- API Reference: [If applicable]
+
+## Troubleshooting
+Common developer issues and solutions
+
+---
+*Last Updated: {current-date}*
+*Feature Type: {Frontend/Backend/Full-stack}*
+```
+
+### Phase 3: Generate User Documentation
+
+Create file: `docs/user/how-to-{feature-name}.md`
+
+**Required Sections:**
+
+```markdown
+# How to Use {Feature Name}
+
+## What is {Feature Name}?
+[Simple, jargon-free explanation of what the feature does and why users would want to use it]
+
+## Before You Begin
+- Prerequisites or requirements
+- Permissions needed
+- Any setup required
+
+## Step-by-Step Guide
+
+### Step 1: {First Action}
+[Clear instruction in simple language]
+
+**Screenshot Placeholder:**
+![{Descriptive alt text}](screenshots/{feature-name}-step-1.png)
+*Caption: {What the user should see at this step}*
+
+### Step 2: {Second Action}
+[Clear instruction]
+
+**Screenshot Placeholder:**
+![{Descriptive alt text}](screenshots/{feature-name}-step-2.png)
+*Caption: {What the user should see at this step}*
+
+[Continue for all major steps...]
+
+## Tips and Best Practices
+- Helpful hints for using the feature effectively
+- Common workflows
+- Time-saving shortcuts
+
+## Frequently Asked Questions
+
+### Q: {Common question}?
+A: {Clear answer}
+
+### Q: {Another common question}?
+A: {Clear answer}
+
+## Troubleshooting
+
+### Issue: {Common problem}
+**Solution:** {How to fix it}
+
+### Issue: {Another problem}
+**Solution:** {How to fix it}
+
+## Related Features
+- [{Related Feature 1}](link-to-related-feature.md)
+- [{Related Feature 2}](link-to-related-feature.md)
+
+## Need More Help?
+- Technical Details: See [developer documentation](../dev/{feature-name}-implementation.md)
+- Contact Support: [Support information]
+
+---
+*Last Updated: {current-date}*
+```
+
+### Phase 4: Cross-Reference Integration
+
+1. **Add links from dev docs to user docs**
+   - In the "Related Documentation" section
+   
+2. **Add links from user docs to dev docs**
+   - In the "Need More Help?" section
+   
+3. **Update any index or table of contents files**
+   - `docs/dev/README.md` or `docs/dev/index.md`
+   - `docs/user/README.md` or `docs/user/index.md`
+
+### Phase 5: Screenshot Integration (Bonus)
+
+**If Claude in Chrome is available:**
+
+1. **For Frontend Features:**
+   - Launch the application in Chrome
+   - Navigate to the feature
+   - Capture screenshots for each major step
+   - Save to `docs/user/screenshots/{feature-name}-step-{n}.png`
+   - Update markdown to reference actual screenshot files
+
+2. **Screenshot Quality Guidelines:**
+   - Use consistent browser window size (1920x1080 recommended)
+   - Highlight relevant UI elements with annotations
+   - Crop to show only relevant portions
+   - Use descriptive filenames
+
+**If Chrome integration not available:**
+- Keep placeholder format with descriptive captions
+- Document in output that screenshots need manual capture
+
+## Adaptive Documentation Rules
+
+### For Frontend Features:
+- Emphasize component structure and UI patterns
+- Include more screenshots in user docs
+- Detail state management approach
+- Document styling conventions used
+
+### For Backend Features:
+- Focus on API contracts and data models
+- Include request/response examples
+- Detail authentication/authorization
+- User docs may be lighter or focus on API consumers
+
+### For Full-Stack Features:
+- Document both frontend and backend thoroughly
+- Show data flow between layers
+- Include end-to-end examples
+- Ensure user docs show complete workflows
+
+## Output Requirements
+
+**Summary Report:**
+```
+✅ Documentation Generated for: {feature-name}
+
+📁 Files Created:
+  - docs/dev/{feature-name}-implementation.md
+  - docs/user/how-to-{feature-name}.md
+
+📊 Feature Classification: {Frontend/Backend/Full-stack}
+
+📝 Files Analyzed:
+  - {list of source files found and analyzed}
+
+📸 Screenshots:
+  - {If captured: list of screenshot files}
+  - {If not captured: number of placeholders that need manual screenshots}
+
+🔗 Cross-References Added:
+  - {list of cross-reference links inserted}
+
+⚠️  Action Items:
+  - {Any manual steps needed, like capturing screenshots}
+  - {Any additional documentation that might be helpful}
+```
+
+## Quality Checklist
+
+Before completing, verify:
+- [ ] Both documentation files created successfully
+- [ ] Documentation follows existing patterns from examples
+- [ ] Feature type correctly identified and documented
+- [ ] All required sections present in both docs
+- [ ] Cross-references properly linked
+- [ ] Code examples are accurate and from actual implementation
+- [ ] User documentation is jargon-free and clear
+- [ ] Screenshot placeholders have descriptive captions
+- [ ] File naming follows project conventions
+- [ ] Index/TOC files updated if they exist
+
+## Error Handling
+
+**If no files found for feature:**
+- Search with more flexible patterns
+- Ask user to specify file locations
+- Suggest checking feature name spelling
+
+**If existing docs directory structure missing:**
+- Create `docs/dev/` and `docs/user/` directories
+- Note this in output summary
+
+**If unable to determine feature type:**
+- Default to full-stack documentation
+- Note uncertainty in output
+- Ask user to clarify and regenerate if needed
+
+## Examples of Excellent Documentation
+
+**Developer Docs Reference:**
+- Look for existing files in `docs/dev/` or `technical/`
+- Match their tone, structure, and level of detail
+
+**User Docs Reference:**
+- Look for existing files in `docs/user/`, `guides/`, or `help/`
+- Match their accessibility and instruction style
+
+## Notes
+
+- Use current date for "Last Updated" timestamps
+- Convert feature names to appropriate case for filenames (kebab-case)
+- Preserve any existing documentation structure conventions
+- If unsure about specific project patterns, ask for clarification
+- Documentation should be complete enough to onboard new team members