agentic-engineering
- Use it when:
- Agents will do most of a piece of engineering work end to end, while humans keep control of quality and risk.
- It does:
- Has the agent set done criteria and evals first, split work into 15-minute verifiable units, and pick Haiku, Sonnet or Opus by task.
- You get:
- Work checked against evals before and after, with model, token estimate, retries, time and outcome tracked per task.
- Also covers:
- When to continue, restart or compact a session, what to review in AI-written code, and how to read tool results before trusting them.
TL;DR
A short operating guide from ECC for agent-driven engineering. Before any work, the agent defines what done means, writes a capability eval and a regression eval, runs a baseline, implements, then reruns them and compares. Work is cut into units of about 15 minutes, each verifiable on its own, with one main risk and a clear done condition. Model choice follows the task: Haiku for classification, boilerplate and narrow edits, Sonnet for implementation and refactors, Opus for architecture, root-cause analysis and invariants across files, moving up a tier only when a lower one shows a clear reasoning gap. Sessions continue for closely coupled units, start fresh after major phases, and compact after milestones rather than mid-debugging. Reviews of AI-written code focus on invariants, edge cases, error boundaries, auth assumptions and hidden coupling, not style. A longer section teaches reading a tool's result in order, transport error, then operation status, then document shape, so a failed read is never mistaken for a data mismatch and a write with an unknown outcome is never blindly retried.
Summarizes the skill at d2ef268.
npx skills add https://github.com/affaan-m/ecc --skill agentic-engineering skills.sh pageSource on GitHubAll skills from affaan-m/ecc
- Total Downloads
- 5,700 on skills.sh, Nov 9, 2026
- Repo stars
- 299,776 affaan-m/ecc
- First seen
- May 19, 2026 on skills.sh
Weekly values
| Week to | Installs |
|---|---|
| Sep 21 | 275 |
| Sep 28 | 168 |
| Oct 5 | 168 |
| Oct 12 | 256 |
| Oct 19 | 426 |
| Oct 26 | 422 |
| Nov 2 | 498 |
| Nov 9 | 456 |
| Category |
Build agents, orchestrate workers and give agents memory. Test-first work, implementation from specs, git hygiene and scope control. Everything for building software: planning, coding, debugging, design, frameworks, cloud, agents and skills. |
|---|---|
| Type |
Knowledge and rules the agent applies while it works: best practices, design principles, API references. |
| Effect |
Adds no side effects of its own. It shapes how the agent thinks, writes or reviews. Guidelines and routers are always effect:none, even when the task they support edits code. |
| Needs |
Instructions only. Works in any agent that supports skills. |
| Publisher |
Everyone else. Unverified vendor claims default to community. |
| Topics | |
| Stack |
SKILL.md
From affaan-m/ecc at d2ef268. Checked daily, last changed Nov 6, 2026.
Frontmatter
name: agentic-engineering
description: Operate as an agentic engineer using eval-first execution, decomposition, and cost-aware model routing. Use when planning or executing engineering work that agents will carry out end to end.
metadata:
origin: ECCAgentic Engineering
Use this skill for engineering workflows where AI agents perform most implementation work and humans enforce quality and risk controls.
Operating Principles
- Define completion criteria before execution.
- Decompose work into agent-sized units.
- Route model tiers by task complexity.
- Measure with evals and regression checks.
Eval-First Loop
- Define capability eval and regression eval.
- Run baseline and capture failure signatures.
- Execute implementation.
- Re-run evals and compare deltas.
Task Decomposition
Apply the 15-minute unit rule:
- each unit should be independently verifiable
- each unit should have a single dominant risk
- each unit should expose a clear done condition
Model Routing
- Haiku: classification, boilerplate transforms, narrow edits
- Sonnet: implementation and refactors
- Opus: architecture, root-cause analysis, multi-file invariants
Session Strategy
- Continue session for closely-coupled units.
- Start fresh session after major phase transitions.
- Compact after milestone completion, not during active debugging.
Review Focus for AI-Generated Code
Prioritize:
- invariants and edge cases
- error boundaries
- security and auth assumptions
- hidden coupling and rollout risk
Do not waste review cycles on style-only disagreements when automated format/lint already enforce style.
Interpret Tool Results Before Comparing Data
For document reads and processing loops, check three boundaries in order:
- Check the tool/transport envelope for an error or an indeterminate outcome.
- Decode the response and check operation status using that tool's documented
contract. An outer success flag or a present payload does not establish that
the requested operation succeeded. Status may live in structured content,
decoded text, or another documented field;
result.okis not a universal MCP field. Missing or unrecognized status stays unknown. - Only after confirmed operation success, validate the document shape and compare its fields. An operation failure is not a document identity mismatch.
Keep the operation name, request/correlation ID when available, relevant status and error details, and the original response needed for diagnosis. Redact secrets and private document data before logging or sharing. Do not reconstruct missing responses from a later response's shape.
Portable Classification Example
The adapter below uses an illustrative read-tool contract, not an MCP schema:
isError is a required boolean; when false, result.ok is a required operation
status. A successful read returns result.document with a string id; a failed
read may carry result.error. Replace this adapter with the actual tool's
contract, including its documented decoding and document validation rules.
function decodeRead(response) {
if (!response || typeof response.isError !== 'boolean') {
return { kind: 'unknown_response' };
}
if (response.isError) return { kind: 'tool_error' };
const result = response.result;
if (result?.ok === false) {
return { kind: 'operation_error', error: result.error };
}
if (result?.ok !== true) return { kind: 'unknown_response' };
const document = result.document;
if (!document || typeof document.id !== 'string') {
return { kind: 'invalid_document' };
}
return { kind: 'document', document };
}
function inspectRead(response, expectedId, decode = decodeRead) {
const outcome = decode(response);
if (outcome.kind !== 'document') return outcome;
return outcome.document.id === expectedId
? { kind: 'match', document: outcome.document }
: { kind: 'field_mismatch', actualId: outcome.document.id, expectedId };
}
Synthetic evaluation cases (not a reproduction of any historical incident):
| Input under this illustrative contract | Expected classification |
|---|---|
isError: true |
tool_error; no field comparison |
isError: false, result.ok: false, maintenance error, no document |
operation_error; preserve maintenance details, no mismatch |
isError: false, missing operation status |
unknown_response; no field comparison |
| Confirmed success, missing document or non-string ID | invalid_document; no field comparison |
| Confirmed success, valid document with expected ID | match |
| Confirmed success, valid document with a different ID | field_mismatch |
Classification does not authorize a write or retry. Temporary maintenance remains an operation failure with its own evidence; follow the tool's documented recovery policy. A documented service-wide maintenance failure should stop a batch rather than trigger the same request for every row; a lone authorization error does not establish service-wide maintenance. If a write times out or its outcome is unknown, preserve that uncertainty and reconcile using a documented status/read-back mechanism before considering a retry. Never infer that a write failed, repeat it, or overwrite a document solely because a read failed or a returned field differs.
Cost Discipline
Track per task:
- model
- token estimate
- retries
- wall-clock time
- success/failure
Escalate model tier only when lower tier fails with a clear reasoning gap.