I assume the main difference in our perspectives is based on different starting points?
Where I am coming from is a state where documentation already exists and needs to be implemented for review and refinement.
That is before your step 1?
If your docs exist but still lead to situations where agent finds a shortcut better than what is defined in the plan it had when starting a goal.. I would take it for a signal of either docs are stale or goal planning process needs a deep review.
Yes, that’s basically what I give codex when /goal is used for code (the folder is finalized in step 4 from the sequence, coding would start as #5 in that sequence).
But it only sounds “scary”, those could be more or less instruction on how to define steps based on request and using codex/chat to generate the prompt for phase 1 (research). Once the research is there, then it’s way easier just to copy paste it adjust existing prompts (or pointing to similar folders) to move through steps
I agree. That was one of my learnings along the way. But I still consider goal to be more of an exploration type of activity than a standardized execution.
From what I understand that’s where your research kicks in.
Yet, but it doesn’t not arrive “bare” as “find me how to”.
Before the research phase (that can be executed as a goal) I plan
- “how would you design a serious research if you would need to know everything about how to do this”
- “what is missing in your design or is underoptimized” then
- “based on the above, create a detailed plan for the research” …
- Then “/goal execute research defined by plan R in that folder”
(The questions sequence sample)
wth… like “hey codex burn token, I don’t even know what I want”?
I tried everything in that x article at least twice.
/goal feels like a kid playing with mud trying to build a castle and it got a credit card and ordered professional material…
When you look at the material list it looks ok.. but…
My friend, from what little I know about you…
You think like really big ideas…
Have you considered splitting your goals into AI-sized bites?
Just curious.
I did but it starts making enterprise level shit code from something that could actually be good.
Would you share your agents.md with us to have a look or maybe just pm me?
my hunch is that is worth touching
nice try haha… nah, can’t do that unfortunately..
I have another /goal running atm.. ~16 hours in atm… Let’s see if it can change my mind.
I’ve added a lot of insults to let it think deeper to “please the customer”…
I am trying to solve this:
from this:
It’s a kind of programmatic guard rail so the model can’t mess it up even if it tries…
There’s no nice try there jochenshultz
explain the kind of code you want but also the reasoning rules
Add at the top for a while:
'For generating code, prefer the smallest safe way to implement all required aspects for every goal."
is the fastest one-line fix I can offer you as a suggestion to show my hands are clean of any ‘nice try material’
Read that in a happy voice with a little laughter without any nasty ulterior motives.
The PLAN.md has ~1100 Lines which I had it write by itself and then checked it manually…
okie dokie.
But there ya go, that explains the issue to me but I’m just an otter and don’t know anything ^.^
Well, ok.. maybe there is something useful coming out from /goal
You use it for quality control of automatically generated app packages.
In practice, you select a project, profile, and app, for example connector.ads.google. The tool then shows all generated files: code, CSS, JSON contracts, data models, seeds, migrations, and so on.
Then you check whether:
- the generated structure is correct
- files are in the right package
- names and paths are correct
- required files are present
- rules are followed, for example no hardcoded brand colors if theme tokens should be used
- the contracts correctly describe data, themes, permissions, workflows, installation, etc.
- the package can be approved
On the right side, you can then Accept or Reject files.
In plain English:
It is a review bench for generated app packages before they are accepted into the system.
Or even shorter:
A kind of QA / approval tool for generated software building blocks.
And the generated apps have a PHP on steroids backend 