DEV Community: Vladislav Guzey

Codex Skill with a Clear Job

Vladislav Guzey — Sun, 20 Sep 2026 13:40:55 +0000

Vladislav Guzey

Sep 20

Build a Small Codex Skill with a Clear Job

#ai #openai #coding #tutorial

6 min read

Build a Small Codex Skill with a Clear Job

Vladislav Guzey — Sun, 20 Sep 2026 13:40:08 +0000

A skill description helps Codex decide when to use that skill. If an invoice skill says it handles “business, money, customers, and documents,” it could match many requests that have nothing to do with invoices.

Let's build a smaller example: a skill that creates Markdown invoice drafts from supplied billing data. It will have a clear trigger, a short set of rules, and practice data with totals we can check by hand.

This follows the skill advice in OpenAI's GPT-6 Astra guide. The example creates a local draft. It does not need a payment service, a PDF tool, or access to real customer records.

1. Define one job

The skill's job is to create or update a Markdown invoice draft.

It needs supplied billing details. It should preserve those details, calculate line totals, report missing fields, and save the result in a requested local folder.

Compare these descriptions:

description: Help with business, money, customers, and documents.

description: Create or revise Markdown invoice drafts from supplied billing data.

The second description gives Codex a useful reason to choose the skill. A request to summarize a customer meeting is outside that job.

OpenAI's skills documentation explains that Codex starts with skill names and descriptions. It reads the full SKILL.md when it selects a skill. Put the actual job near the start of the description.

2. Create the folder

For a repository skill, create this structure:

.agents/skills/invoice-draft/
  SKILL.md
  references/
    invoice-fields.md
  examples/
    demo-billing.md

SKILL.md explains the workflow. The reference holds field and calculation rules. The example file provides practice input; ordinary invoice tasks do not need to read it.

The documented local skill locations include .agents/skills/ in a repository and ~/.agents/skills/ for personal skills. This tutorial uses the repository location.

3. Write SKILL.md

Save the following in .agents/skills/invoice-draft/SKILL.md:

---
name: invoice-draft
description: "Create or revise Markdown invoice drafts from supplied billing data."
---

# Prepare an invoice draft

Read references/invoice-fields.md for required fields and
calculation rules.

Use the billing source named by the user. Read files in examples/
only when the user asks for a practice run using those files.

Preserve supplied names, dates, rates, currency, and payment details.
Use decimal arithmetic or integer minor units for money calculations.

If required data is missing, list it under "Missing information"
and keep the output marked as an incomplete draft.

Save a Markdown file in the requested local output folder.
Check the saved file against the input and calculation rules.

Finish by giving the file path, the checks performed, and any
missing information. Do not send or publish the invoice.

“Integer minor units” means doing a calculation in cents for a currency such as USD. For example, USD 45.00 becomes 4,500 cents. This helps avoid small rounding errors from some number formats.

The skill names a result and its checks. It leaves Codex free to choose how to read the source and create the Markdown file.

4. Add the field rules

Save this in references/invoice-fields.md:

# Invoice draft rules

## Required input

- Invoice number.
- Issue date and due date in YYYY-MM-DD form.
- Supplier and customer names.
- Currency.
- At least one item with a description, quantity, and unit price.
- A tax amount supplied by the user, including an explicit zero.
- Payment instructions supplied by the user.

## Checks

- Dates must be valid calendar dates.
- The due date must not be earlier than the issue date.
- Each quantity must be a positive whole number for this workflow.
- Each unit price and tax amount must be zero or greater.
- Use one currency per invoice. Report mixed currencies.
- Line total = quantity multiplied by unit price.
- Subtotal = sum of line totals.
- Invoice total = subtotal plus the supplied tax amount.
- Do not guess a missing tax amount or payment instruction.

## Output

Include an invoice heading, the supplied details, an item table,
the subtotal, tax amount, total, and payment instructions.

Label every output "Draft for review".
List missing fields or invalid values under "Missing information".
Do not report a complete invoice total while a needed value is missing.

These are rules for this small practice workflow. A real business may need more fields or different calculation rules. Add those from the business's approved requirements before using the skill for real work.

The tax amount is an input here. The skill is not being asked to decide which tax rules apply.

5. Add practice data

Save this in examples/demo-billing.md:

Fictional billing data for a practice run

Invoice number: DEMO-001
Issue date: 2026-09-20
Due date: 2026-10-04
Supplier: Example Studio
Customer: Sample Company
Currency: USD
Tax amount: 0.00
Payment instructions: Practice invoice only. Do not make a payment.

Item	Quantity	Unit price
Form layout review	2	45.00
Written feedback	1	30.00

The expected calculations are:

Form layout review: 2 × USD 45.00 = USD 90.00.
Written feedback: 1 × USD 30.00 = USD 30.00.
Subtotal: USD 120.00.
Supplied tax amount: USD 0.00.
Invoice total: USD 120.00.

These numbers are expected results for the example. They let you check the output without asking another model to judge it.

6. Run the skill explicitly

In Codex CLI, use the skill name in your prompt:

$invoice-draft

Use .agents/skills/invoice-draft/examples/demo-billing.md
to create output/invoice-demo-001.md.

Check the saved file and its calculations before finishing.
This is a practice run with fictional data.

OpenAI documents $ mentions and the /skills command for selecting skills in the CLI. If a new skill does not appear, check the file name and metadata, then restart Codex if needed.

Open the result. Confirm that it contains the supplied names and dates, both items, and a total of USD 120.00. The file should remain marked “Draft for review.”

