codeply-cli 0.5.6 → 0.6.0

package/skills/codehealth-mcp/SKILL.md

@@ -1,167 +1,167 @@
----
-name: codehealth-mcp
-description: Real-time structural Code Health via CodeScene MCP — review before edits, verify score deltas after changes, gate commits and PRs. Use when reviewing code quality, refactoring, checking if AI changes degraded a file, or before commit/PR.
-metadata:
-  origin: community
----
-
-# Code Health MCP (CodeScene)
-
-Structural maintainability feedback for AI-assisted coding. Complements style/lint skills (`coding-standards`, `plankton-code-quality`) with **design-level** health scores and regression gates.
-
-**Upstream:** [codescene-oss/codescene-mcp-server](https://github.com/codescene-oss/codescene-mcp-server)
-**Package:** `@codescene/codehealth-mcp` (stdio via npx)
-
-## Security and boundaries
-
-**Opt-in (ECC):** The `codescene` block in `mcp-configs/mcp-servers.json` is a template only. ECC plugin installs do not auto-enable bundled MCP servers. Copy the entry into your config only if you want it. You can exclude it during ECC install/sync with `ECC_DISABLED_MCPS=codescene,...`.
-
-**Credentials:** No bundled token. Set `CS_ACCESS_TOKEN` yourself (see [getting-a-personal-access-token.md](https://github.com/codescene-oss/codescene-mcp-server/blob/main/docs/getting-a-personal-access-token.md) in the upstream repo). Never commit tokens to the repo.
-
-**What the tools read:** When invoked, tools analyze files and git state **in the local repository** you point them at (paths you pass, plus branch context for `analyze_change_set`). They do not run by themselves. For standalone mode, follow upstream privacy docs: [codescene-mcp-server README](https://github.com/codescene-oss/codescene-mcp-server#frequently-asked-questions) and [CodeScene policies](https://codescene.com/policies). Do not use this skill for secrets, credentials, or paths you do not want analyzed.
-
-**If the MCP is unavailable (offline, bad token, server crash):** Do not invent Code Health scores. Tell the user the check was skipped. Continue only with explicit user approval. Prefer lint/tests/verification-loop for gating when MCP is down. Re-enable checks once the server connects.
-
-## When to Use
-
-- User asks to **review code quality**, **refactor** a file, or check if **AI changes degraded** maintainability
-- Before editing a **hotspot**, legacy module, or unfamiliar file
-- Before **commit** or **pull request** when you need a maintainability safeguard
-- After a large agent-written diff — verify Code Health did not regress
-- Pair with `verification-loop`, `tdd-workflow`, or `/quality-gate` as a structural check (not a replacement for tests/lint)
-
-## When to Activate
-
-Same triggers as **When to Use** above — this heading is what ECC uses for skill auto-activation.
-
-## How It Works
-
-### 1. Connect the MCP server
-
-Copy the `codescene` entry from `mcp-configs/mcp-servers.json` into your harness MCP config.
-
-**Claude Code** (`~/.claude.json` → `mcpServers`):
-
-```json
-"codescene": {
-  "command": "npx",
-  "args": ["-y", "@codescene/codehealth-mcp"],
-  "env": {
-    "CS_ACCESS_TOKEN": "YOUR_CS_ACCESS_TOKEN_HERE"
-  }
-}
-```
-
-**Project-scoped:** merge the same block into `.mcp.json` at the repo root.
-
-Token setup is documented in the upstream repo (link above). Standalone mode does not require a paid CodeScene platform account for the four tools listed below. Restart the session and confirm the `codescene` server is connected before relying on scores.
-
-### 2. Call standalone tools only
-
-| Tool | When to use |
-|------|-------------|
-| `code_health_review` | Full structural analysis **before** modifying a file |
-| `code_health_score` | Quick numeric score after each change (delta check) |
-| `pre_commit_code_health_safeguard` | Block commits that introduce Code Health regressions |
-| `analyze_change_set` | Branch-level check **before** opening a PR |
-
-Do **not** call platform-only tools (e.g. repository-wide technical debt hotspot lists). Do **not** reference `delta_analysis` — not available on standalone.
-
-### 3. Interpret scores (1–10)
-
-| Range | Meaning | Agent behavior |
-|-------|---------|----------------|
-| **9.0–10.0** | Green — healthy | Safer to extend; still prefer vertical slices |
-| **4.0–8.9** | Yellow — debt | Tread carefully; no drive-by refactors |
-| **1.0–3.9** | Red — severe debt | Narrow scope only |
-
-### 4. Run the feedback loop
-
-**Before touching a file**
-
-1. Run `code_health_review` on the target path.
-2. Record baseline score and listed code smells.
-3. Plan the smallest change that addresses the task.
-
-Scope by score: **below 5** — minimal diff only; **5–7** — no broad refactors; **above 7** — safer to refactor, still verify after each edit.
-
-**After each change**
-
-1. Run `code_health_score` on the same file.
-2. Compare to the baseline from `code_health_review`.
-3. If the score **regressed**, fix before continuing. Never mark the task done while the score is lower than when you started.
-
-**Before every commit** — run `pre_commit_code_health_safeguard` on the repository path.
-
-**Before a PR** — run `analyze_change_set` against the base branch (e.g. `main`).
-
-## Examples
-
-### Example: Flask maintainability improvement
-
-On `pallets/flask`, an agent loop using only standalone tools:
-
-1. `code_health_review` on a target module (baseline **4.82**)
-2. Targeted refactor addressing listed smells
-3. `code_health_score` after each edit
-4. `pre_commit_code_health_safeguard` before commit
-5. `analyze_change_set` before PR
-
-Result: Code Health **4.82 → 9.1** (free standalone token only).
-
-### Example: AGENTS.md enforcement block
-
-Paste into the project `AGENTS.md` or `CLAUDE.md`:
-
-```md
-## Code Health (CodeScene MCP)
-
-Before modifying any file: run `code_health_review`, note score and issues.
-
-- Score below 5: problematic range — scope changes narrowly.
-- Score 5–7: warning range — no broad refactors.
-
-After each change: run `code_health_score` to verify delta.
-
-- If score regressed: fix before continuing; never declare done if score dropped.
-
-Before every commit: run `pre_commit_code_health_safeguard`.
-
-Before PR: run `analyze_change_set`.
-```
-
-### Example: anti-patterns vs correct loop
-
-```markdown
-# BAD: Edit first, check later
-[large refactor without code_health_review]
-
-# BAD: Ignore score drop
-"Tests pass" → mark task done while Code Health decreased
-
-# BAD: Broad refactor on red-score file (below 5)
-Drive-by cleanup across the module
-
-# GOOD: review → small change → score → commit safeguard → analyze_change_set
-```
-
-## Pairing with ECC
-
-| ECC skill / flow | Code Health MCP role |
-|------------------|----------------------|
-| `coding-standards` | Style/naming; Code Health = structure/complexity |
-| `plankton-code-quality` | Write-time lint/format; Code Health = pre/post edit structural gate |
-| `verification-loop` / `/quality-gate` | Add structural regression check before "done" |
-| `security-review` | Security vs maintainability — use both when relevant |
-| `tdd-workflow` | Tests pass ≠ healthy design — check score after refactors |
-
-**Context tip:** ECC recommends keeping MCP count low. Enable `codescene` when doing substantive edits; disable when not needed.
-
-## Related Skills
-
-- `coding-standards` — baseline conventions
-- `plankton-code-quality` — write-time lint/format hooks
-- `verification-loop` — build/test/lint gate
-- `tdd-workflow` — test-first development
-- `security-review` — security checklist
-- `documentation-lookup` — library docs via Context7 (orthogonal)
+---
+name: codehealth-mcp
+description: Real-time structural Code Health via CodeScene MCP — review before edits, verify score deltas after changes, gate commits and PRs. Use when reviewing code quality, refactoring, checking if AI changes degraded a file, or before commit/PR.
+metadata:
+  origin: community
+---
+
+# Code Health MCP (CodeScene)
+
+Structural maintainability feedback for AI-assisted coding. Complements style/lint skills (`coding-standards`, `plankton-code-quality`) with **design-level** health scores and regression gates.
+
+**Upstream:** [codescene-oss/codescene-mcp-server](https://github.com/codescene-oss/codescene-mcp-server)
+**Package:** `@codescene/codehealth-mcp` (stdio via npx)
+
+## Security and boundaries
+
+**Opt-in (ECC):** The `codescene` block in `mcp-configs/mcp-servers.json` is a template only. ECC plugin installs do not auto-enable bundled MCP servers. Copy the entry into your config only if you want it. You can exclude it during ECC install/sync with `ECC_DISABLED_MCPS=codescene,...`.
+
+**Credentials:** No bundled token. Set `CS_ACCESS_TOKEN` yourself (see [getting-a-personal-access-token.md](https://github.com/codescene-oss/codescene-mcp-server/blob/main/docs/getting-a-personal-access-token.md) in the upstream repo). Never commit tokens to the repo.
+
+**What the tools read:** When invoked, tools analyze files and git state **in the local repository** you point them at (paths you pass, plus branch context for `analyze_change_set`). They do not run by themselves. For standalone mode, follow upstream privacy docs: [codescene-mcp-server README](https://github.com/codescene-oss/codescene-mcp-server#frequently-asked-questions) and [CodeScene policies](https://codescene.com/policies). Do not use this skill for secrets, credentials, or paths you do not want analyzed.
+
+**If the MCP is unavailable (offline, bad token, server crash):** Do not invent Code Health scores. Tell the user the check was skipped. Continue only with explicit user approval. Prefer lint/tests/verification-loop for gating when MCP is down. Re-enable checks once the server connects.
+
+## When to Use
+
+- User asks to **review code quality**, **refactor** a file, or check if **AI changes degraded** maintainability
+- Before editing a **hotspot**, legacy module, or unfamiliar file
+- Before **commit** or **pull request** when you need a maintainability safeguard
+- After a large agent-written diff — verify Code Health did not regress
+- Pair with `verification-loop`, `tdd-workflow`, or `/quality-gate` as a structural check (not a replacement for tests/lint)
+
+## When to Activate
+
+Same triggers as **When to Use** above — this heading is what ECC uses for skill auto-activation.
+
+## How It Works
+
+### 1. Connect the MCP server
+
+Copy the `codescene` entry from `mcp-configs/mcp-servers.json` into your harness MCP config.
+
+**Claude Code** (`~/.claude.json` → `mcpServers`):
+
+```json
+"codescene": {
+  "command": "npx",
+  "args": ["-y", "@codescene/codehealth-mcp"],
+  "env": {
+    "CS_ACCESS_TOKEN": "YOUR_CS_ACCESS_TOKEN_HERE"
+  }
+}
+```
+
+**Project-scoped:** merge the same block into `.mcp.json` at the repo root.
+
+Token setup is documented in the upstream repo (link above). Standalone mode does not require a paid CodeScene platform account for the four tools listed below. Restart the session and confirm the `codescene` server is connected before relying on scores.
+
+### 2. Call standalone tools only
+
+| Tool | When to use |
+|------|-------------|
+| `code_health_review` | Full structural analysis **before** modifying a file |
+| `code_health_score` | Quick numeric score after each change (delta check) |
+| `pre_commit_code_health_safeguard` | Block commits that introduce Code Health regressions |
+| `analyze_change_set` | Branch-level check **before** opening a PR |
+
+Do **not** call platform-only tools (e.g. repository-wide technical debt hotspot lists). Do **not** reference `delta_analysis` — not available on standalone.
+
+### 3. Interpret scores (1–10)
+
+| Range | Meaning | Agent behavior |
+|-------|---------|----------------|
+| **9.0–10.0** | Green — healthy | Safer to extend; still prefer vertical slices |
+| **4.0–8.9** | Yellow — debt | Tread carefully; no drive-by refactors |
+| **1.0–3.9** | Red — severe debt | Narrow scope only |
+
+### 4. Run the feedback loop
+
+**Before touching a file**
+
+1. Run `code_health_review` on the target path.
+2. Record baseline score and listed code smells.
+3. Plan the smallest change that addresses the task.
+
+Scope by score: **below 5** — minimal diff only; **5–7** — no broad refactors; **above 7** — safer to refactor, still verify after each edit.
+
+**After each change**
+
+1. Run `code_health_score` on the same file.
+2. Compare to the baseline from `code_health_review`.
+3. If the score **regressed**, fix before continuing. Never mark the task done while the score is lower than when you started.
+
+**Before every commit** — run `pre_commit_code_health_safeguard` on the repository path.
+
+**Before a PR** — run `analyze_change_set` against the base branch (e.g. `main`).
+
+## Examples
+
+### Example: Flask maintainability improvement
+
+On `pallets/flask`, an agent loop using only standalone tools:
+
+1. `code_health_review` on a target module (baseline **4.82**)
+2. Targeted refactor addressing listed smells
+3. `code_health_score` after each edit
+4. `pre_commit_code_health_safeguard` before commit
+5. `analyze_change_set` before PR
+
+Result: Code Health **4.82 → 9.1** (free standalone token only).
+
+### Example: AGENTS.md enforcement block
+
+Paste into the project `AGENTS.md` or `CLAUDE.md`:
+
+```md
+## Code Health (CodeScene MCP)
+
+Before modifying any file: run `code_health_review`, note score and issues.
+
+- Score below 5: problematic range — scope changes narrowly.
+- Score 5–7: warning range — no broad refactors.
+
+After each change: run `code_health_score` to verify delta.
+
+- If score regressed: fix before continuing; never declare done if score dropped.
+
+Before every commit: run `pre_commit_code_health_safeguard`.
+
+Before PR: run `analyze_change_set`.
+```
+
+### Example: anti-patterns vs correct loop
+
+```markdown
+# BAD: Edit first, check later
+[large refactor without code_health_review]
+
+# BAD: Ignore score drop
+"Tests pass" → mark task done while Code Health decreased
+
+# BAD: Broad refactor on red-score file (below 5)
+Drive-by cleanup across the module
+
+# GOOD: review → small change → score → commit safeguard → analyze_change_set
+```
+
+## Pairing with ECC
+
+| ECC skill / flow | Code Health MCP role |
+|------------------|----------------------|
+| `coding-standards` | Style/naming; Code Health = structure/complexity |
+| `plankton-code-quality` | Write-time lint/format; Code Health = pre/post edit structural gate |
+| `verification-loop` / `/quality-gate` | Add structural regression check before "done" |
+| `security-review` | Security vs maintainability — use both when relevant |
+| `tdd-workflow` | Tests pass ≠ healthy design — check score after refactors |
+
+**Context tip:** ECC recommends keeping MCP count low. Enable `codescene` when doing substantive edits; disable when not needed.
+
+## Related Skills
+
+- `coding-standards` — baseline conventions
+- `plankton-code-quality` — write-time lint/format hooks
+- `verification-loop` — build/test/lint gate
+- `tdd-workflow` — test-first development
+- `security-review` — security checklist
+- `documentation-lookup` — library docs via Context7 (orthogonal)

package/skills/codeply-taste/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Leonxlnx
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/skills/codeply-taste/SKILL.md

@@ -0,0 +1,100 @@
+---
+name: codeply-taste
+description: Codeply's design layer. Use for any design a person will look at - a website or landing page, app screens, a slide deck, a document, a poster, a social post, a logo - when it has to look designed, not generated. It deals an art direction from a research library (design_direction), checks the result against measured rules and a real render (design_lint), and holds the type, colour, layout, copy, imagery and motion guides in references/.
+---
+
+# Codeply taste
+
+A design that looks generated has the same tells every time: the category's default
+palette, a centred hero with a gradient, three icon cards, pill buttons with a glow,
+and copy that says nothing. This skill exists to make something else: a design with
+one idea, carried by type, colour, pictures and layout that were chosen for it.
+
+The research behind it is in `references/research.md`. The short version: strong
+pages commit to one idea, set type at few sizes far apart, use colour in planned
+proportions, and use real pictures. Weak pages decorate.
+
+## The workflow
+
+1. **Know the brief.** Who is it for, what one thing must it make them feel or do,
+   what real material exists (a name, a product, photographs, numbers). If a fact
+   the design depends on is missing and only the person can say, ask once with
+   ask_user. Otherwise decide and say what you decided.
+
+2. **Deal a direction** (websites, landing pages, and the look of an app):
+   `design_direction` with a one-line `brief`, a `sector` and a `tone`. Use
+   `options` = 3 to see three directions first when the brief is open, then
+   `direction` = the chosen id for the full sheet. The sheet gives the idea,
+   composition, type, palette, imagery, sections and the pitfalls to avoid.
+   Follow it. Re-deal one part with `redraw` (`type`, `palette`, `hero`, `photos`,
+   `section:<role>`) rather than ignoring it. For slides, documents, posters and
+   social posts, a direction is optional: when the subject has a brand or sector,
+   deal one and use its palette and type.
+
+3. **Look at real work** for app screens: `design_reference_search` for the screen
+   type, then `view_images` on 2 to 4 results from different apps, and build from
+   what you saw.
+
+4. **Read the guide you need** before writing: `references/type.md` and
+   `references/colour.md` always; `references/layout.md` for pages and screens;
+   `references/copy.md` for every headline and button; `references/imagery.md`
+   when pictures are involved; `references/motion.md` for websites;
+   `references/tells.md` for what not to do. Read with read_file on
+   `<skill folder>/references/<name>.md` (the use_skill output gives the folder).
+
+5. **Write it** (see "Formats" below). Real words, not lorem ipsum: write copy the
+   way `references/copy.md` says. Real pictures: `image_search`, then
+   `fetch_image` into `assets/`, and credit them; or the dealt photographs from the
+   direction sheet.
+
+6. **Check it, once or twice**: `design_lint` with the `path` and the `kind`, when
+   the design is complete (not after every edit). Fix every FAIL in one or two edits
+   and check once more; three checks per request at most. WARNs are optional: fix
+   the quick ones alongside the FAILs. Look at the attached screenshots the way
+   `references/critique.md` says and fix what is plainly wrong in the same edit.
+   Once a check passes, stop checking.
+
+7. **Say what you made** in two or three lines: the idea, the type and colour, and
+   anything you decided for the person. Never say a design "works": its buttons and
+   forms are pictures of buttons and forms until someone builds it.
+
+## Formats
+
+One self-contained HTML file per design, so it opens anywhere: CSS in a `<style>`
+tag, any script inline, fonts from Google Fonts with `display=swap`, pictures in
+`assets/`. No frameworks, no build step, no external scripts except fonts.
+
+- **website**: a full page at desktop and phone widths, responsive, with
+  `<meta name="viewport" content="width=device-width, initial-scale=1">`.
+  Motion from `assets/base.css` and `assets/base.js` (copy them in, they are
+  small): transform and opacity only, with a reduced-motion fallback.
+- **app**: the screens of the flow side by side on a neutral canvas, each one a
+  390 by 844 frame (`<section class="screen">`) with a short label under it. Real
+  content in every state: the empty state, a loaded list, an error, as the brief
+  needs.
+- **slides**: a 16:9 deck, each slide a `<section class="slide">` of exactly
+  1280 by 720 pixels, stacked with a gap. One idea per slide, big type, real
+  numbers. No bullet walls: three lines at most.
+- **doc**: pages of 816 by 1056 pixels (US Letter at 96 dpi; A4 is 794 by 1123),
+  each a `<section class="page">` with its own margins, set for print too
+  (`@page` and `break-after: page`). A real typographic hierarchy, not a web page
+  squeezed onto paper.
+- **poster**: one `<section class="poster">` at the asked size (1080 by 1350 by
+  default).
+- **social**: one or more `<section class="post">` at 1080 by 1080 (or 1080 by
+  1350 / 1080 by 1920 when asked).
+- **logo**: the mark as inline SVG, shown on light and dark grounds, at large and
+  small sizes, with the wordmark lockup. Simple enough to read at 16 pixels.
+
+Only pages and app screens move. Slides, documents, posters, posts and logos are
+still.
+
+## What never ships
+
+The registry is `references/tells.md`; `design_lint` catches most of it. The ones
+that matter most: gradient text and purple-blue gradients; glassmorphism; glow
+and coloured shadows on buttons; three identical icon cards; everything centred;
+eyebrow labels over every heading; emoji as icons; the cream-and-terracotta and
+the purple "AI" palettes; grey body text with low contrast; more than two
+typefaces; copy that could describe any product ("Unlock the power of...",
+"Seamless", "Elevate").

package/skills/codeply-taste/SOURCE.md

@@ -0,0 +1,10 @@
+# Source
+
+Vendored from [Leonxlnx/taste-skill](https://github.com/Leonxlnx/taste-skill) (MIT, see `LICENSE`),
+the `skills/taste-skill` folder (tasteskill v2) at commit `f624f37a8c650b9cc550253104925efe4c8de246`.
+
+Copied unchanged: `references/`, `library/`, `scripts/`, `assets/`.
+
+Work in progress on the Codeply design layer: Codeply's own `SKILL.md` (websites and app screens,
+wired to the App Store reference library and the engine's `design_direction` / `design_lint` tools)
+is added in a later commit.

package/skills/codeply-taste/assets/base.css

@@ -0,0 +1,100 @@
+/* tasteskill / base.css
+   A neutral foundation: reset, token names, fluid type steps, a 12-column grid, states and the motion
+   helpers from references/motion.md. It has no look of its own. Copy it into the project, replace the
+   token values with the ones on the direction sheet, and build on top. Delete what you do not use. */
+
+/* ---------- tokens (replace with the dealt palette and type system) ---------- */
+:root {
+  --bg: #ffffff;
+  --surface: #f2f2f2;
+  --ink: #111111;
+  --muted: #5c5c5c;
+  --accent: #111111;
+  --accent-ink: #ffffff;
+
+  --font-display: system-ui, sans-serif;
+  --font-text: system-ui, sans-serif;
+
+  --step-small: clamp(0.8125rem, 0.79rem + 0.1vw, 0.875rem);
+  --step-body: clamp(1.0625rem, 1rem + 0.25vw, 1.1875rem);
+  --step-lead: clamp(1.25rem, 1.1rem + 0.7vw, 1.625rem);
+  --step-head: clamp(2rem, 1.3rem + 3.2vw, 4rem);
+  --step-display: clamp(3rem, 1rem + 9vw, 9rem); /* set from the hero blueprint */
+
+  --margin: clamp(1rem, 2.2vw, 2rem);    /* page side margin: tight, so content reaches the edges */
+  --gutter: clamp(1rem, 2vw, 2rem);      /* column gap */
+  --section: clamp(5rem, 12vw, 13rem);   /* space between sections */
+  --radius: 0px;                          /* one radius for the whole page: 0, or large, decided once */
+
+  --ease-out: cubic-bezier(0.22, 1, 0.36, 1);
+  --ease-in-out: cubic-bezier(0.76, 0, 0.24, 1);
+  --ease-soft: cubic-bezier(0.33, 1, 0.68, 1);
+  --t-press: 140ms;
+  --t-hover: 180ms;
+  --t-ui: 240ms;
+  --t-reveal: 800ms;
+}
+
+/* ---------- reset ---------- */
+*, *::before, *::after { box-sizing: border-box; }
+html { -webkit-text-size-adjust: 100%; text-size-adjust: 100%; scroll-behavior: auto; }
+body { margin: 0; background: var(--bg); color: var(--ink); font-family: var(--font-text); font-size: var(--step-body); line-height: 1.5; font-kerning: normal; -webkit-font-smoothing: antialiased; text-rendering: optimizeLegibility; }
+h1, h2, h3, h4, p, figure, blockquote, ul, ol, dl, dd { margin: 0; }
+ul[class], ol[class] { padding: 0; list-style: none; }
+img, video, svg, canvas { display: block; max-width: 100%; }
+img, video { height: auto; background: var(--surface); }
+button, input, select, textarea { font: inherit; color: inherit; }
+button { background: none; border: 0; padding: 0; cursor: pointer; }
+a { color: inherit; }
+:target { scroll-margin-top: 6rem; }
+::selection { background: var(--accent); color: var(--accent-ink); }
+:focus-visible { outline: 2px solid var(--accent); outline-offset: 3px; }
+
+/* ---------- type ---------- */
+h1, h2, h3 { font-family: var(--font-display); font-weight: inherit; text-wrap: balance; hyphens: none; }
+.display { font-size: var(--step-display); line-height: 0.95; letter-spacing: -0.035em; }
+.head { font-size: var(--step-head); line-height: 1.02; letter-spacing: -0.025em; }
+.lead { font-size: var(--step-lead); line-height: 1.35; max-width: 40ch; }
+.small { font-size: var(--step-small); line-height: 1.45; }
+.muted { color: var(--muted); }
+p { max-width: 62ch; text-wrap: pretty; }
+p + p { margin-top: 0.9em; }
+.nums { font-variant-numeric: tabular-nums; }
+.only-wide { display: none; }
+@media (min-width: 48em) { .only-wide { display: inline; } }
+
+/* ---------- layout ---------- */
+.wrap { padding-inline: var(--margin); }
+.grid { display: grid; grid-template-columns: repeat(12, minmax(0, 1fr)); column-gap: var(--gutter); }
+.section { padding-block: calc(var(--section) / 2); }
+.section + .section { margin-top: 0; }
+.bleed { margin-inline: calc(var(--margin) * -1); }
+.cover { width: 100%; height: 100%; object-fit: cover; }
+.sr-only { position: absolute; width: 1px; height: 1px; overflow: hidden; clip-path: inset(50%); white-space: nowrap; }
+
+/* ---------- controls ---------- */
+.button { display: inline-flex; align-items: center; justify-content: center; min-height: 3rem; padding: 0 1.4rem; background: var(--accent); color: var(--accent-ink); border-radius: var(--radius); text-decoration: none; white-space: nowrap; transition: transform var(--t-press) var(--ease-out), background-color var(--t-hover) ease, color var(--t-hover) ease; }
+.button:active { transform: scale(0.97); }
+.link { text-decoration: underline; text-decoration-color: transparent; text-underline-offset: 0.2em; text-decoration-thickness: 0.07em; transition: text-decoration-color var(--t-hover) ease; }
+.link-plain { text-decoration: underline; text-underline-offset: 0.18em; text-decoration-thickness: 0.07em; }
+@media (hover: hover) and (pointer: fine) {
+  .link:hover { text-decoration-color: currentColor; }
+}
+.field { width: 100%; min-height: 3rem; padding: 0.7rem 0.9rem; background: var(--surface); border: 0; border-radius: var(--radius); font-size: max(1rem, var(--step-body)); }
+
+/* ---------- motion helpers (content stays visible without JavaScript) ---------- */
+.lines .line { display: block; overflow: hidden; padding-bottom: 0.08em; margin-bottom: -0.08em; }
+.lines [data-line] { display: block; }
+.shutter { overflow: hidden; }
+@media (prefers-reduced-motion: no-preference) {
+  .js [data-rise] { opacity: 0; transform: translateY(18px); animation: ad-rise var(--t-reveal) var(--ease-out) forwards; animation-delay: calc(var(--i, 0) * 90ms + 120ms); }
+  .js .lines [data-line] { transform: translateY(105%); animation: ad-line 900ms var(--ease-out) forwards; animation-delay: calc(var(--i, 0) * 110ms + 150ms); }
+  .js [data-reveal] { opacity: 0; transform: translateY(24px); transition: opacity 700ms var(--ease-out), transform 900ms var(--ease-out); }
+  .js [data-reveal].is-in { opacity: 1; transform: none; }
+  .js .shutter[data-reveal] { opacity: 1; transform: none; clip-path: inset(0 0 100% 0); transition: clip-path 1100ms var(--ease-in-out); }
+  .js .shutter[data-reveal] img { transform: scale(1.12); transition: transform 1500ms var(--ease-soft); }
+  .js .shutter[data-reveal].is-in { clip-path: inset(0); }
+  .js .shutter[data-reveal].is-in img { transform: none; }
+}
+@keyframes ad-rise { to { opacity: 1; transform: none; } }
+@keyframes ad-line { to { transform: none; } }

package/skills/codeply-taste/assets/base.js

@@ -0,0 +1,37 @@
+// tasteskill / base.js — the small amount of script the motion helpers in base.css need.
+// Put this line in <head> so the hidden states only apply when scripting works:
+//   <script>document.documentElement.classList.add('js')</script>
+// Then load this file at the end of <body> (or with defer).
+
+// Reveal once when an element enters the viewport. Never replays, never leaves content hidden.
+(() => {
+  const targets = document.querySelectorAll('[data-reveal]');
+  if (!targets.length) return;
+  if (!('IntersectionObserver' in window)) { targets.forEach((el) => el.classList.add('is-in')); return; }
+  const io = new IntersectionObserver((entries) => {
+    for (const entry of entries) {
+      if (!entry.isIntersecting) continue;
+      entry.target.classList.add('is-in');
+      io.unobserve(entry.target);
+    }
+  }, { rootMargin: '0px 0px -12% 0px', threshold: 0.1 });
+  targets.forEach((el) => io.observe(el));
+  // safety net: if anything is still hidden a few seconds after load (observer never fired), show it
+  window.addEventListener('load', () => setTimeout(() => {
+    targets.forEach((el) => { const r = el.getBoundingClientRect(); if (r.top < innerHeight && r.bottom > 0) el.classList.add('is-in'); });
+  }, 2500));
+})();
+
+// Optional, for "colour by chapter": each chapter paints its own full-bleed ground in CSS
+// (style="background: var(--field-2); color: var(--field-2-ink)"), so the colour changes exactly at
+// section edges. This only lets a fixed header take the ink of the chapter under it. Give each chapter
+// data-ink="#hex" and style the header with color: var(--header-ink, var(--ink)).
+// Never recolour the whole page from an observer: mid-change, a paragraph sits on two colours.
+(() => {
+  const chapters = document.querySelectorAll('[data-ink]');
+  if (!chapters.length || !('IntersectionObserver' in window)) return;
+  const io = new IntersectionObserver((entries) => {
+    for (const entry of entries) if (entry.isIntersecting) document.documentElement.style.setProperty('--header-ink', entry.target.dataset.ink);
+  }, { rootMargin: '0px 0px -92% 0px', threshold: 0 });
+  chapters.forEach((el) => io.observe(el));
+})();