Fix raise-pr spec-kit pointer reset to compare repo-relative paths

[FrankRay78]

Why

.claude/commands/raise-pr.md step 4 clears the spec-kit feature pointer (.specify/feature.json) when deleting a branch's spec folder, so it doesn't dangle at a folder that no longer exists on main. The reset condition was unreliable: it fired only if feature_directory "points at <FEATURE_DIR>", but FEATURE_DIR (from check-prerequisites.sh --json --paths-only) is an absolute path while .specify/feature.json stores a repo-relative value (e.g. specs/004-…). A literal string comparison never matches, so the pointer can be left dangling — the exact stale-pointer case the bullet exists to prevent (it makes check-prerequisites.sh hard-fail and lets setup-plan.sh silently recreate the deleted folder).

What changes

Tightened only that clause to compare as repo-relative paths, with an inline note that FEATURE_DIR is absolute while the JSON is repo-relative. The rest of the bullet (hard-fail / recreate rationale) is unchanged.

Related

Prompt-only change — no code or tests affected.

[FrankRay78]

@claude Review this pull request. Analyse the code changes and provide feedback covering:

• Bugs or correctness issues
• Security concerns (including any flagged by static analysis)
• Adherence to the project conventions in CLAUDE.md
• Test coverage — do the tests adequately cover the new behaviour?
• Any spec/test-plan mismatches

[claude]

Claude finished @FrankRay78's task in 3m 36s —— View job

---

Review: Fix raise-pr spec-kit pointer reset to compare repo-relative paths

• Gather context (diff, full file, trigger comment)
• Verify the repo-relative comparison claim against the actual scripts
• Post review feedback

---

Summary: This is a correct, well-scoped, single-line fix to .claude/commands/raise-pr.md step 4. I traced the actual mechanics to confirm the diagnosis rather than taking it at face value:

• check-prerequisites.sh --paths-only → get_feature_paths in .specify/scripts/bash/common.sh always normalizes FEATURE_DIR to an absolute path (common.sh:187-188, 199-200), regardless of what's stored in feature.json.
• The actual feature-creation flow this project uses is the speckit-specify skill (.claude/skills/speckit-specify/SKILL.md:93,101-107), which explicitly sets SPECIFY_FEATURE_DIRECTORY to a repo-relative value like specs/003-user-auth and instructs writing that literal relative string into .specify/feature.json.

So the mismatch is real: a raw string comparison of an absolute <FEATURE_DIR> against a repo-relative feature_directory value would never match, silently leaving the pointer dangling — exactly the failure mode the surrounding bullet exists to prevent (stale pointer → check-prerequisites.sh hard-fail, setup-plan.sh silently recreates the deleted folder). Good catch, and the fix addresses it directly.

Findings:

• No bugs or correctness issues. The new wording correctly instructs a repo-relative comparison, and the inline parenthetical accurately explains why (absolute vs. repo-relative) — consistent with this repo's "prompts favour locality over DRY" convention (inline explanation rather than a cross-reference).
• No security concerns. Prompt-only change to an internal slash-command; no code paths, no user input handling.
• CLAUDE.md conventions: followed. No hard-wrapped markdown (single line, soft-wrap-friendly), scope stayed tight to the one clause instead of touching the unrelated hard-fail/recreate rationale, and no spurious doc/test changes for what is a prompt-only fix.
• Test coverage: N/A and correctly noted as such in the PR body — this is a .claude/commands/*.md prompt file, not production C# code, so the TDD principle in the constitution doesn't apply here. Nothing in NetPace.Core/NetPace.Console changed.
• Spec/test-plan mismatches: none — there's no spec folder for this branch (confirmed via git log/ls specs), so no spec-kit tasks/AC traceability applies.

Minor, non-blocking observation:

Step 3 of the file only says to "keep FEATURE_DIR... for step 4" — it doesn't explicitly call out retaining REPO_ROOT from the same JSON payload, which is what an agent would need to turn the absolute FEATURE_DIR into a repo-relative value for the new comparison in step 4. In practice this is almost certainly fine since the executing agent will still have the full JSON output (including REPO_ROOT) in its context from running the step-3 command — but making that explicit (e.g. "keep FEATURE_DIR and REPO_ROOT for step 4") would remove any ambiguity for a strict reading of the instructions. Not worth blocking on.