Engineer

🟢 Required

Use this when: You're an engineer at Artium and want to understand your role in the iteration cycle — or when you're a PM or designer wanting to understand what engineers need from you.

The engineer's job

Engineers own the how. They pair, TDD, and ship working software every iteration.

You estimate and build stories, pair with other engineers, write tests first, maintain CI/CD, participate in all ceremonies, and demo what you built. Your job is to turn clear acceptance criteria into working, tested, deployed software — and to push back when criteria aren't clear enough to build from.

Core responsibilities

Estimate and build stories. Understand the AC before estimating. If you can't explain what a story requires, it's not refined enough.
Pair with other engineers. Pairing is the default. Solo work requires justification. See Pairing Guide.
Write tests first (TDD). Red-green-refactor. The acceptance criteria in the story IS the test spec.
Maintain CI/CD. If the build is broken, fix it before starting new work.
Participate in all ceremonies. IPM, standup, demo, retro. These aren't PM meetings — they're team meetings.
Demo what you built. The builder presents, not the PM. Own your work.

What engineers do NOT do

Work solo by default. Solo is the exception, not the rule. If you're always solo, raise it in retro.
Skip tests. Untested code is unfinished code. TDD isn't optional.
Estimate without understanding AC. If the acceptance criteria are vague, push back. Don't guess.
Accept vague stories without pushing back. The PM writes stories, but you have a responsibility to ask "what about...?" before committing.

Weekly rhythm

Day	Engineer focus
Monday	Review candidate stories before IPM. Estimate and commit. Pair up. Start building.
Tue–Thu	Pair, TDD, ship. Ask the PM when AC is unclear. Flag blockers in standup.
Friday AM	Prepare to demo your work. Verify demo environment (staging, not localhost).
Friday PM	Demo what you built. Participate in retro.

For the full day-by-day breakdown, see Weekly Iteration Rhythm.

What engineers need from PMs

Stories with clear Gherkin AC. Each scenario should translate to a test. If it doesn't, ask the PM to clarify. See Story Writing Standards.
Fast answers to clarifying questions. If you're blocked on a product question, the PM should be available within the hour — not the day.
No mid-story scope changes without negotiation. If the PM discovers a new requirement after you've started building, that's a new story or a re-estimate — not a silent scope expansion.
Realistic commitments based on velocity. The PM commits the team based on historical velocity, not wishful thinking.

See PM role guide for the PM's full responsibilities.

What engineers need from designers

Design specs before build starts. If a story has a UI component, the design should be ready before the story enters the iteration. If it's not, flag it in IPM.
Availability during build for questions. When you're implementing a design, the designer should be reachable for quick clarifications — not in a day-long design sprint elsewhere.
Clear indication of must-have vs. nice-to-have. Which details are essential to the experience and which are polish for a later pass?

See Designer role guide for the designer's full responsibilities.

TDD at Artium

Write the failing test first. Make it pass. Refactor.

The acceptance criteria in the story are your test spec. Each Gherkin scenario maps to at least one test. If the AC is vague, push back before building — not after.

1. Read the acceptance criteria
2. Write a failing test for the first scenario
3. Write the minimum code to make it pass
4. Refactor (improve structure without changing behavior)
5. Repeat for the next scenario

TDD isn't about coverage percentages. It's about building confidence that the code does what the story says it should do.

Pairing

Pairing is the default working mode at Artium, not an occasional practice.

Rotate pairs every 2–3 days or per story. Track rotations in standup.
Driver/navigator is the default style. The driver writes code, the navigator reviews in real time.
Ping-pong for TDD: one person writes the test, the other makes it pass.
Strong-style for onboarding: the expert navigates, the newcomer drives.

For the full pairing methodology, see Pairing Guide.

AI workflows: agentic coding

AI tools (Cursor, Copilot, Claude Code) follow the same human-agent model as Skillet: the agent drives execution, the engineer navigates.

Task	AI tool role	Engineer role
Generate test stubs from Gherkin AC	Draft test structure and assertions	Review for correctness, add edge cases
Implement to pass tests	Write candidate implementation	Verify it actually passes, check for shortcuts
Refactor	Suggest structural improvements	Decide which refactors improve clarity vs. add complexity
Code review	Flag patterns, suggest improvements	Apply judgment — not every suggestion is an improvement
Boilerplate and scaffolding	Generate repetitive structure	Customize for your project's conventions

Human reviews all agent output. AI-generated code can be subtly wrong — it compiles, it looks right, but it misses edge cases or violates project conventions. Review it the same way you'd review a junior engineer's PR.

For AI concepts, see AI Foundations.

How engineers interact with Skillet

Engineers don't typically run PM skills, but understanding Skillet output helps you participate effectively:

/story-write output is the story format you'll build from. Know the structure — title, description, Gherkin AC, technical details, out of scope.
/ipm-plan output includes pair assignments and candidate stories. Review candidates before IPM so you can estimate informed.
/demo-prep output assigns presenters. The builder demos — prepare to show your work, not just describe it.
/retro-synthesize output captures team action items. Own your assigned items.

Anti-patterns

Anti-pattern	Why it fails	Fix
Solo heroics	Knowledge silos, bus factor of 1, no review. Bugs ship.	Pair by default. Solo requires justification.
Skipping tests	"I'll add tests later" means no tests. Regressions accumulate.	TDD. Write the test first. No exceptions.
Gold-plating	Building features nobody asked for. Scope creeps, iteration commitments break.	Build what the AC says. Nothing more. Raise ideas for future stories.
Ignoring AC	Building what you think is right instead of what the story specifies.	AC is the contract. If you disagree, discuss with the PM before building, not after.
Not rotating pairs	Same pair every day. Knowledge stays siloed. One person dominates.	Rotate every 2–3 days. Track in standup.

How to prepare

New to engineering at Artium:

Read Pairing Guide — pairing is how Artium engineers work
Read Story Writing Standards — understand the format you'll build from
Understand Balanced Teams — your role is one of three equals

Adopting AI coding tools:

Read Human-Agent Pairing — same model applies to agentic coding
Read AI Foundations for concepts and limitations
Start with test generation from Gherkin AC — it's the lowest-risk, highest-value use case