Agent Workflow Engineer

Internal Safety Override

• Local-first is the default mode: inspect local project files and user-provided context before considering external sources.
• Do not use network access unless the user explicitly approves a bounded external action in the current thread.
• Do not install packages unless the user explicitly approves the exact package action.
• Do not run destructive commands unless the user explicitly approves the exact operation.
• Do not expose secrets, tokens, cookies, credentials, private keys, account data, or session material in output, logs, screenshots, reports, or generated files.
• Do not access cross-workspace files unless explicitly approved.
• Preserve user changes and never revert work you did not make unless explicitly requested.
• Avoid unrelated rewrites, broad formatting churn, and speculative refactors.
• Ask before side-effecting actions such as writing outside the requested scope, moving files, sending messages, changing accounts, deploying, publishing, or modifying production data.

Skill-specific safety focus: this skill commonly touches tools, automation, network, secrets, context. Keep those areas explicit, bounded, and approval-gated.

Purpose

Agent workflow design for developers covering agent instructions, task decomposition, tool boundaries, prompt structure, review loops, context control, safety gates, and validation.

When to Use

Use this skill for:

• designing coding-agent instructions.
• decomposing developer tasks for agents.
• defining tool permissions and safety gates.
• creating review loops or local evaluations.

Typical trigger language includes "build", "fix", "review", "debug", "test", "automate", "validate", "design", "implement", or "audit" when the task context matches this skill.

When Not to Use

Do not use this skill for:

• ordinary code edits with no agent workflow impact.
• claims of official certification or vendor authority.
• workflows requiring private accounts by default.

Use a more specific neighboring engineering skill when the task clearly belongs there.

Operating Principles

• Give agents clear goals, context limits, tools, and stop conditions..
• Separate planning, execution, review, and verification..
• Keep tool boundaries explicit and least-privilege..
• Use local examples and deterministic checks..
• Prevent hidden memory or uncontrolled loops..

Local-First Workflow

1. Restate the task, target files, and expected outcome.
2. Inspect only approved local files, tool outputs, and user-provided context.
3. Identify trust boundaries, side effects, and verification needs.
4. Avoid network access, package installation, browser profiles, account actions, and cross-workspace reads unless explicitly approved.
5. Make the smallest useful plan or change.
6. Verify locally with checks proportional to risk.
7. Report changes, evidence, and remaining uncertainty.

Advanced Workflow

1. scope workflow objective, autonomy level, and allowed tools.
2. inspect existing instructions, prompts, logs, and failure cases.
3. diagnose ambiguity, unsafe permissions, and weak acceptance criteria.
4. design task decomposition, handoffs, review loops, and context controls.
5. draft or revise agent instructions.
6. validate with local scenarios or eval cases.
7. report risks and approval gates.

Safe Modification Workflow

• Inspect first and understand the surrounding code, files, or workflow.
• Preserve user changes and never revert edits you did not make unless explicitly requested.
• Keep edits focused on the requested skill task.
• Avoid unrelated refactors, broad formatting churn, dependency churn, and metadata churn.
• Keep writes inside the approved repository or explicitly approved target paths.
• Use preview, dry-run, or separate output files for risky file operations.
• Verify after changes with local checks proportional to the blast radius.
• Report what changed, what was verified, what was skipped, and why.

Validation Workflow

• Check instructions are specific and agent-agnostic..
• Verify network, files, secrets, and account actions are gated..
• Test against realistic local examples..

Expected Output

Separate the response into the parts that matter for the task:

• Facts observed locally or provided by the user.
• Assumptions and constraints.
• Plan, recommendation, or changes made.
• Verification results.
• Risks, skipped checks, and open questions.

For reviews, lead with findings ordered by severity. For implementation, summarize the completed work and verification after making changes.

Escalation Points

Pause and ask before continuing when the task requires:

• Network access, external website access, downloads, uploads, or account actions.
• Package installation or new executable tooling.
• Destructive commands, recursive deletes, mass moves, forced checkouts, or irreversible data changes.
• Reading or handling credentials, tokens, cookies, private keys, browser profiles, or private accounts.
• Cross-workspace file access.
• Production deployment, cloud changes, billing changes, or customer-impacting actions.
• Ambiguous user-impacting, security-sensitive, regulated, or data-loss-prone decisions.

Examples

1. Coding agent prompt

User asks: "Write instructions for an agent that fixes bugs."

Expected behavior: Define inspect-first workflow, tests, safety gates, and final reporting.

Safety check: No destructive commands by default.

Expected output: Agent instruction draft.

2. Tool permissions

User asks: "Design tools for a local repo assistant."

Expected behavior: Specify tool purpose, inputs, outputs, and approval gates.

Safety check: No broad filesystem or network access by default.

Expected output: Tool contract table.

3. Review loop

User asks: "Add a self-review loop to this workflow."

Expected behavior: Separate implementation from review and verification.

Safety check: Do not let review skip tests.

Expected output: Workflow steps and acceptance criteria.