Management Consulting

View saved version →

---
name: change-management
description: "Diagnose adoption barriers and design organizational change, stakeholder engagement, communications, training, and reinforcement. Use for system rollouts, new operating models, integration, culture change, and adoption measurement."
license: MIT
metadata:
  category: engagement-delivery
  version: "2.2.0"
  author: Anot
---

# Change Management

Help the affected people perform the new work and sustain the intended business outcome. Diagnose the barrier before prescribing communications or training. Resistance, workarounds, and low usage can reveal a flaw in the process, incentives, access, workload, or technology.

Use the supplied change, affected groups, timeline, sponsorship, and observed behavior. Produce a useful first draft from partial information, marking unknowns and proposed assumptions. Ask only when a missing input materially changes the intervention. Do not invent stakeholder attitudes, adoption figures, job guarantees, or impact estimates.

## Understand the change

Describe what each affected group does today, what must change, what makes that difficult, and what is at stake for them. Separate sponsor intent from employee experience. Inspect competing initiatives, BAU workload, manager capacity, and access to support.

Test barriers to understanding, motivation, knowledge, ability in practice, and reinforcement. These are diagnostic lenses, not a rigid universal sequence. A knowledgeable employee may be unable to adopt because the new system lacks a required feature. Low use is not proof of unwillingness.

Record stakeholder positions from evidence with source and date; use Unknown where no evidence exists. Distinguish influence, degree affected, support, and decision authority. Assign proposed engagement actions by role where names are unavailable. Do not infer personal motives from a job title or cultural stereotype.

## Design the intervention

Match the intervention to the cause: clarify rationale, fix incentives, remove process friction, provide access, change workload, demonstrate useful practice, train, coach, or improve the solution itself. For material concerns, state what evidence would support changing the program rather than persuading people harder.

Use [change interventions](references/change-interventions.md) for phased transformation, communications, champions, training, and resistance responses. Select the pieces the user needs; a communication draft does not require a full transformation plan.

Plan enablement close enough to use that people can practice. Allow for learning, errors, and support demand. Keep service continuity and manager capacity explicit. Mark governance gates as execution decisions, not prerequisites for drafting a plan.

## Measure sustained behavior and outcomes

Define adoption operationally: eligible population, qualifying task or behavior, observation window, numerator, denominator, and source. Segment where a total would hide exclusion, access gaps, or uneven adoption. Report the quality and persistence of use, not just logins or training attendance.

Connect leading signals such as access and proficiency to the business outcome that funded the change. Separate measured outcomes from forecasts, and distinguish association from evidence that the intervention caused improvement. For surveys, state sample and response coverage; do not treat nonrespondents as supporters or a favorable average as universal readiness.

Set a baseline, target basis, measurement owner, review point, and intervention trigger. Targets and dates may be proposed if labeled. Do not invent an industry adoption benchmark or apply a fixed communications frequency.

## Deliver

Give the requested change approach, stakeholder plan, communications, training design, or adoption scorecard with its diagnostic basis. Explain the intervention, owner, timing, success evidence, and fallback where the risk warrants it. Keep messages truthful about employment implications, uncertainty, and what has been decided. Drafting communications does not authorize sending them or making commitments on the client's behalf.

Referenced files: 1

View saved version →

---
name: client-deliverables
description: "Create and refine consulting reports, decision memos, and executive presentations, including storylines, exhibits, visual design, and artifact review. Use for board readouts, investment committee memos, steering updates, and final reports. For sales proposals and pitch decks, use proposal-development when available."
license: MIT
metadata:
  category: communication
  version: "2.2.0"
  author: Anot
---

# Client Deliverables

Turn the analysis into an artifact that enables the intended decision and survives scrutiny. Establish the audience, decision, evidence base, requested format, and reading or presentation conditions from the user's context. Preserve supplied templates, branding, section order, accessibility needs, and length constraints.

Use available evidence and complete the portions it supports. Mark missing proof points or pending decisions where they matter; ask only when a missing answer blocks a useful result. Do not invent a number, source, owner, date, testimonial, or case result to fill a design. Distinguish proposed actions from agreed commitments.

## Build the argument

Lead with the answer, decision request, or the uncertainty that prevents a decision. Organize supporting arguments by what the audience needs to assess the recommendation. Situation-complication-question-answer can help develop the story; it does not require delaying the answer or showing those labels.

Use takeaway titles for analytical sections and slides when they aid comprehension. Keep navigational labels or prescribed headings where the template requires them. The headline must be supported by the exhibit and its qualifications. Do not turn an association into a causal claim or a forecast into an achieved result.

Connect each consequential claim to its source or calculation. Keep units, periods, definitions, and scenario names consistent throughout. Show contradictions and decision-changing limitations near the claim they qualify. Separate observed results, forecasts, judgment, and illustrative examples. A conditional sentence still needs a basis if it asserts an empirical pattern.

Concentrate detail on the trade-offs, financial and operational implications, and actions that determine this decision. Use compact tables for comparisons and prose for reasoning. There is no required sentence count, supporting-argument count, or deck length.

## Choose the artifact

Follow an explicit format request. If the format is open, a memo or report suits asynchronous scrutiny; a presentation suits a discussion with visual evidence. A read-ahead deck needs more self-contained explanation than a projected presentation. Produce multiple formats only when requested or needed for the stated use.

- For reports, decision briefs, and investment committee memos, read [written reports](references/written-reports.md).
- For executive decks, exhibit selection, discussion design, and backup, read [executive presentations](references/executive-presentations.md).
- When designing or substantially revising slides, read [slide design](references/slide-design.md) for visual direction, composition, analytical emphasis, and review across the deck.
- When producing a PowerPoint file with code, read [PPTX generation](references/pptx-generation.md). The optional bridge helper is a tool-specific implementation, not a requirement for other presentation tools.

Use the host's available document, spreadsheet, or presentation tools and relevant format skills if available. This skill supplies consulting content and review criteria; it does not depend on a particular agent or installed plugin. For a requested file, create the file when tools permit. If creation or rendering is unavailable, state the limitation and deliver the usable portion without claiming a finished artifact.

## Check before delivery

Check that the executive summary stands alone, the recommendation follows from the evidence, and the requested decision is explicit. Reconcile figures across prose, tables, charts, and appendices. Test that a chart actually represents the intended relationship, not merely that it renders.

For files, open or parse the saved artifact, refresh calculations where supported, and inspect rendered pages or slides. Check clipping, overlap, legibility, pagination, source notes, and navigation at the intended reading size. Inspect material revisions again, stopping once the affected checks pass. Give the user the artifact and a concise account of material assumptions or verification limits.

