product-content

Files (8)

• SKILL.md
• claude.md · intelligence/
• codex.md · intelligence/
• gemini.md · intelligence/
• ollama.md · intelligence/
• launcher.md
• rich.md · prompts/
• stack.json

SKILL.md (first lines)

# product-content

## Purpose

Author a project's **verbal language** (`CONTENT.md`) — the standing source of truth for
everything the product says to a person. It is written **off the UXD**, which is the document
that names the states its message patterns answer to, and it holds **no per-change copy** — where
that boundary falls is the prompt's § What belongs in this document.

**The peer of the design language, not a part of it.** `DESIGN.md` is the visual language and is
the CDO's; this is the verbal one. A value carried in both is a defect of whichever document
copied it.

This file is the **orchestrator** — posture, the file loop, path resolution, staging, and the
commit. **How to author** — the completeness lens, the behaviour rule, the corpus test, the
checkability bar, the terminology rule, the stability rule and the boundaries — is the authoring
prompt **`prompts/rich.md`**, applied at Step 2; a rule referenced
below by name lives there and is not restated here. The document's **section shape as stamped** is
the template **`<CORE>/templates/product-templates/content_template.md`**; the companion's shape
is **`content_open_issues_template.md`** beside it.

**Non-interactive.** The run never blocks on the owner — it derives the whole verbal language
best-effort, writes its load-bearing calls into a companion open-issues file the owner signs off on
their own time, and a re-run folds those answers in. That is what lets it run headless (as the
`content-manager` subagent) as well as in an interactive `content-manager:` session.

**There is no machine gate.** Its peer runs an external linter before committing; nothing publishes
a schema or a lint for a verbal language, so this skill has no such step and no such evidence. The
bar is carried entirely in how each rule is worded, which is the prompt's § The checkability bar —
the one place this document can fail silently, and the reason that section is not optional reading.

---

## Posture

**Content Manager role required.** If invoked outside Content Manager posture (neither a
`content-manager:` session nor the `content-manager` subagent), stop and say — *"product-content
requires Content Manager posture. Switch? (Open a session with the `content-manager:` prefix, or run
the `content-manager` subagent.)"* Do not shed the role. Where this seat ends and the CDO's begins
is a posture fact the Content Manager loader stack owns, and the split that governs *while
authoring* is the prompt's § The ground you stand on — neither is restated here.

---

## The files and the loop

product-content produces the files below under the product's `docs/` — the skill resolves the
locations (next section); a caller names the **project**, never the paths.

| File | What it is | Lifecycle |
|---|---|---|
| `<Product path>/docs/CONTENT.md` | The verbal language — best-effort complete on every run. | Permanent; one document, revised and versioned in place (the bump-on-revision rule is the template's own header note), never forked. |
| `<Product path>/docs/CONTENT_open_issues.md` | The companion, holding the calls awaiting the owner's sign-off and the few things the run could not settle, in the buckets `content_open_issues_template.md` defines — kept distinct, never blurred. Which bucket an item lands in is the prompt's. | Transient — exists only while something is unresolved. **Its absence is the done signal.** |
| `<Product path>/docs/trail/content/cycle-<N>.md` | Each answered companion, retired whole. | Permanent. |

**Cycle numbering:** `N` is one higher than the **highest** `cycle-<N>.md` already in
`trail/content/` — list the directory and take the max, so a removed or renamed cycle can't make
you collide with an existing one. The first is `cycle-1.md`; create `trail/content/` if it isn't
there. Never overwrite an existing cycle.

**The loop, repeated until clean:**

1. The run derives/updates the verbal language and writes the companion with what it couldn't
   ground.
2. The **owner answers inline** — filling the companion's answer slots, whose names and shape are
   `content_open_issues_template.md`'s, stated there and not here — and re-runs the skill.
3. The run **copies the answered companion whole to the next trail cycle**, folds the answers into
   the verbal language, and rewrites the companion with only what is still unresolved — an answer
   the fold leaves unsettled still drops, its residue re-raised as a fresh unanswered item. This is
   the ordinary cycle. A run where nothing would survive is step 4's, and step 4 alone says what it
   may touch.
4. When the answers resolve everything, the run is the close — one run that folds, copies the
   answered companion to the trail, and **removes** the companion instead of rewriting it, through
   the builder's `--rm` at Step 3, never a hand-`rm`. **No open-issues file = the verbal language
   is done.** The close has a precondition the ordinary cycle does not — the owner's answers must
   already be committed (Step 3 owns the rule and why). Re-entry is inline answers, so the first
   closing touch normally finds them uncommitted, and then it **changes nothing at all**: no fold,
   no trail copy, no rewrite, no commit; the companion survives intact, answers and all, for the
   owner to commit. It reports the state and asks for that commit; the re-run after it is the
   close, start to finish, in one run. That stop is a report with an ask, not a live interview.

Step 3 is why the trail exists. Folding rewrites the companion and the close removes it — so
without the trail the owner's answers are destroyed twice, and their reasoning for a decision
survives only in git history. The trail costs one `cp` on the same commit and makes every owner
answer permanently citable. It is the skill's job; the owner never manages it.

---

## Inputs and where the files land

- **The UXD** — your primary input; read it in full. Its location is `product-uxd`'s to name — that
  skill wrote it, and its own file table owns where the UXD lands under the product's `docs/`;
  resolve the path from `<CORE>/../skills/cdo/.claude/skills/product-uxd/SKILL.md`, never from a path remembered here.
  It must exist — if nothing is at the resolved path, halt and report, because the states that
  carry the product's words are named there and there is nothing to derive patterns from without
  them. What its content means for the derivation is the prompt's rule.
- **The product's existing strings — the corpus.** Locate and read them. What counts as the corpus,
  where it is kept, and what to do when there is none, is the prompt's § Inputs you work from. Finding nothing is a finding the prompt says how to route, never
  a halt.
- **The PRD** — beside the UXD under the product's `docs/`; its location is `product-prd`'s to
  name, resolved from `<CORE>/../skills/cpo/.claude/skills/product-prd/SKILL.md`. Read it if it is there; what it feeds
  is the prompt's. **Its absence does not halt the run** — the state reaches the owner through the
  companion like any other input gap.
- **`system/projects/<name>/agari.md`** — the project's 上がり Agari, beside the card below. Read it
  in full; what the terminus bounds is the prompt's rule. **Absence does not halt the run**, nor
  does an unfilled placeholder — the state reaches the owner through the companion.
- **`system/projects/<name>/doctrine/`** — the project's own doctrine, if the folder holds anything.
  Read what is there; what it binds is the prompt's rule. Empty or absent is silence, not a halt.
- **The product's `docs/` folder** — read it by **listing the directory**, not by recalling a set of
  filenames. Beyond the files named here and the loop files above, whatever else the folder holds is
  input the run is entitled to — brand material, a tone-of-voice note, the design language, the
  upstream trails of owner answers. What each carries, and which supersedes which, is the prompt's
  § Inputs you work from. Skip binary assets. Enumerating rather than naming is deliberate — a list
  of filenames kept here goes stale the day the product gains a document, and the run would never
  know what it had missed.
- **Context and constraints** — whatever the owner hands you, or the docs it points at.
- **`system/projects/<name>/project.md`** — the directed project's card. Its `Product path:` field
  resolves where every output lands; the field is the card template's
  (`<CORE>/templates/project_template.md`, the shape `project-stamp` stamps the card from), so

From eyalgo/kensaiapp, MIT.

More from eyalgo/kensaiapp