Skip to content
cccskills
FreePublished on GitHub

plan

Create a concise, evidence-backed implementation plan and save it to .agents/plans/Plan.md. Use when the user asks to plan a feature or task.

The English summary is being prepared. Showing the original description.

See how to install

Files included (1)

  • SKILL.md3.2 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

The plan file is .agents/plans/Plan.md: a record of decisions and executable tasks.

1. Understand the request

Restate the goal in your own words; ask when the intent is ambiguous or a trade-off matters. When the direction itself is unsettled, run a grilling session first to settle it. Read the repository instructions (AGENTS.md, README, docs) and any existing plans in .agents/plans/.

Done when the goal is restated and no ambiguity that could change the plan is left unasked.

2. Research

  • Inspect the code, tests, schemas, and configuration the task would change; trace the current behavior through real entry points.
  • Use web search for external knowledge — library or API behavior, version compatibility, security guidance, community best practice. Fetch the authoritative source.
  • Use subagents for wide or parallel exploration — a large or unfamiliar codebase, many candidate locations, independent concerns. Dispatch one read-only subagent per area; demand evidence with file:line references.
  • Follow every claim back to the source that owns it — primary sources (code, official docs, specs), not secondary write-ups. Record facts separately from proposals.

Done when the current behavior is traced and every claim the plan will make carries a citation (file:line for code, URL for web).

3. Draft the plan

Use only sections that carry information:

# Plan: [Feature]

## Goal

What outcome changes, for whom, and why.

## Current State

Relevant behavior, entry points, constraints, and evidence, with
citations (file:line or URL).

## Decisions

Each decision: the choice, the alternatives considered, and why they were
rejected. Decisions describe contracts and intent, not file paths — they
must stay true as the code moves.

## Scope

In scope. Intentionally out of scope.

## Tasks

Ordered, bite-sized tasks with checkboxes. Each task:

- Names the files it touches (`**Files:**`).
- Names the seam at which its tests hook in (`**Seam:**`) — prefer an
  existing seam, and the highest one possible.
- Gives a way to verify it (`**Verify:**` command or check).

- [ ] Task 1: ... (**Seam:** ...; **Files:** ...; **Verify:** ...)
- [ ] Task 2: ...

## Verification

Focused checks and observable acceptance criteria.

## Open Questions

Only unresolved decisions that can change the plan.

Rules:

  • Name concrete files and symbols only where evidence supports them.
  • No placeholders: "TBD", "implement later", or "add error handling" without specifics are plan failures. Each task must be executable from the plan alone.

Done when the self-review passes — every goal maps to at least one task, names, signatures, and paths are consistent across tasks, and no placeholder remains. Fix issues inline.

4. Save

Write the final plan to .agents/plans/Plan.md with the write tool. If the file exists and the new plan supersedes the old one, overwrite it; otherwise, ask the user for a filename.

Done when the plan is saved. End your turn with a short summary and the file path.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

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".

The English summary is being prepared. Showing the original description.

nmdra/Dotfiles28Updated Aug 11, 2026

Execute git commits using the Conventional Commits specification. Use this skill whenever the user says "commit", "git commit", "/commit", "stage and commit", "make a commit", "save my changes", or asks to commit specific files or all changes. Also triggers on phrases like "push my changes" (commit first), "commit everything", "commit with message X", or whenever git diff/status suggests uncommitted work the user wants to save. Handles auto-staging, diff analysis, message generation, breaking change detection, batch splitting of unrelated changes, safe pushes, and pre-commit hook failures gracefully. Always use this skill rather than ad-hoc git commit commands.

The English summary is being prepared. Showing the original description.

nmdra/Dotfiles28Updated Aug 11, 2026

Use for any question about a codebase, its architecture, file relationships, or project content — especially when graphify-out/ exists, where the question should be treated as a graphify query first. Turns any input (code, docs, papers, images, videos) into a persistent knowledge graph with god nodes, community detection, and query/path/explain tools.

The English summary is being prepared. Showing the original description.

nmdra/Dotfiles28Updated Aug 11, 2026

Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test their thinking, or uses any 'grill' trigger phrases.

The English summary is being prepared. Showing the original description.

nmdra/Dotfiles28Updated Aug 11, 2026

Implement a piece of work based on a spec or set of tickets.

The English summary is being prepared. Showing the original description.

nmdra/Dotfiles28Updated Aug 11, 2026

Maintain CHANGELOG.md — add new version entries, keep the Unreleased section, cut a release, or restructure the whole file — following the Keep a Changelog format and Semantic Versioning.

The English summary is being prepared. Showing the original description.

nmdra/Dotfiles28Updated Aug 11, 2026

See all skills by nmdra

Report a problem with this skill