yourssh-roadmap - SKILL.md Agent Skill

name: yourssh-roadmap description: Use when the user wants to refresh, update, or regenerate the yourssh project roadmap at docs/roadmap.md — e.g. after shipping a feature, bumping version, completing a sprint, or asking "cập nhật roadmap"

YourSSH Roadmap Refresh

Update docs/roadmap.md for the yourssh repo based on the actual state of the codebase + git history. Avoid rewriting the roadmap from scratch each time — only diff what already exists and propose new features.

When to use

User says "update roadmap", "refresh roadmap", "cập nhật roadmap", "version bump xong rồi"
After merging a large feature into develop/master
When prepping for sprint planning
When the version in app/pubspec.yaml changes

Do not use when: the user wants to brainstorm completely new features from scratch (use superpowers:brainstorming) or write a spec for a specific feature (use superpowers:writing-plans).

Workflow

Read current state (run in parallel):
- Read docs/roadmap.md — existing roadmap
- Bash git log --oneline -30 — recent commits
- Bash grep -E "^version:" app/pubspec.yaml — current version
- Bash ls app/lib/providers app/lib/services app/lib/widgets packages/ — surface area of existing code
- Bash git tag --sort=-creatordate | head -10 — shipped releases
Classify shipped vs remaining by comparing commit messages + new file names against the old roadmap list. Move shipped bullets up to the "Shipped" section at the top of the doc.
Update metadata:
- Version line: Current version: X.Y.Z
- Date line: updated: YYYY-MM-DD (use the real date, do not hard-code)
Ask the user one question (via AskUserQuestion):
- Are there new features to add to P0/P1/P2?
- Is there anything to re-prioritize?
- If the user says "no, just update what's shipped" → skip step 5.
Apply user changes (if any) into the correct table/section.
Show diff before committing: Bash git diff docs/roadmap.md. Wait for user approval before suggesting a commit.

Roadmap structure (must be preserved)

# YourSSH — Roadmap
> Direction + version + date
[Section "Shipped"]
## P0 — Must-have to retain power users  (table with 10 rows)
## P1 — Differentiation & DevOps depth  (sub-sections by theme)
## P2 — Team / Enterprise
## Top 3 suggestions for the next sprint
## How to use this document

Do not change the structure unless the user requests it. P0 is always a table (Feature / Purpose / Implementation notes). P1 is always split by theme.

Detection heuristics — "has this feature shipped?"

Feature in roadmap	Check
Command Palette	`grep -r "CommandPalette\|command_palette" app/lib/`
Tag/group	`grep -E "tags\s*:" app/lib/models/host.dart`
SSH config import	`grep -r "ssh_config\|parseSSHConfig" app/lib/`
Workspace persistence	`grep -r "workspace\|restoreSession" app/lib/providers/`
Search-in-scrollback	`grep -r "searchBuffer\|scrollback.*search" app/lib/`
Kubernetes panel	`ls packages/ \| grep -i kube`

When grep returns a real match (not a comment/TODO), consider it shipped → move to "Shipped".

Common mistakes

❌ Re-generating the entire roadmap from scratch → loses user-added notes from previous sessions. Always read first, edit in place.
❌ Hard-coding the date in the skill. Always Bash date +%Y-%m-%d.
❌ Committing without showing the diff. Always show diff and wait for approval.
❌ Skipping packages/ when detecting shipped features — the plugin folder counts too.
❌ Changing section/table format structure → makes diffs between versions harder to read.
❌ Forgetting to update the wiki when shipping a feature. Always update docs/wiki/ alongside docs/roadmap.md:
- User-visible feature shipped → update or create docs/wiki/User-Guide-*.md
- New developer component → update docs/wiki/Developer-Guide-*.md
- New feature area → add a row to docs/wiki/Home.md

Output

Edit file docs/roadmap.md in place (do not create a new file). At the end, output a 2–3 line summary:

How many items were moved to "Shipped"
How many new items were added
Suggested commit message (but do not commit automatically).