Also check that the final response points to the saved file. A correct invoice shown only in the chat would not meet the request to save it.

7. Check when Codex chooses the skill

Explicit use checks whether the workflow works. You should also try requests without mentioning the skill name.

Request	Intended match
Create a Markdown invoice from this billing file.	Use the skill.
Update the quantity on this invoice draft.	Use the skill.
Summarize notes from a customer meeting.	Do not choose it just because a customer is mentioned.
Build a React app for editing invoices.	Treat this as a software task; this draft-writing skill does not cover the whole job.

Inspect what Codex selects. If the skill matches unrelated work, improve its description. If it misses a valid request, make the intended use clearer.

Then test missing information. Copy the practice data to a new file and remove the currency or tax amount. The expected output should name the missing field and remain incomplete. It should not silently fill in a value.

Keep the skill small as it grows

This skill has one output format. If you later support PDFs, add the tools and checks that PDF creation needs. Make it clear when that extra guidance should be read.

OpenAI calls this approach progressive disclosure: load detailed instructions when they apply. For example, Markdown work should not require reading a long PDF export guide.

You can also keep a very short skill in one file. The separate reference here shows how to keep reusable field rules in a named place. Create another file only when its contents have a clear purpose.

Before sharing a revised skill, run the normal example, the missing-data example, and a request that should not match. Those three checks cover different ways the skill could fail.

Video and sources

My video tutorial covers seven related improvements for prompts, skills, and AGENTS.md. The full website article includes the broader instruction-audit prompt.

Codex Agents: The New Multi-Agent Dashboard Explained

Vladislav Guzey — Sat, 22 Aug 2026 04:09:47 +0000

Vladislav Guzey

Aug 22

Manage Multiple OpenAI Codex CLI Tasks with codex agents and codex queue

#ai #openai #agents #programming

2 min read

Manage Multiple OpenAI Codex CLI Tasks with codex agents and codex queue

Vladislav Guzey — Sat, 22 Aug 2026 04:09:18 +0000

🎥 Watch the demo: OpenAI Codex Agents Dashboard and codex queue

Running several Codex CLI tasks at once can turn your terminal tabs into a confusing task manager.

Codex now provides two commands that solve different parts of this problem:

codex agents shows your local tasks in one dashboard.
codex queue sends a new message to an existing task.

Here is how to use them together.

Requirements

Check your Codex version:

codex --version

Update when necessary:

codex update

For an npm installation:

npm install -g @openai/codex@latest

Open the dashboard

Run this in your normal terminal:

codex agents

The dashboard groups tasks by project and reports three states:

State	Meaning
Need input	The task is blocked on your answer or approval
Working	The task is still running
Ready	The current work is ready to review

Inside a Codex session, return to the dashboard with:

/agents

Remember:

shell:        codex agents
inside Codex: /agents

Rename important tasks

Unique names are easier to search and target:

frontend-accessibility
backend-rate-limits
docs-release-notes

Select a task and press Ctrl+R, or rename it from the session:

/rename backend-rate-limits

Queue a message by name

The syntax is:

codex queue --thread <NAME_OR_UUID> --message <TEXT>

Example:

codex queue \
  --thread "backend-rate-limits" \
  --message "Add a regression test for concurrent requests."

Use the full exact task name and quote both values.

Queue a message by session ID

Open the task and run:

/status

Copy the Session UUID:

01a01234-abcd-7890-1234-123456789abc

Then target it directly:

codex queue \
  --thread "01a01234-abcd-7890-1234-123456789abc" \
  --message "Run the full test suite before finishing."

Names are convenient for manual use. UUIDs are better for scripts and duplicated task names.

Attach an image

You can include a visual reference:

codex queue \
  --thread "frontend-accessibility" \
  --message "Match the mobile header to this screenshot." \
  --image "/path/to/header-reference.png"

Useful dashboard controls

Up / Down: navigate tasks
Enter: open a task
Ctrl+F: search
Ctrl+S: change grouping
Ctrl+R: rename
Ctrl+X: stop

Check the footer in your installed version because shortcuts may change.

Troubleshooting

The command is not available

Update Codex and open a new terminal:

codex update
codex --version

The task cannot be found

Use the exact quoted name or copy the UUID from /status.

The dashboard is empty

Check the installation, authentication, app-server connection, and thread inventory:

codex doctor

The message does not appear immediately

A busy task may process the queued instruction after its current work reaches a safe point. Open it from the dashboard and inspect the transcript.

Recommended workflow

codex agents
  → rename important tasks
  → handle Need input
  → review Ready tasks
  → queue quick follow-ups
  → use UUIDs in scripts

That is the complete pattern: use the dashboard for visibility and codex queue for delivery.

For the full live walkthrough, watch the video tutorial on YouTube.

DeepSeek Harness Tutorial: Run Your First Coding Agent with DeepSeek V4

Vladislav Guzey — Sun, 16 Aug 2026 15:21:18 +0000

DeepSeek Harness is an open-source agent runtime from DeepSeek.

It is not a model. It is the application that connects a model to your project files, terminal, tools, permissions, and session history.

We will use the DeepSeek cloud API. You do not need Ollama, a local model, or a powerful GPU.

DeepSeek Harness is currently a developer preview. Commands and settings may change between versions.

What Runs Locally?

This tutorial uses the following setup:

Your computer:

DeepSeek Harness
Browser interface
Source code
Terminal commands
File changes

DeepSeek cloud:

DeepSeek V4 model

The Web UI is local, but repository context may be sent to the DeepSeek API when the model needs it.

