From Prompts to Pipelines: How I Use Agentic Coding as an Engineering Workflow

从提示词到流水线：我如何将智能体编程作为工程工作流

I am interested in agentic coding for the same reason I care about good engineering process in general: I want work to move forward in a way that is inspectable, repeatable, and resilient once the task gets messy. A lot of AI-assisted coding still feels like improvisation. You ask for something, get a result, adjust the prompt, try again, and hope the useful reasoning is still somewhere in the scrollback. That can work for tiny edits. It gets much less convincing when the task starts touching architecture, tests, review, or pull requests.

我对智能体编程（Agentic Coding）感兴趣的原因，和我关注良好工程流程的原因是一样的：我希望工作能够以一种可检查、可重复且在任务变得复杂时依然稳健的方式推进。目前的许多 AI 辅助编程仍然感觉像是在即兴发挥。你提出需求，得到结果，调整提示词，再试一次，然后祈祷那些有用的推理过程还留在滚动记录里。这对于微小的修改或许可行，但当任务开始涉及架构、测试、代码审查或合并请求（PR）时，这种方式就显得非常不可靠了。

What I want instead is a workflow where the model helps me think and execute, but inside a structure I can inspect afterwards. I want artifacts, gates, and something I can resume tomorrow without reconstructing the entire mental state from memory. That is why I use po8rewq/agentic-skills. It gives me a practical way to do agentic coding as an engineering workflow rather than as a long sequence of chat turns. A task moves through requirements, architecture, implementation, checks, review, and pull request creation. Each stage leaves something I can read, verify, and challenge.

我真正想要的是一种工作流：模型辅助我思考和执行，但这一切都在一个我事后可以检查的结构中进行。我需要产出物、检查点，以及一种明天可以随时恢复工作而无需从记忆中重建整个思维状态的方法。这就是我使用 po8rewq/agentic-skills 的原因。它为我提供了一种实用的方式，将智能体编程转化为一种工程工作流，而不是一连串漫长的聊天对话。任务会经历需求、架构、实现、检查、审查和创建合并请求等阶段。每个阶段都会留下我可以阅读、验证和质疑的记录。

What makes this interesting to me? The interesting part is not just that there is a CLI. Plenty of tools have a CLI. What matters to me is that it turns AI-assisted coding into a staged system: requirements force the task to become explicit; architecture makes risks visible before code is written; implementation happens against a plan instead of against a vague prompt; checks and review happen as part of the flow, not as an afterthought; runs are resumable, so interruptions do not destroy context. That changes the feel of the work quite a bit. Instead of asking “what should I prompt next?”, I am usually asking “what stage is this task in, and what should exist before I move on?” Where this really clicked for me was when I noticed I was spending less energy trying to preserve context in my head and more energy evaluating actual outputs.

这对我来说为什么有趣？有趣之处不仅仅在于它有一个命令行工具（CLI），很多工具都有 CLI。对我而言，重要的是它将 AI 辅助编程变成了一个分阶段的系统：需求迫使任务变得明确；架构在代码编写前就让风险可见；实现过程是基于计划而非模糊的提示词；检查和审查是流程的一部分，而不是事后的补救；运行过程可恢复，因此中断不会破坏上下文。这极大地改变了工作的感觉。我不再问“接下来我该输入什么提示词？”，而是问“这个任务处于哪个阶段，在我继续之前应该准备好什么？”当我发现自己不再需要耗费精力去维持脑中的上下文，而是将更多精力用于评估实际输出时，我真正体会到了它的价值。

What the repository actually provides

该仓库实际上提供了什么

The repository itself is fairly small and opinionated in a good way:

• agentic/ contains the Python package and CLI entry points
• pipelines/ contains definitions such as default.yaml, cheap.yaml, and production.yaml
• skills/ contains the Markdown instructions used by each stage
• templates/ and scripts/ contain setup helpers

该仓库本身非常精简，且带有很好的“主见”：

• agentic/ 包含 Python 包和 CLI 入口点
• pipelines/ 包含如 default.yaml、cheap.yaml 和 production.yaml 等定义
• skills/ 包含每个阶段使用的 Markdown 指令
• templates/ 和 scripts/ 包含设置辅助工具

I like that the shared repository stays centralized while each project keeps only the parts that should be project-specific. In the target repository, I usually only need: agentic.yaml, .ai/skills/, optionally .ai/context/, and optionally .ai/memory/. That separation is one of the reasons the workflow feels sustainable. The orchestration logic lives in one place, while each repository keeps its own commands, context, and operating rules. What surprised me is how much this small separation changes the feel of the system. It stops feeling like a clever demo and starts feeling like something I can keep around.

我喜欢这种方式：共享仓库保持集中化，而每个项目只保留特定于项目的部分。在目标仓库中，我通常只需要：agentic.yaml、.ai/skills/，以及可选的 .ai/context/ 和 .ai/memory/。这种分离是该工作流感觉可持续的原因之一。编排逻辑位于一处，而每个仓库保留自己的命令、上下文和操作规则。令我惊讶的是，这种微小的分离竟如此大地改变了系统的感觉。它不再像是一个巧妙的演示，而更像是一个我可以长期使用的工具。

