@litfamily/litclaude 1.0.10 → 1.0.13

package/plugins/litclaude/skills/lit-humanizer/examples/ko-essay/before.md

@@ -0,0 +1,9 @@
+물론입니다! 지역 도서관이 주민의 하루에 어떤 자리를 차지하는지 살펴보겠습니다.
+
+연화동 도서관은 평일 오전 8시에 문을 연다. 출근길에 들러 신문을 읽는 주민이 있고, 근처 학교에 다니는 아이들은 수업이 끝난 뒤 숙제를 하러 온다. 오전과 오후의 이용자는 다르지만, 같은 열람실에서 서로의 시간을 나눈다.
+
+도서관은 크지 않다. 책장은 두 층으로 이어지고, 창가에는 긴 탁자 하나가 놓여 있다. 비가 오는 날이면 우산을 접을 자리가 모자라 입구가 붐빈다. 직원은 젖은 바닥을 닦고, 아이들이 찾는 책을 서가에서 함께 찾는다. 손이 필요한 일은 대부분 눈에 보이는 곳에서 일어난다.
+
+오후 6시가 지나면 숙제를 마친 아이들이 돌아가고, 퇴근한 주민이 잡지를 펼친다. 조용한 시간이라고 해서 사람이 없는 것은 아니다. 각자 필요한 자리에 앉아 짧게 머물거나, 다음 버스가 올 때까지 창가에서 기다린다.
+
+작은 도서관이 동네의 모든 문제를 해결하지는 않는다. 그래도 아침 신문과 방과 후 숙제, 비를 피하는 몇 분을 한 건물에서 이어 준다. 문을 여는 시간이 주민의 하루와 맞닿아 있다는 점은 이 공간을 설명할 때 빼놓기 어렵다.

package/plugins/litclaude/skills/lit-humanizer/examples/ko-report/after.md

@@ -0,0 +1,9 @@
+# 연화구 저녁 버스 이용 현황
+
+연화구는 저녁 시간대 버스 운행 확대를 검토하고 있다. 2025년 5월 12일부터 16일까지 주민 312가구가 조사에 응답했고, 응답률은 68%였다.
+
+주말에 버스를 기다리는 시간이 20분을 넘었다고 답한 가구는 118곳이었다. 목적지까지 한 번 이상 환승한다고 답한 가구는 91곳이었다. 이 응답은 일부 주민이 겪는 대기와 환승 불편을 보여준다.
+
+이 조사는 표본의 대표성을 따로 검증하지 않았고 응답은 이용자의 기억에 따른다. 구 전체의 이용 양상으로 확대해 해석하기는 어렵다.
+
+저녁 운행 확대와 환승 체계 개선을 검토한다. 검토안은 매주 저녁 2회 운행을 늘리는 시범 운영이며, 운영 뒤 만족도 조사를 해 효과를 분석한다.

package/plugins/litclaude/skills/lit-humanizer/examples/ko-report/before.md

@@ -0,0 +1,13 @@
+물론입니다! 아래는 연화구 저녁 버스 이용 현황에 대한 요약입니다.
+
+## 추진 배경
+
+연화구는 주민 편의를 제고하기 위해 저녁 시간대 버스 운행을 강화하는 방안을 검토 중이다. 본 보고서는 이용자 의견을 기반으로 운행 개선 방향을 도출하고자 한다. 이번 조사는 2025년 5월 12일부터 16일까지 실시되었으며, 총 312가구가 응답했다. 응답률은 68%로 나타났다.
+
+## 주요 결과
+
+조사에 따르면 118가구는 주말에 버스를 기다리는 시간이 20분을 넘었다고 답했다. 91가구는 목적지까지 가기 위해 한 번 이상 환승한다고 응답했다. 이러한 결과를 통해 대중교통 서비스의 사각지대가 존재함을 알 수 있으며, 추가적인 개선이 필요한 시점이다. 주민들의 불편을 해소하는 것은 지속가능한 교통 환경 조성에 중요한 역할을 한다.
+
+## 검토 의견
+
+따라서 구는 저녁 시간대 운행 확대와 환승 체계 개선을 추진해야 한다. 우선 매주 저녁 2회 증편하는 시범 운영을 실시하고, 이후 만족도 조사를 통해 효과성을 분석한다. 다만 본 결과는 표본의 대표성이 검증되지 않았고 응답자의 자가 보고에 의존한다. 구체적인 세부 사항은 제한되어 있다. 그럼에도 불구하고 이번 결과는 주민의 목소리를 반영한 의미 있는 기초자료다.

