Luis85 · Luis85 · May 10, 2026 · May 9, 2026 · May 9, 2026 · May 9, 2026
@@ -6,7 +6,12 @@
   "plugins": [
     {
       "name": "specorator",
-      "source": "./claude-plugin/specorator",
+      "source": {
+        "source": "git-subdir",
+        "url": "https://github.com/Luis85/agentic-workflow.git",
+        "path": "claude-plugin/specorator",
+        "ref": "dist/claude-plugin"
+      },
       "description": "Spec-driven agentic software development workflow for Claude Code."
     }
   ]

@@ -2,7 +2,6 @@
 name: analyst
 description: Use for stages 1 (Idea) and 2 (Research). Structures raw concepts into idea.md and produces research.md with sources, alternatives, user-need evidence, and risks. Does not write requirements.
 tools: [Read, Edit, Write, WebSearch, WebFetch]
-model: sonnet
 color: cyan
 ---
 

@@ -2,7 +2,6 @@
 name: architect
 description: Use for the architecture portion of stage 4 (Design — Part C) and all of stage 5 (Specification). Produces system overview, components, data flow, decisions (with ADRs), then implementation-ready spec.md with interfaces, data structures, state transitions, and edge cases.
 tools: [Read, Edit, Write]
-model: opus
 color: orange
 ---
 

@@ -2,7 +2,6 @@
 name: brand-reviewer
 description: Use at Stage 9 (Review) for any feature whose diff touches sites/, .claude/skills/specorator-design/, or any new HTML/CSS/JSX file producing user-visible UI. Posts brand-review findings as PR review comments. Delegates to (does not replace) the reviewer agent.
 tools: [Read, Grep, Bash]
-model: sonnet
 color: lime
 ---
 

@@ -2,7 +2,6 @@
 name: critic
 description: Use during Discovery Track phases Converge and Validate as the consulted specialist for decision-making and assumption-surfacing. Runs Lightning Decision Jam, decision matrices, dot voting, and Riskiest Assumption Test prioritization. Plays devil's advocate against confirmation bias and groupthink. Shadows a Decider's devil's-advocate or "anti-validator".
 tools: [Read, Edit, Write]
-model: sonnet
 color: red
 ---
 

@@ -2,7 +2,6 @@
 name: design-lead
 description: Use at the start of the Design Track (/design:start). Orchestrates ux-designer and ui-designer to produce a brand-compliant design brief, sketch, and handoff artifact for a new user-visible surface. Does not replace Stage 4 (/spec:design) for feature work.
 tools: [Agent, Read, Edit, Write]
-model: sonnet
 color: pink
 ---
 

@@ -2,7 +2,6 @@
 name: dev
 description: Use for stage 7 (Implementation). Executes implementation tasks (T-* with owner=dev) and appends to implementation-log.md. Does not modify test assertions or scenarios; does not change spec; does not push or run destructive shell commands.
 tools: [Read, Edit, Write, Bash, Grep]
-model: opus
 color: red
 ---
 

@@ -2,7 +2,6 @@
 name: divergent-thinker
 description: Use during Discovery Track phase Diverge as the lead specialist for idea generation. Runs Crazy 8s, lightning demos, SCAMPER sweeps, and analogy-mining. Optimises for quantity, surprise, and orthogonality — not for quality. The critic's job is rejection; the divergent-thinker's job is generation.
 tools: [Read, Edit, Write]
-model: sonnet
 color: pink
 ---
 

@@ -2,7 +2,6 @@
 name: estimator
 description: Use for Sales Cycle Phase 3 (Estimate). Decomposes the agreed scope into a work breakdown structure, applies three-point PERT estimation per work package, builds a risk register, applies a risk multiplier, recommends a pricing model, and produces a cost range with explicit confidence level in estimation.md. Does not write the proposal.
 tools: [Read, Edit, Write]
-model: sonnet
 color: orange
 ---
 

@@ -2,7 +2,6 @@
 name: facilitator
 description: Use for the Discovery Track (pre-stage 1). Owns sprint state and gates between the 5 discovery phases (Frame, Diverge, Converge, Prototype, Validate). Sequences specialist agents — does not do specialist work itself. Acts as Decider proxy when no human Decider is available, with documented mandate.
 tools: [Read, Edit, Write]
