Codex Cli and Desktop do not follow Programming Skills Created - Does not make make new code data, paths, names, artifacts db-owned as required

I am seeing the same underlying failure mode described in this issue, specifically with GPT-5.6 Sol at high reasoning effort: the model can acknowledge or restate project requirements, yet still fails to apply them consistently during analysis and implementation.

I have now used Sol for three consecutive days on existing, documentation-heavy projects, consistently selecting a high reasoning-effort level.

The primary problem is not token consumption. The primary problem is a material degradation in reasoning quality, context discipline, and analytical reliability.

In regular project work, GPT-5.6 Sol repeatedly:

• fails to study the supplied references and existing project documentation deeply enough before forming a conclusion;
• misinterprets the task and builds its subsequent reasoning on an incorrect problem formulation;
• produces shallow, underdeveloped, or irrelevant answers despite a high reasoning-effort setting;
• loses or distorts constraints, facts, and conclusions established earlier in the same thread;
• contradicts its own previous answers without identifying or resolving the contradiction;
• accepts the user's assumptions too readily instead of testing them critically;
• fails to compare the available facts, develop multiple viable options, and explain the trade-offs behind each option;
• responds quickly, but without the depth and verification expected from the highest-tier model.

In my day-to-day use, this is visibly worse than GPT-5.5 under comparable working conditions. This is not merely a stylistic preference.

Incorrect task interpretation propagates through the entire workflow: the model selects the wrong materials, constructs the wrong analysis, proposes the wrong implementation approach, and then produces an answer that may appear confident but is not grounded in the available project evidence.

Token usage, repeated repository scans, and additional compactions are secondary symptoms. When the model fails to understand the task correctly, users have to re-explain requirements, restore lost context, correct contradictions, and force the model to re-read materials it should have analyzed properly the first time.

The resulting token consumption is therefore a consequence of poor reasoning quality, not the central complaint.

This level of performance is unacceptable for GPT-5.6 Sol running at high reasoning effort. Users select the flagship model and deliberately accept higher latency and usage because they expect:

• deeper analysis;
• reliable context retention;
• critical evaluation of assumptions;
• careful examination of the supplied materials;
• consistent and well-supported conclusions.

If High, Max, or Ultra effort can still produce fast but shallow and inconsistent reasoning, those settings no longer represent the quality level their names imply.

Please investigate this as a model-quality regression, separately from token accounting:

1. Compare the current GPT-5.6 Sol serving configuration against GPT-5.5 on long-running, documentation-heavy project tasks.
2. Verify that the selected High, Max, or Ultra effort is actually preserved throughout the thread and is not silently reduced after continuations, compaction, or delegation.
3. Add quality evaluations for:

• task-interpretation accuracy;
• reference-material fidelity and completeness;
• cross-turn context retention;
• contradiction rate;
• the ability to challenge incorrect user assumptions critically;
• the ability to compare facts and present multiple well-supported solution options.

1. Clarify whether any serving or reasoning-profile changes prioritize response latency over analytical depth.
2. Publicly acknowledge the problem and provide a concrete investigation or remediation status.

The current experience is deeply disappointing. A flagship reasoning model should not require constant user supervision merely to remain aligned with the task, respect the supplied evidence, and avoid contradicting itself.

You expect adding a skill will make the agent follow it. But skills are not rules, they are just things the agent can decide to use, or not.

Move to feedback oriented agent loop, with a few validation rules will solve your needs

https://www.wix.engineering/post/how-to-build-ai-agents-that-fix-themselves-without-bigger-prompts-more-context-or-another-llm

Thanks for your reply. Currently testing agent loops and hooks to try to enforce rules which also where not working correctly with gpt 5.5 . Testing the Jay Framework to see if possible to fix and remain consistent.
.

I am seeing the same underlying failure mode described in this issue, specifically with GPT-5.6 Sol at high reasoning effort: the model can acknowledge or restate project requirements, yet still fails to apply them consistently during analysis and implementation. I have now used Sol for three consecutive days on existing, documentation-heavy projects, consistently selecting a high reasoning-effort level. The primary problem is not token consumption. The primary problem is a material degradation in reasoning quality, context discipline, and analytical reliability. In regular project work, GPT-5.6 Sol repeatedly: fails to study the supplied references and existing project documentation deeply enough before forming a conclusion; misinterprets the task and builds its subsequent reasoning on an incorrect problem formulation; produces shallow, underdeveloped, or irrelevant answers despite a high reasoning-effort setting; loses or distorts constraints, facts, and conclusions established earlier in the same thread; contradicts its own previous answers without identifying or resolving the contradiction; accepts the user's assumptions too readily instead of testing them critically; fails to compare the available facts, develop multiple viable options, and explain the trade-offs behind each option; responds quickly, but without the depth and verification expected from the highest-tier model. In my day-to-day use, this is visibly worse than GPT-5.5 under comparable working conditions. This is not merely a stylistic preference. Incorrect task interpretation propagates through the entire workflow: the model selects the wrong materials, constructs the wrong analysis, proposes the wrong implementation approach, and then produces an answer that may appear confident but is not grounded in the available project evidence. Token usage, repeated repository scans, and additional compactions are secondary symptoms. When the model fails to understand the task correctly, users have to re-explain requirements, restore lost context, correct contradictions, and force the model to re-read materials it should have analyzed properly the first time. The resulting token consumption is therefore a consequence of poor reasoning quality, not the central complaint. This level of performance is unacceptable for GPT-5.6 Sol running at high reasoning effort. Users select the flagship model and deliberately accept higher latency and usage because they expect: deeper analysis; reliable context retention; critical evaluation of assumptions; careful examination of the supplied materials; consistent and well-supported conclusions. If High, Max, or Ultra effort can still produce fast but shallow and inconsistent reasoning, those settings no longer represent the quality level their names imply. Please investigate this as a model-quality regression, separately from token accounting: 1. Compare the current GPT-5.6 Sol serving configuration against GPT-5.5 on long-running, documentation-heavy project tasks. 2. Verify that the selected High, Max, or Ultra effort is actually preserved throughout the thread and is not silently reduced after continuations, compaction, or delegation. 3. Add quality evaluations for: task-interpretation accuracy; reference-material fidelity and completeness; cross-turn context retention; contradiction rate; the ability to challenge incorrect user assumptions critically; * the ability to compare facts and present multiple well-supported solution options. 4. Clarify whether any serving or reasoning-profile changes prioritize response latency over analytical depth. 5. Publicly acknowledge the problem and provide a concrete investigation or remediation status. The current experience is deeply disappointing. A flagship reasoning model should not require constant user supervision merely to remain aligned with the task, respect the supplied evidence, and avoid contradicting itself.

Thanks for observation confirming the same results I am having. I had many of the same issues previously with gpt-5.5 and hope that model will improve execution of rules and guidence. Currently working in designing a review and control loop system to validate execution the check work better to avoid constant rewrites. Have decided to work now with Claude which is generally more expensive to use but honestly much better results with Opus 4.8 following rules Skills and prompt guidance or asking when not clear to make plans.