For decks, also inspect the slides together. A sequence of correctly aligned but repetitive text boxes can still be a weak presentation. Use layout, scale, and visual emphasis to make the argument easier to understand while retaining the client's visual identity. Keep drafting and validation commentary out of the delivered content.

Referenced files: 5

View saved version →

---
name: due-diligence
description: "Investigate commercial, operational, financial, strategic, and technology claims for acquisition, investment, partnership, or vendor decisions. Use for data-room analysis, quality of earnings, customer concentration, working capital, synergies, and diligence recommendations."
license: MIT
metadata:
  category: problem-solving
  version: "2.2.0"
  author: Anot
---

# Due Diligence

Determine whether the opportunity is viable, what remains unverified, and which findings change value, terms, conditions, or the operating decision. Adapt to the transaction: an acquisition needs price and funding implications; a vendor assessment may turn on service continuity, switching cost, or exit rights.

Establish the decision, materiality, deadline, access, and scope from the brief. Use available materials before requesting more. Prioritize unknowns that could change the decision, and continue independent work while access is incomplete. A data gap is a limitation or risk to investigate, not proof of concealment. Do not invent data, interviews, benchmarks, or assurances.

## Investigate the thesis

State the propositions that must hold for the opportunity to work and the evidence that would disprove them. Focus effort on concentration, renewal, earnings quality, cash requirements, capabilities, and other drivers material to this case. Do not require every diligence stream for a narrow assignment.

For each consequential finding, record the claim, source and period, test performed, result, limitation, and decision implication. Preserve conflicts between management accounts, presentations, contracts, and customer records. Reconcile dates, entities, definitions, and populations before selecting or combining figures. Source agreement is meaningful only if the evidence is sufficiently independent.

Use [commercial and operational diligence](references/commercial-operational.md) for customers, market, management, technology, vendors, and operating feasibility. Use [financial diligence and integration](references/financial-and-integration.md) for QoE, working capital, cash conversion, deal adjustments, synergies, and Day 1 readiness.

## Translate findings into the decision

Distinguish a deal killer or unacceptable operating exposure, a condition to clear before commitment, an adjustment to price or terms, and an issue that can be managed after commitment. An unquantified risk can still determine the choice. Do not discard a finding because it cannot yet be converted into a dollar amount.

Quantify an adjustment only where its basis is defensible. Avoid double-counting the same exposure in earnings, cash flow, valuation multiple, and a separate discount. Generic concentration thresholds, EBITDA-adjustment percentages, or synergy haircuts are not transaction facts. Use the client's risk appetite and comparable evidence; otherwise show case-specific scenarios and limitations.

Test funding and integration feasibility separately from valuation. A price adjustment does not cure a continuity, consent, or capability problem. Mitigation changes risk only if it is feasible, funded, owned, and tied to the exposure; an earn-out or escrow does not automatically replace lost customers.

## Deliver

Lead with proceed, proceed subject to specific conditions, defer, or decline as the evidence supports. Explain the thesis, strongest supporting evidence, material concerns, value or term implications, unresolved tests, and decision-changing conditions. State what was and was not verified. Do not claim audit, legal, security, or technical assurance beyond the work performed.

For further work, give a prioritized request or test with purpose, owner by role if unknown, and timing relative to the deadline. Draft customer questions or outreach when useful; contact people or use restricted systems only within the user's authorization. Keep numerical cells compact and reasoning near the finding it supports.

Referenced files: 2

View saved version →

---
name: engagement-pricing
description: "Price consulting engagements and evaluate delivery economics. Use for fee models, rate cards, margin floors, realization, retainers, discounts, payment schedules, and the commercial section of a proposal or SOW."
license: MIT
metadata:
  category: business-development
  version: "2.2.0"
  author: Anot
---

# Engagement Pricing

Develop a commercially credible price that fits the scope, delivery cost, value to the client, and available alternatives. Start with the user's requested pricing decision; preserve an agreed model or terms unless a material problem needs to be raised.

Use the supplied scope, cost basis, capacity, rate card, target margins, budget, and procurement context. Continue a draft with explicit unknowns when inputs are missing; ask only for information that prevents a defensible calculation or recommendation. Do not substitute generic rate or margin benchmarks for firm data.

## Select the commercial model

Assess scope certainty, duration, deliverables, dependence on client actions, outcome measurability, attribution, and payment risk. Fixed fees fit bounded deliverables when delivery risk can be estimated. T&M fits evolving work; caps need an explicit scope or effort boundary. Retainers fit continuing access or delivery with defined capacity and service expectations, including a new client when that arrangement is suitable.

Distinguish pricing based on value from payment contingent on outcomes. A fixed value-based fee need not depend on measuring realized results; an outcome-linked fee needs a defensible baseline, measurement rules, attribution, timing, and treatment of external factors. Hybrid structures can share uncertainty without leaving all costs at risk.

## Model the economics

Define what each cost includes before adding it. If personnel cost already includes benefits and allocated overhead, do not allocate that overhead again. Separate direct delivery costs, incremental external costs, allocated overhead, and risk contingency. Make the allocation basis explicit. Do not use billing rates as personnel costs.

Calculate the relevant measures with available tools and state their definitions:

- Delivery margin amount = fee minus defined direct delivery cost; percentage = that amount divided by fee.
- Profit after allocations = fee minus all included costs, counted once; percentage = profit divided by fee.
- Minimum fee for target margin `m` on that cost basis = included cost / `(1-m)`, for `m < 1`.
- Realization = actual fee / rate-card value of actual delivery effort. Explain write-offs, discounts, and scope growth.
- Effective daily rate = fee / total person-days. Confirm the workday length and distinguish headcount from effort.

Show the effect of overrun, scope change, discount, and payment timing where they change the decision. A contingency is a disclosed allowance derived from risks, not an automatic percentage added to an already risk-adjusted estimate.

## Propose terms and trade-offs

Use [commercial structures and negotiation](references/commercial-structures.md) for payment, retainer, outcome, and concession detail. Respect supplied contract terms and the firm's approval authority. Present proposed terms as proposals, not universal legal requirements or commitments already made.

Tie payment timing to the delivery cost curve, exposure to delayed acceptance, and procurement constraints. Quantify financing costs where material instead of imposing a universal Net 30 or final-payment cap. Make scope, client dependencies, change control, acceptance, and exit terms specific to the engagement.

