feat: /plan-status skill — check progress of a gstack plan against git log + codebase

[Willardgmoore]

Problem

gstack generates detailed plan files (CEO plans, eng plans) in ~/.gstack/projects/<slug>/ceo-plans/ and eng-plans/. These plans have phases, success-criteria checkboxes, file/gem references, and pre-migration checklists.

There is no skill to answer: "Where am I against this plan?"

The current workaround is asking Claude to manually read the plan and cross-reference the codebase — which works but is ad-hoc, inconsistent, and not something you'd think to do unless you remembered to ask.

Proposed skill: /plan-status

A read-only skill that:

1. Resolves the plan file — from an explicit argument, branch-name match, or AskUserQuestion if multiple plans exist
2. Extracts phases, - [ ]/- [x] success-criteria checkboxes, file/directory references, gem references, and pre-migration checklists
3. Gathers evidence from git log (commits since branching from main), git diff --name-only, filesystem checks (does the file/dir exist or was it deleted as planned?), and Gemfile grep
4. Classifies each item as DONE / PARTIAL / REMAINING / DROPPED using evidence conservatively (uncertain = REMAINING)
5. Produces a scannable dashboard:

## Plan Status: 2026-05-05-ruby-llm-full-migration.md
Branch: feature/ruby-llm-migration | As of: 2026-05-06

### Phase Summary
| Phase | Status | Notes |
|-------|--------|-------|
| Phase 0: Foundation | DONE | Gems added, initializers present |
| Phase 7: RAG migration | REMAINING | NotImplementedError stubs; no RubyLLM.embed calls |

### Success Criteria
| Item | Status |
|------|--------|
| langchainrb removed from Gemfile | REMAINING |
| Cross-tenant scoping test passes | REMAINING |
| ActsAsTenant require_tenant = true | PARTIAL — dev only |

### Summary
6 of 8 phases complete. 8 of 13 success criteria met.
Suggested next: Phase 7 RAG migration (remove langchainrb, wire RubyLLM.embed)

6. Offers to start on the top REMAINING item or update the plan's checkboxes — but never auto-starts.

Triggers

• "plan status"
• "how far along is the plan"
• "what's done / what's left"
• "check plan progress"
• "where are we on the plan"

Why it belongs in gstack

gstack already owns the plan lifecycle: /office-hours → /plan-ceo-review → /plan-eng-review → implementation → /ship. Plan status is the missing step between "plan written" and "ship called" — the regular check-in that keeps the plan and reality synchronized.

The skill is entirely read-only (no file writes), uses only Bash, Read, Glob, Grep, and optionally AskUserQuestion. Low complexity, high signal.

Related issues

• Add native Gstack plan writing skill #1170 — native plan writing skill (complementary — write + track)
• Claude cannot resume multi-step workflows across sessions #341 — resume multi-step workflows (overlapping concern: session continuity vs. plan continuity)
• /office-hours design doc saved to .claude/plans/ is invisible to downstream gstack skills #542 — office-hours design docs invisible to downstream skills (same family: plan discoverability)

Notes

I've built a local version of this skill at ~/.claude/skills/gstack/plan-status/SKILL.md and am running it now. Happy to contribute the implementation upstream if the direction looks right.

[wwybdd23-bot]

@Willardgmoore would love to see this land. I've been running gstack for nonprofit-board work and grant-pipeline ops (not just code), and the plan-status gap shows up identically there. /office-hours writes a design doc → I implement against it over weeks → there's no way to ask "where am I against the plan" without manually re-reading and cross-referencing. Same shape as your code-side use case, different artifacts (board action items, grant deadlines, milestone deliverables instead of - [ ] success criteria).

If you upstream the implementation, two small asks:

1. Generalize the evidence-gathering layer past git log. The classifier (DONE / PARTIAL / REMAINING / DROPPED) is universally useful — but in non-code projects, evidence comes from filesystem artifacts, calendar entries, sent emails, etc. If the evidence gatherer is an extensible step (e.g., a list of evidence-source functions the skill iterates), the skill works the same way for any plan, code or not.

