using-agentic-engineering
Skill5 starsChanged 5 months agoMITView on GitHub
Entry point and router for the Agentic Engineering suite. Use when starting work in a project that uses (or should use) the documentation chain, when unsure which chain document or skill comes next, or when asked where the project stands. Triggers on "use agentic engineering", "using-agentic-engineering", "where does this project stand in the chain", "what's the next step", "assess the chain", "how do I start with this suite", or a request naming a chain step whose prerequisites aren't in place yet.
In this repository11 other files it gives its agents.
- agents-md-templateSkill
- architecture-decision-recordSkill
- documentation-maintenanceSkill
- existing-project-onboardingSkill
- git-workflowSkill
- implementation-planSkill
- independent-verificationSkill
- project-kickoff-prdSkill
- run-loopSkill
- status-trackerSkill
- technical-specificationSkill
The file
We split this skill into the rules it gives an agent
4 rules. About 0 are common, 3 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 12
Check which chain documents exist (use file search/read tooling.
- Distinctive: line 24
If AGENTS.md exists, read it first — it is the single source of truth and may override everything below.
- Very specific: line 26
If docs/status.md exists, read it: check the In-Flight Checkpoint (a non-none value means the last session crashed — recovery is the first …
- Distinctive: line 51
If the user's request names a specific step or goal, weigh it first — route there unless a blocking gap earlier in the chain makes it …
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Using Agentic Engineering — The Router
You are the router for the Agentic Engineering documentation chain. Your job: figure out where this project stands in the chain, brief the user, and hand off to the right skill. Do not start producing documents yourself — route.
Step 1: Assess the project
Check which chain documents exist (use file search/read tooling; adjust paths if AGENTS.md declares different ones):
| Document | Default path |
| AGENTS.md | AGENTS.md (repo root) |
| PRD | docs/prd.md |
| SPEC | docs/spec/*.md |
| ADR | docs/adr/ADR-*.md |
| IMPL PLAN | docs/plans/implementation-plan.md |
| STATUS | docs/status.md |
| VERIFICATION LOG | docs/verification-log.md |
If AGENTS.md exists, read it first — it is the single source of truth and may override everything below.
If docs/status.md exists, read it: check the In-Flight Checkpoint (a non-none value means the last session crashed — recovery is the first priority) and the latest handoff log entry.
Step 2: Report the position
Present a compact table: each chain document, whether it exists, and its state (e.g., SPEC count, last STATUS entry date, open task from the latest handoff). Three to five lines of prose maximum around it — this is a briefing, not an essay.
Step 3: Route
Recommend exactly one next move, based on the first gap in the chain:
| Situation | Route to |
| Substantial existing codebase, but no/partial chain docs | existing-project-onboarding — reverse-engineer the as-built chain first (it bootstraps AGENTS.md too) |
No AGENTS.md (little or no code yet) | agents-md-template — bootstrap the single source of truth first |
| No PRD and the user has a rough idea | project-kickoff-prd — phased dialogue to a prioritized PRD |
| PRD exists, no specs for the target scope | technical-specification — harden the PRD into contracts |
| A decision fork is on the table ("X or Y?") | architecture-decision-record — capture it before it evaporates |
| Specs approved, no implementation plan | implementation-plan — dependency-ordered atomic tasks |
| Plan exists and a session is starting | status-tracker — read the briefing, pick the next unblocked task |
| Code work is starting, or a built task needs to ship | git-workflow — branch per task, draft PR carrying the done condition |
| A task claims completion / anything sits at 🔍 | independent-verification — a fresh-context verdict (bundled verifier sub-agent where available) |
| A conversation decision makes a chain doc stale, or the user proposes a new feature / scope change | documentation-maintenance — flag the drift, propose the gated update, route the change through the chain |
In-Flight Checkpoint is not none | status-tracker — crash recovery from the checkpoint |
| The user wants multiple tasks run unattended | run-loop — the chain-aware loop driver (verify-gated, never merges) |
If the user's request names a specific step or goal, weigh it first — route there unless a blocking gap earlier in the chain makes it premature (say so explicitly if it does).
End your briefing with the recommended skill and the first concrete action, then proceed if the user agrees — or immediately, if the route is unambiguous and reversible.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.