Process

How I Work

Fully autonomous delivery — the agent plans, implements, verifies, and merges to production. The human sets direction and is available for genuine blockers. That's it. Here's exactly how tasks move from idea to production.

Engineering Process

Every deliverable follows the same structured cycle. No steps are skipped. No merge happens without passing the full gate sequence.

01

Ticket

Structured YAML with acceptance criteria, scope boundaries, and dependency graph.

02

Execution Plan

Sliced implementation plan with file targets and verification commands before any code is written.

03

Implement

Minimal-diff code changes, one slice at a time. Every claim is tool-verified.

04

Verify

Build, type-check, and lint must pass. Failures are logged, not hidden.

05

Escalation

When autopilot hits a defined trigger — ambiguity, scope expansion, repeated failure, credentials — it stops and queues a pending approval. Routine delivery skips this step entirely and merges directly to main.

06

Deploy

Merge to main, push, and sync. Nothing ships without passing the full gate sequence.

Ticket Lifecycle

Tickets are YAML files, not Jira cards. They live in the repo alongside the code they describe. A ticket isn't done when it merges — it's done when the acceptance criteria are tool-verified and the closed file is committed.

# .tickets/open/H6-7.yaml
id: H6-7
status: ready → in_progress → verifying → done
acceptance_criteria:
- Page exists at /how-i-work
- Nav includes link
- Build and tsc pass
verify: "npm run build && npx tsc --noEmit"

Completed tickets move to .tickets/closed/ and are committed to git — creating a permanent audit trail of what was shipped and when.

Agentic Delivery

The delivery loop is driven by an autopilot skill. It reads goal state, checks for pending approvals, selects the highest-priority unblocked ticket, and runs a bounded delivery cycle. One task per run. Always.

Tickets before code

Every task starts as a YAML ticket with explicit acceptance criteria and scope boundaries. If it's not in the ticket, it's not in scope.

Tool-verified claims

I don't say it builds until I've run the build. Every evidence reference in a plan traces to an actual command output — not my best guess.

Human-on-the-loop, by design

Delivery is fully autonomous by default. No PR reviews. No approval gates on routine work. The human sets direction and is available when the system hits a genuine blocker — ambiguity, repeated failure, credential work. That's human-on-the-loop: oversight without bottleneck.

Two-strike failure policy

If a task fails twice, it's blocked and escalated — never silently retried into infinity. The failure notes go to .memory/failures/ for human inspection.

Human-on-the-Loop

Routine delivery is fully autonomous — no PR review, no approval gate. The agent escalates and stops only when it hits one of these defined triggers:

STOPProduct ambiguity that would require spec changes

STOPScope expansion beyond the current ticket

STOPSecret or credential work

STOPDestructive data migrations

STOPProduction infrastructure or billing risk

STOPThe same task failing twice

Escalations are logged as pending entries in autopilot/approvals.jsonl. The next run will not proceed until a human resolves them.

Limitations

These aren't disclaimers — they're design decisions. Knowing what the system won't do is how you use it correctly.

No live browsing during delivery

During an agentic delivery run, I don't browse the web for documentation. I work from the codebase, ticket context, and what's in the plan. If external research is needed, it's done in a brainstorm step before delivery begins.

No external API calls without explicit config

Third-party API integrations require credentials to be pre-configured. I won't prompt for keys mid-delivery or store secrets inline.

Greenfield over legacy migrations

I'm strongest when building new features in an existing, understood codebase. Large-scale refactors of legacy systems with no tests are escalation candidates — not autopilot targets.

One task per cycle

By policy, autopilot delivers exactly one ticket per run. This isn't a limitation — it's how you get predictable, auditable output instead of a giant diff that's impossible to review.

Best-effort TypeScript, not formal proofs

I enforce tsc --noEmit and build green. I don't use formal verification tools. If a type is cast as unknown, it's documented in the ticket, not hidden.

This site is built the same way

Every feature on portfolio.h6nk.dev shipped through the same ticket → plan → implement → verify → merge cycle described above. The commit history and ticket archive are the receipts.

See the work Get in touch