AI-SDLC in Practice: Six Capabilities for Using Coding Agents Effectively

1. Model and Framework: Understand the Agent’s Division of Labor

A coding agent splits into two layers:

• Model: responsible for reasoning, generation, and decisions — it decides “what to think about.”
• Harness (framework layer): responsible for everything outside the model — it decides what the model “sees, can do, and how to continue.” It includes at least six things:
  1. Conversation loop: orchestrating the multi-turn iteration of “think → call a tool → read the result → keep reasoning”;
  2. Tool calling: defining, parsing, and executing tool inputs and outputs;
  3. Context assembly and compaction: deciding what each request contains, and distilling history when the window limit approaches;
  4. Subagent spawning and reclamation: handing independent tasks to separate sessions, then reclaiming their conclusions;
  5. Permission confirmation: intercepting and approving high-risk actions such as writing files or running commands;
  6. External connections: connecting to systems and data sources outside the project.

Mainstream coding agent frameworks are already fairly complete, so there’s rarely a need to reimplement these six modules from scratch. A more realistic approach for an AI-SDLC team has three steps:

1. Map the host’s capability boundaries: clarify who writes each type of information, when it enters the context, and when it is reclaimed.
2. Reuse the host’s capabilities: let the framework handle context management, permission and sandbox mechanisms handle approval and isolation, and standard protocols handle external data access.
3. Build only what the host doesn’t provide, focused on two things:
   • A CLI: drives the workflow and gives the agent helper tools for builds, tests, linting, and contract validation;
   • A knowledge base: captures architecture standards and coding rules to raise the quality of agent-generated code.

The division of labor is clean: the CLI provides “deterministic actions and results,” the knowledge base provides “judgment criteria and constraints,” and the framework layer decides when to feed both into the window.

2. The Context Window: Where the Framework Layer Really Fights

The harness’s most central job is deciding what goes into the context window on each turn. At least seven categories compete for the same space:

Content type	Typical characteristics	Budget profile
System prompt	Built into the framework; defines the role, behavior rules, and output requirements	Fixed cost; usually not trimmable from the project side
Project-level rule files	Architecture constraints, coding conventions, collaboration agreements	Resident for the whole session; size directly eats available space
Tool definitions	Names, purpose descriptions, parameter structures	Grows with the tool set; usually present throughout
Skill list	Names plus short descriptions, for on-demand loading	The initial list has a share cap, and each description has a length cap
History messages	User instructions, model replies, and the trial-and-error inside them	Grows linearly with turns; compacted first
Tool results	File contents, command output, search results	A single item can be huge; the main cause of a blown window
Dynamically injected content	Hook output, data returned by external protocols	Written at specific points in time; local occupancy

Public documentation for the major tools often states explicit built-in budgets. For example:

• When merging project-level rule files, set a total byte cap and, by default, read only a leading range of the file (on the order of tens of KiB);
• The initial skill list may occupy only a certain share of the context window (e.g., 2%);
• A single rule file is recommended to stay within a certain number of lines (e.g., 200 lines);
• Skill descriptions are truncated in the list once they exceed a certain length (e.g., 1,536 characters).

These numbers change across versions, but the thinking is consistent: the framework layer already strictly controls every block of content in the window.

Why Be So Stingy

Because every irrelevant block in the window carries a real cost:

• Diluted attention: in long contexts, adherence to key constraints degrades as irrelevant content grows;
• Conflicting rules: when a shared rule file mixes in details that only apply to some scenarios, it easily clashes with the current task;
• History noise: if compressed trial-and-error logs leave residual conclusion fragments, the model may treat a “previously failed approach” as a “viable approach”;
• Slower responses: the longer the input, the higher the time to first token.

So what AI-SDLC needs is not “feed the agent every rule,” but using the capabilities the harness provides to load only what each stage needs into the window:

• Requirements understanding doesn’t need the previous task’s build logs;
• Architecture design should load layering conventions and interface contracts, not frontend style rules;
• The code review role shouldn’t see the development role’s trial-and-error process, or it gets “carried along” by the development mindset.

The less irrelevant content in the window, the more focused the agent and the more stable its judgment.

3. Six Capabilities: Where Each One Acts in the Window

