feat(writing): add non-coding writer category and skills

[ilovingjny]

Summary

Refreshes #2234 against current dev by implementing the non-coding writer as category + skills instead of a standalone Scribe agent.

• Adds non-coding-writing, a built-in category for reports, proposals, official correspondence, policy documents, creative prose, and product-definition writing.
• Keeps the existing writing category focused on technical documentation and developer prose.
• Adds five built-in skills: locale-aware-writing, official-document-writing, creative-writing, law-policy-writing, and product-definition-writing.
• Updates delegation guidance so professional non-coding prose routes to non-coding-writing with the relevant writing skills.
• Updates model fallback requirements, CLI generator snapshots, schema, docs, and focused tests.

Why this fits OmO

This aligns with OmO's philosophy that users should not need to manually pick the most expensive model or provider to get high-quality work. For prose-first tasks, quality often comes from the right routing, the right prompt surface, locale-aware conventions, and a suitable fallback model chain. A dedicated non-coding-writing category lets OmO apply that same orchestration philosophy to reports, official documents, policy writing, creative prose, law-and-policy analysis, and product-definition documents.

This is not about downgrading writing tasks to cheaper models. It is about making writing tasks model-fit-aware: some prose tasks need a communicative Claude/Kimi-style model, some need GPT-style reasoning, and some can use a faster lightweight fallback. The category and skill layer lets OmO make that choice automatically instead of forcing the user to guess.

Boundary

Prometheus remains the interview/planning/specification agent. This PR does not add another planner and does not grant prose-writing tasks code-editing or shell-oriented behavior.

law-policy-writing is intentionally limited to public, analytical, institutional, or reform-oriented writing. It is not for pleadings, court filings, litigation strategy, demand letters, or client-specific legal advice.

The feature is locale-aware, not Korean-only. Korean formal documents remain a motivating use case, but the rule is to match the user's language, register, and document culture.

If this feels too broad for one PR, I am happy to keep the core non-coding-writing category plus locale-aware-writing, official-document-writing, and law-policy-writing here, then split creative-writing and product-definition-writing into follow-up PRs.

Test plan

• bun test src/model-requirements.test.ts from packages/model-core
• bun --config=/tmp/empty-bunfig.toml test src/features/builtin-skills/skills.test.ts
• bun --config=/tmp/empty-bunfig.toml test src/config/schema.test.ts src/config/schema/agent-names.test.ts
• bun --config=/tmp/empty-bunfig.toml test -u src/cli/model-fallback.test.ts
• bun --config=/tmp/empty-bunfig.toml test src/cli/model-fallback.test.ts
• bun run build:schema
• bun run typecheck
• Direct import check for DEFAULT_CATEGORIES["non-coding-writing"] and its category prompt append

Refs #2234

[github-actions]

All contributors have signed the CLA. Thank you! ✅
_{Posted by the CLA Assistant Lite bot.}

[ilovingjny]

I have read the CLA Document and I hereby sign the CLA

[cubic-dev-ai]

No issues found across 4 files

Confidence score: 5/5

• Automated review surfaced no issues in the provided summaries.
• No files require special attention.

_{Auto-approved: Purely additive change that registers a new 'scribe' agent; does not modify existing agent logic or core orchestration, ensuring no regressions to existing functionality.}

[cubic-dev-ai]

1 issue found across 1 file (changes from recent commits).

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="docs/guide/agent-model-matching.md">

<violation number="1" location="docs/guide/agent-model-matching.md:67">
P1: The documented model fallback chain for the Scribe agent does not match the actual implementation in `src/shared/model-requirements.ts`. Documentation states `Kimi K2.5 → GLM 5 → Claude Sonnet → GPT-5.2`, but the actual implementation is `Claude Sonnet → Kimi K2.5 → Gemini 3 Flash → GPT-5.2`. Update the documentation to reflect the actual implementation.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}

[code-yeongyu]

[sisyphus-bot]

PR sweep status check on dev.

• Review decision: APPROVED
• Mergeable state: CONFLICTING (merge conflict with current dev)

Approved but blocked on merge conflicts. Please rebase onto current dev and resolve. Once green, the owner can merge.

Assigning code-yeongyu for owner visibility on the merge decision.

[code-yeongyu]

[sisyphus-bot] Hi ilovingjny. 🙏 Thanks for the Scribe document-writer agent.

Picking this back up from the 5/16 approval. The PR is small (147/0 across 5 files) and shows CONFLICTING against current dev. The agent layer has been touched on dev since the PR opened.

A focused, additive new specialized agent is a relatively low-risk addition. Could you rebase against current dev and force-push? After rebase, please confirm the Scribe agent's tools + permission set doesn't overlap with Prometheus (which is already the docs-only agent per prometheus-md-only invariant); the roles need a clear distinction. Once CI is green I'll come back for a focused review.

[ilovingjny]

Thanks for picking this back up.

I agree that the important distinction is between Prometheus as a planning/spec agent and Scribe as a prose-production agent.

My intended boundary after rebasing is:

