development-content

Files (7)

• SKILL.md
• claude.md · intelligence/
• codex.md · intelligence/
• gemini.md · intelligence/
• ollama.md · intelligence/
• launcher.md
• change_text_template.md · references/

SKILL.md (first lines)

# Development Content

## Purpose

Write the words one change publishes. The change's spec says what it does and the design says where
the words live. This skill turns those into the labels, messages and prose a person reads, to the
product's standard, and hands them to the Developer in `change_text.md` in a form the Developer can
place as written. Nothing downstream re-judges the prose, so what this skill writes is what the
person reads (`<CORE>/roles/loaders/content_editor_global.md`, opening paragraphs).

**Produces:** `change_text.md` in the change folder, from `references/change_text_template.md`.

## When to Use

- The chain's `content` step launches it, between `plan` and `implementation`, for a change whose
  `change_design.md` carries `**Publishes text:** yes — <places>`. A hand-opened change reaches it the
  same way through `ad-hoc-plan`.
- **Content Editor role only.** Run outside a `content-editor` session or subagent, this skill halts
  `wrong-posture` (§ *Halts*) before it reads any input and writes no `change_text.md`.

**Do not use for:**
- A rule every future string is held to. That is the Content Manager's standing words (`CONTENT.md`,
  the writing bar), and a rule that this change's text needs and the standard lacks goes to
  `## Findings for the Content Manager`, never into the standard.
- Deciding whether the change publishes text. The architect decides it and writes the
  `Publishes text:` line; this skill reads it and never decides it
  (`content_editor_global.md`, § *Non-responsibilities*).

## Enter the worktree

The upstream stages ran inside an isolated worktree for this change, and `change_spec.md`,
`change_design.md` and `tl_instruction.md` are on its branch, not on `main`. Derive the worktree from
the **change key** before reading anything, and work inside it for the whole run.

The **change key** is `<YYYY-MM-DD>_<slug>`, the Tobiishi folder (`journey/tobiishi/<key>/`) and the
branch name. You know it from the invocation. If several worktrees exist under `<repo>/.worktrees/`
and the intended change is ambiguous, ask which one, once.

```bash
REPO_ROOT=$(git rev-parse --show-toplevel)
WORKTREE="$REPO_ROOT/.worktrees/<key>"
test -d "$WORKTREE" || echo "No worktree for <key> — the upstream stages must run first."
```

If `$WORKTREE` does not exist, **STOP**: the upstream stages have not run for this change. Do not
create it here and do not fall back to `main`. Write the halt report where § *Halts* sends a halt
with no worktree.

**Write `$WORKTREE`'s value down, as the absolute path, before you `cd` anywhere.** A shell variable
does not survive from one command to the next, and for an external product the product worktree
carries a `.worktrees/<key>` of its own. Every `$WORKTREE` below means the instance path you wrote
down.

From here the worktree is the working root. Read every pipeline input from `$WORKTREE/`, write
`change_text.md` under `$WORKTREE/`, and commit with `git -C "$WORKTREE"`. The change arc stays on the
branch. The path comes from the key alone, by the same convention `development-design` and
`development-implementation` use, and nothing is handed between sessions.

**Locate the project.** The orchestrator passes the project name `<project>` with the key. The change
folder is `$WORKTREE/system/projects/<project>/journey/tobiishi/<key>/`.

**Resolve the product.** The step asks the path tool, every run, and never composes a product path by
hand:

```bash
python3 "<CORE>/tools/development_path.py" resolve --format json \
  --worktree "$WORKTREE" --project <project> --key <key>
```

A non-zero exit is a STOP, with the tool's `message` in the halt report. From the contract's
`product_path`, `product_repo` and `product_worktree`: `<sub>` is `product_path` when it is relative,
else `product_path` relative to `product_repo` (`.` when the same), and
`PROJECT_DOCS = <product_worktree>/<sub>/docs`, with `PROJECT_ROOT` its parent. For an in-repo
product `product_worktree` is `$WORKTREE`; for an external one it is the product worktree opened for
this change, never the product's primary checkout.

## Workflow

### Step 1 — Check the posture

Before reading any input, confirm this session is a `content-editor` session or subagent. If it is
not, halt `wrong-posture` (§ *Halts*), write no `change_text.md`, and say in one sentence what to
open: "development-content is content-editor work. Open a session or subagent as `content-editor`."

### Step 2 — Enter the worktree and resolve the product

Run § *Enter the worktree*. Record the absolute `$WORKTREE` and `PROJECT_DOCS`.

### Step 3 — Read the verdict

Read `$WORKTREE/system/projects/<project>/journey/tobiishi/<key>/change_design.md` and take the first
line that starts with `Publishes text:` once its markdown dressing is removed (the header form is
`**Publishes text:** yes — <places>`). The value's first word, with its dressing removed, is the
verdict, and it must be exactly `yes` or `no`.

| The line | This skill |
|---|---|
| `yes`, with or without places after it | Continue. The places after the word are the blocks of `## Text`. A bare `yes` names none, and Step 4 reads the design for where the words live. |
| `no` | Halt `no-text-to-write`. Write no `change_text.md`. |
| missing, `Yes`, `maybe`, empty, or no `change_design.md` | Halt `missing-text-verdict`. Write no `change_text.md`. |

**This skill never decides the verdict.** It does not read the spec to find out whether the change
"really" publishes text, and it does not turn a `no` into a `yes` or the other way
(`content_editor_global.md`, § *Non-responsibilities*: it does not decide whether the change needs a
message at all). The engine already gates on this line and launches the step only on `yes`, so a `no`
or a missing line here means the run was started by hand against a design the engine would not have
run, and the report says so.

### Step 4 — Read the inputs

Read, in this order, and nothing from `tl_instruction.md`:

1. `change_spec.md` — what the change does and for whom. Copy `Date`, `Category` and `Behaviour` from
   its header verbatim.
2. `change_design.md` — the places the words live, from the `Publishes text:` line and the design's
   own description of the states. It is the primary input
   (`content_editor_global.md`, § *Inputs you expect*).
3. `$PROJECT_DOCS/CONTENT.md` when it exists. A product with none yet is a normal case, and then the
   instance's writing bar governs alone.

From eyalgo/kensaiapp, MIT.

More from eyalgo/kensaiapp