Capability	When it enters the window	Scope of effect	Main risk
Project-level rule files	Injected at session start, resident throughout, re-injected after compaction	Current project session	Oversized content crowding out the window
Skills	Full content loaded when a task matches	A single task	Vague descriptions causing wrong or missed loads
Subagents	A new session is spawned with an independent window	A single subtask	Context loss, distorted result return
Hooks	Triggered at fixed lifecycle points	A single event	Injected content mismatched to the current stage
External context protocols (e.g., MCP)	Queried on demand, at call time	External systems	Oversized results, credential exposure
Permissions and sandbox	Judged before an action executes	All actions	Too loose means overreach; too strict stalls the flow

In one line, their division of labor:

• Resident: project-level rule files;
• On demand: skills;
• Independent: subagents;
• Scheduled: hooks;
• Externally fetched: external context protocols;
• Backstop: permissions and sandbox, which are enforced outside the window and consume no context.

Each is covered below.

4. The Resident Layer: Injecting Project Rule Files and Handling Exceptions

1. How Resident Injection Works

A rule file in the project root (a conventionally named file such as AGENTS.md / CLAUDE.md) enters the window when the session starts, and every subsequent request carries it.

More importantly, look at how it behaves during compaction: compaction does not summarize it along with the conversation history; it is put back into the window verbatim. Mainstream implementations use one of two approaches:

• Re-read from disk and re-inject after compaction;
• Re-insert the original text saved before compaction.

This makes resident rules a “reliably present” source of constraints, well suited to non-negotiable engineering bottom lines, such as:

• Never modify protected directories or generated code directly;
• Run formatting and unit tests before any commit;
• Any public interface change must update the contract documentation in the same change;
• Database migrations must be reversible and rollbackable;
• Logs must never output sensitive fields.

2. The Exception: On-Demand Loading

Not every rule is resident. The following two categories are typically loaded on demand:

• Rule files in subdirectories: loaded only when the agent reads or writes files under the corresponding directory;
• Rules carrying a path declaration (such as a paths: field): take effect only when a matching file path is involved.

During compaction, these are often summarized together with ordinary conversation, and they get reloaded the next time the agent touches a related file. The layout looks like this:

repo/
├── AGENTS.md                 # Root: resident throughout, global bottom lines only
├── docs/
│   └── ARCHITECTURE.md       # Knowledge base: architecture decision records, layering conventions
├── rules/
│   ├── frontend.md           # Has a paths declaration; loaded only when working on frontend files
│   └── database.md           # Has a paths declaration; loaded only when touching migration scripts
├── skills/                   # On-demand skills; enter the window only when a task matches
│   ├── code-review/
│   │   └── SKILL.md
│   └── api-change/
│       └── SKILL.md
└── hooks/
    └── guardrails.json       # Fires at fixed points: validation, formatting, injecting standard snippets

# Header declaration in rules/frontend.md
paths:
  - "web/**"
  - "frontend/**"

3. From “Writing Everything” to “Writing It Right”

A few principles:

1. Layer the placement: global bottom lines go in the root file; module-level details go into subdirectory rules or rules with path declarations;
2. Control the length: keep resident files lean, ideally within the line count the documentation recommends. Move longer background knowledge into the knowledge base and let skills reference it on demand;
3. Prefer stability: resident rules are re-injected as stable text after compaction, so avoid putting volatile information such as “the version number used today” or a “temporary branch name” into them;
4. Make them testable: write key rules as scripts or checks that can be validated from the command line, and have hooks enforce them. Text rules plus machine checks are far more reliable than piling up text.

5. Using the Other Five Capabilities in AI-SDLC

Skills: On-Demand Knowledge Packages for a Task

A skill is essentially a combination of “name + description + body”: during the list phase only the short description is loaded, and the full content is read only after the task matches. That’s why the description is the key to writing a good skill.

---
name: review-change-risk
description: Use when reviewing code change risk; outputs the affected surface, compatibility risks, and regression test suggestions.
---
# Review process
1. Read the diff and list affected modules and public interfaces;
2. Check each layering constraint in docs/ARCHITECTURE.md one by one;
3. Flag potential compatibility issues and propose a minimal regression test set.

A skill packages “the context a certain type of task needs,” and releases it once done, without occupying the window long term.

