luismori.

AI Coding Workflows

AI Agents Developer Productivity Subagents Agent Skills Workflow Loop Engineering

Audit Your Daily AI Agent Workflow: Skills, Subagents, and Better Defaults

A practical guide for engineers and PMs who want to improve daily AI-agent work by auditing instructions, skills, subagents, tools, and review habits.

17 min read

TL;DR

  • The fastest way to improve daily agent work is not adding more agents. It is auditing where your instructions live and whether the agent sees the right context at the right moment.
  • Keep small, critical, always-relevant guidance in AGENTS.md, CLAUDE.md, or tool-specific rules. Move repeatable procedures into skills. Use subagents only when the work benefits from isolated context, parallel research, or specialized review.
  • Treat skills like reusable playbooks: short SKILL.md, strong trigger description, optional supporting files, scripts for repeatable checks, and clear permission boundaries.
  • Treat subagents like teammates with narrow job descriptions: researcher, reviewer, debugger, migration planner, test strategist. Avoid vague “senior engineer” agents that do everything.
  • Add explicit “do nothing” and “ask first” paths. The May 2026 FixedBench paper found that tested coding agents proposed undesirable changes in 35–65% of no-change tasks unless inaction was framed as success.
  • The practical weekly habit: review the prompts you repeat, the corrections you make, the failed agent runs, and the risky approvals you granted. Each one is a candidate for a rule, skill, subagent, tool, or human checkpoint.

What You Will Learn Here

  • How to audit your daily AI-agent workflow without turning it into a governance ceremony.
  • When to update always-on instructions versus creating a new skill.
  • When a subagent is useful, and when it only adds review work.
  • A simple agent workflow map you can reuse with engineers, PMs, and team leads.
  • Concrete examples for AGENTS.md, SKILL.md, and a subagent definition.
  • A small backlog of high-leverage agent improvements you can apply this week.

This article is for engineers and PMs who already use AI agents in everyday work: coding, planning, research, debugging, review, QA, writing tickets, summarizing PRs, or preparing release notes.

The goal is not to build a giant agent platform. The goal is much more practical: make tomorrow’s agent session less repetitive, less noisy, and easier to trust.

This article focuses on the audit loop: how to classify repeated friction into always-on instructions, skills, subagents, tools, and human checkpoints. For adjacent topics in the same series, see When to Use Subagents vs the Main Chat Thread for delegation tradeoffs, Skills vs Default Agents for benchmark-backed skill decisions, and The Evolution of AI Agent Orchestration for the maturity model from prompts to plugins.

The Core Idea: Audit the Repetition

Most agent workflow problems leave fingerprints.

You keep pasting the same instruction. The agent keeps forgetting how to run the project. A review bot keeps commenting on low-value style issues. A coding agent keeps changing files before reproducing the bug. A PM asks for a roadmap summary and gets a confident answer with no source trail.

Those are not random annoyances. They are workflow design signals.

Here is the audit loop I like:

Daily agent friction
        |
        v
What keeps repeating?
        |
        +--> Stable fact or team convention? -> always-on instructions
        |
        +--> Repeatable procedure? ----------> skill
        |
        +--> Long isolated investigation? ---> subagent
        |
        +--> Needs external data/action? ----> MCP/tool/integration
        |
        +--> Risky or ambiguous? ------------> human checkpoint

This is the difference between “I use agents a lot” and “I am improving my agent system.”

Start With a 30-Minute Workflow Audit

You do not need a formal maturity model. Open your last week of agent conversations, PRs, Slack threads, tasks, or terminal history and answer five questions.

  1. What did I repeat at least three times?
  2. What did the agent misunderstand more than once?
  3. What context did I have to paste manually?
  4. What work produced a noisy or risky diff?
  5. What did I still need to verify by hand?

Then classify each finding:

FindingBest homeWhy
”Use pnpm, not npm”Always-on instructionIt applies to almost every task.
”Run build before article PRs”Always-on instructionIt is a repo-level expectation.
”Create a changelog from merged PRs”SkillIt is a repeatable procedure.
”Research three migration paths”SubagentIt is long, exploratory, and context-heavy.
”Check if this customer data can be shared”Human checkpointIt is sensitive and policy-dependent.
”Query production logs”Tool/MCP with approvalIt needs live system access and guardrails.

