fix(neckbeard): address droid-review findings on position-assessment PR

All five findings from the droid-review run on 2db3bd0 resolved:

- [P1] Path re-selection moved before scoring: step 2 now re-runs the
  SKILL.md path-selection rule against the inventoried surface, so step 3
  scoring and the report's selected-path field no longer depend on a
  value produced later in step 5.
- [P2] Tracking-system field added to delivery-packet.md group (a) and to
  templates/delivery-packet.md, so the phase-1 intake gate has a defined
  packet home for the field tracker-discovery.md requires.
- [P2] tracker-discovery eval aligned with the documented procedure: a
  bare team-key identifier (ENG-482) is treated as ambiguous between
  Jira and Linear; the requester's explicit confirmation is the
  disambiguating evidence recorded in group (a).
- [P3/security] Detection signals weighted: request references are strong
  evidence; repository content (CONTRIBUTING.md, config files) is a weak,
  attacker-influenceable signal requiring corroboration before it alone
  selects a system. Unrouted-system fallback constrained to the system's
  verified official interface.
- [P3] Frontmatter description extended with the new trigger vocabulary
  (mid-flight continuation, Linear/Jira/Notion routing), compressed to
  stay within the 1024-char validator cap.

Generated catalog artifacts regenerated for the description change.
All validators re-run green locally; new head requires fresh CI.

Signed-off-by: Magnus Hedemark <magnus919@users.noreply.github.com>

.claude-plugin/marketplace.json

@@ -732,7 +732,7 @@
         "./neckbeard"
       ],
       "strict": false,