Subagents: Open a Separate Window for Isolation

A subagent spawns an independent context: it starts from a clean window, sees only the task description and necessary files, and hands its conclusion back to the main session at the end. This brings three benefits:

• Noise isolation: exploratory searching, log analysis, and other “dirty work” happen in the sub-window and don’t pollute the main context;
• Role separation: the review subagent can’t see the development process, and the test subagent sees only the interface contract, so they can’t be “carried along” by each other;
• Window reclamation: intermediate steps are reclaimed along with the sub-session, and only the conclusion stays in the main window.

The key to use is to give clear task boundaries and a delivery format, so you don’t end up in a situation where “30,000 words of raw logs come back.”

Hooks: Inject Content and Run Checks at Fixed Points

Hooks bind to lifecycle points (before a tool call, at session start, before session end) and suit two kinds of work:

• Injection: at the requirements clarification point, automatically attach interface contract snippets and the data dictionary;
• Validation: after a file write, automatically run formatting and static checks, and feed failure messages back to the agent.

External Context Protocols: Pull External Data On Demand

Connecting to ticketing systems, monitoring alerts, and documentation platforms through a standard protocol lets you retrieve data on demand instead of pre-loading whole documents into the window. Two things matter in practice: control the size of each return (paginate, summarize, take only relevant fields), and use least-privilege credentials so sensitive information doesn’t end up in the context.

Permissions and Sandboxes: The Backstop Outside the Window

Permission confirmation and sandbox isolation consume no context, but they define the “safety boundary” of what the agent can do. Recommended to grade by action type:

Action type	Recommended policy
Reading files, searching, read-only queries	Allowed by default
Modifying workspace files	Allowed, but limited to permitted directories
Installing dependencies, running builds and tests	Execute in a container or isolated environment
Production changes, permission changes, data deletion	Require human confirmation, with an audit trail kept

6. Into the R&D Pipeline: Context Orchestration per Stage

Stage	What the window should contain	Capabilities used
Requirements understanding	Requirement description, interface contracts, data dictionary	Hook injection, external protocol retrieval
Architecture design	Architecture decision records, layering constraints	Project rules + knowledge base skills
Implementation	Related module files, that module’s coding rules	On-demand rules, subagent retrieval
Test generation	Interface definitions, test framework conventions	Skills + CLI execution
Code review	The diff, review checklist	Independent review subagent + review skill
Release checks	Release checklist, rollback plan	CLI + hook validation

Two bottom lines running throughout are carried by the project-level rule file, with permissions and sandboxes as the backstop outside the window.

It also makes sense to fold context budget checks into the pipeline. For example, add a lightweight script to the CLI that measures and validates resident files and skill descriptions:

# Count lines in resident rule files; fail if over the threshold
lines=$(wc -l < AGENTS.md)
if [ "$lines" -gt 200 ]; then
  echo "Resident rule file too long: $lines lines; split it into on-demand rules" >&2
  exit 1
fi
# Check skill description length; descriptions over the limit get truncated in the list
find skills -name "SKILL.md" | while read -r f; do
  desc_len=$(sed -n 's/^description: *//p' "$f" | wc -c)
  [ "$desc_len" -gt 1536 ] && echo "Skill description too long: $f" >&2
done

7. Checklist

1. Have you separated “what the framework can do” from “what you must build yourself”? Are the self-built items narrowed down to CLI tooling and the knowledge base?
2. Is the resident rule file lean and limited to global bottom lines?
3. Have module-level details been split into on-demand rule files or skills?
4. Can each skill’s description let the agent judge accurately “when to use it and when not to”?
5. Are exploratory and review tasks handed to independent subagents so they don’t pollute the main context?
6. Do the hooks cover the key validation points and share the same rule set as the pipeline?
7. Do high-risk actions have clear human confirmation and audit records?

8. Conclusion

The ceiling of an agent’s capability is set by the model, but the floor is often set by context engineering. The framework layer has already turned window management, compaction, subagents, and permissions into callable infrastructure. The real focus for an AI-SDLC team is to design clearly “who sends what into the window, and when”: rules resident, skills on demand, subagents isolated, hooks scheduled, protocols fetched externally, permissions as the backstop. With all six capabilities in their place, the window can stay lean, accurate, and predictable at every stage.