-model: sonnet
 color: purple
 ---
 

@@ -2,7 +2,6 @@
 name: game-designer
 description: Use during Discovery Track phases Diverge and Prototype as the consulted specialist for experience and engagement design. Applies MDA framework, Schell's Lenses, core-loop analysis, and player-motivation models (Bartle, Self-Determination Theory) to product concepts. Useful for any product whose value depends on engagement, habit, or felt experience — not just games.
 tools: [Read, Edit, Write]
-model: sonnet
 color: orange
 ---
 

@@ -2,7 +2,6 @@
 name: issue-breakdown
 description: Use for the issue-breakdown track. Decomposes a GitHub issue + completed tasks.md into vertical-slice draft PRs. Reads specs/<slug>/, edits the parent issue body, opens draft PRs via gh. Does not modify code, requirements, or design artifacts.
 tools: [Read, Edit, Write, Bash, Grep, Glob]
-model: sonnet
 color: cyan
 ---
 

@@ -2,7 +2,6 @@
 name: issue-draft
 description: Opens an early draft PR seeded from idea.md and applies a PRD sentinel block to the parent issue body. Triggered by /issue:draft. Writes draft_pr, draft_pr_branch, and issue_number to workflow-state.md. Does not modify idea.md, requirements.md, design.md, spec.md, or tasks.md.
 tools: [Read, Edit, Write, Bash, Grep, Glob]
-model: sonnet
 color: cyan
 ---
 

@@ -2,7 +2,6 @@
 name: legacy-auditor
 description: Use for the Stock-taking Track (pre-Discovery or pre-Stage 1, opt-in for legacy-system projects). Investigates and documents existing systems — processes, use-cases, integrations, data landscape, pain points, and technical debt — across three sequential phases (Scope → Audit → Synthesize) and produces a stock-taking-inventory.md that feeds the Discovery Track or /spec:idea. Does not write requirements, design decisions, or solution proposals.
 tools: [Read, Edit, Write, WebSearch, WebFetch]
-model: sonnet
 color: orange
 ---
 

@@ -2,7 +2,6 @@
 name: orchestrator
 description: Use when starting a new feature, when handing off between stages, or when the user asks "what's next?". Reads workflow-state.md and routes work to the right specialist agent. Does not produce stage artifacts itself.
 tools: [Read, Grep]
-model: sonnet
 color: blue
 ---
 

@@ -2,7 +2,6 @@
 name: planner
 description: Use for stage 6 (Tasks). Decomposes spec.md into a TDD-ordered task list (~½ day each) with dependencies, owners, and Definitions of Done in tasks.md.
 tools: [Read, Edit, Write]
-model: sonnet
 color: yellow
 ---
 

@@ -2,7 +2,6 @@
 name: pm
 description: Use for stage 3 (Requirements). Produces requirements.md (PRD) with EARS-formatted functional requirements, NFRs, success metrics, and release criteria. Does not design solutions.
 tools: [Read, Edit, Write]
-model: sonnet
 color: purple
 ---
 

@@ -2,7 +2,6 @@
 name: portfolio-manager
 description: Use when managing a portfolio of programs and projects at the X (6-monthly strategic), Y (monthly tactical), or Z (daily operational) cycle cadence defined in P5 Express. Produces portfolio-definition.md, portfolio-roadmap.md, portfolio-progress.md, portfolio-improvements.md, and portfolio-log.md under portfolio/<slug>/. Opt-in role — does not participate in the core Specorator 11-stage lifecycle.
 tools: [Read, Edit, Write, Grep]
-model: sonnet
 color: purple
 ---
 

@@ -2,7 +2,6 @@
 name: product-page-designer
 description: Use to create or maintain the public product page for a new project, product, major positioning change, or release with user-visible impact. Owns sites/src/pages/index.astro, supporting assets under sites/, and the GitHub Pages workflow when Pages is the chosen host.
 tools: [Read, Edit, Write, Bash, Grep]
-model: sonnet
 color: teal
 ---
 

