본문으로 건너뛰기
cccskills
무료GitHub에 공개

plan-first

Structured planning workflow for any coding task. Use at the start of every new feature, bug fix, refactor, or implementation request. Analyzes the project, asks up to 5 clarifying questions, creates a TODO.md, gets user approval, then executes task by task. Never writes code before a plan is approved.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

설치 방법 보기

포함된 파일(1)

  • SKILL.md3.9 KB

SKILL.md(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

Plan-First Workflow

Rules

  • NEVER write code, create files, or run commands before a TODO.md is approved.
  • NEVER assume missing information. Ask instead.
  • NEVER skip steps. Follow phases in order.
  • NEVER go off-plan. If new work is discovered, add it to TODO.md and ask for approval before doing it.

Phase 1 -- Analyze the Project

Read the project silently before asking anything. Check:

  1. Directory structure (top 2 levels)
  2. package.json, pubspec.yaml, go.mod, requirements.txt, Cargo.toml, pom.xml, or equivalent
  3. Existing dependencies and their versions
  4. Build system and scripts (Makefile, scripts/, CI config)
  5. README.md or README.*
  6. Any existing TODO.md, TASKS.md, .todo, or open issue files

Do not output analysis results unless directly relevant to your questions.


Phase 2 -- Ask Clarifying Questions (One Round Only)

After analysis, identify gaps that would block correct implementation.

  • Ask at most 5 questions in a single message.
  • Only ask what is critical and cannot be inferred from the codebase.
  • Number the questions.
  • Do not ask about things already answerable from the project files.
  • Do not split into multiple rounds -- this is your only chance to ask.

Example format:

Before I create the plan, I need a few things clarified:

1. Should the new endpoint require authentication?
2. Is there a preferred database (the project has both SQLite and Postgres configs)?
3. Should existing tests be updated, or only new ones added?

Wait for the user's response before proceeding.


Phase 3 -- Create TODO.md

Using the analysis and the user's answers, write a TODO.md file in the project root.

TODO.md Structure

# TODO

## Goal
One sentence describing what will be built or fixed.

## Tasks

### 1. <Phase Name>
- [ ] <Concrete, measurable action>
- [ ] <Concrete, measurable action>

### 2. <Phase Name>
- [ ] <Concrete, measurable action>
- [ ] <Concrete, measurable action>

## Notes
Any constraints, decisions, or known risks recorded here.

Requirements

  • Tasks must be small and independently verifiable (one logical change each).
  • Order tasks by dependency (prerequisites first).
  • Each task must be checkable as done/not done.
  • No vague items like "fix things" or "improve code".

After writing the file, show the full contents to the user and ask:

I've created TODO.md. Does this plan look correct?
Reply YES to start, or tell me what to change.

Phase 4 -- Revision Loop (if needed)

If the user requests changes:

  1. Ask targeted follow-up questions to resolve the disagreement.
  2. Rewrite TODO.md.
  3. Show the updated plan and ask for approval again.

Repeat until the user approves.


Phase 5 -- Execute the Plan

Once approved:

  1. Work through tasks in order, one at a time.
  2. After completing each task, mark it done in TODO.md:
    • Change - [ ] to - [x]
  3. State which task you are starting before you begin it.
  4. Do not start the next task until the current one is complete.
  5. Do not perform any work not listed in TODO.md.

If you discover that an unlisted task is required:

  • Stop.
  • Add it to TODO.md under a ## Discovered Tasks section.
  • Tell the user what was found and why it is needed.
  • Ask for approval before continuing.

When all tasks are marked [x], write:

All tasks in TODO.md are complete.

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

Distills enduring architectural decisions and design rationale from wave orchestration plans or historical git changes into structured, tracked Architecture Decision Records (ADRs). Use pre-wave to resolve active architectural constraints or post-wave to record enduring decisions in docs/decisions/.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

AndrewBrown-USDA/aigb-skills-usda72026년 10월 16일 업데이트

Create and maintain AGENTS.md files for project onboarding and grounding. Use when initialized in a new project, when project structure changes significantly, or when creating subfolder-level AGENTS.md files for complex monorepos.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

AndrewBrown-USDA/aigb-skills-usda72026년 10월 16일 업데이트

Audit and update an arbitrary codebase to follow the Code.mil federal open-source licensing model (MIT with 17 U.S.C. Section 105 disclaimers and INTENT.md), including CRAN/R package DESCRIPTION setup.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

AndrewBrown-USDA/aigb-skills-usda72026년 10월 16일 업데이트

caveman

무료

Ultra-compressed communication mode that cuts output tokens while keeping technical accuracy. Levels: lite, full, ultra and the wenyan variants. Use for /caveman, "caveman mode", "talk like caveman", "be brief" or "less tokens".

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

AndrewBrown-USDA/aigb-skills-usda72026년 10월 16일 업데이트

Review the changes since a fixed point (commit, branch, tag, or merge-base) along two axes - Standards (does the code follow this repo's documented coding standards?) and Spec (does the code match what the originating issue/spec asked for?). Runs both reviews in parallel sub-agents and reports them side by side. Use when the user wants to review a branch, a PR, work-in-progress changes, or asks to "review since X".

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

AndrewBrown-USDA/aigb-skills-usda72026년 10월 16일 업데이트

Reads Copilot conversation history and extracts executive-ready success stories. Use when the user asks to study prior Copilot sessions, summarize what was done before, mine evidence, or quantify time, cost, risk, and priority alignment from GitHub Copilot history in any workspace or repository.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

AndrewBrown-USDA/aigb-skills-usda72026년 10월 16일 업데이트

AndrewBrown-USDA의 스킬 모두 보기

이 스킬의 문제 신고