This small table is often enough to find the next three improvements.

The Context Ladder

Modern agent tools now have many context surfaces: AGENTS.md, CLAUDE.md, Cursor rules, skills, subagents, MCP servers, slash commands, hooks, memories, and app-specific settings.

That can feel messy. The trick is to separate them by job.

Always-on instructions
  Small, stable, critical expectations
  Example: setup, test commands, style rules, repo boundaries

Skills
  Reusable procedures and domain playbooks loaded when relevant
  Example: write an article, review a PR, migrate a component

Subagents
  Specialized workers with isolated context and tool boundaries
  Example: security reviewer, test planner, debugger, researcher

Tools and MCP
  Real capabilities and external systems
  Example: GitHub, docs search, browser, database, logs, design APIs

Human checkpoints
  Approval, prioritization, judgment, risk acceptance
  Example: deploy, delete data, merge risky PR, contact customer

The daily workflow improves when each layer has a clear purpose.

Always-On Instructions: Keep Them Boring and Valuable

Always-on instructions are the things the agent should know before doing any work.

The open AGENTS.md format describes itself as a README for agents: setup commands, tests, code style, and conventions that help coding agents work inside a repo. OpenAI’s Codex docs also describe layered discovery: global guidance, project guidance, and closer directory-level overrides.

That makes always-on files perfect for:

  • setup commands
  • build and test commands
  • project structure
  • non-obvious conventions
  • security boundaries
  • “do not touch” areas
  • how to validate work before finishing

They are bad for:

  • long API documentation
  • complete style guides
  • multi-step procedures
  • every preference you have ever had
  • instructions that apply only once a month

The nuance matters. In a January 27, 2026 Next.js 16 eval, Vercel found that a compressed 8KB AGENTS.md docs index reached a 100% pass rate while skills maxed out at 79% even with explicit trigger instructions—because the agent did not have to decide whether to load the context. But a February 2026 arXiv paper on repository context files found that unnecessary requirements in AGENTS.md-style files can reduce task success and increase inference cost by over 20%.

My inference: always-on guidance should be minimal, specific, and operational. Put the “must not forget” facts there. Move the “how to do a complex thing” content somewhere else. Vercel’s result is one framework-specific eval; the arXiv paper is a broader warning against bloated context files.

Example:

# AGENTS.md

## Project Defaults

- Install dependencies with `npm ci`.
- Run `npm run build` before opening a PR that changes source or content.
- Articles live in `content/articles/*.md` and are auto-discovered.
- Keep article frontmatter valid: `title`, `excerpt`, `tags`, and `date`.

## Review Rules

- Do not change unrelated files.
- If no code change is needed, say so and explain the evidence.
- Prefer primary sources for fast-moving AI tooling claims.

Notice what is missing: a giant essay. The agent needs durable constraints, not a bookshelf.

Skills: Turn Repeated Procedures Into Playbooks

Skills are where repeated procedures belong.

Anthropic describes Agent Skills as folders of instructions, scripts, and resources that agents can discover and load dynamically. Claude Code’s skills docs make the practical trigger very clear: create a skill when you keep pasting the same checklist or when part of CLAUDE.md has grown into a procedure.

Cursor 2.4 also added Agent Skills support in the editor and CLI, with SKILL.md files that can include commands, scripts, and instructions. Cursor’s changelog frames skills as better than always-on rules for dynamic context discovery and procedural “how-to” guidance.

Use a skill when the workflow has steps:

  • write a researched article
  • inspect a PR and produce a review
  • migrate one component pattern to another
  • generate release notes
  • debug a flaky test
  • prepare a customer-facing incident summary
  • run a product analytics audit

A skill should be small at the entry point and rich behind the scenes.

article-research/
  SKILL.md              # short workflow and triggers
  references/
    source-policy.md    # how to score sources
    article-template.md # expected structure
  scripts/
    check-frontmatter.js

Example SKILL.md:

---
description: Research and draft a source-backed engineering article. Use when asked to create or update an article with sources, TL;DR, and practical examples.
disable-model-invocation: false
allowed-tools: Read Grep
---

## Workflow

