From upfront
Fix a bug or implement a small feature from a GitHub issue or clear problem statement — more structure than /upfront:quick, less ceremony than /upfront:feature
How this skill is triggered — by the user, by Claude, or both
Slash command
/upfront:patchThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
You are implementing a fix or small feature where the problem is already understood. This is for GitHub issues, bug reports, and well-scoped tasks that don't need ideation or a full feature spec — but are too big or too risky for `/upfront:quick`.
You are implementing a fix or small feature where the problem is already understood. This is for GitHub issues, bug reports, and well-scoped tasks that don't need ideation or a full feature spec — but are too big or too risky for /upfront:quick.
Input: $ARGUMENTS
The input is one of:
#42, owner/repo#42, https://github.com/...)If the input contains --auto (e.g., /patch --auto #42), run without pausing for confirmation:
Auto mode is for well-understood issues where you trust the pipeline. Remove --auto from the input before processing the rest as the issue reference.
This command handles changes up to ~300 lines of non-test code. But size isn't the only dimension — also evaluate:
If it's clearly bigger than 300 lines OR scores high on 2+ reviewability dimensions:
"This looks like it needs
/upfront:feature+/upfront:plan+/upfront:build. Here's why: [reason]. The change touches [N concerns] and affects [blast radius] — a reviewer can't verify this in one pass."
If the scope suggests multiple features worth of work:
"This isn't a patch — it's a chunk of a bigger initiative. Consider
/upfront:visionto map out what you're really doing, or at minimum/upfront:featurefor the first piece."
If it's clearly under ~50 lines and straightforward:
"This is small enough for
/upfront:quick. Want me to run that instead?"
If given a GitHub issue: Read it with gh issue view. Extract:
If given a description: Work with what you have.
Then read context files if they exist:
specs/ARCHITECTURE.md (its invariants section contains hard constraints — if the fix would violate one, stop and say so)specs/DECISIONS.mdspecs/LEARNINGS.mdRead the code that's relevant to the problem. Understand:
Present a brief diagnosis:
Problem: [what's wrong or missing]
Root cause: [why it happens — for bugs]
Fix approach: [what you plan to change]
Files: [list of files you'll touch]
Risk: [what could go wrong, or "low — isolated change"]
Wait for the user to confirm the approach. If the investigation reveals the problem is different from what the issue describes, say so.
For each unit of change:
For changes that aren't unit-testable (config, docs, build scripts), state why and verify through other means.
If the change grows beyond ~300 lines during implementation, stop:
"This grew to ~[N] lines. Want me to continue as-is, or should we switch to
/upfront:feature+/upfront:plan+/upfront:buildfor proper phasing?"
Review your own diff. Check:
specs/DECISIONS.md or specs/ARCHITECTURE.md?specs/DECISIONS.md.If you find issues, fix them and re-run tests.
If investigation reveals the root cause is unclear and requires hypothesis testing, suggest /upfront:debug instead.
Run every linter, formatter, type checker, and test suite configured for the project. Not just the tests you wrote — everything. Fix anything that fails.
Commit with a message that references the issue (if there was one):
fix: [description of what changed]
Fixes #[issue number]
Use conventional prefixes:
fix: for bug fixesfeat: for small featuresrefactor: for structural changes with no behavioral changePatch applied:
- [what changed, in brief]
- [files modified]
- Tests: [what's covered]
- Checks: [what passed]
If the input was a GitHub issue, ask: "Want me to close the issue with a comment summarizing the fix?"
npx claudepluginhub thinkupfront/upfront --plugin upfrontCreates minimal patch plans for targeted code fixes from reviews or bugs, analyzing with git/grep and templating precise changes with validation steps.
Fixes GitHub issues end-to-end with GitHub CLI: views issue, researches context, plans fix, creates branch, implements/tests changes, submits PR.