Codex work system guide

codex-work-os

A skills-first operating system for Codex that helps turn messy, incomplete real-world work into structured outputs across sales, project management, executive support, research, and customer support.

Published by NicheWorks · View this page in Japanese

View on GitHub How to use it Support this project

Current status

Foundation, pack coverage, gates, and end-to-end examples are in place. Current state: public release candidate.

Core system

Five domain packs supported by flows, quality gates, artifacts, shared templates, install helpers, and validation scripts.

Worked scenario

pilot-rollout A cross-pack example that shows one messy operational situation moving through research, PM, executive, sales, and CS outputs.

Repository

Open on GitHub Skills, flows, gates, artifacts, docs, scripts, and examples are published in one repository.

Support future maintenance and example expansion

If this page or repository is useful, you can support future updates, additional scenarios, documentation improvements, and long-term maintenance.

💌 OFUSE ☕ Ko-fi

What it is

codex-work-os is a practical work system for Codex. It is built for situations where information arrives in fragments: Slack threads, loose meeting notes, partial research, half-formed support cases, unclear ownership, and unfinished reply drafts.

The goal is not just to make Codex “write better.” The goal is to help Codex turn unstructured work into outputs that are actually usable: a sales reply, a PM brief, an executive summary, a decision memo, or a support escalation.

This repository is not primarily a prompt pack, not a generic PM framework, and not a random business templates library. It is a Codex-native operating layer for structured work.

Who it is for

This project is a strong fit for people who want Codex to help with operational work beyond coding and who prefer reusable working structure over one-off prompting.

People who want sales, PM, research, executive, or support outputs to follow a stable shape.
Teams using Codex in real workflows where information is messy and work products need to be reusable.
Builders who want flows, gates, and output types to be explicit rather than implied.
Anyone who wants AI outputs that are easier to send, hand off, review, or act on.

It is a weaker fit if you are looking for a broad life-assistant prompt pack, a generic business advice library, or a coding-only helper repository.

The five core packs

sales-pack

For inquiry triage, proposal prep, and ready-to-send sales reply drafts.

pm-pack

For status briefs, blocker maps, weekly updates, and decision-oriented progress summaries.

exec-assist-pack

For short, high-signal briefs intended for leaders and decision-makers.

research-pack

For comparison work, decision memos, evidence summaries, and trade-off-based recommendations.

cs-pack

For support summaries, escalation notes, and clearer handoffs for the next owner.

How it is structured

codex-work-os is intentionally organized as a skills-first system. The primary unit is the domain pack under skills/, and the rest of the repository supports those packs.

Skills

The core domain packs. Each pack contains its own SKILL.md, templates, references, examples, and validation helpers.

Flows

Reusable work paths such as sales response flow, PM brief flow, research memo flow, and escalation flow.

Gates

Quality checks that protect sendability, signal quality, handoff quality, and evidence quality.

Artifacts

Reusable output shapes such as ready-to-send drafts, weekly briefs, decision memos, and escalation notes.

Shared, install, and scripts

Cross-pack references, install helpers, and validation scripts that make the repository operational instead of decorative.

There is no top-level playbooks/ directory because this repository is not built around one linear pipeline. It is built around reusable work domains.

How to use it

The easiest way to use codex-work-os is to treat it as a structured system rather than a collection of unrelated files.

Start with README.md and AGENTS.md to understand the repository’s operating model.
Read docs/architecture.md and docs/pack-mapping.md to understand how packs, flows, gates, and artifacts relate.
Open examples/end-to-end/pilot-rollout/ to see one messy situation move across multiple packs.
Choose the pack that matches your primary work type.
Apply the relevant flow, gate, and artifact when turning raw input into a final deliverable.

If you only want the quickest overview, start with the end-to-end example. If you want to use the system in real work, read the architecture and pack mapping first, then move through the worked scenario.

End-to-end example: `pilot-rollout`

The main worked scenario in this repository is pilot-rollout. It starts from a messy operational situation involving:

a prospect asking for a lightweight pilot,
an internal choice between two setup paths,
unclear PM ownership, and
a support issue involving intermittent missed alerts.

That one situation is then transformed into:

a research memo,
a PM brief,
an executive brief,
a sales reply draft, and
a CS escalation note.

This is the fastest way to understand what codex-work-os is actually trying to do: not just generate text, but reshape noisy work into reusable outputs from multiple operational angles.

Why NicheWorks publishes it

NicheWorks publishes small, practical tools and workflow assets intended to be useful in real work. codex-work-os fits that model: it is not positioned as polished theory, but as a working repository asset that can keep improving through stronger examples, better structure, and clearer operational use.

FAQ

Is this a prompt library?

No. It may contain prompt-adjacent material, but the repository is designed as a structured operational system, not a loose prompt pack.

Is this only for Codex?

The structure is built for Codex-native use, but many of the ideas can still be helpful in other agent-assisted work setups.

Why is it skills-first instead of playbook-first?

Because this repository is meant for cross-functional work that enters from different directions. The first useful question is usually “what kind of work is this?” rather than “what stage of one universal pipeline is this?”

Does it include a full example?

Yes. The pilot-rollout scenario is the main cross-pack example showing how one messy situation can move through multiple output types.

Where should I start?

Start with README.md, then AGENTS.md, then the end-to-end example under examples/end-to-end/pilot-rollout/.

Links

Open the repository Visit NicheWorks 日本語版を見る

Support this project

If this page or repository helps your workflow, you can support future maintenance, documentation updates, and additional worked examples through the links below.