core-engineering

Files (1)

• SKILL.md

SKILL.md (first lines)

# Skill: core-engineering

## Purpose

Apply the default engineering workflow for production-grade implementation work.

## Core Rules

- Verify before acting.
- Prefer the smallest correct change.
- Preserve public contracts unless explicitly asked to change them.
- Match existing project style.
- Do not introduce unrelated refactors.
- Do not invent files, APIs, schemas, commands, or test results.
- Do not use placeholders as implementation.
- Do not leave dead code.
- Do not hide uncertainty.

## Workflow

### 1. Understand

Identify:

- requested behavior;
- expected output;
- constraints;
- ambiguous points;
- relevant domain boundaries.

If ambiguity blocks correctness, ask one precise question.

If ambiguity is manageable, proceed with an explicit assumption.

### 2. Inspect

Before writing code, inspect:

- relevant files;
- nearby related code;
- project config;
- tests;
- existing patterns;
- validation commands.

### 3. Plan

Create a concise plan:

- target files;
- intended changes;
- expected behavior;
- validation method;
- risks/assumptions.

For small tasks, one short paragraph is enough. The plan is a tool, not a paperwork shrine.

### 4. Implement

Implement in small focused slices.

Rules:

- one concern per change;
- explicit control flow;
- explicit error handling;
- no hidden global state;
- no unrelated formatting churn;
- no new dependencies unless justified.

### Tooling Defaults

Use the strongest relevant local tool when it is available:

- `rg` and `rg --files` before slower text or file search;
- `fd` for file discovery when it improves the search;
- `ast-grep` or `tree-sitter` for syntax-aware search and safe mechanical rewrites;
- `jq` or `yq` for structured JSON/YAML inspection and transformation;
- `just` when a `justfile` owns project commands;
- `delta` for local diff review when useful;
- `fzf` only for interactive narrowing, not as a required automation dependency.

If the preferred tool is unavailable, use the best fallback and name the gap
only when it materially affects confidence or reproducibility.

### Context Tooling Tiers

Use the same question-based routing as the steady global prompt, when the
current host exposes the relevant capability:

| Need | First route |
| --- | --- |
| Local edit or literal | `rg`, path filters, and targeted reads |
| Definitions and references | Serena's LSP-backed symbol navigation |
| Architecture and impact | Graphify, with fresh source verification |
| Documentation and ADRs | QMD over allowed roots; `wiki-query` for read-only wiki questions |
| External library documentation | Context7 for the installed library version |
| Dependency source | opensrc for the exact dependency revision |
| Worker handoff | `context-pack`; Repomix when an export is useful |

Do not run every search tool for each task. Keep path filters and bounded
excerpts. A package installation does not prove host availability. If a route
is unavailable, use targeted local evidence and report the material gap.
Repomix is an export, not a live code index.

### Project Context Bootstrap

Before broad reads or repeated cross-file exploration, do a cheap state check:

- Serena: `.serena/project.yml` plus any exposed Serena MCP/symbol tools;
- Graphify: `graphify-out/graph.json`;
- Repomix/context pack: existing requested pack path;
- output compressors: command availability and raw-output location.

Use the result as a decision gate:

- localized task -> use `rg`, symbol lookup, and targeted reads;
- existing Serena, Graphify, or QMD state -> compare its source revision and
  file hashes with the required scope, including uncommitted changes, before

From Mesteriis/Engineering-Bible-AI, MIT.

More from Mesteriis/Engineering-Bible-AI