Do not use a confidential repository for your first test.

Requirements

You need:

Git
Node.js 22.19 or later
npm and npx
A DeepSeek API key
API balance
A browser

The current repository supports Node.js ^22.19.0 or Node.js 24+.

Check your versions:

node --version
npm --version
npx --version
git --version

For a new installation, Node.js 24 is a good choice.

With NVM:

nvm install 24
nvm use 24
nvm alias default 24

Create a Demo Project

Create a disposable project:

mkdir deepseek-harness-demo
cd deepseek-harness-demo
git init

Create calculator.js:

export function multiply(a, b) {
  return a + b;
}

The function contains a bug. It adds the numbers instead of multiplying them.

Create calculator.test.js:

import test from "node:test";
import assert from "node:assert/strict";
import { multiply } from "./calculator.js";

test("multiply returns the product of two numbers", () => {
  assert.equal(multiply(3, 4), 12);
});

Create package.json:

{
  "name": "deepseek-harness-demo",
  "private": true,
  "type": "module",
  "scripts": {
    "test": "node --test"
  }
}

Run the test:

npm test

It should fail.

Commit the initial state:

git add .
git commit -m "Add calculator with intentional bug"

A Git commit makes it easy to inspect and undo the agent's changes.

Start DeepSeek Harness

Remain inside the project folder and run:

npx @deepseek-ai/dsh web

The current official README uses this as the main Web UI command. The server normally starts on port 3080.

Open:

http://127.0.0.1:3080

Keep the terminal process running.

When port 3080 is unavailable, choose another port:

npx @deepseek-ai/dsh web --port 3081

Then open:

http://127.0.0.1:3081

Add Your DeepSeek API Key

Inside the Web UI:

Open Settings
Open Models
Find the DeepSeek provider
Paste your API key
Save

The built-in DeepSeek configuration does not require you to manually add a custom base URL.

Harness stores the key through its local credential system. The settings keep a credential reference, while the browser receives a redacted description instead of the saved secret.

Do not show this screen while recording a video.

Select a Model

Return to the main interface and choose:

DeepSeek-V4-Flash

DeepSeek-V4-Flash

deepseek-v4-flash

The official DeepSeek adapter currently advertises V4 Flash and V4 Pro by default.

Start with Flash. Use Pro later for more difficult tasks.

Create a new session after changing models. Existing sessions keep the model recorded in their own history.

Choose the Workspace

Click Choose workspace and select the demo project.

Run this command when you need the full path:

pwd

A new Harness Web UI does not enable the message composer until you select a workspace.

Select Safe Permissions

Choose the permission preset that uses:

workspace-write

and asks before sensitive operations.

Avoid this preset during your first run:

danger-full-access

The default workspace-write preset combines workspace confinement with an approval policy of ask. The default danger-full-access preset combines broad access with never.

Use a disposable project even with the safer option.

Give the Agent a Clear Task

Paste this prompt:

Inspect this repository.

Run the tests using:

npm test

Find the root cause of the failing test and fix it.

Requirements:
- Do not install packages.
- Do not access files outside this workspace.
- Make only the smallest necessary change.
- Run the tests again after changing the code.
- Inspect the final Git diff.
- Do not claim success unless all tests pass.
- Summarize exactly what you changed.

The expected workflow is:

Read the source file
Read the test
Run npm test
Find the incorrect + operator
Replace it with *
Run the test again
Inspect the Git diff
Return a summary

Approve only actions that you understand.

Verify the Result

Do not trust the agent's final message without checking it.

Run:

npm test

Then inspect the code change:

git diff

The expected diff is:

 export function multiply(a, b) {
-  return a + b;
+  return a * b;
 }

Check the repository status:

git status

Only the intended file should be changed.

How the Agent Loop Works

One model response is usually not enough for a coding task.

Harness may run several steps:

User prompt
    ↓
Model request
    ↓
Tool call
    ↓
Permission check
    ↓
Local tool execution
    ↓
Tool result
    ↓
Another model request
    ↓
Final response

A step includes one model request and the tools called from that request. A turn can contain several steps.

The durable session log can store user messages, assistant output, tool calls, tool results, and execution boundaries. Harness reconstructs model history from this event stream.

This supports:

Session resume
Replay
Forking
Transcripts
Debugging
Persistence

It also helps you understand why the agent made a particular decision.

What to Try Next

After the small demo works, test a real but non-sensitive repository.

A useful prompt is:

Before changing files:
1. Read the relevant documentation.
2. Run the existing tests.
3. Explain the root cause.
4. Propose the smallest fix.

After I approve:
1. Apply the change.
2. Run the relevant tests.
3. Inspect the final diff.
4. Report remaining risks.

Learn more about DeepSeek Harness on my website: https://proflead.dev/

How to Prepare for the Next OpenAI Codex Ambassador Cohort

Vladislav Guzey — Sat, 01 Aug 2026 15:34:31 +0000

I am Vladislav Guzey (proflead), an OpenAI Codex Ambassador in Chiang Mai, Thailand.

If you are interested in a future Codex Ambassador cohort, the best preparation is not writing a perfect application. It is doing useful work for developers before the form opens.

This guide explains the role, the current program status, and a practical preparation plan you can start now.

Status checked August 1, 2026: applications are paused while OpenAI supports the current cohort. OpenAI plans to open another cohort, but it has not announced a date. Use the official Codex Ambassadors page as the source of truth.

What is a Codex Ambassador?

The OpenAI Codex Ambassador Program is a global community program. It brings together people who help developers learn and build with Codex.

