Run any Skill in Manus with one click

emmi-team-manager

Stars4

Forks0

UpdatedApril 14, 2026 at 22:33

Emmi team workflows: GitHub issues, branches, PRs, reviews, task splitting, release notes. Use for sprint planning, delegation, or process.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

Embretr

Embretr/emmi

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Computer and Information Systems ManagersManagement Occupations·SOC 11-3021

SKILL.md

readonly

name	emmi-team-manager
description	Emmi team workflows: GitHub issues, branches, PRs, reviews, task splitting, release notes. Use for sprint planning, delegation, or process.

Team manager

GitHub workflow

Issues

Every piece of work is a GitHub issue before it is code.

Title: imperative, specific. "Add password reset flow" not "Auth improvements."
Body: problem statement, acceptance criteria as a checklist, any relevant context or links.
Labels: feature / bug / chore + size (xs / s / m / l). Size is effort estimate, not time.
Milestone: the MVP or release this issue belongs to.

Create issues via CLI:

gh issue create --title "..." --body "..." --label "feature,s" --milestone "mvp"
gh issue list --milestone "mvp"
gh issue close 42

Branches

Short-lived. Merge within days, not weeks.
Named: feat/short-description, fix/short-description, chore/short-description.
Every branch links to an issue: reference #42 in the PR body.
Delete branches after merge.

Pull requests

One concern per PR. A PR that does two things is two PRs.
Vertical slices. Each PR delivers end-user value where possible — schema + procedure + UI together, not separately.
PR body includes: what this does, how to test it, screenshots for UI changes, issue reference.
Size: aim for PRs reviewable in under 20 minutes. Large PRs get missed or rubber-stamped.

gh pr create --title "..." --body "..." --assignee "@me"
gh pr list
gh pr merge 42 --squash --delete-branch

Reviews

Reviewers check:

Does it solve the issue it references?
Are there tests for non-trivial logic?
Are there any obvious security issues (unvalidated input, missing auth check, exposed secrets)?
UI changes: does it match the design system, does it work on mobile?
No unnecessary complexity introduced.

Reviews are not style enforcement — that is what linters are for.

Task splitting

Vertical slices first. Split by user-visible outcome, not by layer (do not have separate issues for "add DB schema", "add API", "add UI" unless they are genuinely parallelisable).
Spike tasks explicit. If a task requires research before implementation, create a spike issue with a timebox. Output is a decision, not code.
Blockers visible. If an issue cannot start until another is done, note it explicitly in the issue body.
No tasks smaller than 30 minutes or larger than 2 days. Too small = overhead, too large = hard to review and risky to merge.

Releases

Every release to production gets a brief note documenting:

What shipped.
Any migration steps required.
How to roll back if something goes wrong.
Known issues or limitations.

Write it as a GitHub release or in the plan doc. One paragraph is enough for small releases.

gh release create v1.2.0 --title "v1.2.0" --notes "..."

Communication defaults

Async first. Decisions in writing (GitHub issues, PR comments) so they are searchable and don't require everyone online at the same time.
Decisions in the repo. If it affects the code, the decision lives near the code — ADR, plan doc, or issue comment. Not in Slack or a meeting.
No drive-by architecture. Technical decisions that affect multiple files or services go through the iterative-process or architect-dev skill — not a quick PR comment.

More from this repository

same repository

emmi

Embretr/emmi

Emmi opinionated skill kit: iterative product planning (MVP to production), UI/UX with block library, hard QA (ferdig-ferdig), testing and CI/CD, Railway-first deployment, Next.js+tRPC+Prisma+Better Auth+Tailwind, Expo+NativeWind, Turborepo, performance work, architecture, product and team management, browse, and analytics. Use when the user wants Emmi workflows, sub-skill by name, or "the kit". Read sub-skills from this repo root.

2026-04-174

seo-audit

Embretr/emmi

Full website SEO audit with parallel subagent delegation. Crawls up to 500 pages, detects business type, delegates to 10 specialists (7 core + 3 conditional), generates health score. Use when user says audit, full SEO check, analyze my site, or website health check.

2026-04-174

seo-backlinks

Embretr/emmi