package/plugins/litclaude/skills/lit-humanizer/examples/ko-slide/after.md

@@ -0,0 +1,19 @@
+# 지원금 신청 절차
+
+## 1. 신청 경로
+온라인 신청과 주민센터 방문 신청을 이용할 수 있다.
+
+## 2. 온라인
+온라인 신청은 9월 6일 시작하며 10월 29일 마감한다.
+
+## 3. 주민센터 방문
+방문 신청은 9월 13일부터 받는다. 마감일은 10월 29일이다.
+
+## 4. 일정 차이
+온라인 신청이 일주일 먼저 열린다. 두 신청 경로의 마감일은 같다.
+
+## 5. 신청 전 확인
+대상 기준과 제출 항목은 공식 안내문에서 확인한다. 세부 기준은 이 슬라이드에 싣지 않았다.
+
+## 6. 접수
+온라인 또는 주민센터 방문 중 한 경로를 선택해 신청 기간 안에 접수한다.

package/plugins/litclaude/skills/lit-humanizer/examples/ko-slide/before.md

@@ -0,0 +1,21 @@
+물론입니다! 아래는 지원금 신청 절차를 여섯 장으로 정리한 내용입니다.
+
+# 지원금 신청 절차
+
+## 1. 신청 경로
+온라인과 주민센터 방문 신청을 비교한다.
+
+## 2. 온라인 신청
+온라인 신청은 9월 6일 시작한다. 신청 기간은 10월 29일에 끝난다.
+
+## 3. 방문 신청
+주민센터 방문 신청은 9월 13일 시작한다. 신청 기간은 10월 29일에 끝난다.
+
+## 4. 기간 비교
+온라인은 방문 신청보다 일주일 먼저 시작한다. 두 경로의 마감일은 같다.
+
+## 5. 신청 전 확인
+대상 기준과 제출 항목은 공식 안내문에서 확인한다. 이 슬라이드에는 세부 기준을 따로 싣지 않는다.
+
+## 6. 다음 단계
+신청자는 온라인 또는 주민센터 방문 중 한 경로를 선택한다. 신청 기간 안에 접수한다.

package/plugins/litclaude/skills/lit-humanizer/examples/meeting-brief/after.md

@@ -0,0 +1,9 @@
+# Spring workshop planning
+
+**4 March, 10:00–10:45 · Room 3B**
+
+Mina Park will present the venue options, Sol Kim will review the budget, and Jae Lee will check the registration page.
+
+The Riverside Center is available on 18 April for 80 people. Its KRW 1,650,000 quote includes the room and projector. Civic Hall is available on 25 April for 60 people; its quote is KRW 1,200,000, with projector rental billed separately. The budget cap is KRW 1,800,000.
+
+The group will choose a venue at the meeting and assign the next steps.

package/plugins/litclaude/skills/lit-humanizer/examples/meeting-brief/before.md

@@ -0,0 +1,11 @@
+Let's dive in to the planning meeting.
+
+**Date:** 4 March, 10:00–10:45
+**Location:** Room 3B
+**Attendees:** Mina Park, Sol Kim, Jae Lee
+
+The purpose of the meeting is to discuss the spring workshop schedule. First, Mina will present the venue options. Then, Sol will review the budget. Finally, Jae will confirm the registration page.
+
+The group has two options. The first is 18 April at the Riverside Center for 80 people. The second is 25 April at the Civic Hall for 60 people. The budget cap is KRW 1,800,000. The Riverside Center quote is KRW 1,650,000, including room and projector rental. Civic Hall quoted KRW 1,200,000, with projector rental billed separately.
+
+The team should make a decision at the meeting. We will also discuss next steps, share thoughts, and align on action items so we can move forward with confidence.

package/plugins/litclaude/skills/lit-humanizer/examples/policy-faq/after.md

