| name | landscape-update |
| description | Update a single project's metadata from GitHub API โ sync stars, license, description, topics, and activity data. |
Update Project in AI Native Landscape
Sync a single project's metadata from its GitHub repository. Keeps the landscape data fresh without re-adding the project.
When to Use
- User says "update project", "sync project", "refresh project"
- User provides a slug and wants latest data:
landscape-update langchain
- User says "ๆดๆฐ้กน็ฎ", "ๅๆญฅ้กน็ฎ"
- Periodic maintenance to keep metadata accurate
- After a project has a major release or rebranding
Steps
Step 1: Identify the Project
Accept project identifier (same as archive skill):
- Slug (preferred):
landscape-update langchain
- Name (partial):
landscape-update "LangChain"
- Repo URL:
landscape-update https://github.com/langchain-ai/langchain
If slug not given, find it:
grep -rl "name:.*<partial-name>" data/projects/ | head -5
grep -rl "github.com/<owner>/<repo>" data/projects/
Step 2: Read Current Data
head -25 data/projects/<slug>.en.md
Note current values for: name, description, license, tags, homepage, author, ossDate.
Step 3: Fetch Fresh GitHub Data
gh repo view <owner>/<repo> --json name,description,homepageUrl,licenseInfo,stargazerCount,repositoryTopics,owner,createdAt,updatedAt,isArchived,isArchivedAt,latestRelease
Extract:
name โ may have changed
description โ GitHub description
homepageUrl โ project website
licenseInfo.spdxId โ license identifier
repositoryTopics[].name โ GitHub topics โ tags
owner.login โ author/org
isArchived โ if true, suggest archiving
latestRelease.tagName / latestRelease.publishedAt โ latest release info
updatedAt โ last push/activity timestamp
Step 4: Compare and Determine Changes
Compare GitHub data vs current frontmatter:
| Field | Update if |
|---|
name | Changed on GitHub |
description | GitHub description differs |
license | SPDX ID changed |
tags | GitHub topics changed significantly |
homepage | URL changed |
author | Org renamed |
status | GitHub isArchived is true |
Present changes to user before applying. Format:
Changes for <slug>:
name: "Old Name" โ "New Name"
license: "MIT" โ "Apache-2.0"
tags: +[new-tag] -[removed-tag]
homepage: null โ "https://new-site.com"
Step 5: Apply Updates to Both Files
Update frontmatter in both files:
data/projects/<slug>.en.md
data/projects/<slug>.zh.md
English file โ update description with English description from GitHub.
Chinese file โ translate new description if it changed. If description changed, provide updated Chinese translation.
If tags changed:
- Keep manually-added tags that aren't from GitHub
- Add new GitHub topics
- Remove topics no longer on GitHub (unless manually added)
Special handling:
- If
isArchived is true on GitHub โ warn user, suggest running landscape-archive
- If
homepage changed โ update both files
- If
name changed โ update name field, but keep slug unchanged
Step 6: Update Content Sections (Optional)
If user requests full content refresh:
- Fetch README:
gh repo view <owner>/<repo> --json readme
- Re-generate content sections based on README
- Update
## Overview, ## Key Features, ## Use Cases, ## Technical Details
- For Chinese file, translate updated sections
Step 7: Validate and Build
npm run validate
npm run build
Step 8: Report
Summarize what changed:
- Fields updated (list old โ new)
- Files modified
- Validation/build status
- If project is archived on GitHub, recommend
landscape-archive
Batch Update
Update multiple specific projects:
- Accept comma-separated slugs or "all tracked"
- For each project, run Steps 2-5
- Present all changes at once
- Apply after confirmation
- Validate and build once
Error Handling
| Error | Fix |
|---|
| Slug not found | List matches, ask user |
| GitHub repo not found | Repo may be deleted, suggest archiving |
| GitHub API rate limit | Wait and retry, or use cached data |
| No changes detected | Report "already up to date" |
| License "NOASSERTION" | Set to "Unknown", note in report |