zazzcodezazzcode/zazz-skills/.agents/skills/gh-wiki/SKILL.md

gh-wiki

Skill4 starsChanged 4 months agoMITView on GitHub

Placeholder workflow guidance for repos that use GitHub Wiki as a durable documentation surface; use when updating, promoting, or reviewing project overview, architecture, feature, roadmap, milestone, proposal, standard-summary, or completed-specification wiki pages. Does not assume live automation beyond repo-declared GitHub Wiki access.

In this repository21 other files it gives its agents.
- templates/AGENTS.mdAGENTS.md
- architecture-doc-builderSkill
- confluenceSkill
- conformanceSkill
- doc-checkSkill
- feature-doc-builderSkill
- gh-issueSkill
- gh-stackSkill
- handoffSkill
- jiraSkill
- pr-builderSkill
- proposal-builderSkill
- pr-reviewSkill
- psqlSkill
- qa-testingSkill
- spec-builderSkill
- spec-drivenSkill
- sqlcmdSkill
- standard-builderSkill
- worktreeSkill
- zazz-boardSkill

The file

We split this skill into the rules it gives an agent

8 rules. About 0 are common, 5 are distinctive, and 3 are very specific to this project.

≈0
Common · estimate
Many files like this have a rule of this kind.
≈5
Distinctive · estimate
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.

Common
Distinctive
Very specific

Distinctive:
Use this skill when a repo's AGENTS.md declares GitHub Wiki as the durable surface for project knowledge or completed specifications.
line 8
Distinctive:
Read AGENTS.md and confirm GitHub Wiki is the declared source of truth for the artifact type you are touching.
line 17
Distinctive:
Read the current wiki page or repo pointer before drafting changes.
line 23
Distinctive:
If wiki access, naming, or responsibility is unclear, ask the responsible human instead of inventing a page path.
line 24
Very specific:
Keep local working specifications under <DOCS_ROOT>/specifications/.
line 29
Very specific:
Do not put RUN_LOG files, QA notes, handoffs, recovery notes, evidence captures, or scratch analysis into durable wiki pages.
line 31
Distinctive:
Do not use the wiki as public user-facing documentation unless the repo explicitly says that is its product-doc surface.
line 35
Very specific:
If a contract changes during implementation, update the specification body and Implementation And Review Change Log first.
line 37

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

Keep what fits and drop the rest. Your version, ready for your agents.

Files

SKILL.md

GitHub Wiki Skill

Use this skill when a repo's AGENTS.md declares GitHub Wiki as the durable surface for project knowledge or completed specifications.

This is a placeholder workflow skill. It does not provide a custom API client. Follow the repo-declared GitHub Wiki workflow and use normal Git/GitHub tooling only when access and instructions are explicit.

Startup Sequence

Read AGENTS.md and confirm GitHub Wiki is the declared source of truth for the artifact type you are touching.
Identify the artifact type: project overview, architecture, feature requirements, roadmap, milestone, proposal outcome, completed specification, or standards summary.
Find the wiki entry point, page naming convention, and update authority declared by the repo.
Read the current wiki page or repo pointer before drafting changes.
If wiki access, naming, or responsibility is unclear, ask the responsible human instead of inventing a page path.

Rules

Keep local working specifications under <DOCS_ROOT>/specifications/; promote or mirror final implemented specs to GitHub Wiki only when the repo declares that policy.
Do not put RUN_LOG files, QA notes, handoffs, recovery notes, evidence captures, or scratch analysis into durable wiki pages.
Preserve stable links back to source PRs, merge commits, tracker records, and governing specs when available.
Do not use the wiki as public user-facing documentation unless the repo explicitly says that is its product-doc surface.
If a contract changes during implementation, update the specification body and Implementation And Review Change Log first; update the wiki after the durable outcome is accepted or merged.

Output

Produce either:

a wiki page update through the repo-declared workflow, or
a concise draft/pointer that a human can apply when live wiki access is unavailable.

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.

Check your setup, free