@@ -0,0 +1,9 @@
+# Ticket questions
+
+**Can I request a refund?** Yes. Send the order number at least 24 hours before the booked entry time.
+
+**What if I arrive late?** The ticket remains valid for 30 minutes after the selected entry time. After that, staff can admit visitors if space is available.
+
+**When should a school group arrive?** Groups with 10 or more students should arrive 15 minutes early. One adult must accompany each group of 10 students.
+
+Refunds are unavailable inside the 24-hour cutoff, and admission after the ticket's 30-minute window depends on available space.

package/plugins/litclaude/skills/lit-humanizer/examples/policy-faq/before.md

@@ -0,0 +1,9 @@
+Let's dive in to the museum's ticket policy.
+
+**Refunds:** Visitors may request a refund up to 24 hours before the booked entry time. The request must include the order number.
+
+**Late arrival:** Tickets remain valid for 30 minutes after the selected entry time. After that, staff may admit visitors if space is available.
+
+**School groups:** Groups of 10 or more students should arrive 15 minutes before their entry time. One adult must accompany each group of 10 students.
+
+These guidelines are designed to create a seamless experience for everyone. It is important to note that refunds are not available after the 24-hour cutoff, and late entry is not guaranteed. The policy is not about limiting access, but about helping the museum manage capacity.

package/plugins/litclaude/skills/lit-humanizer/examples/pr/after.md

@@ -0,0 +1,15 @@
+## Summary
+
+Clarifies the timeline for the rollout across 14 clinics. The rollout ended on 2026-09-18. The regional review is scheduled for October 2, and the launch date remains open until the review ends.
+
+## Changes
+
+- Adds the rollout completion date.
+- Distinguishes that date from the review date.
+- Removes the old estimate that implied a confirmed launch.
+
+## Checks
+
+The document review matched the clinic count to the regional rollout record. The review packet contains no approved launch date. The regional review has not taken place.
+
+The checklist is ready for October 2. This change does not affect clinic instructions or launch planning.

package/plugins/litclaude/skills/lit-humanizer/examples/pr/before.md

@@ -0,0 +1,17 @@
+## Summary
+
+Clarifies the timeline for the rollout across 14 clinics. The rollout ended on 2026-09-18. The regional review is scheduled for October 2, and the launch date remains open until the review ends.
+
+## Changes
+
+- Adds the rollout completion date.
+- Distinguishes that date from the review date.
+- Removes the old estimate that implied a confirmed launch.
+
+## Checks
+
+The document review matched the clinic count to the regional rollout record. The review packet contains no approved launch date. The regional review has not taken place.
+
+The checklist is ready for October 2. This change does not affect clinic instructions or launch planning.
+
+Let's dive in to the next steps.

package/plugins/litclaude/skills/lit-humanizer/examples/project-update/after.md

@@ -0,0 +1,7 @@
+# North Hall renovation — 18 September
+
+The project remains on schedule. The contractor finished the west stairwell on 12 September and began second-floor electrical work on 15 September. The inspection is planned for 3 October.
+
+The reading room will close from 22 to 26 September while crews replace the ventilation controls. Visitors can use the South Hall reading room during the closure.
+
+The budget is £480,000, including £22,000 for the ventilation controls. Spending through 18 September is £301,500. The next update will be published on 30 September.

package/plugins/litclaude/skills/lit-humanizer/examples/project-update/before.md

@@ -0,0 +1,9 @@
+Let's dive in to the North Hall project update.
+
+The North Hall renovation remains on schedule. The contractor finished the west stairwell on 12 September and began electrical work on the second floor on 15 September. The project team expects the second-floor inspection on 3 October.
+
+The project has made significant progress across multiple areas. The west stairwell is complete, electrical work is underway, and the inspection date has been confirmed. These milestones demonstrate the team's dedication and commitment to quality.
+
+The reading room will close from 22 September through 26 September while crews replace the ventilation controls. Visitors can use the South Hall reading room during that period. The project budget remains £480,000, including the £22,000 ventilation-control replacement. The team has spent £301,500 through 18 September.
+
+We will continue to provide updates as the project moves forward. The next update will be published on 30 September. Please let me know if you would like additional details.

