# Eng

> >

- **Type:** Skill
- **Install:** `agentstack add skill-ndisisnd-msg-eng`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [ndisisnd](https://agentstack.voostack.com/s/ndisisnd)
- **Installs:** 0
- **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [ndisisnd](https://github.com/ndisisnd)
- **Source:** https://github.com/ndisisnd/msg/tree/main/.claude/skills/eng

## Install

```sh
agentstack add skill-ndisisnd-msg-eng
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# eng

Platform-agnostic engineering agent with two modes — `--plan`, `--build` — each a distinct protocol in its own ref file, selected by the invocation flag. This file is the shared spine: it routes to the active mode but never runs a mode's work itself.

---

## Step 0 — Route to the active mode

Read the invocation flag and load exactly one mode protocol:

| Flag | Read |
|------|------|
| `--plan` | `refs/plan/protocol.md` |
| `--plan report=` | `refs/plan/report-fix.md` (instead of `protocol.md`) |
| `--build` | `refs/build/protocol.md` |
| `--build report=` | `refs/build/report-fix.md` (instead of `protocol.md`) |
| `--build roadmap=` | `refs/build/protocol-roadmap.md` (instead of `protocol.md`) |

Exactly one mode flag must be present (`--plan` | `--build`). If zero or more than one is given, emit:

```
Hard failure: exactly one mode flag required (--plan | --build). Got: .
```

Stop.

**`--todo` is no longer a mode.** Todos are now written by `eng --plan` in the same pass as the engineering section — there is no separate todo wave. An invocation carrying `--todo` hard-fails:

```
Hard failure: --todo is no longer a mode — todos are written by `eng --plan` in the same pass. Re-run with --plan.
```

Stop. `roadmap=` (a `--build`-only field) loads `refs/build/protocol-roadmap.md` **instead of** `refs/build/protocol.md`: it turns this session into an autonomous **product-operations orchestrator** executing a whole `roadmap/roadmap.md` phase-by-phase, spawning `eng`/`pre-merge` subagents (pre-merge is the single CI gate — it absorbed `/review` + `/test`).

Otherwise read the active mode file **fully** first — it defines the mode-specific input rules, summary content, work steps, and output contract. The numbered steps below are the shared spine; they run for every mode and point to the active mode file where the path diverges.

---

## Step 1 — Input validation

Three input sources. The **PRD/exec-table source** is the default for every mode; **`report`** is an alternate available on both modes, and **`roadmap`** is a `--build`-only alternate.

### PRD/exec-table source (all modes)

Requires four fields. Hard-refuse if any is missing:

| Field | Value |
|-------|-------|
| mode flag | `--plan` or `--build` |
| `prd-path` | Path to the PRD `.md` file containing the execution table |
| `rows` | Semicolon-separated exec-table Feature identifiers for this invocation — each the exact `:  — ` text of a Feature cell (e.g. `F2: Track streak — Schema migration`) |
| `agent` | This invocation's agent identity (e.g. `eng-backend`) — the exec-table **Agent** column value for the assigned rows; names the `## Engineering — ` heading and confirms row ownership. |

If any field is missing, emit:

```
Hard failure: missing required field(s): . Provide the mode flag, prd-path, rows, and agent to continue.
```

Stop. The active mode file may add mode-specific input rules — apply those too.

### Alternate sources

- **`report=`** — build or plan from a failed run's issues file (`report-prd--.json`) instead of an exec-table. On `--build`, required fields, rejections, path-validity failures, and the finding→issue-ticket projection live in `refs/build/report-fix.md`. On `--plan`, the same source plans the fix tickets for the issues file's findings — required fields, rejections, and the fix-plan output contract live in `refs/plan/report-fix.md`.
- **`roadmap=`** — `--build` only: hand the whole roadmap to the orchestrator (`refs/build/protocol-roadmap.md`), which derives per-PRD fields for each leaf subagent. Required fields and rejections live in that file.

`--plan` accepts `report` but rejects `roadmap`; passing more than one input source is a hard failure (ambiguous source) — exact messages in the mode refs.

---

## Step 2 — Pre-flight: read everything in one pass

Before any output, read the spec, devkit, and relevant codebase files in one consolidated scan.

**Orchestrated fast path (scoped context injected).** When an orchestrator (`plan-em` or the roadmap orchestrator) has injected **scoped excerpts** — the assigned rows, the relevant PRD feature sections, and a devkit **digest** — work from those directly; do **not** re-read the full PRD or every devkit file. The PRD path is always supplied as an **escape hatch**: read the full PRD (or a specific devkit file) on demand only when an excerpt is insufficient to resolve a row.

**Standalone path (default when nothing is injected).** Read the full PRD at `prd-path`, locate the Execution Table, and select rows whose **Feature** column text exactly matches one of the assigned `rows`. A `rows` identifier matching no Feature cell, or a matched row whose **Agent** column differs from the `agent` field, is a hard failure — emit it and stop. On the `report` source there is no exec-table, no `rows`, and no ownership to confirm — read the file and project its `issues[]` per `refs/build/report-fix.md`.

**Devkit files** (read in parallel with the PRD, unless a digest was injected): `devkit/AHA.md` (past learnings relevant to the rows), `devkit/GLOSSARY.md` (canonical terms; flag PRD deviations), `CLAUDE.md` at project root (tech-stack constraints on every file-path/approach decision), `devkit/ARCHITECTURE.md` (validate scope against system layers; flag conflicts as gaps), `devkit/DESIGN-SYSTEM.md` (reusable components). If `devkit/` does not exist, emit a single warning and continue; a missing individual file is a per-file warning, then continue.

**Codebase scan** (in parallel): read files relevant to the assigned rows, matched by concern type (schema migration → migrations/schema; API contract → handlers, routes, OpenAPI; client mobile/web → screens/pages, components, services/clients; tests → existing test files; webhook → event emitters, queue handlers). For each, determine **Modify** (exists) or **Create** (does not), and note naming conventions, patterns, and constraints — they constrain the output. Eng derives all implementation paths from this scan and the spec; `report`'s `issues[].file` marks where a *symptom* was observed, not a path to blindly edit.

Complete pre-flight before Step 3; emit no output during it.

---

## Step 3 — Pre-run (1 of 2): Summary + approval gate

Emit a **short summary** (3–4 lines max) — content per the active mode file's "Summary content" section — then ask:

```
AskUserQuestion:
  "Does this summary look right?"
  Options:
    - Yes, proceed
    - No, needs correction
    - I have a follow-up question
```

- **Yes, proceed:** continue to Step 4.
- **No, needs correction:** rewrite the summary once with the correction and re-ask; if still rejected, stop and ask the user to clarify scope.
- **I have a follow-up question:** enter the interview (Step 3a), then re-present the summary.

Never proceed to Step 4 without an explicit "Yes, proceed." *(Under an autonomy contract — e.g. an orchestrator running hands-off — treat this gate as pre-approved and proceed.)*

### Step 3a — User interview (on demand)

Ask up to 3 focused questions, one at a time — each naming the specific row or PRD section it concerns, with 3–4 concrete `AskUserQuestion` options (never open-ended). If more than 3 ambiguities exist, list them and ask which to prioritise. Then resume where the protocol paused — do not restart.

---

## Step 4 — Pre-run (2 of 2): Coding standards

Coding standards come from `/cook`, pulled via **explicit flags** (never a prose summary) so the call is cacheable and the P0 floor always loads. **Runs on `--build` only:** `--plan` does not call `/cook` — its design doc + todo tickets are grounded in the `CLAUDE.md` + `devkit/ARCHITECTURE.md` stack constraints read in Step 2; standards are pulled later, at build time. On `--build`, resolve standards one of two ways:

- **Orchestrated (payload injected):** when the prompt carries a **`standards payload`** section (an orchestrator compiled it once for this stack and injected it), use it and **do not call `/cook`**. Default on orchestrated runs.
- **Standalone (call cook yourself):** when no payload is injected, call `/cook` once with explicit flags — stack→flag table in `refs/build/protocol.md`. Always include `--global` (guarantees the P0 floor + 8 concern refs); an identical flag set repeats as a cook cache hit. Read fully; surface any uncovered stack as a named gap in the build summary.

---

## Step 5 — Run the active mode's work and emit output

Follow the work steps and output contract in the active mode file, where the modes diverge:

- `--plan` → in one pass, append the `## Engineering — ` section, fill the Execution steps + Files columns, and write the `## Todos — ` tickets that decompose each owned F-ID (no implementation code written; inline snippets/pseudocode encouraged).
- `--build` → write code to derived paths; emit a build summary.

---

## Step 6 — Scope enforcement (continuous)

Throughout Steps 2–5, enforce strict scope: act only on what the assigned exec-table rows specify; make no additional refactors, unrelated file touches, or out-of-scope changes. A row that cannot be resolved from the PRD, exec-table, or codebase scan → surface it as a named gap (plan / review) or block and ask (build). Never resolve ambiguity by assumption.

---

## References

- `refs/plan/protocol.md` — `--plan`: summary content, output contract, exact-identifier rule, **and the `## Todos — ` ticket-writing spec** run in the same pass. `refs/plan/template-todo.md` — the ticket schema (`F-T` ids, the seven fields, rendering, rules, empty-block sentinel, the ticket-sizing rule) that `--build` reads mechanically. `refs/plan/template-eng-plan.md` — §1–13 output format.
- `refs/plan/report-fix.md` — `--plan`'s `report` source: required fields, rejections, and the fix-plan output contract for planning the fixes to a failed run's issues file.
- `refs/build/protocol.md` — `--build`: branch contract, `report` source, coding-standards flag table, work steps, per-ticket pair review, commit/PR contract. `refs/build/protocol-exec.md` — Execution-steps column format. `refs/build/report-fix.md` — `report` source + the finding→issue-ticket projection and `kind` discriminator.
- `refs/build/pair-review.md` — per-ticket pair-review subagent: platform-parameterised principal-engineer persona, unnecessary-code-only mandate, one-revision-round blocking contract (loaded on the build hot path).
- `refs/build/protocol-roadmap.md` — `--build roadmap=` orchestrator: executes `roadmap/roadmap.md` phase-by-phase, spawning subagents and injecting per-stack standards.
- `.claude/scripts/eng-db-touch.sh` — production/data guardrail; the orchestrator pauses for sign-off when it trips.
- `.claude/scripts/eng-comment-scan.sh` — deterministic A4 comment scan; flags added symbol declarations with no plain-English comment above them (`--staged` or a diff range).
- `.claude/scripts/eng-commit-cap.sh` — A5 commit-size measurement on the staged diff (>500 changed LOC, >300 with `--breaking`) — advisory: always exits 0, prints `CAP_OK`/`CAP_EXCEEDED` for the agent to judge split-or-commit; `--oversize-reason` records the justification when committing over-cap anyway.
- **Contract:** the `## Engineering — ` and `## Todos — ` headings written by `--plan` (same pass) are how `plan-em` detects the section is ready and how `--build` locates its spec. Do not rename them.

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [ndisisnd](https://github.com/ndisisnd)
- **Source:** [ndisisnd/msg](https://github.com/ndisisnd/msg)
- **License:** MIT

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-ndisisnd-msg-eng
- Seller: https://agentstack.voostack.com/s/ndisisnd
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.