The program is relevant to:

Developer meetup organizers
Open-source maintainers and contributors
Student community leaders
Workshop teachers
Codex power users who support other builders

You do not need to be a full-time content creator or have a large audience. A useful GitHub project, a clear tutorial, or a small hands-on workshop can show meaningful community impact.

The ambassador role as a simple loop

I think about the work as a four-step loop:

Listen to builders
      ↓
Create an event or resource
      ↓
Help people use it
      ↓
Share lessons and feedback
      ↺

Each part improves the next one.

1. Listen to builders

Find out what people actually need. New developers may need installation help. Experienced engineers may want code review, testing, migration, or automation examples. Open-source maintainers may care about issue triage and contributor workflows.

Do not choose an event topic only because it sounds impressive. Choose it because it removes a real obstacle.

2. Create something practical

Ambassador contributions may include:

Meetups and workshops
Hackathons or build days
Tutorials and videos
Open-source repositories
Codex skills and agents
Prompt and workflow examples
Event notes and learning materials

Reusable resources are especially useful. A workshop helps the people in the room. A public repository or guide can also help the next group.

3. Support people while they build

A good technical event should include time for participants to use the tool. A 60-minute talk with no practice may be interesting, but it does not show whether people can apply the ideas.

For a beginner workshop, I like a structure similar to this:

10 min  — explain the task and expected result
15 min  — demonstrate one complete workflow
30 min  — participants build with support
15 min  — demos, questions, and feedback

The exact timing can change. The important point is to give builders enough time to try, fail safely, ask questions, and continue.

4. Share honest feedback

Ambassadors can report what developers find useful, confusing, or difficult. This feedback gives the Codex team context from different cities, countries, skill levels, and working environments.

Useful feedback is specific. “People liked it” is less helpful than “five beginners could not understand where project instructions should live, so we added a short setup exercise.”

What support is listed?

OpenAI currently describes support including:

Codex and API credits for ambassador activities and events
Adaptable starter kits
Collaboration with ambassadors and the Codex team
Invitations to selected future events
Exclusive swag

Support can change between cohorts. Verify the exact details when a new application round opens.

What is the time commitment?

The current expectation is about two to four hours per week and at least one contribution each month.

Treat this as regular community work, not a single application task. Some weeks may be quiet. Event weeks may require more preparation.

Before applying, ask:

Can I contribute consistently?
Do I have a community or audience I understand?
Can I complete at least one realistic activity each month?
Can I listen to feedback instead of only promoting my own ideas?

A five-part preparation plan

The following is my personal advice, not an official OpenAI checklist.

Step 1: Build with Codex

Use Codex on something real: a personal project, work task, open-source issue, workshop example, or automation.

Keep a small record:

## Project
What did I build or change?

## Workflow
How did I use Codex?

## Result
What worked?

## Lesson
What would I teach another developer?

Three strong examples are enough to begin.

Step 2: Publish one reusable resource

Choose a problem you understand and create one resource that solves it. This could be a short DEV post, GitHub example, video, Codex skill, or workshop worksheet.

Make it easy to verify:

State the goal.
List requirements.
Show the workflow.
Explain common mistakes.
Include the final result.

Step 3: Help a small group

You do not need to begin with a conference. Invite a local developer group, student club, online community, or several colleagues.

Run a small session and collect questions. Those questions often reveal what your next tutorial should explain.

Step 4: Define your local focus

Write one sentence in this format:

I help [specific group] use Codex for [specific need] through [realistic activity].

For example:

I help university students in Chiang Mai learn practical coding-agent workflows through monthly beginner workshops.

This is clearer than “I want to grow AI worldwide.”

Step 5: Propose one first-month contribution

Keep it small enough to complete:

audience: 20 local developers
format: 90-minute hands-on workshop
topic: using Codex to understand and improve an existing repository
result: each participant completes one reviewed change
follow_up: publish notes and example files

Specific plans are easier to understand and deliver.

What I learned from an event in Thailand

On July 18, 2026, I hosted an OpenAI Build Week community meetup in Chiang Mai. Developers, founders, students, and AI-curious creators explored Codex across the app, CLI, IDE, and cloud.

My main lesson was simple: different experience levels can work well in one room when the activity has a clear goal and people are encouraged to help one another.

If you are in Thailand, follow my Codex events and resources page for future meetups, workshops, hackathons, recaps, and tutorials. You can also see my official OpenAI Ambassador profile.

Frequently asked questions

Do I need previous event experience?

Existing community experience is useful, but professional event experience is not required. Builders who are ready to start bringing people together locally may also be a fit.

Can several people apply from one city?

Yes. The program is about supporting a community, not reserving a city for one person.

Do I need to be an expert programmer?

OpenAI does not list a required degree, job title, or fixed number of coding years. Practical Codex experience and the ability to help builders are more relevant.

When will applications reopen?

No reopening date has been announced. Check the official program page instead of relying on an old application link.

Resources

The application form may be paused, but your preparation can start today: build something real, document the workflow, help a small group, and listen carefully to what developers need.

OpenAI Codex Subagents Tutorial for Beginners

Vladislav Guzey — Thu, 02 Jul 2026 14:41:53 +0000

Hey devs! When you use Codex, putting too many tasks into a single conversation makes the model slow, confused, and unreliable. To solve this problem, I highly recommend using subagents (or Custom Agents).

Think of it like this: instead of forcing one agent to do everything, you act as the manager running a team. You can have one subagent write front-end code, another write back-end code, and another review the code-all working in parallel at the exact same time. And this is what we cover in today’s article ;).

