원클릭으로 Manus에서 모든 스킬 실행

upgrade-plan

스타4

포크0

업데이트2026년 7월 20일 10:56

Upgrades an outdated plan or requirements set to current CodeOps standards. Use when the user says "upgrade_plan", "upgrade_requirements", "upgrade my plan", "upgrade my requirements", "bring my plan up to date", "bring my requirements up to date", or asks for a "version upgrade" of a plan/requirements set. ONE skill covers both targets: "upgrade_plan [feature-name]" re-evaluates a plan in plans/<feature>/ against current standards, and "upgrade_requirements" re-evaluates the set in requirements/. It detects the target from the phrasing/arguments and branches. The flow is: detect version, assess gaps, present an upgrade report BEFORE changing anything, pass a non-negotiable Content Quality Gate, apply upgrades preserving all user-authored content verbatim, then verify. Does NOT auto-advance the roadmap.

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

blendsdk

blendsdk/claude-codeops

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

관련 직업SOC

SOC 직업 분류 기준

소프트웨어 개발자컴퓨터 및 수학직·SOC 15-1252

파일 탐색기

3 개 파일

SKILL.md

readonly

이 저장소의 다른 Skills

같은 저장소

exec-plan

blendsdk/claude-codeops

Executes an implementation plan created by the make_plan skill. Use when the user says "exec_plan", "run the plan", "execute the plan", "implement the plan in plans/<feature>", or "continue the plan for <feature>". Accepts a feature name and an optional commit-mode flag: --ask-commit (default, ask after each verified task), --no-commit (never commit), or --auto-commit (commit + push after each verified task). Reads plans/<feature>/99-execution-plan.md, finds the next incomplete task, and runs the per-task loop (implement -> update the execution plan immediately -> verify -> commit per mode) following specification-first task ordering. When the repo's CLAUDE.md carries a CodeOps quality-profile block, a profile-gated quality loop reviews each executed phase (reviewer + auditor agents); critical/major findings pause for a user ruling in every commit mode.

2026-07-204

grill-me

blendsdk/claude-codeops

Relentlessly interrogate a design to eliminate ambiguity before any planning, requirements, or implementation work begins. Use for "grill me", "grill_me", "disambiguate", "deep-dive", or "interview me about this". Runs a structured, branch-by-branch interview: maps the design tree of major decision branches, walks each branch surfacing options, assumptions, and sub-decisions one at a time, resolves cross-branch dependencies, and confirms explicit shared understanding. Acts as a senior architect conducting a design review — never accepts vague answers, names every decision/assumption/constraint, resolves dependencies first, and tracks the decision tree until zero ambiguity remains.

2026-07-204

make-plan

blendsdk/claude-codeops

Creates a detailed, multi-document implementation plan for a software feature or task before any code is written. Use when the user wants to "make a plan", types "make_plan", or asks to "plan this feature", "create an implementation plan", "plan out this work", or "write a spec/plan" for something to be built. Drives a mandatory clarifying-questions interview, a hard Zero-Ambiguity Gate, and produces a `plans/<feature>/` document set ending in a task-by-task execution plan. For EXECUTING an existing plan, use the exec_plan skill instead.

2026-07-204

make-requirements

blendsdk/claude-codeops

Gather and document requirements, turn an idea into formal requirement documents (RDs). Use for "make_requirements" (full discovery: brain dump or bare idea into a structured requirements/ set), "add_requirement" (add one new RD to an existing set), and "review_requirements" (health check / gap analysis on an existing set). Trigger when the user wants to capture, expand, structure, or audit what a system must do before building it — e.g. "help me spec out my app", "document requirements", "what features am I missing", "add a feature to the requirements", "review my requirements for gaps". Acts as a proactive domain consultant: absorbs the seed idea, expands it with comparable-system features, challenges it with edge cases, then decomposes it into numbered RDs behind a hard Zero-Ambiguity Gate.

2026-07-204

preflight

blendsdk/claude-codeops

Runs a rigorous multi-dimensional quality audit of a plan, requirements, or any artifact, grounded in the actual codebase. Use for "preflight", "quality audit", "review gate", "audit this plan", "audit these requirements", or "review my plan/requirements before I build it". An adversarial review gate that hunts for every ambiguity, contradiction, gap, and risk, verifies every claim against the real code, scores findings on a 13-dimension scan, and presents each one with options and a recommendation for the user to decide — it never fixes silently. Takes an artifact target (e.g. requirements, requirements RD-03, <feature-name>, <feature-name> 03-api-design, or a file/dir path) plus optional --continue to resume an interrupted session.

2026-07-204

retro-requirements

blendsdk/claude-codeops

Reverse-engineer an existing codebase into structured requirements. Use for "retro_requirements", "reverse requirements", "reconstruct requirements from code", "requirements archaeology", or "reverse-engineer this codebase". Trigger when the user wants to reconstruct requirements from an existing, undocumented, or legacy codebase — for documentation, migration, or a from-scratch rebuild — e.g. "document what this app does", "extract requirements from this code", "reverse-engineer this service into a spec". Analyzes any language/framework through a 9-phase archaeology pipeline and produces a reconstruction brief that feeds the make_requirements skill. Extracts WHAT the system does (not HOW), classifies every behavior by confidence (✅/⚠️/🔴), and enforces a hard Bug-or-Feature Triage Gate so bugs are never silently documented as features. Supports --scope <path> to analyze one module/package and --continue to resume an interrupted session.

