AGENTS.md

SLKone marketing and positioning guidance

Use this section whenever editing public site copy, IA, page hierarchy, visuals, CTAs, case-study presentation, service pages, or positioning documents.

Core positioning

SLKone is a delivery firm, not an AI company, not a software company, and not a deck factory. The site should make clear that SLKone embeds with leadership and operators to move important work from unclear priority to measurable operating result. AI, analytics, automation, MCP tooling, skills, agents, dashboards, models, and governance are capabilities used to compress and improve the work; they are not the firm’s identity.

Be critical. Most consulting websites sound interchangeable because they overuse broad claims and under-show the work. SLKone’s site should not claim it is different; it should make the difference obvious through specificity, evidence, and sharper choices about what not to say.

The internal pitch to preserve in spirit:

We’re not an AI company. We’re a delivery firm that uses AI better than anyone else. Our clients don’t pay for decks. They pay because things actually change.

Do not copy that line everywhere. Translate it into the page’s context.

Critical marketing pillars

• Execution over recommendations: SLKone does the work clients need done but often lack the time, tools, capacity, or cross-functional muscle to carry through.
• Decision to done: SLKone helps leaders frame the decision, align operators, build the tools and routines, execute the change, and prove the result.
• Embedded delivery: SLKone works beside the people who will own the process after the engagement, not above them as detached advisors.
• Builder capability: SLKone builds practical assets: models, dashboards, workflows, automations, MCP tools, AI-enabled workflows, governance routines, reporting systems, and operating cadences.
• Proof orientation: Claims should be supported with case studies, before/after operating states, metrics, artifacts, or concrete examples of what changed.
• AI-enabled where useful: AI should appear as a practical accelerator for knowledge work, analysis, governance, automation, and workflow execution. It should not overwhelm the business-first story.
• Business-first technology: Technology and AI language must connect to revenue, cost, cash, cycle time, quality, risk, adoption, decision speed, or management control.

If a page does not clearly connect to at least one of these pillars, it is probably generic filler.

Deficiencies the site must overcome

• Generic consulting language: Avoid vague phrases like “tailored solutions,” “complex challenges,” “data-driven insights,” “transformative change,” and “strategic partner” unless they are immediately grounded in specific work.
• Passive proof: Case studies cannot sit as disconnected articles. Surface what changed, what SLKone built, the operating constraint, the team involved, and the measurable result.
• AI confusion: Do not make SLKone look like it is pivoting into an AI product company. AI is part of how SLKone delivers, not the offer by itself.
• Bridge confusion: Bridge is owned proof of capability, not the public offer and not a top-level product unless leadership explicitly makes that decision.
• BVA overreach: Business Value Assessment / Value Assessment is a lead-gen and sales conversion asset. It should support the broader firm positioning, not become the whole site strategy.
• Overbroad rewrites: Do not spread uncertain positioning across dozens of pages. Start with homepage, services landing, AI Enablement, Data & Advanced Analytics, Private Equity, BVA, and proof modules.
• Weak CTAs: “Contact Us” is acceptable in utility navigation, but primary CTAs should reinforce the work: discuss a priority, make a decision executable, assess value, see proof, or talk through a stuck operating issue.
• Design without evidence: Visual polish should help buyers understand what SLKone does. Avoid decorative sections that do not clarify work, proof, audience, or conversion.
• Abstract differentiation: “We are hands-on” is not enough. Every serious consulting firm claims this. Show what hands-on means: who SLKone sits with, what artifacts it builds, what operating routines it changes, and what proof remains after the engagement.
• Capability sprawl: The firm does many things, but the site should not read like a menu of unrelated services. Tie services back to the common operating promise: decisions made executable.
• Over-polished vagueness: Elegant language that hides the work is worse than plain language. Prefer a concrete sentence over a beautiful but generic one.
• AI theater: Do not mention agents, MCP, governance, or automation because they sound modern. Mention them only when the workflow, business use, and value are clear.
• Unsupported bravado: Avoid superlatives like “better than anyone else” in public copy unless paired with proof. The internal pitch can be provocative; public copy needs evidence.

Strengths to reinforce

• Hands-on implementation: SLKone does not stop at recommendations. Make implementation, adoption, and measurable operating change explicit.
• Cross-functional translation: SLKone connects strategy, finance, operations, technology, and change management.
• Operator empathy: Copy should recognize constrained internal teams, competing priorities, messy systems, limited capacity, and the need for practical next steps.
• Private equity and executive relevance: Speak to sponsors, CEOs, CFOs, operators, and functional leaders who need credible progress fast.
• Analytics and automation heritage: Existing case studies include strong evidence around forecasting, ARR automation, FP&A systems, dashboards, process mining, operating cadence, and transaction support. Use that evidence.
• Governed adoption: Reinforce controls, ownership, training, decision forums, reporting cadence, and sustainability after SLKone leaves.
• Owned proof: Bridge and internal AI-enabled delivery workflows prove SLKone can build and operate the type of modern work infrastructure it recommends.

Critical differentiators

• SLKone embeds where decisions become work. This is stronger than “we advise leaders.”
• SLKone builds usable operating assets. Models, dashboards, automations, agents, workflows, governance, and cadences are concrete differentiators.
• SLKone combines advisory judgment with builder execution. The firm can help decide what matters and then build the machinery to act on it.
• SLKone uses AI in the workflow, not as theater. AI should be tied to governed workflows, reusable knowledge, automation, analysis, and better management control.
• SLKone is proof-backed. Case studies and owned tools should carry more weight than broad claims.
• SLKone can work inside ambiguity. The site should show that SLKone helps define the real decision when clients do not yet have a clean problem statement.