What Are Codex Subagents?

A subagent is a separate Codex agent thread that the parent Codex session can spawn for a focused task. Subagents are useful when a job can be split into independent or specialized work: code review, security audit, documentation research, frontend debugging, test generation, or implementation planning.

Codex includes built-in agents such as **default**, **worker**, and **explorer**.

The Built-in Agents I Use

Codex already comes with a few basic agents built right in:

Default Agent: This is your general fallback agent.
Worker Agent: Focuses strictly on implementation and bug fixes.
Explorer Agent: Best for reading, searching, and understanding your existing codebase.

You can also define custom agents as TOML files. Each custom agent has its own name, description, instructions, and optional model, reasoning, sandbox, MCP, and skill settings.

Subagents are not spawned automatically just because files exist. In normal use, ask Codex explicitly:

Spawn security_auditor to review this authentication change for OWASP risks.  
Spawn python_expert to refactor this module with type hints and pytest tests.  
Spawn orchestrator to plan this full-stack feature and recommend specialist handoffs.

Why I Use subagents (And Why You Should Too)

Using sub-agents gives you three massive advantages:

No Context Overload: Even large context window LLMs have limits. Sub-agents keep your chat clean because each agent only looks at its specific task.
Speed: Because multiple agents work in parallel, your tasks get done much faster.
Specialization: Different tasks need different thinking. With sub-agents, you can assign different models, unique instructions, and specific tools to each job.

Where Custom Agents Live

Codex supports two common install locations:

For public libraries and team repos, use project-scoped agents so they clone with the repository:

.codex/  
  config.toml  
  agents/  
    python_expert.toml  
    security_auditor.toml  
    orchestrator.toml

Dot directories are hidden in many file explorers. If you do not see .codex, use:

ls -la  
ls -la .codex/agents

How to Set Up Your Custom Sub-agents

When you find yourself repeating the same workflow many times, it’s time to build a Custom Agent. You can set these up directly inside your terminal, VS Code, or whatever IDE you prefer.

Step 1: Create the Folder Structure

Go to your project folder and create a directory structure that looks exactly like this:

your-project/  
│  
└── .codex/  
    ├── config.toml  
    └── agents/  
        ├── backend_developer.toml  
        └── code_reviewer.toml

(Tip: If you want these agents to be accessible across your entire computer for all projects, place them in your home directory at _~/.codex/agents/_ instead).

Step 2: Configure Global Settings (`config.toml`)

Open your config.toml file to set up the global boundaries for your team. Here is the configuration I recommend:

[agents]  
max_threads = 6  
max_depth = 1

max_threads controls how many agent threads can be open concurrently. max_depth = 1 is a good default because it allows direct child agents but prevents recursive fan-out that can become expensive and hard to reason about.

Step 3: Write Your Custom Agent Files

Inside your .codex/agents/ folder, create files using readable, clear names. We will use these exact file names to call the agents in our prompts later.

Important fields explained

name

The identifier Codex uses when spawning the agent. Keep it stable and easy to type. This library uses lowercase underscore_case:

python_expert  
security_auditor  
frontend_developer

description

Tells humans and Codex when this agent should be used. Make it specific. A weak description says:

Helps with code.

A stronger description says:

Use when you need read-only pull request review focused on correctness,

regressions, security risks, and missing tests.

developer_instructions

The agent’s core behavior. Include:

Role and specialty.
What to prioritize, and what to avoid.
How to report results.
Whether it should edit files or stay read-only.
How it should handle missing context or validation.

model & model_reasoning_effort

Use stronger models and higher reasoning for review, security, architecture, orchestration, and difficult debugging. Use smaller or faster models for routine implementation, documentation, and focused exploration. If you omit model fields, the agent inherits the parent Codex session settings.

sandbox_mode

Use read-only for agents that inspect and report without changing files; use workspace-write for agents that implement code or documentation changes.

sandbox_mode = "read-only"

sandbox_mode = "workspace-write"

Subagents still inherit the parent session’s approval policy and live runtime overrides, so the parent session remains the final control point.

nickname_candidates

Display labels for spawned agent threads. They do not change the real agent's name. Use simple ASCII names with letters, digits, spaces, hyphens, or underscores.

nickname_candidates = ["Atlas", "Delta", "Echo"]

Example 1: **security_auditor.toml** Open the file and define the properties. The most important parts to include are the name, description, and developer instructions:

name = "security_auditor"  
description = "Use when you need read-only security review, OWASP risk analysis, dependency risk triage, or credential-handling review."  
model = "gpt-5.4"  
model_reasoning_effort = "high"  
sandbox_mode = "read-only"  
nickname_candidates = ["Security Auditor"]  
developer_instructions = """  
You are the Codex custom subagent `security_auditor`.  

Review code like a security owner. Stay read-only. Prioritize exploitable vulnerabilities, auth and access-control flaws, injection risks, data exposure, insecure secrets handling, and dependency risk.  

Lead with concrete findings ordered by severity. Include affected files or symbols, impact, and remediation. Avoid style-only comments.  
"""

Example 2: **python_expert.toml**

name = "python_expert"  
description = "Use when you need modern Python implementation, refactoring, type hints, pytest tests, or framework-specific Python guidance."  
developer_instructions = """  
You are the Codex custom subagent `python_expert`.  

Focus on modern Python. Prefer type hints, explicit error handling, pathlib, small functions, and pytest coverage. Follow the parent Codex session's repository instructions and approval policy.  

When editing code, keep changes scoped to the Python task. When you cannot run validation, state the exact command the parent should run.  
"""

