New: 98,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Wf Spec Wrapup

by changkun in changkun/wallfacer

Close out a finished spec: write the Outcome section, move the status through the testing gate to complete, update specs/README.md, and commit.

MITAuto-check passedDevelopment

Install Wf Spec Wrapup

skills CLI
$ npx skills add changkun/wallfacer --skill wf-spec-wrapup -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install changkun/wallfacer wf-spec-wrapup --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/changkun/wallfacer.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.claude/skills/wf-spec-wrapup .claude/skills/wf-spec-wrapup && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
wf-spec-wrapup
GitHub stars
112
Token cost
~2.4k tokens
SKILL.md length
1,297 words
Files
1
Skills in repo
14
Repo updated
First seen
Licence
MIT

At a glance

Close out a finished spec: write the Outcome section, move the status through the testing gate to complete, update specs/README.md, and commit.

  • Works in 6 steps: Verify completion → Update the parent spec → Update specs/README.md → …
  • The work is genuinely done
  • SKILL.md covers Step 1: Verify completion, Step 2: Update the parent spec, Step 3: Update specs/README.md and Step 4: Check downstream specs…, plus 3 more sections
  • Calls git

What it does

Wf Spec Wrapup is an agent skill from changkun/wallfacer. Close out a finished spec: write the Outcome section, move the status through the testing gate to complete, update specs/README.md, and commit. Reconstructs from task notes or from git history. Writes and commits. Use when the work is genuinely done; use drift when the point is to record divergence rather than to finish.

Its SKILL.md is about 2.4k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Development, covering Git workflow and Technical documentation. The repository describes itself as: Chat, specs, tasks, and code. An autonomous engineering platform. Full autonomy when you trust it. Full control when you don't. The licence is MIT.

When your agent uses it

  • The work is genuinely done
  • Use drift when the point is to record divergence rather than to finish

Example prompts

  • “/wf-spec-wrapup”

Workflow steps

6 steps, taken from the step headings in SKILL.md.

  1. Verify completion
  2. Update the parent spec
  3. Update specs/README.md
  4. Check downstream specs (reverse dependency analysis)
  5. Commit
  6. Report

What it can do on your machine

Read from SKILL.md and the folder at commit 5b3cea1. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • git

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use git, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Wf Spec Wrapup loads about 2.4k tokens when it runs. Until then it costs about 84 tokens; SKILL.md has 1,297 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~84
When it runs · the whole SKILL.md, loaded when a task matches
~2.4k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from changkun/wallfacer at commit 5b3cea1, republished under its MIT licence (© changkun). 1,297 words, ~2,407 tokens.

