Security audit
Security checks for vulnerabilities and agentic risk
This skill is openly an autonomous code-changing loop, but it gives itself broad repository mutation and execution authority with limited user control after launch.
Install only in disposable clones or branches where autonomous edits, commits, reverts, test execution, and local logging are acceptable. Set tight budget and max_rounds limits, review the parsed goal before launch, and be prepared to stop it with `.team-loop/STOP`.
The statement "Delete wrong tests; never patch them" describes destructive behavior without an explicit safeguard, approval gate, or rollback warning. In an autonomous looping skill, this can lead to deletion of valuable tests or masking regressions by replacing failing tests rather than preserving them for review.
The README describes an autonomous task loop but does not prominently warn, near the description and quick start, that execution may modify files and create commits. That omission can mislead users about operational risk, especially because the skill advertises zero human intervention and autonomous plan→execute→verify cycles.
The trigger set includes very broad aliases such as "loop" and the Chinese "迭代", which can plausibly appear in ordinary user requests and accidentally invoke a high-autonomy code-modifying skill. In this specific skill, accidental activation is more dangerous than usual because the workflow is explicitly human-out-of-loop, can modify files, and can create commits before a user realizes what was triggered.
The top-level design advertises a zero-human-intervention autonomous loop, which is a genuine security concern because it normalizes continuous self-directed action without review. In a repository context, that autonomy amplifies the blast radius of mistakes or malicious prompt influence across repeated plan-execute-verify cycles.
description: >
Autonomous task loop engine — self-verifying, goal-driven, human-out-of-loop.
Triggered by: loop, team-loop, 迭代研发, 迭代.
Human sets a quantifiable goal (e.g., coverage ≥ 50%), agent team autonomously
executes plan→execute→verify→memorize→replan cycles with zero human intervention.
Suitable for: coverage improvement, code migration, refactoring, test completion,
token-budget tasks.
The skill is explicitly designed to modify files, perform git operations, and run tests/subprocesses without further human approval once a goal is set. In practice, this grants a high degree of autonomous control over code and execution paths, which can be abused for destructive changes, unsafe code execution, or unintended propagation of malicious repository contents.
it will **modify your repository** without further human approval. Be aware:
- **File modification:** Can create, edit, delete source files and tests autonomously
- **Git operations:** May commit, revert, and branch without confirmation
- **Test execution:** Runs project code and tests in subprocesses — untrusted code paths may execute
- **State persistence:** Stores prompts, code context, file paths, and debug logs in `.team-loop/` on disk
- **Broad triggers:** `loop` and `迭代` are common terms — accidental invocation is possible; always review the goal before confirming
The trigger set includes extremely common terms like loop and 迭代, which materially increases the chance of accidental invocation during ordinary conversation. In this skill, accidental invocation is especially dangerous because activation can lead to autonomous repository modification, git operations, and execution of project code with minimal additional friction.
The skill explicitly instructs the agent to develop on the current branch, create commits, and perform git revert operations, but it does not require an explicit pre-execution warning or fresh user confirmation before modifying the repository. In a 'human-out-of-loop' autonomous loop, this materially increases the risk of unintended code changes, history rewrites, loss of in-progress work, or destructive rollback actions occurring without the user realizing the repository will be changed.
The file presents separate English and Chinese specifications, but does not state how the skill chooses language or that the user can opt in to a preferred locale. This can be a natural-language policy concern if the skill defaults to a language without explicit user preference.
The skill requires explicit invocation via a fixed set of English and Chinese trigger keywords, but does not indicate any user-selectable language or locale preference. This can amount to a language-policy issue because invocation is constrained to preset languages rather than clearly offering opt-in or alternatives.