My Pro-Tip on Budgeting: If you are on a pay-as-you-go plan, defining the _model_ property is incredibly useful. You can set up a cheaper model for low-effort tasks and save expensive, high-reasoning models for complex tasks!

Shortcut: The Codex Agents Library

If you don’t want to create these from scratch, you don’t have to. I have a library containing around 36 different pre-made agents. You can simply download a file-like the front_end_developer agent-and drop it straight into your project's agents folder using VS Code.

Codex Agents Library: https://github.com/proflead/codex-agents-library

How to Run Subagents in the Terminal

Now that everything is configured, let’s launch Codex and look at how to control your new team.

1. Calling a Single Agent

To spawn a custom agent, you must explicitly call it by its name inside your prompt:

Spawn code_reviewer to review this branch against main for correctness,   
regressions, and missing tests. Report findings only.

Codex will analyze your folder, find the front-end agent, and successfully assign the task to it.

2. Running Agents in Parallel

Because we allowed up to 6 concurrent threads in our config, you can call multiple agents at once to handle separate tasks simultaneously:

Review this PR with parallel subagents. Spawn code_reviewer for correctness,   
security_auditor for exploitable risks, test_generator for coverage gaps,   
and performance_optimizer for latency or memory issues. Wait for all results   
and summarize findings by severity.

You will see both agents trigger and start working side-by-side in real-time.

3. Managing the Session

Check Status: Type the **/agent** command in your session terminal. This lists every active sub-agent currently running.
Granular Control: You can actually step inside the thread of a single active agent to give it specific, isolated instructions without confusing the other agents.

Watch out for Git Branches: By default, sub-agents do not create separate working branches; they will dump all changes straight onto your _main_ branch. If you want to keep things clean, explicitly tell them in your prompt: "create a separate branch before you start the job."

5 Critical Mistakes I Want You to Avoid

As you start experimenting with sub-agents, please keep these five classic beginner traps in mind:

Using Agents Without a Clear Plan: If you just say “use sub-agents to fix my app,” your manager agent has to guess too much. Be highly specific about who does what.
Spawning Too Many Agents: More agents do not mean better output. Spawning too many just increases your API costs, adds background noise, and creates general confusion.
Letting Multiple Agents Edit Related Files at the Same Time: This is a major trap. It can create semantic conflicts-meaning your code breaks logically even if Git doesn’t show a traditional merge conflict.
Trusting AI-Generated Tests Too Much: AI-written tests sometimes test the implementation rather than the behavior. Always review the tests yourself.
Giving Agents Early Access to Sensitive Areas: Never let a sub-agent handle production secrets, deployment scripts, database migrations, or infrastructure changes without a human reviewing it first.

At the end of the day, subagents are incredibly powerful tools to speed up your development, but you are still completely responsible for the final code!

Codex Subagents: Video Tutorial

Watch my full step-by-step tutorial about Codex agents on YouTube:

Watch on YouTube: Codex Subagents

Cheers, proflead! ;)

Codex /goal is the Most Powerful AI Coding Feature You're Not Using

Vladislav Guzey — Wed, 20 May 2026 12:37:26 +0000

Vladislav Guzey

May 20

OpenAI Codex /goal: Your Code Ships Itself While You Sleep

#openai #ai #vibecoding #coding

4 min read

OpenAI Codex /goal: Your Code Ships Itself While You Sleep

Vladislav Guzey — Wed, 20 May 2026 12:36:51 +0000

AI coding assistants are becoming better every day. But most still work one prompt at a time. You ask something, get an answer, and then guide the next step manually.

The new /goal command in OpenAI Codex changes this workflow.

Instead of asking for isolated answers, you can give Codex a long-term objective with clear success conditions. Codex can investigate, write code, run tests, and continue working toward the result over multiple steps.

In this guide, you’ll learn:

What /goal does
How it works
How to enable it
Real examples
Best practices
Common mistakes

What Is the `/goal` Command in Codex?

The /goal command lets you define a persistent objective for Codex.

Instead of treating every message as a separate request, Codex keeps working toward the same result until:

The goal is completed
You pause it
You clear it
It gets blocked
Resource limits are reached

Think of it like giving an AI developer a task and letting it continue working without repeating instructions.

How the Goal Lifecycle Works

Goals usually follow a simple workflow.

Step 1: Define the objective

You tell Codex what should happen.

Example:

/goal Reduce dashboard page load time below 2 seconds

Step 2: Codex investigates and plans

Codex may:

Read files
Analyze code
Check dependencies
Search for issues
Plan next actions

Step 3: Execute and verify

Codex can:

Write code
Run tests
Refactor functions
Validate changes

Step 4: Complete or pause

Once conditions are met, the goal can be finished.

You can also pause and resume work later.

Codex /goal example

When to Use `/goal`

Goals work best for tasks that require multiple steps.

Good use cases:

Performance optimization

/goal Reduce homepage loading time

Constraints:

Keep existing UI
Keep Lighthouse score above 90
Target loading under 2 seconds

Finding difficult bugs

/goal Investigate memory leaks in analytics.ts

Constraints:

Keep existing architecture
Add tests if needed
Clearly label uncertain findings

Writing test coverage

/goal Create unit tests for auth.ts

Constraints:

Reach at least 90% coverage
Do not modify business logic

Large refactoring work

/goal Refactor payment module

Constraints:

Preserve API behavior
Keep tests passing
Improve readability

When NOT to Use `/goal`