2. Make the plan-file resolution Glob-pattern configurable. Your default of ~/.gstack/projects/<slug>/ceo-plans/*.md is right for gstack's pipeline. But office-hours users running gstack for non-code projects (board planning, fundraising campaigns) often save plans under different paths. A frontmatter plan_glob knob in the SKILL.md would let users point it at their actual plan directories without forking.

Happy to test against my use case if helpful — I run with 4 active plans (board strategic plan, capital campaign plan, grant pipeline v2, accreditation prep) and zero of them are in git log. Real-world non-code stress test.

[Willardgmoore]

Hey @wwybdd23-bot — thanks for the detailed feedback. Really helpful to hear about the non-code use case.

Before we decide whether to fold your two asks into the current PR or treat them separately, we'd love to understand your setup a little better. A few questions — no technical knowledge needed:

About your plans (both asks)

1. Where do you currently save your plan documents? For example: a specific folder on your computer, a cloud service like Notion or Google Docs, or somewhere else?
2. Do you create these plans using gstack's /office-hours skill, or do you write them yourself in a text editor?

About the "where to find my plans" ask (Ask 2)
3. If you could tell plan-status "look for my plans here instead of the default location," would that solve your problem? For example: plan_glob: ~/board-plans/*.md in a config file.

About the "evidence from non-code projects" ask (Ask 1)
4. When you want to check whether a task in your plan is done, what would you actually look at? For example:

• A file showing up in a folder (e.g., a signed document was saved)
• A note or document you created (e.g., a meeting summary written up)
• Something else you can point to as a file on your computer?

5. Quick clarification on scope that might save you time: gstack is focused on evidence you can find in files and folders on your computer (documents, notes, project files). Gbrain — a separate tool — is the right home for connecting to external services like Gmail or Google Calendar. So if your evidence is "I sent an email" or "a calendar event happened," that's a Gbrain feature request, not a gstack one. Does your non-code workflow mostly involve local files, or are you relying heavily on cloud services as the source of truth?

---

The reason we're asking: these two asks might be very different in terms of how much work they are.

• Ask 2 (point plan-status at a different folder) is small and could land in the current PR.
• Ask 1 (check non-file evidence) depends heavily on your answer to question 5 above — if it's file-based, it may fit gstack; if it's Gmail/Calendar-based, it belongs in a Gbrain feature request instead.

Your answers will help us figure out which direction to go. No wrong answers here!

[wwybdd23-bot]

Thanks Willard — happy to give context. Quick sketch of my setup:

1. Where my plans live
   Most of my plans live in an Obsidian vault on my Mac (markdown files synced via Obsidian). A smaller set live in working folders on Desktop, organized by project — e.g. ~/Desktop/CCC - Grants/ for grant pipeline work, similar folders for board governance, capital planning, etc. All local files, all markdown.

2. How I create plans
   Mix of both. I use Claude Code skills (including /office-hours and project-specific planning skills) to draft them, then iterate in my editor / Obsidian. So the output is plain markdown either way — plan-status doesn't need to know how they were authored.

3. Would plan_glob solve Ask 2?
   Yes — that's exactly what I need. Something like:

plan_glob:

• ~/Obsidian/CCC/**/plan-*.md
• ~/Desktop/CCC - Grants/plans/*.md
  Multiple globs would be ideal since plans are scattered across a few project roots. If only one is feasible for the current PR, single glob is still a big win.

4. What "done" evidence looks like for me
   All of these, depending on the task:

Files: a signed PDF saved to a folder, a draft narrative committed to Obsidian, a budget spreadsheet updated
Emails sent: grant LOIs submitted, board packets distributed, funder follow-ups
Calendar events that happened: board meetings, committee meetings, funder calls (past-dated = completed)
External system state: a grant marked submitted in our pipeline DB (Supabase), a Linear/issue closed
5. Where artifacts actually live
Split roughly:

Local files: Obsidian vault + Desktop folders (markdown, PDFs, docx)
Gmail: all sent/received correspondence
Google Calendar: meetings and events
Supabase / app DBs: structured records (grant pipeline, etc.)
I already have MCP servers connected to Gmail, Calendar, and Supabase in my Claude Code setup, so the "evidence" sources are queryable — but I get that asking plan-status to depend on user-configured MCPs is a much bigger surface than scanning local files.

My take on scoping

Ask 2 in this PR sounds right — plan_glob is genuinely the unblocker. Even just supporting an env var or single config key gets me 90% of the value today.
Ask 1 as a separate discussion also makes sense. The honest design question isn't "scan emails" — it's "how does plan-status accept pluggable evidence sources?" That's worth designing carefully (probably as user-defined evidence checkers / hooks, not built-in Gmail/Calendar integrations) and shouldn't bloat this PR.
Happy to open a separate issue for Ask 1 with a longer write-up if useful.

[Willardgmoore]

PR open: #1438

Implements the skill as described. The plan_glob knob (your Ask 2) is included — configure it in ~/.gstack/config.yaml to point at any plan directory (Obsidian vault, Desktop folders, etc.).

Ask 1 (pluggable evidence sources / non-file artifacts) is scoped out of this PR as a separate design discussion, as you suggested.