Skip to content
skillsafebeta
← Report library
Purpose / Development

Incremental Implementation Skill Security Audit

What the author says it does (original text)

Delivers changes incrementally. Use when implementing any feature or change that touches more than one file. Use when you're about to write a large amount of code at once, or when a task feels too big to land in one step.

Independent security check

Security risks found

Files checked
1
Risks found
3
Could it run dangerous commands?Looks for programs run straight after downloading, remote control of your computer, and hidden commands.Risks found: 1
Medium risk

Verification runs repository-controlled test, build, and tooling commands

Source references: 2
What we found

The Skill explicitly requires the repository's own test, build, type-check, and lint commands, with npm, Gradle, pytest, and npx examples. Such commands can execute repository scripts, plugins, build logic, and dependency code rather than merely inspect source files.

Why this matters

In an untrusted repository or dependency set, verification could execute malicious code that reads accessible files or credentials, changes the workspace, or uses any network access available to the agent.

The Skill actively requires running the repository's test, build, type-check, and lint commands after increments. Such commands commonly execute repository scripts, build plugins, or dependency code; in an untrusted repository, that code could access files, environment credentials, or the network within the agent's permissions. Verification is consistent with the Skill's development purpose, but the code-execution risk remains. Users can require command review and restrict network, credentials, and filesystem access.