package/plugins/litclaude/skills/lit-humanizer/examples/readme/after.md

@@ -0,0 +1,12 @@
+# Setup
+
+Use Node.js 20 or later. From the repository root, run:
+
+~~~sh
+npm install
+npm run build
+~~~
+
+The build writes ESM files to dist/. Then run npm test. The tests use checked-in fixtures and need no network access.
+
+If installation fails, check that the registry can reach the package host. Keep the lockfile in place while troubleshooting. This setup matches the guide reviewed on 2026-09-20.

package/plugins/litclaude/skills/lit-humanizer/examples/readme/before.md

@@ -0,0 +1,14 @@
+Let's dive in to the package setup.
+
+# Setup
+
+Install Node.js 20 or later. From the repository root, install dependencies and build the package:
+
+~~~sh
+npm install
+npm run build
+~~~
+
+The build writes ESM files to dist/. Run npm test after the build. The test command uses the checked-in fixtures and does not need network access.
+
+If npm install fails, confirm that your registry can reach the package host. The project uses a lockfile; do not remove it to work around an installation error. The README was reviewed against the setup guide on 2026-09-20.

package/plugins/litclaude/skills/lit-humanizer/examples/report/after.md

@@ -0,0 +1,13 @@
+# Quarterly rollout note
+
+The rollout covered 14 clinics and ended on 2026-09-18. The regional team completed the field checklist and sent it to the review coordinator. It records the clinic contact, operating hours, and date staff received the updated instructions.
+
+Ten clinics returned their checklists by 2026-09-12. The other four submitted them by 2026-09-18. The regional coordinator received the final checklist at 16:20 local time. All 14 clinics used the same checklist version, dated 2026-09-01.
+
+The regional review will compare returned forms with the central rollout record. Reviewers will check the clinic count, dates, and staff instruction version. The review has not started, and the forms do not confirm that each clinic followed the instructions during daily service.
+
+The checklist is ready for regional review.¹
+
+## Reference
+
+[1] Regional rollout record, 2026-09-18.

package/plugins/litclaude/skills/lit-humanizer/examples/report/before.md

@@ -0,0 +1,11 @@
+Let's dive in to the quarterly clinic rollout.
+
+# Quarterly rollout note
+
+The rollout covered 14 clinics and ended on 2026-09-18. The regional team completed the field checklist and sent it to the review coordinator. It records the clinic contact, operating hours, and date staff received the updated instructions.
+
+Ten clinics returned their checklists by 2026-09-12. The other four submitted them by 2026-09-18. The regional coordinator received the final checklist at 16:20 local time. All 14 clinics used the same checklist version, dated 2026-09-01.
+
+The regional review will compare returned forms with the central rollout record. Reviewers will check the clinic count, dates, and staff instruction version. The review has not started, and the forms do not confirm that each clinic followed the instructions during daily service.
+
+The checklist is ready for regional review. The regional rollout record dated 2026-09-18 is the source for the clinic count and completion date.

package/plugins/litclaude/skills/lit-humanizer/examples/research-abstract/after.md

@@ -0,0 +1,5 @@
+We assigned 84 first-year biology students to one of two groups. For six weeks, the practice group completed four 20-minute reading sessions each week; the comparison group kept its usual study schedule.
+
+In week seven, students took a 30-question quiz. The practice group averaged 21.4 correct answers, compared with 18.7 in the comparison group. Both groups had similar scores on the 10-question baseline quiz.
+
+The results suggest that regular reading may improve recall, though further research is needed. The study followed 84 students for six weeks. Future studies can test whether the pattern holds in other groups.

package/plugins/litclaude/skills/lit-humanizer/examples/research-abstract/before.md

@@ -0,0 +1,5 @@
+Let's dive in. This study investigates the relationship between four weekly reading sessions and recall among first-year biology students. The study represents an important contribution to the ongoing conversation about learning, highlighting the transformative potential of consistent practice.
+
+We assigned 84 students to one of two groups. The practice group completed four 20-minute reading sessions each week for six weeks. The comparison group followed its usual study schedule. On a 30-question quiz in week seven, the practice group averaged 21.4 correct answers and the comparison group averaged 18.7. The groups began with similar scores on a 10-question baseline quiz.
+
+These results suggest that regular reading may improve recall. While further research is needed and the sample is limited, the findings point toward a promising new direction. The findings are not just about the reading sessions, but about the value of a structured approach to learning. Future studies should explore this area in greater depth.

