lucas-winter-berlin/Agent-Engineer-Skills
Agent skills for building features and MVPs. Spec, build, review, test - one named job at a time.
Actual rules from this repo
Path in source repo: .cursor/rules/agent-engineer-skills.mdc · format: mdc
---
description: Dispatcher for Agent Engineer Skills. Maps feature-development work to one skill. Use skill: <id> runs only that skill. Lookup is skills/<id>/SKILL.md in this pack, or the host skill folder after install.
alwaysApply: true
---
# Agent Engineer Skills dispatcher
This repo is a collection of skills for developing features. A skill is a structured instruction set and execution contract, not optional style advice.
`Use skill: <id>` always selects that skill and **only** that skill. The **id** is the leaf folder name. Read that skill's `SKILL.md` from the first path that exists: `skills/<id>/SKILL.md` (this pack), else `.cursor/skills/<id>/SKILL.md` (Cursor app install), else `.agents/skills/<id>/SKILL.md` (Antigravity app install). Do not start the next skill unless the user named it. `SKILL.md` is authoritative if this rule and the skill file diverge.
This pack stores each skill once, at `skills/<id>/`. Family (`feature-builder` or `mvp-builder`) is grouping only, not a folder. Do not keep extra copies of the skill folders in this repo.
There is no composer / harness skill in this collection. If the user asks for a harness, end-to-end path runner, or `feature-harness`, do not invent one. Tell them to name each skill they want (`feature-developer`, `feature-code-reviewer`, `feature-refactorer`, `feature-tester`).
## Install
When the user asks to install this pack into an app, follow `README.md` How to install. That is not a skill. Do not start `feature-specifier`.
MUST stop and ask once, before creating the docs folder, where markdown output should live (`what-to-build.md` and the sibling write-ups). Use `AskQuestion` when the host has it:
- Default: keep the **folder** `agent-engineer-skills/` (docs in `agent-engineer-skills/<feature-name>/`)
- Custom: the operator types a repo-relative **folder**; create that directory; files go in `<folder>/<feature-name>/`
Do not skip the question. Do not choose a path for them. Create that path as a **directory** (default name `agent-engineer-skills`). Never write a file named `aes-write-up-root`; if that file exists, delete it. Set the Feature-folder write-ups line in the app's `AGENTS.md` and in the app's copy of this dispatcher to that folder.
## Where SKILL.md lives
| id | Path |
| --- | --- |
| `feature-specifier` | `skills/feature-specifier/SKILL.md` |
| `feature-bug-analyst` | `skills/feature-bug-analyst/SKILL.md` |
| `feature-developer` | `skills/feature-developer/SKILL.md` |
| `feature-code-reviewer` | `skills/feature-code-reviewer/SKILL.md` |
| `feature-refactorer` | `skills/feature-refactorer/SKILL.md` |
| `feature-tester` | `skills/feature-tester/SKILL.md` |
| `mvp-specifier` | `skills/mvp-specifier/SKILL.md` |
Templates live in `assets/` next to that `SKILL.md`. Feature-folder write-ups live under `agent-engineer-skills/<name>/`. After a custom install, the **app** `AGENTS.md` and this dispatcher name that docs folder instead. That path is a directory, not a file.
## Decision mapping
When the user did not name a skill id:
| User intent | Skill |
| --- | --- |
| Vague idea, problem, or feature; spec before code (feature in an existing repo) | `feature-specifier` |
| Defect, crash, wrong output, regression, or flaky failure to analyze before a fix | `feature-bug-analyst` |
| Prototype, MVP, new project, greenfield, or pitch | `mvp-specifier` |
| Implement this specification / this feature folder | `feature-developer` |
| Review this feature folder, or review against `what-to-build.md` | `feature-code-reviewer` |
| Messy existing module / refactor / extract / split, no new product | `feature-refactorer` |
| Test or verify this feature folder against `what-to-build.md` | `feature-tester` |
| Install this pack into an app | Not a skill. Follow README How to install. Ask once for the docs folder. |
If they named one skill, run only that skill. `Use skill: feature-verifier` is the old name for `feature-tester`. `Use skill: pitch-to-spec` is the old name for `mvp-specifier`.
If the specification is missing or the idea is fuzzy: a feature in an existing app is `feature-specifier`; a prototype, MVP, new project, greenfield, or pitch is `mvp-specifier`. A reported defect with expected vs actual (or a stacktrace) is `feature-bug-analyst`, not `feature-specifier`. A generic "I have an idea" in an existing app still maps to `feature-specifier`. If they named implement, review, test, or refactor alone, stop after that skill. `mvp-specifier` must not start `feature-developer` in the same chat. `feature-bug-analyst` must not start `feature-developer` unless the user named it. `feature-refactorer` must not start `feature-code-reviewer` unless the user named it.
## Global contract
1. Follow the steps in that skill's `SKILL.md` in order. Do not skip, merge, or reorder.
2. Instantiate templates from that skill's `assets/` folder. Do not invent alternate structures.
3. Check the finished write-up against that skill's `Before you finish` list, and fix what fails.
4. Stop when the skill says to wait (questions, missing specification, product landmine). `ok` / `lgtm` is not a skip.
5. Capability claims require evidence paths. Unknown tools are `unknown` or `absent`, never implied.
6. No icons or emojis in artifacts.
7. Consuming-project security and secrets policy wins. This framework wins on templates and required write-up content for the named skill. Skill order wins only when the user named the next skill. Code style of the consuming project wins for source.
## Do not
- Chain specifier → developer → reviewer → tester unless the user named each skill.
- Chain bug-analyst → developer unless the user named the next skill.
- Chain `feature-refactorer` → reviewer or tester unless the user named the next skill.
- Run `feature-developer` while the requirement is ambiguous.
- Invent or restore `feature-harness` / a path runner.
- Run `mvp-specifier` for a feature in an existing repo (use `feature-specifier`). Do not start `feature-Content truncated. View full file in the source repo (linked above).
Why this is listed
This repository appears on Cursor Rules Live because it matches the tracker's GitHub Search criteria (cursor-rules) and was active in the recent indexing window. The tracker refreshes every 15 minutes, so the metadata above reflects the state at the most recent index pass. If the data here looks stale, the source repository may have been archived or moved out of the tracked topic; the next cron tick will reconcile.