autoplan
“Auto-review pipeline — reads the full CEO, design, eng, and DX review skills from disk and runs them sequentially with auto-decisions using 6 decision principles. (gstack)”
aipkg.jsonLICENSE.txtREADME.mdSKILL.mdSKILL.md.tmpl- 01SDI-470%HIGH
SKILL.md:921
detailhide
The skill instructs 'Every section in the loaded skill files must still be executed at the same depth' and 'You MUST still READ the actual code,' but the Phase 1-3 implementations contain explicit section-skipping rules, compression guidance ('not a 3-sentence summary'), and deferred analysis via 'mark TASTE DECISION' without showing findings. This creates a false promise of rigor and allows superficial review when deep analysis is claimed to be mandatory. Users rely on the skill for thorough review and may ship incomplete plans.
919---920921## What "Auto-Decide" Means922923Auto-decide replaces the USER'S judgment with the 6 principles. It does NOT replacefix 1. Clarify the skill contract: either (A) enforce full depth analysis with explicit section skip-list limits, or (B) acknowledge the skill performs 'filtered review' with stated completeness targets (e.g., 'happy path focus'). 2. Remove contradictory language from 'What Auto-Decide Means' that promises full depth if the actual phases skip sections. 3. Add a pre-execution check that warns users if phase outputs are below stated depth requirements (e.g., 'Test section skipped—test plan not produced').
- 02SQP-292%HIGH
SKILL.md.tmpl:166
detailhide
The skill modifies user files (plan file, TODOS.md) through Write/Edit operations without explicit per-operation confirmation. This enables unintended data loss or overwrites if the skill encounters unexpected conditions. The audit trail is written incrementally but only AFTER changes are committed.
164### Step 1: Capture restore point165166Before doing anything, save the plan file's current state to an external file:167168```bashfix Add explicit AskUserQuestion before each Write/Edit operation to the plan file or TODOS.md. Alternatively, require the user to confirm all modifications in a single gate before committing any changes. Maintain a dry-run preview that shows all planned modifications before applying them.
- 03SQP-285%MEDIUM
SKILL.md.tmpl:193
detailhide
The skill reads multiple sensitive files from disk (CLAUDE.md, TODOS.md, git history, design docs) without documenting what information is accessed. An attacker could craft malicious git history or design docs that influence subsequent auto-decisions. Users cannot audit what data the skill ingests.
191### Step 2: Read context192193- Read CLAUDE.md, TODOS.md, git log -30, git diff against the base branch --stat194- Discover design docs: `ls -t ~/.gstack/projects/$SLUG/*-design-*.md 2>/dev/null | head -1`195- Detect UI scope: grep the plan for view/rendering terms (component, screen, form,fix Document exactly which files are read and what data fields are extracted. Add optional flags to skip reading specific file categories. Log all file reads with contents summary for user review. Sanitize git history and file contents before processing (e.g., strip PII).
- 04SQP-288%MEDIUM
SKILL.md.tmpl:150
detailhide
The skill executes external Codex commands with user-provided context (plan file, git state) without documenting that control is passing to an external system. Error handling masks failures, and timeout/hang detection downgrades to partial review without warning. Codex commands include web_search_cached capability, expanding the attack surface.
148---149150## Filesystem Boundary — Codex Prompts151152All prompts sent to Codex (via `codex exec` or `codex review`) MUST be prefixed withfix Explicitly document that Codex execution transfers control outside the current security context. Add pre-execution consent gate showing what data will be sent to Codex. Require explicit user approval before enabling web_search_cached. Log all Codex invocations and their results with timestamps. Provide user-readable summaries of what data left the local system.
- 05SSD-487%MEDIUM
SKILL.md.tmpl:105
detailhide
The 6 decision principles are presented as objective guidelines but contain embedded value judgments that override user intent (e.g., 'Choose completeness' → auto-expand scope; 'Bias toward action' → merge over review). The narrative progressively normalizes autonomous decision-making, making it feel inevitable rather than optional. By Phase 4, users may accept 'User Challenges' (where both models override user direction) as reasonable rather than recognizing this as a significant intent change.
103---104105## Sequential Execution — MANDATORY106107Phases MUST execute in strict order: CEO → Design → Eng → DX.fix Reframe the 6 principles as optional heuristics, not mandatory rules. Explicitly state: 'These principles guide auto-decisions only if you approve them.' Add a pre-Phase 1 gate where users can disable specific principles or request full interactive mode. In Phase 4, highlight User Challenges as 'INTENT OVERRIDES' in bold with severity indicators. Require explicit acceptance of each User Challenge, not just acknowledgment.
- 06SSD-183%MEDIUM
SKILL.md.tmpl:81
detailhide
The 'User Challenges' framing disguises intent overrides as neutral observations. The instruction 'the models must make the case for change' inverts the burden of proof: instead of 'why should we change the user's direction', it becomes 'why shouldn't we adopt the models' recommendation'. This shifts the default from 'user's direction stands' to 'models' direction is presumed better unless user objects'.
793. **Codex disagreements** — codex recommends differently and has a valid point.8081**User Challenge** — both models agree the user's stated direction should change.82This is qualitatively different from taste decisions. When Claude and Codex both83recommend merging, splitting, adding, or removing features/skills/workflows thatfix Rename 'User Challenges' to 'Recommended Intent Changes' or 'Decision Overrides'. Explicitly state in Phase 4: 'Your original direction is the default. Below are items where both models recommend a different approach. Each requires your explicit approval.' Use a checkbox-based gate instead of narrative framing. Require users to opt-in to each change, not opt-out.
- 07SSD-279%LOW
SKILL.md.tmpl:150
detailhide
The 'Codex auth + version preflight' section includes a boundary instruction telling Codex to ignore skill definition files and focus only on repository code. This is presented as a security measure but actually prevents Codex from auditing whether the skill itself contains vulnerabilities or suspicious patterns. It's a soft instruction that Codex may or may not follow.
148---149150## Filesystem Boundary — Codex Prompts151152All prompts sent to Codex (via `codex exec` or `codex review`) MUST be prefixed withfix Replace the soft boundary instruction with actual file access controls. If Codex should not access skills/ directories, enforce this at the execution layer (e.g., --exclude-path flag) rather than via natural language. Be explicit: 'Codex will not have access to gstack skill files.' Alternatively, remove this instruction entirely and document that Codex review includes the skill definitions themselves.
- 08EA2Autonomous Decision Making75%MEDIUM
SKILL.md:861
detailhide
The 6 decision principles are stated as universal auto-decision rules but include vague criteria ('pragmatic', 'boil lakes < 1 day CC effort', 'in blast radius') that require human judgment to apply correctly. The skill auto-applies these without validation. For example, 'Auto-approve expansions that are in blast radius AND < 1 day CC effort (< 5 files, no new infra)' can be misapplied if blast radius is mismeasured or effort estimate is wrong, leading to scope creep or incomplete reviews.
These rules auto-answer every intermediate question: 1. **Choose completeness** — Ship the whole thing. Pick the approach that covers more edge cases. 2. **Boil lakes** — Fix everything in the blast radius (files modified by this plan + direct importers). Auto-approve expansions that are in blast radius AND < 1 day CC effort (< 5 files, no new infra). 3. **Pragmatic** — If two options fix the same thing, pick the cleaner one. 5 seconds choosing, not 5 minutes. 4. **DRY** — Duplicates existing functionality? Reject. Reuse what exists. 5. **Explicit over clever** — 10-line obvious fix > 200-line abstraction. Pick what a new contributor reads in 30 seconds.fix 1. Require the user to confirm effort estimates and blast radius before auto-applying principle P2 ('boil lakes'). 2. Add explicit validation: for each auto-decision that invokes a vague principle, log the assumptions (e.g., 'Assumed blast radius = [files], effort = [estimate]'). 3. Flag 'borderline' decisions (e.g., 4-6 files instead of clear < 5) as TASTE decisions requiring user input, not auto-approval.
- 09EA4Unbounded Resource Access60%MEDIUM
SKILL.md:1571
detailhide
The instruction 'Max 2 attempts — if still missing after retrying twice, proceed to the gate with a warning noting which items are incomplete. Do not loop indefinitely' creates a loophole: if Phase 1 outputs are missing after 2 retries, the skill proceeds anyway with incomplete data, potentially approving a plan review that lacks required artifacts (test plans, architecture diagrams, etc.). This weakens the review gate.
If ANY checkbox above is missing, go back and produce the missing output. Max 2 attempts — if still missing after retrying twice, proceed to the gate with a warning noting which items are incomplete. Do not loop indefinitely. ---fix 1. Escalate to BLOCKED status if any mandatory output (test plan, architecture diagram, error registry) is still missing after 2 attempts. 2. List which outputs are mandatory vs optional per phase before retrying. 3. Require user confirmation to waive missing outputs: 'Test plan artifact missing after 2 attempts. Proceed anyway? (A) Yes, mark as manual review (B) No, restart.'
- 10RA2Session Persistence65%MEDIUM
SKILL.md:14
detailhide
The skill uses Write and Edit tools to modify the plan file incrementally (audit trail appends, decision logs, artifact paths) without explicit user consent checkpoints. Between user decision gates, the skill mutates the plan file multiple times. If a decision gate is rejected (option E), the plan file has already been modified, making rollback to the restore point unclear or lossy.
allowed-tools: - Bash - Read - Write - Edit - Glob - Grepfix 1. Capture restore point at skill start (already done per Phase 0 Step 1). 2. After each user-facing AskUserQuestion gate, offer: 'Revert to restore point? (A) Yes (B) No, keep changes.' 3. Log all plan file mutations in a separate audit file (~/.gstack/projects/$SLUG/autoplan-mutations-$DATETIME.jsonl) that can be undone programmatically. 4. On user rejection (option E), auto-revert to restore point unless explicitly confirmed.
- 11RA2Session Persistence65%MEDIUM
SKILL.md:940
detailhide
The MUST-level directives ('WRITE all required artifacts to disk', 'IDENTIFY every issue', 'DECIDE each issue') conflict with the earlier admission that sections are skipped and decisions are compressed. The skill sets a high standard but the implementation is permissive about waiving it. Users are told the review is comprehensive when it may be abbreviated. This is misleading and undermines the stated quality gate.
- IDENTIFY every issue the section is designed to catch - DECIDE each issue using the 6 principles (instead of asking the user) - LOG each decision in the audit trail - WRITE all required artifacts to disk **You MUST NOT:** - Compress a review section into a one-liner table rowfix 1. Define 'full depth' operationally: specify which sections are mandatory (non-skippable) vs optional (can be skipped with reason). 2. For each mandatory section, define minimum output (e.g., test section requires test plan artifact or explicit skip reason). 3. After Phase 3.5, verify all mandatory artifacts exist; if not, halt and ask user to either (A) generate them or (B) acknowledge a 'shallow review' and mark the plan accordingly.
- 12TM1Tool Parameter Abuse70%HIGH
SKILL.md:277
detailhide
The instruction 'Run `git rm -r .claude/skills/gstack/`' to migrate from vendored to team mode is presented as an automatic action within an AskUserQuestion branch (option A). If a user chooses A, the skill deletes the entire gstack skill directory from the repository without a confirmation checkpoint. If the user's choice is misinterpreted or the deletion is unintended, this causes loss of vendor code without recovery (outside a git commit). This is high-impact filesystem mutation.
- B) No, I'll handle it myself If A: 1. Run `git rm -r .claude/skills/gstack/` 2. Run `echo '.claude/skills/gstack/' >> .gitignore` 3. Run `~/.claude/skills/gstack/bin/gstack-team-init required` (or `optional`) 4. Run `git add .claude/ .gitignore CLAUDE.md && git commit -m "chore: migrate gstack from vendored to team mode"`fix 1. Add a confirmation checkpoint before running `git rm -r`: 'About to delete .claude/skills/gstack/ from git. This cannot be undone in the current session. Confirm? (A) Yes, proceed (B) Cancel.' 2. Create a backup tag or snapshot before deletion: `git tag gstack-vendored-backup-$DATE` 3. After deletion, require `git commit` with user confirmation, not auto-commit.