create-workspace

name	create-workspace
description	Create a private GitHub repository from the Spec-Led-Certification template and clone it, as the durable home for one certification search. Use when the user wants the search backed by a repo rather than a local folder — "make a repo for this", "set up a workspace for finding a certification". For a plain local directory with no remote, use scaffold-workspace instead.

Create a workspace repository

Stand up a private GitHub repo from the Spec-Led-Certification template and clone it. That repo is then the definitive store for one search: the profile, the frozen scorecard, the research, the reports, and the archived runs.

Why a repo rather than a folder

The workflow is built on the premise that its state outlives the conversation, and a folder on one machine is a weak form of that. A repo gives the things that premise actually needs: it survives the laptop, the history shows when the scorecard was frozen relative to when the research ran, a diff shows what a re-run changed, and it can be opened by a different assistant on a different machine months later.

Instantiating the template also copies skills/, agents/ and docs/ into the new repo, so it explains its own process without this plugin installed. That is the whole agent-agnostic claim, delivered rather than asserted.

Use scaffold-workspace instead when the search belongs inside an existing repo, when there is no gh, or when the user does not want a remote.

Check prerequisites

gh auth status

If gh is missing or unauthenticated, say so plainly and offer scaffold-workspace as the local-only path. Do not attempt to work around it — a half-created repo is worse than a folder.

Read the user's preferences first

Look for ~/.claude-plugins/spec-led-certification/config.yaml:

owner: <github-user-or-org>
visibility: private          # private | public
workspace_parent: ~/repos    # where clones land
naming: "{subject}-certification-{mmyy}"
remove_examples: true

This file is the user's, not the plugin's — it lives outside the plugin directory because /plugin update replaces that directory wholesale, and it stays out of the template and the plugin repos so nobody's own defaults leak into a public repository.

If it exists, use it and stop asking questions it already answers. If it does not, proceed by asking, and offer to write it at the end so the second search is a single confirmation. Never write it without being asked.

Choose the name

Derive a proposal from the subject and show it. A good default is the subject plus a month stamp: a search for an agentic AI certification opened in August 2026 becomes agentic-ai-certification-0826. The month matters because a search is a point in time and a second search on the same subject two years later is a different repo, not an overwrite.

If naming is set in the config, follow it. If the user has a convention visible in the working environment, follow theirs over either.

Check it is free before proposing it as settled:

gh repo view <owner>/<name> >/dev/null 2>&1 && echo taken

Confirm before creating

Creating a repository is a real, outward-facing action. Show the exact command and get an explicit yes.

gh repo create <name> --template danielrosehill/Spec-Led-Certification \
  --private --clone --description "<subject> — spec-led certification search"

State three things in the confirmation:

• the repo will be private, and named
• it will end up holding a fairly complete picture of the user — what they know, what they earn or can spend, what they are trying to move toward
• it lands under their GitHub account, not on this machine only

If the user asks for --public instead, say once, without lecturing, what the profile files will contain by the end of the run, and then do as they asked. It is their account and their call; the point is only that the choice is made knowingly rather than by a default nobody read.

Create

Run it. Takes a few seconds. gh handles the template instantiation race internally — the clone comes back complete rather than empty, so no wait loop is needed.

The new repo starts with a single squashed Initial commit and no upstream link to the template. That is normal for template instantiation and mostly what you want: the search is not a fork and will not receive template changes. Say so if the user asks about updates — improvements to the method are pulled in by hand, and a search in progress generally should not be, because changing the skills underneath a frozen scorecard is exactly the drift the method exists to prevent.

Settle the workspace in

Working in the clone:

1. Write the marker .spec-led-certification at the repo root:

   created: <today, YYYY-MM-DD>
   subject: <the subject, one line>
   template: danielrosehill/Spec-Led-Certification
   backing: github
   repo: <owner>/<name>
   workspace_root: .
   

   This is what the other skills resolve paths against, and it records what the workspace was built from.

2. Rewrite README.md for this search. The template's README describes the template — it is the wrong front page for a live search, and leaving it there means the repo's landing page never says what the repo is about. Replace it with something short: the subject, when the search opened, the current state (intake not started), where the answer will appear (pdf/), and a link back to the template repo for the method. Keep it a status page — a few lines that get updated as stages complete, not a second copy of the documentation, which is already in docs/method.md.

3. Offer to remove examples/. It is a worked example with invented credentials, useful while learning the workflow and clutter once a real run is under way. Ask; removing it is not obviously right and it costs nothing to keep.

4. Commit and push.

   git add -A && git commit -m "Open the search: <subject>" && git push
   

Then

Say where the repo is, both the local path and the GitHub URL, and confirm it is private.

If they answered questions the config could have answered, offer to save them to ~/.claude-plugins/spec-led-certification/config.yaml now.

Then hand off to start-search — but as a separate step, not in the same breath. Creating a repo is infrastructure and the intake is an hour of questions about the user; give them the chance to look at what appeared before starting.