For the client's value case, distinguish benefit-cost multiple (`benefits / costs`) from net ROI (`(benefits-costs)/costs`). Include relevant client implementation and operating costs, not only the consulting fee. Explain whether benefits are cash savings, released capacity, incremental contribution, or risk reduction. Claim attribution only where supported.

## Deliver

Present the recommended fee and structure, included scope, assumptions, cost and margin basis, downside exposure, payment schedule, and decisions needed. Offer alternative tiers only when they represent useful scope or risk choices. Keep numerical tables compact and put the rationale beside the choice. Producing a quote does not authorize submitting it or agreeing concessions with a client.

Referenced files: 1

View saved version →

---
name: engagement-setup
description: "Launch a consulting engagement with a focused kickoff, discovery plan, stakeholder assessment, and working arrangements. Use after award or when resetting an engagement that lacks shared scope, access, or decision authority."
license: MIT
metadata:
  category: engagement-delivery
  version: "2.2.0"
  author: Anot
---

# Engagement Setup

Turn the agreed engagement into a shared problem definition, access to evidence, working ownership, and useful early progress. Preserve the contract, approved scope, existing work, and client's operating requirements. Do not replay sales qualification after award or impose enterprise governance on a small advisory task.

Use the brief, contract, known team, timeline, and available data. Draft supported portions while recording missing information. Ask only when a missing answer changes the scope or makes the plan unusable. Mark unknown stakeholder positions and proposed commitments rather than filling them with plausible names, dates, or attitudes.

## Prepare the launch

Identify the outcome, decision-maker, scope boundaries, deliverables, success evidence, dependencies, and near-term decisions. Compare expectations with the agreement and make discrepancies visible. Separate contractual commitments from planning assumptions.

Map affected groups and decision roles. Use a power-interest matrix when it helps: high power/high interest = manage closely; high power/low interest = keep satisfied; low power/high interest = keep informed and hear their input; low power/low interest = monitor proportionately. Influence and interest do not establish support or opposition. Record stance from evidence and revisit it when information changes.

Design the kickoff around unresolved alignment and decisions. Move routine information into a proportionate pre-read if time permits. Select a duration and participants to fit the brief; a kickoff can be a short working session rather than a workshop. Identify the authority or representation required for decisions without treating absence as automatic evidence of disengagement.

For a charter, use [project charter template](references/project-charter-template.md). Adapt fields to the engagement; do not require every field to be finalized live or describe a charter as replacing the contract.

## Design discovery

Tie each question to the decision it will inform. Choose data review, interviews, observation, working sessions, or a survey according to the evidence needed. Use [discovery methods](references/discovery-methods.md) for requests, interviews, and synthesis.

Distinguish an interview report, an observed behavior, and a measured outcome. Several people reporting the same theme can justify further investigation but do not establish prevalence or causality. Test executive accounts against operating evidence without assuming either is always more accurate.

Prioritize evidence that could change the recommendation or unlock work. Track what was requested, supplied, tested, and still missing. Do not commission broad research or contact stakeholders merely because a template lists them; execute those actions within the user's authorization.

## Establish working arrangements

For the work that needs coordination, set workstream ownership, deliverable handoffs, decision rights, access, document locations, version conventions, communication channels, and escalation. Reuse the client's systems and governance. Schedule only the ceremonies needed to make decisions or resolve dependencies.

Capture actual agreements separately from proposals. Protect sensitive stakeholder assessments and interview confidentiality under the engagement's rules; sanitize shared materials where appropriate. Do not promise anonymity or record a meeting without the applicable agreement and authorization.

## Deliver

Produce the requested kickoff agenda, charter draft, discovery plan, interview guide, or launch pack. Check that it reflects the contract, identifies unresolved decisions, and makes the first useful work clear. Named actions need an owner and timing; when unconfirmed, use a proposed role and relative date. Report evidence gaps as work to resolve, not as invented findings.

Referenced files: 2

View saved version →

---
name: financial-modeling
description: "Build auditable financial models and business cases for investment, valuation, cost-benefit, and build-versus-buy decisions. Use for cash-flow projections, NPV, IRR, ROI, payback, TCO, break-even, and sensitivity analysis."
license: MIT
metadata:
  category: problem-solving
  version: "2.2.0"
  author: Anot
---

# Financial Modeling

Build the financial evidence for the user's decision. Work at the requested scope: checking a calculation, comparing investments, constructing a workbook, or valuing a business. Preserve supplied assumptions, horizons, conventions, and approved decisions; challenge a material inconsistency explicitly.

## Establish the model basis

Use provided data first. Identify missing drivers and continue portions they do not block. Ask when a missing input prevents a defensible result; otherwise show a disclosed assumption, range, or symbolic formula. Keep hypothetical examples separate from client estimates. Never invent costs, forecasts, benchmarks, or evidence for a benefit.

For the model being built, define relevant conventions: currency and units, valuation date, cash-flow timing, horizon, baseline, inflation treatment, taxes, financing, working capital, and terminal value. Compare options on the same basis. Historical actuals, supplied forecasts, sourced estimates, and unsupported placeholders remain distinguishable.

Maintain one source for each assumption. Record its value, unit, period, basis, source, and limitation in a register when the model's size warrants one; for a short calculation, put the assumptions beside the result. Treat a management forecast as a forecast even if it arrives in a polished workbook.

## Model the incremental economics

Calculate cash flows relative to the stated baseline. Include continuing the current course or deferral when relevant, without reopening an approved choice just to add an option. Avoid counting the same benefit as labor savings, productivity, and revenue uplift. Separate time released, usable capacity, realized cash savings, and additional output.

Use [cash-flow and return conventions](references/cash-flow-conventions.md) for calculations and [technology and TCO economics](references/technology-and-tco.md) for build-versus-buy, automation, or AI investments. Use [valuation and uncertainty methods](references/valuation-and-risk.md) only when DCF, scenario probabilities, Monte Carlo, EVA, MIRR, or options are relevant.

Use available calculation tools for material arithmetic. Show formulas and enough intermediate results to reproduce the answer. In a workbook, link outputs to inputs, keep assumptions separate from formulas, label units and periods, and make scenarios update the model consistently. Recalculate where tools allow and inspect the saved output; disclose if formula results could not be refreshed.

## Test the decision

Test funding feasibility separately from investment return. A positive NPV does not solve an interim cash shortfall. Examine payment timing, committed financing, capacity, and other hard constraints before recommending approval.

Find the inputs that can change the recommendation and vary them over plausible ranges. Show the break-even or switching threshold. Do not mechanically apply ±10%, increase discount rates because data is missing, or assign probabilities without a basis. Preserve conflicting sources and show their decision effect. Distinguish scenario assumptions from forecasts and avoid counting the same risk in both cash-flow haircuts and discount-rate adjustments without explaining why.

