@prateek_ai/agents-maker 1.0.0

package/skills/animated_website.md

@@ -0,0 +1,285 @@
+# Skill: Animated Website
+
+## Purpose
+
+Design and implement a production-quality animated website or web page. Covers entrance
+animations, scroll-triggered effects, micro-interactions, page transitions, loading sequences,
+and background motion — with performance and accessibility guardrails built in.
+
+This skill is the canonical way to request any animation work across the kit. It picks the
+right technology for the project's stack and budget, generates implementation-ready code,
+and flags performance traps before they ship.
+
+---
+
+## Trigger Conditions
+
+Invoke this skill when the user's message contains:
+- "animate", "animation", "animated website", "motion"
+- "scroll effect", "parallax", "fade in", "slide in", "entrance"
+- "micro-interaction", "hover effect", "transition", "loading screen"
+- "GSAP", "Framer Motion", "Three.js", "Lottie", "CSS keyframe"
+- "interactive", "dynamic page", "cinematic", "immersive"
+- Any Phase 3 implementation task in `product_design` or `software` domain where
+  the `solution_design` artifact includes animation or motion as a requirement
+
+---
+
+## Technology Selection Guide
+
+Pick the stack based on project constraints before writing any code:
+
+| Technology | Use when | Avoid when |
+|---|---|---|
+| **CSS only** | Simple fade/slide/scale; no JS budget; SSR sites | Sequenced multi-step timelines; scroll scrubbing |
+| **CSS + Intersection Observer** | Scroll-triggered entrance animations; no library budget | Complex staggering logic |
+| **GSAP** | Complex timelines, scroll scrubbing (ScrollTrigger), SVG morphing | React-only projects (use Framer Motion instead) |
+| **Framer Motion** | React/Next.js; layout animations; gesture-driven UI | Non-React stacks |
+| **Three.js / R3F** | 3D scenes, WebGL backgrounds, particle systems | Simple 2D effects (overkill) |
+| **Lottie** | Designer-exported After Effects animations; icon animations | When file size matters (Lottie JSON can be large) |
+| **Web Animations API** | Lightweight imperative control; no library budget | Complex timelines (too verbose) |
+
+---
+
+## Input Expectations
+
+| Input | Required | Description |
+|---|---|---|
+| `page_description` | Yes | What the page/site does — target audience, purpose, tone |
+| `animation_goal` | Yes | What the animation should communicate (e.g., premium, playful, technical) |
+| `stack` | Yes | React, Vue, plain HTML/CSS, Next.js, etc. |
+| `sections` | No | List of page sections (hero, features, pricing, footer, etc.) |
+| `brand_tokens` | No | Colors, fonts, spacing scale |
+| `performance_budget` | No | Target Lighthouse score or "no library" constraint |
+| `reference_sites` | No | URLs or descriptions of sites with similar motion feel |
+
+**If required input is missing:**
+- `page_description` — ask: "What does this page/site do? Who is the audience and what tone should the motion convey?" Do not proceed without this.
+- `animation_goal` — ask: "What should the animation communicate — premium, playful, technical, minimal, energetic?" Vague briefs produce vague motion; this field is non-negotiable.
+- `stack` — ask: "What is the frontend stack — React, Vue, plain HTML/CSS, Next.js, or something else?" Technology selection depends entirely on this.
+- `sections` — assume a standard landing page structure (hero, features, CTA, footer); list these assumptions at the top of the Animation Plan.
+- `brand_tokens` — proceed without; use neutral defaults (white background, dark text, `ease-out cubic` easing).
+- `performance_budget` — default to "standard budget"; select technology based on complexity alone.
+- `reference_sites` — if `animation_goal` is vague (e.g., "make it premium"), ask for 1–2 reference sites before writing any code.
+
+---
+
+## Output Format
+
+```
+## Animation Plan: <page or component name>
+
+**Motion language**: <one sentence — e.g., "Smooth, editorial fade-ups with staggered reveals and a subtle parallax hero.">
+**Stack selected**: <technology choice + one-line reason>
+**Estimated JS weight**: <e.g., "~45 KB gzipped (GSAP core + ScrollTrigger)">
+**Reduced-motion fallback**: <yes — all animations disabled via prefers-reduced-motion>
+
+---
+
+### Section Breakdown
+
+| Section | Animation type | Trigger | Duration | Easing |
+|---|---|---|---|---|
+| Hero | Scale-up + fade text | Page load | 1.2s | ease-out cubic |
+| Features | Staggered card slide-up | Scroll enter (20% visible) | 0.6s each, 0.1s stagger | ease-out quart |
+| Testimonials | Horizontal marquee | Auto-play, pause on hover | infinite | linear |
+| CTA | Pulse ring on button | Idle after 3s | 1.5s loop | ease-in-out |
+| Footer | Fade-in | Scroll enter | 0.4s | ease |
+
+---
+
+### Implementation
+
+#### 1. Base CSS setup
+
+```css
+/* Reduced motion — always include */
+@media (prefers-reduced-motion: reduce) {
+  *, *::before, *::after {
+    animation-duration: 0.01ms !important;
+    animation-iteration-count: 1 !important;
+    transition-duration: 0.01ms !important;
+  }
+}
+
+/* GPU-composited properties only — do not animate layout properties */
+.animate-ready {
+  will-change: transform, opacity;
+}
+```
+
+#### 2. Entrance animation (CSS + Intersection Observer)
+
+```css
+.reveal {
+  opacity: 0;
+  transform: translateY(32px);
+  transition: opacity 0.6s ease-out, transform 0.6s ease-out;
+}
+
+.reveal.visible {
+  opacity: 1;
+  transform: translateY(0);
+}
+
+/* Stagger via custom property */
+.reveal:nth-child(2) { transition-delay: 0.1s; }
+.reveal:nth-child(3) { transition-delay: 0.2s; }
+.reveal:nth-child(4) { transition-delay: 0.3s; }
+```
+
+```js
+const observer = new IntersectionObserver(
+  (entries) => entries.forEach(e => {
+    if (e.isIntersecting) {
+      e.target.classList.add('visible');
+      observer.unobserve(e.target); // fire once
+    }
+  }),
+  { threshold: 0.2 }
+);
+document.querySelectorAll('.reveal').forEach(el => observer.observe(el));
+```
+
+#### 3. Hero entrance (GSAP timeline)
+
+```js
+import gsap from 'gsap';
+
+const tl = gsap.timeline({ defaults: { ease: 'power3.out' } });
+
+tl.from('.hero-headline', { opacity: 0, y: 48, duration: 1 })
+  .from('.hero-sub',      { opacity: 0, y: 24, duration: 0.8 }, '-=0.6')
+  .from('.hero-cta',      { opacity: 0, scale: 0.9, duration: 0.6 }, '-=0.4');
+```
+
+#### 4. Scroll-scrubbed parallax (GSAP ScrollTrigger)
+
+```js
+import { ScrollTrigger } from 'gsap/ScrollTrigger';
+gsap.registerPlugin(ScrollTrigger);
+
+gsap.to('.hero-bg', {
+  yPercent: -30,
+  ease: 'none',
+  scrollTrigger: {
+    trigger: '.hero',
+    start: 'top top',
+    end: 'bottom top',
+    scrub: true,
+  },
+});
+```
+
+#### 5. Framer Motion card stagger (React)
+
+```tsx
+import { motion } from 'framer-motion';
+
+const container = {
+  hidden: {},
+  show: { transition: { staggerChildren: 0.1 } },
+};
+
+const item = {
+  hidden: { opacity: 0, y: 32 },
+  show:   { opacity: 1, y: 0, transition: { duration: 0.5, ease: [0.25, 0.46, 0.45, 0.94] } },
+};
+
+export function FeatureGrid({ features }) {
+  return (
+    <motion.ul variants={container} initial="hidden" whileInView="show" viewport={{ once: true }}>
+      {features.map(f => (
+        <motion.li key={f.id} variants={item}>
+          {f.title}
+        </motion.li>
+      ))}
+    </motion.ul>
+  );
+}
+```
+
+#### 6. Loading screen
+
+```css
+.loader {
+  position: fixed; inset: 0;
+  background: #0a0a0a;
+  display: grid; place-items: center;
+  z-index: 9999;
+  transition: opacity 0.5s ease, visibility 0.5s ease;
+}
+
+.loader.hidden { opacity: 0; visibility: hidden; }
+
+.loader-bar {
+  width: 160px; height: 2px;
+  background: #222;
+  border-radius: 2px;
+  overflow: hidden;
+}
+
+.loader-bar::after {
+  content: '';
+  display: block;
+  height: 100%;
+  background: #fff;
+  animation: load 1.4s ease-in-out infinite;
+}
+
+@keyframes load {
+  0%   { width: 0%; margin-left: 0; }
+  50%  { width: 100%; margin-left: 0; }
+  100% { width: 0%; margin-left: 100%; }
+}
+```
+
+---
+
+### Performance Checklist
+
+- [ ] Only animate `transform` and `opacity` (never `width`, `height`, `top`, `left`)
+- [ ] Add `will-change: transform` only on elements actively animating (remove after animation)
+- [ ] All entrance animations use `once: true` / `unobserve()` — no repeated triggers
+- [ ] `prefers-reduced-motion` media query disables all motion
+- [ ] GSAP ScrollTrigger instances killed on component unmount (React/Vue)
+- [ ] Total animation JS budget: ≤ 60 KB gzipped unless 3D/WebGL is required
+- [ ] Lottie files ≤ 150 KB; lazy-loaded below the fold
+
+---
+
+### Accessibility
+
+- All animated elements retain focus and keyboard navigability
+- No animation relies on color alone to convey state
+- Auto-playing carousels and marquees pause on `hover` and `focus`
+- Loading screens resolve within 3 seconds or expose a skip option
+```
+
+---
+
+## Rules
+
+- Always include a `prefers-reduced-motion` block — no exceptions.
+- Never animate `width`, `height`, `margin`, `padding`, `top`, `left`, or `bottom` — use
+  `transform: translate/scale` instead to stay on the compositor thread.
+- If the user only specifies a vibe (e.g., "make it look premium"), ask for 1–2 reference sites
+  before writing code. Vague briefs produce vague motion.
+- When GSAP ScrollTrigger is used in a React/Vue SPA, always include the cleanup call
+  (`ScrollTrigger.getAll().forEach(t => t.kill())`) in the component unmount hook.
+- Output code must be copy-paste ready — no pseudocode, no `// TODO` placeholders.
+- After the implementation block, always append a Performance Checklist (pre-filled based
+  on the techniques used) and an Accessibility section.
+- If Three.js or WebGL is selected, warn: "3D scenes can drop to 20 fps on mid-range mobile
+  — always test on a real device and provide a 2D fallback."
+
+---
+
+## Token Cost Tier
+
+**Medium** for CSS/Intersection Observer implementations (no file reads required).  
+**High** for GSAP or Framer Motion integrations that touch existing component files.  
+**High** for Three.js / WebGL scenes (full repo scan needed to assess bundle impact).
+
+Compression hint: if the animation is isolated to a single new component, scope context to
+that file only. If touching the global CSS bundle or app entry point, request a repo summary first.

