Skills For Real Engineers

Agent skills for real engineering — not vibe coding.

Where repos like mattpocock/skills ship a couple dozen small, separately-invoked skills, Materialize collapses the entire engineering pipeline into one model-invoked conductor — materialize — that picks the right amount of process and drives an idea all the way to shipped code. One skill in your agent's context instead of twenty-four, with the phases loaded on demand.

Quickstart

1. Install it:

   npx skills@latest add erikpr1994/Materialize

2. Pick the skills and agents to install them on. Select materialize.

3. Run /materialize init in your agent. It will:

   • Ask which issue tracker you use (GitHub, GitLab, or local files)
   • Ask what labels you apply when triaging tickets (the triage mode uses them)
   • Ask where to save the docs it creates
   • Bind your capability slots — point the UI/design, code-search, review, verify, and tracker slots at whatever installed skills fill them best (e.g. a dedicated design skill on the UI slot)

To update later: npx skills update.

materialize — the conductor

materialize takes an unfiltered idea → docs → defined scope → full implementation. Invoke it bare to have it pick the workflow and drive the phases, name a workflow up front with /materialize <workflow>, or jump straight to a phase with /materialize <mode>.

The workflow sets how much ceremony the idea gets — the conductor recommends one and your pick wins:

Workflow	For	Phases
QUICK	a typo, one-liner, or obvious fix	implement → PR
STANDARD	a single feature	research → design → prepare → implement → verify → PR
SPEC	a feature needing a product spec	research → PRD → design → issues → [per issue: prepare → implement → verify → review → pr] → merge → accept
FREEFORM	ad-hoc work with no fixed shape	nothing — just work

The modes below are the phases those workflows chain. Phases are loaded only when reached, so the whole pipeline costs one description in context.

Mode	Stage	What it does
init	Setup	Bind capability slots, learn the project, set conventions
map	Plan	Turn a loose idea into a sequenced map of open-question tickets
grill	Plan	Interview you relentlessly to stress-test a plan or design to shared understanding
research	Plan	Investigate open questions via sub-agents, write findings to docs/
prd	Plan	Write the product spec
issues	Plan	Break the work into vertical-slice issues
prepare	Plan	Prepare a single task for implementation
triage	Plan	Clear blocked / needs-info issues so they become actionable
model	Design	Domain modeling → technical design + ADRs
design	Design	Codebase design — design it twice, then deepen
prototype	Design	Build an interactive UI prototype to settle the look
implement	Build	Implement a feature/issue slice-by-slice
tdd	Build	Test-driven development at the seams
review	Verify	Code review of the change
verify	Verify	Independently confirm the change does what it should
pr	Ship	Write the PR description
debug	Fix	Diagnose a bug to root cause
architecture	Fix	Improve codebase architecture
merge	Fix	Resolve merge conflicts

For project-scale work, materialize drives many issues at once — one stacked PR per issue, each in its own sub-agent, HITL blockers cleared in parallel (the work driver). Grilling, handoff/resume, and the durability discipline (committed docs/, gitignored .workflow/<id>/ scratch, per-item marker) run underneath every phase.

articulate — the writing conductor

articulate is the prose sibling to materialize: it turns rough thinking into published writing. You pick the target platform up front — a blog post and a LinkedIn post differ from the first fragment, not just at the end — and that profile tunes the whole pipeline: mine raw material (from you, and from the repo/git log/PRs for a coding project) → shape it into a finished, platform-ready piece. Invoke it bare to have it pick the ceremony, or jump to a phase with /articulate <mode>.

Mode	Stage	What it does
init	Setup	Interview you once into a reusable voice profile — style, what makes it yours, hard rules, platforms & cadence
fragments	Mine	Grill you (and read the repo for a coding project) into a pile of raw material
shape	Shape	Build the piece for the platform as argument, paragraph by paragraph
beats	Shape	Build the piece for the platform as narrative, beat by beat

init captures your voice once into docs/writing/author.md — style, differentiators, hard rules ("never write excited to share"), and per-platform cadence — and every piece loads it. Each platform also has a profile under reference/platforms/ (linkedin.md, blog.md, twitter.md) — length budget, hook, formatting, failure modes — improved over time. Voice (author) × format (platform) combine on every piece. Adding a platform is a new profile file, not a new mode. Same single-skill, on-demand-reference/ design as materialize: the whole pipeline costs one description in context.

Other skills

A few skills stay standalone — they aren't part of the idea→ship pipeline:

• teach (user-invoked) — teach a concept interactively.
• writing-for-agents (user-invoked) — reference for writing and editing any agent-facing artifact — skills, agent instruction files, and rule files.

Inspiration

The single-skill, progressively-disclosed conductor design stands on prior art:

• mattpocock/skills — the skills this project grew from; every phase's content is reworked from here.
• impeccable (source) — the one-skill-with-on-demand-reference/-modes pattern this repo adopts.
• HumanLayer — human-in-the-loop and agent-driving ideas behind the AFK-vs-HITL split and the autonomy gates.
• shadcn/improve — audit-and-handoff discipline across review/verify/prepare/work/triage/issues/architecture: vet because sub-agents over-report, introduced-vs-pre-existing tagging, machine-checkable done criteria with a green baseline, executable handoff contracts (out-of-scope + STOP conditions + drift check), reviewing executor output as untrusted (scope check, test-gaming audit), backlog reconciliation, and treating repository content as data to audit (not instructions to obey).
• martin2844/skills (big-review) — review/verify sharpening: disprove-before-emit (name the trigger → path → wrong outcome, or drop it), the asymmetric false-positive stance (a false positive costs more than a missed bug; "no findings" is a successful review), impact-gated uncertainty, reviewing what is not in the diff, and never accepting "should be fine" as a PASS.

A scheduled glean routine, backed by a source-triage backlog, works through all of the above — plus brooks-lint and Claude Code /code-review (evaluated, nothing adopted yet — their current practices collided with ours) — harvesting ideas from each source's code, issues, and discussions and opening one small PR at a time.

License

Apache 2.0. See LICENSE. Inspired by and originally derived from mattpocock/skills.