OpeItcLoc03/claude-skills
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat(hermes): mvp-coverage — 9 skills converted to Hermes format

Browse Source 
- mapping.yaml: 7 pending → auto (setup-tasks, using-tasks, setup-wiki,
  using-wiki, using-projects-meta, using-context7, project-bootstrap,
  recommend-dont-menu). pending count now 0.

- dist-hermes/ populated:
  software-development: project-bootstrap (+ assets)
  productivity: recommend-dont-menu, setup-tasks, using-tasks
  research: setup-wiki, using-wiki
  mcp: using-context7, using-projects-meta

- active-platform replace-rule verified: Windows+PowerShell → Linux+bash
  in body SKILL.md (frontmatter description unchanged by design).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
vitya
2026-05-07 09:21:56 +03:00
parent 27026c5e0e
commit 82f82a2036
19 changed files with 2738 additions and 48 deletions
Download Patch File Download Diff File Expand all files Collapse all files

108
dist-hermes/productivity/setup-tasks/README.md Normal file
View File

@@ -0,0 +1,108 @@
# setup-tasks
One-time skill that creates or migrates a project's `.tasks/` board to the
canonical layout — `STATUS.md` (the board, with emoji status legend) plus
per-task `<task-slug>.md` files for each active or paused task. The runtime
policy for working *with* the board lives in
[`using-tasks`](../using-tasks/) — `setup-tasks` is the only place that
creates the structure.
## When it triggers
- User says: "set up tasks", "init tasks", "create task tracking",
"migrate tasks to canon", "tasks broken", or the Russian equivalents
("настрой таски", "инициализируй таски").
- [`using-tasks`](../using-tasks/) detects a missing or non-canonical
`.tasks/` and delegates here via its Prerequisites section.
- [`project-bootstrap`](../project-bootstrap/) Step 4 delegates here when
initializing a new project.
## Modes
`setup-tasks` picks one of three modes after a discovery scan:
| Mode | Trigger | Action |
|---|---|---|
| **greenfield** | No `.tasks/` exists | Write `.tasks/STATUS.md` from the canonical template. No per-task files yet — they're created on demand. |
| **noop** | `.tasks/STATUS.md` already canon (emoji status legend + at least one per-task file) | Report and exit. |
| **migrate** | `.tasks/STATUS.md` is flat (plain `## Done` / `## In Progress` / `## Backlog`, no emoji legend, no per-task files) | Back up, then drive an interactive migration — one task at a time, asking the user for the canonical fields. |
A "placeholder" STATUS.md (just the bootstrap default with no real tasks) is
treated as `greenfield` — no migration needed.
## What canon means
```
.tasks/
├── STATUS.md ← board, with emoji status legend + one block per task
└── <task-slug>.md ← per-task deep context (one file per active/paused task)
```
Status legend: 🔴 active / 🟡 paused / ⚪ ready / 🟢 done / 🔵 blocked.
`STATUS.md` block format (one per task):
```
## 🔴 [task-slug] — short description
**Status:** active
**Where I stopped:** one sentence — the exact thought or action interrupted
**Next action:** one concrete step to resume immediately
**Blocker:** (only if blocked) what is preventing progress
**Branch:** git branch name
```
Per-task file sections: Goal, Key files, Decisions log, Open questions,
Completed steps, Notes.
## Hard rules
- **Never auto-mutate.** Phase 1 (discovery) and Phase 2 (plan) always pause
for explicit confirmation. A trigger phrase grants permission to inspect,
not to write.
- **Never auto-parse a flat STATUS.md.** Old layouts vary; agent heuristics
mangle real work. Migration is interactive — the agent asks the user for
each task's canonical fields.
- **Never invent task slugs / branches / "where you stopped" values.** The
whole point is *real* preserved context, not hallucinated context.
- **No empty per-task files at greenfield.** Wait until the user adds a
real task.
- **Never edit the `.bak` file.** It's the rollback artifact.
## Procedure (high-level)
1. **Phase 0** — environment sanity (project root).
2. **Phase 1** — discovery (greenfield / noop / migrate).
3. **Phase 2** — plan + confirm. Wait for explicit "ok"/"go"/"поехали".
4. **Phase 3** — backup (migrate only) → `STATUS.md.bak-YYYYMMDD-HHMMSS`.
5. **Phase 4a/4b** — greenfield create or interactive migrate.
6. **Phase 5** — verify (canon `STATUS.md`, per-task files for active/paused
only, no required content lost).
7. **Phase 6** — final report; if invoked from `project-bootstrap`, return
silently.
Full procedure with templates and the migration script lives in
[`SKILL.md`](SKILL.md).
## Rollback
- Greenfield: `rm -rf .tasks/`.
- Migrate: `mv .tasks/STATUS.md.bak-<ts> .tasks/STATUS.md` plus `rm` for any
newly created per-task files; `git reset HEAD .tasks/`.
## Install
From the repo root:
```bash
bash scripts/install.sh setup-tasks
```
Works on Windows under git-bash, Linux, macOS.
## See also
- [`using-tasks`](../using-tasks/) — runtime policy for working with `.tasks/`.
- [`project-bootstrap`](../project-bootstrap/) — orchestrator that delegates
here for new projects.
- Source pattern: `.wiki/raw/setup-task-status-wiki.md` in this repo —
extended documentation, decisions log format, agent operations.