SKILL.md:201In the instructionsOpen original file
After each increment, verify with the repository's own commands (see the test-driven-development skill's Discover the Stack First section):- [ ] The change does one thing and does it completely- [ ] All existing tests still pass (the repository's test command: `npm test`, `./gradlew test`, `pytest`, ...)- [ ] The build succeeds (the repository's build command)- [ ] Type checking passes, where the stack has one (`npx tsc --noEmit`, `mypy`, ...)- [ ] Linting passes (the repository's lint command)- [ ] The new functionality works as expected- [ ] The change is committed with a descriptive message
Show 1 other places
SKILL.md:38In the instructionsOpen original file
1. **Implement** the smallest complete piece of functionality2. **Test** — run the test suite (or write a test if none exists)3. **Verify** — confirm the slice works as expected (tests pass, build succeeds, manual check)4. **Commit** -- save your progress with a descriptive message (see `git-workflow-and-versioning` for atomic commit guidance)5. **Move to the next slice** — carry forward, don't restart
Could it expose your files or keys?Looks for uploads of files containing passwords or keys, and keys written directly in the code.No risks found
Could it delete files or keep running?Looks for broad file deletion, disk overwrites, and programs set to start automatically.Risks found: 1
Medium risk

Creates Git commits for every increment by default

Source references: 5
What we found

The Skill makes committing a required step for every increment and ends by requiring no uncommitted changes. Authorization to implement a task does not necessarily authorize changing repository history.

Why this matters

The agent may create several lasting commits when the user only wanted changes prepared for review, making review, reorganization, or rollback harder. If the worktree already contains user changes, an unspecified commit scope could also include them.

The live workflow makes a commit part of every increment, repeats that requirement in the checklist, and finally requires no uncommitted changes. If followed when the user authorized file changes but not Git-history changes, it would create commits; the clean-tree requirement could also pressure the agent to handle pre-existing unrelated changes. A user can require that commits be opt-in and that existing uncommitted work remain untouched.

SKILL.md:38In the instructionsOpen original file
1. **Implement** the smallest complete piece of functionality2. **Test** — run the test suite (or write a test if none exists)3. **Verify** — confirm the slice works as expected (tests pass, build succeeds, manual check)4. **Commit** -- save your progress with a descriptive message (see `git-workflow-and-versioning` for atomic commit guidance)5. **Move to the next slice** — carry forward, don't restart
Show 4 other places
SKILL.md:239In the instructionsOpen original file
After completing all increments for a task:- [ ] Each increment was individually tested and committed- [ ] The full test suite passes- [ ] The build is clean- [ ] The feature works end-to-end as specified- [ ] No uncommitted changes remain
SKILL.md:41In the instructionsOpen original file
3. **Verify** — confirm the slice works as expected (tests pass, build succeeds, manual check)4. **Commit** -- save your progress with a descriptive message (see `git-workflow-and-versioning` for atomic commit guidance)5. **Move to the next slice** — carry forward, don't restart
SKILL.md:203In the instructionsOpen original file
- [ ] The change does one thing and does it completely- [ ] All existing tests still pass (the repository's test command: `npm test`, `./gradlew test`, `pytest`, ...)- [ ] The build succeeds (the repository's build command)- [ ] Type checking passes, where the stack has one (`npx tsc --noEmit`, `mypy`, ...)- [ ] Linting passes (the repository's lint command)- [ ] The new functionality works as expected- [ ] The change is committed with a descriptive message
SKILL.md:241In the instructionsOpen original file
- [ ] Each increment was individually tested and committed- [ ] The full test suite passes- [ ] The build is clean- [ ] The feature works end-to-end as specified- [ ] No uncommitted changes remain
Could it bypass safety checks?Looks for skipped website security checks, excessive file access, or actions that skip your approval.Risks found: 1
Low risk

The install command does not pin a dependency version

Source references: 2
What we found

The installation command does not specify dependency versions. The same command may download different code later, so what you install can differ from what was checked.

Why this matters

A later install may download different code even though the command and this report have not changed.

Legitimate use of this code

This is not an instruction to install a dependency; it is an example command for projects that already use type checking, within a checklist that says to use the repository's own commands. Although `npx` may prompt or attempt a download when a package is absent in some environments, the source does not instruct an unpinned installation, so the claimed risk is not directly supported.

This assessment concerns the code and conditions shown, not proof that harm has occurred.
SKILL.md:206In the instructionsOpen original file
- [ ] The build succeeds (the repository's build command)- [ ] Type checking passes, where the stack has one (`npx tsc --noEmit`, `mypy`, ...)- [ ] Linting passes (the repository's lint command)
Show 1 other places
SKILL.md:201In the instructionsOpen original file
After each increment, verify with the repository's own commands (see the test-driven-development skill's Discover the Stack First section):
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 directs the agent to split multi-file changes into small vertical increments and implement, test, verify, and commit each increment before continuing.

View source
SKILL.md:36In the instructionsOpen original file
For each slice:1. **Implement** the smallest complete piece of functionality2. **Test** — run the test suite (or write a test if none exists)3. **Verify** — confirm the slice works as expected (tests pass, build succeeds, manual check)4. **Commit** -- save your progress with a descriptive message (see `git-workflow-and-versioning` for atomic commit guidance)5. **Move to the next slice** — carry forward, don't restart

It requires scope discipline: no cleanup of adjacent code or features outside the specification, and unrelated issues should be reported rather than changed.

View source
SKILL.md:117In the instructionsOpen original file
Touch only what the task requires.Do NOT:- "Clean up" code adjacent to your change- Refactor imports in files you're not modifying- Remove comments you don't fully understand- Add features not in the spec because they "seem useful"- Modernize syntax in files you're only readingIf you notice something worth improving outside your task scope, note it — don't fix it:

For unfinished functionality, the Skill recommends a disabled-by-default feature flag and requires each increment to be independently reversible.

View source
SKILL.md:147In the instructionsOpen original file
### Rule 3: Feature Flags for Incomplete FeaturesIf a feature isn't ready for users but you need to merge increments:```typescript// Feature flag for work-in-progressconst ENABLE_TASK_SHARING = process.env.FEATURE_TASK_SHARING === 'true';if (ENABLE_TASK_SHARING) {  // New sharing UI}```This lets you merge small increments to the main branch without exposing incomplete work.
SKILL.md:174In the instructionsOpen original file
### Rule 5: Rollback-FriendlyEach increment should be independently revertable:- Additive changes (new files, new functions) are easy to revert- Modifications to existing code should be minimal and focused- Database migrations should have corresponding rollback migrations- Avoid deleting something in one commit and replacing it in the same commit — separate them
Start here · InstructionsSKILL.md
incremental-implementation
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

Operations mentioned in code and instructions

Read keys or account settings
SKILL.md:153In the instructionsOpen original file
// Feature flag for work-in-progressconst ENABLE_TASK_SHARING = process.env.FEATURE_TASK_SHARING === 'true';
Install extra software packages
SKILL.md:206In the instructionsOpen original file
- [ ] The build succeeds (the repository's build command)- [ ] Type checking passes, where the stack has one (`npx tsc --noEmit`, `mypy`, ...)- [ ] Linting passes (the repository's lint command)
Lines read
250
File checksum (to compare versions)
f363fa03d08c2b7bdb8bfd66fa052b9f6e51ab5231e301a8d0d6848329f51de5