Skip to content
Report library
Purpose / Other

Planning And Task Breakdown Skill Security Audit

What the author says it does (original text)

Breaks work into ordered tasks. Use when you have a spec or clear requirements and need to break work into implementable tasks. Use when a task feels too large to start, when you need to estimate scope, or when parallel work is possible.

Independent security check

Security risks found

Files checked
1
Risks found
2
Could it run dangerous commands?Looks for programs run straight after downloading, remote control of your computer, and hidden commands.No risks found
Could it expose your files or keys?Looks for uploads of files containing passwords or keys, and keys written directly in the code.Risks found: 1
Medium risk

External-tracker mode publishes project planning details to a third-party account

Source references: 3
What we found

When the user or project rules designate GitHub, Jira, Linear, or another tracker, the instructions require creating an external item for every task. Item bodies include descriptions, acceptance criteria, verification steps, and dependencies, which can reveal unreleased features, file locations, or architecture details.

Why this matters

Project information may leave the local workspace and become visible according to the destination project's permissions, potentially to an organization or the public. Persistent records are also created in the user's account.

Legitimate use of this code

This is not a hidden upload to an arbitrary third party. The skill creates tracker items only when the user or project rules have already designated an external tracker, and it explicitly states that acceptance criteria, verification steps, and dependencies go into those items. That is a normal, conditional output of a planning skill. Items may also include likely file paths, so the tracker's visibility matters, but the source does not show bypassing authorization, choosing an undesignated account, or making content public on its own.

This assessment concerns the code and conditions shown, not proof that harm has occurred.
SKILL.md:81In the instructionsOpen original file
Each task follows this structure, whether it lands in the markdown task list or as an item in an external tracker (see Output Files):```markdown## Task [N]: [Short descriptive title]**Description:** One paragraph explaining what this task accomplishes.**Acceptance criteria:**- [ ] [Specific, testable condition]- [ ] [Specific, testable condition]**Verification:**- [ ] Tests pass: [the repository's focused-test command]- [ ] Build succeeds: [the repository's build command]- [ ] Manual check: [description of what to verify]**Dependencies:** [Task numbers this depends on, or "None"]**Files likely touched:**- `src/path/to/file.ts`- `tests/path/to/test.ts`**Estimated scope:** [Small: 1-2 files | Medium: 3-5 files | Large: 5+ files]```
Show 2 other places
SKILL.md:162In the instructionsOpen original file
- **Default: a checklist-style markdown file at `tasks/todo.md`.** This is the convention the `/build` command and other downstream tooling expect. Use it unless the project says otherwise.- **External tracker:** if the project's agent rules (`CLAUDE.md`, `AGENTS.md`, etc.) or the user designate an issue tracker (e.g. GitHub Issues, Jira, Linear, `bd`/beads), create one tracker item per task instead of writing `tasks/todo.md`. Map the Step 4 structure onto the tracker's fields: acceptance criteria and verification steps in the item body, dependencies via the tracker's linking mechanism (`bd dep add`, "blocked by", etc.). Record Step 5 checkpoints as tracker items too, or as a checklist in the plan document if the tracker has no natural equivalent.When using an external tracker, note it in `tasks/plan.md` (e.g. "Tasks tracked in Linear project FOO") so downstream steps and future sessions know where to look, and keep the plan document's Task List section as an ordered index of tracker item IDs or links rather than a duplicate checklist.
SKILL.md:161In the instructionsOpen original file
- **Default: a checklist-style markdown file at `tasks/todo.md`.** This is the convention the `/build` command and other downstream tooling expect. Use it unless the project says otherwise.- **External tracker:** if the project's agent rules (`CLAUDE.md`, `AGENTS.md`, etc.) or the user designate an issue tracker (e.g. GitHub Issues, Jira, Linear, `bd`/beads), create one tracker item per task instead of writing `tasks/todo.md`. Map the Step 4 structure onto the tracker's fields: acceptance criteria and verification steps in the item body, dependencies via the tracker's linking mechanism (`bd dep add`, "blocked by", etc.). Record Step 5 checkpoints as tracker items too, or as a checklist in the plan document if the tracker has no natural equivalent.When using an external tracker, note it in `tasks/plan.md` (e.g. "Tasks tracked in Linear project FOO") so downstream steps and future sessions know where to look, and keep the plan document's Task List section as an ordered index of tracker item IDs or links rather than a duplicate checklist.
Could it delete files or keep running?Looks for broad file deletion, disk overwrites, and programs set to start automatically.Risks found: 1
Low risk

The claimed “read-only” planning mode still changes project files

Source references: 2
What we found

The instructions first call planning “read-only,” but then require saving two Markdown files and potentially creating a directory. This wording may lead users to believe the run will not modify the workspace.

Why this matters

The run can leave new or updated planning files. This may add workspace clutter or modify an existing plan for the same work. The Skill does protect unfinished plans for different work from being overwritten, which limits the risk.

The skill calls planning “read-only mode,” but the same workflow requires writing a plan and task list into the project and creating the `tasks/` directory when needed. Although it prohibits implementation code, using the skill can still change the workspace. A user interpreting “read-only” as no disk writes could receive unexpected new or updated files. The later overwrite safeguards reduce destructive risk but do not resolve the misleading wording.

