Codify the repetitive labor of "manually reviewing all projects and data every week". The scenario this skill targets is very specific—every week you have to manually cd go into a dozen or so repos to check git log, dig through content data, and keep in your head where each of your business lines stands, and after reviewing you often end up with a pile of play-by-play with no conclusion. What this skill replaces is exactly this manual work of scanning + judging.
Your stance: taking stock is forjudging, not for listing. Anyone can list 20 commits; what's valuable is that one line: "the only thing truly advanced this week was core product billing, everything else was maintenance work". The final output is decision input, not an activity log.
Usage
/ray-weekly # 默认盘最近 7 天(上个周一至今)
/ray-weekly 2026-07-01..07-07 # 指定日期范围
/ray-weekly 上周 # 自然语言范围也认
First determine the time window (default "1 week ago" to now), then take four steps. Project classification map and ready-made scan commands → read references/project-map.md, don't type repo paths from memory.
Step 1: Project activity—active vs dormant
Scan your project root directory (e.g. ~/projects/<类别>/) for each repo's commits this week, and sort repos into three tiers:
- Active: has commits within the window. Note the commit count + what the last commit was doing (look at the message, not the count).
- Dormant: zero commits within the window, but not an archived project. Pay attention to these—still being pushed last week, stopped this week, that's a signal.
- Archived: anything under the archive directory (e.g.
_archive/) is excluded entirely, not counted as "dormant" to create anxiety. Archived = actively stopped, not stalled.
⚠️ Key distinction:dormant ≠ archived. Repos in the archive directory are normal no matter how long they've been untouched, don't list them under "stalled this week". Conversely, an active business repo suddenly untouched for a week is what deserves to be flagged separately with the question "why".
Scan commands (batch-run git log by category, list each repo's last commit time) are in references/project-map.md. dist artifacts, node_modules, and non-git directories are skipped automatically.
Step 2: Content / IP data
Pull the quantitative side of this week's external content:
- Social media data: prefer calling
/ray-metrics(if ready) to pull this week's follower growth, impressions, engagement, top posts; if not available, have the person provide it or skip, don't hardcode numbers. - Other platforms: WeChat Official Account, knowledge base (e.g. Feishu/Notion), Xiaohongshu, etc., include any that have data.
- Data is for looking attrends and anomalies, not for copying ledgers: which piece of content took off, is follower growth accelerating or flat, has there been a posting gap.
Ledger discipline: all numbers are based on what you provide or what tools actually pull.Don't fabricate, don't estimate, don't say "gained a few hundred followers, roughly". If you can't pull it, write "social media data not pulled this week"; leaving a blank is better than making things up. This is a hard line—your ledger tolerates no guessing.
Step 3: Business line status
First, clearly define the business/focus lines you yourself have set (usually 2-4, such as "core product/monetization line", "service/consulting line", "influence/content line"). For each line, judge this weekwhether there was substantive progress(not "did you think of it", but "did any action land"):
| Line (example prototype) | What counts as progress this week | Corresponding project/signal |
|---|---|---|
| Product / monetization line | New payments/renewals, billing or deployment changes, traffic brought by lead-generation tools | Commits in the core product repo + customer updates reported by the person |
| Service / consulting line | New leads, diagnosis/solution delivery, payment collection, case progress | /ray-diagnose·/ray-proposal actual usage + consulting progress reported by the person |
| Influence / content line | Content output and data, influence actions, assembly draft landing | Content pipeline repo, Step 2 data, knowledge base updates |
The table above isan example prototype, not a fixed route—replace it with the lines you actually focus on. For each line, give a one-sentence conclusion + a direction marker (progress ↑ / flat → / stalled ↓).
⚠️ Note: some lines (typically the consulting/service line) often make progressnot reflected as git commits(they are offline delivery, payment collection, verbal progress), so you must judge based on the information provided by the person, and cannot judge it as stalled just by looking at the repo.
Honesty first: if a line truly did not move this week, write "stalled ↓, no action this week",do not scrape together "progress" from scraps just to make every line look bright. A line stopping is itself the most valuable signal—it tells you where your attention leaked this week. Forcing progress is self-deception and directly destroys the usefulness of this skill.
Step 4: Comprehensive wrap-up
This is the only step that truly requires thinking; the first three steps are all preparing material for it. Produce four sections:
- What actually moved this week(≤5 items, judgment not a running account): condense a pile of commits into a few conclusions. "Launched tiered billing" is one item; "fixed 3 typos, updated README" is merged into "maintenance actions" in one sentence or omitted. Distinguishadvancingactions frommaintenanceactions.
- Which line is advancing, which is stopping: directly cite the direction markers from Step 3, and point out where this week's attention actually landed and where it leaked.
- Next week's focus (≤3 items): few and solid. Each item is a concrete actionable action, not a slogan like "pay more attention to content".Better to write only 1 item that can truly be pushed than to pad 3 items and dilute them. Greed = another week of accomplishing nothing next week. Focus comes from "lines stalled this week + lines with momentum that should be doubled down on", not from moving over everything unfinished.
- Worth noting(optional): a one-off lesson, an unexpected signal, a fork in the road that needs a decision.
Output form
By default, output a structured piece of text (the four-section wrap-up first, with project/data/business line details afterward for traceability), directly readable in the terminal. If it needs to be archived as a document or long image, discuss separately.
If you want to turn the review into a publicly published "this week's progress" post: that crosses the boundary of functional output and enters persona voice. In that case,only deliver the assembly skeleton + materials(which items are worth telling externally, data points, timeline), leave the viewpoint and tone 【你的话:____】 as blanks for you to fill in yourself. Internal retrospectives can be fully delivered; external statements are not ghostwritten.
Discipline
- Judgment > listing: deliver conclusions, not commit logs. Producing a "running account with no conclusions" is as good as not doing the retrospective at all.
- The ledger is based on you: numbers are pulled for real or given by the person themself; if they cannot be pulled, leave them blank. Never fabricate, never question the numbers you report.
- Honestly mark stagnation: if a line has stopped, say it has stopped; do not force progress. Stagnation is a signal, not a failure.
- Focus on ≤3 and make them real: few but real, actionable. A focus padded to make up numbers is worse than not writing one.
- Archiving does not count as stagnation: archive directories (such as
_archive/) are excluded from the activity review.
When not to use it
- To dig deep into the progress of a particular project → go directly into that repo; do not start a global review.
- To write a progress post for external publication → this skill only goes as far as the skeleton; the flesh and blood go through no ghostwriting.
- Cross-quarter / strategic-level retrospectives → that is direction calibration on a larger scale, not a review of one week's activity.