LLMSkillHub
mirroredCopied from Pratiyush/llm-wiki under MIT. Pratiyush has not claimed this page, and is not affiliated with LLM SkillHub.

pratiyush / project-maintainer

Maintain an llmwiki-style open-source project across the full framework pipeline. Use when the user says "maintain the project", "check my tasks", "update progress", "run phase gate", "do a monthly verify", "lint my wiki", "check stale entries", or invokes any form of ongoing project-keeping chore. Reads _progress.md, tasks.md, docs/roadmap.md, and .github issues to figure out what's next and what's drifted.

0
SKILL.md
5.7 KB
⚠This file contains 1 character(s) that do not render as themselves (U+FE0F). They are shown highlighted below.

project-maintainer

What this skill does

The Maintainer owns the full Open Source Framework v4.1 pipeline on a project. Given the current repo state, it:

  1. Audits phase gates — are we in the right phase? Are the deliverables for the current phase complete?
  2. Reconciles task tracking — keeps tasks.md, _progress.md, and GitHub issues in sync (the framework's "dual-tracking" rule).
  3. Runs stale checks — flags content, links, and claims older than the stale threshold.
  4. Triggers CI — re-runs the privacy grep, performance budget check, and link checker.
  5. Reports next action — tells the user exactly what to do next and why.

It works for any project that follows the framework — not just llmwiki.

When to invoke

  • "Maintain the project" / "maintenance check" / "do a health check"
  • "Update progress" / "reconcile tasks" / "sync tasks"
  • "Check phase gate" / "can I move to the next phase"
  • "Lint the wiki" / "check for stale entries"
  • "Monthly verify" / "quarterly review"
  • Any time the user is unsure what to work on next

Framework phase awareness

PhaseThe Maintainer's job in this phase
0 CaptureVerify idea-brief.md exists and names target users + the 10x mechanism
1 ValidateVerify scorecard /25 is in _progress.md and ≥20
1.25 ResearchVerify .temp/ has at least 10 cloned reference repos and docs/research.md exists with a gap matrix
1.5 SteeringVerify _progress.md has "Key Decisions" table filled in
1.75 Agent SurveyFor agent-native tools — verify adapter compatibility matrix exists
2 BrandVerify README.md, LICENSE, and badges are in place
3 StructureVerify folder layout matches docs/architecture.md
4 ContentTrack which M items in docs/roadmap.md are ✅ vs [ ]
5 ContributionVerify CONTRIBUTING.md, PR template, issue templates, CI workflow
5.25 Adapter FlowFor agent-native tools — verify adapter contract doc + at least one community contribution example
5.5 Pre-Launch QARun the full QA checklist from docs/framework.md
6 LaunchVerify git tag + GitHub Release + social posts drafted
6.5 Self-DemoVerify GitHub Pages workflow triggered and live URL returns 200
7 GrowTrack stars / forks / downloads week-over-week
7.5 Living KnowledgeVerify public wiki is updating on release
8 MaintainRun monthly verification, merge PRs, update stale entries

Workflow

  1. Locate the project root. Look for _progress.md in the current dir or its parents. If missing, tell the user this skill needs a project that follows the framework.

  2. Read the state files:

    • _progress.md — current phase + phase status table
    • tasks.md — Kiro-style tasks with [ ]/[/]/[x]/[-] markers
    • docs/roadmap.md — if present, the master MoSCoW table
    • CHANGELOG.md — latest release
  3. Audit each phase gate up to the current phase. For each phase marked done, verify the deliverable file exists and is non-empty. Report any gaps.

  4. Reconcile task tracking:

    • Are there items in tasks.md marked [x] but not in CHANGELOG.md?
    • Are there open GitHub issues with no matching task in tasks.md?
    • Are there tasks in tasks.md with no corresponding GitHub issue?
    • If any drift — propose fixes before making any changes.

  5. Run stale checks:

    • Any last_updated in wiki frontmatter older than 30 days? Flag.
    • Any source_file reference in wiki pointing to a file that no longer exists? Flag.
    • Any entity page mentioned in 3+ sources but with its own last_updated older than the newest source? Flag.
    • Any [[wikilink]] pointing to a non-existent page? Flag.

  6. Run CI gates locally (if configured):

    • Privacy grep: grep -r "<real_username>" site/ wiki/ must be empty
    • Link check: python3 -m llmwiki lint-docs (when implemented)
    • Performance budget: build time <15s, HTML <50MB

  7. Write the report. Structure:
    `
    ## Health report: <project> — <date>

    Phase: <current phase> (<status>)

    ### ✅ Green

    • <things that are fine>

    ### ⚠‹VARIATION SELECTOR U+FE0F› Yellow

    • <minor drift that should be fixed soon>

    ### ❌ Red

    • <broken gates that block progress>

    ### Next action

    1. <specific thing the user should do next>
    2. <second thing if any>
  8. Offer to fix green issues automatically. For yellow/red, ask before touching anything.

Hard rules

  1. Never silently update _progress.md. Always explain what changed and why.
  2. Never close a GitHub issue without the user saying so.
  3. Never overwrite tasks.md without showing the diff first.
  4. Respect the framework's "one PR per concern" rule — if a fix spans multiple files, surface it as multiple suggestions, not one big patch.
  5. Never auto-bump versions. Version bumps are a launch activity, not maintenance.

Related skills

  • self-learn — when a new pattern emerges during maintenance, pipe it to self-learn to potentially add it to the framework.
  • llmwiki-query — when you need context from past sessions on why a decision was made.
  • llmwiki-lint — for wiki-specific lint work (overlaps with step 5).