Exécutez n'importe quel Skill dans Manus
en un clic

Exécutez n'importe quel Skill dans Manus en un clic

eng-flow

Étoiles1

Forks0

Mis à jour4 juin 2026 à 06:31

Orchestrator for the eng pipeline. Runs the five skills in order — scope → grill → eng-review → tdd → execute — driven entirely off the phase recorded in the .plan doc, pausing at a gate between each so the user stays in control. Picks up wherever the doc left off, so it's also "resume my planning flow". Use when the user wants to run the whole plan-to-ship pipeline rather than invoking skills one at a time. Triggers: "eng flow", "run the pipeline", "plan to ship", "take this from idea to code", "resume the flow".

Installation

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Exécuter dans Manus

Source

nitintf

nitintf/ai-skills

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Exécuter dans Manus

Métiers associésSOC

Basé sur la classification professionnelle SOC

Développeurs de logicielsProfessions informatiques et mathématiques·SOC 15-1252

SKILL.md

readonly

name

eng-flow

description

eng-flow — run the pipeline end to end, one gate at a time

You orchestrate the five eng skills. You are deliberately dumb: the doc holds all the state. You read the current phase and run the next skill. This is exactly why the skills also work solo — there's no orchestrator-only logic.

First, read the doc schema at ${CLAUDE_PLUGIN_ROOT}/SPEC.md so you understand the phase lifecycle.

How it works

1. Find or start the feature

If the user gave a task with no .plan doc yet → start at scope.
If a .plan/<feature-slug>/ exists → read its README.md and the ticket docs to find the current phase. If several features exist, ask which.

2. Run the next skill based on phase

Use this mapping (the doc's phase → the skill to run next):

current phase	next skill
(no doc)	`scope`
`scoped`	`grill`
`grilled`	`eng-review`
`reviewed`	`tdd`
`tested`	`execute`
`implemented`	done

Invoke that skill (via the Skill tool) and let it do its full job, including writing its results and advancing the phase.

3. Gate between every step

After each skill completes, stop and check in with the user before running the next one. Summarize what that step produced and what's next, e.g.: "Scope is done — 3 tickets drafted in .plan/jira-assets-csv/. Next is /grill to resolve 7 open questions. Continue?" Only proceed on confirmation.

The gate matters most before execute (code gets written) — never blow through that one.

4. Multi-ticket features

Run the planning phases (scope→tdd) for the whole feature, then execute tickets in dependency order. Respect each doc's depends-on.

5. Stop when done

When every ticket is implemented, report what shipped and suggest the project's ship/PR flow. The user can re-run /eng-flow anytime to resume — it just reads the phase and continues.

Plus depuis ce dépôt

même dépôt

backfill-tests

nitintf/ai-skills

Add tests to existing untested code. Picks a target by risk, reads the code to understand what it actually does, matches the repo's test style, then writes characterization tests that lock in current behavior — covering happy path, edge cases, and error paths. Surfaces suspected bugs instead of silently encoding them. Standalone: does NOT touch `.plan` docs. Complements `/tdd`, which specs tests for NEW features; this covers code that already shipped without them. Use when a module has no tests, before refactoring risky code, or when hardening a legacy area. Triggers: "add tests for this", "backfill tests", "this has no tests", "cover this code", "characterization tests".

2026-07-121

refactor

nitintf/ai-skills

Plan and safely execute a behavior-preserving refactor. Establishes a test safety net first (runs existing tests green, adds characterization tests where coverage is thin), learns the house style, plans the change as small atomic steps, then executes step by step keeping tests green the whole way — verifying behavior never changed. Standalone: does NOT touch `.plan` docs. Use when reshaping existing code without changing what it does — reducing duplication, untangling coupling, renaming, extracting, restructuring. Triggers: "refactor this", "clean up this code", "untangle this", "extract this", "restructure this". NOT for behavior changes — that's a feature, use `/scope`.

2026-07-121

review

nitintf/ai-skills

Fast pre-commit review of your uncommitted working diff, in house style, before you commit. Reads staged + unstaged changes and new files, learns how the codebase already does things, and gives a high-signal gut-check: correctness, consistency with the codebase, obvious security/data issues, leftover debug/dead code, and missing tests — separating blocking issues from nits. Standalone: does NOT touch `.plan` docs. Distinct from `/pr-review` (whole branch vs main, with GitHub context) — this is the quick check on the working tree. Use right before committing. Triggers: "review my changes", "review the diff", "check this before I commit", "quick review", "review my working tree".

2026-07-121

understand

nitintf/ai-skills

Map an unfamiliar codebase or subsystem before you touch it. Reads the repo's structure, entry points, and key paths, traces how data and control actually flow, and extracts the house conventions — then delivers an architecture map: what the major pieces are, how they fit, where to make a given change, and what looks risky. Standalone: does NOT touch `.plan` docs, but its output is the ideal warm-up before `/scope`. Use when onboarding to a new repo/job, picking up an unfamiliar area, or answering "how does this work?". Triggers: "understand this codebase", "map this repo", "how does this work", "explain this subsystem", "help me onboard".

2026-07-121

note

nitintf/ai-skills

Capture something you just learned into your Obsidian vault as a well-placed, well-written note in your own voice. Takes a spoken/typed brain-dump, figures out where it belongs in the Learn/ hierarchy, decides whether to create a new note or merge into an existing one, writes it in Nitin's note-taking voice (not AI voice), wires up wikilinks, and updates the parent index hub. Auto-detects two modes: verbatim (you dumped the full content) and expand (you gave a topic + a few points and want it written up). Use when the user says "I just learned X", "add this to my second brain", "note this down", "put this in obsidian", "capture this", or invokes /note.

2026-07-121

pr-review

nitintf/ai-skills

Staff/principal-engineer review of a pull request. Reads the current branch's commits and diff against the main branch, pulls extra context from GitHub via `gh` (PR description, linked issues, CI, existing review threads), then reviews the change the way a senior reviewer actually does: correctness and edge cases first, then architecture, then — critically — consistency with how THIS codebase already builds things, so the code reads like the team wrote it. Standalone: does NOT touch `.plan` docs or the eng-flow pipeline. Use when the user wants a PR or branch reviewed before it lands. Triggers: "review this PR", "pr review", "review my branch", "review before I merge", "code review this".

2026-06-111

name

eng-flow

description

eng-flow — run the pipeline end to end, one gate at a time

First, read the doc schema at ${CLAUDE_PLUGIN_ROOT}/SPEC.md so you understand the phase lifecycle.

How it works

1. Find or start the feature

If the user gave a task with no .plan doc yet → start at scope.
If a .plan/<feature-slug>/ exists → read its README.md and the ticket docs to find the current phase. If several features exist, ask which.

2. Run the next skill based on phase

Use this mapping (the doc's phase → the skill to run next):

current phase	next skill
(no doc)	`scope`
`scoped`	`grill`
`grilled`	`eng-review`
`reviewed`	`tdd`
`tested`	`execute`
`implemented`	done

Invoke that skill (via the Skill tool) and let it do its full job, including writing its results and advancing the phase.

3. Gate between every step

The gate matters most before execute (code gets written) — never blow through that one.

4. Multi-ticket features

Run the planning phases (scope→tdd) for the whole feature, then execute tickets in dependency order. Respect each doc's depends-on.

5. Stop when done

When every ticket is implemented, report what shipped and suggest the project's ship/PR flow. The user can re-run /eng-flow anytime to resume — it just reads the phase and continues.