2026-07-204

name	upgrade_plan
description	Upgrades an outdated plan or requirements set to current CodeOps standards. Use when the user says "upgrade_plan", "upgrade_requirements", "upgrade my plan", "upgrade my requirements", "bring my plan up to date", "bring my requirements up to date", or asks for a "version upgrade" of a plan/requirements set. ONE skill covers both targets: "upgrade_plan [feature-name]" re-evaluates a plan in plans/<feature>/ against current standards, and "upgrade_requirements" re-evaluates the set in requirements/. It detects the target from the phrasing/arguments and branches. The flow is: detect version, assess gaps, present an upgrade report BEFORE changing anything, pass a non-negotiable Content Quality Gate, apply upgrades preserving all user-authored content verbatim, then verify. Does NOT auto-advance the roadmap.
when_to_use	Use to bring an EXISTING plan or requirements set up to current standards. Plan CREATION lives in the make_plan skill and requirements CREATION in the make_requirements skill — point the user there for new artifacts. Trigger on /upgrade_plan, /upgrade_requirements, or any natural-language request to upgrade / modernize / bring up to date an existing plan or requirements set.
argument-hint	[feature-name]
arguments	feature

upgrade_plan — Upgrade a Plan or Requirements Set

CodeOps Skills Version: 3.11.0

Plans and requirements are living documents. As CodeOps standards evolve, older artifacts drift out of date. This skill detects staleness, assesses gaps against current standards, upgrades documents while preserving all user-authored content, and verifies the result.

This skill covers upgrades only. To create a new plan use the make_plan skill; to create a new requirements set use the make_requirements skill.

Resolve paths layout-aware, and don't migrate layout here. A plan/requirements set lives at a flat path (plans/<feature>/, requirements/) or, in a nested-layout repo, under codeops/features/<f>/… — resolve it via ../../_shared/layout-convention.md. This skill upgrades content/version in place; it never moves a repo between layouts. Converting a flat repo to the nested codeops/ layout is the setup_codeops skill's job — point the user there for that, and keep upgrades within the existing layout.

Which target? (branch first)

Detect the target from the phrasing/arguments before doing anything else:

Trigger	Target	Directory
`upgrade_plan [feature-name]`, "upgrade my plan", "bring the plan up to date"	Plan	`plans/[feature-name]/`
`upgrade_requirements`, "upgrade my requirements", "bring requirements up to date"	Requirements	`requirements/`

If the target is genuinely ambiguous (e.g. bare "upgrade"), ask the user which one. The two branches share the same 4-phase flow; the per-document checklists differ and live in upgrade-checklists.md.

Version detection & classification

Read the plan's 00-index.md (or 99-execution-plan.md), or for requirements the README.md and individual RD documents.
Look for a version stamp: > **CodeOps Version**: X.Y.Z or > **CodeOps Skills Version**: X.Y.Z.
Compare the stamp against the current standard version 3.3.2 (the bumps since 3.0.0 are behavioral — no document migration — so 3.0.0–3.3.1 artifacts remain compatible).

Condition	Classification	Action
No version stamp found	Pre-versioning / outdated	Full upgrade recommended — the artifact predates version stamping
Stamp = `3.0.0`, `3.1.0`, `3.2.0`, `3.3.0`, `3.3.1`, or `3.3.2`	Current	Report "No upgrade needed" — already compatible (behavioral, no-migration bumps since 3.0.0)
Stamp < `3.0.0`	Outdated	Upgrade recommended — re-evaluate against current standards

After a successful upgrade, every stamped document carries > **CodeOps Skills Version**: 3.11.0.

The 4 phases (overview)

The same flow applies to both branches. Per-document checklists are in upgrade-checklists.md; the Phase 2B gate detail is in content-quality-gate.md.

Phase 1 — Assessment

Locate the directory and read all .md documents in it.
Detect version stamps (see above).
Load current standards — for plans, the make_plan skill's current standards; for requirements, the make_requirements skill's current standards. Coding/testing standards come from your project's coding/testing standards (CLAUDE.md).
Generate a gap analysis — compare each document against current templates and checklists.

Error conditions (STOP):

Error	Action
Target directory doesn't exist	STOP — suggest the make_plan skill (plans) or the make_requirements skill (requirements)
Directory is empty / has no `.md` files	STOP — suggest make_plan / make_requirements
Artifact is already at version `3.0.0`, `3.1.0`, `3.2.0`, `3.3.0`, `3.3.1`, or `3.3.2`	Report "Already current, no upgrade needed" and stop

Phase 2 — Upgrade Report (BEFORE any changes)