Backlink profile analysis: referring domains, anchor text distribution, toxic link detection, competitor gap analysis. Works with free APIs (Moz, Bing Webmaster, Common Crawl) and DataForSEO extension. Use when user says backlinks, link profile, referring domains, anchor text, toxic links, link gap, link building, disavow, or backlink audit.

2026-04-174

seo-competitor-pages

Embretr/emmi

Generate SEO-optimized competitor comparison and alternatives pages. Covers "X vs Y" layouts, "alternatives to X" pages, feature matrices, schema markup, and conversion optimization. Use when user says "comparison page", "vs page", "alternatives page", "competitor comparison", "X vs Y", "versus", "compare competitors", or "alternative to".

2026-04-174

seo-content

Embretr/emmi

Content quality and E-E-A-T analysis with AI citation readiness assessment. Use when user says "content quality", "E-E-A-T", "content analysis", "readability check", "thin content", or "content audit".

2026-04-174

seo-dataforseo

Embretr/emmi

Live SEO data via DataForSEO MCP server. SERP analysis (Google, Bing, Yahoo, YouTube), keyword research (volume, difficulty, intent, trends), backlink profiles, on-page analysis (Lighthouse, content parsing), competitor analysis, content analysis, business listings, AI visibility (ChatGPT scraper, LLM mention tracking), and domain analytics. Requires DataForSEO extension installed. Use when user says "dataforseo", "live SERP", "keyword volume", "backlink data", "competitor data", "AI visibility check", "LLM mentions", or "real search data".

2026-04-174

name	emmi-team-manager
description	Emmi team workflows: GitHub issues, branches, PRs, reviews, task splitting, release notes. Use for sprint planning, delegation, or process.

Team manager

GitHub workflow

Issues

Every piece of work is a GitHub issue before it is code.

Title: imperative, specific. "Add password reset flow" not "Auth improvements."
Body: problem statement, acceptance criteria as a checklist, any relevant context or links.
Labels: feature / bug / chore + size (xs / s / m / l). Size is effort estimate, not time.
Milestone: the MVP or release this issue belongs to.

Create issues via CLI:

gh issue create --title "..." --body "..." --label "feature,s" --milestone "mvp"
gh issue list --milestone "mvp"
gh issue close 42

Branches

Short-lived. Merge within days, not weeks.
Named: feat/short-description, fix/short-description, chore/short-description.
Every branch links to an issue: reference #42 in the PR body.
Delete branches after merge.

Pull requests

One concern per PR. A PR that does two things is two PRs.
Vertical slices. Each PR delivers end-user value where possible — schema + procedure + UI together, not separately.
PR body includes: what this does, how to test it, screenshots for UI changes, issue reference.
Size: aim for PRs reviewable in under 20 minutes. Large PRs get missed or rubber-stamped.

gh pr create --title "..." --body "..." --assignee "@me"
gh pr list
gh pr merge 42 --squash --delete-branch

Reviews

Reviewers check:

Does it solve the issue it references?
Are there tests for non-trivial logic?
Are there any obvious security issues (unvalidated input, missing auth check, exposed secrets)?
UI changes: does it match the design system, does it work on mobile?
No unnecessary complexity introduced.

Reviews are not style enforcement — that is what linters are for.

Task splitting

Vertical slices first. Split by user-visible outcome, not by layer (do not have separate issues for "add DB schema", "add API", "add UI" unless they are genuinely parallelisable).
Spike tasks explicit. If a task requires research before implementation, create a spike issue with a timebox. Output is a decision, not code.
Blockers visible. If an issue cannot start until another is done, note it explicitly in the issue body.
No tasks smaller than 30 minutes or larger than 2 days. Too small = overhead, too large = hard to review and risky to merge.

Releases

Every release to production gets a brief note documenting:

What shipped.
Any migration steps required.
How to roll back if something goes wrong.
Known issues or limitations.

Write it as a GitHub release or in the plan doc. One paragraph is enough for small releases.

gh release create v1.2.0 --title "v1.2.0" --notes "..."

Communication defaults

Async first. Decisions in writing (GitHub issues, PR comments) so they are searchable and don't require everyone online at the same time.
Decisions in the repo. If it affects the code, the decision lives near the code — ADR, plan doc, or issue comment. Not in Slack or a meeting.
No drive-by architecture. Technical decisions that affect multiple files or services go through the iterative-process or architect-dev skill — not a quick PR comment.