콘텐츠 메이커 스킬 (contentsmaker) — 게시글과 짧은 글 초안

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

사용자가 일반 게시판용 글, Threads 같은 짧은 글, 또는 API로 등록할 게시글 초안을 요청할 때 사용한다. "글등록스킬", "글 등록 스킬", "게시글 등록", "글 올려줘", "이 내용을 글로 등록", "프롬프트 게시글 만들어줘"라고 말해도 이 스킬을 사용한다. 원문 메모를 읽고 게시판 성격과 독자 수준에 맞춰 제목, 본문, 요약, 태그, 톤을 정리하며 필요하면 게시글 등록용 payload와 대표이미지/스크린샷 첨부값까지 만든다.

사용 방법

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

사용 예:
contentsmaker 스킬 사용해줘.
이 작업은 contentsmaker 기준으로 진행해줘.

연관스킬

이 스킬과 함께 쓰면 좋은 관련 스킬입니다.

• portfolio-thumbnail-maker

원본 위치

.codex/skills/contentsmaker/SKILL.md

SKILL.md

---
name: contentsmaker
description: 사용자가 일반 게시판용 글, Threads 같은 짧은 글, 또는 API로 등록할 게시글 초안을 요청할 때 사용한다. "글등록스킬", "글 등록 스킬", "게시글 등록", "글 올려줘", "이 내용을 글로 등록", "프롬프트 게시글 만들어줘"라고 말해도 이 스킬을 사용한다. 원문 메모를 읽고 게시판 성격과 독자 수준에 맞춰 제목, 본문, 요약, 태그, 톤을 정리하며 필요하면 게시글 등록용 payload와 대표이미지/스크린샷 첨부값까지 만든다.
---

# Contents Maker

## 역할

- 원문 메모를 게시판 글 또는 짧은 스레드 글로 바꾼다.
- 일반 유저가 바로 이해할 수 있게 용어, 길이, 구조를 조절한다.
- 필요하면 게시판 타입을 판단하고, API 등록용 필드를 함께 만든다.
- 사용자가 `글등록스킬`, `글 등록 스킬`, `게시글 등록`, `글 올려줘`라고 말하면 이 스킬의 별칭으로 인식한다.

## 기본 원칙

1. 먼저 대상 형식을 정한다.
   - `board_post`: 일반 게시판, 공지, 안내, 가이드, 후기, Q&A
   - `thread_post`: Threads, X, 짧은 홍보성/요약형 글
2. 사용자가 형식을 지정하지 않으면 내용과 채널에 맞춰 추정한다.
3. 사실이 불명확하면 임의로 지어내지 말고 짧게 확인 질문을 한다.
4. 글은 독자가 다음 행동을 쉽게 알 수 있게 구성한다.
5. API 등록이 필요하면 글 본문과 별도로 전송용 구조를 만든다.
6. 사용자가 따로 요구하지 않아도 AI가 쓴 글처럼 보이는 표현을 줄이고, 실제 운영자가 쓴 자연스러운 게시글 톤을 우선한다.

## 작성 순서

1. 원문에서 핵심 메시지, 대상 독자, 강조점, 제약을 뽑는다.
2. 게시판/스레드에 맞는 길이와 톤을 정한다.
3. 제목, 본문, 요약, CTA, 태그를 만든다.
4. 서비스/사이트 소개글이면 대표이미지가 필요한지 확인하고, 가능하면 스크린샷 또는 `og:image`를 본문 첫 이미지로 넣는다.
5. 필요하면 `api_post` 형태로 등록값을 구성한다.
6. 최종 출력은 사용자가 바로 붙여넣거나 등록할 수 있게 정리한다.

## 자연스러운 사람 글쓰기

게시판 글은 기계적으로 완벽한 보고서보다 실제 운영자가 읽고 쓰는 글처럼 보여야 한다.

