القائمة
Ship working, build changeable. When implementing decisions made under ambiguity, build seams so the decision can be changed without rewriting.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Complete reference for the factory CLI — all commands, arguments, options, and usage. Use when an agent needs to invoke factory commands, check correct syntax, or understand available options.
When and how to write a human-action-needed entry to memory/{agent}/needs.md. Agents write these entries when they hit blockers that only a human can resolve.
When you encounter a failure, correction, or new pattern, write a learning and optionally propose a skill.
How the factory workspace is organized and what each directory means.
What to examine during a reflection pass and how to write observations to memory/{agent}/needs.md.
When and how to write scenario holdouts for factory verification.
| name | refactorability-first |
| description | Ship working, build changeable. When implementing decisions made under ambiguity, build seams so the decision can be changed without rewriting. |
Intent is king. A working demo that meets intent trumps a perfect architecture that doesn't exist. But:
When a spec contains decisions made under ambiguity (auto-resolved soft gates, or operator decisions that might change), apply these patterns at the decision boundary:
Interface boundaries. Where the ambiguous decision lives, build a seam. The rest of the code talks to the interface, not the implementation.
Parameterized choices. Hardcoded choices are sins. Parameterized choices are features. A config flag, an enum, an argument — anything that makes swapping the choice a one-line change.
Test behavior, not implementation. Tests are the contract that survives refactoring. Assert "output is correct" not "streaming parser was called." Tests should pass regardless of which option was chosen.
Own your dependencies. Wrap external APIs so you can swap providers. The factory's own multi-backend abstraction is a living example of this pattern.
No global state at decision boundaries. Makes testing hard, makes refactoring impossible. Pass the choice in, don't reach out for it.
When Builder implements work that includes auto-resolved decisions, write builder-notes.md alongside the task in tasks/review/. This file documents:
The Verifier reads builder-notes to verify that seams exist and decisions are properly parameterized. The operator reads builder-notes to review auto-resolved decisions asynchronously.
You have permission to decide under ambiguity. The decision-heuristic skill tells you when and how. This skill tells you how to build the result so that changing your mind is cheap.
The contract: if the cost-to-change is documented as LOW and the seam exists, the decision was responsibly made. If the operator overrides, the rebuild is bounded.
