One Article Teaches You from Writing Good Prompts to Managing Agents – Bonus: Agents.md

“No need to write prompts anymore?” I’ve been seeing statements like this a lot lately.

Recently, people have also seen OpenAI’s official prompt engineering guide, as well as posts claiming that workflow skills like Superpowers affect the performance of GPT-5.6 series models. So we have to admit:

As models get more powerful, the skills we previously used to improve Agent effectiveness might actually interfere with the Agent. And we know that Skills

When Agents like Codex and Claude Code truly start reading files, editing code, calling tools, and running tests, saying “help me finish this project” is far from enough.

It at least needs to know:

• What the goal is;
• Where the context is;
• Which files and tools are allowed to access;
• Which operations are forbidden;
• When to stop and ask a human;
• What conditions count as completion.

This is the signal that AI workflows have truly entered the “control plane.” 🤖

Prompt Engineering Hasn’t Disappeared – It Has Upgraded from Sentence Craft to Agent Engineering

Traditional prompt engineering focused on: how to make the model give a better answer in one shot.

Agent tasks focus on: how to make the agent complete the task safely, stably, and verifiably.

So a qualified Agent task card should at least include:

• Goal: what is ultimately to be changed;
• Context: relevant repositories, files, data, and known issues;
• Allowed access: readable paths, writable paths, usable tools;
• Forbidden: do not delete, publish, push, or modify certain content;
• Execution method: analyze first, then plan, then implement in stages;
• Feedback mechanism: pause when scope changes, tests fail, or high-risk operations occur;
• Completion criteria: what checks must pass, what to deliver in the end.

“Help me implement the login page” is too vague.

Turn the above into this:

“Only modify src/auth/ and related tests. First check existing routes and API types. Do not add new dependencies. After finishing, run npm test. If a public interface needs to be changed, pause and confirm first.” That’s close to an issue written for an AI engineering collaborator.

Codex Demonstrates a New Way of Working

I think the most interesting part of Codex isn’t that it can write code, but that it breaks an Agent task into several controllable phases:

• Ask / Plan: first understand the codebase and problem;
• Execute: modify according to the plan;
• Steer: correct course in time during execution;
• Verify: accept with tests, type checks, lint, and diff;
• Queue: queue up temporary follow-up tasks without interrupting the main line.

This means we should no longer treat the Agent as a “chatbot that waits for an answer after submitting a prompt.”

It’s more like:

Propose goal → Agent plans → Human confirms direction → Agent executes → Phase checks → Continuous correction → Final acceptance

The key to long tasks is not to let the model think through everything at once, but to let the human always see what it’s doing.

This is also somewhat like a Loop, a workflow Loop.

How to Optimize an Agent Workflow

1. Cut Tasks Small

Don’t ask the Agent to “finish the whole product” in one go.

Break the task into single outcomes like locate the problem, add tests, implement a module, run verification, organize changes. The smaller the task, the easier it is to spot where it went wrong.

2. Write Stable Context into AGENTS.md

Startup commands, test commands, directory conventions, files that cannot be modified, historical pitfalls – all should be in the project context.

Temporary information for the current task goes in the prompt; long-term rules go in AGENTS.md.

3. Match Permissions to Task Scope

Reading code, editing code, running local tests, accessing external services, publishing or destructive operations – these should be different risk levels.

MCP solves “how to connect tools,” but does not automatically solve “what the tool should do.”

Tool whitelists, read/write separation, credential rotation, call logs, and manual confirmation are the foundation for an Agent to enter a real system.

4. Use Phase Acceptance Instead of Final Acceptance Only

Don’t wait until the Agent finishes everything to realize it misunderstood from the first step.

Ask it to output in stages: “analyze → plan → implement → test → summarize”, leaving checkable results at each stage.

5. Use Data to Judge Whether Optimization Is Effective

Change only one variable per optimization. Record:

• First-time completion rate;
• Number of rework and steer interventions;
• Error rate for paths, tools, and permissions;
• Token usage, cost, execution time, and human review time.