Goals are not the right tool for every task.

Avoid using /goal for:

One-line edits
Quick explanations
Small bug fixes
Short code reviews
Questions with one answer

Bad example:

/goal Make this code better

Why this is bad:

“Better” has no clear finish line.

Codex may continue making changes without knowing when to stop.

Better version:

/goal Refactor user-service.ts

Constraints:

Keep API unchanged
Improve readability
Keep tests passing

How to Enable `/goal` in Codex

Update Codex:

npm install -g @openai/codex@latest

Verify installation:

codex --version

Some Codex versions may require enabling goal-related features. In order to do that find the config.toml file and add this line:

[features]

goals = true

Goal Commands

Create a goal:

/goal Finish dashboard migration

Check current goal:

/goal

Pause:

/goal pause

Resume:

/goal resume

Clear:

/goal clear

Good vs Bad Goal Prompts

Bad

/goal Refactor this code and make it better

Problems:

No measurable result
No constraints
No finish line

Good

/goal Optimize database queries in db.ts

Constraints:

Keep schema unchanged
Cover all execution paths with tests
Target execution time below 50ms

Why it works:

Clear objective
Defined limits
Measurable result

Permission and Safety Tips

Codex may ask for confirmation before actions that can change files or execute commands.

Before running long autonomous tasks:

Keep Git clean

Create a new branch:

git checkout -b codex-experiment

Commit before running goals

git add .

git commit -m "Clean starting point"

Avoid sensitive environments

Do not run autonomous tasks:

On production systems
With exposed secrets
On important system folders

Best Practices

Define a clear finish line

Bad:

/goal Improve performance

Better:

/goal Reduce API response time below 150ms

Define constraints

Tell Codex what should not change.

Examples:

Keep API unchanged
Keep tests passing
Do not change database schema

Do not hide uncertainty

If data may be unavailable:

If metrics cannot be collected, label results as estimated.

Use measurable targets

Examples:

Response time under 100ms
95% test coverage
Lighthouse score above 90

Video Tutorial

Watch on YouTube: Codex /goal explained

Conclusion

The /goal command changes Codex from a prompt-response tool into a longer-running coding workflow.

Instead of repeating instructions every few minutes, you give Codex a clear objective, define constraints, and let evidence decide when work is complete.

Give it a shot and share your feedback in the comments under my YouTube video! ;)

Cheers, proflead! ;)

Build Your First AI Agent with Google CLI (Step-by-Step)

Vladislav Guzey — Wed, 29 Apr 2026 14:27:17 +0000

Vladislav Guzey

Apr 29

What is Google Agents CLI? Full Beginner Guide

#ai #google #googlecloud #tutorial

5 min read

What is Google Agents CLI? Full Beginner Guide

Vladislav Guzey — Wed, 29 Apr 2026 14:26:11 +0000

Google recently released the Agentic CLI, a powerful tool that makes building, testing, and deploying AI agents faster and more intuitive. I think it’s super useful, so I'll walk you through the entire lifecycle of an AI agent using the CLI.

What is the Google Agents CLI?

Before we dive into the code, let’s understand the “why.” Usually, building an AI agent requires a lot of “glue code”, the messy scripts that connect an LLM (Large Language Model) to external tools or databases.

The Agents CLI removes this friction. Agents CLI is an official Google tool for creating, evaluating, and deploying agents built with Google’s Agent Development Kit (ADK). It acts as the programmatic backbone of the Agent Development Lifecycle (ADLC) on Google Cloud.

Skills packaged for agents

Agents CLI bundles seven “skills” that teach coding agents how to perform each step of the ADLC:

Your coding agent can call these skills directly once installed. Alternatively, a human developer can run the same commands manually (see “Human Mode” below).

How to Install Google Agents CLI?

To get started, you need a clean environment. The CLI relies on a few modern web and data tools. Follow these steps to ensure everything is ready:

Prerequisites

Python & PIP: The backbone of most AI development.

sudo apt install python3 python3-pip

Node.js & NPM: Required for the CLI’s interface and deployment features.

sudo apt install nodejs npm

UV: A lightning-fast Python package installer that the Agents CLI uses under the hood.

pip install uv

Installation Steps

Create a Virtual Environment: It is always a good idea to keep your projects separate so they don’t interfere with each other.

python -m venv agent-env  
source agent-env/bin/activate  # On Windows use `agent-env\Scripts\activate`

The CLI is distributed through uv:

uvx google-agents-cli setup

The CLI supports macOS and Linux; native Windows is currently unsupported (use WSL 2 instead).

Authentication

Agents CLI picks up your credentials automatically if you are already authenticated with the gcloud CLI. When running locally without gcloud, you can set a Gemini API key:

export GEMINI_API_KEY="your‑key"

For detailed authentication scenarios (service accounts, A2A roles etc.) refer to the Authentication guide. The important point is that your coding agent inherits whatever credentials your shell has; you do not need to embed secrets in code.

Building Your First “Weather” Agent

The fastest way to learn is by doing. The CLI comes with a “boilerplate” or template system to get you moving in seconds.

Run the following command in your terminal:

agent-cli create my-first-agent  
cd my-first-agent

Install Dependencies

Inside your new project folder, you need to install the specific libraries required for this agent:

agent-cli install

The Playground

One of the best features of this CLI is the Playground. Instead of testing your agent in a black-and-white terminal, you can launch a local web interface.

agent-cli playground

