From request thread to documented delivery.
Krahnie’s job is to keep work moving through a clear, observable, repeatable sequence — regardless of whether the implementer is an AI agent, Salesforce developer, admin, architect, or mixed pair.
A Slack request thread, form, email, or client message is captured. Krahnie extracts client, org, urgency, artifacts, acceptance criteria, and unknowns.
A delivery card is created or linked. Slack user identity maps to GitHub/Jira/Linear/Asana identity, so ownership and audit trails stay clean.
Krahnie proposes complexity, effort, due date, assignee, reviewer, and dependencies. Humans can approve or edit in the thread.
The request is routed to the right client context, repository, Salesforce org, sandbox, metadata package, runbook, and knowledge base.
Krahnie identifies impacted metadata, likely files, tests, data requirements, feature flags, and documentation touchpoints before anyone starts changing code.
Each request gets an isolated workspace. Branch names are generated from card IDs. Admins do not need to know the Git mechanics; developers can inspect everything.
Krahnie can implement low-risk changes, scaffold work, write tests, or pair with a human. All work stays tied to the card and branch.
Commits reference the card. PR templates include intent, changed metadata, test plan, deployment plan, screenshots, risks, rollback notes, and documentation updates.
Reviewers get a concise summary and diff highlights. Approved changes merge to a connected partial branch, not directly to production.
CI detects changed Salesforce metadata and deploys only the relevant delta to the connected partial sandbox. Deployment logs return to the request thread.
Krahnie guides validation: automated tests, smoke checks, admin QA steps, user acceptance notes, screenshots, and known limitations.
Functional docs explain what changed and how users should operate it. Technical docs explain metadata, integration impact, dependencies, and rollback path.
After delivery, Krahnie captures what surprised the team, what should be automated, client-specific quirks, reusable prompts, and runbook updates.
Role matrix
| Role | What they do | How Krahnie helps |
|---|---|---|
| Client stakeholder | Requests change, validates business outcome. | Receives crisp status, acceptance criteria, and UAT prompts without seeing delivery complexity. |
| Salesforce admin | Configures declarative changes, validates org behavior, documents functional impact. | Uses guided Slack actions instead of memorizing Git, branches, PRs, and CI commands. |
| Developer | Implements code/metadata, tests, reviews, handles complex diffs. | Gets prebuilt worktree, context pack, impacted files, PR scaffold, and deployment feedback. |
| Architect / lead | Approves patterns, reviews risk, protects standards. | Sees triage summaries, guardrail exceptions, cross-client patterns, and documentation gaps. |
| Krahnie/Hermes | Orchestrates the process and performs safe automated work. | Keeps every step linked, observable, auditable, and documented. |
Request thread/card pattern
Every request gets a canonical thread and a canonical card. The thread is the live cockpit; the card is the system of record. Krahnie mirrors important state both ways: owner, due date, branch, PR, deploy status, validation evidence, doc links, and final outcome.