package/plugins/litclaude/skills/lit-humanizer/examples/slides/after.md

@@ -0,0 +1,19 @@
+# Water-quality pilot
+
+## 1. Sampling period
+The pilot ran from 1 June through 30 June 2026.
+
+## 2. Three river sites
+Staff collected samples at North Bridge, Market Bend, and South Weir.
+
+## 3. Sample count
+Each site contributed 24 samples; the total was 72.
+
+## 4. Lab flags
+The lab flagged 2 North Bridge samples and 3 South Weir samples for a second review. None from Market Bend were flagged.
+
+## 5. Follow-up
+The second review is scheduled for 8 July. The pilot has no assigned owner for the field follow-up.
+
+## 6. Scope
+The pilot records results at these three sites. It does not estimate river-wide conditions or establish a health effect.

package/plugins/litclaude/skills/lit-humanizer/examples/slides/before.md

@@ -0,0 +1,19 @@
+Let's dive in to the water-quality pilot.
+
+## Slide 1 — Sampling period
+The pilot ran from 1 June through 30 June 2026.
+
+## Slide 2 — Locations
+Staff collected samples at three river sites: North Bridge, Market Bend, and South Weir.
+
+## Slide 3 — Sample count
+The team collected 24 samples at each site, for 72 samples total.
+
+## Slide 4 — Lab flags
+The lab flagged 2 samples from North Bridge and 3 from South Weir for a second review. No samples from Market Bend were flagged.
+
+## Slide 5 — Follow-up
+The lab scheduled the second review for 8 July. The pilot has not assigned an owner for the field follow-up.
+
+## Slide 6 — Boundary
+The pilot records sample results at the three sites. It does not estimate river-wide conditions or establish a health effect.

package/plugins/litclaude/skills/lit-humanizer/examples/troubleshooting/after.md

@@ -0,0 +1,11 @@
+# Upload requests return 429
+
+The API allows 60 requests per minute per account. A 429 response includes a Retry-After header with the number of seconds to wait before sending another request.
+
+Read that header and pause for the stated interval. For example, if the value is 30, wait 30 seconds before retrying:
+
+~~~sh
+curl -i -X POST https://api.example.test/uploads
+~~~
+
+The rate limit resets every minute. Check the account's request count in the dashboard if 429 responses continue after the wait. Contact support if repeated 429 responses persist.

package/plugins/litclaude/skills/lit-humanizer/examples/troubleshooting/before.md

@@ -0,0 +1,11 @@
+Certainly! Here is a comprehensive guide to resolving upload errors.
+
+If the API returns 429, it means that the request rate is too high. The service accepts up to 60 requests per minute for each account. The response includes a Retry-After header with the number of seconds before another request can be sent.
+
+First, it is important to check whether your client reads this header. Then, you can implement a robust retry strategy. The following example uses a 30-second delay:
+
+~~~sh
+curl -i -X POST https://api.example.test/uploads
+~~~
+
+If errors continue, check your account's request count in the dashboard. The rate limit resets every minute. Contact support if your client receives repeated 429 responses after following these steps. Let me know if you'd like me to provide an example in another language.

package/plugins/litclaude/skills/lit-humanizer/motion-guide.md