## Present and verify

Lead with the recommendation, investment, financial result, funding requirement, and principal limitation. Report only metrics that help this decision. Use compact numeric tables and explain assumptions beside them. State the downside being accepted and what would change the choice. Where essential evidence is absent, a conditional decision or deferral can be the supported answer.

Check signs, units, timing, totals, baseline treatment, cost and benefit overlap, terminal assumptions, and sensitivity direction. For file requests, deliver the working artifact and a concise explanation of how to change its assumptions. Do not claim independent verification or audit assurance beyond the checks performed.

Referenced files: 3

View saved version →

---
name: implementation-planning
description: "Turn an agreed recommendation into a feasible roadmap and implementation plan. Use for sequencing, workstreams, dependencies, resources, rollout gates, recovery plans, and the business case needed to fund execution."
license: MIT
metadata:
  category: engagement-delivery
  version: "2.2.0"
  author: Anot
---

# Implementation Planning

Produce a plan that respects funding, capacity, dependencies, and the decision already made. Enter at the requested stage: compare execution approaches, secure funding, design a roadmap, detail workstreams, or recover a slipping plan. Do not repeat strategy or build a new business case when the direction and funding are already approved.

Use the supplied recommendation, constraints, milestones, resource availability, and baseline. Mark unknowns and proceed with supported portions. Ask only when a missing input prevents a useful or defensible plan. Label estimated durations, proposed owners, and unapproved dates explicitly; do not invent commitments.

## Choose the feasible approach

Where execution choices are open, compare materially different approaches, including defer or continue current operations when relevant. Screen hard constraints before weighted preferences. A high score cannot compensate for missing legal eligibility, unaffordable peak funding, or unavailable capacity. Use weights only when they represent the decision-maker's priorities; test whether plausible changes alter the choice.

If funding analysis is requested, show incremental costs and benefits, timing, downside, and funding need against a consistent baseline. Distinguish released capacity from cash savings, and revenue from contribution. Use financial-modeling if available for substantial calculations; this workflow does not depend on that skill being installed. Do not invent a hurdle rate or add a standard contingency percentage to make a plan look complete.

## Sequence the work

Define outcomes and acceptance criteria before assigning activities. Group workstreams by manageable responsibility and explicit interfaces. Map dependencies, required client decisions, vendor lead times, and business calendar constraints before committing dates.

Use [scheduling and resourcing](references/scheduling-and-resourcing.md) for critical paths, effort, capacity, and recovery. Distinguish target dates from feasible forecasts. Protect business continuity and account for parallel operations, training, adoption, support, and benefit measurement where relevant.

Choose rollout gates that release commitment as evidence improves. State the evidence needed, authority, and responses: proceed, proceed with bounded conditions, revise, or stop. These are gates for executing the plan, not prerequisites for drafting later phases. Provisional later phases can remain useful while earlier evidence is pending.

## Assign ownership and control

Give each deliverable an accountable role and the people doing the work. In a RACI, normally assign one A and at least one R, with combined A/R allowed on small teams. Confirm how joint legal authorities or mandated approvals are represented without hiding them in a simplified matrix. Keep consulted roles limited to those whose input changes the work.

Use the client's existing governance where supplied. Set escalation by materiality, remaining decision time, and authority rather than generic two-week or 10% cutoffs. For ongoing reporting, project-governance can help when available. Separate consulting recommendations from client approval and spending authority.

## Deliver and check

Present the outcome, sequence, workstreams, milestone evidence, dependencies, capacity, budget, risks, and immediate decision or action at the requested depth. A short roadmap does not require a full program handbook.

Verify dates follow dependencies, resource demand fits availability, budgets reconcile, and benefits have a measurement owner. Show the limiting constraint and the consequence of delay. For a recovery plan, distinguish the original baseline, current forecast, and proposed reset; do not erase slippage by silently replacing the baseline. State the trigger and fallback for the risks that could defeat the plan.

Referenced files: 1

View saved version →

---
name: org-design
description: "Design organizational structures, operating models, role architectures, and transitions that support strategy. Use for reporting lines, spans and layers, centralization, decision rights, job families, and reorganizations."
license: MIT
metadata:
  category: engagement-delivery
  version: "2.2.0"
  author: Anot
---

# Organizational Design

Design how work, decisions, and accountability fit together. Diagnose whether structure is part of the problem before proposing a reorganization. The user may need one role definition, a decision-rights repair, an operating-model comparison, or a full transition; match that scope.

Use supplied strategy, work flows, organization data, constraints, and employee implications. Mark missing facts and proposed roles or spans. Ask only when an unknown prevents a defensible design; draft alternative designs or principles where the strategy remains unsettled. Do not invent headcount, costs, capability scores, stakeholder positions, or approval.

## Diagnose the operating problem

Trace strategic priorities to capabilities and recurring decisions. Identify what the organization must do better and how success will be observed. Inspect how work actually crosses functions, where it queues, who resolves exceptions, and which informal arrangements make it work.

Separate structural problems from gaps in systems, skills, incentives, process, workload, or leadership. A maturity gap does not establish its cause. Use 7S or another alignment lens only when it helps test a specific mismatch; ratings need behavioral anchors and evidence. Consider a repair to decision rights or coordination before changing reporting lines.

Baseline relevant layers, spans, roles, effort, costs, vacancies, and service outcomes using consistent definitions. Average span can hide very different work. Diagnose supervision and coordination demand rather than declaring a narrow span vanity or a wide span neglect.

## Compare viable designs

Define principles that resolve a trade-off, such as which decisions need local customer knowledge and which gain from scale. Compare functional, product, geography, customer, matrix, network, or platform structures as appropriate. Assess strategic fit, economics, service, accountability, coordination cost, talent, and transition risk. Preserve the approved strategy and actual constraints.

Use [operating models and roles](references/operating-models-and-roles.md) for structural choices, spans, job architecture, and integration. A matrix needs explicit decision rights when objectives conflict; a simpler hierarchy still needs a mechanism for cross-functional work. Do not select a structure from fashion or a preferred span benchmark.

## Make the design executable

Define unit mandates, outputs, reporting relationships, decision authority, and integration mechanisms. For material roles, specify purpose, accountabilities, authority, required capabilities, relationships, and capacity. Distinguish the design of roles from the selection of individuals; personnel decisions need appropriate evidence and the client's process.

