agentleFS
waynesuttonwaynesutton/convexskills/skills/project-docs/SKILL.md

project-docs

Skill405 starsChanged 45 days agoApache-2.0View on GitHub

Brings task.md, changelog.md, and files.md back in sync with what the code says shipped. Reads git history and the working tree, never memory, and refuses to log features it cannot see in source. Use when a feature or fix lands, when the user says "update the docs", "sync changelog", "update files.md", "@update", or when task.md and the code disagree.

  • Reads credentials

22 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use test-audit, to-issues and 3 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • BlockSkill

    test-audit

    Invoke whenever writing, changing, reviewing, or sweeping tests in buzz-app. Authoring gate for new tests plus audit workflow for low-value, implementation-coupled, or duplicative tests and the test-only production seams they demand.

    Also in 3 projects that use this

  • GoogleSkill

    to-issues

    Break a plan, spec, or PRD into independently-grabbable issues on the project issue tracker using tracer-bullet vertical slices.

    Also in 3 projects that use this

  • GoogleSkill

    to-prd

    Turn the current conversation into a PRD and publish it to the project issue tracker — no interview, just synthesis of what you've already discussed.

    Also in 3 projects that use this

  • Google CloudSkill

    triage

    Gather context on a change or bug and plan the implementation.

    Also in 3 projects that use this

  • BlockSkill

    frontend-design

    Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, or applications. Generates creative, polished code that avoids generic AI aesthetics.

    Also in 3 projects that use this

The file

Show its rules and text

We split this skill into the rules it gives an agent

18 rules. 0 are common, 12 are distinctive, and 6 are very specific to this project.

  • 0

    Common

    Most of the 17 edited versions we read keep these.

  • 12

    Distinctive

    This author's own choices. Worth a look.

  • 6

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Read all three files as they are.

    line 22
  2. Distinctive:

    Update each file. Rules below.

    line 23
  3. Distinctive:

    Check idempotency. If nothing new landed since the last entry, change nothing and say so.

    line 24
  4. Distinctive:

    Never delete history. Old completed items stay.

    line 34
  5. Very specific:

    If task.md does not exist, create it with the three headings and the current change under Completed or In Progress based on the evidence.

    line 35
  6. Very specific:

    Keep a Changelog format. ## [Unreleased] at the top, then ## [x.y.z] - YYYY-MM-DD blocks, each with ### Added, ### Changed, ### Fixed, ### …

    line 39
  7. Distinctive:

    Write for the user of the project, not the author.

    line 42
  8. Distinctive:

    Do not log dependency bumps, formatting, or generated files unless they change behavior.

    line 44
  9. Very specific:

    If a version bump exists in package.json with no matching heading, add the heading.

    line 45
  10. Distinctive:

    Add every new source file from the diff.

    line 60
  11. Distinctive:

    Keep each description under one line.

    line 63
  12. Very specific:

    When the repo has a convex/ folder, the changelog and files.md can name Convex features, but only ones the source proves.

    line 67
  13. Very specific:

    Prefer none over an invented value.

    line 77
  14. Very specific:

    Never open .env, .env.local, or any secret store to fill in a doc.

    line 83
  15. Distinctive:

    Never include API keys, tokens, email addresses, phone numbers, street addresses, private hostnames, or application data records.

    line 84
  16. Distinctive:

    Never commit, push, deploy, publish, or tag.

    line 91
  17. Distinctive:

    Never rewrite older entries for tone.

    line 92
  18. Distinctive:

    Do not call production APIs or query live data to make the docs richer.

    line 93

“Common” is measured: kept by at least 6 in 10 of the 17 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Project docs

Three files describe a project to the next person who opens it. Keep them true.

FileAnswers
task.mdWhat is planned, in flight, and done
changelog.mdWhat changed for users, by version and date
files.mdWhat each file is for

Truth comes from the repo, not from the conversation. If the diff does not show it, it did not ship.

Run the sync

  1. Find the root. git rev-parse --show-toplevel, or the workspace root without git.
  2. Collect evidence. git log --date=short -n 20, git status --short, git diff --stat, and for the current change git diff HEAD --stat or the staged diff. See references/evidence-rules.md for what counts.
  3. Read all three files as they are. Note the last logged date and the last completed task.
  4. Update each file. Rules below.
  5. Check idempotency. If nothing new landed since the last entry, change nothing and say so.
  6. Scan for secrets and personal data before saving. See the redaction section.
  7. Report in a few lines. Show the new changelog entry or say the docs were already current.

task.md

Sections: ## To Do, ## In Progress, ## Completed.

  • Move an item to Completed only if its verification step ran. If the PRD lists a check that has not run, leave it In Progress and say which check is pending.
  • Completed entries: - [x] YYYY-MM-DD HH:mm UTC <what>. <PRD path if any>. <files touched>. Verified: <command or outcome>.
  • Never delete history. Old completed items stay.
  • If task.md does not exist, create it with the three headings and the current change under Completed or In Progress based on the evidence.

changelog.md

Keep a Changelog format. ## [Unreleased] at the top, then ## [x.y.z] - YYYY-MM-DD blocks, each with ### Added, ### Changed, ### Fixed, ### Removed as needed.

  • Dates come from git log --date=short. The release date is the date of the commit that bumped the version, or today's UTC date if it has not been committed yet. Never a placeholder, never a future month.
  • Write for the user of the project, not the author. "Uploads over 5 MB now show a progress bar" beats "refactored upload hook".
  • One line per change. Group related commits.
  • Do not log dependency bumps, formatting, or generated files unless they change behavior.
  • If a version bump exists in package.json with no matching heading, add the heading.

files.md

One line per file that matters. Grouped by folder.

## convex/
- `schema.ts` tables and indexes
- `stats.ts` heartbeat mutation with 10s dedup window, page view inserts

## src/hooks/
- `usePageTracking.ts` sends heartbeats, debounced 5s, path change aware
  • Add every new source file from the diff.
  • Fix descriptions that the diff made wrong.
  • Skip node_modules, _generated, lockfiles, build output, and assets unless they are hand written.
  • Keep each description under one line. What it is for, not how it works.

Convex projects

When the repo has a convex/ folder, the changelog and files.md can name Convex features, but only ones the source proves. references/convex-detection.md lists what file shows what.

Short version:

  • A component counts only if convex/convex.config.ts registers it. A dependency in package.json is not proof.
  • Crons count only if convex/crons.ts exists and registers a job.
  • HTTP actions count only if convex/http.ts has a route.
  • Auth counts only if convex/auth.config.ts or an auth component is present.
  • AI model names count only if code or config names them. Do not guess which model built the app.

Prefer none over an invented value.

Redaction

changelog.md and files.md are often public. Treat them that way.

  • Never open .env, .env.local, or any secret store to fill in a doc. Env var names are fine to mention. Values never.
  • Never include API keys, tokens, email addresses, phone numbers, street addresses, private hostnames, or application data records.
  • Scan the whole file before saving, not just the new lines. Replace any address shaped text with [redacted] and say so in one line.
  • Log behavior, not identifiers. "Signed webhook verification for inbound mail" is fine. The inbox address is not.

Boundaries

  • Edit only task.md, changelog.md, files.md, and PRDs the user points at. Nothing else unless asked.
  • Never commit, push, deploy, publish, or tag. Print the suggested commit message instead.
  • Never rewrite older entries for tone. Fix facts when the evidence contradicts them and flag the correction.
  • Do not call production APIs or query live data to make the docs richer.

Report format

Synced project docs.

changelog.md  added 2.1.0 (2026-09-15): 3 added, 1 fixed
files.md      added 2 files, updated 1 description
task.md       moved 1 item to Completed, 1 still In Progress (verification pending: e2e)

Suggested commit: docs: sync changelog, files, and tasks for 2.1.0

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.