Download SKILL.mdSave it as .claude/skills/wf-spec-wrapup/SKILL.md (or your agent's skills folder).
name
wf-spec-wrapup
description
Close out a finished spec: write the Outcome section, move the status through the testing gate to complete, update specs/README.md, and commit. Reconstructs from task notes or from git history. Writes and commits. Use when the work is genuinely done; use drift when the point is to record divergence rather than to finish.
argument-hint
<spec-file>
user-invocable
true

Wrap Up a Completed Spec

Finalize the spec at $ARGUMENTS after all implementation tasks are done.

Step 1: Verify completion

  1. Read the spec file. Parse YAML frontmatter to extract title, status, depends_on, affects, effort, created, updated, dispatched_task_id.

  2. Detect the lifecycle path — a spec reaches "done" two ways, and the Outcome source differs:

    • Dispatched path — a child spec directory exists (sibling directory with the same name as the spec file without .md), and/or leaves carry a dispatched_task_id. Execution happened elsewhere; the record lives in task files.
    • Direct-implement path — no child directory and dispatched_task_id is null. The spec was implemented in-session (often by /wf-spec-implement, or by hand). There are no task files; the record is the git history of the affects files plus any in-session knowledge handed to you.

    Pick the path from what actually exists on disk, not from how you were invoked. Both paths run the rest of this skill; only the Outcome source (Step 2b) differs.

  3. Dispatched path only: read all child spec files and parse their frontmatter. Verify every leaf spec in the subtree has status: complete (non-leaf children are complete when all their own leaves are). If any leaf is not complete, report them and stop — do not proceed with wrap-up. Direct-implement path: confirm the spec body's items are actually present in the code (spot-check the affects files / recent commits). If the implementation is clearly incomplete, report what is missing and stop.

  4. Discover and run the repository's documented full verification command. If it fails, stop. If you just ran the equivalent full gates in-session and they were green, say so and you may skip the re-run.

Step 2: Update the parent spec

Read the parent spec file and update it to match the completed-spec style:

2a. Run the divergence analysis (the shared engine)

Before writing the Outcome, run the divergence analysis defined by /wf-spec-drift (its Steps 2–5) as wrap-up's analysis engine — do not eyeball the diff. This is the single place that classification logic lives; wrap-up composes the Outcome from it, so the two skills never write the section twice.

  1. Determine the commit range:
    • Dispatched path: the commits associated with the task UUID (per /wf-spec-drift Step 2).
    • Direct-implement path — the commits on the affects files since created:: git log --oneline -- <affects files>.
  2. Run /wf-spec-drift Steps 3–5: classify each spec item (Satisfied / Diverged / Not implemented / Superseded), identify unspecified work (scaffolding / improvement / scope creep), and compute the drift level (Minimal / Moderate / Significant) and satisfaction rate.

If you are running /wf-spec-drift standalone (not via wrap-up), it writes the Outcome itself; here, wrap-up owns the write (2b).

2b. Write the single Outcome section

Insert one ## Outcome section before any "Future Work" or "Phase N (Future)" sections. This is the canonical completion record: /wf-spec-implement delegates here, and /wf-spec-drift supplies the analysis consumed in 2a. It contains:

  1. Summary — 2-3 sentences: what shipped, dispatched vs implemented directly, commit SHAs (or PR link), and the drift / satisfaction line from 2a (e.g. "Drift: Minimal — N/M items satisfied (X%)").
  2. What Shipped — key deliverables: API endpoints and location (or "no new endpoints" if reusing routes), frontend components/stores/libs and approximate size, number of tests (backend + frontend) and coverage, key features.
  3. Design Evolution — the Diverged and Superseded items from 2a: what the spec said vs. what was built, why, and the commit. If a deviation made the spec body wrong, fix the body inline too.
  4. Not Implemented — the Not implemented items from 2a: each with why (deferred / descoped / superseded / blocked) and whether a follow-up exists.
  5. Unspecified Work — the unspecified changes from 2a, each tagged scaffolding / improvement / scope creep.
  6. Decisions / surprises / follow-ups — judgment calls not in the spec (naming, defaults, schema, UX micro-details, test strategy) with reasoning; gotchas a future maintainer or dependent spec should know (hidden coupling, fragile assumptions, test-infra quirks); concrete follow-ups not done here (link new specs/issues, or "None"). Highest-value detail — omit a bullet only if genuinely empty. On the dispatched path, mine the task files' ## Implementation notes for this; on the direct path, use any in-session knowledge handed to you plus the commit diffs.
Show full SKILL.md (618 more words)Show less
2c. Transition status through the testing gate (drift-aware)

The lifecycle forbids validated → complete directly: a spec reaches complete only via testing, where the drift verdict is rendered. The drift analysis from 2a is that verdict. Honor the gate; never hand-write complete onto a validated spec. Always set updated: <today> and keep dispatched_task_id null for non-leaf specs.

Drive the status by the path detected in Step 1, preferring the server transition API (it validates the edge and runs stale fan-out); fall back to legal-edge YAML only when the server is unreachable:

  • Dispatched path — the server already owns validated → testing → complete/stale (the task-done drift pipeline; or, where that server runs its drift tester disabled, an unconditional complete). Do not re-set the status. Read it:
    • Already complete/stale → leave it; you are only enriching the Outcome.
    • Stuck in testing (verdict pending / tester failed) → use the force-complete action (it's testing → complete) only if your analysis says minimal/moderate drift; on significant drift use the stale action. Both are gates — confirm with the user before overriding the server.
  • Direct-implement path — no task ran, so no server hook fired; the spec is still validated. Walk the legal edges yourself, using the drift level from 2a:
    • Minimal / Moderate drift → validated → testing → complete. There is no API action to enter testing from validated, so write status: testing (legal) as a YAML edit, then complete the testing → complete leg via the force-complete action when the server is reachable, else by writing status: complete (legal from testing). For Moderate, the Outcome documents the divergences; suggest /wf-spec-refine to align the body.
    • Significant drift → validated → stale (legal directly). Do not complete it; the spec no longer describes what was built. Report this and recommend /wf-spec-refine, then re-dispatch the remaining work.
2d. Update File Inventory

If the spec has a File Inventory section, verify it matches the actual files that were created/modified. Update any discrepancies.

Step 3: Update specs/README.md

  1. Read specs/README.md.
  2. Change the spec's status in its index table row, in the wording the table already uses.
  3. If the index keeps a status overview (e.g., a tree of ○/◐/✅ markers), mark the spec ✅ there too.
  4. Update the delivers column if the implementation differs from what was originally described.

Step 4: Check downstream specs (reverse dependency analysis)

Scan all spec files for depends_on entries that reference this spec's path:

  1. Reverse depends_on scan — grep all spec frontmatter for this spec's path in their depends_on lists. These are specs that were blocked by this one and are now potentially unblocked.
  2. If this spec introduced or changed interfaces listed in its affects, check whether downstream specs reference those same files/packages. Verify their descriptions are still accurate.
  3. If a stale spec depends on this one, flag it — the completion may resolve or worsen the staleness.
  4. Only make factual corrections — do not redesign other specs.

Step 5: Commit

Stage all modified spec files and commit:

specs: mark <spec-name> as complete, update README

Do NOT push unless the user explicitly asks.

Step 6: Report

Tell the user:

  • The spec is marked complete
  • How many tasks were verified
  • Any downstream specs that were updated
  • Whether any issues were found during verification

Guidelines

  • Read before writing — read the spec and all task files before making changes.
  • Preserve UX design — the spec may contain detailed UX descriptions, wireframes, and user interaction flows. These are valuable documentation even after implementation. Do not remove or summarize them.
  • Preserve future work — Phase 3, Phase 4, and "Future Work" sections describe planned extensions. Keep them intact.
  • Match the style of other completed specs in the repo (specs with status: complete and an ## Outcome section).
  • Be factual — the Outcome and Design Evolution sections should document what actually happened, not what was planned. Read task implementation notes for accuracy.

© changkun, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .claude/skills/wf-spec-wrapup of changkun/wallfacer.

Open the folder on GitHubat commit 5b3cea1

Compare with similar skills

Wf Spec Wrapup next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Wf Spec Wrapup compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Wf Spec Wrapup this skillchangkun/wallfacer112—~2.4kAutomated safety check: PassMIT
Doc Maintenancepaperclipai/paperclip99k—~1.6kAutomated safety check: PassMIT
Update DocsArcReel/ArcReel5.4k—~544Automated safety check: NotesAGPL-3.0
Docs Update from DiffQwenLM/qwen-code28k—~1.1kAutomated safety check: PassApache-2.0
Facade YARD Documentation Rulesruby-git/ruby-git1.8k—~5kAutomated safety check: PassMIT
GitHub Code ReviewRedWoodOG/Hermes-Desktop1775 repos~3.4kAutomated safety check: NotesMIT

Similar skills

  • Doc Maintenance

    paperclipai/paperclip

    Audit README, SPEC, and PRODUCT docs against recent git history for drift and make minimal PR-ready edits.

    99k GitHub stars~1.6k tokensUpdated today
    DevelopmentAuto-check passed

  • Update Docs

    ArcReel/ArcReel

    根据最近的 git 改动，更新面向用户的文档（README 双语、入门教程、部署、剪映导出等）。手动调用. An agent skill from ArcReel/ArcReel.

    5.4k GitHub stars~544 tokensUpdated today
    DevelopmentAuto-check: notes

  • Docs Update from Diff

    QwenLM/qwen-code

    Reads local git changes and updates only the matching docs pages, so documentation stays in sync with uncommitted or recent code changes.

    28k GitHub stars~1.1k tokensUpdated today
    DevelopmentAuto-check passed

  • Facade YARD Documentation Rules

    ruby-git/ruby-git

    Sets facade-specific YARD documentation rules for the Git::Repository public API, layered on the gem's general YARD skill.

    1.8k GitHub stars~5k tokensUpdated 7 days ago
    DevelopmentAuto-check passed

  • GitHub Code Review

    RedWoodOG/Hermes-Desktop

    Review code changes by analyzing git diffs, leaving inline comments on PRs, and performing thorough pre-push review.

    177 GitHub starsUsed in 5 repos~3.4k tokens
    DevelopmentAuto-check: notes

  • Fantasia Final Cleanup

    vishiri/fantasia-archive

    End-of-batch ship workflow for Fantasia Archive: run full yarn testbatch:verify (not dev scoped gate), fix failures, sync README/AGENTS/rules/skills from Git changes, update in-app changelog, split…

    409 GitHub stars~1.2k tokensUpdated yesterday
    DevelopmentAuto-check passed

More from changkun/wallfacer

All 14 skills in this repo

  • Wf Spec Breakdown

    changkun/wallfacer

    Split one spec into children — sub-design specs when questions are still open, or implementation-ready leaves when the plan is clear.

    112 GitHub stars~2.6k tokensUpdated 5 days ago
    Auto-check passed

  • Wf Spec Create

    changkun/wallfacer

    Write a new spec from scratch when none exists for the idea yet.

    112 GitHub stars~2.3k tokensUpdated 5 days ago
    Auto-check passed

  • Wf Spec Dispatch

    changkun/wallfacer

    Mark a validated spec ready to build and resolve its dependency wiring; where a task board with a transition API is present, create the linked task atomically.

    112 GitHub stars~1.6k tokensUpdated 5 days ago
    Auto-check passed

  • Wf Spec Drive

    changkun/wallfacer

    Run the whole lifecycle for one spec, calling the other skills in order and advancing one legal transition at a time until it reaches a target state (default complete), stopping to ask at…

    112 GitHub stars~2.3k tokensUpdated 5 days ago
    Auto-check passed

  • Wf Spec Report

    changkun/wallfacer

    Survey the whole spec tree: what is complete, in progress, blocked, and actionable next.

    112 GitHub stars~1.6k tokensUpdated 5 days ago
    Auto-check passed

  • Wf Spec Review Impl

    changkun/wallfacer

    Read-only verdict on whether an implementation meets its spec: each acceptance criterion classified, unintended changes flagged, test coverage checked.

    112 GitHub stars~1.1k tokensUpdated 5 days ago
    Auto-check passed

Categories

Questions about Wf Spec Wrapup

What does Wf Spec Wrapup do?

Close out a finished spec: write the Outcome section, move the status through the testing gate to complete, update specs/README.md, and commit. Wf Spec Wrapup is an agent skill from changkun/wallfacer.md, and commit.

When should I use Wf Spec Wrapup?

Wf Spec Wrapup fits situations like: the work is genuinely done; use drift when the point is to record divergence rather than to finish.

How do I install Wf Spec Wrapup in Claude Code?

Run `npx skills add changkun/wallfacer --skill wf-spec-wrapup -a claude-code`. Or copy the skill folder (.claude/skills/wf-spec-wrapup in changkun/wallfacer) into .claude/skills/wf-spec-wrapup in your project. Claude Code loads it when a task matches its description.

How do I install Wf Spec Wrapup in Codex?

Run `npx skills add changkun/wallfacer --skill wf-spec-wrapup -a codex`. Or copy the skill folder (.claude/skills/wf-spec-wrapup in changkun/wallfacer) into .agents/skills/wf-spec-wrapup in your project. Codex loads it when a task matches its description.

Can I use Wf Spec Wrapup in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add changkun/wallfacer --skill wf-spec-wrapup -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/wf-spec-wrapup, .gemini/skills/wf-spec-wrapup, .github/skills/wf-spec-wrapup and .opencode/skills/wf-spec-wrapup in your project.

What does Wf Spec Wrapup need to run?

Going by SKILL.md and its folder, Wf Spec Wrapup needs the command-line tools its instructions call (git).

Does Wf Spec Wrapup access the network?

SKILL.md contains no URLs. Its commands use git, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Wf Spec Wrapup safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Wf Spec Wrapup use?

Wf Spec Wrapup is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Wf Spec Wrapup use?

About 2.4k tokens (SKILL.md is roughly 9.6k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Wf Spec Wrapup?

Skills that share tags, products or a category with Wf Spec Wrapup: Doc Maintenance (paperclipai/paperclip, 99k stars), Update Docs (ArcReel/ArcReel, 5.4k stars), Docs Update from Diff (QwenLM/qwen-code, 28k stars) and Facade YARD Documentation Rules (ruby-git/ruby-git, 1.8k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Wf Spec Wrapup?

changkun (a GitHub user) maintains it in changkun/wallfacer, which has 112 GitHub stars. The repository holds 14 skills in this directory. The repository was last updated on October 4, 2026.

Source: changkun/wallfacer on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.