- 첫 문장은 과한 선언 대신 상황이나 필요에서 시작한다.
- 모든 문단을 `첫째/둘째/마지막으로`처럼 정리하지 않는다.
- `혁신적인`, `강력한`, `완벽한`, `최적화된`, `사용자 경험을 극대화`처럼 AI가 자주 쓰는 과장어를 피한다.
- 근거 없는 칭찬, 보장형 표현, 가짜 후기 느낌의 문장을 만들지 않는다.
- 문장은 짧게 쓰되 일부 리듬은 자연스럽게 둔다. 모든 문장이 같은 길이로 끝나면 기계적으로 보인다.
- 제목은 검색성을 유지하되 낚시성·광고성 느낌을 줄인다.
- 마무리는 매번 `도움이 되길 바랍니다`로 끝내지 말고, 글의 목적에 맞는 다음 행동만 남긴다.
- 사용자가 준 말투가 있으면 그 말투를 우선하고, 운영자 공지라면 차분하고 책임 있는 톤을 사용한다.

## 모드 선택

- `board_post`
  - 제목은 명확하고 검색 가능한 표현을 우선한다.
  - 본문은 도입, 핵심, 세부, 마무리 순으로 정리한다.
  - 소제목, 목록, 예시를 허용한다.
  - 단순한 소개글은 목록을 남발하지 말고 짧은 문단 중심으로 쓴다.
- `thread_post`
  - 첫 문장에 핵심을 둔다.
  - 한 글에 한 메시지만 담는다.
  - 문장은 짧게 유지하고 줄바꿈으로 리듬을 준다.
  - 글자수 제한이 있으면 먼저 지키고, 부족하면 스레드 분할을 제안한다.

## 게시판 판단

- 공지/업데이트: 변경점, 영향, 행동 안내를 앞에 둔다.
- 가이드/설명: 초보자 기준으로 단계와 용어 설명을 넣는다.
- 커뮤니티/후기: 자연스러운 말투를 유지하고 과한 운영자 문체를 피한다.
- FAQ/Q&A: 질문과 답을 짝지어 짧고 명확하게 쓴다.

## API 출력

- 등록이 필요하면 텍스트와 별도로 아래 항목을 채운다.
  - `board_type`
  - `title`
  - `content`
  - `summary`
  - `tags`
  - `thumbnail_url`
  - `pending_file_srls`
  - `status`
  - `visibility`
- 실제 API 스키마가 있으면 그 스키마를 우선한다.
- 스키마가 없으면 추정값과 확정값을 구분해서 적는다.
- API 등록 규칙과 예시는 [api-posting.md](references/api-posting.md)를 우선한다.
- 이 저장소에서는 `mid`, `category_srl`, `is_secret`, `pending_file_srls`, `extra_vars`까지 함께 고려한다.
- 외부 서비스 소개글처럼 `site_url`이 있는 글은 대표이미지 규칙과 업로드 절차를 [representative-image.md](references/representative-image.md)에서 확인한다.

## 출력 형식

기본 출력은 아래 순서를 따른다.

1. `mode`
2. `target_board`
3. `title`
4. `content`
5. `summary`
6. `tags`
7. `api_post` 또는 `등록용 payload`

## 참고 문서

- 게시판별 글 구조와 톤: [board-formats.md](references/board-formats.md)
- 글쓰기 규칙과 길이 통제: [writing-rules.md](references/writing-rules.md)
- API 등록 필드와 예시: [api-posting.md](references/api-posting.md)
- 대표이미지/스크린샷 첨부: [representative-image.md](references/representative-image.md)

참고 리소스

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

.codex/skills/contentsmaker/references/api-posting.md

# API Posting

## Purpose

Define how to turn source notes into a post that fits the target board and can also be sent through an API.

The skill should do two things at once:

- decide which board the content belongs to
- shape the content so general users can understand it quickly

## Core writing rule

When the user says something like:

- "이 내용을 정리해서 말해줘"
- "컨텐츠메이커 스킬로 글 써줘"
- "이걸 일반 게시판 글로 바꿔줘"
- "이걸 Threads 글로 써줘"

then produce a post that matches the board type, not just a plain summary.

## Board behavior

### board_post

Use this for regular bulletin boards.

Write the content in a way that:

- explains the main point first
- keeps the structure easy to scan
- adds detail only when it helps understanding
- uses headings, bullets, or short paragraphs when needed

### thread_post

Use this for Threads-style short posts.

Write the content in a way that:

- starts with the main point immediately
- keeps each sentence short
- trims extra explanation
- respects the character limit first

## API mapping

If the content will be registered by API, prepare a payload like this:

- `board_type`
- `board_id`
- `title`
- `content`
- `summary`
- `tags`
- `thumbnail_url`
- `status`
- `visibility`
- `format`

## Project schema

For this repository, the board write flow maps closely to these fields:

### Core document fields

- `mid`
- `title`
- `content`
- `tags`
- `category_srl`
- `is_secret`
- `pending_file_srls`
- `thumbnail_url`
- `slug`

### Document model fields

- `module_srl`
- `category_srl`
- `title`
- `content`
- `tags`
- `status`
- `password`
- `member_srl`
- `user_id`
- `user_name`
- `nick_name`
- `email_address`
- `regdate`
- `last_update`
- `extra_vars`

### Extra vars used by the write form

- `price`
- `product_id`
- `site_url`
- `market_url`
- `long_text`
- `schedule_date`
- `project_status`
- `event_color`
- `end_date`
- `version`
- `rhymix_compat`
- `license`
- `demo_url`
- `badge`
- `highlights`
- `pricing`
- `options`

### Board-specific conditions

- `status` becomes `PUBLIC`, `PENDING`, `SPAM_REPORTED`, or `SECRET` depending on write-time rules.
- `tags` are merged from the form field and `#hashtags` in the content.
- `category_srl` must belong to the target board or it is reset to `0`.
- `extra_vars` should be treated as JSON when present.
- For service introduction posts with a source URL, prepare a representative image before publishing. Use `thumbnail_url` for the uploaded path and insert it as the first `<img>` in `content`; include `pending_file_srls` when the upload endpoint returns file ids.

## Output rule

Return both of these when needed:

1. human-readable post content
2. API-ready payload

Do not mix transport fields into the visible post unless the target platform requires it.

## Example payload

```json
{
  "board_type": "thread_post",
  "board_id": "threads",
  "mid": "threads",
  "title": "컨텐츠메이커 스킬 소개",
  "content": "원문을 일반 유저가 이해하기 쉬운 글로 바꿔주는 규칙을 정의합니다.",
  "summary": "게시판과 스레드용 글을 자동 정리하는 스킬",
  "tags": ["content", "thread", "board"],
  "thumbnail_url": "",
  "status": "draft",
  "visibility": "public",
  "format": "plain_text",
  "category_srl": 0,
  "is_secret": "N",
  "pending_file_srls": []
}
```

.codex/skills/contentsmaker/references/representative-image.md

# Representative Image

Use this when a board post introduces an external service, website, app, AI tool, product, or portfolio item and the source has a public URL.

For advanced portfolio thumbnails with scroll reveal capture, responsive screenshots, or desktop/tablet/mobile mockup composition, use `$portfolio-thumbnail-maker`.

## Default rule

- Create or fetch a representative image before publishing whenever `site_url` or a source URL is available.
- Prefer a screenshot of the landing page above a generic logo, because list cards use the first image as the thumbnail.
- Put the image at the very top of `content` before the first paragraph:

```html
<p><img src="/static/uploads/YYYY/MM/file.png" alt="서비스명 화면"></p>
```

## Existing project behavior

- The page renderer extracts the thumbnail from the first `<img>` in `content`.
- The upload table is `xe_files` through `app.models.file.RhymixFile`.
- On production Eond/Rhymix sites, prefer Rhymix-compatible `./files/attach/images/YYYY/MM/DD/file.ext` in `xe_files.uploaded_filename` and `/files/attach/images/YYYY/MM/DD/file.ext` in visible `content`.
- Do not use `/static/uploads/...` for public `eond.com` or `ai.eond.com` content unless the deployment is verified to serve that route.
- Valid uploaded image records should use:
  - `upload_target_srl`: document srl after the post exists, or `0` while pending
  - `module_srl`: target board module srl
  - `member_srl`: author member srl
  - `uploaded_filename`: `./files/attach/images/YYYY/MM/DD/<filename>.<ext>` for Rhymix-compatible production uploads, or `/static/uploads/YYYY/MM/<uuid>.<ext>` only for verified eondcms local uploads
  - `mime_type`: `image/png`, `image/jpeg`, `image/webp`, or similar
  - `isvalid`: `Y`

## Preferred upload flow

1. If using the web write flow, call the existing authenticated endpoint:
   - `POST /upload/from-url`
   - Body includes the target URL plus viewport settings.
   - It screenshots with Playwright and falls back to `og:image`.