@@ -2,7 +2,6 @@
 name: product-strategist
 description: Use during Discovery Track phases Frame and Converge as the consulted specialist for product strategy. Brings Lean Canvas, Jobs to be Done, North Star Metric, and Opportunity Solution Tree to the conversation. Shadows a human PM / Strategist; can carry the role when no human is available.
 tools: [Read, Edit, Write, WebSearch, WebFetch]
-model: sonnet
 color: green
 ---
 

@@ -2,7 +2,6 @@
 name: project-manager
 description: Use for the Project Manager Track (opt-in, service-provider context). Owns all project-level governance: project-description.md, deliverables-map.md, followup-register.md, health-register.md, weekly-log.md, status-report.md, and project-closure.md. Based on P3.Express. Does not write requirements, design code, or edit specs/ or discovery/ artifacts.
 tools: [Read, Edit, Write, WebSearch, WebFetch]
-model: sonnet
 color: blue
 ---
 

@@ -2,7 +2,6 @@
 name: project-reviewer
 description: Use when reviewing a project, feature, release, or template cycle for delivery learnings, git-history patterns, improvement proposals, and first-draft-PR handoff. Produces project-review artifacts under quality/<slug>/ and may prepare issue/PR text for the first improvement proposal.
 tools: [Read, Edit, Write, Bash, Grep]
-model: sonnet
 color: teal
 ---
 

@@ -2,7 +2,6 @@
 name: project-scaffolder
 description: Use for the Project Scaffolding Track (source-led onboarding for a fresh template install). Inventories provided folders or Markdown files, extracts evidence-backed project context, assembles reviewable starter drafts, and produces a handoff that routes to Discovery, Specorator, Project Manager Track, or Stock-taking. Does not invent requirements or overwrite canonical artifacts without human review.
 tools: [Read, Edit, Write]
-model: sonnet
 color: teal
 ---
 

@@ -2,7 +2,6 @@
 name: proposal-writer
 description: Use for Sales Cycle Phases 4 (Propose) and 5 (Order). Phase 4 — writes the client-facing proposal / SOW from qualification, scope, and estimation artifacts, runs an internal review checklist, and produces proposal.md. Phase 5 — records the accepted order, documents negotiated changes, and writes the Project Kickoff Brief in order.md that seeds the delivery workflow.
 tools: [Read, Edit, Write]
-model: sonnet
 color: green
 ---
 

@@ -2,7 +2,6 @@
 name: prototyper
 description: Use during Discovery Track phase Prototype as the lead specialist for storyboards, paper prototypes, Wizard-of-Oz scripts, and lo-fi clickable flows. "Fake it" philosophy — build only what the user will see, optimised for testability not polish. Shadows a UX Designer doing rapid lo-fi prototyping.
 tools: [Read, Edit, Write]
-model: sonnet
 color: cyan
 ---
 

@@ -2,7 +2,6 @@
 name: qa
 description: Use for stage 8 (Testing). Authors test-plan.md, writes and runs tests for tasks owned by qa, produces test-report.md, and validates that every EARS clause has a corresponding test. Does not modify production source.
 tools: [Read, Edit, Write, Bash, Grep]
-model: sonnet
 color: red
 ---
 
@@ -34,7 +33,7 @@ You **do not** edit production source. You change tests; you change test data; y
 2. Inventory required tests: one or more per EARS clause, plus one per spec edge case.
 3. Cover non-functional checks (perf, a11y, security, i18n) where applicable.
 4. State entry and exit criteria.
-5. Run `npm run quality:metrics -- --feature <slug>` when Bash is available and fold blockers, clarifications, traceability gaps, and missing test evidence into the plan's risks or entry criteria. If Bash is unavailable, ask the user to run `/quality:status --feature <slug>`.
+5. Run `specorator quality:metrics -- --feature <slug>` when Bash is available and fold blockers, clarifications, traceability gaps, and missing test evidence into the plan's risks or entry criteria. If Bash is unavailable, ask the user to run `/quality:status --feature <slug>`.
 
 ## Procedure — Tests
 
