Start with /cos to route a business ask, or delegate a bounded question to its department. Get a recommendation, its sources, unanswered questions and clear handoffs.
Verified in marketplace 1.148.0, source 54bfcfc. All ten department packages have landed. The coordinator remains a separate two-skill package.
Coordinator · chief-of-staff v0.3.0 · two skills
Chief of Staff: start with /cos
The Chief of Staff routes an ask to the departments that own it, runs independent work in parallel, checks the results and returns a result, a proposal or a decision memo. It runs in the main session, never inside a subagent. It coordinates ten department agents, with no separate coordinator agent file.
Exact entry point
/cos <ask>
/cos is the documented skill entry. It loads chief-of-staff:chief-of-staff, the operating manual. The package has two skill files and zero command files, so /cos does not increase the catalog's command-file count.
Install or refresh the needed packages. Use a compatible main-session host with chief-of-staff, the relevant departments and model-router. Verify the required hooks, ledger access and external specialists in that session.
Read the context card first. The manual names MoxyWolf Vault/_Shared Knowledge/Operating Norms/chief-of-staff-context.md as the home for company facts and standing rules. Pass its path to departments instead of copying its contents into every dispatch.
Read project instructions, then the ask. When a project is attached, load 00 – Project Hub/cowork-project-instructions.md. Confirm the relevant data access and declared project-workspace log destination.
If the context card is missing, stop the work and log the outcome as escalated (context card missing). This guide has not inspected the live Vault card, installed the packages or verified the host's permissions. Source verification does not establish runtime readiness.
claude plugin install chief-of-staff@moxywolf-plugins
Start each run with yesterday's after-action report
Version 0.3.1 starts /cos by minting a run ID shaped as YYYY-MM-DD-short-ask. The start command must run on its own, with no command chaining, so the model-router hook can record it for this session. Also set COS_RUN_ID in the shell of checks you run yourself; a shell export alone does not tag later hook processes.
Read the previous calendar day, not a rolling 24 hours. Run model-router's route.py aar for that date against $GSTACK_PEER_REVIEW_DIR/model-routing, or ~/.gstack/model-routing if unset. Save it to the project's 00 – Project Hub/after-action/<date>.md. Read an existing report rather than rewriting it. Unreadable ledger data is reported, but does not stop dispatch.
Join evidence by run, department and actual model. The routing ledger records cos_run, department and applied_model. Claim checks record their pass/fail outcomes in claim-checks.jsonl with --department, --cos-run and the actual --model from the dispatch ledger. Omit an unknown model instead of guessing. The prose decision log's Run: line joins these records.
Read rates with their own denominator. The AAR reports usage counts alongside model and department rates, including checks passed, failures, send-backs and escalations. A sample under 10 is a lead, not a conclusion. Zero records means no observations, not a clean day. Missing tags stay untagged.
Account for confounding. Harder tasks go to stronger models by design. Differences in rates do not show that a model caused the result. Script-class advice is not actual model usage.
Bring one proposed decision. Lead with the AAR's headline counts and its one proposed decision, or its explicit below-the-bar result when evidence is insufficient. The AAR never changes routing by itself.
The source documents these hooks and evidence fields, but MR-003 hook behavior and CS-007 /cos dispatch tagging are not live-session verified in the repository's DESIGN record. This guide does not claim a successful live run. Model-router evidence and AAR source
Example request
/cos Assess why customer onboarding keeps slipping. Use the attached project context, identify the process bottleneck and customer impact, compare feasible fixes with their cost, and tell me what needs my decision. Do not send customer messages or commission code.
This illustrative ask could involve Operations for the handoff, Customer Experience for the customer consequence and Finance for the cost. The Chief of Staff names one lead and any contributors, then states two to four checkable success criteria.
The working loop
Name the owners and why. State routing before dispatch. Run independent departments in parallel. One lead owns a mixed answer; each contributor owns its part.
Dispatch five things. Send the context-card path, the user's wording, success criteria, authorized scope and evidence already held. A goal assigns an item, not additional authority.
Check the return contract, then the criteria. Check four fields for the original eight departments and nine for Sales and Marketing. Claim-check Sales and Marketing returns. Send an incomplete result back once, identifying each missing field or failed line. If it stays incomplete, escalate the gap instead of supplying the specialist's answer.
Get independent Security review. Review each completed lead or contributor result that touches identity, secrets, customer data or an outside integration. Wait before presenting it, report pending review without exposing the unreviewed result, and keep sensitive actions blocked.
Respect the disagreement exception. If Sales or Finance is in a disagreement, request Security review as usual but bring the memo after the return contract is settled. Name pending reviews and the blocked action. This exception does not unblock a sensitive action.
Return and record the outcome. Report done, proposed or escalated, with counts and verification gaps. Log every exit, close the run tag, and claim-check the final report and any memo together.
Four or nine return fields
Original eight departments
Answer
Skills loaded
Sources cited
Open questions
Sales and Marketing
Answer
Skills loaded
Sources cited
Open questions
Criterion-by-criterion evidence and status
Assumptions and uncertainty
Verification performed or missing
Proposed next action
Pending approvals
Sales and Marketing mark each criterion met, not met or blocked, with evidence. Source records include the title or origin, URL or file, source date when available and retrieval date. Distinguish supplied facts, verified observations and inferences. Unsupported claims stay flagged. “Not supplied” or “not read” does not establish that something does not exist.
A missing external specialist blocks dependent work. Pending approvals include every gated next action, its exact revision and whether Security review is required. Open artifact fields or unsupported claims make a request not ready for approval.
Claim checks: a receipt, not proof of truth
scripts/claim_check.py checks Sales and Marketing returns, then the final Chief of Staff report and decision memo. Save the exact ask, results and report as files. Supply the matching source files; fix failed lines, rerun the check, and end the report with its receipt and document sha256.
Use exact source quotations under their labels, first-person Me: observations and Open: questions. The coordinator labels its reasoning My inference:; departmental results use Inference:, plus Proposal:, Skill: and Source: where appropriate. These are the plugin's labeled-line formats, not permission to present unsupported claims as facts.
The manual names Dorian Cougias as the Release Owner Gate. Publication, production release, customer-system or CRM writes, deletions, permission changes and sensitive actions wait for recorded approval, as do external communications and spend. Analysis, a goal, a connected tool and specialist instructions cannot grant it. This is an instruction-level gate, not technical enforcement.
Each request supplies six things: the exact action; artifact and revision; audience or system; evidence; risks; and rollback or a clear statement that it cannot be undone. An unfinished artifact is marked not ready for approval, naming every open part. Approval binds the owner, action, audience or system and exact artifact revision. A changed artifact or scope needs fresh approval; silence and urgency are not approval.
Where routing lines fall
Incidents: security events go to Security; operational outages go to Operations. If unclear, Security goes first.
Identity: account creation, changes and removal go to IT operations. Access policy and review go to Security.
Programs: cross-project work goes to the PMO; one process or vendor relationship goes to Operations.
Revenue: one named account or person goes to sales-department. Audiences, positioning, campaigns and content go to marketing-department. Post-sale service goes to Customer Experience, pricing economics to Finance and market entry to Corporate Strategy.
Outside the ten: legal: and product-orchestrator: are external routes; code goes to /gstack-build. sales: and marketing: are external specialists loaded by their department heads, not department replacements or copied skills. Verify availability at run time.
Decision memo and log
A memo states the call and deadline, quotes each department's position, gives options with cost, risk and a labeled recommendation, and explains what happens if nothing is done. Keep unresolved questions and disagreement intact. A Finance disagreement also needs a customer-deidentified “For the bookkeeper” section for the owner to forward. Neither the coordinator nor a department contacts the bookkeeper. Stop further option work until the owner answers.
Every /cos exit appends to <workspace>/00 – Project Hub/chief-of-staff-log.md; without an attached project, use GitHub/Projects/MoxyWolf LLC/00 – Project Hub/chief-of-staff-log.md. Resolve workspace.path from project-surfaces.json; org-shared projects use GitHub/Projects, while personal projects may use Taskade. Include Run:, ask, departments, outcome and the decision or pending state. A missing card or still-incomplete return is escalated with a reason. The prose log is an agent-written summary; the session transcript is the fuller trace, and the joined routing and claim-check ledgers are code-captured records.
End the run tag on every exit, as a standalone command, so later dispatches are not assigned to a finished run:
python3 "${CLAUDE_PLUGIN_ROOT}/../model-router/scripts/route.py" cos-run end
Shipped and planned
Version 0.3.1 ships /cos, the ten-department manual, claim checking and the previous-day AAR workflow. /cos-brief, a scheduled weekday brief and /cos-review remain planned, with no entry-point skill files at this snapshot. The AAR at /cos startup is not a scheduled brief.
Approved coding proposals route to /gstack-build. A separately approved multi-item goal uses the goal-mode workflow. There is no shipped automatic /cos-to-/gstack-goal dispatch. Chief of Staff package notes
How to ask
Delegate a request, then inspect the evidence
Name the department and outcome. Include the decision, relevant facts, scope, constraints, deadline and what must not change.
Load the head skill first. Each agent then loads the matching specialist skill. Sales and Marketing use external sales: and marketing: specialists, loading each kind of work their answer contains. Missing specialists block dependent work; installation of the department alone does not supply them.
Keep ownership explicit. If part of the request belongs to another department, the agent names that function and leaves that part to it.
Read the result as a reviewable recommendation. The original eight return the answer, skills loaded, sources cited and open questions. Sales and Marketing return nine fields with explicit evidence, uncertainty, verification, next action and approvals. Inspect the full return contracts.
Prerequisites
Install or refresh the relevant package in a host that supports its Claude plugin and department-agent format. The README describes an agent Claude can delegate to; installation and agent availability still need to be checked in your host.
Provide the relevant records or authorized access. Vendor names in the skills describe a professional tool landscape; they do not install or connect QuickBooks, an HRIS, an identity provider or any other system.
Give the agent a bounded task and identify the person who can make the consequential decision. A department title does not grant account access or authority to act.
Have the agent consult the specialist's references/sources.md when present, follow its source-use notes and cite what it actually used. Missing references must be reported, not invented.
Repository-documented Claude Code installation commands
For an existing marketplace, refresh it:
claude plugin marketplace update moxywolf-plugins
If the marketplace has not been registered, the repository documents:
claude plugin marketplace add MoxyWolfLLC/moxywolf-plugins
Then install the packages you want by their exact names:
claude plugin install finance@moxywolf-plugins
claude plugin install people@moxywolf-plugins
claude plugin install it-operations@moxywolf-plugins
claude plugin install security@moxywolf-plugins
claude plugin install pmo@moxywolf-plugins
claude plugin install operations@moxywolf-plugins
claude plugin install corporate-strategy@moxywolf-plugins
claude plugin install customer-experience@moxywolf-plugins
claude plugin install sales-department@moxywolf-plugins
claude plugin install marketing-department@moxywolf-plugins
These are installation commands, not department slash commands. Repository installation pattern. Use the pinned marketplace and exact package manifests for the current roster. The original eight packages did not copy the upstream ChatGPT/Codex manifest, build scripts, verticals or org chart. Sales and Marketing add local head skills while loading external specialists; do not assume either path configures another host or its connectors.
Find the accountable function
Choose a department
The requests below are illustrative prompts. They describe work to review, not actions already taken or automatic permission to change a business system.
finance · v0.1.0 · 13 skills
Finance
Financial models, budgets, forecasts, cash, unit economics and financial decision support.
Use when: A plan needs defensible numbers, a funding decision or a clear account of financial risk.
Relevant cost, revenue, cash or working-capital data
What to expect back
A driver-based model or recommendation with assumptions
Cost, risk, trade-offs and evidence that would change the recommendation
Named financial decisions and follow-up owners
Example request
Delegate this to the finance department: build a rolling cash forecast from these actuals and the proposed hiring plan. Show the drivers, downside case, assumptions that would break the plan and the decisions needed from the owner.
An unfundable plan goes to the Chief Executive; reporting obligations go to Legal & Risk
A forecast must state its assumptions and failure conditions
Recommendations do not authorize payments, borrowing, investment trades or other financial commitments
Handoffs: People owns the hiring plan; Operations owns operating cost drivers. Finance tests affordability and owns the financial model and budget view.
Budget, location and relevant employment jurisdiction
Job-relevant evidence, with personal data limited to what is necessary
What to expect back
A proposed org, hiring plan, role definition or people process
Documented reasoning and relevant assumptions
Decision owners, legal questions and next steps
Example request
Delegate this to the people department: turn these business outcomes into a hiring plan and structured interview rubric. Explain the role levels, evidence each question should collect, budget assumptions and decisions that need legal or executive review.
Executive-team restructures go to the Chief Executive
Employment law, investigations and protected-characteristic issues go to Legal & Risk
The agent does not independently hire, terminate, change pay or resolve employment matters
Handoffs: Finance validates headcount cost. People defines onboarding and offboarding needs; IT executes authorized account lifecycle work under Security's access policy.
Asset, identity or service inventory relevant to the task
Security-approved policy and business recovery objectives
Change scope, maintenance window and available test evidence
What to expect back
A scoped service plan or operational runbook
Ownership boundaries and measurable service outcomes
Recovery evidence or an explicit untested gap
Example request
Delegate this to IT operations: prepare a joiner-mover-leaver runbook for these corporate systems using the approved access policy. Identify the owner, approval, execution evidence and rollback or recovery check for each step. Do not change accounts yet.
Security sets access and vulnerability policy; IT executes authorized changes
Engineering owns product infrastructure; IT owns the corporate estate
A backup is not proven recovery until a restore is tested; proposed access, network or security changes require their own authorization
Handoffs: People supplies approved joiner-mover-leaver events. Security defines permissions. Operations sets business continuity targets; IT must demonstrate it can meet them.
System owner, decision deadline and risk-acceptance owner
What to expect back
An explicit blocking or non-blocking finding
Exposure, likelihood reasoning and required remediation evidence
Any accepted risk with a named accepter, expiry and monitoring
Example request
Delegate this to the security department: review this proposed customer-data architecture. Identify trust boundaries and concrete threats, separate blocking findings from advice, and state the evidence that would resolve each blocker.
The department under review cannot overrule a Security blocker or approve its own exception
A conflicting ship decision escalates to the Chief Executive for recorded risk acceptance
Regulatory or contractual consequences go to Legal & Risk; a recommendation does not authorize live security changes
Handoffs: Engineering or IT fixes the system it owns. Security defines the finding and verifies adequate controls rather than silently absorbing the owning team's repair work.
Initiatives, accountable owners and intended benefits
Real capacity and allocation constraints
Milestones, dependency logic and current delivery facts
Risk, uncertainty and decision dates
What to expect back
A capacity-based portfolio recommendation or delivery plan
Dependencies, risks and decisions grounded in events rather than status colors
Named benefit and adoption measures
Example request
Delegate this to the PMO: compare these three initiatives against the team's actual capacity. Show the critical dependencies, what must be deferred, the decisions needed this week and how we will verify the expected benefits after delivery.
Clear handoff inputs, owner and completion criteria
Capacity trade-offs and a small set of owned follow-up actions
Example request
Delegate this to operations: trace one customer onboarding from sale to support using these records. Identify where the handoff fails, define the completion criteria and next owner, and propose the smallest process change with a measurable review date.
Key uncertainties and the indicators that could falsify an option
What to expect back
A choice with explicit trade-offs and a reason to act now
Scenarios, assumptions and indicators to monitor
A first commitment, its owner and decision date
Example request
Delegate this to corporate strategy: compare entering this adjacent market, partnering and staying focused on our current segment. State what each option gives up, the least-certain assumption, the indicator that would change the recommendation and the first commitment required.
The Chief Executive approves and owns the strategy of record; this department develops and maintains its analysis
Finance must agree on balance-sheet consequences before a corporate-development approach
A deal thesis or recommendation does not authorize an acquisition, investment, approach or agreement
Handoffs: The Chief Executive makes the strategic call, Finance translates it into the plan, and the owning departments change resourcing and delivery priorities.
A definition of customer resolution and an agreed sharing scope
What to expect back
A specific customer problem and recommended fix
Cost or customer impact, delivery owner and trade-offs
A measurable way to verify resolution
Example request
Delegate this to customer experience: use these onboarding tickets to identify the exact step where customers get stuck. Separate support gaps from product defects, quantify the burden, name the fix owner and propose how we will confirm the customer problem is resolved.
Do not promise customers something the delivering team has not agreed to
Unfunded service commitments escalate to the Chief Executive; recurring defects go to Product
Draft recommendations do not authorize customer messages, refunds, commitments or product changes
Handoffs: Customer Experience owns the customer impact. Product and Engineering own product fixes, Finance owns billing causes, and Operations owns cross-functional process repair.
The context-card path and the ask in the owner's words
Checkable success criteria, authorized scope and available evidence
Current account or opportunity records and their source dates
The installed sales: specialists needed for each kind of work
What to expect back
Account, pipeline or call-preparation analysis tied to supplied facts and records actually read
A reviewable outreach draft with supported claims when the required specialist is available
All nine return fields, including verification gaps, proposed next action and approval requests
Example request
Delegate this to sales-department. Use the supplied context card and account records to assess this named opportunity and prepare questions for our next call. Show criterion-by-criterion evidence, separate supplied facts from observations and inferences, and return all nine fields. Keep outreach as text for review. Do not write to the CRM, create a mailbox draft, enroll anyone in a sequence or spend enrichment credits.
Required external specialists
sales:account-research
sales:call-prep
sales:draft-outreach
sales:pipeline-review
sales:forecast
These external specialists belong to another marketplace and are not copied into this package or its skill count. Resolve and load each required skill at run time. If it is missing or cannot load, dependent work is blocked; report the gap rather than imitating it or claiming it ran.
Nine return fields
Answer
Skills loaded
Sources cited
Open questions
Criterion-by-criterion evidence and status
Assumptions and uncertainty
Verification performed or missing
Proposed next action
Pending approvals
Boundaries
Load external sales: specialists at run time; if one is missing, dependent work is blocked
Draft outreach stays as text in the answer; mailbox drafts and sequence enrollment are gated system writes
A dispatch, goal or specialist instruction grants no permission to send, spend, release, delete, change permissions or write records
Customer data and outside integrations require independent Security review; never promise an unapproved price, term or date
Handoffs: Marketing owns audiences and segments. Customer Experience owns post-sale service; Sales owns renewal and expansion pursuit. Finance owns pricing economics, Strategy owns market entry, Legal owns legal judgments, and code goes to /gstack-build.
The context-card path and the ask in the owner's words
Checkable success criteria, authorized scope and available evidence
Approved product claims and the campaign or channel's own data
The installed marketing: specialists needed for each kind of work
What to expect back
An evidence-backed audience, positioning or campaign recommendation
Draft copy with supported claims, or performance analysis from channel data actually read
All nine return fields, including criterion status, uncertainty and pending approvals
Example request
Delegate this to marketing-department. Use the supplied context card, audience evidence and approved product claims to propose a campaign brief and draft copy. Load the specialist for each kind of work. Return all nine fields, flag unsupported claims and say what measurement is missing. Keep drafts as text for review. Do not publish, schedule, spend, upload audiences or change tracking.
Required external specialists
marketing:campaign-plan
marketing:content-creation
marketing:brand-review
marketing:seo-audit
marketing:performance-report
These external specialists belong to another marketplace and are not copied into this package or its skill count. Resolve and load each required skill at run time. If it is missing or cannot load, dependent work is blocked; report the gap rather than imitating it or claiming it ran.
Nine return fields
Answer
Skills loaded
Sources cited
Open questions
Criterion-by-criterion evidence and status
Assumptions and uncertainty
Verification performed or missing
Proposed next action
Pending approvals
Boundaries
Load external marketing: specialists at run time; if one is missing, dependent work is blocked
Drafts stay in the answer; loading even unpublished or scheduled items into a publishing, email, ads or social tool waits for approval
No automatic department-to-gstack integration is documented. The Chief of Staff and the Sales and Marketing heads route approved code work to /gstack-build. Departments never launch a goal run or infer goal approval. The following is a separate, human-reviewed goal workflow for a suitable multi-item outcome.
Ask the owning department to define the need. For example, Customer Experience identifies a recurring onboarding failure, its cost, the fix owner and the evidence that would show resolution.
Resolve the decisions before coding. Product and Engineering own a product fix; Finance checks affordability where needed; Security supplies independent findings; the PMO can surface capacity and dependencies.
Draft a bounded engineering goal. With an existing DESIGN.md objective and checkable outcome, ask for /gstack-goal-new <goal-id> "<outcome>". The department's recommendation is input to the brief, not an approved goal or an independent test.
Keep the existing approvals and tests. Only after the goal-approval PR is approved and merged under the documented workflow should /gstack-goal <goal-id> --pr <goal-approval-PR> run. Department review does not replace independent goal tests, sealed holdout, cross-vendor review or the separate usability and Production decision.
Prepare a separate multi-item goal only when it fits the approved work:
/gstack-goal-new <goal-id> "<outcome>"
Only after the goal-approval PR is approved and merged:
The pinned marketplace and manifests define this snapshot: 50 packages, with ten department agents and the separate Chief of Staff coordinator. Package counts include pointer or bundle entries; they do not prove those packages are usable in this host.
The 8 skills below have no references/sources.md at this commit, despite the generic instruction to consult it. Report that gap and distinguish any additional verified sources from the package's own references.
Legal and product remain external routes; engineering goes to /gstack-build. Sales and Marketing now have department packages, but their sales: and marketing: specialists come from separate marketplaces and must resolve in the actual session.
it-operations:service-desk
operations:chief-operating-officer
operations:operating-cadence
corporate-strategy:scenario-planning
corporate-strategy:strategic-alliances
customer-experience:chief-customer-officer
customer-experience:customer-success-management
customer-experience:voice-of-customer
The original eight packages draw on headcount commit 98d1c17 under MIT, with MoxyWolf's department agents and packaging edits. Sales and Marketing supply their own head skills without copying external specialists. Check each package's README and provenance. This guide verifies source, not host installation, connector access, live hook behavior or actual department-agent execution.
