Harness Operating System
The operating baseline that makes AI-assisted engineering repeatable
Harness Intelligence is the shared operating baseline for AI-assisted engineering at Devpunks.
A harnessed repository has more than code and package scripts. It has prompt surfaces, scoped guidance, workflow skills, validation gates, required tools, wiki memory, scaffold manifests, update mechanics, and feedback loops.
The operating system exists because agent work otherwise becomes private craft. One engineer may have a careful local setup, strong prompts, source inspection habits, browser validation, and review discipline. Another may only have a chat box. The harness narrows that spread by making the workflow inspectable and repeatable inside the repository.
Repeatable operating surfaces make agent work reviewable because they turn a run into a visible sequence: guidance loaded, skill contract chosen, evidence inspected, edits made, checks run, artifacts updated, blockers recorded. Review can then inspect the model of work instead of trusting the transcript or the final diff alone.
Boundary
Harness pages own the methodology:
- how an agent receives context
- which prompts and scoped guidance apply
- which skills shape the lifecycle
- which validation gates prove completion
- how durable wiki and docs knowledge is updated
- how feedback from real repositories improves the baseline
The CLI domain owns punks / dp mechanics: command behavior, scaffold manifests, baseline resolution, local filesystem writes, update ergonomics, and tool installation. Harness pages link to CLI mechanics when the reader needs command details.
Future backend and backoffice surfaces own registry, provenance, telemetry ingestion, reports, authenticated artifact access, and internal adoption visibility. They do not perform local repo mutation. The CLI remains the local executor.
Operating Surfaces
Harness Intelligence is assembled from several surfaces that reinforce one another:
- Prompt surfaces: global behavior, project policy, scoped
AGENTS.md, memory notes, and hook guidance. - Skills: reusable contracts for requirements, planning, delivery, review, debugging, docs ingest, debt resolution, framework work, and quality work.
- Packs: curated groups of skills, hooks, tools, prompt surfaces, and scaffold assets selected from repo facts.
- Validation gates: tests, typecheck, builds, browser checks, runtime evidence, review, manual checklists, and docs closeout.
- Required tools:
skills,opensrc,agent-browser,portless, and selected pack tools. - Wiki and docs: routed private wiki pages for durable product and methodology knowledge, plus root docs for setup, workflow, runbooks, and implementation reference.
- Distribution and feedback: scaffold baselines, update checks, manifests, reports, and future backoffice loops.
Lifecycle Shape
The adoption path is intentionally ordinary. dp scaffold init starts the requirements and wiki path. dp scaffold setup performs repo-aware setup once the repository shape exists. Day-to-day work then moves through entrypoint-driven manual skills or AFK phase wrappers, depending on the task and the operator's chosen mode.
The CLI handles distribution. The methodology decides why each asset exists and how work moves from unclear intent to validated closeout.
For setup details, start with Basic Usage and the CLI Domain. For supported work, start with Harness Entry Points, then choose the page that matches the current job.
Done Signal
A harness run is done when the requested scope is implemented or honestly blocked, the relevant checks produced evidence, review has no unresolved blocking finding, docs ingest was handled when durable knowledge changed, and follow-up reports or backlog updates are synchronized when they are in scope.
The operating system gives the team artifacts that show how care was applied: the chosen workflow, the evidence behind decisions, the validation result, and the durable record that future work can reuse.