Sequence the transition around continuity, dependencies, required consultation, role clarity, staffing, systems, and support. Label proposed timing and approvals. Surface job and career implications honestly, including what is unresolved. Do not promise employment outcomes or impose a generic communication calendar.

## Deliver and assess

Present the recommended design with its rationale, trade-offs, alternative, transition conditions, and operating measures. Use an org chart when it explains reporting, but include how work and decisions cross the boxes. A chart alone is insufficient for a complex operating model.

Check workload, role overlap and gaps, contradictory authorities, coordination capacity, and transition continuity. Define observable tests such as decision latency, handoff quality, customer outcomes, cost, and role clarity against baseline. Set review points to the change's risk and pace; state what evidence would require adapting the design.

Referenced files: 1

View saved version →

---
name: process-excellence
description: "Diagnose and improve business processes using evidence, flow analysis, Lean, and appropriate statistical methods. Use for bottlenecks, cycle time, defects, cost, process mining, DMAIC plans, and control design."
license: MIT
metadata:
  category: engagement-delivery
  version: "2.2.0"
  author: Anot
---

# Process Excellence

Find the cause of an operating problem and design an improvement that works for the whole process. Use Lean, Six Sigma, or a simpler diagnostic according to the question and evidence. A narrow analysis does not require producing every DMAIC artifact.

Establish boundaries, customer requirement, decision, available data, and the user's requested output. Work from the supplied baseline and definitions. If data is incomplete, provide a provisional diagnosis or measurement plan with limitations; do not invent a baseline or require real-world sign-offs before drafting. Execution gates and controlled rollout still matter where the operational risk requires them.

## Measure the work as it happens

Define the start and end event, unit of work, eligible cases, period, and whether time includes waiting, nonbusiness hours, rework, and incomplete cases. Separate touch time from elapsed time. Inspect missing events, duplicates, time zones, selection bias, and open cases before trusting averages.

Map the flow, decisions, queues, handoffs, and exceptions from evidence. SIPOC can establish boundaries; value-stream mapping can expose waiting and inventory. Use the mapping depth that helps the decision. Do not infer a bottleneck solely from the longest average duration when parallel capacity, batch size, or demand differs.

Use [measurement and statistical methods](references/measurement-and-statistics.md) for event logs, capability, control charts, and flow measures. Apply statistical tools only when their assumptions and data are suitable. Unknown performance is not a sigma level.

## Test causes and design improvements

Use observation, process data, interviews, Pareto analysis, fishbone, and repeated why questions to generate testable explanations. Distinguish a suspected cause from a verified cause. “Human error” may hide a design or control issue; an external cause should not be discarded merely because the team cannot control it.

Assess waiting, rework, unnecessary movement, excess work, inventory, redundant processing, and unused capabilities in context. Do not remove a control or apparently non-value-adding step without understanding its purpose and obligation. Check downstream effects and constraints before optimizing one step.

Compare feasible changes by impact, cost, service risk, adoption, and reversibility. For material changes, define a pilot, baseline comparison, success criterion, and stop or rollback trigger. For low-risk improvements, verification can be proportionate rather than a ceremonial gate.

## Quantify without double counting

Build the financial effect from volumes, time, rates, quality, and actual cost changes. Separate released labor capacity from reduced spending. Increased throughput produces revenue only if demand and downstream capacity permit it; use incremental contribution and cash where appropriate. Keep service quality, risk, and nonfinancial outcomes visible when they are the reason for the change.

State the period and included costs for ROI and payback. Calculate net ROI as `(benefits-costs)/costs` over that period; show implementation, ongoing costs, and the benefit ramp. Do not count the same improvement as labor savings and redeployed capacity simultaneously.

## Sustain and deliver

Define operating ownership, revised standard work, monitoring, and a response when performance deteriorates. Control limits describe observed process variation; specification limits describe requirements. Do not substitute one for the other.

Deliver the analysis, improvement plan, map, or control design requested. Explain the evidence, remaining uncertainty, recommended change, expected effect, and what would disprove the diagnosis. For actual implementation, confirm training, ownership, support, and relevant approvals through the existing operating process. Do not report a pilot or improvement as completed when only a plan was drafted.

Referenced files: 1

View saved version →

---
name: project-closeout
description: "Close or transition a consulting engagement through acceptance, handover, knowledge transfer, benefits ownership, financial reconciliation, and lessons learned. Use for successful completion, early termination, suspension, or transition to business-as-usual."
license: MIT
metadata:
  category: engagement-delivery
  version: "2.2.0"
  author: Anot
---

# Project Closeout

Leave the client able to operate the delivered work and maintain a clear record of what was accepted, transferred, and left open. Adapt closeout to successful completion, early termination, suspension, or transition to business-as-usual. A paused project needs restart conditions; a terminated project needs an accurate partial handover.

Use the agreement, deliverable inventory, acceptance records, finances, and operating responsibilities supplied. Extract lists and figures from those materials; do not invent them. Produce supported draft sections with explicit gaps, asking only when a missing input changes the closure decision. Preserve the agreed scope and support obligations.

## Assess readiness

Separate closure conditions, tasks needed to reach them, and items the authorized owner can accept with a resolution plan. Acceptance of delivered scope may occur before longer-term benefits mature. Do not require future benefits to be fully realized or every minor issue resolved if the agreed closure criteria permit handover.

Record each deliverable's current version, location, status, acceptance evidence, receiving owner, and open items. Distinguish delivered, reviewed, accepted, and operationally supported. A draft signature block is not acceptance.

## Transfer usable ownership

Prepare the user, technical, operating, or analytical documentation the work actually needs. A financial model needs assumptions and update instructions; a live process may need a runbook, monitoring, escalation, and tested exception handling. Do not require API documentation or hypercare for a memo-only engagement.

For knowledge transfer, identify the recipient, method, material, and evidence that the recipient can use it. A document link or attendance record alone may not demonstrate readiness for critical work. Define the post-project support scope, dates, owner, escalation, and any unresolved commitment from the actual agreement.

For benefits, transfer definition, baseline, target basis, current measurement, source, calculation, owner, and review or intervention trigger. Separate measured results from forecasts and annualized run rates. Do not impose a generic benefits calendar. Plan future reviews where appropriate, without scheduling them unless authorized.

## Reconcile and learn

Reconcile budget, actual and committed costs, invoices, payments, expenses, and remaining obligations. Explain variances and distinguish a proposed settlement from agreed billing. Release resources and access only through the relevant authority, with continuity and retention obligations understood.

