Menu
Create a new implementation plan in the repo's planning area.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
Integrate and use @stll/folio-agents, the framework-neutral LLM tool layer over @stll/folio-core: function-calling tools that read and mutate a .docx document, with every mutation landing as a tracked change or comment pending human review. Load this skill when wiring folio's tools into an agent's tool-use loop (TanStack AI, Vercel AI SDK, raw Anthropic/OpenAI SDKs, or a custom loop), choosing between the headless reviewer bridge and the live-editor-ref bridge, or summarizing what changed between two document versions.
Shape a feature or problem before implementation. Use this when the request is still fuzzy, when several solutions are possible, or when execution risks outrunning product clarity.
Process automated PR review comments systematically. Use this for CodeRabbit, Gemini, GitHub Copilot, Devin, Greptile, and similar bots.
Track down a behavior that used to work and now fails, changed, or regressed. Use this when a bug report points to a recent breakage, especially when the cause is not obvious yet.
Run a security-focused code audit with a generic checklist first, then layer on repo-specific risks.
Review and update third-party dependencies. Use this when asked to upgrade packages, survey new minor or major releases for useful features, assess whether a repository can adopt them, or validate whether a release looks suspicious before bumping it.
| name | plan |
| description | Create a new implementation plan in the repo's planning area. |
Create a new implementation plan in the repo's planning area.
$ARGUMENTS — A short slug for the plan, ideally kebab-case. If empty, derive a reasonable slug from the task.
Prefer this shared planning layout when the repo supports it:
.agents/ARCHITECTURE.md
.agents/GOALS.md
.agents/STATUS.md
.agents/plans/
If the repo uses a different planning area, adapt to it rather than creating duplicate systems.
Read planning context:
.agents/ARCHITECTURE.md if present.agents/GOALS.md if presentDetermine the plan location:
.agents/plans/Determine the next plan number:
ls .agents/plans/
Use the next sequential number when numbered plans are already in use. If the repo does not number plans, follow its established naming.
Research before writing:
Write the plan with this structure:
# Plan: [Feature Name]
Date: YYYY-MM-DD
## Goal
What are we building and why?
## Design Decisions
- **Decision**: Why this approach over alternatives.
## Scope
**In scope:**
- ...
**Out of scope:**
- ...
## Implementation
- `path/to/file` — what changes here
## Test Cases
What needs to be verified.
## Open Questions
Any unresolved decisions.
Plan well, do not over-specify:
Confirm before finalizing if the user is still shaping the task. If they asked you to just create the plan, go ahead and write it.