Agent skill · magnus919
neckbeard
Use when asked to fix, build, refactor, review, verify, or release software and the work is non-trivial — including delivering a change request (issue, ticket, or request) from intake through planning, gates, implementation, review, verified PR, and authorized post-merge release. neckbeard routes the change through framing, discovery, design, implementation, review, verification, delivery, and learning — choosing the smallest *safe* intervention, proving it at the real delivery boundary, and leaving an inspectable evidence ledger. For change-request / issue-to-PR work, conditionally loads a 9-phase journey with gates, delivery packet, and lifecycle integration. Composes specialist catalog skills rather than replacing them. Not a persona, not a '10x developer' prompt, not a LOC-minimizer. The journey is not loaded for plain fixes, refactors, or reviews that lack an issue/ticket trajectory.
What it needs
About 7k tokens when loaded.
What this skill does
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. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills magnus919/neckbeard