Use [closeout and early termination](references/closeout-and-termination.md) for readiness records, lessons, handover, and a difficult ending. Capture lessons from evidence and translate them into a specific change for future work; do not invent personnel feedback or attribute quotes without support.

For regulated engagements, data disposition, or retention questions, read [regulated-industry closeout](references/regulated-industry-closeout.md). Verify applicable current rules, contracts, holds, and ownership before recommending disposition. Drafting a closeout plan does not authorize deleting data or closing contracts.

## Deliver

Produce the requested checklist, handover pack, acceptance draft, retrospective, or closure report. State the closure recommendation, completed and pending evidence, accepted open items, receiving owners, and remaining decisions. Check that the summary reflects the records and the client has a usable route to support. Do not claim sign-off, payment, access revocation, or knowledge transfer has occurred without evidence.

Referenced files: 2

View saved version →

---
name: project-governance
description: "Design and operate consulting engagement governance: decision rights, steering committees, RACI, risk and issue registers, status reports, escalation, and stage gates. Use for oversight of delivery; use implementation-planning when available for the execution plan itself."
license: MIT
metadata:
  category: engagement-delivery
  version: "2.2.0"
  author: Anot
---

# Project Governance

Give the client timely decisions and visibility into delivery. Use the lightest governance that meets the engagement's risk, complexity, and mandatory controls. Start from the client's existing PMO templates, contract, decision rights, and reporting rhythm.

Use available scope, budget, team, milestones, and reporting evidence. Mark missing facts and proposed roles instead of inventing names or approvals. Complete useful draft governance without waiting for charter sign-off; distinguish a proposal from authority to spend, deploy, or change the engagement.

## Establish authority and cadence

A small advisory engagement may need a sponsor, engagement lead, decision log, and short check-in. A transformation may need workstream forums, a program review, and a steering committee. Add a forum only when it makes a decision, resolves a dependency, or satisfies an identified requirement.

For consequential decisions, record the decider, required input or approval, deadline, escalation path, and evidence needed. Distinguish the consultant's internal recommendation review from the client's decision to invest or implement. If the user supplies joint approvals or regulated authorities, preserve them explicitly.

Use RACI when it clarifies delivery responsibility. Normally assign one accountable role per deliverable and at least one responsible role; the same person may be both. Record assignments as proposed until confirmed. Keep roles current when ownership changes.

## Report the state of delivery

Lead with the overall assessment, the decision or intervention needed, and when it becomes time-critical. Separate baseline, current forecast, and approved changes. Report outcomes completed, remaining work, milestones, cost, resource constraints, and material dependencies at the requested depth.

Show RAG status with definitions and trend. Use Unknown where evidence is missing; do not convert missing information into Green. Base progress on delivered scope or a defensible measure of remaining effort. Compare spending to planned and earned progress with the cost curve in view; early front-loaded expenditure alone does not prove overrun.

Use [risk, issues, and reporting](references/risk-and-reporting.md) for registers, severity, forecasting, and escalation. Numerical probabilities and risk scores require a stated basis. Preserve material uncertainty and source conflicts.

## Use gates as decisions

For each gate define the relevant evidence, authority, decision deadline, and options: proceed, proceed with explicit conditions, revise, or stop. Readiness criteria depend on the transition. A go-live gate tests operational readiness before launch; closure acceptance is a separate decision.

Track accepted conditions and open items to a named role and date. Do not treat a passed gate as proof that all future risks are resolved. Avoid duplicating agile and phase-based reporting; use one coherent rhythm with necessary approval points.

## Deliver and maintain

Produce the charter, decision-rights map, status report, register, or governance design requested. Include actionable escalations rather than a mandatory collection of every governance artifact. Check that decisions sit with authorized roles, status follows evidence, dates are feasible, and material risks have owners and responses.

Preparing a status report or meeting pack does not authorize sending it, scheduling meetings, or recording approvals. At closeout, document the handback of decision and reporting responsibilities; use project-closeout when available for detailed handover and benefits ownership.

Referenced files: 1

View saved version →

---
name: proposal-development
description: "Develop consulting pursuits, RFP responses, proposals, statements of work, value propositions, and pitch decks. Use for winning and scoping an engagement; use client-deliverables when available for reports and presentations during delivery."
license: MIT
metadata:
  category: business-development
  version: "2.2.0"
  author: Anot
---

# Proposal Development

Produce a persuasive, compliant proposal for the client's specific buying decision. Start at the requested stage: opportunity assessment, win themes, proposal, SOW, or oral presentation. Do not require qualification of an already approved pursuit or recreate a signed agreement when the request is for a limited edit.

Use the RFP, conversation notes, firm credentials, staffing, and commercial inputs provided. Preserve mandatory format, section order, page limits, and submission requirements. Complete supported sections and flag missing credentials or inputs precisely. Do not invent client results, team members, certifications, competitor intelligence, references, or outcome percentages.

## Understand the buying decision

Distinguish must-pass requirements from scored criteria and inferred preferences. Record submission deadlines, format, mandatory attachments, eligibility, evaluation weights, and clarification procedures. Trace each material requirement to its source, response location, evidence, owner, and completion status. A persuasive response that fails a mandatory requirement may be unusable.

For qualification when requested, assess fit, capability, capacity, economics, strategic value, and the cost of pursuit. State the basis for a go/no-go recommendation. Do not invent win probabilities or conclude that a deal is wired from one unusual requirement; identify evidence and questions to test that concern.

Develop win themes from the client's priorities and proof the firm can substantiate. A differentiator explains why this team or approach fits this problem and what evidence supports it. Conditional wording does not justify an unsupported savings range or implied track record.

## Draft the requested artifact

For a proposal, connect the client's challenge to approach, deliverables, outcomes, team, evidence, investment, assumptions, and next decision. Adapt this arc to the required response order. Write the executive summary against the completed proposal so it reflects the actual scope and terms.

For a SOW, use [proposal and SOW mechanics](references/proposal-and-sow.md). Define boundaries, acceptance, client obligations, dependencies, pricing basis, and change control. Respect supplied contract terms and distinguish proposed provisions from agreed terms. Do not impose deemed acceptance, liability caps, or signature requirements as universal rules.

For a pitch or oral defense, use [pitch deck](references/pitch-deck.md). Preserve the time slot, audience, and decision objective. For pricing, engagement-pricing can help when available, but this skill remains usable independently.

## Persuasion and evidence

State the outcome and how the approach could achieve it. Separate delivery commitments from forecast business benefits that depend on client action or external conditions. Use relevant real cases, with permitted attribution, and accurately label hypothetical examples. A missing proof point can remain a specific draft marker; do not fill it with fabricated prose to make the document look finished.