202
dist-hermes/productivity/setup-tasks/SKILL.md Normal file
View File

@@ -0,0 +1,202 @@
---
name: setup-tasks
version: 1.0.0
description: Creates or migrates a project's `.tasks/` board to the canonical layout — `STATUS.md` (the board, with emoji status legend) plus per-task `<task-slug>.md` files for each active or paused task. Use when the user says "set up tasks", "init tasks", "настрой таски", "инициализируй таски", "create task tracking", "migrate tasks to canon", "tasks broken", or whenever `using-tasks` detects a missing or non-canonical `.tasks/`. Two modes — greenfield (no `.tasks/`) and migrate (existing flat STATUS.md without per-task files). Confirmation gate before writing. Cross-platform.
---
# setup-tasks
> Creates or migrates a `.tasks/` board to canon. The canonical layout is enforced by `using-tasks` and described in `.wiki/raw/setup-task-status-wiki.md` (the original idea file from which this skill is derived). This skill is the *only* place that creates the board structure.
## When to use
- User explicitly asks: set up / init / migrate / create tasks.
- `using-tasks` runs and detects a missing or non-canonical `.tasks/` — its Prerequisites delegate here.
- `project-bootstrap` Step 4 delegates here when initializing a new project.
## Out of scope
- Editing existing task content during normal work (that's `using-tasks`).
- Anything outside `.tasks/`.
## Hard rule: don't auto-mutate
The procedure mutates `.tasks/`. **Pause for explicit confirmation between Phase 1 (discovery) and Phase 2 (plan).** A trigger phrase is permission to inspect, not to write.
## Procedure
### Phase 0 — Environment sanity
- Confirm current working directory is a project root (preferably with `.git/`; otherwise it's still OK to bootstrap, just note it).
- Tasks paths are POSIX-style (`.tasks/...`) on every OS.
### Phase 1 — Discovery
Inspect `.tasks/`:
- **No `.tasks/`** → mode = `greenfield`.
- **`.tasks/STATUS.md` exists with canonical signals** — has emoji status (🔴 / 🟡 / ⚪ / 🟢 / 🔵) AND at least one per-task `.tasks/<slug>.md` exists for any active/paused entry → mode = `noop`.
- **`.tasks/STATUS.md` exists but flat** — no emoji legend, no per-task files, just plain `## Done` / `## In Progress` / `## Backlog` sections (or similar) → mode = `migrate`.
Report findings:
```
Mode: greenfield | noop | migrate
STATUS.md: exists | missing
Per-task files: <count>
Format: canon | flat | mixed
```
### Phase 2 — Plan + confirm
Show the plan in one block.
**Greenfield:**
```
Will create .tasks/STATUS.md with the canonical board template.
Per-task files will be created on demand by using-tasks when actual tasks are added.
```
**Migrate:**
```
Will:
• back up existing STATUS.md → STATUS.md.bak-<ts>
• for each task entry I can identify in the old STATUS.md, ask you for:
- task-slug (kebab-case, latin)
- current status (active / paused / ready / done / blocked)
- branch
- where you stopped (one sentence)
- next action (one sentence)
then write `.tasks/<slug>.md` and a canonical STATUS.md block.
• leave the .bak file as a fallback reference.
```
If existing `STATUS.md` is purely a placeholder (just the bootstrap-default comment block, no real tasks), treat as `greenfield` — no migration needed, just overwrite with the template.
Wait for explicit confirmation ("ok", "go", "поехали"). Anything else → stop.
### Phase 3 — Backup (migrate only)
```bash
TS=$(date +%Y%m%d-%H%M%S)
cp .tasks/STATUS.md ".tasks/STATUS.md.bak-$TS"
```
### Phase 4a — Greenfield create
Write `.tasks/STATUS.md`:
```markdown
# Task Board
_Updated: <today>_
<!--
Add one block per task, sorted by priority. Use the emoji status legend below.
Per-task deep context lives in .tasks/<task-slug>.md (created on demand by using-tasks).
Block format:
## 🔴 [task-slug] — short description
**Status:** active
**Where I stopped:** one sentence — the exact thought or action interrupted
**Next action:** one concrete step to resume immediately
**Blocker:** (only if blocked) what is preventing progress
**Branch:** git branch name
---
Status legend:
🔴 Active — only one at a time
🟡 Paused — in progress, resumable
⚪ Ready — defined, not started
🟢 Done — kept until merged
🔵 Blocked — waiting on external input
-->
```
No per-task files at greenfield — they're created when actual tasks are added.
### Phase 4b — Migrate
In migrate mode, do *not* try to auto-parse the old flat STATUS.md. The old layout is too varied — agent-driven heuristics will mangle real work. Instead, drive the migration interactively:
1. Show the user the old STATUS.md content (or a summary).
2. Ask: "Which of these are real, in-flight tasks you want to keep?" Get a list.
3. For each task, ask the four canonical fields (slug, status, branch, where-stopped, next-action). The skill never invents these.
4. Build a fresh canonical `.tasks/STATUS.md` from those answers.
5. Create `.tasks/<task-slug>.md` for each active or paused task using the per-task template (Goal, Key files, Decisions log, Open questions, Completed steps, Notes).
6. Leave the `.bak-<ts>` file in place — historical record.
Per-task template:
```markdown
# <task-slug>
## Goal
One paragraph. What this achieves and why it matters.
## Key files
- `path/to/file.ts` — role in this task
## Decisions log
- <today>: migrated from flat STATUS.md via setup-tasks@<version>
## Open questions
- [ ] (fill in)
## Completed steps
- [x] (fill in)
## Notes
```
### Phase 5 — Verify
After writes:
- `.tasks/STATUS.md` exists and has the emoji status legend (or template comment block in greenfield).
- For migrate: each task referenced in STATUS.md has its `<task-slug>.md` file (active and paused only).
- No required content was lost (the `.bak` file is the safety net).
If verification fails → restore from `.bak-<ts>` and report.
### Phase 6 — Report
Print final state:
```
✅ Tasks board ready at .tasks/.
Mode: greenfield | migrate
STATUS.md: <created | rewritten + .bak-<ts>>
Per-task files: <count>
Next steps for the user:
• Add or edit task entries in .tasks/STATUS.md
• Read using-tasks SKILL.md if unfamiliar with the workflow
```
If invoked from `project-bootstrap`, return control silently.
## Rollback
1. `rm -rf .tasks/` (greenfield rollback)
or
`mv .tasks/STATUS.md.bak-<ts> .tasks/STATUS.md` (migrate rollback) and `rm .tasks/<task-slug>.md` for any newly created per-task files.
2. `git reset HEAD .tasks/` if a git repo.
3. Tell user what failed.
## Common mistakes
- **Auto-parsing existing flat STATUS.md.** Don't. The format varies, real work is at stake — drive migration through the user, one task at a time.
- **Inventing task slugs / branches / "where you stopped" values.** Never. Ask the user. The whole point of `.tasks/` is *real* preserved context, not hallucinated context.
- **Skipping confirmation on greenfield.** Yes, even greenfield needs the gate — the user might be running this in the wrong directory.
- **Creating per-task files at bootstrap.** Don't pre-generate empty `<slug>.md` files in greenfield mode — wait until the user adds actual tasks.
- **Editing the `.bak` file.** It's the rollback artifact; leave it alone.
## Cross-platform notes
The procedure is platform-agnostic. Wiki-style paths (`.tasks/...`) work the same on Windows / Linux / macOS. The only platform-conditional command is the timestamp generator (`date +%Y%m%d-%H%M%S` in bash; equivalent in PowerShell), and our scripts use bash via git-bash on Windows.
## Source
The canonical pattern (extended documentation, decisions log format, agent operations) lives in this repo at `.wiki/raw/setup-task-status-wiki.md`. Refer to it when designing project-specific extensions.