Once you run this, you’ll get a local URL (usually http://127.0.0.1:8000). Open it in your browser, select your agent from the menu, and start chatting. By default, this agent is configured to handle weather requests.

When you are ready to evaluate, call:

agents-cli eval run

Deploy AI Agents

When you run agent-cli deploy, you usually have two choices:

Cloud Run: This treats your agent like a standard web application. It’s great if you want total control over the server.
Agent Runtime: This is a specialized environment built specifically for AI. It handles things like Memory (remembering what the user said earlier) and Orchestration (managing multiple agents working together) automatically.

The Deployment Process

Ensure you have a Google Cloud Project set up.
Enable billing in the Cloud Console.
Run the command:

# Deploy to the configured target (Agent Runtime, Cloud Run or GKE)  
agents-cli deploy

If you want to register your agent with Gemini Enterprise, run this command:

# Register your deployed agent with Gemini Enterprise  
agents-cli publish gemini-enterprise

It allows you to use your agent directly from https://gemini.google.com/

Almost all commands accept flags such as --project, --region, --datastore, --cicd-runner and --deployment-target so that you can customize the environment. Use agents-cli --help the CLI reference for full details.

Agents CLI Key Commands Cheat Sheet

agent-cli setup Installs the core environment
agent-cli create [name] Starts a new agent project
agent-cli playground Launches the web testing interface
agent-cli eval run Checks if your agent is performing correctly
agent-cli deploy Pushes your agent to Google Cloud

Building an agent with your coding assistant

After installation, open your coding assistant (Codex, Claude Code, Gemini CLI, or Copilot) and verify that the Agents CLI skills are visible:

/skills

You should see google‑agents‑cli‑workflow and the other packaged skills. From there, you can instruct the agent using natural language. For example:

Build a support agent that answers questions from our docs

Gemini CLI (or Claude Code, Codex, etc.) will call the CLI skills to scaffold the project, install dependencies, evaluate performance, and prepare deployment. This pattern works with any agent platform that supports skills installation.

If you're happy with the result, simply call deploy command and your agent will be live:

# Deploy to the configured target (Agent Runtime, Cloud Run or GKE)  
agents-cli deploy

Video Tutorial: Agents CLI Explained

In this video, I’ll show you how to use Google Agents CLI to build, test, and deploy AI agents from scratch.

Watch on YouTube: Agents CLI Explained

Conclusion

Google’s new agent‑oriented CLIs demonstrate how the command line is becoming a universal interface for both human operators and AI agents. Agents CLI offers a comprehensive, officially supported pathway to turn ideas into production‑ready agents on Google Cloud.

Give it a shot and share with me what you build!

Cheers, proflead! ;)

GitHub Copilot AI Agents: The Complete Technical Deep Dive

Vladislav Guzey — Sun, 19 Apr 2026 15:07:53 +0000

Vladislav Guzey

Apr 19

GitHub Copilot AI Agents: The Secret to 10x Engineering in 2026

4 min read

DEV Community: Vladislav Guzey

Codex Skill with a Clear Job

Build a Small Codex Skill with a Clear Job

Build a Small Codex Skill with a Clear Job

1. Define one job

2. Create the folder

3. Write SKILL.md

4. Add the field rules

5. Add practice data

Fictional billing data for a practice run

6. Run the skill explicitly

7. Check when Codex chooses the skill

Keep the skill small as it grows

Video and sources

Codex Agents: The New Multi-Agent Dashboard Explained

Manage Multiple OpenAI Codex CLI Tasks with codex agents and codex queue

Manage Multiple OpenAI Codex CLI Tasks with codex agents and codex queue

Requirements

Open the dashboard

Rename important tasks

Queue a message by name

Queue a message by session ID

Attach an image

Useful dashboard controls

Troubleshooting

The command is not available

The task cannot be found

The dashboard is empty

The message does not appear immediately

Recommended workflow

DeepSeek Harness Tutorial: Run Your First Coding Agent with DeepSeek V4

What Runs Locally?

Requirements

Start DeepSeek Harness

Add Your DeepSeek API Key

Select a Model

Choose the Workspace

Select Safe Permissions

Give the Agent a Clear Task

How the Agent Loop Works

What to Try Next

How to Prepare for the Next OpenAI Codex Ambassador Cohort

What is a Codex Ambassador?

The ambassador role as a simple loop

1. Listen to builders

2. Create something practical

3. Support people while they build

4. Share honest feedback

What support is listed?

What is the time commitment?

A five-part preparation plan

Step 1: Build with Codex

Step 2: Publish one reusable resource

Step 3: Help a small group

Step 4: Define your local focus

Step 5: Propose one first-month contribution

What I learned from an event in Thailand

Frequently asked questions

Do I need previous event experience?

Can several people apply from one city?

Do I need to be an expert programmer?

When will applications reopen?

Resources

OpenAI Codex Subagents Tutorial for Beginners

What Are Codex Subagents?

The Built-in Agents I Use

Why I Use subagents (And Why You Should Too)

Where Custom Agents Live

How to Set Up Your Custom Sub-agents

Step 1: Create the Folder Structure

Step 2: Configure Global Settings (config.toml)

Step 3: Write Your Custom Agent Files

Important fields explained

Shortcut: The Codex Agents Library

How to Run Subagents in the Terminal

1. Calling a Single Agent

2. Running Agents in Parallel

3. Managing the Session

5 Critical Mistakes I Want You to Avoid

Codex Subagents: Video Tutorial

Step 2: Configure Global Settings (`config.toml`)

What Is the `/goal` Command in Codex?

When to Use `/goal`

When NOT to Use `/goal`

How to Enable `/goal` in Codex