AI can write the code. You're still responsible for what ships.
These are the skills I use to turn a rough idea into reviewed, understandable software. Usually I want to think through the decisions myself, with an agent that helps me see the options. Sometimes I deliberately hand over more of the work. Both are valid choices. The delegation should be yours.
- Install
- Choose how you work
- Driver mode: stay involved
- Make It Happen: deliberately delegate
- Common uses
- The workflow
- The skills
- Editing this collection
- Author & inspiration
Install all six skills for Claude Code and Codex, available across projects:
npx skills add GigiLoria5/agent-skills -g -a claude-code -a codex --skill '*'Replace '*' with a skill name such as write-pr to install just that skill.
Omit -g for a project-local installation. Install the full collection when
using make-it-happen, so its companion skills are available.
Examples use Claude's /skill-name notation. Select the skill from your agent's
menu, then add your request. See the
Skills CLI reference
for other agents and options.
| Driver mode | make-it-happen |
|
|---|---|---|
| You bring | A draft, a problem, or a task to work through | A goal and a place to build it |
| Decisions | You own consequential choices; the agent researches and recommends | You explicitly delegate routine choices and coordination |
| Missing context | The agent asks for intent it cannot retrieve | The agent makes reasonable choices within scope; asks when the goal or a consequential boundary is missing |
| Pace | Discuss, understand, decide, then continue | Coordinate the requested phases, or the whole workflow |
| Review | Choose your own review, agent review, cleanup, or a combination | The agent coordinates review and resolves supported findings within the delegated scope |
| Closure | Choose which specs and docs to update; select any proposed instruction improvements | Reconcile the task's known docs; propose instruction improvements for your selection |
| Responsibility | Yours | Still yours |
Both modes work for developers and nontechnical teammates. Driver mode does not require a technical quiz, and delegated mode does not require pretending to know every implementation detail.
Choose the mode for each piece, not once for the whole task. Think through the
spec and plan in driver mode, delegate implementation with make-it-happen,
then review the result yourself. You can switch back at any point; settled
decisions carry forward and delegation stays within the phases you requested.
In either mode, aim for the simplest complete solution. Reuse what exists, keep types and contracts precise, and verify behavior with meaningful tests and checks. Repository guidance determines the stack and conventions. Quality is part of each implementation slice; cleanup helps remove what is still unnecessary. The implementation quality reference sets out the baseline used by the delegated workflow.
Start with a rough draft, a few details, a pasted conversation, or an accessible Slack thread. A task does not need an existing Notion card.
think-it-through and make-it-happen work best with connected context: use
MCP integrations for Notion, Slack, or your task tracker so the agent can read
sources and update the destination you choose. Connections are optional; pasted
notes, conversations, and local Markdown work too. Access to a tool does not
choose what the agent should update.
- Discuss with
think-it-through. Clarify the problem through a conversation. The agent brings facts, options, and recommendations. When intent or a material tradeoff is missing, it asks you instead of silently deciding. - Agree and save the spec. The agent offers to update your chosen card and establishes its audience: a personal/technical reference, a product brief, or two linked versions. Clear destination context can establish the audience; ambiguity brings a question.
- Choose whether to plan. Once the spec is settled, the agent asks whether you want an implementation plan. The plan defines useful slices, validation, branch/PR boundaries, dependencies, and commit preferences. Keep it as ignored local Markdown in the repository, add it to the technical card, or use both. Local plans stay untracked unless you ask otherwise.
- Implement and understand. Use the repository's implementation guidance. Work in slices, inspect the result, ask for explanations, and iterate until you are satisfied. An agreed spec or plan is not an automatic instruction to start coding.
- Choose review and cleanup. Review it yourself, use
cto-code-review, runsimplify-and-cleanup, or combine them. CTO review lets you accept, reject, or defer findings, then choose fixes here, a subagent, a handoff prompt, or fixing them yourself. - Prepare delivery. Revisit branch boundaries if implementation changed the
plan and use
write-prfor concise PR wording. - Align docs and improve with
align-and-improve. Choose the specs and relevant docs to update, with a shortlist suggested from the task when useful. Reconcile them with the actual result and consider concrete lessons. Changes to shared skills or steering instructions remain your choice.
Use only the piece you need. think-it-through can discuss one decision, turn a
Slack thread into a product task, rewrite a technical spec, or plan an already
agreed change. It does not restart the full workflow for each of those requests.
/think-it-through Help me clarify this idea: <card or notes>.
A short brief is not permission to invent your product decisions. You can explicitly delegate an individual choice with “you decide” or “go automatically” without handing over the entire workflow.
/think-it-through Draft a product task from this thread: <link>
/align-and-improve
For a nontechnical teammate, a familiar task, or a day when you want to
delegate, invoke make-it-happen explicitly. It coordinates the companion
skills and the repository's implementation conventions for the phases you
request, up to the whole route from spec through PR delivery and documentation
alignment. With a goal or card and no phase restriction, that full route is the
default; review, fixes, cleanup, and delivery coordination are built in.
It records the plan and meaningful decisions, implements and verifies the work, coordinates review and fixes, simplifies the result, prepares the requested delivery, then reconciles the task's known documentation when those phases are included. It proposes lessons without silently changing shared skills or steering instructions. You get an understandable result, useful evidence, and anything that still needs your decision.
/make-it-happen Take this task through to a PR: <goal or card>.
/make-it-happen Implement the agreed plan; stop before review.
This mode is explicit-only. It does not activate because you gave a short prompt or because you are not a developer. It can still need a real goal, access, or a decision outside the delegated scope. You can take the wheel back at any time.
These examples assume the agent knows the repository and can read linked sources. Give a starting point and desired outcome or stopping boundary; the skills supply the internal workflow. You do not need to list review tools or repeat the delivery procedure.
/make-it-happen Implement this task and open a PR: <Notion card link>.
The agent handles the spec, plan, implementation, review, fixes, cleanup, PRs, and relevant documentation. It asks when product intent or necessary access is missing.
/think-it-through Help me agree the spec and plan for this: <draft or link>.
Once you're satisfied with the plan:
/make-it-happen Implement the agreed plan; stop before review.
/simplify-and-cleanup Clean up these changes and split branches or commits where useful.
Cleanup preserves intended behavior. Requesting a useful split authorizes it; cleanup alone only recommends branch and commit boundaries.
/make-it-happen Review the existing changes, prepare them for delivery, and open the PRs.
The agent starts from the existing implementation and handles the remaining workflow automatically.
Send these as separate messages, moving on when you're satisfied:
| Step | What to say |
|---|---|
| Discuss and plan | /think-it-through Help me agree the spec and plan: <card or idea>. |
| Build one slice | Implement the first slice, explain the important choices, then wait for my review. |
| Review | /cto-code-review |
| Choose fixes | Accept F1; defer F2. Fix here. |
| Clean up | /simplify-and-cleanup |
| Open the PR | /write-pr Open the PR. |
| Align and improve | /align-and-improve |
Choose findings from the actual review and repeat implementation and review for later slices as needed. You choose when to continue, what to fix, and which docs to update. You can also review changes yourself.
This is the full route. Enter at the piece you need, skip phases you did not
request, and choose driver or delegated mode for each piece. write-pr comes
before align-and-improve; final doc changes can update the existing PR.
flowchart TD
A["Draft, details, or conversation"] --> B["Choose how to work: stay involved or delegate"]
B --> C["think-it-through: discuss and clarify"]
C --> D["Agree the spec"]
D --> E{"Save or update the spec?"}
E -->|Yes| F["Update the chosen destination"]
E -->|Keep in chat| G{"Create an implementation plan?"}
F --> G
G -->|Later| H["Keep the agreed spec"]
G -->|Yes| I["Plan slices and branch boundaries"]
I --> J["Implement and verify with repository conventions"]
B -.->|Start from an agreed plan| J
J --> K{"Choose review or cleanup"}
K --> L["Your review 🗿"]
K --> M["cto-code-review"]
K --> N["simplify-and-cleanup"]
L --> O["Understand, decide, and fix"]
M --> O
N --> O
O -->|Iterate| J
O -->|Ready| P["write-pr"]
K -->|Ready| P
P --> Q["Requested PR delivery"]
Q --> R["align-and-improve: concise doc updates and useful lessons"]
R --> V["Hand back result and remaining proposals"]
| Skill | Reach for it when |
|---|---|
| think-it-through | You want to think through a change and write the right spec for its audience. |
| cto-code-review | You want evidence-based scrutiny of correctness, security, performance, and structural simplicity. |
| simplify-and-cleanup | You want less complexity and boilerplate, plus a useful check of delivery boundaries. |
| write-pr | You want the outcome and essential reviewer context, with implementation bookkeeping left in the diff. |
| make-it-happen | You explicitly delegate selected phases or the whole workflow. |
| align-and-improve | You want to reconcile specs and docs, then choose useful improvements from what happened. |
Use Node.js 22.22.2+ (22.x) or a version supported by package.json. Run
npm install once to enable commit hooks. Commits auto-format and lint staged
Markdown; CI checks published Markdown. Private skills and notes are excluded.
make lintThis is my authored collection. PROVENANCE.md records origins and inspiration; third-party downloads stay with their original sources.
Improve instructions from real use: what decision did the agent get wrong, and what small change would help it get that decision right next time?