[camera_andriod_camerax] Add gspencergoog/write-prose skill

packages/camera/camera_android_camerax/.agents/skills/write-prose

@@ -0,0 +1 @@
+../../../../../third_party/skill-repos/gspencergoog/.agents/skills/write-prose

third_party/skill-repos/gspencergoog/.agents/skills/write-prose/SKILL.md

@@ -0,0 +1,84 @@
+---
+name: write-prose
+description: Master prose writing and orchestration skill for creating clear, plain, accessible, and natural human writing. Synthesizes ISO 24495-1:2023, W3C Cognitive Accessibility Guidance, Plain Writing Act, and Simplified Technical English (STE) standards. Use when writing, drafting, editing, or reviewing reports, PR descriptions, commit messages, API docstrings, READMEs, architecture documents, user guides, prompts, or general technical prose.
+---
+
+# Master Prose Writing & Orchestration (`write-prose`)
+
+> [!CAUTION]
+> **MANDATORY LINGUISTIC AUDIT**
+> Language models naturally default to pre-trained "AI-isms" (*delve, leverage, seamless, robust, pivotal, testament, not only... but also*). You MUST actively execute the Two-Pass Drafting Protocol below to audit and replace machine-generated fluff before producing final output.
+
+> [!IMPORTANT]
+> **WORKSPACE HYGIENE & FILE LOCATION RULES**
+> - **No Repo Pollution**: Never create temporary draft files or scratch markdown in the project repository root or source directories.
+> - **Temporary Drafts**: Store intermediate drafts, multi-pass review files, or scratch notes in the conversation scratch directory: `<appDataDir>/brain/<conversation-id>/scratch/`.
+> - **Final Artifacts**: Write persistent, user-facing markdown reports or documents to the conversation artifacts directory: `<appDataDir>/brain/<conversation-id>/`.
+
+This skill serves as the central source of truth for clear, plain, accessible, and natural human writing across all technical and non-technical documents.
+
+## Procedural Workflow
+
+### Step 1: Context & Audience Inference
+Determine the target audience and document format:
+1. **Pull Requests / Commits**: Engineering peers $\rightarrow$ Focus on "Why" over "How", factual tone, no fluff.
+2. **API Documentation / Docstrings**: API consumers $\rightarrow$ Third-person singular verbs, concise summaries, clear parameter prose.
+3. **User Guides / Tutorials**: End users $\rightarrow$ Direct second-person ("you"), short critical paths, explicit step-by-step instructions.
+4. **Architecture / Design RFCs**: Team leads & stakeholders $\rightarrow$ Clear tradeoffs, decision-first layout, plain language.
+5. **Prompts & System Instructions**: AI Agents / LLMs $\rightarrow$ Imperative tone, XML tags, positive directives, assume high baseline knowledge (name concepts without explaining them).
+
+> [!NOTE]
+> If the target audience or document context is ambiguous, use `ask_question` to clarify before drafting.
+
+For detailed audience templates and tone matrices, see [references/audiences.md](references/audiences.md).
+
+---
+
+### Mode A: Writing & Drafting New Prose
+
+#### Step 2: Sub-Skill Coordination
+For specialized document types, delegate content gathering to domain skills while enforcing `write-prose` quality standards:
+- **Pull Request Descriptions**: Refer to [`write-pr-description`](../write-pr-description/SKILL.md) for diff structure and testing steps.
+- **Commit Messages**: Refer to [`commit-changes`](../commit-changes/SKILL.md) for conventional commit formatting.
+- **Code & API Documentation**: Refer to [`code-documentation`](../code-documentation/SKILL.md) for docstring and tag conventions.
+- **AI Prompts & Skill Instructions**: Refer to Section 7 in [`references/standards.md`](references/standards.md#7-prompt-design-standards-for-llm-audiences) for XML tagging, primacy placement, and token conservation.
+
+#### Step 3: Apply Plain Writing & Accessibility Standards
+Before writing, consult [references/standards.md](references/standards.md) to apply core principles from:
+- **ISO 24495-1:2023**: Ensure content is relevant, findable, understandable, and usable.
+- **W3C Cognitive Accessibility (COGA)**: Use clear words, literal language, short text, separate steps, short critical paths, and no reliance on memory.
+- **Plain Writing Act**: Ensure immediate first-reading clarity using active voice and short sentences (15–20 words max).
+- **Simplified Technical English (STE / ASD-STE100)**: Use controlled vocabulary, explicit sequential steps, max 3 nouns per cluster, and warnings before actions.
+
+#### Step 4: Two-Pass Drafting & Anti-AI-ism Self-Correction
+Execute this mandatory two-pass procedure before finalizing output:
+
+1. **Pass 1 (Content Draft)**: Draft the response focusing on technical accuracy, structure, and domain content.
+2. **Pass 2 (Linguistic Inspection & Rewrite)**:
+   - Scan the draft line-by-line against the **Positive Replacement Pairs** in [references/standards.md](references/standards.md#61-positive-replacement-pairs-banned-words-mappings).
+   - Flag and replace any banned verbs (*delve, leverage, foster, cultivate, maximize, democratize, resonate, encompass, bridge, underscore*).
+   - Replace vague adjectives (*robust, seamless, pivotal, crucial, holistic, intuitive*) with **specific physical/technical behaviors** (e.g. replace *"robust error handling"* with *"retries failed HTTP requests up to 3 times"*).
+   - Eliminate copula substitutions (*"serves as"* $\rightarrow$ *"is"*), negative parallelism (*"not only... but also"*), and rule-of-three lists.
+3. **Output**: Present only the polished, post-audit prose.
+
+---
+
+### Mode B: Reviewing & Auditing Existing Prose
+
+When the user asks to review, audit, or critique an existing document, PR description, or prompt:
+
+1. **Run the Statistical Analyzer**:
+   Execute the analyzer script on the target file:
+   ```bash
+   python3 /usr/local/google/home/gspencer/.gemini/config/skills/write-prose/scripts/analyze_prose.py <path-to-file>
+   ```
+2. **Evaluate Output Metrics**:
+   - Check total word count, sentence count, median sentence length, and paragraph stats.
+   - Note any sentences exceeding **25 words**, paragraphs exceeding **4 sentences**, or **banned AI words** returned by the script.
+3. **Generate Audit Report Table**:
+   Output a clear feedback report detailing findings and concrete fixes:
+
+   | Line / Location | Issue / Violation | Standard Violated | Suggested Plain Language Fix |
+   | :--- | :--- | :--- | :--- |
+   | Line 12 | *"serves as a robust framework"* | Anti-AI-ism / Copula Sub | *"is a framework that retries HTTP requests"* |
+   | Line 34 | Sentence length (42 words) | STE / Plain Language | Split into two sentences ($\le 20$ words each). |

third_party/skill-repos/gspencergoog/.agents/skills/write-prose/references/audiences.md

@@ -0,0 +1,118 @@
+# Audience & Voice Matrix (`audiences.md`)
+
+This guide provides concrete matrices and **one-shot reference examples** demonstrating how the same technical concept is adapted across 5 distinct audiences.
+
+---
+
+## 1. Audience Matrix & Rule Adaptations
+
+| Audience | Primary Goal | Voice / Person | Verb & Tense Style | Structural Focus |
+| :--- | :--- | :--- | :--- | :--- |
+| **Peer Engineers** | PR descriptions, commit logs, code reviews | Factual / Impersonal | Past-tense for changes (*"Added"*, *"Fixed"*); Present for logic intent (*"Why"* over *"How"*). | Summary $\rightarrow$ Logic Changes $\rightarrow$ Impact $\rightarrow$ Testing Steps. |
+| **API Consumers** | Library docs, docstrings, SDK references | Third-person neutral | 3rd-person singular present (*"Calculates..."*, *"Retries..."*); Booleans start with *"Whether..."*. | 1-Sentence Summary $\rightarrow$ Parameter Prose $\rightarrow$ Usage Code Sample. |
+| **End Users / Devs** | Tutorials, user guides, setup docs | Direct second-person ("you") | Imperative action verbs (*"Open"*, *"Configure"*); 1 action per step. | Prerequisites $\rightarrow$ Numbered Steps $\rightarrow$ Expected Result. |
+| **Leadership / RFCs** | System designs, RFCs, technical proposals | Objective / Analytical | Present tense; decision-first layout. | Executive Summary $\rightarrow$ Proposal $\rightarrow$ Trade-offs Table $\rightarrow$ Migration. |
+| **AI Agents / LLMs** | System prompts, agent skills, tool directives | Imperative / Unambiguous | Direct imperative commands (*"Execute"*, *"Return"*); positive action directives. | Role Anchor $\rightarrow$ XML Delimiters $\rightarrow$ Guardrails $\rightarrow$ Examples. |
+
+---
+
+## 2. One-Shot Reference Examples (Same Topic, 5 Audiences)
+
+**Scenario**: Adding exponential backoff retry logic to an HTTP network service client.
+
+### Example A: Peer Engineers (PR Description)
+
+```markdown
+## Summary
+Adds automatic HTTP retry logic with exponential backoff to `HttpClient` to prevent transient network dropouts from failing user requests.
+
+## Changes
+* Wrapped `HttpClient.send()` in a retry loop using `ExponentialBackoff`.
+* Added `maxRetries` (default: 3) and `initialDelayMs` (default: 200ms) parameters to `HttpClientConfig`.
+* Retries only on HTTP 502, 503, 504, and socket timeout exceptions.
+
+## Testing
+* Added unit tests in `test/http_client_test.dart` verifying backoff delays: 200ms, 400ms, 800ms.
+* Verified that HTTP 4xx errors fail immediately without retrying.
+```
+
+---
+
+### Example B: API Consumers (Docstrings / API Reference)
+
+```dart
+/// Sends an HTTP request and retries transient failures using exponential backoff.
+///
+/// Retries up to [HttpClientConfig.maxRetries] times when encountering HTTP 502,
+/// 503, or 504 status codes, or network socket timeouts. Throws [HttpException]
+/// if all retries fail or if a non-retriable error (e.g. 4xx) occurs.
+///
+/// Usage:
+/// ```dart
+/// final response = await client.send(request);
+/// ```
+Future<HttpResponse> send(HttpRequest request);
+```
+
+---
+
+### Example C: End Users / Developers (User Guide / Setup Doc)
+
+```markdown
+## Configuring Automatic Retries
+
+You can configure the client to retry failed requests automatically when temporary network errors occur.
+
+1. Open your project configuration file (`config.yaml`).
+2. Add the `retry_policy` block to your network settings:
+
+```yaml
+network:
+  max_retries: 3
+  initial_delay_ms: 200
+```
+
+3. Save the file and restart your application service.
+```
+
+---
+
+### Example D: Leadership / RFCs (System Design / RFC)
+
+```markdown
+# RFC: Network Client Resilience & Transient Failure Handling
+
+## Executive Summary
+We propose introducing exponential backoff retries to the core HTTP client. This will reduce user-facing network error spikes by an estimated 80% during transient cloud gateway dropouts.
+
+## Proposed Design & Trade-offs
+
+| Option | Implementation Cost | Latency Impact | Resilience |
+| :--- | :--- | :--- | :--- |
+| **1. No Retries (Current)** | Zero | 0ms added | Poor (Errors surface immediately) |
+| **2. Exponential Retries (Proposed)** | Low (2 days) | +200ms–1400ms on transient failures | High (Recovers from transient outages) |
+
+## Migration & Risk
+This change is non-breaking. Default retry values (3 attempts, 200ms initial delay) apply automatically without configuration changes.
+```
+
+---
+
+### Example E: AI Agents / LLMs (System Prompt Directive)
+
+```markdown
+<role>
+You are an expert networking engineer assisting with HTTP client resilience.
+</role>
+
+<instructions>
+When configuring retry logic, enforce exponential backoff using these parameters:
+1. Set initial delay to 200ms with a multiplier of 2.0.
+2. Limit retries strictly to HTTP 502, 503, 504, and socket timeouts.
+3. Fail non-retriable HTTP 4xx status codes immediately.
+</instructions>
+
+<output_format>
+Return client configuration as a YAML block formatted inside ```yaml code fences.
+</output_format>
+```