• Prometheus remains the interview/planning/specification agent. It can write/edit planning artifacts, but those writes are constrained to .omo markdown planning files by the prometheus-md-only path policy. Its output is work definition: plans, specs, questions, decomposition, and execution guidance.
• Scribe should not be another planner and should not overlap with Prometheus' project-planning role. Its role is final or near-final prose drafting/editing for non-coding documents: reports, proposals, official correspondence, policy documents, and long-form writing.
• Scribe should stay tool-conservative. It should not run bash, edit code, apply patches, or delegate tasks. If file write support remains enabled, it should be for user-facing document artifacts rather than .omo planning state or source-code changes.

I also want to refresh the implementation to match the current dev direction. Since OMO has moved further toward category + skill based delegation, I may narrow the PR so professional writing is routed through a writing/document-writing category and writing skills, while keeping scribe as an optional explicit named agent only if maintainers still prefer that shape.

One design correction from the original PR: this should be locale-aware, not Korean-only. Korean formal writing is an important motivating use case, but the general rule should be "match the user's language and document culture" so English, Chinese, Japanese, Korean, and other professional document formats can be handled consistently.

I will rebase onto current dev, resolve the conflicts, update the docs/tests, and make the Prometheus/Scribe boundary explicit in the refreshed PR.

[ilovingjny]

Refreshed this PR against current dev and force-updated the branch. I changed the implementation from a standalone Scribe agent to the current category + skill architecture:\n\n- Added non-coding-writing for reports, proposals, correspondence, policy docs, creative prose, and product-definition writing.\n- Kept writing focused on technical docs and developer prose.\n- Added built-in skills for locale-aware writing, official documents, creative writing, law/policy writing, and product-definition writing.\n- Made the Prometheus boundary explicit: this is prose production, not planning/spec orchestration.\n- Kept law-policy writing out of pleadings, court filings, litigation strategy, demand letters, and client-specific legal advice.\n\nVerified with model-core tests, builtin-skill tests, config schema tests, build:schema, typecheck, and a direct category constant import check. The feature is locale-aware rather than Korean-only, with Korean formal writing as one motivating use case.

[ilovingjny]

Follow-up update:\n\n- Updated the CLI model-fallback snapshots so the new non-coding-writing category is reflected in generated config outputs. This should remove the stale snapshot annotations from the previous successful CI run.\n- Expanded the PR body with the OmO-aligned rationale: prose quality should come from category routing, prompt surface, locale conventions, and a suitable fallback chain, not from forcing users to manually pick the most expensive model.\n- Added an explicit scope note: if the PR feels too broad, creative-writing and product-definition-writing can be split into follow-ups while keeping the core writing category and formal/locale/law-policy skills here.\n\nLocal verification added: bun --config=/tmp/empty-bunfig.toml test src/cli/model-fallback.test.ts passes after snapshot update.

[cubic-dev-ai]

1 issue found across 31 files

Confidence score: 4/5

• This PR looks safe to merge overall, with a focused, low-to-moderate risk issue rather than a broad runtime regression.
• In src/tools/delegate-task/tools.test.ts, a case-sensitive assertion does not match the actual prompt text ("Not pleadings"), so the test is likely to fail until the expected string is corrected.
• Because the issue is confined to test expectations (severity 5/10) and not a confirmed production behavior break, the merge risk stays relatively contained.
• Pay close attention to src/tools/delegate-task/tools.test.ts - fix the assertion text/casing mismatch to avoid CI/test failures.

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[ilovingjny]

@cubic-dev-ai Thanks for catching this. Fixed the case-sensitive test expectation in src/tools/delegate-task/tools.test.ts so it matches the actual prompt text (Not pleadings).

Local verification: bun --config=/tmp/empty-bunfig.toml test src/tools/delegate-task/tools.test.ts -t "non-coding-writing" passes.

[cubic-dev-ai]

@cubic-dev-ai Thanks for catching this. Fixed the case-sensitive test expectation in src/tools/delegate-task/tools.test.ts so it matches the actual prompt text (Not pleadings).

Local verification: bun --config=/tmp/empty-bunfig.toml test src/tools/delegate-task/tools.test.ts -t "non-coding-writing" passes.

@ilovingjny Looks good — matching the actual prompt text is the right call. Snapshot-driven tests like that bite you exactly when casing drifts between the source template and the expectation, and your fix keeps them in sync.

One suggestion: if the law-policy-writing skill prompt uses "Not pleadings" (title case after a period), double-check the same casing convention is consistent across the other new skill prompts (locale-aware-writing, official-document-writing, etc.) so this doesn't re-surface. But if you already verified that, we're set.

_{Tip: get faster answers by chatting with cubic’s review copilot in the review UI}

[cubic-dev-ai]

0 issues found across 1 file (changes from recent commits).

<sub>Auto-approved: This PR cleanly adds a new non-coding-writing category and five companion skills with zero modifications to existing functionality, updated documentation, and passing test coverage, so there is no risk of regression.

Re-trigger cubic</sub>