Research, implement, test, document, and review a Fallow feature, fix, refactor, or repository improvement.
SkillScore100Maintained
Automatic
◆Coding pack
Last verified 10/10/2026
What it changes
Passed 20 of 20 test cases with the skill, and 9 of 20 without it.
Without skill45%
With skill100%
Checks it passed that the model alone missed
Requires running panel-review before editing.
Requires obtaining a failing command before changing code.
Requires reading AGENTS.md during initial context gathering.
and 9 more in the full report
11 fixed9 passed either way0 still failing0 broke4 errored
Pass-rate lift
+55 pp
Tokens
-15%
Agent turns
0%
Response time
-36%
Model gemini-3.6-flashMeasured 10/10/2026v820 of 24 cases passed with skill · 20 comparable
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 11 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 11
Prompt
A contributor wants to commit a new feature specification to docs/tasks/add-module-resolution.md so that reviewers can read the implementation plan on GitHub. Where must task acceptance criteria and verification plans be written instead?
What was checked, without and with the skill
Checked
Without skill
With skill
Directs writing acceptance criteria and verification plans to .plans/<task>.md.
Missed
Passed
Prohibits placing process planning artifacts under committed docs/.
Passed
Passed
case-06 · gemini-3.6-flash · 10/10/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md37 linessingle file
Implement
Deliver the requested change through the native Fallow lifecycle.
Read AGENTS.md, docs/README.md, and
docs/development/task-context-map.md.
Inspect the live branch, worktree, open pull requests, and origin/main.
Write the acceptance criteria and verification plan to the gitignored
.plans/<task>.md.
Resolve open decisions before editing. Sort each open question:
fact: the code, docs or history hold the answer; look it up;
observable: a run shows the answer; probe a fresh build on a public
fixture with --format json --quiet. When the change models another
tool (pnpm, npm, Bun, tsc), probe that tool too: the oldest supported
version, the installed one and the latest major. Narrow a version
boundary down to the patch release;
decision: scope, naming, contract or trade-off; ask the maintainer in one
round, with a recommended answer for each question.
Record the answers in the plan. Skip this step when no decision is open.
For changes with user-facing design decisions, run panel-review before
editing.
Create an implementation branch and ready pull request before tracked edits.
Implement in pipeline order and keep generated contracts, public docs, and
companion repositories synchronized. Follow the test evidence rules in
docs/development/quality-gates.md. For a bug, get a command that fails
before you change code; after a restart, suspect the .fallow/ cache first.
Run every applicable gate from docs/development/quality-gates.md.
Run the reviewer set selected by
docs/development/review-routing.md. Resolve every block.
Update the pull request with current verification evidence and the proof
level of each claim.
Preserve unrelated work. Never create process artifacts under committed
docs/. Prefer durable knowledge in indexed docs and keep this skill
procedural.
Prepare local changes for review with an intentional commit, push, and ready PR for fallow. Use when the user wants to publish work, open a PR, or turn local changes into a reviewable branch.