If you just make the prompt longer but don’t reduce rework and tool errors, it’s not true optimization.

My Tool Stack Choice: Don’t Overload GPT-5.6 with Heavy Workflows

Recently, there’s a claim in the community: strong workflow skills like Superpowers might slow down GPT-5.6 series models, consume more context, and even degrade task quality.

This is not yet a confirmed conclusion.

I’ve seen community issues where someone reports that the reporting phase was skipped and the review agent was incorrectly scheduled in parallel. Another Codex issue documents a repetitive loop related to brainstorming.

These materials suggest there might be compatibility issues between skill orchestration and runtime, but they don’t alone prove “Superpowers makes GPT-5.6 dumber.”

But from a practical usage standpoint, I make a deliberate trade-off:

Keep grill-me. Before actual execution, use it to repeatedly question goals, scope, assumptions, and acceptance criteria until the plan is clear.

Delete or disable other Superpowers’ auto-serialized skills. Don’t force every small task through brainstorming, planning, TDD, debugging, review, and wrap-up. That wastes tokens!

I choose to keep subagent-driven-development. Complex tasks can still be split into multiple clearly bounded sub-tasks, handled by different Agents, and finally integrated and verified by the main Agent.

The key is not that more process equals more professional; the process must match the task size.

Changing three lines of CSS does not need a full specification review chain.

Cross-module migration is worth splitting into multiple sub-tasks with quality gates.

A Ready-to-Use Skill

For grill-me:

First, strictly review this development plan. Do not write code.

Focus on:

1. Is the goal verifiable?
2. Is the context and file scope clear?
3. Are any dependencies, risks, and rollback methods missing?
4. Which steps can be removed or merged?
5. Can the final acceptance criteria be verified with tests or commands?

Keep questioning until the plan is small enough and clear enough, then output a streamlined task card.

Practice: Let the Agent Safely Add a GET /health Endpoint

Step One: Confirm the project baseline.

Read-only check of the current repository. Do not modify files.

Output:

• 1. Framework and entry point;
• 2. Location of routes and test files;
• 3. Commands for install, test, type check, and lint;
• 4. Current git workspace status;
• 5. Whether current tests pass.

If unsure, mark as “unconfirmed”. Do not guess.

Step Two: Only let the Agent plan, do not code yet.

Goal: Add a GET /health endpoint to an existing Node.js + TypeScript service.

Expected response: HTTP 200, JSON { "status": "ok" }.

Constraints:

• Only modify route implementation and related tests;
• Do not modify database, deployment config, or unrelated modules;
• Do not add new dependencies;
• Do not overwrite existing uncommitted changes.

Completion criteria:

• New endpoint test;
• Related tests pass;
• Type check and lint pass;
• Finally list modified files and uncovered risks.

Now only analyze the repository and give an implementation plan. Do not modify files.

Step Three: Confirm the plan before executing.

Require writing tests first, then implementing the code. Handle one small step at a time. Pause if the scope needs to expand. After completion, run related tests, type check, and lint.

Step Four: Real-time correction.

If the Agent starts modifying unrelated files, say directly:

Pause current action. You are modifying files outside the task scope. Return to src/routes/ and corresponding test files. Only implement the /health endpoint. Do not refactor neighboring modules or add new dependencies. First state which files you will modify next, then continue.

Step Five: Treat verification results as the final deliverable.

Require it to report:

• npm test
• npm run typecheck
• npm run lint
• git diff --stat
• git diff --name-only

The final answer must include: modified files, commands executed, test results, example request and response for the endpoint, and edge cases not verified.

The minimal loop of this method is:

Baseline check → Plan → Small-step execution → Real-time correction → Automated verification → Human review

My Final Judgment

“Prompt engineering is dead” is a false narrative.

A more accurate statement is: Prompt engineering is evolving from sentence craft into Agent engineering.

In the past, we optimized whether a single sentence could make the model answer correctly.

Then came many workflow skills to enhance Agent thinking.