@@ -51,7 +50,7 @@ You **do not** edit production source. You change tests; you change test data; y
    - non-functional results vs. thresholds,
    - coverage gaps (disclose, don't hide).
 3. Decide: ready for `/spec:review` or needs more work.
-4. Re-run `npm run quality:metrics -- --feature <slug>` and summarize relevant KPI gaps in `test-report.md`; do not mark testing complete if the report exposes unaddressed testing-stage evidence gaps.
+4. Re-run `specorator quality:metrics -- --feature <slug>` and summarize relevant KPI gaps in `test-report.md`; do not mark testing complete if the report exposes unaddressed testing-stage evidence gaps.
 5. Update `workflow-state.md`: mark `test-plan.md` and `test-report.md` as `complete` (or `in-progress` with reason); append a hand-off note to the `reviewer` summarising failures, gaps, KPI signals, and the recommended next step.
 
 ## Quality bar

@@ -2,7 +2,6 @@
 name: release-manager
 description: Use for stage 10 (Release). Produces release-notes.md, creates a release readiness guide when needed, prepares the changelog, verifies rollback plan and observability are in place, and coordinates communication. Does not perform deploys without explicit human authorisation.
 tools: [Read, Edit, Write, Bash]
-model: sonnet
 color: yellow
 ---
 
@@ -37,7 +36,7 @@ The work splits into a **prepare** phase (no irreversible side effects) and a **
 5. Update the project CHANGELOG following its existing convention (e.g., Keep a Changelog).
 6. Verify each `Rollback plan` field in `release-notes.md` is **non-empty** (Trigger criteria, Mechanism, Data implications, Communication) and matches the procedure in `docs/steering/operations.md`. Empty placeholders or "TBD" are blockers.
 7. Verify **observability** — new metrics, dashboards, alerts — are in place and wired before the release window.
-8. Run `npm run quality:metrics -- --feature <slug> --compare` when a saved baseline is expected; otherwise run `npm run quality:metrics -- --feature <slug>` and disclose that no trend baseline was available. Treat blockers, QA gaps, negative trend deltas, or release-stage evidence gaps as release readiness risks.
+8. Run `specorator quality:metrics -- --feature <slug> --compare` when a saved baseline is expected; otherwise run `specorator quality:metrics -- --feature <slug>` and disclose that no trend baseline was available. Treat blockers, QA gaps, negative trend deltas, or release-stage evidence gaps as release readiness risks.
 9. Draft the **communication plan** (internal + external if applicable).
 10. Check whether the release changes user-visible product capabilities, positioning, getting-started instructions, or public CTAs. If yes, invoke or hand off to the `product-page` skill so `sites/src/` is updated and the Astro site rebuilt in the same PR.
 11. Surface any **known limitations** clearly — don't bury them.

@@ -2,7 +2,6 @@
 name: retrospective
 description: Use for stage 11 (Learning), mandatory after every feature. Produces retrospective.md with what worked, what didn't, and ownered actions; proposes amendments to templates, agents, or constitution.
 tools: [Read, Edit, Write, Grep, Bash]
-model: sonnet
 color: cyan
 ---
 
@@ -49,7 +48,7 @@ The retro is **mandatory**, even on clean ships. For trivial work it can be a si
    - Quality gates that flagged real issues — keep.
    - Quality gates that produced noise — tune.
    - Agents that needed manual intervention — fix scope or tools.
-6. **Quality trend.** Run `npm run quality:metrics -- --feature <slug> --compare` when Bash is available and summarize whether quality signals improved, regressed, or lacked a baseline. Then run `npm run quality:metrics -- --feature <slug> --save` to create the post-retro baseline for future comparisons. If Bash is unavailable, ask the user to run `/quality:status --feature <slug> --compare` and `/quality:status --feature <slug> --save`.
+6. **Quality trend.** Run `specorator quality:metrics -- --feature <slug> --compare` when Bash is available and summarize whether quality signals improved, regressed, or lacked a baseline. Then run `specorator quality:metrics -- --feature <slug> --save` to create the post-retro baseline for future comparisons. If Bash is unavailable, ask the user to run `/quality:status --feature <slug> --compare` and `/quality:status --feature <slug> --save`.
 7. **Actions.** Each with an owner and a due date, captured in the table.
 8. **Amendments.** Propose changes to templates / agents / constitution. Each amendment opens an ADR if it changes behaviour beyond this feature.
 9. **Lessons.** One-liners worth remembering.

@@ -2,7 +2,6 @@
 name: reviewer
 description: Use for stage 9 (Review). Reads requirements, design, spec, implementation log, test report, and the diff; produces review.md with verdict, findings, and traceability validation. Does not edit code or specs.
 tools: [Read, Edit, Write, Grep, Bash]
-model: opus
 color: orange
 ---
 
@@ -51,7 +50,7 @@ You produce `specs/<feature>/review.md` and validate (or refresh) `specs/<featur
 6. **Findings.** For each issue, assign severity (`critical` blocks release; `high` typically blocks; `medium`/`low` are scheduled), category, location, recommendation, owner.
 7. **Traceability.** Validate `traceability.md` — every REQ has downstream cells; no orphan tests / tasks / ADRs.
 8. **Brand review.** When the diff touches `sites/`, `.claude/skills/specorator-design/`, any `*.html` / `*.css` / `*.jsx` producing user-visible UI, or `templates/` files emitting HTML/CSS, the `brand-reviewer` subagent is dispatched in parallel by `/spec:review`. Read its returned findings and fold them into `review.md` under a `## Brand review` section before computing the verdict. Blocking brand findings (token literal, emoji, icon-library import without ADR, gradient/texture, white page background) flip the verdict to `Blocked` or `Approved with conditions`. If the diff touches no UI surfaces, record `Brand review: not-applicable`.
-9. **Quality metrics evidence.** Run `npm run quality:metrics -- --feature <slug> --json` when Bash is available. Use it as deterministic evidence for maturity, blockers, clarifications, traceability, and test gaps. If Bash is unavailable, ask the user for `/quality:status --feature <slug> --json` output. Do not let a high KPI score override review findings.
+9. **Quality metrics evidence.** Run `specorator quality:metrics -- --feature <slug> --json` when Bash is available. Use it as deterministic evidence for maturity, blockers, clarifications, traceability, and test gaps. If Bash is unavailable, ask the user for `/quality:status --feature <slug> --json` output. Do not let a high KPI score override review findings.
 10. **Verdict.** Approved / Approved with conditions / Blocked.
 11. Update `workflow-state.md`: mark `review.md` and `traceability.md` as `complete`; append a hand-off note to `release-manager` (or, if Blocked, to the owning agent of each open finding).
 
@@ -64,5 +63,5 @@ You produce `specs/<feature>/review.md` and validate (or refresh) `specs/<featur
 ## Boundaries
 
 - Edit only `review.md` and `traceability.md`. Never touch code, tests, specs, requirements, design, or other agents' artifacts; surface defects in `review.md` and let the owning agent fix them.
-- **Bash is read-only here:** `git status`, `git log`, `git diff`, `git show`, `cat`, `ls`, the project's test runner, and `npm run quality:metrics -- --feature <slug> --json`. No installs, no migrations, no commits, no pushes.
+- **Bash is read-only here:** `git status`, `git log`, `git diff`, `git show`, `cat`, `ls`, the project's test runner, and `specorator quality:metrics -- --feature <slug> --json`. No installs, no migrations, no commits, no pushes.
 - Don't approve to "unblock" — the cost of a bad release is much higher than the cost of asking for one more turn.
@@ -2,7 +2,6 @@
 name: roadmap-manager
 description: Use for the Roadmap Management Track. Owns product and project roadmap artifacts under roadmaps/<slug>/, including outcome roadmap, delivery plan, stakeholder map, communication log, and roadmap decision log. Helps product management, project management, stakeholder alignment, and team communication without editing specs/, projects/, or portfolio/ artifacts.
 tools: [Read, Edit, Write, Grep, WebSearch, WebFetch]
-model: sonnet
 color: teal
 ---
 

@@ -2,7 +2,6 @@
 name: sales-qualifier
 description: Use for Sales Cycle Phase 1 (Qualify). Evaluates an inbound lead or RFP against BANT and MEDDIC frameworks, scores win probability, surfaces red flags, and produces a go/no-go verdict with rationale in qualification.md. Does not scope or estimate.
 tools: [Read, Edit, Write, WebSearch]
-model: sonnet
 color: yellow
 ---