← Blog Automation Pack

5단계 온보딩 코스 / Interactive course →

Blog Automation Pack user guide

Before you buy

This is downloadable code, configuration examples and operating documentation to set up on your computer. You must install tools, connect accounts and review output. Uploading the ZIP to a web chat does not start the pipeline. Setup services, AI subscriptions, API credits and hosting are not included. Setup and first-output time depend on your environment.

The instructions target macOS and a terminal. Linux and Windows/WSL require changes to shells, paths, fonts, browser connections, notifications and scheduling; unchanged operation is not guaranteed. Start with one account and one output. Local jobs do not run while the computer is off or asleep.

Do I need both Claude and Codex subscriptions?

No. Start with one supported cloud CLI that your account can access, with enough remaining usage. Multiple engines provide alternatives when a provider is unavailable. An installation assistant and the CLI invoked by the scripts are separate: signing into a desktop app does not establish that CLI authentication is ready.

Set the engine order to the CLI you use. Image, voice and video APIs may charge separately from a text CLI subscription. Total running cost includes your chosen AI access, media generation and hosting/execution, in addition to the pack. Measure a single output before scheduling; no fixed monthly running cost is promised. Check provider billing and budget controls first.

Official documentation checked on 2026-09-28; check again before paying because plans, limits and models change.

• Claude Code setup and accounts · Claude API billing
• Codex plans · Codex authentication
• Gemini CLI authentication · Gemini API billing

What this pack needs

The first success milestone is a reviewable research.md, brief.md, post.md, image folder and qa.json, not a published post. Traffic, search visibility and revenue are not guaranteed.

1. Extract and configure

Extract into a new folder and open it in a terminal. The following copies are for a fresh installation: compare files instead if settings already exist. Install Python, Node, zsh and your chosen CLI first.

python3 --version
node --version
zsh --version
cp .env.example .env
cp config/accounts.example.yaml config/accounts.yaml
cp config/seeds.example.yaml config/seeds.yaml
cp config/style.example.json config/style.json
export PACK_HOME="$PWD"
export OPS_HOME="$PWD"

Set PACK_HOME and OPS_HOME in .env to the actual extracted folder. Set CLOUD_ONLY=1 if you do not use Ollama. Keep only blog-a in config/accounts.yaml for the first run; set your blog_id, browser profile, daily_cap of 1 and desired slots. Put one topic in config/seeds.yaml. Configure PHOTO_DIR for photo-based blogs.

Activate your Python environment. If your ZIP includes requirements.txt, install its dependencies. Check the version's README for image and browser dependencies. Put only your own settings in .env; quote paths containing spaces.

2. Check without publishing

blog-a is the configuration key. Use an ISO date, not a word such as “tomorrow”. The first command plans; the second consumes real model usage.

RUN_DAY=$(python3 -c 'import datetime; print(datetime.date.today()+datetime.timedelta(days=1))')
DRY=1 zsh bin/run-queue.sh blog-a "$RUN_DAY"
TEST_KW="a topic I can verify personally" zsh bin/run-queue.sh blog-a "$RUN_DAY"

TEST_KW skips the runner's normal blog-save/scheduling branch. Also tell the generation assistant not to publish and keep schedulers unregistered. A successful DRY run does not prove authentication, model calls or image generation work.

3. Review the result

Open the printed drafts/blog-a/<date>-<slug>/ folder. Check text, images, facts, sources and qa.json. Do not bypass a failed gate by changing its status or substituting empty files.

zsh bin/doctor.sh
python3 bin/check.py blog-a "drafts/blog-a/actual-generated-folder"

Tool detection by doctor does not prove a successful login or publish. Inspect the run logs under data/ and the failed stage's files first.

4. Enable scheduling deliberately

Log into your Naver blog in Aside yourself and confirm the profile targets the correct blog. Manually schedule one reviewed post first; check the editor, platform schedule and eventual public RSS entry. Then follow docs/PIPELINE.md, review paths/time zones in jobs/, and register only the jobs you need. Version 1.1.0 saves local outputs by default. Browser saving/scheduling requires explicit ALLOW_PUBLISH=1. Copying every example job is not an installation check.

Distinguish scheduled from published. Confirm the platform schedule and use the public RSS entry as publication evidence. Stopping local automation does not cancel posts already scheduled on Naver.

Ask your installation assistant

Open the extracted folder in Claude Code or Codex and use this request. The assistant consumes your account's usage too. Enter secrets locally, not in chat.

Read docs/START-HERE.md and the README in this folder.
Check my OS, tools and the one cloud CLI I plan to use, including authentication.
Separate required tools, optional tools and additional charges.
Do not overwrite existing .env/config files or print secrets.
Keep schedulers, uploads, publishing and comment DMs disabled.
After checks, help me generate one local output only.
Identify unfinished adapters and failures explicitly.
Show output paths and the human review checklist. Stop before publishing.

Precautions

• Keep .env, tokens, browser profiles and private source material out of public repositories and support requests. Back up existing settings; compare new examples rather than overwriting your configuration.
• Review facts, numbers, sources and rights to images, video, music and voices. Check applicable platform and regional disclosure requirements for affiliate links. Automated review does not replace human review.
• Do not force local-only drafts out of hold by editing their status. Review and revise them through the intended approval flow.
• DRY=1 is a planning option only where the runner supports it. Generation with publishing disabled still consumes CLI/API usage and writes files. Adding an arbitrary --dry flag does not make a command safe.
• To stop automation, disable registered dagu/launchd/cron/Actions schedules, then check posts already scheduled on the platform separately. Stopping local jobs does not cancel existing platform schedules.

Troubleshooting

For support, provide the pack and ZIP version, OS, failing stage/command, expected result and last 20 error lines with secrets removed. Never send keys, cookies or your full .env. See docs/HUMAN-STEPS.md for the operating checklist and docs/PIPELINE.md for the stage reference.