@@ -0,0 +1,123 @@
+# Motion guide for frontend work
+
+This guide turns motion into a small, testable part of the interface. Start with one sentence naming the page, target components, and out-of-scope areas; follow it with labeled sections in implementation order. Specify the stack, visual tokens, layers, timing, viewport behavior, reduced-motion behavior, assets, and performance limits before describing a page. Name exact files or components so the implementation does not invent unrelated sections. A page brief may name component families such as hero, pricing, footer, or dashboard before detailing the chosen one.
+
+All values below are starting defaults. Keep the page calm when motion does not explain hierarchy, state, or cause and effect.
+
+## 1. Stack, tokens, and composition
+
+**Do:** Name the framework, styling system, animation package, icon set, and their tested version pins. Define colors, spacing, font family, numeric weights, and breakpoints as reusable tokens. Use a distinct mobile navigation component when the desktop layout no longer fits. Assign a short z-index map before adding overlays.
+
+**Don't:** ask for a “modern animated site” without stating the stack, scope, or interaction. Don't leave the package versions open-ended when the work depends on an animation API.
+
+```text
+Stack: [framework + pinned version], [styling + pinned version], [motion + pinned version].
+Scope: [named components only].
+Layers: background 0; page content 10; navigation 30; modal 50.
+Breakpoints: mobile [value], medium [value], wide [value].
+```
+
+**Do:** Give fluid display type a `clamp()` range, numeric weight, and tight but readable line-height. State how fonts load and name a system fallback. Pair a large heading with a restrained content width. Set colors with tokens; use `rgba()` when alpha matters on translucent surfaces, and choose a tinted near-black base when the design calls for a dark canvas. A blend mode may shape a heading or light treatment when its contrast is checked against the final background.
+
+**Don't:** use “large,” “glass,” or “dark” as the only specification. Don't add a blur, gradient, or blend mode without deciding which layer it affects and how text remains legible.
+
+**Do:** Put reusable visual primitives in one place and refer to them by name. Let a background gradient end at the page's base color so a scroll does not reveal a hard seam. State spacing at mobile, medium, and wide breakpoints in one consistent vocabulary, for example `16 / 24 / 32 px` in the order mobile / medium / wide. Keep one breakpoint vocabulary throughout the brief.
+
+**Don't:** duplicate slightly different blur or spacing values across components, or let a fixed media layer cover focus rings and text.
+
+## 2. Timing and viewport choreography
+
+Use named curves so a later editor can change the motion family without hunting through components:
+
+| Name | Curve | Default duration | Use |
+|---|---|---:|---|
+| `enter` | `cubic-bezier(0.16, 1, 0.3, 1)` | 420 ms | A short entrance that settles cleanly |
+| `ui` | `cubic-bezier(0.2, 0.8, 0.2, 1)` | 180 ms | Hover, focus, and state feedback |
+| `exit` | `cubic-bezier(0.4, 0, 1, 1)` | 160 ms | Dismissal or removal |
+
+**Do:** pair every duration with one named curve. Keep ordinary controls below 400 ms. Give an entrance and an exit different intent. Keep the hover feedback shorter than the compositional reveal.
+
+**Don't:** use a duration with the browser's unspecified default curve, or put an elastic bounce on routine navigation.
+
+**Do:** Trigger a reveal when at least 15% of its section enters view, with a bottom root margin of 10%. Trigger once per section; make the content visible if observation is unavailable. For a scroll-linked effect, define a progress interval and its output range, then use one dominant movement in the hero.
+
+**Don't:** animate every section continuously, make multiple parallax layers compete, or hide content until the observer fires.
+
+**Do:** Stagger a small group by 60 ms per item and cap the sequence at 300 ms. Express it as a base delay plus `itemIndex × 60 ms`, so every item's timing is inspectable. Keep each group short enough that the first item is still relevant when the last appears. A menu may use a separate overlay and a brief item sequence.
+
+**Don't:** delay each item by a large fixed pause, stagger a long article line by line, or make users wait for the page to become readable.
+
+## 3. Motion and resource budgets
+
+**Do:** Give each section one entrance sequence and no more than two simultaneously moving elements. Give the hero one principal scroll or entrance effect and one animated headline. Keep controls responsive while decorative motion runs.
+
+**Don't:** animate the headline, background, cards, icons, and navigation at once. Remove any motion whose absence does not change comprehension or feedback.
+
+**Do:** Animate `transform` and `opacity` for routine movement. Target a frame callback below 4 ms so the page has room for layout, paint, and input work within a 60 Hz frame. Check for dropped frames on a mid-range device.
+
+**Don't:** animate `top`, `left`, `width`, or `height` on every frame, or assume a desktop GPU represents a phone.
+
+**Do:** Keep the first view within a stated transfer budget. As a default, limit initial motion media to 1 MB compressed and a video poster to 150 KB. Lazy-load below-the-fold media; size images for their rendered slot; split optional motion code from the initial route.
+
+**Don't:** fetch a large background video before the user sees the page, ship multiple full-resolution images for a small card, or treat a CDN as a performance plan.
+
+**Do:** Provide a real poster frame for every background video. On small screens or when the browser signals data saving, use the poster or a still image and skip video download and autoplay. Keep the same message and contrast in the fallback.
+
+**Don't:** make a video the only source of information or start a large media request on a metered connection.
+
+**Do:** Treat a sticky background video as its own positioned layer with a separately sized overlay; state the overlay's coverage, such as the lower 40% of the frame. Group its playback requirements together: autoplay where allowed, muted, looping, and inline playback. Point to an approved project asset or media source by its existing name. If none exists, ask for a real asset or specify a designed still; do not leave a fake URL in the brief.
+
+**Don't:** bury a media source in an arbitrary CSS background, or let a video layer intercept text selection and focus.
+
+## 4. Accessibility and input modes
+
+**Do:** Honor `prefers-reduced-motion`. Show the final content state immediately, remove parallax and tilt, and reduce nonessential transitions. Keep focus movement, visible focus, keyboard operation, and meaningful image text independent of animation.
+
+**Don't:** use motion as the only way to reveal a label, indicate success, or make a control reachable.
+
+```css
+@media (prefers-reduced-motion: reduce) {
+  .motion-enter,
+  .motion-scroll,
+  .motion-tilt {
+    animation: none;
+    transition-duration: 0.01ms;
+    transform: none;
+  }
+}
+```
+
+**Do:** Restrict pointer tilt to fine-pointer devices. Clamp rotation to ±4 degrees, reset on pointer exit, and leave touch input alone. Compose the tilt with other transforms instead of overwriting them.
+
+**Don't:** request device orientation, require a hover to expose content, or let a pointer effect move text away from its focus target.
+
+Give cursor tracking its own interaction scope and budget. For a 3D scene or carousel, name the component and supported input before specifying its movement; check it under a separate frame and device budget because it can cost more than a small CSS transition.
+
+## 5. One headline and a deliberate pace
+
+**Do:** Choose one headline for a restrained reveal. Keep its full text in the accessibility tree and make it readable before an animation library loads. Give the rest of the page stable text and a clear reading order.
+
+**Don't:** animate every character, repeat the same reveal on every section title, or split a short heading into a long sequence.
+
+**Do:** Let the page open with its primary point, settle while the reader scans, use one reveal for a meaningful section change, then let the call to action rest. Test the complete path with motion enabled, with reduced motion, and with media unavailable.
+
+**Don't:** put a continuous moving background behind dense copy, make the final action compete with a transition, or use a repeated animation to fill an otherwise empty section.
+
+## 6. Interaction details and implementation order
+
+**Do:** Specify hover, focus, pressed, disabled, and open states independently. Give icon swaps their own rotation angle and short duration. Keep a mobile menu's overlay opacity and blur distinct from desktop navigation. Size proof cards and other evidence blocks for the amount of text they actually carry; for example, set an 18–22 rem width range and let height follow content.
+
+**Don't:** treat a hover state as keyboard feedback or reuse the same opacity and blur values for every surface.
+
+**Do:** Organize labeled sections in dependency order: stack and tokens, page structure, media and fallbacks, navigation, content, interactions, dependencies, then build configuration. State responsive spacing and padding at mobile, medium, and wide sizes together. Treat an early render as a draft; refine it against the scope and device targets.
+
+**Don't:** let the visual scroll order dictate dependency order, add unrelated sections, or leave library versions unspecified after the design relies on a particular API.
+
+## Review checklist
+
+- Are the stack, scope, breakpoints, font loading, tokens, and layer order explicit?
+- Does each motion have a named curve, duration, trigger, and reduced-motion result?
+- Does each section stay within its motion budget, with one dominant hero effect?
+- Are media poster, mobile/data-saving fallback, lazy loading, and transfer budget specified?
+- Are focus, keyboard use, contrast, and nonanimated content complete?
+- Are package versions pinned, and does the page remain readable when motion or media is unavailable?