A useful starting point.
Make it your own.
Six focused skills, project-context templates, and a worked example. Add the pieces you need to the way you already build.
Everything has a job.
- skills/
- Six original SKILL.md templates for shaping, specifying, slicing, implementing, reviewing, and maintaining context.
- repository/
- An AGENTS.md entry point, project boundaries, and documentation seeds to adapt.
- templates/
- Plan, specification, ticket, and handoff formats.
- examples/
- A notification-preferences example, from project context through to a verification handoff.
These are original starter materials. Use your existing coding agent and documentation tools; no particular wiki is required. Sources and attribution.
Start where you are.
Existing repository
Read your current agent instructions first. Merge the useful
parts of repository/AGENTS.md and guardrails.md into your existing guidance. Preserve
the project’s actual rules and commands.
New project
Create the application with your usual tooling. Use the kit’s repository templates as a starting point, then fill in the real architecture, validation commands, and project boundaries.
Adopt a small piece first. The kit is a set of templates, not an installer. Review files before copying them, and replace the prompts with verified project facts.
Give project knowledge a home.
Adapt the documentation seeds in repository/docs/.
Describe your architecture, accepted decisions, and local
development workflow. Plain Markdown is a useful starting point.
Give agents a small index to read first, with links to the relevant topics. Keep decisions and current behaviour in their own pages, then update those pages as the project changes.
Choose the simplest index that works.
A linked Markdown index may be enough. As the docs grow, you can add search, generated indexes, or wiki tooling. Choose an approach your agent can access and your team can maintain.
Example: index your docs with Plasma Wiki
Plasma Wiki is one option for indexing Markdown documentation and letting agents navigate it through a CLI. It is optional; the same workflow works with a maintained index and your existing tools.
Explore Plasma Wiki or follow the setup guide.
uv tool install plasma-wikiThis example uses uv . Follow the setup guide to initialise the wiki, keeping its version aligned with your project tooling. Back up existing docs and review initialisation changes.
Example lookup after setup
wiki map --path docs
wiki search "your topic" --path docs
wiki read <page-name> --path docs
Replace <page-name> with a page returned by
your wiki. After edits, refresh the index with wiki update --path docs
and check it with wiki lint --path docs. The kit’s
docs are Markdown seeds, not a pre-initialised wiki.
Reusable skills. Local knowledge.
Inspect the six folders in skills/ and choose the ones
you need. Each contains an original SKILL.md with a
specific job, inputs, and completion criteria.
- Choose the scope. Shared skills belong in a user-level directory supported by your client. Project-only skills belong in its supported repository directory.
- Copy the complete folder. For clients that
discover it,
~/.agents/skills/shape-work/SKILL.mdis an example of user-level placement. Check your client’s current discovery rules. - Verify discovery. Open the client’s skill list or ask it to identify the installed skill. Use the client’s supported invocation syntax; a folder alone does not prove the skill is active.
- Adapt deliberately. Keep reusable procedures in skills and project facts in your repo docs. A skill should point to the relevant context when it needs it.
Take one feature around the loop.
Start with the notification-preferences example . Read the context, decisions, spec, tickets, implementation brief, and final report format in order.
Then choose a small feature in your own project. Clarify the decisions, write only the spec you need, and split the work if it is too large for one useful change. Finish with actual verification and updated docs.
The example is illustrative. It demonstrates documents and handoffs. It does not include an implemented notification app or claim that application checks were run.
Tickets can stay as local Markdown. A connected tracker is optional; publishing work to it needs an explicit request.
A few useful answers.
Do I need every step for every change?
No. A small fix may only need relevant context, a clear outcome, and focused checks. Use the fuller planning and ticket workflow when it reduces uncertainty or helps divide the work.
Will these skills work in my coding agent?
The files follow the open Agent Skills format. Discovery paths, invocation syntax, and available tools differ by client. These templates avoid client-specific tool bindings, but you should verify them in your own setup.
Are these the same as third-party planning skills?
No. They are original, deliberately small templates for this kit. You can use your existing planning, spec, ticket, and review skills instead. The workflow matters more than the names.
Can I use the kit for commercial work?
Yes. The original kit materials use the MIT license, including its attribution notice. External tools and third-party skills have their own licenses.
Where is the original Spec Architect agent?
The original Claude Code agent is still available as a legacy download. It uses the earlier single-agent workflow; the new kit provides a broader set of context, implementation, and verification templates.