How the pipeline is driven

流水线是如何驱动的

The config is not just setup. It is the part that tells the pipeline how to behave: which provider to use, which commands to run, when to ask for approval, what context to load, and how the task should progress from one stage to the next. A very small agentic.yaml can already show the idea:

配置不仅仅是设置。它是告诉流水线如何运行的核心：使用哪个模型提供商、运行哪些命令、何时请求批准、加载什么上下文，以及任务应如何从一个阶段推进到下一个阶段。一个非常简单的 agentic.yaml 就能展示这一理念：

project:
  name: my-api
  default_branch: main
providers:
  default: claude-code
  available:
    claude-code: {command: claude}
  forge:
    provider: github
    create_pr: true
commands:
  install: pnpm install
  lint: pnpm lint
  typecheck: pnpm typecheck
  test: pnpm test
  build: pnpm build

That is obviously not a full production config, but it already makes the model operate inside a real engineering boundary. It knows which provider to call, which repo commands count as checks, what the main branch is, and whether it should prepare a PR at the end. From there I usually add the pieces that make the workflow more serious: model aliases by stage, gating and risk-routing rules, context and memory paths, and project-specific command overrides. Once that file exists, I stop thinking in terms of isolated prompts and start thinking in terms of pipeline behavior. The part I did not expect is that a boring config file would do so much work. It quietly turns “use an AI assistant here” into an operating model with boundaries.

这显然不是一个完整的生产环境配置，但它已经让模型在真实的工程边界内运行。它知道调用哪个提供商、哪些仓库命令算作检查、主分支是什么，以及最后是否应该准备一个合并请求。在此基础上，我通常会添加一些让工作流更严谨的配置：按阶段划分的模型别名、门控和风险路由规则、上下文和内存路径，以及项目特定的命令覆盖。一旦这个文件存在，我就不再从孤立的提示词角度思考，而是开始从流水线行为的角度思考。我没预料到的是，一个枯燥的配置文件竟然能发挥如此大的作用。它悄无声息地将“在这里使用 AI 助手”变成了一种有边界的运营模式。

How I set it up

我是如何设置的

The setup is intentionally boring, which is part of the appeal. I install the shared package from po8rewq/agentic-skills:

设置过程刻意保持简单，这也是其吸引力的一部分。我从 po8rewq/agentic-skills 安装共享包：

cd /path/to/agentic-skills
python3 -m venv .venv
source .venv/bin/activate
python3 -m pip install --upgrade pip setuptools
python3 -m pip install -e .

That gives me three commands: run-pipeline, validate-agentic-config, and install-agentic-skills. In the target project, I copy the example config: cp /path/to/agentic-skills/agentic.example.yaml /path/to/project/agentic.yaml. Then I install the shared skills: install-agentic-skills --source /path/to/agentic-skills/skills .ai/skills. For starter repo context and memory files: install-agentic-skills --with-context --with-memory .ai/skills. At that point, the workflow is ready to try on a real task.

这为我提供了三个命令：run-pipeline、validate-agentic-config 和 install-agentic-skills。在目标项目中，我复制示例配置：cp /path/to/agentic-skills/agentic.example.yaml /path/to/project/agentic.yaml。然后安装共享技能：install-agentic-skills --source /path/to/agentic-skills/skills .ai/skills。对于初始仓库的上下文和内存文件：install-agentic-skills --with-context --with-memory .ai/skills。至此，工作流就可以在实际任务中使用了。

What it looks like on a small task

在小任务上的表现

The easiest way to understand the workflow is to run a tiny change through it. Take a small but real task like: “Add audit logging to endpoint X.” Before I worked this way, that kind of task usually turned into a loose sequence of prompts and manual checks. I would explain the endpoint, ask for a plan, ask for an implementation, remember to think about logging format, wonder whether I had missed a migration or config update, run tests manually, and then do a separate cleanup pass before opening a PR. With the pipeline, the same task becomes much more structured:

理解该工作流最简单的方法是运行一个小改动。以一个虽小但真实的任务为例：“为端点 X 添加审计日志”。在我采用这种方式之前，这类任务通常会变成一连串松散的提示词和手动检查。我会解释端点，要求一个计划，要求一个实现，记得考虑日志格式，担心是否遗漏了迁移或配置更新，手动运行测试，然后在打开合并请求之前进行单独的清理工作。有了流水线，同样的任务变得结构化多了：

• Before: I describe the task in chat and keep refining the prompt.

• With the pipeline: I start with a task and let the pipeline create explicit requirements. Architecture concerns stay in my head unless I stop and write them down. Architecture is a stage, so affected modules, risks, and planned files get written down early. Implementation can drift because the prompt…

• 之前： 我在聊天中描述任务并不断优化提示词。

• 使用流水线： 我从一个任务开始，让流水线创建明确的需求。架构问题不再仅仅停留在我的脑海中，因为架构是一个独立的阶段，受影响的模块、风险和计划文件都会被提前记录下来。实现过程不会偏离轨道，因为提示词……