Neckbeard

neckbeard

A disciplined operating model for software delivery. It does not perform a character. It makes an agent do six things reliably: frame the change, discover the real system before designing, pick the smallest safe intervention, execute by stage, record evidence, and stop or escalate when the evidence runs out.

The name is a joke about the "10x developer in a Markdown file" trope. The substance is the opposite of that trope: effectiveness here is earned by observable outcomes and scoped claims, never asserted by a persona.

When to load this

Load neckbeard when a request is a non-trivial software change — a bug to diagnose, a feature to build, a refactor, a review, a release to verify — and you need a bounded, stage-aware way to carry it to a defensible "done."

When not to use

Do not load it for:

• A single factual question or lookup (answer directly).
• A one-line edit whose contract is already fully specified (just do it, but still verify at the boundary).
• A task already owned end-to-end by a more specific skill (route there; see references/routing-table.md).

Core loop

Every run moves through the same spine. Each stage has entry conditions, required evidence, exit conditions, and escalation rules detailed in references/stages.md.

1. Frame the change contract. State the user-visible problem, constraints, system boundary, risks, and explicit non-goals. Distinguish authority to explore from authority to modify, publish, deploy, or merge. Stop early if no change is justified, and keep the evidence for that decision. Template: templates/change-contract.md.

2. Discover before designing. Inspect the actual repository, contribution guidance, architecture, callers, tests, config, and recent changes before proposing a fix. Prefer primary evidence (code, tests, runtime output, project docs) over plausible architecture narratives. Make unverified assumptions and missing access explicit.

3. Select the smallest safe intervention. Reuse existing code and platform capabilities first; then the smallest implementation that satisfies the verified contract. Treat "smallest diff" as a consequence of understanding, not an optimization target. Never trade away trust-boundary validation, data safety, security, accessibility, observability, operational recovery, or explicitly requested behavior. Record any deliberate ceiling and its upgrade trigger.

   Classify a test-hardening request explicitly when production behavior is already correct and the work adds a focused guard for a coverage gap or named mutation. That is a lightweight-path subtype, not an ordinary production bugfix: use baseline-pass / mutant-fail evidence instead of requiring the new test to fail on clean main. Load references/lightweight-test-hardening.md for the bounded contract and escalation triggers.

4. Execute by SDLC stage. Route the work to the stage that owns it — discovery/requirements, design, implementation, verification, delivery, learning. Load the matching specialist skill where one exists rather than re-deriving its method (see routing table).

5. Keep an evidence ledger. Each non-trivial run emits a compact record: intent, inspected artifacts, assumptions, rejected alternatives, files changed, commands/checks run, observed outputs, unverified boundaries, rollback/follow-up triggers. Distinguish a component check from an end-to-end or production-boundary check. Format and rules: references/evidence-ledger.md. Template: templates/evidence-ledger.md.

6. Stop and escalate by rule. Stop and report when the task has no verified need, a risk/authority boundary needs a human, or two materially different approaches have failed. Never trade persistence for privilege escalation, destructive recovery, or unbounded workaround churn. Rules: references/risk-authority-gates.md.

Change-request work (conditional)

When the request is a change request — an issue, ticket, or tracked request that will produce a pull request or an equivalent reviewable deliverable — the 6-step core loop above still governs each stage, but the run also follows the canonical 9-phase change-request journey:

→ references/journey.md — intake → discovery → design → spec → test plan → implementation → review → readiness → authorized release.

The journey adds gates, a delivery packet for cross-phase state, and platform lifecycle mechanics (GitHub or enterprise). It does not replace the core loop or create a second orchestrator.

Do not load the journey for: a simple fix, refactor, or review that has no issue/ticket trajectory. That work uses the core loop and the stage references below without the journey's phases, packet, or gates.

Mid-flight engagement (conditional)

When the request is to continue delivery work that started elsewhere — a half-implemented branch, an adopted spec, a change request another contributor began — and no delivery packet exists, do not restart at phase 1 and do not trust narrative summaries of what was done. Run position assessment first: inventory observable artifacts, score them against phase exit conditions, emit a position report (current step, satisfied gates with evidence pointers, remaining checklist), then bootstrap a packet and continue under the normal journey.

Procedure: references/position-assessment.md. Load it only for mid-flight engagement; fresh change requests start at phase 1, and existing packets govern resumability through references/delivery-packet.md.

Path selection before ceremony

Select the delivery path immediately after current-state discovery and before creating path-specific artifacts. Use the affected surface and risk, not line count alone.

For a test-hardening request, choose the lightweight path only when production behavior is already correct, production code remains unchanged, the change is confined to tests or fixtures, and a focused deterministic check plus a bounded controlled weakening can expose the regression. Record the invariant, the clean baseline evidence, the named mutation, and the non-goals. Do not apply the ordinary bugfix requirement that a new test fail on clean main.

For expensive or serialized CI, local design, hermeticity, focused tests, targeted mutation, lint, compilation, and scope checks must pass before the first push. Freeze the candidate before requesting one bounded final review or the repository's required platform review. A timed-out review is inconclusive, not a reason to launch repeated review rounds. Material changes invalidate the relevant verification and bind the replacement verdicts to the new exact head.

The detailed test-hardening contract and escalation triggers are in references/lightweight-test-hardening.md.

The one rule that defines "done"

"Done" is prohibited unless the declared verification target has actually been exercised. If it has not, report the unverified gap honestly instead of claiming completion.

A passing unit test is not the same as exercising the delivery boundary. A local render is not production. State which boundary was checked and which was not. Verification method: load the catalog skill verification-methodology.

Minimalism, correctly

Minimalism in this bundle is a conditional design choice made after real-flow understanding — not an unconditional "fewest lines wins" reflex. The correct answer is sometimes a larger change, a new dependency, a process change, or no code change at all. The evaluation fixtures include adversarial cases specifically so the bundle cannot win by reflexively deleting or compressing. See references/stages.md §3.

Routing: compose, don't swallow

neckbeard owns the cross-stage contracts — the change contract, evidence ledger, stop rules, and evaluation protocol. It does not own domain method. When a stage has a specialist skill, load it and follow it. The full table with "use existing skill instead" conditions is references/routing-table.md. Summary:

If a specialist skill is not installed, neckbeard's stage references provide a minimal fallback method — but note in the ledger that the specialist was absent.

Evaluation is a first-class deliverable

This bundle ships a versioned evaluation harness in eval/. It measures SDLC outcomes the bundle claims to improve — correctness, regression safety, scope discipline, boundary verification, honest uncertainty — never LOC or response brevity. Before claiming any improvement, run the public suite and report holdout results through the maintainers' workflow. Methodology: references/evaluation.md.

Claims policy. Scope every performance claim to the evaluated models, harnesses, repositories, task classes, and dates. Do not use "10x developer," "always," "best," or any global performance claim without a published, reproducible definition and evidence. LOC may appear only as diagnostic metadata, never as a success proxy.

File map