cubox-research
Skill2 starsChanged 2 months agoMITView on GitHub
Search a user's Cubox collection deeply by topic, theme, or question. Use this whenever the user asks to search Cubox, saved articles, archived reads, or collected pages for a subject, wants multiple keyword variations tried, wants full-text search across Cubox, or needs article details exported from Cubox HTML into local Markdown with downloaded images for later analysis.
- Reads credentials
In this repository34 other files it gives its agents.
- agent-native-redesignSkill
- assess-source-project-fitSkill
- brainstormingSkill
- coaching-engineSkill
- codex-skill-creatorSkill
- dev-browserSkill
- diffusion-mapSkill
- exa-web-searchSkill
- executing-plansSkill
- general-skill-creatorSkill
- harnessSkill
- i-diagramSkill
- memosSkill
- merge-and-rebaseSkill
- paseo-relaySkill
- plan-coachingSkill
- plan-meSkill
- plan-reviewSkill
- problem-framingSkill
- prove-itSkill
- pruneSkill
- raise-ambitionSkill
- readwise-researchSkill
- report-coachingSkill
- report-meSkill
- report-reviewSkill
- seeSkill
- shapeSkill
- subagent-driven-developmentSkill
- systematic-debuggingSkill
- test-driven-developmentSkill
- use-remote-skillSkill
- worktree-managerSkill
- writing-plansSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
23 rules. About 0 are common, 13 are distinctive, and 10 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈13
Distinctive · estimate
This author's own choices. Worth a look.
10
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 14
Make sure dependencies are installed once with bun install.
- Very specific: line 15
Check .env before any API call.
- Very specific: line 16
Prefer read-only endpoints.
- Distinctive: line 33
Treat Cubox retrieval like library research:
- Distinctive: line 37
Search in more than one mode.
- Distinctive: line 41
Do not stop after the first hit unless the user explicitly wants a quick lookup.
- Distinctive: line 45
Before searching, create a keyword set that covers multiple angles:
- Distinctive: line 64
If the user already gives candidate terms, still add 2-4 meaningful variations unless doing so would obviously introduce noise.
- Distinctive: line 70
When tags, collections, or browsing context might help, run:
- Distinctive: line 76
Use it to understand available groups and tags before searching.
- Very specific: line 80
Use research when you want one command to search and fetch details:
- Very specific: line 93
Use search when you want to inspect candidates before downloading details:
- Distinctive: line 105
Default behavior searches all three modes:
- Very specific: line 113
When you already know the cardId, fetch a single article:
- Distinctive: line 136
When using this skill for an actual user request:
- Distinctive: line 141
When you fetched details, cite the exported Markdown paths.
- Distinctive: line 143
If results are thin, say so plainly and explain what keyword expansion or narrowing you tried.
- Distinctive: line 147
Use this structure unless the user asks for something else:
- Very specific: line 174
Prefer --json whenever you need to inspect script output programmatically.
- Distinctive: line 175
Use multiple keywords on purpose.
- Very specific: line 176
Use both quick and full-text unless there is a good reason not to.
- Very specific: line 183
Read references/api-map.md when you need the observed endpoint behavior from the HAR.
- Very specific: line 184
Run bun run ./scripts/inspect-har.ts <har-path> if the user supplies a newer HAR and wants the map refreshed.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill 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.
Files
cubox-research
Use this skill when the user's Cubox collection is the source of truth. The goal is not to do one shallow keyword lookup, but to search broadly, vary keywords on purpose, fetch the best-matching article details, and analyze local Markdown instead of raw Cubox HTML.
Preflight
- Work from this skill directory.
- Make sure dependencies are installed once with
bun install. - Check
.envbefore any API call. The only required value isCUBOX_AUTHORIZATION. - Prefer read-only endpoints. Do not call mutation endpoints such as
POST /c/api/norm/card/readunless the user explicitly asks for that side effect.
What The Bundled Scripts Do
scripts/cubox.ts contextFetches account search context: groups, tags, and the overloadedkeyword/listpayload.scripts/cubox.ts searchRuns multiple keywords acrosspreview,quick, andfull-textmodes, then deduplicates and ranks hits.scripts/cubox.ts researchDoes the same search workflow and also fetches article details for the strongest matches.scripts/cubox.ts fetch-detailFetches one Cubox article detail, converts the HTML fragment to Markdown, downloads images locally, and stores the files in the temp collection.scripts/inspect-har.tsRe-summarizes a HAR file into a quick API map when the user provides a fresh capture.
Core Working Style
Treat Cubox retrieval like library research:
- Understand the user's actual topic or question.
- Build a keyword set with deliberate variation.
- Search in more than one mode.
- Fetch article details for the best candidates.
- Analyze the exported Markdown and cite local file paths.
Do not stop after the first hit unless the user explicitly wants a quick lookup.
Keyword Planning
Before searching, create a keyword set that covers multiple angles:
- The direct topic phrase
- Synonyms or alternate wording
- English and Chinese variants when relevant
- Product names, author names, company names, or framework names tied to the topic
- Abbreviations and shorthand terms
- Narrower subtopics if the topic is broad
Good example for a topic like "agent harness":
agent harnessharness engineeringdeep agentsagent evalsskills工具调用智能体评测
If the user already gives candidate terms, still add 2-4 meaningful variations unless doing so would obviously introduce noise.
Retrieval Workflow
1. Optional context pass
When tags, collections, or browsing context might help, run:
bun run ./scripts/cubox.ts context --jsonUse it to understand available groups and tags before searching.
2. Run broad search
Use research when you want one command to search and fetch details:
bun run ./scripts/cubox.ts research \
--topic "agent harness" \
--keyword "agent harness" \
--keyword "harness engineering" \
--keyword "deep agents" \
--keyword "智能体评测" \
--detail-limit 5 \
--jsonUse search when you want to inspect candidates before downloading details:
bun run ./scripts/cubox.ts search \
--topic "台积电营收模型" \
--keyword "台积电" \
--keyword "TSMC" \
--keyword "营收模型" \
--keyword "equity research" \
--jsonDefault behavior searches all three modes:
preview: quick prefix discovery and highlighted matchesquick: title and metadata-oriented retrievalfull-text:正文全文搜索
3. Fetch the strongest candidates
When you already know the cardId, fetch a single article:
bun run ./scripts/cubox.ts fetch-detail --card-id 7433881606177162362 --jsonThe exported files are stored under:
<system temp>/cubox-collection/<cardId>-<safe-title>/Each article directory contains:
article.mdarticle.htmlmetadata.jsonimages/
This is the preferred format for analysis. Read the Markdown, not the raw HTML.
Output Expectations
When using this skill for an actual user request:
- Tell the user which keyword families you tried.
- Mention which search modes found the strongest hits.
- Cite the most relevant article titles and why they matter.
- When you fetched details, cite the exported Markdown paths.
- Synthesize findings instead of dumping raw search results.
- If results are thin, say so plainly and explain what keyword expansion or narrowing you tried.
Reporting Pattern
Use this structure unless the user asks for something else:
# Cubox Topic Memo: <topic>
## Search Strategy
- keywords tried
- why those variants were chosen
## Strongest Matches
- title, why it is relevant, and where it was found
## Detailed Takeaways
- key idea with evidence from exported Markdown
## Gaps Or Weak Signals
- what was missing
- what other keywords or filters might helpRules That Matter
- Prefer read-only endpoints.
- Prefer
--jsonwhenever you need to inspect script output programmatically. - Use multiple keywords on purpose; do not rely on a single literal phrase.
- Use both
quickandfull-textunless there is a good reason not to. - Deduplicate by
cardId, not by title alone. - Analyze
article.mdafter fetching details. The script has already converted the Cubox HTML fragment and downloaded images. - Remember that article exports are grouped under
tmp/cubox-collection/, not flat in the temp root.
Reference Files
- Read
references/api-map.mdwhen you need the observed endpoint behavior from the HAR. - Run
bun run ./scripts/inspect-har.ts <har-path>if the user supplies a newer HAR and wants the map refreshed.
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
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.