1. Inspect the article schema and two recent articles.
2. For fast-moving topics, gather primary sources first.
3. Draft with:
   - TL;DR
   - What You Will Learn Here
   - practical examples
   - source list
4. Validate frontmatter and run the project build.

## Quality Bar

- Use absolute dates for recent product claims.
- Separate source-backed claims from inference.
- Keep the tone friendly for engineers and PMs.

The skill does not need to contain every article ever written. It needs to reliably start the right workflow.

Subagents: Use Them for Isolation, Not Theater

Subagents are powerful when they protect the main conversation from clutter.

Claude Code’s subagent docs describe specialized assistants with their own context windows, custom prompts, tool access, and independent permissions. Cursor 2.4 describes subagents as independent agents that run in parallel, use their own context, and can be configured with prompts, tools, and models.

That makes subagents useful for:

  • large codebase exploration
  • source gathering
  • log-heavy debugging
  • security or performance review
  • test strategy
  • comparing implementation approaches
  • independent critique after implementation

They are less useful when:

  • the task is tiny
  • every agent needs to edit the same files
  • nobody has time to review multiple outputs
  • the subagent job is vague
  • the main agent already has enough context

Good subagent definitions sound like narrow roles:

---
name: evidence-reviewer
description: Reviews drafted technical claims against provided sources. Use after a research article draft exists.
tools: Read, Grep
model: sonnet
---

You review source-backed writing for accuracy.

Focus on:
- claims that need a source
- claims that overstate what the source says
- dates that need to be absolute
- missing caveats or unsupported recommendations

Do not rewrite the article. Return a concise list of issues and suggested fixes.

Bad subagent definitions sound like vibes:

---
name: super-engineer
description: Helps with engineering tasks.
---

Be smart and improve everything.

The first one has a job. The second one has a cape and no calendar.

A Practical Daily Agent Workflow

Here is a workflow that works well for engineering and product tasks.

1. Frame
   User/PM/engineer states the outcome and constraints.

2. Explore
   Main agent or research subagent gathers repo/source context.

3. Decide
   Human confirms the plan when risk or ambiguity is high.

4. Execute
   Main agent implements; skills provide repeatable workflows.

5. Verify
   Tests, build, browser checks, source audit, or reviewer subagent.

6. Capture
   Update AGENTS.md, a skill, or a subagent if the lesson will repeat.

The last step is the one most teams skip.

If the agent made a mistake and you only fix the output, you improved one result. If you update the workflow asset that caused the mistake, you improve future sessions.

What to Add or Update This Week

Here is a high-signal backlog for most teams using AI agents daily.

1. Add a Short Agent README

If your repo does not have AGENTS.md, add one. If it already has CLAUDE.md, .cursor/rules, or .github/copilot-instructions.md, decide whether AGENTS.md should become the portable index and the tool-specific files should point to it.

Start with:

  • setup commands
  • test commands
  • project structure
  • PR expectations
  • security or data boundaries
  • where to find deeper docs

Keep it short enough that someone would actually review it in a PR.

2. Create a “Change Summary” Skill

This is the daily bread-and-butter skill. It should read the current diff, summarize the change, flag risk, and suggest tests.

---
description: Summarize current git changes, identify risk, and suggest validation. Use before committing or opening a PR.
disable-model-invocation: false
---

## Current diff

!`git diff --stat && git diff --name-only`

## Instructions

Return:
1. What changed
2. Why it appears to matter
3. Risk areas
4. Validation still needed

If the diff is empty, say there are no local changes.

3. Create a Read-Only Review Subagent

Make a reviewer that cannot edit files. Its job is to find issues, not “fix everything” in the background.

Good defaults:

  • read-only tools
  • strict focus on bugs, security, tests, and regressions
  • explicit permission to return “no findings”
  • concise output

This matters because review agents are most trusted when they are selective.

4. Add an Inaction Rule

Add this to your always-on instructions or review skill:

If no code or content change is needed, treat "no change" as a successful outcome.
Explain the evidence and stop.

This small instruction pushes against action bias. The May 2026 FixedBench paper (Coding Agents Don’t Know When to Act) found that tested coding agents proposed undesirable changes in 35–65% of no-change tasks unless abstention was explicitly framed as success. Do not assume the agent naturally knows that restraint is success.