2. Insert the returned `url` as the first image in `content`.
3. Include the returned pending file id in `pending_file_srls` when available.
4. Publish the post, then verify the detail page and board list show the thumbnail.

## Direct DB posting flow

When posting directly with repository scripts:

1. Capture a screenshot with Playwright at a desktop viewport such as `1365x768`; if capture fails, fetch `og:image`.
2. For production Eond/Rhymix boards, save/upload the image under `public_html/files/attach/images/YYYY/MM/DD/` and use a Rhymix-compatible DB path. Use `static/uploads/YYYY/MM/` only when that route is known to be publicly served.
3. Create the document.
4. Create or update a `RhymixFile` record linked to the document:
   - `upload_target_srl=document_srl`
   - `module_srl=target module_srl`
   - `member_srl=author member_srl`
   - `uploaded_filename=./files/attach/images/YYYY/MM/DD/file.ext` for production Rhymix uploads
5. Prefix `content` with `<img src="/files/attach/images/YYYY/MM/DD/file.ext" ...>` and set `uploaded_count` to at least `1` if the document model field is available.
6. Verify:
   - detail URL returns `200`
   - board list returns `200`
   - page HTML contains the title and first `<img src="/files/attach/...">`
   - the public image URL returns `200` and an `image/*` content type

## Fallbacks

- If the website blocks screenshot capture, use `og:image`.
- If neither screenshot nor `og:image` works, publish the post only after noting that no representative image was available.
- Do not use unrelated stock images for factual service introductions.

.codex/skills/contentsmaker/references/board-formats.md

# Board Formats

## 1. board_post

Use for normal bulletin boards, notices, guides, announcements, FAQs, reviews, and community posts.

Recommended structure:

1. Title
2. Short summary
3. Main body with headings
4. Next action or closing line

Tone:

- clear
- practical
- friendly but not verbose

## 2. thread_post

Use for Threads-style short posts and other tight character-limited formats.

Recommended structure:

1. Hook sentence
2. Core point
3. One supporting detail
4. Optional follow-up or CTA

Tone:

- short
- direct
- single-message focus

## 3. Board selection hints

- Use `board_post` when the user needs explanation, steps, or a reusable notice.
- Use `thread_post` when the user needs speed, reach, or a short platform-native post.
- If the user says "스레드", "짧게", "글자수 제한", or gives a platform-specific limit, prefer `thread_post`.
- If the user says "공지", "가이드", "정리해서", or "게시판에 올릴 글", prefer `board_post`.

.codex/skills/contentsmaker/references/writing-rules.md

# Writing Rules

## Required checks

- Keep the message understandable for a general user.
- Remove jargon unless it is needed.
- Put the most important point first.
- Do not invent facts that were not provided.
- If the source is too thin, ask for the missing facts before writing.

## Rewrite rules

- Convert notes into a clean hierarchy.
- Prefer short sentences.
- Split long paragraphs into smaller blocks.
- Turn vague claims into concrete user-facing benefits.
- Keep the tone aligned with the target board.

## Human-like posting rules

- Do not over-polish every sentence. Keep a natural operator or creator voice.
- Avoid generic AI phrases such as `혁신적인`, `강력한`, `완벽한`, `최적화된`, `새로운 차원의`, `사용자 경험을 극대화`.
- Avoid repeated paragraph formulas: `이 글에서는`, `첫째`, `둘째`, `마지막으로`, `결론적으로`.
- Use bullets only when they make scanning easier. A normal post can use short paragraphs instead.
- Do not invent emotional praise, fake confidence, fake reviews, awards, or performance numbers.
- Keep one or two slightly conversational transitions when appropriate, especially for community posts.
- If the user gives rough wording, preserve useful phrases instead of replacing everything with corporate copy.
- End with the real next action, not a generic closing sentence.

## Length control

- For `board_post`, expand only when the extra detail helps comprehension.
- For `thread_post`, reduce to one idea per sentence when possible.
- If the character budget is tight, trim examples before trimming the main point.

## Output hygiene

- Use the user's terminology when it is clear.
- Normalize repeated points into one statement.
- Preserve quoted names, URLs, and product terms exactly when they matter.
- Before finalizing, remove phrases that make the text read like an AI-generated marketing summary.