DEV Community: Robert Ionut Fundulea

Turn a recurring Codex task into a reviewable skill

Robert Ionut Fundulea — Thu, 05 Nov 2026 15:34:28 +0000

Disclosure: I am the maker of the paid Agent Craft Studio toolkit linked at the end. This article was prepared with AI assistance. The example is illustrative, not a measured customer result.

Before packaging a recurring agent task, write down what a good result must preserve and what the agent should do when information is missing. That gives you something concrete to review each time you change the workflow.

Here is a small example: turn rough client notes into a project brief for a developer.

1. Give the workflow a bounded job

Use a brief like this:

Convert the supplied notes into a project brief containing the objective, audience, requested deliverables, existing stack, budget, timing and open questions. Preserve supplied amounts, currencies and dates. Mark missing information as unknown. Surface contradictions instead of choosing an answer silently. Do not create commitments for the client.

The task has a recognizable input and output. It also states decisions that remain with a person. You can review whether the output followed that contract without relying on how polished the prose sounds.

2. Separate stable instructions from project facts

The reusable part is the method: what to extract, which fields to produce, and how to handle uncertainty. A client's budget, preferred stack and deadline belong in the current input.

OpenAI’s skills documentation describes skills as instructions and resources for repeatable workflows. When building a skill, keep its purpose focused enough that the agent can tell when to use it. Supporting examples and reference material can explain the method without making every invocation carry every previous client's information.

A useful maintenance question is: if I reuse this tomorrow for a different client, which facts must be replaced?

3. Make tool use part of the contract

If the workflow reads from an MCP tool, specify the source it should consult and how to handle incomplete results. A returned document can support a brief; it does not automatically authorize sending the brief, changing a project or publishing a commitment.

For this example, the first version can stop at a reviewable draft. If you later add a write operation, give that operation its own inputs, destination and verification step.

Tool access and workflow instructions need to agree. An instruction that says to inspect an existing project cannot be completed if the assistant has no way to read that project.

4. Keep a few behavioral examples

Start with cases that could change a real decision:

Input case	Behavior to inspect
No deadline is supplied	The timing field remains unknown; the agent asks for it.
Two notes give different budgets	Both values and their conflict are visible.
The notes specify EUR 800	The brief preserves the amount and currency.
The project already uses React	The brief records that fact without inventing a migration.
The notes request a landing page but no hosting	Hosting remains an open question rather than a promised deliverable.

These are proposed checks. They are not claims that a particular model or toolkit has passed them.

After an instruction change, compare the new outputs against the same cases. Record what passed, what failed and what you did not rerun. A small case set helps reveal regressions; it does not prove every future request will work.

5. Ask for a reviewable handoff

The final response should make the result easy to inspect:

Return the brief, list unresolved questions, and identify any conflicting facts. Report which checks you actually performed. Keep proposed next actions separate from actions already completed.

That last distinction matters when a workflow grows from drafting into tool use. A prepared update and a saved update are different observed outcomes.

Using a downloadable toolkit with AI assistance

I packaged related workflows, editable source, examples and evaluation material in Agent Craft Studio. It is a paid downloadable software/documentation toolkit.

After downloading it, a buyer can ask Codex to read the included START HERE guide and help with installation. This needs an assistant with authorized access to the local files and a terminal. An ordinary ChatGPT conversation does not itself install a local Codex plugin.

Here is a prompt to adapt after downloading:

I downloaded Agent Craft Studio to [absolute ZIP path]. Help me install it in my local Codex setup. First inspect the archive entries and read the included START HERE and installation instructions. Check Codex plugin support and the Node.js version. Preserve the complete package structure. Explain the required changes and follow the documented installer steps; do not guess script names or commands. If a permission or manual step is required, tell me what it is. Verify the documented result, then tell me when to open a new Codex task. Report missing prerequisites or unverified steps honestly.

The native plugin requires compatible Codex with plugin support and Node.js 24+. Windows is the tested platform described in the listing; other native-host installs are unverified. Creator-backed scaffolding and authoritative validation additionally require Python 3.11+ and the installed Codex system creator utilities. The separate ChatGPT companion is a manual copy-and-paste kit. AI accounts and usage are separate.

AI assistance does not guarantee an unattended installation. The assistant still needs access, the required software and the package's actual instructions.

For the example above, which missing fact would you want the brief to flag before a developer starts work?

Four lessons from building AI, education, and healthcare products with Next.js

Robert Ionut Fundulea — Mon, 27 Jul 2026 19:20:30 +0000

Over the last few years, I have built products in very different domains: generative AI, job search, education, and clinic operations.

Although the interfaces and users are different, several engineering lessons appeared repeatedly.

1. Multiple AI features still need to feel like one product

Klyro brings together streamed chat, cited web search, image analysis, and image generation.

The difficult part was not simply connecting several AI services. It was creating one consistent experience around them: shared authentication, one responsive interface, predictable errors, subscriptions, billing, and a transparent credit balance.

For every operation, Klyro estimates the cost, reserves the required credits, and settles the balance according to actual usage. When an operation fails, the reserved credits are released.

Live product:
https://www.klyroai.net

