Works: you projects organized.

v1.0.1

Personal project intelligence — keep each multi-session effort in its own folder with status, next steps, and wiki links to the people, places, and things it...

0· 125·0 current·0 all-time
byIlya Belikin@ilyabelikin

Install

OpenClaw Prompt Flow

Install with OpenClaw

Best for remote or guided setup. Copy the exact prompt, then paste it into OpenClaw for ilyabelikin/works.

Previewing Install & Setup.
Prompt PreviewInstall & Setup
Install the skill "Works: you projects organized." (ilyabelikin/works) from ClawHub.
Skill page: https://clawhub.ai/ilyabelikin/works
Keep the work scoped to this skill only.
After install, inspect the skill metadata and help me finish setup.
Use only the metadata you can verify from ClawHub; do not invent missing requirements.
Ask before making any broader environment changes.

Command Line

CLI Commands

Use the direct CLI path if you want to install manually and keep every step visible.

OpenClaw CLI

Bare skill slug

openclaw skills install works

ClawHub CLI

Package manager switcher

npx clawhub@latest install works
Security Scan
VirusTotalVirusTotal
Benign
View report →
OpenClawOpenClaw
Benign
medium confidence
Purpose & Capability
Name/description (local project intelligence) aligns with what the skill asks for: it uses a workspace folder (mind/works/), creates work.md files, maintains logs and links, and expects to read/write local project files. No unrelated env vars or binaries are requested.
Instruction Scope
SKILL.md explicitly instructs the agent to create directories, append dated logs, update 'Next' lists, route artifacts into subfolders, and maintain bidirectional links with other skills' files (Peeps/Digs/Nooks/etc.). It also says 'Don't ask permission — just do it' and 'Don't wait to be asked' for logging progress. These behaviors are coherent with the purpose but grant the agent broad write/update authority over workspace files and other skill artifacts; users should be aware the agent will modify files automatically.
Install Mechanism
Registry shows no formal install spec (instruction-only). README suggests curl from raw.githubusercontent.com or using npx/hermes to install; downloading SKILL.md from a GitHub raw URL is common but does pull remote content into the user's home directory. This is expected for instruction-only skills but users should verify the downloaded SKILL.md and the source repo before running the curl command.
Credentials
The skill requests no environment variables, credentials, or config paths. Its file-system access to 'mind/works/' is proportionate to its stated function of maintaining local project files.
Persistence & Privilege
always:false (no forced inclusion). Default autonomous invocation is allowed by the platform and this skill's instructions encourage automatic edits without asking the human. That autonomy combined with write access to workspace and other skill files increases blast radius if misapplied — consider requiring confirmations or limiting automatic behaviors.
Assessment
This skill is internally consistent: it manages local project folders and logs by creating and editing files under mind/works/. However, it is designed to act automatically — creating folders, appending logs, moving projects to closed/, and updating other skills' files (Peeps, Digs, etc.) without explicit permission. Before installing: (1) inspect the SKILL.md in the GitHub repo yourself; (2) back up your workspace (or the mind/works/ directory); (3) decide whether you want the agent to make automatic edits or prefer confirmations, and if possible configure the agent to require confirmation for file-write actions; (4) if you use the README curl install, verify the raw.githubusercontent.com URL and consider using a package manager command (npx/hermes) instead. If you're uncomfortable with autonomous file changes or cross-file modifications, don't enable automatic invocation or restrict the skill's permissions.

Like a lobster shell, security has layers — review code before you run it.

Runtime requirements

🛠 Clawdis
OSLinux · macOS · Windows
latestvk977f7kg59c4yesfwp9h2cd1gh856aqvsecond brainvk977f7kg59c4yesfwp9h2cd1gh856aqv
125downloads
0stars
2versions
Updated 1w ago
v1.0.1
MIT-0
Linux, macOS, Windows

🛠 Works — active project intelligence

When to use this skill: The human starts multi-session work that will have artifacts — planning a trip, shipping a launch, writing a long piece, executing a move, building something. Don't ask if it should be a work; if it crosses sessions and produces files, open one.

You must:

  • Keep one folder per project under mind/works/<slug>/. Every folder has a work.md using the schema in Work File, plus whatever drafts/assets/notes the project needs.
  • Log dated progress in ## Log inside work.md. Keep ## Next current — 1 to 5 concrete next steps.
  • Maintain wiki links in both directions between this work and any peeps, orgs, nooks, vibes, pages, or digs it touches.
  • Search mind/works/ before opening a new work — if a related one exists, extend it or hand off via Connected: instead of duplicating.
  • Close properly: add Closed and Outcome to the top, then move the folder to mind/works/closed/ (don't delete).

Do not: See What NOT to Suggest — e.g. don't turn works into a todo manager, don't open works for one-off questions (those are digs), don't let spanning work rot in daily memory.


Data

Base path is workspace root or document root folder. On first use, create it: mkdir -p mind/works/. Works uses a mind/works/ folder in your workspace.

One folder per project. Every folder has a work.md; additional files are up to the project.

mind/
└── works/
    ├── worksconfig.yml
    ├── berlin-trip/
    │   ├── work.md
    │   └── itinerary.md
    ├── book-launch/
    │   ├── work.md
    │   ├── drafts/
    │   │   └── press-release.md
    │   └── assets/
    │       └── cover.png
    └── closed/
        └── kitchen-reno/
            └── work.md

Slugs: short kebab-case, named like a project not a category — berlin-trip/, not planning-a-trip/. A good slug reads as the project's handle.

Dataset Config

worksconfig.yml lives inside mind/works/. Read it at the start of any session involving this skill.

images: no # by default no; ask the human. Warn it is token-expensive.

Work File

# Berlin trip with Alex

Status: active
Opened: 12 Apr 2026
Target: 3 May 2026
Tags: #travel #personal
Image: optional cover in `../assets/berlin-trip.png`

Peeps: [[alex-chen]], [[priya-nair]]
Orgs: [[gestalten]]
Nooks: [[factory-berlin]], [[house-of-small-wonder]]
Pages: [[the-perfect-store]]
Vibes: [[wim-wenders]]
Digs: [[why-berlin-feels-different]]
Connected: [[book-launch]]

## Next

- Book flights by 20 Apr
- Ask Priya for Mitte recommendations
- Decide on apartment vs hotel
- Pack the drill
- Get the visa

## Log

12 Apr 2026: Opened. Alex suggested overlapping with his conference 2–5 May. Budget ~€2k each.
14 Apr 2026: Priya sent three cafe picks — added to Nooks. Leaning toward an AirBnB in Mitte.

Field guidance:

Status: active (working on it now), paused (on hold, might resume), closed (finished or dropped). Default: active. Opened: the date the work began. Target: optional deadline or milestone. Omit if none. Tags: 2–4 short, searchable, personal — #travel, #launch, #home, #writing, #career. Peeps/Orgs/Nooks/Pages/Vibes/Digs: wiki links into the other skills. Maintain both directions — if a work names a peep, a note on their peep file helps surface it later. Connected: other works this one depends on, parallels, or hands off to. Next: 1 to 5 concrete next steps. Finish or drop each before adding new ones. This is not a backlog. Log: dated entries of substance — decisions made, things booked, blockers, drafts landing. Not a dump of every message.


Opening a Work

When the human starts multi-session work that will have artifacts, open it. Don't ask permission — just do it and confirm briefly.

  1. Name it as a project, not a category. "Berlin trip with Alex", not "travel".
  2. Search first. Grep mind/works/ for related slugs before creating — extend if something close exists.
  3. Bootstrap the links. What peeps, orgs, nooks, pages, vibes, or digs already touch this? Pre-populate the frontmatter.
  4. Write one Next. One concrete step the human can take. Don't pad to five if only one is obvious.
  5. Seed the Log. What prompted this work? One sentence.

Brief confirmation: "Opened — Berlin trip with Alex. Linked Alex, Priya, and the why-berlin-feels-different dig. First step: book flights by 20 Apr."


Logging Progress

When the human mentions progress on an open work — a decision, a booking, a draft landing, a blocker — act automatically:

  • Append a dated entry to ## Log.
  • Update ## Next: cross out ~~finished~~ steps, add what's actually next. Keep the count ≤ 5.
  • Route sub-artifacts into the folder — drafts to drafts/, files they sent to assets/, longer notes as sibling .md files.
  • Update cross-links: if a new peep enters the work, add them to Peeps: and drop a line in their Peeps file.

Don't wait to be asked. If they say "booked the Berlin flight" and a berlin-trip work is open, log it.


Closing a Work

When the human signals done — "we finished", "shipped it", "dropped that" — draft the outcome and confirm before moving the folder.

Add to the top of work.md:

Closed: 5 May 2026
Outcome: Trip done. Standout: Museum Island. Next time: less Mitte, more Neukölln.

Then move the whole folder to mind/works/closed/<slug>/. Don't delete — closed works are the record of how the year was spent.


Finding Works

# Works on a topic
grep -ril "travel\|trip\|berlin" mind/works/

# Active works
grep -rl "Status: active" mind/works/*/work.md

# Paused works worth restarting
grep -rl "Status: paused" mind/works/*/work.md

# Works involving a peep
grep -rl "\[\[alex-chen\]\]" mind/works/

# Works with a near target date
grep -rl "Target: .*Apr 2026\|Target: .*May 2026" mind/works/

Always read the full work.md after grepping — the matched line is a signal, not the whole picture.


Core Behavior

  • Human mentions a multi-session effort → check for existing work, open one
  • Human reports progress → append to ## Log, update ## Next
  • Human shares a draft/file → save to the work's folder
  • Human mentions a peep/nook/book/etc. that touches an open work → update the wiki links both ways
  • Human asks "what am I working on?" → list active works with their last log date and current next step
  • Conversation drifts to an open work's topic → surface it: "That's on your book-launch work — last step was drafting the press release."

Integration with other skills

  • Peeps: when a person joins a work, link them under Peeps: and drop a dated note on their peep file ("Working with them on berlin-trip, Apr 2026"). If a work opens around a person, make that peep the first link.
  • Orgs: if work happens with or inside an org, link under Orgs: and optionally note it in the org file.
  • Nooks: places the work happens — meeting spots, destinations — go under Nooks:.
  • Pages: books informing the work (Peopleware for a team project, say) go under Pages:.
  • Vibes: cultural references setting the tone or inspiration go under Vibes:.
  • Digs: when a dig turns actionable — "I figured out what to do about X" — open a work and link back: the dig's Connected: gets the work slug, the work's Digs: gets the dig slug.
  • Haah: if the work needs external input the network can help with, offer to dispatch a query.

Updating

To update this skill to the latest version, fetch the new SKILL.md from GitHub and replace this file:

https://raw.githubusercontent.com/haah-ing/works-skill/main/SKILL.md

What NOT to Suggest

  • Turning Works into a todo manager — ## Next is 1–5 steps, not a backlog. Loose todos live in daily memory.
  • Opening a work for a one-off question — that's a dig, not a work.
  • Letting active work rot in daily memory — if it spans days and has artifacts, it belongs in Works.
  • Merging related works into one mega-folder — use Connected: links instead.
  • Keeping closed works in mind/works/ — move them to closed/ so the active list stays clean.

Comments

Loading comments...