agentleFS
from68from68/claude-portfolio-management-skills/CLAUDE.md

claude-portfolio-management-skills

CLAUDE.md0 starsChanged 3 months agoMITView on GitHub

Claude Code plugin with stock-screening and portfolio-analysis skills. Skills live in skills/<name>/SKILL.md, agents in agents/, manifests in .claude-plugin/. Everything here is prose that Claude reads at runtime — there is no build and no test suite. Two remotes, and they are not interchangeable: Never push main, a task branch, or anything else carrying main's history to github. The development history contains personal data. The public repo receives one squashed commit per release and nothing else — no merges from main,…

  • Installs packages
  • Commits and pushes

The file

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

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

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈0

    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. Very specific:

    After pushing, advance the local ref with git pull --ff-only in the worktree that owns publish.

    line 49
  2. Very specific:

    Keep private hostnames, internal repo paths, real portfolio files and account details out of every committed file — the whole tree goes …

    line 54

≈ “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

CLAUDE.md

Claude Code plugin with stock-screening and portfolio-analysis skills. Skills live in skills/<name>/SKILL.md, agents in agents/, manifests in .claude-plugin/. Everything here is prose that Claude reads at runtime — there is no build and no test suite.

Publishing — read this before any push

Two remotes, and they are not interchangeable:

RemoteVisibilityBranchContents
originprivate, internal git servermainfull development history
githubpublicmain ← local publishsquashed release commits only

Never push main, a task branch, or anything else carrying main's history to github. The development history contains personal data. The public repo receives one squashed commit per release and nothing else — no merges from main, no cherry-picked ranges of internal commits, no git push github main.

publish is the only branch that may be pushed to github. Each of its commits is a single squashed snapshot of main's tree, so the public repo's history is a list of releases, never a list of internal commits.

Releasing

Bump the version in both .claude-plugin/plugin.json and .claude-plugin/marketplace.json (they must match), commit that on main, then:

git fetch github
git checkout --detach github/main   # base on the remote, not the local publish ref
git read-tree -u --reset main       # take main's tree wholesale, including deletions
git diff --cached --stat            # review: this is exactly what goes public
git commit --no-verify -m "<one-line release summary>"
git diff --stat HEAD main           # must print nothing
git push github HEAD:main
git checkout -

read-tree + one commit is what keeps it to a single commit; do not merge, cherry-pick or rebase from main onto publish.

Notes:

  • Base the commit on github/main, not on local publish. publish is checked out in the primary worktree and goes stale whenever a release is pushed from a git worktree, which would turn the next push into a non-fast-forward.
  • After pushing, advance the local ref with git pull --ff-only in the worktree that owns publish. Never move the publish ref from a worktree that does not own it — its files would read as a pending revert of the release.
  • The pre-commit hook blocks every git commit without --no-verify; the version bump it asks about is the one described above.
  • Keep private hostnames, internal repo paths, real portfolio files and account details out of every committed file — the whole tree goes public at the next release. .gitignore already excludes *.xml, Shortlist/ and Stock Screener/.

Editing skills

  • A skill's description is its trigger. Changing it changes when the skill fires, so edit it deliberately and keep the existing trigger phrases.
  • quick-stock-analysis always evaluates all five gates and reports a score out of five — it never short-circuits on a failing gate.
  • portfolio-management installs the pp CLI (go install github.com/from68/pp-cli/cmd/pp@latest) at the start of every run that reads a Portfolio Performance file.
  • Market data comes from the FMP and IBKR MCP connectors only. Never add a WebSearch or scraping fallback for a number that belongs in a metrics table.
  • No .mcp.json ships with this plugin — connectors are configured per user in Claude.

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.