docs(blog): 말하기 에세이와 공개 리뷰 스킬 추가 - #121
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 7d09712758
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| If the user provides prose instead of a path, use the supplied prose and state | ||
| which repository checks could not be performed. | ||
|
|
||
| ## Workflow |
There was a problem hiding this comment.
Add the required ADR for this workflow
Adding this Workflow turns public-writing review into a repeatable repo process, but the commit does not add a numbered ADR or update docs/adr/README.md; the repository rule requires an ADR whenever repeated rules or boundaries are defined, so this should carry the decision context and index entry alongside the new skill.
AGENTS.md reference: AGENTS.md:L26-L35
Useful? React with 👍 / 👎.
| If the post is mainly a review of an external object, route to the existing | ||
| blog review workflow instead of forcing it into these two types. If it is a | ||
| technical document with reader instructions as its main goal, route to the | ||
| technical-writing skill. |
There was a problem hiding this comment.
Point technical-doc routing at an existing skill
This branch tells reviewers to route technical documents to a technical-writing skill, but repo-wide search (rg --hidden "technical-writing|tech-writing") only finds this new reference and .agents/skills contains only the three blog skills. When a technical post hits this branch, the reviewer has no callable destination, so the workflow stalls; either add that skill or name an existing documented path.
Useful? React with 👍 / 👎.
| If the target is an Ark Tech post and `qualityReview` is present, report the | ||
| existing core score fields (`philosophy`, `design`, `implementation`) without | ||
| inventing scores. The public policy threshold is a repository rule, not a | ||
| substitute for editorial judgment. |
There was a problem hiding this comment.
Treat missing Tech review scores as a release blocker
This only tells the reviewer to report the Tech core scores when qualityReview is present, but the publication policy in docs/blog-quality-guide.md requires engineering posts to clear the philosophy, design, and implementation average before public release. For a private Tech draft with no qualityReview, this release-readiness workflow can return publish without ever marking the missing scores as verify or block, so the Tech policy check should run even when the scores are absent.
Useful? React with 👍 / 👎.
변경 내용
말을 잘하고 싶다.로 정리하고 문단 흐름 개선의도
private유지영향 범위
검증
npm run content:auditnpm run lintnpm run build