showpane 0.4.0 → 0.4.2

package/bundle/toolchain/skills/portal-status/SKILL.md

@@ -0,0 +1,268 @@
+---
+name: portal-status
+description: |
+  Terminal dashboard showing all portals with health scores. Use when asked to "portal status",
+  "dashboard", "health check", "how are my portals", or "overview of all portals". (showpane)
+allowed-tools: [Bash, Read, Glob, Grep]
+---
+
+## Preamble (run first)
+
+Before doing anything else, execute this block in a Bash tool call:
+
+```bash
+CONFIG="$HOME/.showpane/config.json"
+if [ ! -f "$CONFIG" ]; then
+  echo "Showpane not configured. Run /portal setup first."
+  exit 1
+fi
+APP_PATH=$(cat "$CONFIG" | python3 -c "import sys,json; print(json.loads(sys.stdin.read()).get('app_path',''))" 2>/dev/null)
+DEPLOY_MODE=$(cat "$CONFIG" | python3 -c "import sys,json; print(json.loads(sys.stdin.read()).get('deploy_mode','docker'))" 2>/dev/null)
+ORG_SLUG=$(cat "$CONFIG" | python3 -c "import sys,json; d=json.loads(sys.stdin.read()); print(d.get('orgSlug','') or d.get('org_slug',''))" 2>/dev/null)
+APP_PATH="${SHOWPANE_APP_PATH:-$APP_PATH}"
+if [ -f "$APP_PATH/.env" ]; then set -a && source "$APP_PATH/.env" && set +a; fi
+DATABASE_URL="${DATABASE_URL:-}"
+if [ ! -d "$APP_PATH/node_modules/.prisma" ]; then
+  echo "App dependencies not installed. Run: cd $APP_PATH && npm install"
+  exit 1
+fi
+SKILL_DIR="${SHOWPANE_TOOLCHAIN_DIR:-$HOME/.showpane/current}"
+SKILL_VERSION=$(cat "$SKILL_DIR/VERSION" 2>/dev/null || echo "unknown")
+echo "SHOWPANE: v$SKILL_VERSION | MODE: $DEPLOY_MODE | APP: $APP_PATH"
+LEARN_FILE="$HOME/.showpane/learnings.jsonl"
+[ -f "$LEARN_FILE" ] && echo "LEARNINGS: $(wc -l < "$LEARN_FILE" | tr -d ' ') loaded" || echo "LEARNINGS: 0"
+
+# Predictive next-skill suggestion
+if [ -f "$HOME/.showpane/timeline.jsonl" ]; then
+  _RECENT=$(grep '"event":"completed"' "$HOME/.showpane/timeline.jsonl" 2>/dev/null | tail -3 | grep -o '"skill":"[^"]*"' | sed 's/"skill":"//;s/"//' | tr '\n' ',' | sed 's/,$//')
+  [ -n "$_RECENT" ] && echo "RECENT_SKILLS: $_RECENT"
+fi
+
+# Search relevant learnings
+LEARN_FILE="$HOME/.showpane/learnings.jsonl"
+if [ -f "$LEARN_FILE" ]; then
+  _LEARN_COUNT=$(wc -l < "$LEARN_FILE" 2>/dev/null | tr -d ' ')
+  echo "LEARNINGS: $_LEARN_COUNT entries"
+  if [ "$_LEARN_COUNT" -gt 0 ] 2>/dev/null; then
+    echo "RECENT_LEARNINGS:"
+    tail -5 "$LEARN_FILE" 2>/dev/null
+  fi
+fi
+
+# Track skill execution
+SHOWPANE_TIMELINE="$HOME/.showpane/timeline.jsonl"
+mkdir -p "$(dirname "$SHOWPANE_TIMELINE")"
+echo '{"skill":"portal-status","event":"started","ts":"'$(date -u +%Y-%m-%dT%H:%M:%SZ)'"}' >> "$SHOWPANE_TIMELINE" 2>/dev/null
+```
+
+If RECENT_SKILLS is shown, suggest the likely next skill:
+- After portal-create → suggest /portal-preview
+- After portal-preview → suggest /portal-deploy or /portal-share
+- After portal-deploy → suggest /portal-status or /portal-verify
+- After portal-setup → suggest /portal-create
+- After portal-credentials → suggest /portal-share
+- After portal-update → suggest /portal-deploy
+
+If RECENT_LEARNINGS is shown, review them before proceeding. Past learnings may contain
+relevant warnings or tips for this operation. Apply them where relevant but don't
+mention them unless they directly affect the current task.
+
+## Overview
+
+This skill produces a terminal-based status dashboard showing all portals with health scores, recent activity, and attention flags. It combines data from the portal list and analytics queries into a single at-a-glance view. Think of it as the "home screen" for a Showpane operator -- one command to understand the state of all client portals.
+
+The health score is a composite 0-10 rating that weights recent activity, credential freshness, content recency, and file completeness. Portals scoring below 5 are flagged with suggestions for improvement.
+
+## Steps
+
+### Step 1: Fetch the portal list
+
+Run the list script to get all active portals:
+
+```bash
+cd $APP_PATH && NODE_PATH="$APP_PATH/node_modules" npx tsx --tsconfig $APP_PATH/tsconfig.json $SKILL_DIR/bin/list-portals.ts --org-id <org_id>
+```
+
+This returns the list of portals with their metadata (slug, company name, status, last updated, credential info).
+
+If the org has zero portals, display:
+
+```
+SHOWPANE STATUS DASHBOARD
+════════════════════════════════════════════════════════════
+  No portals yet. Run /portal create to get started.
+════════════════════════════════════════════════════════════
+```
+
+### Step 2: Fetch analytics for each portal
+
+For each portal in the list, query analytics:
+
+```bash
+cd $APP_PATH && NODE_PATH="$APP_PATH/node_modules" npx tsx --tsconfig $APP_PATH/tsconfig.json $SKILL_DIR/bin/query-analytics.ts --slug <slug> --org-id <org_id>
+```
+
+If you have many portals (5+), you can batch the queries. For a small number, sequential calls are fine. The script should return quickly for each portal.
+
+Collect the following data points per portal:
+- `views7d`: Total views in the last 7 days
+- `lastActivity`: Timestamp of most recent event
+- `credentialCreatedAt`: When credentials were first set up
+- `lastUpdated`: When the portal content was last modified
+- `hasFiles`: Whether the portal has at least one uploaded/attached file
+
+### Step 3: Calculate health scores
+
+Score each portal on a 0-10 scale using four weighted dimensions:
+
+#### Recent Activity (30% weight)
+- Views in last 7 days > 0: score 10
+- No views in last 7 days but views in last 30 days > 0: score 5
+- No views in last 30 days: score 0
+
+#### Credential Freshness (20% weight)
+- Credentials created less than 30 days ago: score 10
+- Credentials created less than 90 days ago: score 7
+- Credentials older than 90 days: score 3
+- No credentials at all: score 0
+
+#### Content Recency (30% weight)
+- `lastUpdated` within 30 days: score 10
+- `lastUpdated` within 90 days: score 7
+- `lastUpdated` older than 90 days: score 3
+
+#### Has Files (20% weight)
+- At least 1 file/document attached: score 10
+- No files: score 5
+
+**Composite score** = (activity * 0.3) + (credentials * 0.2) + (content * 0.3) + (files * 0.2)
+
+Round to one decimal place.
+
+### Step 4: Display the dashboard
+
+Format the output as a rich ASCII table:
+
+```
+SHOWPANE STATUS DASHBOARD
+════════════════════════════════════════════════════════════
+  Portal    Company              Health  Views(7d)  Last Login
+  ───────── ──────────────────── ─────── ────────── ──────────
+  whzan     Whzan Digital Health 8.5/10  12         2 days ago
+  acme      Acme Corp            6.0/10  0          15 days ago
+  example   Example Portal       3.0/10  0          Never
+════════════════════════════════════════════════════════════
+  3 portals | Avg health: 5.8/10 | 1 needs attention
+```
+
+Column definitions:
+
+- **Portal**: The slug. Keep it short.
+- **Company**: Client company name, truncated to 20 characters if needed.
+- **Health**: Composite score out of 10, one decimal place.
+- **Views(7d)**: View count in the last 7 days. "0" if none.
+- **Last Login**: Human-readable relative time. "2 days ago", "15 days ago", "Never". Use "Never" if there are zero recorded events.
+
+### Step 5: Flag portals needing attention
+
+Any portal with a health score below 5.0 gets flagged. After the table, list specific, actionable suggestions:
+
+```
+NEEDS ATTENTION
+────────────────────────────────────────
+  example (3.0/10):
+    - No views in 30 days. Check if credentials were shared with the client.
+    - Content last updated 4 months ago. Consider refreshing.
+    - No files attached. Add documents to increase engagement.
+  
+  acme (6.0/10):
+    - No views in 7 days. Consider a follow-up email.
+────────────────────────────────────────
+```
+
+Guidelines for suggestions:
+
+- **No views, has credentials**: "Check if credentials were shared with the client."
+- **No views, no credentials**: "Set up credentials with /portal credentials <slug> and share them."
+- **Stale content (> 90 days)**: "Content last updated X months ago. Consider refreshing."
+- **No files**: "Add documents to increase engagement."
+- **Declining activity (had views before, none now)**: "Activity has dropped off. Consider a follow-up."
+- **Old credentials (> 90 days)**: "Credentials are X months old. Consider rotating with /portal credentials <slug>."
+
+Limit to 3 suggestions per portal maximum. Prioritize by impact.
+
+### Step 6: Summarize
+
+The footer line provides the aggregate view:
+- Total portals count
+- Average health score across all portals
+- Count of portals needing attention (health < 5.0)
+
+If all portals are healthy (score >= 7.0), add a positive note: "All portals healthy. Nice work."
+
+If average health is below 5.0, flag it: "Overall health is low. Focus on the flagged portals above."
+
+## Health Score Interpretation
+
+Provide this legend if the user asks what the scores mean or on first use:
+
+- **8-10**: Excellent. Portal is active, content is fresh, credentials are current.
+- **5-7.9**: Okay. Some areas could use attention but the portal is functional.
+- **Below 5**: Needs attention. The portal may be stale, unused, or missing key components.
+
+## Conventions
+
+- Always show all active portals. Do not filter or paginate -- the dashboard should be a complete picture.
+- Sort by health score ascending (worst first) so the portals needing attention are at the top.
+- Use relative time for "Last Login" column ("2 days ago", "3 weeks ago", "Never") for quick scanning.
+- Use double-line box drawing (`═`) for outer borders and single-line (`─`) for internal dividers and the "needs attention" section.
+- The dashboard should fit within 80 columns if possible. Truncate company names if needed.
+- If learnings indicate the user checks status regularly, skip the health score legend and just show the dashboard.
+
+## Error Handling
+
+- If the preamble fails, stop and display the error.
+- If the list query succeeds but analytics queries fail for some portals, still show the dashboard with available data. Mark missing analytics as "N/A" rather than failing the whole dashboard.
+- If all queries fail, show the error and suggest checking the database connection.
+
+## Dashboard Refresh
+
+The status dashboard is a point-in-time snapshot. It does not auto-refresh or watch for changes. If the user wants to monitor portal health over time, suggest running `/portal status` periodically (e.g., weekly) or setting up a scheduled task.
+
+If learnings indicate the user runs status checks regularly, track the trend: "Average health this week: 6.2/10 (up from 5.5/10 last week)." This requires comparing against previous status check results stored in learnings.
+
+## Health Score Calibration
+
+The health scoring weights are intentionally opinionated. They reflect what matters for a client portal product:
+
+- **Activity (30%)** is weighted highest because the primary purpose of a portal is client engagement. A portal with no views is not serving its purpose.
+- **Content recency (30%)** is equally weighted because stale content erodes trust. If a client sees the same content from months ago, they stop checking.
+- **Credential freshness (20%)** matters for security hygiene. Old credentials are more likely to be compromised or forgotten.
+- **Has files (20%)** is a completeness signal. Portals with documents tend to have higher engagement because they give clients a reason to return.
+
+If the user disagrees with the weighting (e.g., "files aren't important for my portals"), note it as a learning for future reference but do not change the scoring algorithm at runtime. The scoring is consistent across all portals for comparability.
+
+## Telemetry
+
+If telemetry is enabled, the status skill records:
+
+```json
+{"skill":"portal-status","ts":"2026-04-07T12:00:00Z","duration_s":3,"outcome":"success","portal_count":3,"avg_health":5.8}
+```
+
+This helps track how often the user monitors their portals and whether overall health is trending up or down. No portal-specific data (slugs, company names) is included in telemetry.
+
+## Completion
+
+As a final step, log skill completion:
+
+```bash
+echo '{"skill":"portal-status","event":"completed","ts":"'$(date -u +%Y-%m-%dT%H:%M:%SZ)'"}' >> "$HOME/.showpane/timeline.jsonl" 2>/dev/null
+```
+
+## Related Skills
+
+- `/portal analytics <slug>` -- deep dive into a specific portal's analytics
+- `/portal list` -- simpler list without health scores
+- `/portal preview <slug>` -- open a portal to verify its content
+- `/portal credentials <slug>` -- set up or rotate credentials for a flagged portal