package/skills/compare_approaches.md

@@ -0,0 +1,86 @@
+# Skill: Compare Approaches
+
+## Purpose
+
+When a decision has multiple valid implementation paths, produce a structured trade-off comparison
+and recommend one approach based on the current project's constraints, stack, and goals.
+
+This skill is how the kit provides **decision support** — not just executing a chosen path, but
+helping the user pick the right one before committing.
+
+---
+
+## Trigger Conditions
+
+Invoke this skill when the user's message contains:
+- "compare", "trade-off", "trade off", "pros and cons"
+- "which approach", "which is better", "should I use X or Y"
+- "what are my options for…", "how should I implement…"
+- Any design choice point during Phase 2 (Solution Design) where ≥2 valid paths exist
+- When the Reviewer Agent (Phase 4) flags a design decision as revisable
+
+---
+
+## Input Expectations
+
+| Input | Required | Description |
+|---|---|---|
+| `decision_question` | Yes | The specific choice being evaluated — e.g., "Redis vs. in-memory cache for rate limiting" |
+| `candidate_approaches` | Yes | 2–4 named options to compare (from user message or inferred from design context) |
+| `project_constraints` | No | Stack, team size, timeline, must-not constraints from `task_profile`, `requirements_spec`, or `project.yaml` |
+| `approved_adrs` | No | Any architecture decisions already confirmed — recommendations must not contradict them |
+
+**If required input is missing:**
+- `decision_question` — infer from the user's message; if still ambiguous, ask: "What specifically are you deciding between?" before producing the table.
+- `candidate_approaches` — if only one approach is named, actively surface a second (hybrid, deferral, or "don't solve this yet") so the comparison has ≥2 options.
+- `project_constraints` — proceed without; note that the recommendation is based on general trade-offs only, not project-specific context.
+- `approved_adrs` — proceed without; add a caveat: "Check existing ADRs before committing to this recommendation."
+
+---
+
+## Output Format
+
+```
+**Decision: <the specific question being decided — one clear sentence>**
+
+| Approach | Pros | Cons | Complexity | Token cost to implement |
+|---|---|---|---|---|
+| A: <name> | <2–3 specific pros> | <2–3 specific cons> | low / med / high | low / med / high |
+| B: <name> | <2–3 specific pros> | <2–3 specific cons> | low / med / high | low / med / high |
+| C: <name> | <2–3 specific pros> | <2–3 specific cons> | low / med / high | low / med / high |
+
+**Recommendation for this project: Approach <X>**
+Reasoning: <2–3 sentences that reference specific project constraints, stack details, or known
+goals from the task_profile or requirements_spec — not generic advice>
+
+Confidence: <high | medium | low>
+Reversibility: <easy to change later | hard to change later | irreversible — flag with WARNING>
+
+Next step: `python agents-maker/tools/generate_prompt.py "implement <chosen approach name> for <decision context>"`
+```
+
+---
+
+## Column Definitions
+
+| Column | What to write |
+|---|---|
+| Pros | Specific advantages for THIS project — reference stack, team size, timeline if known |
+| Cons | Specific drawbacks — what breaks, what becomes harder |
+| Complexity | Effort to implement: low = <1 session, med = 1–3 sessions, high = 3+ sessions |
+| Token cost | Context needed by AI to implement: low = conversation, med = 3–5 files, high = full repo |
+
+---
+
+## Rules
+
+- Always provide **2–4 options**. Never output a comparison with just one option.
+- Pros and cons must be specific to the project — not copy-pasted generic trade-offs.
+- The **Recommendation** must cite at least one known constraint from `project.yaml`,
+  `requirements_spec`, or the current conversation.
+- If `Reversibility` is **irreversible**, prepend: `⚠ WARNING: This decision is difficult to undo.`
+- If `Confidence` is **low**, explain what additional information would raise it.
+- Never recommend an approach that conflicts with an already-approved ADR or `requirements_spec` constraint.
+- If the user only asks about two options, still consider whether a third option exists (hybrid,
+  defer, or "don't solve this yet").
+- After the table, offer: "Want me to expand on any approach? Say 'expand on approach X.'"