Grounded Options & Recommendations (coding standards → Working style) apply here. Before presenting options/findings/recommendations: filter out non-viable ones (no strawmen; ≥2 only when ≥2 are genuinely viable, else present the single viable path and name what was rejected), second-guess each, verify any code-modifying option against the actual current code (cite file:line), and lead with a recommendation backed by grounded reasoning. Match ceremony to stakes — the user decides. Apply the recommendation-hardening protocol (_shared/recommendation-hardening.md) to consequential recommendations; escalate to an independent challenger only when the decision is genuinely high-stakes.

Present findings to the user before making any changes:

## Upgrade Report: [feature-name | requirements]

**Current Version:** [stamp or "none (pre-versioning)"]
**Target Version:** 3.3.2

### Will Be Added (missing sections/content)
- [ ] ...

### Will Be Updated (structural/format changes)
- [ ] ...

### Will Be Preserved (user content — no changes)
- [ ] ...

### Proceed with upgrade?

Then ask the user to choose:

"Yes, apply all upgrades" — proceed to Phase 2B.
"Show me the details first" — display a side-by-side comparison of changes, then re-ask.
"No, keep as-is" — abort the upgrade.

Phase 2B — Content Quality Gate (🚨 non-negotiable hard gate)

Phase 3 is BLOCKED until this gate passes. A document with modern formatting but vague content is still a bad document. Before any structural upgrade you MUST scan every existing document for content gaps across all 12 ambiguity categories, flag every vague-language pattern, append findings to the Ambiguity Register tagged (upgrade), and resolve every entry with an explicit user decision.

🚫 While blocked: do not proceed to Phase 3, do not update version stamps, do not modify any document content, do not accept vague language as "good enough", do not rationalize ("the existing approach seems reasonable").

✅ The gate opens ONLY when all 5 conditions hold:

Every content gap found is in the Ambiguity Register.
Every register entry has Status = "✅ Resolved" with the user's explicit decision.
The user has reviewed and confirmed the complete register (for >15 items, present in batches by category).
Zero vague-language patterns remain unresolved.
Zero deferred items — the user decides NOW (no-deferral, no-delegation policy).

Full detail — the 12 categories, the vague-language list, register handling/append/template, and the gate-open conditions — is in content-quality-gate.md. Read it before running Phase 2B.

Phase 3 — Apply Upgrades

Once the gate passes, re-evaluate each document against current templates AND write the resolved content fixes into the documents with an AR # back-reference. Use the per-document re-evaluation checklists in upgrade-checklists.md (separate checklists for the plan docs 00-index / 00-ambiguity-register / 01-requirements / 02-current-state / 03-tech-specs / 07-testing-strategy / 99-execution-plan, and for the requirements docs README / RD documents / register).

🚨 Content Preservation Rules — the upgrade MUST NOT destroy user work:

Content type	Action
Technical specifications (`03-XX` docs)	Preserve verbatim
Scope decisions	Preserve verbatim
Completed task checkboxes `[x]`	Preserve
Requirement descriptions, acceptance criteria, rationale	Preserve verbatim
Priority/status decisions, custom notes/comments	Preserve
Version stamps	Update to `3.3.2`
Template structural sections	Update if the format changed
Missing protocol sections (security, techdocs, session protocol, …)	Add
Cross-references	Update to current skill/command names
Content gaps resolved in Phase 2B	Insert with an `AR #` back-reference

Phase 4 — Verification

✅ Confirm all documents updated.
✅ No user content lost (compare document count, task/RD count, technical specs, acceptance criteria).
✅ Version stamps now read > **CodeOps Skills Version**: 3.11.0.
✅ Ambiguity Register complete — every entry resolved.
✅ Zero vague language remaining in any document.
✅ AR # back-references present for every content gap resolved during the upgrade.
✅ Present the upgrade summary to the user.

## Upgrade Complete: [feature-name | requirements]

**Version:** [old] → 3.3.2

### Structural Changes Applied
- ...

### Content Quality Gaps Resolved: [X] items
- See `00-ambiguity-register.md` for the full audit trail.

### Documents Updated: X of Y
### User Content Preserved: ✅ All technical specs, task states, and custom content intact
### Ambiguity Register: ✅ All entries resolved — zero vague language remaining

Partial-upgrade resume handling

If a previous upgrade was interrupted (some documents stamped with the target version, others not):

Detect the partial state from the per-document stamps.
Resume — only upgrade documents that still need it; leave current ones untouched.
Report which documents were already current and which were upgraded.

Notes & pointers

The upgrade does NOT auto-advance the roadmap. Roadmap status is unchanged by an upgrade.
Cross-references to update during the upgrade: make_plan → the make_plan skill; requirements → the make_requirements skill; techdocs → the techdocs skill; git-commands → the /gitcm and /gitcmp commands; project conventions → the project's CLAUDE.md (or detected project conventions); coding/testing → your project's coding/testing standards (CLAUDE.md).
Related skills/commands: make_plan, make_requirements, exec_plan, roadmap, techdocs, /gitcm, /gitcmp.

Key principles: version-agnostic full re-evaluation (not incremental patches); content-first (the gate catches gaps before structural upgrades); non-destructive (user content preserved verbatim); transparent (changes approved before applied); resumable; zero-ambiguity (no vague language, no deferred decisions, no AI guesswork survives the upgrade).