package/bundle/toolchain/skills/portal-update/SKILL.md

@@ -0,0 +1,348 @@
+---
+name: portal-update
+description: |
+  Edit existing portal content — add tabs, update text, change structure, or refresh after a new meeting.
+  Trigger phrases: "update portal", "edit portal", "change the portal", "add a tab to", "update content for". (showpane)
+allowed-tools: [Bash, Read, Write, Edit, Glob, Grep]
+---
+
+## Preamble (run first)
+
+```bash
+# Read config
+CONFIG="$HOME/.showpane/config.json"
+if [ ! -f "$CONFIG" ]; then
+  echo "Showpane not configured. Run /portal setup first."
+  exit 1
+fi
+APP_PATH=$(python3 -c "import json; d=json.load(open('$CONFIG')); print(d.get('app_path',''))" 2>/dev/null)
+DEPLOY_MODE=$(python3 -c "import json; d=json.load(open('$CONFIG')); print(d.get('deploy_mode','docker'))" 2>/dev/null)
+ORG_SLUG=$(python3 -c "import json; d=json.load(open('$CONFIG')); print(d.get('orgSlug','') or d.get('org_slug',''))" 2>/dev/null)
+APP_PATH="${SHOWPANE_APP_PATH:-$APP_PATH}"
+if [ -f "$APP_PATH/.env" ]; then set -a && source "$APP_PATH/.env" && set +a; fi
+DATABASE_URL="${DATABASE_URL:-}"
+if [ ! -d "$APP_PATH/node_modules/.prisma" ]; then
+  echo "App dependencies not installed. Run: cd $APP_PATH && npm install"
+  exit 1
+fi
+SKILL_DIR="${SHOWPANE_TOOLCHAIN_DIR:-$HOME/.showpane/current}"
+SKILL_VERSION=$(cat "$SKILL_DIR/VERSION" 2>/dev/null || echo "unknown")
+echo "SHOWPANE: v$SKILL_VERSION | MODE: $DEPLOY_MODE | APP: $APP_PATH"
+LEARN_FILE="$HOME/.showpane/learnings.jsonl"
+[ -f "$LEARN_FILE" ] && echo "LEARNINGS: $(wc -l < "$LEARN_FILE" | tr -d ' ') loaded" || echo "LEARNINGS: 0"
+
+# Predictive next-skill suggestion
+if [ -f "$HOME/.showpane/timeline.jsonl" ]; then
+  _RECENT=$(grep '"event":"completed"' "$HOME/.showpane/timeline.jsonl" 2>/dev/null | tail -3 | grep -o '"skill":"[^"]*"' | sed 's/"skill":"//;s/"//' | tr '\n' ',' | sed 's/,$//')
+  [ -n "$_RECENT" ] && echo "RECENT_SKILLS: $_RECENT"
+fi
+
+# Search relevant learnings
+LEARN_FILE="$HOME/.showpane/learnings.jsonl"
+if [ -f "$LEARN_FILE" ]; then
+  _LEARN_COUNT=$(wc -l < "$LEARN_FILE" 2>/dev/null | tr -d ' ')
+  echo "LEARNINGS: $_LEARN_COUNT entries"
+  if [ "$_LEARN_COUNT" -gt 0 ] 2>/dev/null; then
+    echo "RECENT_LEARNINGS:"
+    tail -5 "$LEARN_FILE" 2>/dev/null
+  fi
+fi
+
+# Track skill execution
+SHOWPANE_TIMELINE="$HOME/.showpane/timeline.jsonl"
+mkdir -p "$(dirname "$SHOWPANE_TIMELINE")"
+echo '{"skill":"portal-update","event":"started","ts":"'$(date -u +%Y-%m-%dT%H:%M:%SZ)'"}' >> "$SHOWPANE_TIMELINE" 2>/dev/null
+```
+
+If RECENT_SKILLS is shown, suggest the likely next skill:
+- After portal-create → suggest /portal-preview
+- After portal-preview → suggest /portal-deploy or /portal-share
+- After portal-deploy → suggest /portal-status or /portal-verify
+- After portal-setup → suggest /portal-create
+- After portal-credentials → suggest /portal-share
+- After portal-update → suggest /portal-deploy
+
+If RECENT_LEARNINGS is shown, review them before proceeding. Past learnings may contain
+relevant warnings or tips for this operation. Apply them where relevant but don't
+mention them unless they directly affect the current task.
+
+## Steps
+
+### Step 1: Identify the portal to edit
+
+If the user provided a slug (e.g., `/portal update acme-health`), use it. Otherwise, ask which portal to update.
+
+Verify the portal exists by checking for the client component file:
+
+```bash
+ls "$APP_PATH/src/app/(portal)/client/<slug>/<slug>-client.tsx" 2>/dev/null
+```
+
+If the file doesn't exist, inform the user and suggest `/portal create <slug>` instead. If the slug directory exists but the client file has a different name, list the directory contents to find the correct file.
+
+### Step 2: Read the existing portal
+
+Read the full client component file:
+
+```bash
+cat "$APP_PATH/src/app/(portal)/client/<slug>/<slug>-client.tsx"
+```
+
+Also read the page.tsx for completeness:
+
+```bash
+cat "$APP_PATH/src/app/(portal)/client/<slug>/page.tsx"
+```
+
+Parse and understand the current portal structure:
+- How many tabs exist and what are their IDs and labels?
+- What content is in each tab?
+- What PortalShell props are set?
+- What icons are imported?
+
+### Step 3: Present current structure
+
+Show the user a concise summary of the portal's current state:
+
+```
+Portal: acme-health (Acme Health)
+
+  Tabs:
+    1. overview — "Services overview" (Presentation icon)
+    2. meetings — "Meetings" (CalendarDays icon)
+    3. documents — "Documents" (FileText icon, amber badge)
+
+  Contact: Jane Smith (Account Manager)
+  Last updated: 2 April 2026
+```
+
+This gives the user context before they describe what to change.
+
+### Step 4: Scope lock
+
+**CRITICAL: Only edit files within the portal's own directory.**
+
+Allowed files:
+- `$APP_PATH/src/app/(portal)/client/<slug>/page.tsx`
+- `$APP_PATH/src/app/(portal)/client/<slug>/<slug>-client.tsx`
+- Any other files within `$APP_PATH/src/app/(portal)/client/<slug>/`
+
+Do NOT modify:
+- `$APP_PATH/src/components/portal-shell.tsx` or any shared components
+- Other portals' directories
+- Files in `$APP_PATH/src/lib/`
+- Any files outside the portal's directory
+
+If the user's request would require changes to shared components, explain that this is outside the scope of a portal update and suggest they make those changes separately.
+
+### Step 5: Check learnings for user preferences
+
+Before making changes, read any relevant learnings from the learnings file:
+
+```bash
+if [ -f "$HOME/.showpane/learnings.jsonl" ]; then
+  grep '"portal-update"\|"portal-create"' "$HOME/.showpane/learnings.jsonl" | tail -10
+fi
+```
+
+Look for patterns that inform how to make edits:
+- Tab preferences (how many tabs the user typically wants)
+- Content density preferences (sparse vs. detailed)
+- Styling preferences (color accents, badge usage)
+- Structural patterns (timeline vs. bullet list for next steps)
+
+Apply these preferences when generating new content, but do not mention them to the user unless relevant.
+
+### Step 6: Understand the requested changes
+
+Ask the user what they want to change. Common requests and how to handle them:
+
+**Adding a new tab:**
+1. Ask for the tab name and what content it should contain
+2. Create a new function component for the tab content (e.g., `function PricingTab()`)
+3. Add the tab to the `tabs` array in the exported component
+4. Import any new icons needed
+5. Keep the tab count at or below 6
+
+**Updating existing content:**
+1. Identify which tab and section to update
+2. Make the targeted edit
+3. Preserve the existing structure and styling
+
+**Adding meeting notes from a new meeting:**
+1. If a transcript is provided (from Granola or pasted), analyze it for new discussion points, action items, and documents
+2. Add a new meeting section to the Meetings tab using the collapsible `<details>` pattern
+3. Update the Next Steps tab if new action items were discussed
+4. Update `lastUpdated` to today's date
+
+**Changing the tab order:**
+1. Reorder the `tabs` array — but keep overview/welcome as the first tab
+2. Update the `hideFooterOnTab` prop if the first tab changes
+
+**Removing a tab:**
+1. Remove the tab from the `tabs` array
+2. Remove the corresponding function component
+3. Clean up unused icon imports
+4. Ensure at least 2 tabs remain
+
+**Updating contact info or metadata:**
+1. Update the relevant PortalShell props
+2. Update any inline mentions of the contact in tab content
+
+### Step 7: Make the edits
+
+Apply the changes to the client component file. Follow the same conventions as `/portal create`:
+
+- Cards: `rounded-2xl border bg-white shadow-sm`
+- Card padding: `p-5 sm:p-6`
+- Section headings: `text-base font-bold tracking-tight text-gray-900`
+- Body text: `text-sm leading-relaxed text-gray-600`
+- Small text: `text-xs text-gray-500`
+- Responsive: use `sm:` breakpoints
+- Icons from `lucide-react` only
+
+When adding new content, match the visual weight and density of existing tabs. A portal with sparse, clean tabs should get sparse, clean new content — not suddenly dense data tables.
+
+### Step 8: Show diff before confirming
+
+After making edits, show the user a summary of what changed:
+
+- Which tabs were added, removed, or modified
+- What content was updated
+- Any prop changes on PortalShell
+
+If using git, show the actual diff:
+
+```bash
+cd "$APP_PATH" && git diff "src/app/(portal)/client/<slug>/"
+```
+
+Ask the user to confirm the changes look correct before considering the update complete.
+
+### Step 9: Update lastUpdated
+
+Update the `lastUpdated` prop on PortalShell to today's date in the format "7 April 2026". This signals to the client that the portal has fresh content.
+
+### Step 10: Open preview
+
+Check if the dev server is running:
+
+```bash
+lsof -i :3000 -sTCP:LISTEN -t 2>/dev/null
+```
+
+If running, open the portal:
+
+```bash
+open "http://localhost:3000/client/<slug>"
+```
+
+If a specific tab was updated, deep-link to it:
+
+```bash
+open "http://localhost:3000/client/<slug>#<tab_id>"
+```
+
+If not running, suggest starting the dev server with `/portal dev`.
+
+### Step 11: Record learning
+
+If the update reveals a pattern or preference, record it:
+
+```bash
+echo '{"skill":"portal-update","key":"<pattern>","insight":"<observation>","confidence":7,"ts":"'$(date -u +%Y-%m-%dT%H:%M:%SZ)'"}' >> "$HOME/.showpane/learnings.jsonl"
+```
+
+Examples of useful learnings:
+- "User prefers 3-tab portals over 5-tab"
+- "User always includes a Documents tab"
+- "User prefers numbered next steps over bullet points"
+- "User likes amber badges on action-required tabs"
+
+## Granola Enrichment for Updates
+
+When the user says something like "update the portal with the latest meeting" or "add notes from today's call", attempt Granola MCP integration:
+
+1. Try `list_meetings` to get recent meetings
+2. If available, show recent meetings and ask which one to add
+3. If selected, pull the transcript with `get_meeting_transcript`
+4. Analyze the transcript for new discussion points, action items, and documents
+5. Add a new meeting section to the Meetings tab (or create the tab if it doesn't exist)
+6. Update the Next Steps tab with any new action items
+7. Update `lastUpdated` to today's date
+
+If Granola is not available, ask the user to paste the transcript or describe the changes manually. Never fail because Granola is unavailable.
+
+## Content Pattern Reference
+
+When adding new content, use these patterns to match the existing portal style:
+
+**Meeting notes section** (collapsible):
+```tsx
+<MeetingSection title="Follow-up Call" defaultOpen={true}>
+  <ul className="space-y-2 text-sm text-gray-600">
+    <li className="flex gap-2.5">
+      <span className="mt-1.5 h-1.5 w-1.5 shrink-0 rounded-full bg-primary/60" />
+      Discussion point text here
+    </li>
+  </ul>
+</MeetingSection>
+```
+
+**Action item with status**:
+```tsx
+<li className="flex items-stretch gap-3 sm:gap-4">
+  <div className="flex flex-col items-center">
+    <span className={cn(
+      "flex h-6 w-6 shrink-0 items-center justify-center rounded-full text-[11px] font-semibold",
+      done ? "bg-green-500 text-white" : "bg-gray-900 text-white"
+    )}>
+      {done ? "✓" : index + 1}
+    </span>
+  </div>
+  <div className="pb-5">
+    <p className="text-sm font-semibold text-gray-900">Action title</p>
+    <p className="mt-0.5 text-sm leading-relaxed text-gray-500">Details here</p>
+  </div>
+</li>
+```
+
+**Document download card**:
+```tsx
+<div className="flex flex-col gap-4 sm:flex-row sm:items-center sm:justify-between">
+  <div className="flex items-start gap-3">
+    <FileText className="mt-0.5 h-5 w-5 shrink-0 text-gray-400" />
+    <div>
+      <p className="text-sm font-medium text-gray-900">Document title</p>
+      <p className="mt-1 text-sm text-gray-500">Description or instructions</p>
+    </div>
+  </div>
+  <button type="button" className="flex w-full items-center justify-center gap-1.5 rounded-lg bg-gray-900 px-5 py-2 text-xs font-semibold text-white transition-colors hover:bg-gray-800 sm:w-auto">
+    <Download className="h-3.5 w-3.5" />
+    Download PDF
+  </button>
+</div>
+```
+
+## Completion
+
+As a final step, log skill completion:
+
+```bash
+echo '{"skill":"portal-update","event":"completed","ts":"'$(date -u +%Y-%m-%dT%H:%M:%SZ)'"}' >> "$HOME/.showpane/timeline.jsonl" 2>/dev/null
+```
+
+## Conventions
+
+- Scope lock: ONLY edit files in `$APP_PATH/src/app/(portal)/client/<slug>/`
+- Never modify shared components, other portals, or lib files
+- Always show the diff to the user before considering the update complete
+- Preserve existing styling patterns — match the visual density of existing tabs
+- Update `lastUpdated` on every content change
+- Keep tab count between 2 and 6
+- First tab must always be overview/welcome
+- Follow the same Tailwind class conventions as `/portal create`
+- If the user's request is ambiguous, ask for clarification rather than guessing
+- When adding meeting notes, use the collapsible `<details>` pattern from the example portal
+- When the user asks to "refresh" a portal, they typically mean update `lastUpdated` and add new content from a recent meeting — treat this as a meeting enrichment flow
+- If a portal has grown to 6 tabs and the user wants to add more, suggest consolidating related tabs instead of exceeding the maximum