Critical standards for future edits

Before accepting any copy, layout, or IA change, test it against these questions:

• Could a competitor say this unchanged? If yes, rewrite it with SLKone-specific work, proof, or operating detail.
• Does this say what SLKone actually does? If it only says what SLKone believes, values, or enables, it is incomplete.
• Does this make AI the subject when the business problem should be the subject? If yes, invert the sentence.
• Does this imply speed is inherently good? If yes, reframe around better decisions, less wasted effort, control, adoption, or measurable progress.
• Does this create a new offer accidentally? Avoid making BVA, Bridge, AI Enablement, or any internal capability look like the whole company.
• Does this add a card because cards are easy? If yes, consider whether a table, proof band, process strip, pull quote, or compact evidence module would communicate better.
• Does this hide the buyer’s tension? Strong copy should acknowledge capacity constraints, unclear ownership, messy data, stalled decisions, system friction, adoption risk, or pressure to show value.
• Does this show the artifact? Where possible, name the thing built: model, dashboard, governance routine, workflow, agent, report, value tracker, decision forum, integration plan.

Copy rules

• Lead with the business problem and work to be done before naming AI or tools.
• Use concrete nouns: decision, model, dashboard, workflow, cadence, governance, owner, metric, value pool, constraint, adoption, proof.
• Prefer “make the decision executable” / “move priority work from decision to done” / “turn priority work into operating reality” over generic transformation language.
• Avoid implying speed is always good. The value is clearer decisions, sharper execution, measurable progress, better control, and less wasted effort.
• When mentioning AI, pair it with the mechanism and outcome: “AI-enabled workflow to reduce manual analysis,” “MCP tooling for governed knowledge retrieval,” “agents for repeatable operating tasks.”
• Do not make Bridge prominent without context. If referenced publicly, frame it as “built by SLKone, used by SLKone” proof of delivery capability.
• Keep BVA language consultative and focused. “Value Assessment” works as a nav label; “Business Value Assessment” can remain the formal page title or body term.
• Cut words before adding words. If copy feels heavy, make the claim smaller and more concrete.
• Avoid category jargon unless a buyer would use it in the same way. “AI readiness,” “digital transformation,” and “value creation” need immediate operational grounding.
• Replace vague verbs like “enable,” “empower,” “leverage,” “optimize,” and “transform” with clearer verbs like build, size, decide, sequence, automate, govern, measure, train, implement, or run.
• Do not write as if SLKone only enters after the client has already made the decision. SLKone also helps make decisions when the facts, options, tradeoffs, or ownership are unclear.

Design and page-structure rules

• The homepage should introduce who SLKone is, how it works, why it is different, and why buyers should trust it.
• First-scroll content should quickly answer: what work does SLKone actually do?
• Proof modules should be more evidence-like than blog-like: show duration, team size, services, result, and operating context where available.
• Service and industry pages should include AI/analytics/automation only where relevant to the actual work, not as a shared generic badge.
• Avoid making every section a rounded card. Use restrained bands, clear hierarchy, and fewer stronger modules.
• Visual assets should support the operating/workflow/proof story. Do not let abstract imagery compete with the windmap identity unless the style is intentionally unified.
• Keep primary CTAs clear and action-oriented. Secondary CTAs can point to proof, services, BVA, or How We Work.
• Do not let the windmap become visual noise. It should create identity and motion, not reduce readability or distort spacing.
• Avoid hero padding or centering changes that break alignment between headline, copy, and CTA. The hero should feel deliberate, not like content floating in a large graphic field.
• If adding a section, define its job. Good section jobs include: clarify the work, route an audience, prove a claim, explain the delivery model, or convert a qualified lead.
• Do not add decorative complexity to compensate for weak content. Fix the content first.

Cursor Cloud specific instructions

This is a Jekyll 3.10 + Tailwind CSS 3 static website for SLKone (a consulting firm). No database or external services are required for local development.

Prerequisites (system-level, installed once)

• Ruby 3.2+ with Bundler (sudo apt-get install -y ruby-full build-essential zlib1g-dev && sudo gem install bundler)
• Node.js 18+ (pre-installed in cloud VMs)

Running the dev server

1. npm run build:css:prod — builds Tailwind CSS to assets/css/main.css (must run before Jekyll serve, or use npm run build:css for watch mode)
2. bundle exec jekyll serve --host 0.0.0.0 --port 4000 — starts dev server at http://localhost:4000

Building for production

• bundle exec jekyll build — outputs to _site/

Key gotchas

• vendor must be in _config.yml exclude list. When gems are installed via bundle install with a local path (vendor/bundle), Jekyll will try to process files inside vendor and fail. The _config.yml includes vendor in its exclude list to prevent this.
• No dedicated lint/test commands exist in this project. There are no test suites, linters, or CI checks configured. Validation is done by successfully building the site (bundle exec jekyll build).
• postcss.config.js references _includes/tailwind.config.js but the actual Tailwind config is at the project root (tailwind.config.js). The PostCSS config is used by the jekyll-postcss plugin; the npm run build:css script uses Tailwind CLI directly which picks up the root config. For development, use the npm scripts to build CSS rather than relying on jekyll-postcss.
• No .nvmrc/.ruby-version/.tool-versions files exist. Ruby 3.2.x and Node 18+ are known to work.