Coding Playbooks

Alfrada OS can work with your code two ways: upload files straight into the chat with the + button, or connect My GitHub to read and manage real repositories. Every playbook below works with either; the "Best setup" line names the strongest fit.

Bug Triage

• Good for: ambiguous failures and regression hunting
• Best setup: give Alfrada OS the code — upload the relevant repo files or connect My GitHub — and ask for a verification plan
• Example prompt:

Bug triage

Investigate this bug: [symptom]. First identify likely root causes from the codebase, then propose the smallest safe fix. Call out any risky assumptions and what should be tested after the change.

Feature Spec To Implementation Plan

• Good for: turning product ideas into engineering work
• Best setup: the existing repo (via My GitHub) plus your explicit constraints
• Example prompt:

Feature plan

Take this feature request: [request]. Inspect the current codebase and produce an implementation plan that names the affected areas, the lowest-risk approach, and the edge cases I should care about before building.

Repo Explainer

• Good for: onboarding or understanding an unfamiliar codebase
• Best setup: connect My GitHub so Alfrada OS can search the code
• Example prompt:

Repo explainer

Explain how [system or feature] works in this repository. Focus on the request flow, the main files, the user-facing behavior, and the parts I should change if I want to extend it.

Test Plan Builder

• Good for: reducing regressions before shipping
• Best setup: the changed files (upload them, or point at the pull request on My GitHub) plus the existing tests
• Example prompt:

Test plan

Given these proposed code changes, create a focused test plan. Separate the highest-risk regressions from lower-priority checks and suggest only the tests that materially improve confidence.

Daytona Server Operations & DevOps

• Good for: pulling data or running operations on your own servers
• Best setup: save the server once in the Vault (Settings → Account → Vault, or let the in-chat popup capture it), then reference it by label
• How it behaves: Code Execution selects its server target and runs from a dedicated ephemeral Daytona sandbox. Vault secrets enter only the fixed runner process. Read-only commands run immediately; writes, restarts, installs, and deletes pause under SSH command execution.
• Direct and private servers: public hosts connect directly. Private-network targets can use optional bastion/jump-host fields in the same Vault credential.
• Agent guidance: the built-in runtime playbook is daytona_server_operations; Alfrada OS reads it before starting server/devops work.

Recipe

1. If no server is stored, let Alfrada OS open the secure server_access Vault popup. Never paste the key into chat.
2. For inspection, Alfrada OS calls Code Execution with the server target, server label, and one bounded read command.
3. For a write/deploy, Alfrada OS explains the intended change; the Safety Center approval appears before execution.
4. For long/background work, set Daytona's idle window to comfortably exceed the first follow-up (5 minutes–24 hours), launch the remote job with durable logs/status, then call wake_me.
5. On wake, reconnect through the same Vault label and inspect status/logs. If unchanged, back off the next wake. Stop waking when the job succeeds, fails, or needs the user.

• Example prompt:

Server health check

On my prod server, check disk usage, memory, and the status of nginx and the app service, then show me the last 50 lines of the app error log. Don't change anything.

Guarded deploy

Deploy the latest main branch on prod-exoscale. Show me the plan before anything changes, run it through isolated Daytona, keep the sandbox available for 45 minutes, then wake in 10 minutes and check the rollout logs and service health.

My GitHub

• Good for: PR reviews, CI triage, and release digests on your real repositories
• Best setup: connect under Settings → Tools & Data → Data Sources → My GitHub (you can link up to 3 accounts), then just name the repo in your prompt
• How it behaves: Alfrada OS reads repos, issues, PRs, commits, releases, and Actions runs on its own; anything irreversible — merging, publishing a release, committing files — is confirmed with you first
• Example prompts:

PR review

Review PR #[number] in [repo]: summarize the diff, flag the risky files, and leave a review with comments on anything that needs a second look.

CI triage

Why did the last workflow run fail on main in [repo]? Show me the failing job, then rerun just the failed jobs.

Release digest

What changed in [repo] since tag [v1.2]? Group the commits by area and call out anything that looks breaking.

Look Up Real Docs (Context7 Docs)

• Good for: writing against a library without hallucinated or outdated APIs — models remember old versions; Context7 Docs fetches what the library says today
• Best setup: nothing to connect — just tell Alfrada OS to check the current docs before it writes code
• Example prompt:

Docs-first integration

Before writing the integration, pull the current docs for [library] and use the exact current API — don't rely on what you remember about older versions.

Deep Technical Diligence With Smith

• Good for: due diligence that would eat your whole chat — dependency audits, "should we adopt X" research, security and maintenance health checks
• Best setup: Agent mode; say how deep to go — Morpheus (quick lookup), Trinity (solid research), or Neo (exhaustive deep dive)
• How it behaves: Smith forges independent worker agents that run in parallel while your conversation stays free — one task, one worker; multiple tasks, multiple workers. If a Trinity-level dive hits its ceiling with real progress made, it escalates itself to Neo and keeps going.
• Example prompt:

Dependency deep dive

Send Smith on a Neo-level deep dive into [library or dependency]: maintenance health, open security issues, breaking changes across recent major versions, and credible alternatives. Come back with an upgrade-or-replace recommendation and the evidence behind it.

Which Model And Effort To Pick

For most coding work, leave the model on Auto — Alfrada OS routes each turn to a model that fits it. When the work is genuinely hard agentic coding (a large refactor, a multi-file feature, a long debugging session), pin Claude Sonnet 5 - Reasoning: near-Opus coding and agents, with a 1M-token context window that comfortably holds a large codebase. More on picking models in Models And Modes.

Effort is the separate dial for how hard Alfrada OS checks its own work, in the chat input → model selector → Effort row (Auto / Fast / Medium / Beast):

Effort	What it does	Use it for
Auto	Alfrada OS picks the effort (and, on the Auto model, the model) per turn	The default — most sessions
Fast	No self-review — fastest	Quick questions, "what does this function do"
Medium	One self-review-and-revise pass	Everyday changes you'll still glance over
Beast	Reviews and revises until it passes (capped)	Gnarly refactors and code that must be right the first time

Under the hood — tool names

• My GitHub tools share the gh_ prefix (42 tools across repos, issues, PRs, commits, releases, and Actions workflows) — the full operation list is on the tools reference.
• Context7 Docs = context7_docs.
• Smith = agent_smith, with effort values morpheus / trinity / neo.