Address supported objections and material risks. Explain what the client must provide and the trade-off being proposed. Avoid generic capability claims, unsupported superlatives, and a menu of services unrelated to the request.

## Complete and check

Deliver the proposal, SOW, pitch, or assessment requested. When a file is requested, use available document or presentation tools and format skills if present; no particular host or plugin is required. Check the saved artifact and rendered layout when tools allow.

Verify requirement coverage, section and page constraints, consistency of scope, dates, staffing and fees, substantiation of credentials, and visibility of unresolved items. Check arithmetic with available tools. Preparing a response does not authorize submitting it, contacting the buyer, or agreeing terms. State the material gaps that prevent the draft from being submitted as-is.

Referenced files: 2

View saved version →

---
name: strategic-analysis
description: "Structure an ambiguous business decision, test competing explanations, and recommend a course using evidence. Use for growth, market entry, competitive positioning, business models, and portfolio choices. For execution of an approved direction, use implementation-planning when available."
license: MIT
metadata:
  category: problem-solving
  version: "2.2.0"
  author: Anot
---

# Strategic Analysis

Produce an answer the decision-maker can use and a supporting argument a skeptical reviewer can inspect. Start at the user's current stage: framing a question, diagnosing a cause, evaluating options, or challenging a recommendation. Do not restart completed analysis unless a material inconsistency changes the decision.

## Frame the work

Identify the decision, decision-maker, timeframe, success criteria, and constraints from the supplied context. Respect the requested format and length. Distinguish hard constraints (cash, legal eligibility, capacity, deadlines) from preferences that can be traded off. Screen infeasible options before comparing attractive features.

Use what is available. Mark missing information and proceed with work it does not block. Ask only when the missing answer materially changes the decision and cannot be handled with a transparent assumption or conditional recommendation. A request for a draft or an illustrative method does not require a complete client data room. Label fictional examples at their point of use.

## Diagnose and compare

Build a causal decomposition that fits the economics or operating problem. Define units and avoid overlapping branches or mixing different cuts of the same business. A price-volume-mix bridge may answer a profitability question more directly than a named strategic framework.

For the branches that could change the answer, state a testable hypothesis, evidence for and against it, the quickest useful test, and the action implied if it holds. Distinguish a plausible mechanism from a demonstrated cause. Prioritize by decision impact, uncertainty, and the cost of obtaining better information. Stop expanding an analysis when further work would not change the choice at the required confidence.

Develop materially different options when the choice is open. Include continuing the current course or deferring when relevant. Compare on consistent scope, timing, economics, execution capacity, reversibility, and the client's priorities. Do not invent alternatives or reopen an approved choice merely to complete a table.

Use [strategic frameworks](references/strategic-frameworks.md) only for the lens the question needs. There is no minimum framework count. A second lens earns its place by revealing a distinct driver, trade-off, or blind spot. Two frameworks using the same evidence do not provide independent corroboration.

## Evidence and uncertainty

Trace consequential claims to a supplied file, interview, calculation, or external source. Record date, population, definitions, and limitations where they affect comparability. Separate observed results, management claims, estimates, and forecasts. When current external information is required, use available research tools and primary sources; if unavailable, identify what remains unverified.

Keep conflicting sources visible. Investigate differences in dates, populations, definitions, and incentives before choosing between them. Do not average incompatible estimates or convert repeated interview opinions into measured facts. Treat benchmarks as comparisons with a stated source and context, not automatic targets.

For market sizing or competitor work, use [market and competitive analysis](references/market-and-competition.md). Compute material quantities with available tools, show the method, and test the assumptions that could reverse the answer.

## Deliver the decision

Lead with the recommendation or the specific reason a decision must remain conditional. Connect the supporting evidence to implications, trade-offs, and action. State the strongest supported alternative, the downside being accepted, and what new evidence or threshold would change the recommendation. For execution next steps, distinguish proposed owners and dates from agreed commitments.

Keep tables compact: numeric cells contain numbers with units; assessments have enough nearby reasoning to be defensible. Match confidence and precision to evidence. A complete answer can be a paragraph, an issue tree, a workplan, or a substantial report; the user's decision determines the form.

Referenced files: 2

View saved version →

---
name: thought-leadership
description: "Develop evidence-backed points of view, white papers, case studies, industry briefs, and research reports for a consulting audience. Use to turn research or permitted engagement experience into a useful, defensible argument."
license: MIT
metadata:
  category: business-development
  version: "2.2.0"
  author: Anot
---

# Thought Leadership

Produce a useful perspective that a practitioner can defend and act on. Match the user's audience, publication format, voice, length, and business purpose. A thesis earns its place through evidence and decision relevance; it does not need to be provocative or contrarian.

Use the research, firm experience, and approved cases provided. Identify missing evidence and draft what is supportable. Ask only when a missing answer determines the piece's meaning or permitted use. Do not invent engagement counts, research findings, quotes, customer results, or claims about what other firms have observed.

## Develop the thesis

State the argument and where it applies. Identify the decision it changes, the mechanism, the boundary conditions, and the strongest supported alternative explanation. A broad trend summary may need a sharper question; do not manufacture disagreement to make it distinctive.

For each consequential factual claim, keep the source, date, population, method where relevant, and limitation. Separate empirical findings, a proposed mechanism, forecast, and opinion. “Organizations that do X tend to see Y” and “research suggests” still need evidence. When sources conflict, explain the difference or preserve the uncertainty.

Use current primary sources when the topic requires research and tools are available. Do not imply research has been performed when it has not. A useful evidence-limited draft can identify which claims need support and state a narrower thesis.

## Build the asset

Use [content formats and evidence](references/content-and-evidence.md) for POVs, white papers, case studies, industry briefs, and research reports. Choose the format the user requested and adapt its structure; section lengths and counts are not fixed quotas.

Make a specific managerial argument: what should the reader decide or do differently, and why does this evidence support that advice? Keep the argument central when evidence is limited. State material qualifications concisely beside the relevant claim; put source and approval housekeeping in a reviewer note. Do not fill the piece with repeated warnings or generic advice to collect more data. Connect findings to the implications for the reader. Include the counterargument when it has evidence or a plausible mechanism, and explain the conditions under which it changes the recommendation. Prefer a precise supported observation to a dramatic unsupported statistic.

Use visuals where they clarify a relationship or compress evidence. Trace chart values to sources and distinguish actuals from forecasts. For a requested file, use available creation tools and inspect the result; the skill does not require another plugin.

## Use engagement experience accurately

Use only substantiated experience with permitted attribution. A named case can remain named when the user supplies the appropriate approved context. For anonymization, remove or generalize identifying details without changing material industry, scale, timing, or causal facts. If multiple cases are combined or facts materially altered, label the example as composite or hypothetical and do not present its numbers as measured results.

Distinguish drafting from publication. Respect supplied contract, client-consent, quotation, and internal review requirements at the relevant stage; preparing a reviewable draft need not wait for publication approval. Do not publish, contact clients, or claim approval without authorization. Anonymization alone does not establish that publication is permitted.

## Review and deliver

Check that the thesis follows from the evidence, examples are truthful and appropriately attributed, limitations are visible, and recommendations fit the audience's ability to act. Remove generic openings, invented opposition, causal overclaims, and repetitive conclusions. Make the piece stand alone without inflating the firm's experience.

State any material evidence or approval gap that affects intended use. For a research report, preserve methodology and uncertainty rather than turning it into promotional copy. For a short POV, retain the argument and practical implication without appending a full research process.

Referenced files: 1

View saved version →

---
name: workshop-facilitation
description: "Design and facilitate consulting workshops, strategy offsites, discovery sessions, prioritization, and design sprints. Use for agendas, participant activities, facilitation guides, pre-work, and follow-through for in-person, virtual, or hybrid groups."
license: MIT
metadata:
  category: engagement-delivery
  version: "2.2.0"
  author: Anot
---

# Workshop Facilitation

Design a session that produces the learning, alignment, decision, or work product the user needs. Start with the objective, participants, authority, time available, format, and constraints. Discovery and learning are valid outcomes even when the group is not ready to choose a strategy.

Use the known context and produce a useful agenda or guide with labeled assumptions. Ask only when an unknown materially changes the design. Do not invent participant names, tensions, pre-work completion, decisions, or agreement. Respect the requested duration, accessibility needs, and participation preferences.

## Design backward from the output

Specify what the group should produce and how it will be used. Identify the evidence, perspectives, and authority required. Separate generating ideas, evaluating them, recommending a choice, and making an authorized decision. A preference vote does not replace the decision-maker or override a hard constraint.

Select the activities needed for this outcome using [formats and facilitation](references/formats-and-facilitation.md). Adapt methods and durations; an offsite need not take a full day, and an innovation session does not require a warmup when time or context argues against it.

For each activity, give its purpose, input, method, output, timing, and facilitator response to likely failure. Keep time labels compact and put facilitation detail in notes when an executive agenda should be short.

## Make participation usable

Use silent reflection, written input, structured rounds, or anonymous ranking where hierarchy or speaking style could distort the evidence. Brief senior leaders on when their input is needed without treating their silence as a universal requirement. Let participants contribute through accessible alternatives; camera use is a preference or local policy, not a condition of meaningful participation.

For hybrid sessions, provide a shared digital or otherwise equally accessible workspace, explicit remote turns, and a way to contribute when audio or a tool fails. Do not move to an in-room-only activity while remote participants lose access. If decision-critical participants cannot participate, use an agreed delegate, mark the result provisional, or reschedule the decision.

## Check time and dependencies

Calculate the agenda from start to finish, including transitions, breaks, synthesis, and close. Choose sustained work intervals and breaks to fit the audience, activity, access needs, and available time. Do not ship a template that contradicts its stated break pattern.

If pre-work cannot happen, build the necessary context into the session and reduce the ambition accordingly. Plan what to cut if discussion runs long. Preserve the closing record and the authority needed for any decision rather than rushing untested consensus.

## Close and follow through

Record outputs, decisions, dissent or unresolved questions, decision authority, and actions with owners and timing. Distinguish workshop recommendations from approved commitments. If the task is planning, produce a plan for capturing these results; do not fabricate a post-session summary.

Deliver the agenda, facilitator guide, activity materials, or summary requested. Verify timing, input availability, participant access, and the decision mechanism. Propose follow-up proportional to the work. Sending invitations, distributing materials, recording participants, or scheduling follow-ups requires the user's authorization; drafting them does not.

Referenced files: 1

View saved version →

---
name: writing-style
description: "Write and edit consulting analysis, recommendations, reports, decks, and client communications with direct language, proportional detail, and explicit evidence. Use to adapt a consulting deliverable to its audience and remove generic or unsupported claims."
license: MIT
metadata:
  category: standards
  version: "2.2.0"
  author: Anot
---

# Writing Style

Follow the user's requested voice, audience, format, and length. These are defaults for consulting work, not a requirement to imitate a role or overwrite an approved style.

Lead with the answer or decision the reader needs. Explain the evidence, consequence, trade-off, and action in the detail needed to assess them. Spend more words where the reasoning is difficult; omit routine sections that add no decision value.

Use concrete nouns, active verbs, and natural sentence variation. Define technical terms when the audience needs it. Remove ceremonial openings, inflated adjectives, and stock phrases such as “unlock value” or “in today's rapidly evolving landscape.” Replace them with the specific outcome or mechanism. Use periods, commas, or parentheses instead of em dashes in original prose; preserve quotations and supplied style when required.

Remove invented rhetorical contrasts, empty praise, question-and-answer headings, and conclusions that repeat the opening. A sentence should add a finding, explanation, trade-off, or action. Do not pad a short request into a standard consulting framework.

Use paragraphs for connected reasoning, lists for parallel items, and tables for comparison. Numeric cells can contain a number and unit. Do not enforce a sentence count in every cell, a fixed number of arguments, or a uniform section length. A title should help navigation or state a supported takeaway according to the artifact's purpose.

State supported judgments directly. Calibrate certainty to the evidence rather than stripping all qualifications. Distinguish facts, sourced claims, forecasts, estimates, and opinion. Quantify when defensible, with units, periods, and a basis. Do not turn an unknown into a directional number just to sound specific.

Never invent experience, quotations, research, benchmarks, or sources. “Organizations that do X tend to see Y” still asserts an empirical pattern and needs support. When evidence is absent, explain the mechanism as a hypothesis, mark an example as fictional, or state the missing input. Preserve material contradictions and limitations near the claim.

Put a material caveat beside the affected claim once, with its decision consequence. Keep drafting and validation notes outside client-facing prose when the reader does not need them. Evidence discipline should make the answer usable, not turn every deliverable into an audit of its own limitations.

For a proposed action, identify who would own it and what happens next when the task calls for execution detail. Label suggested owners and dates as proposals. Finish when the requested artifact is complete; avoid adding a menu of unrelated next services.