메뉴
Use when you have a written implementation plan to execute in a separate session with review checkpoints
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Query or contribute to syv.ai's shared company brain — the private 1brain GitHub repo (kunder, tilbud, teknik, strategi, wiki) — from any session, regardless of the current directory. Bootstraps a local clone when needed. Use when the user asks what syv.ai knows about a client or topic ("hvad ved vi om Krifa?", "har vi løst noget lignende før?"), wants something added to the brain ("tilføj til hjernen", mødenoter, læringer, nye dokumenter), or mentions 1brain or hjernen. All brain content is in Danish.
Write a syv.ai client proposal (tilbud, forslag, offer, PoC-beskrivelse, bud på udbud) in the company's fixed format and style, and render it as a branded PDF. Works from any session — bootstraps the private 1brain repo where the full proposal skill, templates and Typst PDF pipeline live. Trigger on opgavebeskrivelser, kravspecifikationer, SKI-udbud, RFPs and "lav et tilbud til …", also when the word "tilbud" isn't used directly.
Interviews the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when the user wants to stress-test a plan, get grilled on their design, or mentions "grill me".
Zooms out to give broader context or a higher-level perspective on a section of code. Use when you're unfamiliar with an area of code or need to understand how it fits into the bigger picture.
How to add or restyle a D3 diagram in the playbook docs (MkDocs Material). Use for any flowchart, diagram, chart, or graphic in docs/.
Use when a plan is multi-file, architecture-heavy, data-heavy, UI-heavy, ambiguous, or risky enough that the wrong direction would be expensive to undo. Renders the plan as a single self-contained HTML review surface — diagrams, file maps, annotated code, open questions — opened in the browser, with decisions captured in the terminal.
| name | executing-plans |
| description | Use when you have a written implementation plan to execute in a separate session with review checkpoints |
Load plan, review critically, execute all tasks, report when complete.
Announce at start: "I'm using the executing-plans skill to implement this plan."
For each task:
After all tasks complete and verified:
STOP executing immediately when:
Ask for clarification rather than guessing.
Return to Review (Step 1) when:
Don't force through blockers - stop and ask.
Before claiming a task complete: run the actual verification (tests, build, the task's acceptance check) and read the output — never claim from memory or "should pass".
Related workflow skills:
