agentleFS
tasteraytasteray/skills/CLAUDE.md

skills

CLAUDE.md26 starsChanged 4 months agoMITView on GitHub

Commit directly to main This repository contains skills for TasteRay's psychological profiling capabilities. Skills encode research-backed techniques for understanding users through natural conversation. Each skill has a SKILL.md file with YAML frontmatter: The body contains: - Core principles and philosophy - Research foundations with citations - Specific techniques with examples - Anti-patterns (what NOT to do) - References section linking to detailed reference files Skills are installed via the skills.sh installer: Or install all skills: Proposing the right session setup…

The file

We split this CLAUDE.md into the rules it gives an agent

9 rules. About 0 are common, 7 are distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈7

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Commit directly to main

    line 3
  2. Distinctive:

    Create a directory with the skill name (lowercase, hyphenated)

    line 44
  3. Very specific:

    Add SKILL.md with proper YAML frontmatter

    line 45
  4. Very specific:

    Add reference files in references/ subdirectory

    line 46
  5. Distinctive:

    Update README.md with the new skill

    line 47
  6. Distinctive:

    Use academic citations where possible

    line 66
  7. Distinctive:

    Keep reference files focused on single topics

    line 69
  8. Distinctive:

    If nothing is missing, don't mention resources at all — just do the task.

    line 79
  9. Distinctive:

    Never guess the other side of a cross-repo contract: if the task touches a contract whose other repo is not connected, treat that repo as …

    line 80

≈ “Common” is an estimate: at least 1 in 5 of the 26,980 CLAUDE.md files we read have a rule of the same kind, not the same words. “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
CLAUDE.md

TasteRay Skills Repository

Commit directly to main

Purpose

This repository contains skills for TasteRay's psychological profiling capabilities. Skills encode research-backed techniques for understanding users through natural conversation.

Repository Structure

/
├── .gitignore
├── CLAUDE.md          # This file
├── LICENSE            # MIT License
├── README.md          # Skill catalog and installation
└── <skill-name>/
    ├── SKILL.md       # Main skill file with YAML frontmatter
    └── references/    # Supporting research and technique details
        └── *.md

Skill File Format

Each skill has a SKILL.md file with YAML frontmatter:

---
name: skill-name
description: 'Multi-line description of when to use this skill.
  Include specific use cases and trigger phrases.'
---

The body contains:

  • Core principles and philosophy
  • Research foundations with citations
  • Specific techniques with examples
  • Anti-patterns (what NOT to do)
  • References section linking to detailed reference files

Adding New Skills

  1. Create a directory with the skill name (lowercase, hyphenated)
  2. Add SKILL.md with proper YAML frontmatter
  3. Add reference files in references/ subdirectory
  4. Update README.md with the new skill
  5. Commit directly to main

Installation

Skills are installed via the skills.sh installer:

npx skills add tasteray/skills/<skill-name>

Or install all skills:

npx skills add tasteray/skills

Conventions

  • Use academic citations where possible
  • Include specific conversational examples
  • Document anti-patterns explicitly
  • Keep reference files focused on single topics
  • Cross-reference between related techniques

Session concierge — resource fit-check

Proposing the right session setup is Claude's job, not the user's. When the first real task of a session arrives, check — BEFORE starting work — whether the session has what the task needs:

  1. Infer what the task touches using the resource map below.
  2. Compare with what is actually available: cloned repos, MCP servers (probe via tool search — availability varies per user and environment), skills.
  3. If something relevant is missing, open the reply with a short section "Setup for this task" / "Zestaw na to zadanie" (match the user's language): what's missing, why it matters (one phrase each), and the exact next step written for a non-technical reader. Do it yourself when possible (add_repo tool if present, MCP authorization links); ask the user only for what genuinely requires them. Start any work that can safely proceed in parallel.
  4. If nothing is missing, don't mention resources at all — just do the task.
  5. Never guess the other side of a cross-repo contract: if the task touches a contract whose other repo is not connected, treat that repo as missing.

TasteRay resource map

Repos:

  • tasteray-mvp — the app (Next.js): chat/Ray, onboarding, UI, API; owns the main D1 (tasteray-d1: users, titles, content, notification_log). PRs target preview, never main.
  • tasteray-postman (brain) — cards, scenarios, picker, notification delivery, brain admin dashboard, Janina/Sherlock; own D1 (tasteray-postman-d1) and writes to mvp's D1. Merges to main auto-deploy.
  • tasteray-admin — main admin SPA (separate from brain's dashboard).
  • tasteray-funnels — funnels worker (same D1 binding pattern).
  • skills — TasteRay product skills (elicitation, recommendations); connect only when editing them.

Cross-repo contracts (need BOTH repos in the session):

  • Notifications end-to-end: brain writes notification_log in mvp's D1; the mvp bell reads it.
  • Cards iframe: mvp /cards page ↔ brain ray-feed postMessage protocol ('close-feed', 'no-cards', cards:analytics).
  • Notification deep links /cards?card=<id>: brain generates them, mvp preserves them through login.
Task typeReposMCP / skills
Cards, notifications, scenariostasteray-postman; add tasteray-mvp when touching mvp's D1, deep links, or /cardsCloudflare (prod D1, logs), PostHog
App: chat, onboarding, UItasteray-mvp; add tasteray-postman at card touchpointsai-sdk, natively-expert, PostHog
Main admin paneltasteray-admin + tasteray-mvpGitHub
Data, metrics, reportsusually no repo neededPostHog; Cloudflare for prod D1
Ray profiling skillsskillsdeep-research
PR review / CI babysittingthe PR's repoGitHub MCP, /code-review, subscribe_pr_activity

MCP notes: PostHog, GitHub, Slack, Gmail, Drive and Calendar are usually already connected in web sessions. Cloudflare Developer Platform and Linear are installed but need a ONE-TIME OAuth login — when relevant, generate the authorization link and walk the user through it. GitHub MCP scope follows the session's repos.

Adding a missing repo mid-session: use the add_repo tool (claude-code-remote MCP) if available; otherwise tell the user, in plain words, to start a new session from an environment that includes the needed repos.

Duplicated verbatim in the CLAUDE.md of tasteray-mvp, tasteray-postman, and skills so it loads regardless of which repo the session includes — update all copies together.

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.