@winspan/claude-forge 8.54.4 → 9.12.0

package/dist/skills/distilled/distilled-architecture-decision.md

@@ -0,0 +1,173 @@
+---
+name: distilled-architecture-decision
+version: 1.0.0-portable
+description: 'Distilled IT-universal skill: architecture decision records (portable, hand-rewritten 2026-05-27)'
+keywords:
+  - architecture
+  - adr
+  - decision
+  - design
+  - record
+  - architecture decision
+  - 架构决策
+  - 技术选型
+rubric_version: 2
+distilled_from:
+  - upstream: https://github.com/winspan/claude-forge.git
+    license: MIT
+    commit: 7d96b86c
+    paths:
+      - official/official-architecture-decision.md
+distilled_at: '2026-05-27T02:11:00.000Z'
+distilled_by: hand-rewrite (D4-reverse)
+it_universal_score: 4.5
+it_universal_dims:
+  d1: 1
+  d2: 1
+  d3: 1
+  d4: 1
+  d5: 0.5
+it_universal_rationale: ADR template + decision-record discipline; entirely process-level, stack-agnostic.
+is_stub: false
+---
+
+## Goal
+
+Capture every consequential technical decision as a short, dated, immutable record so that future maintainers can reconstruct **why** the system looks the way it does — not just what it does.
+
+## When to trigger
+
+- Choosing among multiple plausible technologies (framework, database, queue, build tool, runtime).
+- Drawing a system boundary (which service owns which data; what crosses an API).
+- Picking a protocol (REST vs gRPC vs message-bus; sync vs async).
+- A decision that will affect more than one module, team, or release cycle.
+- Reversing or superseding a prior architectural choice.
+- A design debate that has happened more than twice — write it down once and stop relitigating.
+
+Skip the ADR for: trivial style tweaks, single-file refactors, bug fixes, or anything that doesn't change the shape of the system.
+
+## Steps
+
+1. **Detect the decision moment.** When you notice yourself or a teammate weighing trade-offs that will outlive the current sprint, pause and open a new ADR file.
+
+2. **Pick the next number.** Use a monotonic counter (`ADR-0001`, `ADR-0002`, ...). Numbers are never reused, even for retired records. Store them in a known directory of the repo (a common convention is `docs/adr/`).
+
+3. **Fill the template** (see "Examples" for the canonical shape). The minimum sections are: Status, Context, Decision, Alternatives considered, Consequences. Keep each section short — usually one to four paragraphs.
+
+4. **Mark status honestly.** Start at `Proposed`. Once approved (whatever your team's bar is — a review, a meeting, a PR merge), change to `Accepted`. If later replaced, change to `Superseded by ADR-NNNN`. If retired without replacement, `Deprecated`.
+
+5. **Never edit an Accepted ADR's substance.** Typos are fine; rewriting the decision is not. If the decision changes, write a **new** ADR that supersedes the old one. The old record stays in the repo as historical context.
+
+6. **Cross-link.** When an ADR depends on, or invalidates, another, link both ways: ADR-0007 "supersedes ADR-0003"; ADR-0003 carries a note "superseded by ADR-0007".
+
+7. **Reference ADRs from code or PRs** when a non-obvious choice would otherwise confuse readers. A comment like `// see ADR-0012` is cheaper than a 20-line explanation that drifts out of date.
+
+## Anti-patterns
+
+- **Editing an Accepted ADR.** The record loses its truth value. If circumstances changed, supersede with a new ADR.
+- **ADRs that say "we chose X" without saying why.** The context and alternatives sections are the whole point — the choice itself is the cheap part.
+- **Writing an ADR after the fact** to rubber-stamp a decision already shipped. Better than nothing, but flag it as `Accepted (retroactive)` and acknowledge the alternatives were not really weighed.
+- **One giant ADR covering many decisions.** Split them. One ADR = one decision.
+- **Burying ADRs in a wiki nobody reads.** Keep them in the repo, next to the code, in a flat browsable directory.
+- **Status that lies.** A `Proposed` ADR that has been shipping for 6 months is not Proposed — fix the status.
+- **Skipping ADRs for "obvious" choices.** Often the obvious choice is obvious only to the original author; the record protects future maintainers from re-evaluating from scratch.
+
+## Success criteria
+
+- [ ] The repo has a known directory holding ADRs (e.g. `docs/adr/`), with a flat numbering scheme.
+- [ ] Every Accepted ADR has filled Context, Decision, Alternatives, and Consequences sections.
+- [ ] Status of every ADR matches reality (no stale `Proposed` records).
+- [ ] At least one ADR exists for every cross-module / cross-team choice made in the last release cycle.
+- [ ] Superseded ADRs link to their successors, and vice versa.
+- [ ] Code / PRs reference ADR numbers when explaining non-obvious choices.
+
+## Failure modes
+
+- **Decisions made in chat without a record.** When the third person asks "why are we using X?", that's the prompt — open an ADR retroactively and tag it.
+- **ADR explosion.** If you have 200 ADRs, you've blurred the line between "architecture decision" and "any decision". Tighten the trigger criteria; small decisions belong in code comments or PR descriptions, not ADRs.
+- **Two contradictory Accepted ADRs.** A symptom that nobody checked the existing record before writing the new one. Resolution: write a third ADR that explicitly supersedes the older one.
+- **Authors disagree on the decision.** Don't write a wishy-washy ADR. Record the dissent in the Alternatives section: "Option B preferred by A and C; Option A chosen because of X. See discussion thread Y."
+- **Decision turns out to be wrong.** That's fine — write a new ADR superseding the old one. The old ADR is not embarrassing; it's history. Editing it to hide the mistake is worse.
+
+## Examples
+
+### Canonical ADR template
+
+```markdown
+# ADR-0007: Use a message queue between the ingest and processor
+
+## Status
+Accepted (2026-04-12)
+
+## Context
+The ingest service produces ~10k events/min. The processor's throughput is variable
+because some events trigger expensive enrichment calls. Coupling them synchronously
+caused 99th-percentile latency spikes and cascading retries on the upstream caller.
+
+## Decision
+Insert a durable message queue between ingest and processor. Ingest writes, returns
+immediately; processor consumes at its own pace. At-least-once delivery; processor
+handles idempotency by event ID.
+
+## Alternatives considered
+- Direct HTTP with a larger thread pool in the processor: rejected — does not
+  bound memory; still vulnerable to processor outage causing data loss.
+- Persist events to the database; processor polls: rejected — DB becomes a queue,
+  and queries to drain the backlog conflict with the read workload.
+- Bounded in-process channel: rejected — does not survive process restarts.
+
+## Consequences
++ Ingest latency decoupled from processing latency.
++ Processor can be restarted / scaled independently.
+- New operational surface: queue health, lag monitoring, dead-letter handling.
+- Processor code must be idempotent; existing code is not, requiring refactor.
+- One extra hop adds ~10-30ms to end-to-end latency.
+```
+
+### A second example: superseding an earlier decision
+
+```markdown
+# ADR-0019: Switch from polling to push for cache invalidation
+
+## Status
+Accepted (2026-05-20). Supersedes ADR-0011.
+
+## Context
+ADR-0011 chose polling because the cache layer did not support push at the time.
+The cache vendor added a push API in their 4.0 release (2026-04). Polling now
+accounts for ~12% of read traffic against the cache and adds 30-second staleness.
+
+## Decision
+Subscribe to the cache push channel; remove the polling loop.
+
+## Alternatives considered
+- Keep polling, reduce interval: rejected — does not solve the staleness floor
+  and increases load.
+- Hybrid (push + slow poll as safety net): considered; reserved for ADR-0020
+  if observed push reliability drops below SLA.
+
+## Consequences
++ Staleness drops from 30s to <1s p99.
++ Read traffic to cache drops ~12%.
+- New dependency on push channel availability; requires monitoring.
+- Migration window: both polling and push run for one week before polling is
+  removed (see migration plan in PR #4421).
+```
+
+And ADR-0011 receives an edit (the only allowed kind of edit on an Accepted ADR) at the top of its Status line:
+
+```markdown
+## Status
+Accepted (2025-09-04). Superseded by ADR-0019 (2026-05-20).
+```
+
+## Adoption notes
+
+To put this into practice in any codebase:
+
+- Create the directory (commonly `docs/adr/`) and add a `README.md` explaining the convention.
+- Copy a template file as `docs/adr/template.md`. New ADRs start by copying it.
+- Add a one-liner to the project guide: "Cross-module decisions get an ADR before merging."
+- Pick a numbering policy and commit to it. Padded four-digit numbers (`ADR-0001`) sort cleanly and survive growth.
+- Optionally automate: a script that creates the next file with pre-filled date and number, or a CI check that PRs touching the design-doc directory must include an ADR when they change the architecture overview.
+- Pair this skill with the spec-driven design skill: a spec answers "what will we build"; an ADR answers "why is the building shaped this way". They are complementary, not redundant.

package/dist/skills/distilled/distilled-brainstorming.md

@@ -0,0 +1,79 @@
+---
+name: distilled-brainstorming
+version: 0.2.0-distilled
+description: 'Distilled IT-universal skill: brainstorming (score 3.5/5)'
+keywords:
+  - brainstorming
+rubric_version: 2
+distilled_from:
+  - upstream: https://github.com/obra/superpowers.git
+    license: MIT
+    commit: f2cbfbefebbfef77321e4c9abc9e949826bea9d7
+    paths:
+      - brainstorming/SKILL.md
+distilled_at: '2026-06-15T00:48:29.650Z'
+distilled_by: claude-code skill-distiller agent
+it_universal_score: 3.5
+it_universal_dims:
+  d1: 1
+  d2: 0.5
+  d3: 0.5
+  d4: 0.5
+  d5: 1
+it_universal_rationale: >-
+  Language-neutral design-before-code methodology with strong transferable principles (YAGNI,
+  one-question-at-a-time, hard-gate, spec self-review); only minor deductions for references to
+  project-specific skill names and file paths that are easily abstracted away.
+---
+
+# Brainstorming Ideas Into Designs
+
+## When to use
+- Before **any** creative or implementation work: new features, components, functionality changes, or behavioral modifications
+- Any time you have an idea but not yet a validated design
+- Especially when a "simple" task tempts you to skip design — that's when unexamined assumptions cost the most
+
+## Core idea
+Turn ideas into fully-formed, user-approved designs through structured collaborative dialogue before writing a single line of code. The process enforces a **hard gate**: no implementation until a design is presented and approved. Questions are asked one at a time to avoid overwhelming; two or three concrete approaches (with trade-offs) are proposed before settling; and the resulting spec goes through a self-review checklist before the user sees it. This discipline catches scope creep, conflicting assumptions, and accidental complexity early — when fixing them is cheap.
+
+## Steps
+
+1. **Explore project context** — Read existing files, docs, and recent commits before asking anything. Follow existing patterns.
+
+2. **Assess scope** — If the request spans multiple independent subsystems (e.g., "build a platform with chat, billing, and analytics"), flag this immediately and help decompose into sub-projects. Each sub-project gets its own design → plan → implementation cycle. Don't ask refinement questions about a project that first needs decomposition.
+
+3. **Offer visual companion** *(optional, own message)* — When upcoming questions will involve layouts, diagrams, or mockups, offer to show them visually (e.g., in a browser or rendered output). This offer must be its own message; wait for consent before continuing. Even after consent, only use visuals for questions that are genuinely visual — layouts, wireframes, architecture diagrams — not for conceptual or text-based trade-off choices.
+
+4. **Ask clarifying questions** — One question per message. Prefer multiple-choice when possible. Focus on: purpose, constraints, success criteria. If a topic needs more exploration, break it into sequential questions.
+
+5. **Propose 2–3 approaches** — Present options conversationally with trade-offs. Lead with your recommended option and explain why.
+
+6. **Present design sections** — Scale each section to its complexity (a few sentences for simple aspects; up to ~300 words for nuanced ones). Ask after each section whether it looks right before moving on. Be ready to revise.
+
+7. **Write design doc** — Save the validated spec to a `docs/specs/YYYY-MM-DD-<topic>-design.md` (or wherever your repo stores specs). Commit it to version control.
+
+8. **Spec self-review** — Before asking the user to review, check:
+   - **Placeholder scan**: any "TBD", "TODO", or vague requirements? Fill them in.
+   - **Internal consistency**: do sections contradict each other? Does architecture match feature descriptions?
+   - **Scope check**: is this focused enough for one implementation plan, or does it need decomposition?
+   - **Ambiguity check**: can any requirement be interpreted two ways? Pick one and make it explicit.
+   Fix issues inline; no need to re-review after fixing.
+
+9. **User reviews spec → transition to implementation planning** — Ask the user to review the spec file. If they request changes, make them and re-run the self-review. Only when they approve, proceed to create a detailed implementation plan.
+
+## Anti-patterns
+- **Skipping design for "simple" tasks** — Every project goes through this process. Simple projects are where unexamined assumptions cause the most waste. The design can be short, but it must exist and be approved.
+- **Multiple questions at once** — Overwhelming the user leads to shallow answers. One question, one message.
+- **Jumping to a single approach** — Always propose 2–3 with trade-offs. Forced comparison surfaces assumptions.
+- **Implementing before approval** — The hard gate is unconditional. No code, no scaffolding, no "just a quick prototype" until the design is approved.
+- **Proposing unrelated refactoring** — When working in an existing codebase, only include targeted improvements that directly serve the current goal. Stay focused.
+- **Treating all visual topics as requiring visuals** — "What personality should this UI have?" is a conceptual question; use text. "Which of these two layouts?" is a visual question; use a diagram. Topic ≠ medium.
+- **Skipping the decomposition check for large requests** — Spending clarifying questions on details of an oversized project that first needs to be split is wasted effort.
+
+## Design quality principles (carry into every spec)
+- **YAGNI ruthlessly** — Remove unnecessary features from all designs.
+- **Isolation and clear boundaries** — Break the system into units that each have one clear purpose, communicate through well-defined interfaces, and can be understood and tested independently. For each unit: what does it do, how do you use it, what does it depend on?
+- **Working in existing codebases** — Explore structure before proposing changes; follow existing patterns; improve code you're working in only when it directly affects the goal.
+
+## References
+- Upstream: https://github.com/obra/superpowers.git

package/dist/skills/distilled/distilled-brand-guidelines.md

@@ -0,0 +1,86 @@
+---
+name: distilled-brand-guidelines
+version: 0.2.0-distilled
+description: 'Distilled IT-universal skill: brand-guidelines (score 3/5)'
+keywords:
+  - brand
+  - guidelines
+rubric_version: 2
+distilled_from:
+  - upstream: https://github.com/anthropics/skills.git
+    license: Apache-2.0
+    commit: 690f15cac7f7b4c055c5ab109c79ed9259934081
+    paths:
+      - brand-guidelines/SKILL.md
+distilled_at: '2026-06-15T01:02:32.005Z'
+distilled_by: claude-code skill-distiller agent
+it_universal_score: 3
+it_universal_dims:
+  d1: 0.5
+  d2: 0.5
+  d3: 1
+  d4: 0.5
+  d5: 0.5
+it_universal_rationale: >-
+  Color tokens and type-scale rules are language/tool-agnostic; only the original python-pptx
+  implementation detail is language-specific and was stripped in distillation.
+---
+
+# Anthropic Brand Guidelines — Visual Reference
+
+## When to use
+- You need to produce any visual artifact (slides, reports, web pages, diagrams, data-viz) that should match Anthropic's official look-and-feel.
+- A user asks for brand colors, corporate color palette, or Anthropic typography.
+- You are post-processing or styling an existing artifact to bring it on-brand.
+- You are picking accent colors for charts, icons, or decorative shapes in an Anthropic context.
+
+## Core idea
+
+Anthropic's visual identity revolves around a warm neutral base (near-black / off-white / grays) with three accent colors (orange, blue, green) that cycle through non-text shapes. Typography is split into two roles: **Poppins** (or Arial fallback) for headings, **Lora** (or Georgia fallback) for body. The key principle is to keep backgrounds and text in the neutral palette and reserve accents for interactive or decorative elements, maintaining legibility at all times.
+
+## Color Tokens
+
+### Neutral Base
+
+| Role | Hex | Usage |
+|---|---|---|
+| Dark | `#141413` | Primary text; dark backgrounds |
+| Light | `#faf9f5` | Light backgrounds; text on dark |
+| Mid Gray | `#b0aea5` | Secondary / supporting elements |
+| Light Gray | `#e8e6dc` | Subtle background tints, dividers |
+
+### Accent Palette (cycle in order)
+
+| Name | Hex | Role |
+|---|---|---|
+| Orange | `#d97757` | Primary accent (CTA, highlights) |
+| Blue | `#6a9bcc` | Secondary accent |
+| Green | `#788c5d` | Tertiary accent |
+
+## Typography
+
+| Text Role | Font | Fallback |
+|---|---|---|
+| Headings (large / ≥ 24 pt) | Poppins | Arial |
+| Body text | Lora | Georgia |
+
+> Fonts should be pre-installed in the target environment for best results. The fallbacks (Arial / Georgia) are safe on all platforms.
+
+## Steps
+
+1. **Establish the background** — choose `#faf9f5` (light) or `#141413` (dark) as the canvas; avoid mixing both on the same surface.
+2. **Apply text colors** — use Dark `#141413` on light backgrounds, Light `#faf9f5` on dark backgrounds; use Mid Gray `#b0aea5` for secondary/caption text.
+3. **Assign fonts** — headings at ≥ 24 pt → Poppins/Arial; all body copy → Lora/Georgia.
+4. **Color decorative shapes** — cycle accent colors: first shape orange `#d97757`, second blue `#6a9bcc`, third green `#788c5d`, then repeat. Do not apply accents to large background areas.
+5. **Validate contrast** — confirm text-on-background meets WCAG AA (≥ 4.5:1 for body, ≥ 3:1 for large text). The defined neutral pairs all pass at normal usage sizes.
+6. **Trim non-brand colors** — remove any bright reds, purples, or generic blues that are not in the palette above.
+
+## Anti-patterns
+- **Using accents as backgrounds** — large orange/blue/green fills look off-brand; keep them to shapes, icons, and callout borders.
+- **Mixing font stacks arbitrarily** — using Poppins for body or Lora for headings breaks the typographic hierarchy.
+- **Pure black / pure white** — `#000000` / `#ffffff` are not in the palette; use `#141413` / `#faf9f5` instead.
+- **Skipping fallbacks** — always specify Arial after Poppins and Georgia after Lora so artifacts render correctly on systems without the custom fonts.
+- **More than three accent colors on a single page** — cycling works, but introducing additional off-palette colors dilutes the brand identity.
+
+## References
+- Upstream: https://github.com/anthropics/skills.git

package/dist/skills/distilled/distilled-canvas-design.md

@@ -0,0 +1,128 @@
+---
+name: distilled-canvas-design
+version: 0.2.0-distilled
+description: 'Distilled IT-universal skill: canvas-design (score 3.5/5)'
+keywords:
+  - canvas
+  - design
+rubric_version: 2
+distilled_from:
+  - upstream: https://github.com/anthropics/skills.git
+    license: Apache-2.0
+    commit: 690f15cac7f7b4c055c5ab109c79ed9259934081
+    paths:
+      - canvas-design/SKILL.md
+distilled_at: '2026-06-15T01:03:48.379Z'
+distilled_by: claude-code skill-distiller agent
+it_universal_score: 3.5
+it_universal_dims:
+  d1: 1
+  d2: 0.5
+  d3: 0.5
+  d4: 0.5
+  d5: 1
+it_universal_rationale: >-
+  Language-neutral visual design methodology (two-phase philosophy→canvas) transferable to any
+  creative/design output workflow regardless of toolchain or codebase
+---
+
+# Two-Phase Visual Design: Philosophy-First Canvas Creation
+
+## When to use
+- When asked to create a poster, piece of art, visual identity, or any static visual artifact
+- When the goal is expressive/artistic output (PNG, PDF, or similar) rather than functional UI
+- When an AI agent or designer needs a structured framework to avoid "decorated document" pitfalls
+- When quality bar is museum/magazine-grade, not clipart/template-grade
+
+## Core idea
+
+Great visual output requires separating the *thinking* phase from the *making* phase. First, articulate a named aesthetic movement (design philosophy) in 4–6 paragraphs covering space, color, material, rhythm, and composition. Only then execute the canvas, treating the philosophy as a scientific bible. Text on the canvas must be treated as a rare visual element—never explanatory paragraphs, only essential words integrated into the architecture. Expert craftsmanship is the non-negotiable standard: every alignment, color choice, and spacing decision should feel like it was labored over by someone at the top of their field.
+
+## Steps
+
+### Phase 1 — Design Philosophy Creation (output: `.md`)
+
+1. **Name the movement** (1–2 words): e.g., "Brutalist Joy", "Chromatic Silence", "Metabolist Dreams"
+
+2. **Write the philosophy** (4–6 paragraphs), covering each dimension exactly once:
+   - *Space and form*: How does the aesthetic treat negative space, volume, structure?
+   - *Color and material*: What palette logic or material sensibility governs the work?
+   - *Scale and rhythm*: How do elements grow, repeat, pulse, or breathe?
+   - *Composition and balance*: What governs arrangement—grid, organic, axial?
+   - *Visual hierarchy*: How does the eye move? What dominates, what recedes?
+
+3. **Repeat the craftsmanship imperative** multiple times within the philosophy:
+   > "meticulously crafted", "painstaking attention", "the product of deep expertise", "countless hours"
+
+4. **Keep it generic** (no mention of the specific output subject)—the philosophy should feel like it could apply to any artifact in that aesthetic tradition.
+
+5. **Leave interpretive room**: be specific about *direction*, not prescriptive about *every element*.
+
+### Phase 2 — Deduce the Subtle Reference
+
+Before drawing, identify the conceptual thread from the request:
+- This is the **soul** of the piece—the quiet DNA woven into composition, color, and form
+- It should be recognizable to those who know, invisible to those who don't
+- Think: *jazz musician quoting another song*—only insiders catch it, everyone else just hears great music
+
+### Phase 3 — Canvas Execution (output: `.pdf` or `.png`)
+
+6. **Ratio**: ~90% visual / 10% text (essential words only, never explanatory blocks)
+
+7. **Visual language of systematic observation**:
+   - Dense accumulation of marks, repeated elements, layered patterns
+   - Sparse clinical typography + systematic reference markers
+   - Treat the subject as if it were being documented by an imaginary discipline
+
+8. **Typography rules**:
+   - Use diverse, design-forward fonts (thin weight preferred)
+   - Type is *part of the art*, not typeset copy
+   - Nothing overlaps, nothing falls off canvas; every element has breathing room
+
+9. **Color**: Limited palette, intentional and cohesive; anchor with 1–2 subtle phrases or detail markers
+
+10. **Single page default** (unless multi-page is explicitly requested); treat it as one page of a coffee-table book
+
+### Phase 4 — Refinement Pass
+
+11. **Do not add more elements**; instead *refine* what exists:
+    - Make spacing more precise
+    - Make colors more cohesive
+    - Make composition more internally consistent with the philosophy
+    - Ask: *"How do I make what's already here more of a piece of art?"* before adding anything new
+
+12. **Final checklist**:
+    - All elements inside canvas boundaries with proper margins
+    - No overlaps anywhere
+    - Typography flawless
+    - Composition coherent with the stated philosophy
+
+### Multi-page Option (when requested)
+
+13. Bundle additional pages in the same PDF (or multiple PNGs)
+14. Each page: unique twist on the philosophy, not a repeat—like chapters in a visual story
+15. Pages should feel connected yet individually distinct
+
+## Anti-patterns
+
+- **Decorated document trap**: Adding text blocks with design "decoration" around them is not visual art—information must live in design, not paragraphs
+- **Literal interpretation**: The subtle reference should be *felt*, not *announced*; avoid illustrating the subject literally
+- **Adding to fix**: Refinement means subtraction and precision, not accumulation of new elements
+- **Font monotony**: One font throughout kills design sophistication; vary with intention
+- **Redundant philosophy**: Each design dimension (color, space, etc.) should appear once in the philosophy—repetition dilutes authority
+- **Amateur energy**: Cartoony shapes, clip-art icons, gradient noise—none of these belong; everything must justify its presence
+
+## Philosophy Examples (condensed)
+
+| Name | Core Visual Language |
+|---|---|
+| "Concrete Poetry" | Massive color blocks, sculptural typography, Brutalist spatial divisions, Polish poster meets Le Corbusier |
+| "Chromatic Language" | Color as information system; geometric precision; Josef Albers meets data viz; words only to anchor what color already shows |
+| "Analog Meditation" | Paper grain, ink bleeds, vast negative space; Japanese photobook aesthetic; text whispered in small restrained type |
+| "Organic Systems" | Rounded forms, natural clustering, color from nature through architecture; info through spatial diagrams, not text |
+| "Geometric Silence" | Grid-based precision, bold photography, dramatic negative space; Swiss formalism meets Brutalist material honesty |
+
+*Full philosophies are 4–6 substantial paragraphs each.*
+
+## References
+- Upstream: https://github.com/anthropics/skills.git

package/dist/skills/distilled/distilled-claude-api.md

@@ -0,0 +1,185 @@
+---
+name: distilled-claude-api
+version: 0.2.0-distilled
+description: 'Distilled IT-universal skill: claude-api (score 4/5)'
+keywords:
+  - claude
+  - api
+rubric_version: 2
+distilled_from:
+  - upstream: https://github.com/anthropics/skills.git
+    license: Apache-2.0
+    commit: 690f15cac7f7b4c055c5ab109c79ed9259934081
+    paths:
+      - claude-api/SKILL.md
+  - upstream: https://github.com/affaan-m/ECC.git
+    license: MIT
+    commit: 928076cc08cbb31e8549cea2883b4f51811de1c8
+    paths:
+      - api-connector-builder/SKILL.md
+  - upstream: https://github.com/affaan-m/ECC.git
+    license: MIT
+    commit: 928076cc08cbb31e8549cea2883b4f51811de1c8
+    paths:
+      - api-design/SKILL.md
+  - upstream: https://github.com/affaan-m/ECC.git
+    license: MIT
+    commit: 928076cc08cbb31e8549cea2883b4f51811de1c8
+    paths:
+      - x-api/SKILL.md
+  - upstream: https://github.com/affaan-m/ECC.git
+    license: MIT
+    commit: 928076cc08cbb31e8549cea2883b4f51811de1c8
+    paths:
+      - api-design/SKILL.md
+  - upstream: https://github.com/affaan-m/ECC.git
+    license: MIT
+    commit: 928076cc08cbb31e8549cea2883b4f51811de1c8
+    paths:
+      - api-connector-builder/SKILL.md
+  - upstream: https://github.com/affaan-m/ECC.git
+    license: MIT
+    commit: 928076cc08cbb31e8549cea2883b4f51811de1c8
+    paths:
+      - api-design/SKILL.md
+  - upstream: https://github.com/affaan-m/ECC.git
+    license: MIT
+    commit: 928076cc08cbb31e8549cea2883b4f51811de1c8
+    paths:
+      - x-api/SKILL.md
+  - upstream: https://github.com/affaan-m/ECC.git
+    license: MIT
+    commit: 928076cc08cbb31e8549cea2883b4f51811de1c8
+    paths:
+      - api-connector-builder/SKILL.md
+  - upstream: https://github.com/affaan-m/ECC.git
+    license: MIT
+    commit: 928076cc08cbb31e8549cea2883b4f51811de1c8
+    paths:
+      - api-design/SKILL.md
+  - upstream: https://github.com/affaan-m/ECC.git
+    license: MIT
+    commit: 928076cc08cbb31e8549cea2883b4f51811de1c8
+    paths:
+      - x-api/SKILL.md
+distilled_at: '2026-06-15T01:04:51.971Z'
+distilled_by: claude-code skill-distiller agent
+it_universal_score: 4
+it_universal_dims:
+  d1: 1
+  d2: 0.5
+  d3: 0.5
+  d4: 1
+  d5: 1
+it_universal_rationale: >-
+  Multi-language surface-selection methodology and agent-viability criteria are fully portable to
+  any codebase integrating the Anthropic Claude API, regardless of language, framework, or project
+  structure.
+---
+
+# Building Applications with the Anthropic Claude API
+
+## When to use
+- You are adding or modifying Claude/Anthropic SDK integration in any project
+- You need to choose between single API calls, tool-use workflows, or Managed Agents
+- You are migrating Claude model versions or tuning caching / streaming / thinking settings
+- You have questions about prompt caching, batch processing, tool use, or streaming in an Anthropic SDK project
+
+## Core idea
+
+All Claude API requests go through a single endpoint (`POST /v1/messages`). Tool use, output constraints, streaming, and caching are all features of this one endpoint — not separate APIs. The main architectural decision is **which surface** to use: a plain API call, a code-orchestrated tool-use workflow, or Anthropic-managed stateful agents (Managed Agents). Default to the simplest tier that meets your needs; only escalate to agents when the task genuinely requires open-ended, model-driven exploration. Always use the official Anthropic SDK for your language — never mix raw HTTP calls into an SDK project, and never fall back to OpenAI-compatible shims.
+
+## Steps
+
+### 1. Detect the project language
+
+Match project files to the correct SDK:
+
+| Signals | Language / SDK |
+|---|---|
+| `*.py`, `pyproject.toml`, `requirements.txt` | Python (`anthropic`) |
+| `*.ts`, `*.tsx`, `package.json`, `tsconfig.json` | TypeScript (`@anthropic-ai/sdk`) |
+| `*.js`/`*.jsx` with no `.ts` files | TypeScript SDK (JS-compatible) |
+| `*.java`, `pom.xml`, `build.gradle` | Java (`com.anthropic.*`) |
+| `*.kt`, `*.scala`, `build.sbt` | Java SDK (Kotlin/Scala-compatible) |
+| `*.go`, `go.mod` | Go (`github.com/anthropics/anthropic-sdk-go`) |
+| `*.rb`, `Gemfile` | Ruby |
+| `*.cs`, `*.csproj` | C# |
+| `*.php`, `composer.json` | PHP |
+| Shell scripts, explicit cURL request | Raw HTTP only |
+
+If multiple languages are detected, ask which one the Claude integration lives in. If no language is inferable, ask before writing code.
+
+### 2. Choose the right surface
+
+```
+0. Deploying via Amazon Bedrock, Google Vertex AI, or Microsoft Foundry?
+   └── Yes → Claude API + tool use for all tiers (Managed Agents is 1P-only)
+   No → continue
+
+1. Single task (classify, summarize, extract, Q&A, batch)?
+   └── Claude API — one request, one response
+
+2. Want Anthropic to run the agent loop AND host a per-session
+   container (bash, file ops, code execution)?
+   └── Managed Agents — persisted agent configs, SSE stream,
+       Skills + MCP, file mounts, per-session workspaces
+
+3. Multi-step pipeline with code-controlled logic, your own tools?
+   └── Claude API + tool use — you orchestrate the loop
+
+4. Open-ended agent, your own tools, you host the compute?
+   └── Claude API agentic loop
+```
+
+### 3. Gate on agent viability (before choosing the agent tier)
+
+Check all four criteria. If **any** answer is "no", stay at a simpler tier:
+
+- **Complexity** — Is the task multi-step and hard to fully specify upfront?
+- **Value** — Does the outcome justify higher cost and latency?
+- **Viability** — Is Claude reliably capable at this task type?
+- **Cost of error** — Can errors be caught and recovered from? (tests, review, rollback)
+
+### 4. Apply code defaults
+
+Unless the user explicitly requests otherwise:
+
+| Setting | Default |
+|---|---|
+| Model | `claude-opus-4-7` |
+| Thinking | `thinking: { type: "adaptive" }` for anything non-trivial |
+| Streaming | Enable for long input, long output, or high `max_tokens` |
+| Streaming helper | `.get_final_message()` / `.finalMessage()` to get complete response |
+| Prompt caching | Always include — reduces cost on repeated large contexts |
+
+### 5. Verify SDK usage before writing code
+
+- Function names, class names, method signatures, and import paths **must** come from official documentation or the SDK repository — never infer from another language's SDK or from cURL shapes.
+- If a binding is not documented in the reference you have at hand, fetch the official SDK repository or API docs before writing code.
+- Never reach for raw HTTP (`requests`, `fetch`, `httpx`) in a project that has an official SDK.
+- Check for non-Anthropic provider markers (`import openai`, `langchain_openai`, `gpt-4`, `*-openai.py`) before editing any file — do not inject Anthropic SDK calls into a file written for another provider.
+
+### 6. Managed Agents: create once, reference by ID
+
+- Call `agents.create` once at setup time; store the returned agent ID.
+- Every subsequent `sessions.create` references that ID — do **not** call `agents.create` in the request path.
+- Agents are persistent versioned objects; sessions pin to a specific version.
+
+## Anti-patterns
+
+- **Mixing raw HTTP with SDK** — pick one and stick to it per project
+- **Inferring SDK API shapes** from cURL examples or from a different language's SDK
+- **Calling `agents.create` per request** — agents are persistent; create once, reuse by ID
+- **Skipping streaming** for requests with large inputs or high `max_tokens` — risks timeouts
+- **Omitting prompt caching** — it should be the default, not an afterthought
+- **Reaching for the agent tier reflexively** — single API calls and code-orchestrated workflows handle most real use cases; agents add cost and complexity
+- **Using Managed Agents on third-party providers** (Bedrock/Vertex/Foundry) — they are Anthropic 1P only; use Claude API + tool use instead
+
+## References
+
+- Upstream: https://github.com/anthropics/skills.git
+- Anthropic API docs: https://docs.anthropic.com
+- Python SDK: https://github.com/anthropics/anthropic-sdk-python
+- TypeScript SDK: https://github.com/anthropics/anthropic-sdk-typescript
+- Go SDK: https://github.com/anthropics/anthropic-sdk-go