2. AI should assist important decisions, not hide them

RoleMint is a job-search copilot that discovers opportunities, compares them with a candidate’s profile, generates ATS-oriented materials, and organizes applications in a visual pipeline.

The user remains responsible for reviewing and approving every generated application. That human checkpoint is important when AI-generated content represents someone professionally.

https://rolemint.vercel.app

3. A learning platform starts with its data model

BrightLearn supports lessons, categories, tags, quizzes, questions, answers, attempts, scoring, and progress history.

It was built with Next.js, TypeScript, Prisma, PostgreSQL, Clerk, and AI integrations. Designing the relationships between learning content and user attempts was just as important as building the interface.

BrightLearn is open source:
https://github.com/RobertIonutF/brightlearn

Application:
https://medilearn-rose.vercel.app

4. Operational software needs traceability

FizioKinetoMaxim is a protected CRM for clinic operations. It centralizes patients, appointments, medical and administrative activity, CAS cases, exercise programs, feedback, reports, incidents, complaints, and audit history.

The application uses Next.js, TypeScript, and Convex for reactive data and real-time workflows. Role-based access and traceability were essential because the application handles sensitive operational processes.

https://fiziokineto-maxim-crm.vercel.app

Building similar products

I work on complete SaaS products, AI integrations, CRM systems, educational platforms, and operational dashboards.

If you need something similar, you can contact me through LinkedIn:
https://www.linkedin.com/in/robertionutfundulea/

You can also support my independent projects here:
https://buymeacoffee.com/robertfundulea

A Bug Triage Workflow for AI That Does Not Invent the Root Cause

Robert Ionut Fundulea — Tue, 21 Jul 2026 18:19:17 +0000

AI can make bug triage faster, but it also makes one dangerous failure mode easier: turning a plausible explanation into a confident diagnosis before the failure has been reproduced.

The useful question is not “Can the model suggest a cause?” It usually can. The question is: what evidence would let another developer review that cause?

Here is the workflow I now use for AI-assisted bug work.

1. Turn the report into an actionable record

Capture the build, environment, user path, expected behavior, actual behavior, frequency, impact, and any existing evidence.

Keep observations separate from interpretations. “The request returned 500 at 14:32” is evidence. “The database timed out” is still a hypothesis unless the logs support it.

If a material fact is missing, the workflow should ask for it. It should not silently fill the gap.

2. Reproduce—or document bounded non-reproduction

A good reproduction record includes:

the exact setup and version;
inputs and relevant timestamps;
ordered actions;
expected and actual output;
logs, screenshots, or traces;
the control case that still works.

When the issue does not reproduce, return the matrix that was tested and name the next signal needed. “Could not reproduce” is not the same as “the bug is invalid.”

3. Compare the failing path with a working control

A nearby working path is often more useful than reading the entire codebase.

Consider a fictional scheduling defect: patients can double-book a physical slot near the spring daylight-saving transition, but only when rescheduling in Europe/Bucharest.

The new-booking path normalizes local time through a timezone-aware scheduling boundary. The reschedule path compares a naive local value directly with stored UTC instants.

That comparison gives us something much stronger than “timezones are hard”: a narrow difference between a failing path and a working control.

4. State the smallest evidence-supported cause

A useful cause statement has three parts:

Condition: rescheduling across the DST boundary.
Mechanism: a naive local timestamp is compared with stored UTC instants.
Evidence: the failing path skips normalization while the working booking path uses it.

Also record alternatives that were ruled out and those that remain untested. This prevents a narrow finding from becoming an unsupported claim about the whole system.

5. Repair the authority boundary, not the symptom

The minimal repair is to route rescheduling through the existing timezone-aware normalization function before collision checks.

It is not to weaken collision rules globally, disable validation near DST, or rewrite every scheduling path.

Minimal does not mean careless. It means correcting the supported cause with the smallest reasonable regression surface.

6. Protect the invariant

The regression test should fail for the original defect and prove the behavior that matters:

equivalent instants cannot reserve the same physical slot;
the DST gap is handled according to the product rule;
adjacent slots still work;
ordinary dates remain unchanged;
the new-booking control path stays green.

Then add rollout signals and a recovery path appropriate to the risk. A local test does not prove production repair.

A compact review checklist

Before accepting an AI-assisted diagnosis, ask:

Do we know the exact environment and build?
Is expected behavior stated independently of the implementation?
Was the failure reproduced, or was non-reproduction bounded?
Is there a working control path?
Does the cause statement connect condition, mechanism, and evidence?
Does the proposed change preserve unrelated policy?
Does the regression test protect the invariant rather than mirror the code?
Are rollout and recovery signals explicit?

AI is valuable here as a structure and comparison tool. It can organize evidence, propose a reproduction matrix, compare paths, and draft regression cases. It should not claim a root cause, test result, or production behavior it has not observed.

I published a free, read-only walkthrough with the worked timezone example here:

AI Bug Triage Workflow: From Report to Minimal Fix

I built CodeCurrent Studio and may benefit if someone buys one of its workflow packs. The walkthrough above is free. CodeCurrent Studio is independent and is not affiliated with or endorsed by any AI model vendor.