@techwavedev/agi-agent-kit 1.6.0 → 1.6.3

package/templates/skills/extended/security/privacy-by-design/SKILL.md

@@ -0,0 +1,259 @@
+---
+name: privacy-by-design
+description: "Use when building apps that collect user data. Ensures privacy protections are built in from the start—data minimization, consent, encryption."
+risk: safe
+source: community
+date_added: "2026-02-23"
+---
+
+# Privacy by Design
+
+## Overview
+
+Integrate privacy protections into software architecture from the beginning, not as an afterthought. This skill applies Privacy by Design principles (GDPR Article 25, Cavoukian's framework) when designing databases, APIs, and user flows. Protects real users' data and builds trust.
+
+## When to Use This Skill
+
+- Use when building apps that collect personal data (names, emails, locations, preferences)
+- Use when designing database schemas, APIs, or authentication flows
+- Use when the user mentions forms, user accounts, analytics, or third-party integrations
+- Use when deploying to production—verify privacy controls before launch
+
+## Legal Frameworks
+
+**GDPR (EU)** — Primary reference. Article 25 mandates "data protection by design and by default." Applies to EU users and often adopted globally.
+
+**CCPA (California)** — Right to know, delete, opt-out of sale. Similar principles: minimize, disclose, allow control.
+
+**LGPD (Brazil)** — Aligned with GDPR. Purpose limitation, necessity, transparency. Applies to Brazil users.
+
+Design for the strictest framework you target; it often satisfies others.
+
+---
+
+## Core Principles
+
+### 1. Data Minimization
+Collect only what is strictly necessary. Every field needs a documented justification. Avoid "we might need it later."
+
+### 2. Purpose Limitation
+Store the purpose of each data point. Do not reuse data for purposes the user did not consent to.
+
+### 3. Storage Limitation
+Define retention periods. Implement automated deletion or anonymization when retention expires. Never keep data "forever" by default.
+
+### 4. Privacy as Default
+Opt-in for optional collection, not opt-out. Sensitive settings (analytics, marketing) off by default. No pre-checked consent boxes.
+
+### 5. End-to-End Security
+Encrypt at rest and in transit. Use RBAC. Log access to sensitive data for audit.
+
+### 6. Transparency
+Document what is collected and why. Clear privacy policies. Easy access and deletion for users.
+
+---
+
+## User Rights (GDPR)
+
+Ensure these are implementable from day one:
+
+| Right | What to build |
+|-------|---------------|
+| **Access** | Endpoint or flow to return all user data |
+| **Rectification** | Ability to update/correct data |
+| **Erasure** | Account deletion + data purge (including backups) |
+| **Portability** | Export data in machine-readable format (JSON, CSV) |
+
+---
+
+## Deep Dive: Why It Matters
+
+**Data minimization** — Less data = less breach impact, lower storage cost, simpler compliance. Each field is a liability.
+
+**Purpose limitation** — Reusing data without consent is illegal under GDPR. Document purpose in schema or metadata.
+
+**Retention** — Indefinite storage increases risk and violates GDPR. Define `retention_days` per data type; automate cleanup.
+
+**Logging** — Logs often leak PII. Redact emails, IDs, tokens. Use structured logging with allowlists.
+
+**Third parties** — Every SDK (analytics, crash reporting, ads) may send data elsewhere. Audit dependencies; require consent before loading.
+
+---
+
+## Code Examples
+
+### JavaScript/Node — Minimal User Model
+
+```javascript
+// BAD: Collecting everything "just in case"
+const user = { email, name, phone, address, birthdate, ipAddress, userAgent, ... };
+
+// GOOD: Minimal, documented purpose
+const user = {
+  email,        // purpose: authentication
+  displayName,  // purpose: UI display
+  createdAt,    // purpose: account age
+};
+```
+
+### JavaScript — Consent Before Tracking
+
+```javascript
+// BAD: Track first, ask later
+analytics.track(userId, event);
+
+// GOOD: Check consent first
+if (userConsent.analytics) {
+  analytics.track(userId, event);
+}
+```
+
+### Python — Safe Logging
+
+```python
+# BAD: Logging PII in plain text
+logger.info(f"User {user.email} logged in from {request.remote_addr}")
+
+# GOOD: Redact or hash identifiers
+logger.info(f"User {hash_user_id(user.id)} logged in")
+# Or: logger.info("User login", extra={"user_id_hash": hash_id(user.id)})
+```
+
+### SQL — Schema with Purpose and Retention
+
+```sql
+-- GOOD: Document purpose and retention in schema
+CREATE TABLE users (
+  id UUID PRIMARY KEY,
+  email VARCHAR(255) NOT NULL,  -- purpose: auth, retention: account lifetime
+  display_name VARCHAR(100),   -- purpose: UI, retention: account lifetime
+  created_at TIMESTAMPTZ,      -- purpose: audit, retention: 7 years
+  last_login_at TIMESTAMPTZ    -- purpose: security, retention: 90 days
+);
+
+-- Add retention policy (PostgreSQL example)
+-- Schedule job to anonymize/delete last_login_at after 90 days
+```
+
+### API — Return Only Needed Fields
+
+```python
+# BAD: Returning full user object
+return jsonify(user)  # May include internal fields, hashed passwords
+
+# GOOD: Explicit allowlist
+return jsonify({
+    "id": user.id,
+    "email": user.email,
+    "displayName": user.display_name,
+})
+```
+
+---
+
+## Common Pitfalls
+
+| Pitfall | Solution |
+|---------|----------|
+| Logs contain emails, IPs, tokens | Redact PII; use hashed IDs or structured logs |
+| Error messages expose data | Return generic errors to client; log details server-side |
+| Third-party SDKs load before consent | Load analytics/ads only after consent; use consent management |
+| No deletion flow | Design account deletion + data purge from day one |
+| Backups keep data forever | Include backups in retention; encrypt backups |
+| Cookies without consent | Use consent banner; respect Do Not Track where applicable |
+
+---
+
+## Third-Party Audit
+
+Before adding a dependency that touches user data:
+
+- [ ] What data does it collect or receive?
+- [ ] Where does it send data (servers, countries)?
+- [ ] Is it loaded before or after user consent?
+- [ ] Can we disable it if user opts out?
+- [ ] Does their privacy policy align with ours?
+
+---
+
+## Implementation Checklist
+
+When building a feature that touches user data:
+
+- [ ] Is this data necessary? Can we achieve the goal with less?
+- [ ] Do we have explicit consent for this use?
+- [ ] Is it encrypted (at rest and in transit)?
+- [ ] Do we have a retention/deletion policy?
+- [ ] Can the user export or delete their data?
+- [ ] Are third-party services disclosed and consented?
+- [ ] Are logs free of PII?
+- [ ] Are backups included in retention policy?
+
+---
+
+## Best Practices
+
+- ✅ Ask "do we need this?" for every new data field
+- ✅ Design deletion and export flows from day one
+- ✅ Use hashing or tokenization for sensitive identifiers when possible
+- ✅ Document purpose and retention in schema or metadata
+- ❌ Don't log passwords, tokens, or PII in plain text
+- ❌ Don't share data with third parties without explicit consent
+- ❌ Don't assume "we'll add privacy later"—it rarely happens
+- ❌ Don't expose stack traces or internal errors to clients
+
+---
+
+## When to Use
+
+This skill is applicable when building software that collects, stores, or processes personal data. Apply it proactively during design and implementation.
+
+---
+
+<!-- AGI-INTEGRATION-START -->
+
+## AGI Framework Integration
+
+> **Adapted for [@techwavedev/agi-agent-kit](https://www.npmjs.com/package/@techwavedev/agi-agent-kit)**
+> Original source: [antigravity-awesome-skills](https://github.com/sickn33/antigravity-awesome-skills)
+
+### Memory-First Protocol
+
+Cache compliance check results to avoid re-running expensive AWS API calls. Retrieve prior audit findings to track remediation progress across sessions.
+
+```bash
+# Check for prior security context before starting
+python3 execution/memory_manager.py auto --query "prior security audit results for Privacy By Design"
+```
+
+### Storing Results
+
+After completing work, store security decisions for future sessions:
+
+```bash
+python3 execution/memory_manager.py store \
+  --content "Audit findings: 3 critical IAM misconfigurations found and remediated" \
+  --type technical --project <project> \
+  --tags privacy-by-design security
+```
+
+### Multi-Agent Collaboration
+
+Share security findings with other agents so they avoid introducing vulnerabilities in their code changes.
+
+```bash
+python3 execution/cross_agent_context.py store \
+  --agent "<your-agent>" \
+  --action "Completed security audit — 3 critical findings fixed, compliance score 94%" \
+  --project <project>
+```
+
+### Signed Audit Trail
+
+All security findings are cryptographically signed with the agent's Ed25519 identity, providing tamper-proof audit logs for compliance reporting.
+
+### Semantic Cache for Compliance
+
+Cache compliance check results (`semantic_cache.py`) to avoid redundant AWS API calls. Cache hit at similarity >0.92 returns prior results instantly.
+
+<!-- AGI-INTEGRATION-END -->

package/templates/skills/extended/workflow/finishing-a-development-branch/SKILL.md

@@ -1,6 +1,9 @@
 ---
 name: finishing-a-development-branch
-description: Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup
+description: "Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup"
+risk: unknown
+source: community
+date_added: "2026-02-27"
 ---
 
 # Finishing a Development Branch
@@ -199,6 +202,8 @@ git worktree remove <worktree-path>
 **Pairs with:**
 - **using-git-worktrees** - Cleans up worktree created by that skill
 
+## When to Use
+This skill is applicable to execute the workflow or actions described in the overview.
 
 ---
 

package/templates/skills/knowledge/frontend/stitch-loop/SKILL.md

@@ -7,7 +7,6 @@ allowed-tools:
   - "Read"
   - "Write"
   - "Bash"
-  - "qdrant-memory"
 ---
 
 # Stitch Build Loop
@@ -17,8 +16,7 @@ You are an **autonomous frontend builder** participating in an iterative site-bu
 ## Overview
 
 The Build Loop pattern enables continuous, autonomous website development through a "baton" system. Each iteration:
-
-1. Reads the current task from a baton file (`next-prompt.md`)
+1. Reads the current task from a baton file (`.stitch/next-prompt.md`)
 2. Generates a page using Stitch MCP tools
 3. Integrates the page into the site structure
 4. Writes the next task to the baton file for the next iteration
@@ -26,73 +24,56 @@ The Build Loop pattern enables continuous, autonomous website development throug
 ## Prerequisites
 
 **Required:**
-
 - Access to the Stitch MCP Server
 - A Stitch project (existing or will be created)
-- A `DESIGN.md` file (generate one using the `design-md` skill if needed)
-- A `SITE.md` file documenting the site vision and roadmap
+- A `.stitch/DESIGN.md` file (generate one using the `design-md` skill if needed)
+- A `.stitch/SITE.md` file documenting the site vision and roadmap
 
 **Optional:**
-
 - Chrome DevTools MCP Server — enables visual verification of generated pages
-- Qdrant Memory Skill — enables semantic context retrieval and long-term memory
 
 ## The Baton System
 
-The `next-prompt.md` file acts as a relay baton between iterations:
+The `.stitch/next-prompt.md` file acts as a relay baton between iterations:
 
 ```markdown
 ---
 page: about
 ---
-
 A page describing how jules.top tracking works.
 
 **DESIGN SYSTEM (REQUIRED):**
-[Copy from DESIGN.md Section 6]
+[Copy from .stitch/DESIGN.md Section 6]
 
 **Page Structure:**
-
 1. Header with navigation
 2. Explanation of tracking methodology
 3. Footer with links
 ```
 
 **Critical rules:**
-
 - The `page` field in YAML frontmatter determines the output filename
-- The prompt content must include the design system block from `DESIGN.md`
+- The prompt content must include the design system block from `.stitch/DESIGN.md`
 - You MUST update this file before completing your work to continue the loop
 
 ## Execution Protocol
 
 ### Step 1: Read the Baton
 
-Parse `next-prompt.md` to extract:
-
+Parse `.stitch/next-prompt.md` to extract:
 - **Page name** from the `page` frontmatter field
 - **Prompt content** from the markdown body
 
-### Step 2: Check Context Files
+### Step 2: Consult Context Files
 
 Before generating, read these files:
 
-| File        | Purpose                                                               |
-| ----------- | --------------------------------------------------------------------- |
-| `SITE.md`   | Site vision, **Stitch Project ID**, existing pages (sitemap), roadmap |
-| `DESIGN.md` | Required visual style for Stitch prompts                              |
-
-### Step 2.5: Check Memory (Optional)
-
-If the **Qdrant Memory Skill** is available, retrieve relevant context to ensure consistency:
-
-1. **Retrieve Context**: Call `qdrant_search_memory` (or `retrieve_context` script) with technical queries related to the current task.
-   - Example query: "navigation structure", "footer design", "auth flow pattern"
-   - Filter by project if applicable.
-2. **Check Decisions**: Look for past architectural decisions (`type: "decision"`) that might impact this page.
+| File | Purpose |
+|------|---------|
+| `.stitch/SITE.md` | Site vision, **Stitch Project ID**, existing pages (sitemap), roadmap |
+| `.stitch/DESIGN.md` | Required visual style for Stitch prompts |
 
 **Important checks:**
-
 - Section 4 (Sitemap) — Do NOT recreate pages that already exist
 - Section 5 (Roadmap) — Pick tasks from here if backlog exists
 - Section 6 (Creative Freedom) — Ideas for new pages if roadmap is empty
@@ -102,20 +83,23 @@ If the **Qdrant Memory Skill** is available, retrieve relevant context to ensure
 Use the Stitch MCP tools to generate the page:
 
 1. **Discover namespace**: Run `list_tools` to find the Stitch MCP prefix
-2. **Get or create project**:
-   - If `stitch.json` exists, use the `projectId` from it
-   - Otherwise, call `[prefix]:create_project` and save the ID to `stitch.json`
+2. **Get or create project**: 
+   - If `.stitch/metadata.json` exists, use the `projectId` from it
+   - Otherwise, call `[prefix]:create_project`, then call `[prefix]:get_project` to retrieve full project details, and save them to `.stitch/metadata.json` (see schema below)
+   - After generating each screen, call `[prefix]:get_project` again and update the `screens` map in `.stitch/metadata.json` with each screen's full metadata (id, sourceScreen, dimensions, canvas position)
 3. **Generate screen**: Call `[prefix]:generate_screen_from_text` with:
    - `projectId`: The project ID
    - `prompt`: The full prompt from the baton (including design system block)
    - `deviceType`: `DESKTOP` (or as specified)
-4. **Retrieve assets**: Call `[prefix]:get_screen` to get:
-   - `htmlCode.downloadUrl` — Download and save as `queue/{page}.html`
-   - `screenshot.downloadUrl` — Download and save as `queue/{page}.png`
+4. **Retrieve assets**: Before downloading, check if `.stitch/designs/{page}.html` and `.stitch/designs/{page}.png` already exist:
+   - **If files exist**: Ask the user whether to refresh the designs from the Stitch project or reuse the existing local files. Only re-download if the user confirms.
+   - **If files do not exist**: Proceed with download:
+     - `htmlCode.downloadUrl` — Download and save as `.stitch/designs/{page}.html`
+      - `screenshot.downloadUrl` — Append `=w{width}` to the URL before downloading, where `{width}` is the `width` value from the screen metadata (Google CDN serves low-res thumbnails by default). Save as `.stitch/designs/{page}.png`
 
 ### Step 4: Integrate into Site
 
-1. Move generated HTML from `queue/{page}.html` to `site/public/{page}.html`
+1. Move generated HTML from `.stitch/designs/{page}.html` to `site/public/{page}.html`
 2. Fix any asset paths to be relative to the public folder
 3. Update navigation:
    - Find existing placeholder links (e.g., `href="#"`) and wire them to the new page
@@ -130,35 +114,24 @@ If the **Chrome DevTools MCP Server** is available, verify the generated page:
 2. **Start dev server**: Use Bash to start a local server (e.g., `npx serve site/public`)
 3. **Navigate to page**: Call `[chrome_prefix]:navigate` to open `http://localhost:3000/{page}.html`
 4. **Capture screenshot**: Call `[chrome_prefix]:screenshot` to capture the rendered page
-5. **Visual comparison**: Compare against the Stitch screenshot (`queue/{page}.png`) for fidelity
+5. **Visual comparison**: Compare against the Stitch screenshot (`.stitch/designs/{page}.png`) for fidelity
 6. **Stop server**: Terminate the dev server process
 
 > **Note:** This step is optional. If Chrome DevTools MCP is not installed, skip to Step 5.
 
 ### Step 5: Update Site Documentation
 
-Modify `SITE.md`:
-
+Modify `.stitch/SITE.md`:
 - Add the new page to Section 4 (Sitemap) with `[x]`
 - Remove any idea you consumed from Section 6 (Creative Freedom)
 - Update Section 5 (Roadmap) if you completed a backlog item
 
-### Step 5.5: Store Memory (Optional)
-
-If **Qdrant Memory Skill** is available:
-
-1. **Store Completion**: Use `qdrant_store_memory` to record the completion of the page.
-   - Content: "Completed page: {page}. Implemented features: [list features]."
-   - Metadata: `type: "milestone"`, `page: "{page}"`
-2. **Store Decisions**: If you made any structural or design decisions (e.g., "Standardized footer links"), store them:
-   - Metadata: `type: "decision"`, `topic: "navigation"`
-
 ### Step 6: Prepare the Next Baton (Critical)
 
-**You MUST update `next-prompt.md` before completing.** This keeps the loop alive.
+**You MUST update `.stitch/next-prompt.md` before completing.** This keeps the loop alive.
 
-1. **Decide the next page**:
-   - Check `SITE.md` Section 5 (Roadmap) for pending items
+1. **Decide the next page**: 
+   - Check `.stitch/SITE.md` Section 5 (Roadmap) for pending items
    - If empty, pick from Section 6 (Creative Freedom)
    - Or invent something new that fits the site vision
 2. **Write the baton** with proper YAML frontmatter:
@@ -167,14 +140,12 @@ If **Qdrant Memory Skill** is available:
 ---
 page: achievements
 ---
-
 A competitive achievements page showing developer badges and milestones.
 
 **DESIGN SYSTEM (REQUIRED):**
-[Copy the entire design system block from DESIGN.md]
+[Copy the entire design system block from .stitch/DESIGN.md]
 
 **Page Structure:**
-
 1. Header with title and navigation
 2. Badge grid showing unlocked/locked states
 3. Progress bars for milestone tracking
@@ -184,28 +155,85 @@ A competitive achievements page showing developer badges and milestones.
 
 ```
 project/
-├── next-prompt.md      # The baton — current task
-├── stitch.json         # Stitch project ID (persist this!)
-├── DESIGN.md           # Visual design system (from design-md skill)
-├── SITE.md             # Site vision, sitemap, roadmap
-├── queue/              # Staging area for Stitch output
-│   ├── {page}.html
-│   └── {page}.png
+├── .stitch/
+│   ├── metadata.json   # Stitch project & screen IDs (persist this!)
+│   ├── DESIGN.md       # Visual design system (from design-md skill)
+│   ├── SITE.md         # Site vision, sitemap, roadmap
+│   ├── next-prompt.md  # The baton — current task
+│   └── designs/        # Staging area for Stitch output
+│       ├── {page}.html
+│       └── {page}.png
 └── site/public/        # Production pages
     ├── index.html
     └── {page}.html
 ```
 
+### `.stitch/metadata.json` Schema
+
+This file persists all Stitch identifiers so future iterations can reference them for edits or variants. Populate it by calling `[prefix]:get_project` after creating a project or generating screens.
+
+```json
+{
+  "name": "projects/6139132077804554844",
+  "projectId": "6139132077804554844",
+  "title": "My App",
+  "visibility": "PRIVATE",
+  "createTime": "2026-03-04T23:11:25.514932Z",
+  "updateTime": "2026-03-04T23:34:40.400007Z",
+  "projectType": "PROJECT_DESIGN",
+  "origin": "STITCH",
+  "deviceType": "MOBILE",
+  "designTheme": {
+    "colorMode": "DARK",
+    "font": "INTER",
+    "roundness": "ROUND_EIGHT",
+    "customColor": "#40baf7",
+    "saturation": 3
+  },
+  "screens": {
+    "index": {
+      "id": "d7237c7d78f44befa4f60afb17c818c1",
+      "sourceScreen": "projects/6139132077804554844/screens/d7237c7d78f44befa4f60afb17c818c1",
+      "x": 0,
+      "y": 0,
+      "width": 390,
+      "height": 1249
+    },
+    "about": {
+      "id": "bf6a3fe5c75348e58cf21fc7a9ddeafb",
+      "sourceScreen": "projects/6139132077804554844/screens/bf6a3fe5c75348e58cf21fc7a9ddeafb",
+      "x": 549,
+      "y": 0,
+      "width": 390,
+      "height": 1159
+    }
+  },
+  "metadata": {
+    "userRole": "OWNER"
+  }
+}
+```
+
+| Field | Description |
+|-------|-------------|
+| `name` | Full resource name (`projects/{id}`) |
+| `projectId` | Stitch project ID (from `create_project` or `get_project`) |
+| `title` | Human-readable project title |
+| `designTheme` | Design system tokens: color mode, font, roundness, custom color, saturation |
+| `deviceType` | Target device: `MOBILE`, `DESKTOP`, `TABLET` |
+| `screens` | Map of page name → screen object. Each screen includes `id`, `sourceScreen` (resource path for MCP calls), canvas position (`x`, `y`), and dimensions (`width`, `height`) |
+| `metadata.userRole` | User's role on the project (`OWNER`, `EDITOR`, `VIEWER`) |
+
 ## Orchestration Options
 
 The loop can be driven by different orchestration layers:
 
-| Method            | How it works                                           |
-| ----------------- | ------------------------------------------------------ |
-| **CI/CD**         | GitHub Actions triggers on `next-prompt.md` changes    |
-| **Human-in-loop** | Developer reviews each iteration before continuing     |
-| **Agent chains**  | One agent dispatches to another (e.g., CI/CD pipeline) |
-| **Manual**        | Developer runs the agent repeatedly with the same repo |
+| Method | How it works |
+|--------|--------------|
+| **CI/CD** | GitHub Actions triggers on `.stitch/next-prompt.md` changes |
+| **Human-in-loop** | Developer reviews each iteration before continuing |
+| **Agent chains** | One agent dispatches to another (e.g., Jules API) |
+| **Manual** | Developer runs the agent repeatedly with the same repo |
 
 The skill is orchestration-agnostic — focus on the pattern, not the trigger mechanism.
 
@@ -213,58 +241,23 @@ The skill is orchestration-agnostic — focus on the pattern, not the trigger me
 
 This skill works best with the `design-md` skill:
 
-1. **First time setup**: Generate `DESIGN.md` using the `design-md` skill from an existing Stitch screen
+1. **First time setup**: Generate `.stitch/DESIGN.md` using the `design-md` skill from an existing Stitch screen
 2. **Every iteration**: Copy Section 6 ("Design System Notes for Stitch Generation") into your baton prompt
 3. **Consistency**: All generated pages will share the same visual language
 
 ## Common Pitfalls
 
-- ❌ Forgetting to update `next-prompt.md` (breaks the loop)
+- ❌ Forgetting to update `.stitch/next-prompt.md` (breaks the loop)
 - ❌ Recreating a page that already exists in the sitemap
-- ❌ Not including the design system block in the prompt
+- ❌ Not including the design system block from `.stitch/DESIGN.md` in the prompt
 - ❌ Leaving placeholder links (`href="#"`) instead of wiring real navigation
-- ❌ Forgetting to persist `stitch.json` after creating a new project
+- ❌ Forgetting to persist `.stitch/metadata.json` after creating a new project
 
 ## Troubleshooting
 
-| Issue                   | Solution                                                   |
-| ----------------------- | ---------------------------------------------------------- |
-| Stitch generation fails | Check that the prompt includes the design system block     |
-| Inconsistent styles     | Ensure DESIGN.md is up-to-date and copied correctly        |
-| Loop stalls             | Verify `next-prompt.md` was updated with valid frontmatter |
-| Navigation broken       | Check all internal links use correct relative paths        |
-
-## AGI Framework Integration
-
-### Qdrant Memory Integration
-
-Before executing complex tasks with this skill:
-```bash
-python3 execution/memory_manager.py auto --query "<task summary>"
-```
-
-**Decision Tree:**
-- **Cache hit?** Use cached response directly — no need to re-process.
-- **Memory match?** Inject `context_chunks` into your reasoning.
-- **No match?** Proceed normally, then store results:
-
-```bash
-python3 execution/memory_manager.py store \
-  --content "Description of what was decided/solved" \
-  --type decision \
-  --tags stitch-loop <relevant-tags>
-```
-
-> **Note:** Storing automatically updates both Vector (Qdrant) and Keyword (BM25) indices.
-
-### Agent Team Collaboration
-
-- **Strategy**: This skill communicates via the shared memory system.
-- **Orchestration**: Invoked by `orchestrator` via intelligent routing.
-- **Context Sharing**: Always read previous agent outputs from memory before starting.
-
-### Local LLM Support
-
-When available, use local Ollama models for embedding and lightweight inference:
-- Embeddings: `nomic-embed-text` via Qdrant memory system
-- Lightweight analysis: Local models reduce API costs for repetitive patterns
+| Issue | Solution |
+|-------|----------|
+| Stitch generation fails | Check that the prompt includes the design system block |
+| Inconsistent styles | Ensure `.stitch/DESIGN.md` is up-to-date and copied correctly |
+| Loop stalls | Verify `.stitch/next-prompt.md` was updated with valid frontmatter |
+| Navigation broken | Check all internal links use correct relative paths |