SKILL.md:26In the instructionsOpen original file
Before writing any code, operate in read-only mode:- Read the spec and relevant codebase sections- Identify existing patterns and conventions- Map dependencies between components- Note risks and unknowns**Do NOT write code during planning.** The output is a plan document saved to `tasks/plan.md` and a task list recorded in the task list target (see Output Files; default `tasks/todo.md`), not implementation.
Show 1 other places
SKILL.md:145In the instructionsOpen original file
- **Plan document:** Save the implementation plan to `tasks/plan.md`. This is always a markdown file — design decisions, risks, and open questions don't map cleanly onto individual tracker issues.- **Task list:** Record each task in the **task list target** (defined below).Create the `tasks/` directory if it does not exist.**Never overwrite an incomplete plan.** Before writing `tasks/plan.md` or `tasks/todo.md`, check whether they already exist and still contain unchecked tasks:
Could it bypass safety checks?Looks for skipped website security checks, excessive file access, or actions that skip your approval.No risks found
Could it mislead the AI or hide text?Checks the skill instructions for requests to ignore you, influence the report, or hide text in invisible characters.No risks found
Could it change links or payment recipients without asking?Looks for forced referral or payment changes combined with instructions to hide the change.No risks found

Inside this skill

8 instruction sections

The Skill reads specifications and relevant code, maps dependencies, and produces an implementation plan with acceptance criteria, verification steps, and dependencies. It explicitly prohibits implementation coding during planning.

View source
SKILL.md:26In the instructionsOpen original file
Before writing any code, operate in read-only mode:- Read the spec and relevant codebase sections- Identify existing patterns and conventions- Map dependencies between components- Note risks and unknowns**Do NOT write code during planning.** The output is a plan document saved to `tasks/plan.md` and a task list recorded in the task list target (see Output Files; default `tasks/todo.md`), not implementation.

By default, the output creates or updates `tasks/plan.md` and `tasks/todo.md` in the project, creating the `tasks/` directory when needed.

View source
SKILL.md:143In the instructionsOpen original file
## Output Files- **Plan document:** Save the implementation plan to `tasks/plan.md`. This is always a markdown file — design decisions, risks, and open questions don't map cleanly onto individual tracker issues.- **Task list:** Record each task in the **task list target** (defined below).Create the `tasks/` directory if it does not exist.
SKILL.md:161In the instructionsOpen original file
- **Default: a checklist-style markdown file at `tasks/todo.md`.** This is the convention the `/build` command and other downstream tooling expect. Use it unless the project says otherwise.- **External tracker:** if the project's agent rules (`CLAUDE.md`, `AGENTS.md`, etc.) or the user designate an issue tracker (e.g. GitHub Issues, Jira, Linear, `bd`/beads), create one tracker item per task instead of writing `tasks/todo.md`. Map the Step 4 structure onto the tracker's fields: acceptance criteria and verification steps in the item body, dependencies via the tracker's linking mechanism (`bd dep add`, "blocked by", etc.). Record Step 5 checkpoints as tracker items too, or as a checklist in the plan document if the tracker has no natural equivalent.

It includes collision protection: if an unfinished plan belongs to different work, it must stop and ask the user rather than overwrite, delete, or rename it. Similar protection applies to open items in an external tracker.

View source
SKILL.md:150In the instructionsOpen original file
**Never overwrite an incomplete plan.** Before writing `tasks/plan.md` or `tasks/todo.md`, check whether they already exist and still contain unchecked tasks:- Same work being replanned (the user asked to revise or extend this plan) → update the existing files in place.- Different work → **stop and ask.** The unchecked tasks may be mid-build in another session. Do not delete, overwrite, or rename the existing files on your own; present the conflict and let the user decide (finish the old plan first, explicitly discard it, or tell you where the new plan should go).The same rule applies to an external task list target: never bulk-close or delete another plan's open tracker items to make room for new ones.

If the user or project rules designate an external task tracker, the Skill creates one tracker item per task and records item IDs or links in the local plan.

View source
SKILL.md:162In the instructionsOpen original file
- **Default: a checklist-style markdown file at `tasks/todo.md`.** This is the convention the `/build` command and other downstream tooling expect. Use it unless the project says otherwise.- **External tracker:** if the project's agent rules (`CLAUDE.md`, `AGENTS.md`, etc.) or the user designate an issue tracker (e.g. GitHub Issues, Jira, Linear, `bd`/beads), create one tracker item per task instead of writing `tasks/todo.md`. Map the Step 4 structure onto the tracker's fields: acceptance criteria and verification steps in the item body, dependencies via the tracker's linking mechanism (`bd dep add`, "blocked by", etc.). Record Step 5 checkpoints as tracker items too, or as a checklist in the plan document if the tracker has no natural equivalent.When using an external tracker, note it in `tasks/plan.md` (e.g. "Tasks tracked in Linear project FOO") so downstream steps and future sessions know where to look, and keep the plan document's Task List section as an ordered index of tracker item IDs or links rather than a duplicate checklist.
Start here · InstructionsSKILL.md
planning-and-task-breakdown
Lines connect the instruction file to its sections, not an observed execution order. Select a section to read the source. 3 more sections are available in the original file.
Files and check records1 files

Coverage and gaps

Content covered in each file

These are the source ranges included in this check, not a guarantee that every issue has been resolved.

  • SKILL.mdFull text included

This report is for the version above. We read the available code and instructions without running the skill or checking extra packages it installs. This is not a promise of safety: a different version or setup may behave differently.

  • SKILL.mdInstructions
Lines read
258
File checksum (to compare versions)
8cc69ea9a749b762e9facdc82d533da3cc091067cb0f045ea2cba52454db2a61