-      "description": "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."
+      "description": "Use when asked to fix, build, refactor, review, verify, or release software and the work is non-trivial — including delivering a change request through planning, gates, implementation, review, verified PR, and authorized release; continuing work started elsewhere with no packet via evidence-based position assessment; or operating tracked work items in Linear, Jira, or Notion via their tooling skills. neckbeard routes the change through framing, discovery, design, implementation, review, verification, and learning — choosing the smallest *safe* intervention, proving it at the real delivery boundary, 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."
     },
     {
       "name": "notion",

llms.txt

@@ -82,7 +82,7 @@
 - [ml-engineering](ml-engineering/SKILL.md): Plan and execute production ML engineering work — model training and fine-tuning (LoRA/QLoRA), evaluation and eval-set design, quantization decisions, inference deployment, and regression triage, grounded in practical engineering patterns for production ML systems. Do not use for statistical modeling and experimental design (that's the data scientist) or for operating a specific inference engine (that's a tool skill such as llama-cpp or vllm).
 - [mobile-development](mobile-development/SKILL.md): Build, test, sign, and ship mobile apps across iOS, Android, Flutter, and React Native — project scaffolding, builds and code signing, device and emulator testing, store submission (App Store and Play Store), app lifecycle and backgrounding, offline and sync, and mobile-specific testing. Use when the task involves creating, building, testing, or shipping a mobile app for iOS or Android, or reasoning about mobile behavior such as background execution, push notifications, offline storage, and data sync. Do not use for web frontend work (that is frontend-engineering), backend services and APIs (that is backend-engineering), or desktop and web platform targets outside the iOS and Android scope.
 - [multi-tenant-saas-architecture](multi-tenant-saas-architecture/SKILL.md): Design and review end-to-end multi-tenant SaaS architectures: tenant and subscription semantics, control and application planes, pooled or isolated tenancy, onboarding, entitlements, metering, billing handoffs, lifecycle, partitioning, and tenant-aware operations. Use when a subscription product needs a coherent tenant model and architecture decision across these seams. Do not use for threat modeling or isolation controls, API contract semantics, data-platform design, backend implementation, migration execution, privacy compliance artifacts, capacity evidence, financial modeling, or infrastructure operations; route those to the named specialist owners.
-- [neckbeard](neckbeard/SKILL.md): 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.
+- [neckbeard](neckbeard/SKILL.md): Use when asked to fix, build, refactor, review, verify, or release software and the work is non-trivial — including delivering a change request through planning, gates, implementation, review, verified PR, and authorized release; continuing work started elsewhere with no packet via evidence-based position assessment; or operating tracked work items in Linear, Jira, or Notion via their tooling skills. neckbeard routes the change through framing, discovery, design, implementation, review, verification, and learning — choosing the smallest *safe* intervention, proving it at the real delivery boundary, 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.
 - [notion](notion/SKILL.md): Operate Notion from a terminal or agent: retrieve pages, query databases, search pages and databases, and update page properties — with a bundled notion-cli script that is read-only by default and gates every create or update behind a --dry-run/--yes confirmation. Use when an agent needs to read Notion content, answer questions from a team wiki or database, or make a confirmed edit. Do not use for building Notion integrations or block-level page composition beyond property updates (that is Notion API application development), or for other knowledge bases (that is their own tooling).
 - [nous-branding](nous-branding/SKILL.md): Generate images and content consistent with the Nous Research brand identity. Use when creating visuals in the Nous / Theia / Hermes ecosystem: a "cyber-classical" style blending neo-classical statuary, cyberpunk/industrial grunge, and retro anime illustration. Covers official brand color palette, typography (Inter/IBM Plex Sans, JetBrains Mono, heavy distressed display faces), the Nous Girl mascot, texture system, and image prompt construction. Ships reference images for palette, mascot, and brand collage that can be used as img2img inputs.
 - [open-knowledge-format](open-knowledge-format/SKILL.md): Google's Open Knowledge Format (OKF) v0.1 — an open, vendor-neutral spec for representing knowledge as markdown files with YAML frontmatter, designed for AI agent consumption. Use when the user mentions OKF, Open Knowledge Format, Google's knowledge format, LLM wiki bundles, agent knowledge packs, creating OKF bundles, validating OKF documents, or converting knowledge into the OKF standard.

neckbeard/SKILL.md

@@ -1,18 +1,17 @@
 ---
 name: neckbeard
 description: >-
-  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.
+  Use when asked to fix, build, refactor, review, verify, or release software and the work is
+  non-trivial — including delivering a change request through planning, gates, implementation,
+  review, verified PR, and authorized release; continuing work started elsewhere with no packet
+  via evidence-based position assessment; or operating tracked work items in Linear, Jira, or
+  Notion via their tooling skills. neckbeard routes the change through framing, discovery,
+  design, implementation, review, verification, and learning — choosing the smallest *safe*
+  intervention, proving it at the real delivery boundary, 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.
 license: MIT
 compatibility: Agent harness with file read/write, terminal, and skill loading. No network or runtime dependency required by the bundle itself.
 metadata:

neckbeard/references/delivery-packet.md

@@ -29,7 +29,7 @@ into another or left to implication.
 
 | Group | Name | Fields |
 |---|---|---|
-| **(a)** | **Change-request provenance** | Change-request URL or number; source type (issue / ticket / email / verbal); repository; base ref; issue/comment snapshot (request text, comments, and linked work captured at intake); head SHA at intake. |
+| **(a)** | **Change-request provenance** | Change-request URL or number; source type (issue / ticket / email / verbal); repository; base ref; issue/comment snapshot (request text, comments, and linked work captured at intake); tracking system identified at intake per [tracker-discovery.md](tracker-discovery.md), with its evidence basis (repository-detected or requester-confirmed); head SHA at intake. |
 | **(b)** | **Granted authority + workflow mode/path** | Authority class granted (Explore / Modify / Publish / Deploy / Merge — see [risk-authority-gates.md](risk-authority-gates.md)); selected workflow mode (GitHub reference mode or enterprise mode); selected path (lightweight / full / refactor / high-risk). |
 | **(c)** | **Resumable phase/gate state + current head SHA** | Current phase name; current gate name; the head SHA at which the last successful gate verdict was recorded; the current lifecycle state (see below). |
 | **(d)** | **Problem / baseline evidence / scope / non-goals / affected surfaces** | User-visible problem; baseline (pre-change) evidence with boundary labels; in-scope work; explicit non-goals; affected surfaces (paths, contracts, boundaries). |

neckbeard/references/position-assessment.md

@@ -72,6 +72,11 @@ Inventory reads are read-only discovery; they need no confirmation. Record
 where each artifact was found (path, SHA, URL) — pointers become the evidence
 references in the report.
 
+**Re-select the delivery path here, before scoring.** Run the path-selection
+rule ([../SKILL.md](../SKILL.md) § Path selection) against the affected surface
+and risk observed in the inventory; do not inherit a path assumption from the
+prior work. The selected path determines which phases are mandatory to score.
+
 ### Step 3 — Score against phase exit conditions
 
 Compare each inventoried artifact with the exit condition and gate definition
@@ -87,9 +92,9 @@ of its phase ([journey.md](journey.md); gate semantics in
 
 Scoring constraints:
 
-- Score the selected delivery path's mandatory phases; conditional phases are
-  scored only if their artifacts exist (an absent conditional phase with a
-  legitimate skip reason is recorded as such, not penalized).
+- Score the delivery path selected in step 2; conditional phases are scored
+  only if their artifacts exist (an absent conditional phase with a legitimate
+  skip reason is recorded as such, not penalized).
 - Verified-complete work is **not** re-executed, mirroring packet-resume
   semantics. Assessment establishes position; it does not redo accepted work.
 - Never upgrade a verdict to fill a gap. A missing gate verdict is `absent`,
@@ -124,9 +129,9 @@ Create a fresh delivery packet so subsequent operation has normal resumability:
 
 - Group (a) provenance records: engaged mid-flight, artifacts assessed, with
   the inventory pointers.
-- Group (b) records the re-selected delivery path (path selection per
-  [../SKILL.md](../SKILL.md) § Path selection — re-run it here; do not inherit
-  a path assumption from the prior work).
+- Group (b) records the delivery path selected in step 2 (path selection per
+  [../SKILL.md](../SKILL.md) § Path selection was re-run during assessment; no
+  path assumption was inherited from the prior work).
 - Group (c) initializes from the position report: current phase, current gate,
   and the head SHA at assessment time.
 - Unverified assumptions go to the evidence ledger

neckbeard/references/tracker-discovery.md

@@ -40,16 +40,27 @@ Run during phase 1 alongside provenance capture:
 
 2. **Check what the request itself references.** A change request arriving as a
    Linear issue URL, a Jira ticket ID, or a GitHub issue number is direct
-   evidence for its own system.
+   evidence for its own system. A bare team-key identifier (`ENG-42` shape) is
+   **ambiguous** between Jira and Linear — treat it as a lead, not a verdict.
 
-3. **Ask when ambiguous or absent.** If signals conflict (repo mirrors to
-   GitHub but issues live in Jira) or none exist, ask one bounded question:
-   which system holds this work item? Record the answer as requester-provided
-   provenance. Do not silently pick the system whose CLI happens to be installed.
+3. **Weight the signals honestly.** The request's own references are strong
+   evidence. Repository content — `CONTRIBUTING.md`, `AGENTS.md`, README
+   integrations, config files like `.linear/` or `.jira-url` — is a **weak
+   signal**: it describes what the repository documents, not necessarily what
+   holds authoritative work items, and it is attacker-influenceable in
+   mid-flight or adopted-branch scenarios where this bundle also operates.
+   Repository signals require corroboration (request references, remote
+   configuration, or requester confirmation) before they alone select a system.
 
-4. **Record in packet group (a):** detected/requested system, the evidence or
-   source of the answer, and the routing decision below. Silent omission is
-   prohibited like every other intake field.
+4. **Ask when ambiguous or absent.** If signals conflict, rest only on weak
+   signals, or none exist, ask one bounded question: which system holds this
+   work item? Record the answer as requester-provided provenance. Do not
+   silently pick the system whose CLI happens to be installed.
+
+5. **Record in packet group (a):** detected/requested system, the evidence or
+   source of the answer (including when the basis is a requester confirmation),
+   and the routing decision below. Silent omission is prohibited like every
+   other intake field.
 
 ## Routing tracker operations
 
@@ -62,7 +73,7 @@ improvising API calls:
 | Linear | `linear` |
 | Jira | `jira-cli` |
 | Notion | `notion` |
-| Other / none of the above | No specialist route: operate through the system's own documented interface with bounded reads, and note the absent specialist in the ledger |
+| Other / none of the above | No specialist route: operate only through the system's verified official interface (primary vendor documentation, confirmed endpoint/auth surface), with bounded reads; note the absent specialist in the ledger |
 
 Routing constraints:
 

neckbeard/templates/delivery-packet.md

@@ -14,6 +14,7 @@
 - **Repository:** _[fill: repo path or URL, e.g. `https://github.com/org/repo`]_
 - **Base ref:** _[fill: branch or ref the change is based on, e.g. `main`]_
 - **Issue/comment snapshot:** _[fill: request text, comments, and linked work captured at intake — paste inline or link to a snapshot file]_
+- **Tracking system:** _[fill: system identified per ../references/tracker-discovery.md, e.g. `Linear (requester-confirmed)` / `GitHub Issues (detected: issue URL in request)`]_
 - **Head SHA at intake:** _[fill: `git rev-parse HEAD` at intake, e.g. `a1b2c3d`]_
 
 ## (b) Granted authority + workflow mode/path