Wilder1222/style-capture

<!-- Inlined into every SKILL.md via {{PREAMBLE_CORE}}. Keep ≤30 lines. -->

Preamble (Core)

Status protocol — end every session with one of: DONE (evidence provided) · DONE_WITH_CONCERNS (list each) · BLOCKED (state what blocks you) · NEEDS_CONTEXT (state what you need).

Auto-advance — pipeline: THINK → PLAN → REVIEW → BUILD → VERIFY → RELEASE. Only human gate is spec approval at THINK. On DONE at other stages, print [STAGE] DONE -> advancing to [NEXT-STAGE] and invoke the next skill. On any non-DONE status at any stage, STOP.

Output directory — all artifacts go in docs/superomni/<kind>/<kind>-[branch]-[session]-[date].md. See CLAUDE.md for the full directory map.

TACIT-DENSE — before high-tacit decisions, classify D1 (domain expertise) · D2 (user-facing UX) · D3 (team culture) · D4 (novel pattern). On hit, output TACIT-DENSE [D#]: [question] — My default: [recommendation]. See reference for actions.

Anti-sycophancy — take a position on every significant question. Name flaws directly. No filler ("that's interesting", "you might consider", "that could work").

Telemetry (local only) — at session end, log bin/analytics-log. Nothing leaves the machine.

See preamble-ref.md for detailed protocols.

Style Capture — Learn From Examples

Goal: Capture the user's implicit code style, architecture, and documentation preferences by analyzing examples they consider "good" and "bad" — then produce a reusable style profile that downstream skills reference.

Iron Law

LEARN FROM EXAMPLES, NOT JUST RULES.

Never ask "what's your style?" — ask "show me something you're satisfied with." Demonstration transfers tacit knowledge better than description (Polanyi's Paradox).

Good Example (Learn From Examples)

Agent: "Can you point me to 2-3 files in this project that you consider well-written?"
User: "Look at src/auth/middleware.ts and src/utils/validation.ts"
Agent: [reads both files, extracts patterns]
  -> Naming: camelCase functions, PascalCase types, descriptive 2-3 word names
  -> Comments: JSDoc on public APIs only, no inline comments
  -> Error handling: early returns, typed errors
  -> Saves to style profile with citations

Bad Example (AVOID)

Agent: "What's your preferred coding style?"
User: "Uh... clean code I guess?"
Agent: [applies generic 'clean code' assumptions]
  -> Writes overly abstracted code with dependency injection everywhere
  [VIOLATED: Asked for rules instead of examples — got vague answer, applied wrong assumptions]

Phase 1: Sample Collection

Prompt the user to provide examples. Key principle: concrete examples, not abstract descriptions.

Collecting Good Examples

Ask: "Can you point me to 3-5 files, code snippets, or references that you consider well-written or 'feel right'?"

Accepted input formats:

• File paths in the current project (preferred — most relevant)
• Pasted code snippets
• URLs to external repos or gists
• Names of libraries/projects they admire

If user provides fewer than 3: proceed but note gaps in the profile's "Unknown" section.

Collecting Bad Examples (Optional)

Ask: "Optionally — is there code in this project (or elsewhere) that you consider poorly written, or a style you want to avoid?"

1-2 contrast examples significantly improve feature extraction accuracy. If the user declines, proceed without.

Phase 1 Gate

• [ ] At least 2 "good" examples collected
• [ ] Examples are readable (file exists, code is accessible)
• FAIL -> ask for additional examples before proceeding

Phase 2: Feature Extraction

Analyze the collected examples across 6 style dimensions. For each dimension, compare good vs bad examples to identify the preference direction.

Extraction Dimensions

| Dimension | What to Look For | Signal Examples | |-----------|-----------------|-----------------| | Naming style | Variable/function/type naming patterns | camelCase vs snake_case, descriptive vs concise, prefix conventions | | Comment density | Where and how comments are used | JSDoc only, inline explanations, no comments, "why" vs "what" | | Function granularity | Function length and decomposition | Short single-purpose vs longer procedural, helper count | | Error handling | How errors are managed | Early returns, try/catch depth, error types, fallback strategies | | Abstraction level | DRY extremism vs concrete-first | Utility extraction threshold, interface vs implementation | | Documentation style | How docs/READMEs are written | What vs Why vs How emphasis, examples included, formal vs casual |

Extraction Process

For each dimension:

1. Scan all good examples for the pattern
2. Scan bad examples (if provided) for the anti-pattern
3. Rate confidence: HIGH (clear pattern in 3+ examples) / MEDIUM (2 examples) / LOW (1 example)
4. If confidence is LOW, mark as "Unknown — ask before assuming"

Phase 3: Style Profile Output

Generate the style profile document:

_SCOPE="${1:-project}"  # default scope is "project"; can be "frontend", "api", "docs"
mkdir -p docs/superomni/style-profiles
_PROFILE="docs/superomni/style-profiles/${_SCOPE}.md"

Write docs/superomni/style-profiles/<scope>.md:

# Style Profile: <scope>

**Generated:** [date]
**Based on:** [N] good examples, [N] bad examples
**Confidence:** [HIGH/MEDIUM/LOW overall]

## Confirmed Preferences

### Naming
- [Observed pattern with citation: "In `file.ts:12`, functions use camelCase..."]

### Comments
- [Observed pattern with citation]

### Function Granularity
- [Observed pattern with citation]

### Error Handling
- [Observed pattern with citation]

### Abstraction Level
- [Observed pattern with citation]

### Documentation
- [Observed pattern with citation]

## Reference Examples

### Good Examples
- `[file path]` — [why it's a good reference for: naming, error handling]
- `[file path]` — [why it's a good reference for: comments, granularity]

### Bad Examples (Contrast)
- `[file path]` — [what to avoid: over-abstraction, unclear naming]

## Unknown / Ask Before Assuming
- [Dimension where signal is insufficient — e.g., "No test files were provided; testing style is unknown"]
- [Dimension where examples conflict — e.g., "Two examples use different error patterns"]

Phase 4: Injection Verification

Distill the profile into a compact prompt fragment for downstream skill consumption:

_PROMPT_FILE="docs/superomni/style-profiles/prompt-${_SCOPE}.md"

Write docs/superomni/style-profiles/prompt-<scope>.md:

## Style Guidelines (from style profile)

Apply these preferences when writing code for this project:
- Naming: [1-line summary]
- Comments: [1-line summary]
- Functions: [1-line summary]
- Errors: [1-line summary]
- Abstraction: [1-line summary]
- Docs: [1-line summary]

When in doubt about style, check: docs/superomni/style-profiles/<scope>.md

Downstream Integration Check

Verify that the profile is discoverable by other skills:

# These skills should reference style profiles when they exist:
echo "Integration points:"
echo "  brainstorm     -> references profile for aesthetic decisions"
echo "  executing-plans -> references profile when writing code"
echo "  code-review    -> uses profile as review criteria"
echo "  self-improvement -> treats profile as improvement target"
ls docs/superomni/style-profiles/*.md 2>/dev/null

Style Profile Report

STYLE CAPTURE REPORT
════════════════════════════════════════
Scope:              [project / frontend / api / docs]
Good examples:      [N files/snippets analyzed]
Bad examples:       [N files/snippets analyzed]
Dimensions captured: [N/6]
Unknown dimensions: [list]
Profile saved:      docs/superomni/style-profiles/<scope>.md
Prompt fragment:    docs/superomni/style-profiles/prompt-<scope>.md
Status:             DONE | DONE_WITH_CONCERNS
Concerns:
  - [e.g., "Only 2 examples provided — LOW confidence on naming and comments"]
════════════════════════════════════════