Skip to main content

SC ClickUp Tag Taxonomy

Purpose​

Names every approved space-level ClickUp tag, what it means, when to apply it, and who applies it. The taxonomy is strict: tags not listed here are not allowed on tickets, and new tags require a PR amending this doc before they are applied.

Without governance, ClickUp tag drift produces a tag list that grows monotonically — synonyms accumulate, abandoned tags clutter pickers, and reporting becomes unreliable. A short, curated taxonomy keeps tags useful as a telemetry surface (per-contractor quality patterns, per-domain throughput, per-blocker latency).

Scope​

  • In scope: Space-level tags applied to ClickUp tasks in the Client Delivery and SC Operations spaces.
  • Out of scope: Repo doc frontmatter tags (see SC Tagging Standard §Core Tag Categories); GHL contact tags (see SC Tagging Standard §GHL Contact Tags & Custom Fields).

Governance rules​

  1. Closed taxonomy. Every tag on every ticket must appear in §Approved tags below. Ad-hoc tags are not allowed.
  2. New tags require a PR. To add a tag, open a PR amending this doc with: name, definition, when applied, who applies, automation implications. Land the PR before applying the tag in ClickUp.
  3. Quarterly audit. Each quarter the CEO or designated AM lists all space-level tags in the ClickUp UI, diffs against this doc, removes or renames orphans, and posts a one-paragraph summary as a comment on the recurring audit task. See §Quarterly audit procedure for the checklist.
  4. Tag format:
    • Lowercase, hyphen between words.
    • Use a colon (:) prefix to namespace categories: quality:rework, domain:wordpress, blocked-on:client.
    • Exception: client tags use a forward slash (client/<slug>) to match the existing repo frontmatter convention from SC Tagging Standard.
  5. Tags are not structured fields. Status, priority, assignee, due date, time estimate are ClickUp fields, not tags. Tags are reserved for metadata that doesn't fit a structured field.

Approved tags​

Client identity​

  • client/<slug> — identifies the client the task serves. Required when the task is in a non-client list (e.g., an SC Operations task that touches one client) or when cross-list reporting is needed. Slug matches the directory name under 09-clients/ in the documentation repo.
    • Example: client/moots-law, client/rotary-sports.
    • Applied by: task author at creation.
    • Automation: future symphony-flow reporting filters by this tag for per-client throughput.

Domain area​

What subject-matter area the task touches. Use to filter for skill matching and reporting.

  • domain:wordpress — WordPress builds, plugin work, theming.
  • domain:seo — SEO audits, on-page optimization, SearchAtlas configuration, sitemap work, GSC integration.
  • domain:dns — DNS records, domain transfers, cutover coordination.
  • domain:billing — invoicing, subscription configuration, payment reconciliation.
  • domain:ghl — GHL sub-account configuration, workflows, snapshots, custom fields.
  • domain:design — visual design, brand assets, Canva/Figma work.

Add new domain:* tags via PR when a new area recurs across 3+ tasks. One-off domains do not justify a tag.

Quality (defect telemetry)​

Applied to tasks that did not meet AC the first time, or that closed cleanly but produced a defect in the wild. The whole family persists on the task across reopens — the audit trail matters more than visual cleanliness.

  • quality:rework — Task was sent back during review for a defect. AC was not met, the deliverable broke a side-effect, or the work did not match the spec. Applied by the reviewer at the moment the task is moved back to In-Progress (or equivalent). Remains on the task permanently, including after re-close.
    • When NOT to apply: advisory feedback only (see Review Standard §Feedback tone). Rework is for blocking defects, not nice-to-haves.
    • Applied by: reviewer (AM or CEO).
  • quality:escaped — Task was closed cleanly and the defect was discovered later — in production, by the client, by a downstream task, or on a follow-up review. The "oversight" case. Applied either on reopen of the original task, or as a tag on a follow-up task that links back to the original via the description.
    • When to apply: any time work that previously closed turns out to have been wrong, incomplete in a way the AC should have caught, or built on a faulty assumption. The bar is "would this defect have been caught if AC had been stricter or if validation evidence had been demanded?"
    • Applied by: whoever finds the defect (AM, CEO, contractor, client-reported via AM).
  • quality:partial-met — Task closed with one or more AC bullets only partially met, by mutual agreement. The unmet portion is documented in the close-out comment and either deferred to a follow-up task or accepted as a known limitation.

External-dependency state​

  • blocked-on:client — paused awaiting client response, decision, or asset.
  • blocked-on:vendor — paused awaiting a third-party vendor (Synergy Online, acewebx, Stripe support, registrar, etc.).
  • blocked-on:hosting-support — paused awaiting hosting provider on a support ticket.

Add new blocked-on:* tags via PR if a recurring external dependency emerges (blocked-on:legal, blocked-on:bank, etc.).

What is NOT a tag​

  • Status — use ClickUp status (open, in-progress, review, closed, blocked).
  • Priority — use ClickUp priority field.
  • Assignee — use ClickUp assignee field.
  • Due date — use ClickUp due-date field.
  • Effort estimate — use ClickUp time-estimate field.
  • One-off context — write it into the task description, not a tag.

If a piece of metadata fits a structured ClickUp field, use the field. Tags are for telemetry-grade categorical metadata that doesn't fit a structured field.

Quarterly audit procedure​

Run once per quarter. Allocate ~30 minutes.

  1. List all space-level tags. In ClickUp, navigate to space settings → Tags. Copy the full list (name + usage count if available).
  2. Diff against §Approved tags. For each tag in ClickUp not in this doc → orphan. For each tag in this doc not in ClickUp → missing (create it at space level so future tasks can apply it).
  3. Resolve orphans. For each orphan:
    • If it represents a recurring need not yet captured → open a PR amending this doc, then keep the tag.
    • Otherwise → remove from ClickUp. If the tag is on existing tasks, decide per case: replace with the canonical equivalent, or accept the tag dies with the task list.
  4. Resolve missing. Create any missing canonical tags at space level so they appear in the picker.
  5. Log the audit. Post a one-paragraph summary as a comment on the recurring audit task: tags added, removed, renamed; any open follow-ups.