Now we design whether a set of tasks can be safely completed by an agent, and whether there is too much redundant prompting.

For individual developers, the next step is not just learning more prompt techniques, but preparing four things:

• Stable project context;
• Clear tool boundaries;
• Repeatable verification processes;
• An interaction interface that allows humans to correct course at any time.

Models will continue to improve, but what truly determines whether an Agent can enter a real workflow is often these “not-so-smart” control details.

Finally, I share the AGENTS.md file I’ve been using. You can use it directly:

AGENTS.md

This file provides long-term working conventions for AI Coding Agents. It applies to Codex, Claude Code, Cursor, and Antigravity.

User Background

• Name: 【】
• Role: 【】
• Default language: Simplified Chinese
• Operating System: 【】

Working Principles

1. Simplicity First

Solve the current problem with minimal code. Do not add speculative features.

• Do not add unsolicited extended functionality.
• Do not over-abstract. Do not reserve configurations or interfaces without real need.
• If 50 lines can solve it clearly, do not write a 200-line complex solution.
• If the solution seems over-engineered, actively trim it and explain the trade-off.

2. Precise Changes

Only modify what is necessary to complete the task. Maintain the existing project style.

• Do not incidentally refactor adjacent normal code, comments, or formatting.
• Preserve the user’s existing uncommitted changes. Do not overwrite, roll back, or clean them without permission.
• Remove orphan functions, abandoned branches, and unused dependencies introduced by this change.
• If historical issues are discovered, only report them. Do not modify them beyond the task scope unless the user explicitly asks.

3. Result Verification

Turn tasks into checkable goals and form independent verification loops.

• New feature: First add tests for key behavior or invalid inputs, then implement the code.
• Bug fix: First write a failing test that reliably reproduces the issue, then fix.
• After completion, run tests, type checks, lint, or build commands related to the changes.
• Finally, describe the modified files, commands executed, verification results, and uncovered risks.

4. Use Process According to Task Size

• Single-line copy change, simple query, small-scope modification: handle directly. Do not force a plan.
• Multi-file, multi-step, or architecturally impactful tasks: first give an implementation plan with file paths.
• Each step of a complex task should be independently executable and verifiable.
• Split parallel development only when sub-task boundaries are clear and dependencies are well-defined.

5. Answering Style

• Lead with the conclusion. Express clearly, directly, and with evidence.
• When involving code, architecture, or debugging, explain key judgments and trade-offs.
• When uncertain, explicitly write assumptions, risks, and verification methods.
• Do not fabricate non-existent APIs, files, test results, links, or facts.

Work Boundaries

• Without explicit authorization, do not commit, push, publish, send messages, or disclose content.
• When deleting, overwriting, large-scale moving, or renaming, first confirm the scope.
• For time-sensitive facts, verify sources first. If unverifiable, mark as uncertain. Do not present rumors as facts.
• User explicit instructions take precedence over preferences in this file. Platform security rules and permission boundaries always apply.

Meta rule: These conventions serve results, not as a ritual to be executed line by line. Keep simple tasks lightweight. Increase planning, splitting, and verification only for complex tasks.

References

OpenAI Prompting fundamentals
https://openai.com/academy/prompting/

OpenAI: How OpenAI uses Codex
https://openai.com/business/guides-and-resources/how-openai-uses-codex/

OpenAI: Working with ChatGPT Codex
https://openai.com/academy/working-with-codex/

OpenAI Codex Manual: AGENTS.md
https://learn.chatgpt.com/docs/agent-configuration/agents-md.md

Google: Expanding Managed Agents in Gemini API
https://blog.google/innovation-and-ai/technology/developers-tools/expanding-managed-agents-gemini-api/

Google: Gemini API Docs MCP and Agent Skills
https://blog.google/innovation-and-ai/technology/developers-tools/gemini-api-docsmcp-agent-skills/

Community issues:
https://github.com/obra/superpowers/issues/1463
https://github.com/openai/codex/issues/21786

#AIAgent #VibeCoding #Codex #MCP