5. Move Long Docs Out of Always-On Context

If your instruction file is becoming a manual, split it:

AGENTS.md
  short index and must-follow rules

docs/agent/
  architecture.md
  testing.md
  release.md

.claude/skills/
  release-notes/SKILL.md
  pr-review/SKILL.md

The always-on file tells the agent where to look. The skill tells the agent how to act. The docs hold details.

6. Use Worktrees for Parallel Agent Work

When multiple agents or sessions may edit files, isolate them.

Claude Code’s worktree docs describe separate working directories with their own branches so parallel sessions do not collide. Cursor 2.0 also emphasized running many agents in parallel through git worktrees or remote machines. For a deeper multi-repo worktree pattern, see Multi-Repo Feature Folders with Git Worktrees and Claude Code.

Use worktrees for:

  • two competing implementations
  • background bug fixes
  • article drafts while a feature branch is active
  • subagent experiments that may touch files

Avoid them when the task is only read-only research.

PM-Friendly Metrics for Daily Agent Quality

PMs do not need to understand every model setting to improve agent workflows. Track simple signals:

SignalWhat it tells you
Repeated correction countMissing or weak instructions
Abandoned agent runsPoor task framing or too much autonomy
Review comment acceptanceWhether review agents are trusted
Time to verified draftWhether agents are accelerating useful work
Number of manual context pastesCandidate skills or docs indexes
Post-agent cleanup timeWhether outputs are too noisy

The point is not surveillance. The point is to notice which workflows are worth productizing.

A Simple Monthly Agent Audit

Once a month, spend 45 minutes with one engineer and one PM.

Inputs:
  - last 10 agent-assisted PRs
  - last 10 repeated prompts
  - last 5 agent failures
  - current AGENTS.md / CLAUDE.md / rules
  - current skills and subagents

Questions:
  - What should be always-on?
  - What should become a skill?
  - What should become a subagent?
  - What should require approval?
  - What should be deleted because nobody uses it?

Outputs:
  - 1 instruction update
  - 1 skill update
  - 1 subagent/tooling experiment
  - 1 thing removed

That last output is important. Agent systems rot when you only add.

Common Traps

Trap 1: Turning Instructions Into a Junk Drawer

If your always-on file has fifty rules, the least important rules compete with the most important ones. Keep the file sharp.

Trap 2: Creating a Skill for Knowledge the Agent Must Always Have

If the agent must know it before any decision, put a small version in always-on context. Skills are useful only when the agent triggers them at the right time or you invoke them directly.

Trap 3: Creating Subagents Before You Have Review Capacity

Parallel work is not free. Every extra agent output needs review, merge, or rejection.

Trap 4: Giving Tools Without Boundaries

MCP and tool integrations are useful because they connect agents to real systems. That is also the risk. The MCP specification itself emphasizes consent, data privacy, and tool safety. Treat tool permissions like production access, not like autocomplete settings.

Trap 5: Forgetting to Capture the Lesson

When an agent makes a mistake, ask: should this become a rule, a skill, a subagent change, a test, or a human checkpoint?

If you are starting from scratch, I would keep it boring:

Repo root:
  AGENTS.md
    setup, tests, conventions, safety rules, docs index

Skills:
  summarize-changes
  pr-review
  research-article
  release-notes

Subagents:
  read-only-code-reviewer
  source-auditor
  debugger
  test-strategist

Tools:
  GitHub
  browser
  docs search
  issue tracker

Human gates:
  dependency additions
  destructive commands
  production data access
  deploys

That is enough to make daily agent use noticeably better without building an over-designed internal platform.

Limitations

This article is intentionally practical, but a few boundaries are worth stating up front:

  • It does not benchmark specific tools head-to-head. Cursor, Claude Code, Codex, Copilot, and other tools are evolving quickly.
  • It does not cover enterprise governance in depth: audit logs, managed settings, data retention, and policy enforcement deserve their own article. For security gates around agentic coding, see Secure Agentic Code Generation.
  • It does not include a full production MCP security checklist.
  • It focuses on knowledge-work and software workflows, not customer-facing autonomous agents.
  • The starter stack is a template. Teams should evaluate each asset against their own failure patterns, not copy it wholesale.

Sources