레이아웃 흡수 스킬 (layout-page-absorber) — 기존 페이지를 새 레이아웃으로

layout-page-absorber는 반복 업무를 더 안정적으로 처리하기 위한 AI 에이전트 스킬입니다.

Absorb existing Eond layout pages into another layout, especially moving pages from el_gate, el_pro, el_imweb, el_aithres, el_main, wpmarket, or rhymixmarket into el_unified while preserving content intent, route behavior, required context variables, CSS/JS dependencies, responsive behavior, and verification. Use when the user asks to unify layouts, migrate/port/copy/흡수/통합 pages, create a page migration task list, or make a reusable workflow for future layout production.

사용 방법

Codex나 호환되는 AI 에이전트의 스킬 폴더에 아래 SKILL.md 내용을 저장한 뒤, 설명에 포함된 트리거 문장으로 호출하세요.

사용 예:
layout-page-absorber 스킬 사용해줘.
이 작업은 layout-page-absorber 기준으로 진행해줘.

원본 위치

.codex/skills/layout-page-absorber/SKILL.md

SKILL.md

---
name: layout-page-absorber
description: Absorb existing Eond layout pages into another layout, especially moving pages from el_gate, el_pro, el_imweb, el_aithres, el_main, wpmarket, or rhymixmarket into el_unified while preserving content intent, route behavior, required context variables, CSS/JS dependencies, responsive behavior, and verification. Use when the user asks to unify layouts, migrate/port/copy/흡수/통합 pages, create a page migration task list, or make a reusable workflow for future layout production.
---

# Layout Page Absorber

Use this skill to move an existing layout page into a target layout without breaking routing, context variables, visual consistency, or site goals.

## Reference Selection

Read `references/eond-layout-page-absorption.md` when:

- Choosing which pages to absorb first.
- Building a migration checklist.
- Porting pages into `el_unified`.
- Deciding whether to copy markup, rewrite CSS, or create target-layout components.

## Workflow

1. Identify source and target:
   - Source layout/page: `templates/layouts/{source}/pages/{page}.html`
   - Target layout/page: `templates/layouts/{target}/pages/{page}.html`
   - Route or mid that should render it.

2. Inspect routing before editing:
   - Check `app/page_context.py` for whether the mid is static, board, contents, market, portfolio, or special-case.
   - Confirm whether adding `pages/{mid}.html` is enough.
   - If a module exists, verify whether the static page takes precedence for that mid.

3. Audit dependencies:
   - Template variables used by the source page.
   - CSS classes and external CSS files required.
   - JS behaviors required.
   - Assets referenced by URL.
   - Links that should keep `?_layout={target}` during preview.

4. Choose migration mode:
   - **Direct absorb**: Source uses shared classes already loaded by target. Copy and adjust only `qs`, comments, links, and copy.
   - **Adapter absorb**: Source markup mostly stays, but add target CSS wrappers or a small target CSS file.
   - **Rewrite absorb**: Source depends on another design system or JS stack. Rebuild with target tokens/components.

5. Implement narrowly:
   - Add only the target page and the smallest required CSS/JS.
   - Do not move unrelated source files.
   - Preserve original content intent, but update wording if the target site strategy changed.
   - Avoid nested cards and ornamental gradients unless the target layout already uses them.

6. Verify:
   - Run syntax checks for changed JS and Python where applicable.
   - Render the target template with realistic menu/site context.
   - Search rendered HTML for key text, links, and external-link attributes.
   - Check responsive and overflow risks when CSS changes affect layout shell.

7. Report:
   - Source page absorbed.
   - Target page created or changed.
   - Any fallback/route caveats.
   - Next pages in priority order.

## Output Expectations

For planning-only requests, produce:

- Candidate page inventory.
- Priority score: revenue impact, traffic importance, implementation risk, design fit.
- Batch plan with 3-5 pages per phase.

For implementation requests, finish with:

- Files changed.
- Verification commands and results.
- Known limitations.

참고 리소스

이 스킬이 직접 참조하는 Markdown 참고 파일입니다. 재사용할 때 같은 상대 경로로 저장하면 동작이 안정적입니다.

.codex/skills/layout-page-absorber/references/eond-layout-page-absorption.md

# Eond Layout Page Absorption Reference

## Goal

Use `el_unified` as the global Eond shell while gradually absorbing useful content pages from older/specialized layouts.

The target is not to delete the old layouts immediately. The target is to make important routes render coherently inside the unified header, menu, footer, search, and service-map experience.

## Priority Rules

Score each candidate page:

| Criterion | Meaning |
|---|---|
| Revenue impact | 제작의뢰, 마켓 판매, 호스팅, AXAI 상담, eondcms 도입으로 이어지는가 |
| Navigation importance | 현재 메인 메뉴나 검색에서 바로 연결되는가 |
| Design fit | `el_unified`가 이미 로드하는 CSS/classes로 흡수 가능한가 |
| Context safety | 필요한 template variables가 `build_layout_context` 또는 route context에 있는가 |
| Risk | 결제, 글쓰기, 인증, 복잡한 JS, 외부 API 의존이 있는가 |

Start with high revenue and low risk pages.

## Recommended First Batches

### Batch 1: Static gateway and revenue pages

- `market`: source `el_gate/pages/market.html`, target `el_unified/pages/market.html`
- `works`: source `el_gate/pages/works.html`, target `el_unified/pages/works.html`
- `privacy`, `terms`: source `el_gate/pages/*`, target `el_unified/pages/*`
- `notice` or `support`: only if static and low-risk

### Batch 2: Portfolio and product trust pages

- `works_detail`: requires route context from works router.
- portfolio list/view: compare `el_pro`, `wpmarket`, `el_main` variants.
- service detail pages from `el_pro/pages/service_*.html`.

### Batch 3: Community/content layouts

- board list/view/edit from `el_reddit`, `el_aithres`, `el_dev`, `rhymixmarket`.
- These need permission, write/delete, comment, attachment, and responsive checks.

## Migration Modes

### Direct absorb

Use when source classes are already loaded by target. Example: `el_gate` pages inside `el_unified`, because `layout.html` loads `/static/el_gate/theme.css` and `/static/el_gate/gate.css`.

Checklist:

- Change preview query from source layout to target layout.
- Update page comments.
- Keep links absolute or target-layout friendly.
- Render test with target layout.

### Adapter absorb

Use when markup is good but classes are source-specific. Add a small target CSS file with scoped class names.

Checklist:

- Prefix new CSS with page/layout prefix.
- Avoid importing entire old layout CSS if it affects shell.
- Add `<link rel="stylesheet">` from target page only.

### Rewrite absorb

Use when source depends on Tailwind, Alpine, framework-specific components, or heavily branded visuals.

Checklist:

- Rebuild sections using target tokens/classes.
- Convert JS interactions to `static/{target}/theme.js` conventions.
- Keep content and data flow, not necessarily markup.

## Route Notes

`app/page_context.py` renders `layouts/{active_layout}/pages/{mid}.html` for static mids when the module does not exist. For existing board/contents mids, static pages may not take precedence unless special-case logic allows it.

Before assuming a page works, inspect the relevant route section and render with real context.

## Verification Checklist

- Template renders with realistic `site`, `request`, `main_menu`, `asset_version`.
- Key headings and CTAs appear.
- Links preserve target preview query only when appropriate.
- External links use `target="_blank" rel="noopener"`.
- No horizontal overflow from `100vw`, fixed widths, long words, or unboxed padding.
- Mobile layout remains single-column or scroll-safe.
- JS syntax passes if changed.
- Python compile passes if route/context code changed.