package/skills/define_data_schema.md

@@ -0,0 +1,99 @@
+# Skill: define_data_schema
+
+## Description
+
+Produce a data schema artifact: entity-relationship sketch (ASCII), metric definition table, and data dictionary. Used by the Code Agent and Architect Agent in `data_analytics` tasks (Phases 2–3) and by any domain when a solution design requires specifying data structures.
+
+---
+
+## When to invoke
+
+- User requests a data model, schema, data dictionary, or metric definitions.
+- Architect Agent needs to specify data structures as part of a solution design.
+- Code Agent needs a schema contract before writing queries or pipeline code.
+- Review phase identifies metrics that lack formula or grain definitions.
+
+---
+
+## Input expectations
+
+| Input | Required | Description |
+|---|---|---|
+| `entities` | Yes | List of data entities (tables, streams, or collections). Each: `{name, description, key_fields[]}` |
+| `metrics` | Yes | List of metrics to define. Each: `{name, description}` |
+| `grain` | Yes | The atomic unit each metric row represents (e.g., "one row per user per day") |
+| `filters` | No | Standard filters applied to the data (e.g., `is_active=true`, `event_type='purchase'`) |
+| `existing_tools` | No | Data stack in use (e.g., "BigQuery + dbt", "Postgres + SQLAlchemy", "Spark") |
+| `relationships` | No | Foreign-key or join relationships between entities |
+
+**If required input is missing:**
+- `entities` — ask: "What data entities are involved? (e.g., users, orders, events — with their primary key fields)"
+- `metrics` — ask: "Which metrics need to be defined? List each by name and what it measures."
+- `grain` — ask: "What does one row in the output represent? (e.g., one user, one transaction, one day)"
+- `filters` — default to "none" and note: "Add standard filters if some records should always be excluded."
+- `existing_tools` — default to "unspecified"; omit tool-specific syntax notes from output.
+
+---
+
+## Output format
+
+### 1. Entity-Relationship Sketch (ASCII)
+
+```
+## Entity-Relationship Sketch
+
+<EntityA> (PK: <key>)
+  ├── <field>: <type>
+  └── <field>: <type>
+        |
+        | 1:N
+        ↓
+<EntityB> (PK: <key>, FK: <EntityA.key>)
+  ├── <field>: <type>
+  └── <field>: <type>
+```
+
+Use `|` for 1:1, `1:N` for one-to-many, `M:N` for many-to-many. If relationships were not provided, output a flat list of entities and note: "Relationships not specified — add FK links after confirming cardinality."
+
+### 2. Metric Definition Table
+
+```markdown
+## Metric Definitions
+
+| Metric | Formula | Grain | Standard Filters | NULL behavior | Owner |
+|---|---|---|---|---|---|
+| <metric_name> | <formula or description> | <grain> | <filter or "none"> | <what NULL means / how handled> | <team or role> |
+```
+
+**Required fields per metric row:**
+- **Formula** — either a precise SQL-style expression or a plain-language definition if formula is not yet specified (flag with `[draft]`)
+- **Grain** — must match the stated `grain` input or note the exception
+- **NULL behavior** — explicitly state what a NULL value means for this metric (e.g., "NULL = user has no purchases", "NULL = sensor offline")
+
+### 3. Data Dictionary
+
+```markdown
+## Data Dictionary
+
+### <EntityName>
+| Field | Type | Description | Nullable | Example |
+|---|---|---|---|---|
+| <field> | <type> | <description> | Yes / No | <example value> |
+```
+
+Generate one section per entity listed in `entities`.
+
+---
+
+## Token cost tier
+
+**Medium.** Requires translating business descriptions into precise technical definitions. Output grows with number of entities and metrics. Typical output: 400–900 tokens.
+
+---
+
+## Notes
+
+- If a metric formula is ambiguous, output it as `[draft: <best interpretation>]` and add a clarifying question below the table.
+- Flag any metric that cannot be computed from the provided entities: `[BLOCKED: requires <missing entity or field>]`.
+- If `existing_tools` is specified, add a "Tool notes" row below each metric noting any platform-specific behavior (e.g., BigQuery's handling of DIV0, dbt metric layer syntax).
+- The ER sketch uses ASCII art only — no Mermaid or PlantUML unless the user explicitly requests a diagram format.

package/skills/design_api.md

@@ -0,0 +1,126 @@
+# Skill: design_api
+
+## Description
+
+Draft a complete, unambiguous API contract for a set of related endpoints or an interface definition. Output is a structured contract that a developer can implement against without requiring further clarification. Covers REST, GraphQL (query/mutation list), and RPC-style interfaces.
+
+---
+
+## When to invoke
+
+- The Architect Agent needs to define the public surface of a new service.
+- A feature requires new endpoints and the contract must be agreed before implementation begins.
+- An existing API is being versioned or extended and the delta must be documented.
+
+---
+
+## Input expectations
+
+| Input | Required | Description |
+|---|---|---|
+| `feature_description` | Yes | What the API enables the client to do |
+| `api_style` | Yes | `REST` \| `GraphQL` \| `RPC` \| `event` |
+| `existing_contracts` | No | Snippets of existing API contracts to ensure consistency |
+| `auth_model` | No | `none` \| `bearer_token` \| `api_key` \| `oauth2` \| `session` |
+| `versioning_strategy` | No | `url_prefix` \| `header` \| `none` |
+| `non_functional` | No | Latency target, rate limits, pagination requirements |
+
+**If required input is missing:**
+- `feature_description` absent → ask: "What should this API allow a client to do? (one sentence is enough to start.)"
+- `api_style` absent → infer from project stack (`project.yaml`): Python/FastAPI → REST, GraphQL server present → GraphQL, event-driven stack → event. State the assumption; user may override inline.
+- `auth_model` absent → default to `bearer_token` for external APIs, `none` for internal. State assumption in the contract header.
+
+---
+
+## Output format
+
+### REST
+
+```
+## API Contract: <feature name>
+
+**Base path**: `/api/v<N>/<resource>`
+**Auth**: <auth_model>
+
+| Method | Path | Description | Request body | Response | Error codes |
+|---|---|---|---|---|---|
+| POST | `/resource` | <desc> | `{field: type}` | `201 {id, ...}` | 400, 409 |
+| GET | `/resource/{id}` | <desc> | — | `200 {id, ...}` | 404 |
+| PATCH | `/resource/{id}` | <desc> | `{field?: type}` | `200 {id, ...}` | 400, 404 |
+| DELETE | `/resource/{id}` | <desc> | — | `204` | 404 |
+
+### Request / Response Schemas
+
+**POST /resource — Request**
+\`\`\`json
+{
+  "field": "string",   // required; max 255 chars
+  "other": "integer"   // optional; default: 0
+}
+\`\`\`
+
+**POST /resource — Response (201)**
+\`\`\`json
+{
+  "id": "uuid",
+  "field": "string",
+  "created_at": "ISO8601"
+}
+\`\`\`
+
+### Error Response Shape
+\`\`\`json
+{
+  "error": "string",       // machine-readable code
+  "message": "string",     // human-readable
+  "details": {}            // optional; field-level validation errors
+}
+\`\`\`
+```
+
+### GraphQL
+
+```
+## GraphQL Contract: <feature name>
+
+**Queries**
+| Name | Arguments | Returns | Description |
+|---|---|---|---|
+
+**Mutations**
+| Name | Input type | Returns | Description |
+|---|---|---|---|
+
+**Types**
+\`\`\`graphql
+type Resource {
+  id: ID!
+  field: String!
+}
+\`\`\`
+```
+
+### Event / async
+
+```
+## Event Contract: <feature name>
+
+| Event name | Producer | Consumers | Payload schema | Ordering guarantee |
+|---|---|---|---|---|
+```
+
+---
+
+## Token cost tier
+
+**Medium.** Schema detail depends on endpoint count. Typical output: 400–800 tokens.
+
+Compression hint: if the contract is long, the caller may request "schema stubs only" — field names and types without descriptions or examples.
+
+---
+
+## Notes
+
+- Always include at least one error code per endpoint. "200 only" contracts are incomplete.
+- Use consistent field naming: match the existing project convention (snake_case vs camelCase) visible in `existing_contracts`.
+- Do not prescribe implementation details (ORM, DB table name, handler class). The contract is interface-only.

package/skills/improve_copy.md

@@ -0,0 +1,69 @@
+# Skill: improve_copy
+
+## Description
+
+Review and rewrite microcopy: button labels, placeholder text, error messages, empty states, tooltips, section headings, and instructional text. Output is a before/after table with a brief rationale for each change.
+
+---
+
+## When to invoke
+
+- The UX Agent identifies copy as a friction source.
+- The UI Agent needs updated labels to go with a layout change.
+- A standalone request targets onboarding copy, error messages, or empty states.
+
+---
+
+## Input expectations
+
+| Input | Required | Description |
+|---|---|---|
+| `copy_items` | Yes | List of current strings with their UI context |
+| `persona` | Yes | Who is reading this copy and what they are trying to do |
+| `tone` | No | `professional` \| `friendly` \| `technical` \| `minimal` (default: `professional`) |
+| `constraints` | No | Character limits, must-include terms, brand voice rules |
+
+**If required input is missing:**
+- `copy_items` absent → ask: "Please share the copy strings you want improved (paste them with their UI location, e.g. 'Submit button label: Submit Form')."
+- `persona` absent → infer from project domain (e.g., software → "developer using this tool") and state the assumption explicitly in the output header. Do not block on this.
+
+---
+
+## Output format
+
+```
+## Copy Improvements: <screen/feature name>
+
+**Tone**: <detected or specified>
+**Persona**: <one-line summary>
+
+| Context | Current copy | Issue | Improved copy | Rationale |
+|---|---|---|---|---|
+| Submit button | "Submit" | Generic; doesn't describe outcome | "Save changes" | Action-oriented; tells user what happens |
+| Error: required field | "Field is required" | Negative framing; no guidance | "Enter your email address" | Tells user exactly what to do |
+| Empty state | "No data" | Unexplained; leaves user stuck | "No reports yet. Create your first report →" | Explains state + shows next action |
+| Placeholder | "Enter name..." | Redundant with label | "" (remove) | Labels already describe the field |
+| Tooltip | "Click to expand" | States the obvious | Remove tooltip entirely | The chevron icon is self-explanatory |
+
+## Unchanged Items
+| Item | Reason kept |
+|---|---|
+| "Cancel" button | Standard affordance; no improvement needed |
+```
+
+---
+
+## Token cost tier
+
+**Low.** Typically 150–300 tokens regardless of number of copy items.
+
+Compression hint: this skill is already token-light. No compression needed.
+
+---
+
+## Notes
+
+- **Tone consistency**: all suggestions in a single invocation must match the specified tone. Do not mix friendly and technical voice.
+- **Character limits**: if a constraint specifies a character limit (e.g., mobile button label ≤ 20 chars), flag any suggestion that exceeds it.
+- **Do not over-improve**: if the current copy is acceptable, mark it in "Unchanged Items". Unnecessary rewrites create churn.
+- **Placeholder text**: the default recommendation is to remove placeholders when a label exists. Only suggest placeholder text if the field format is non-obvious (e.g., date format).