← Browse

@g2i-ai/workflow

B

Orchestrate the repo workflow from brief through draft PR using skills and thin role wrappers.

skillclaude

Install

agr install @g2i-ai/workflow --target claude

Writes 1 file into .claude/skills/, pinned to git-7a8991c5.

  • .claude/skills/workflow/SKILL.md

Document


name: workflow description: Orchestrate the repo workflow from brief through draft PR using skills and thin role wrappers.

Workflow

Objective

Coordinate the standard delivery flow:

brief -> spec -> tdd -> code -> review -> draft-pr

This is a skill entry point, not a command wrapper. Keep the orchestration light and route work into the stage skills instead of duplicating their guidance here.

Instructions

  1. Ask for the feature or change name and which stage range to run (full, partial like spec -> code, or resume from an existing artifact).
  2. Check which stage artifacts already exist before asking the user to recreate them:
    • docs/briefs/
    • docs/specs/
    • docs/qa/reports/
  3. For each selected stage, invoke the matching skill (brief, spec, tdd, code, review, draft-pr). Each skill self-routes via its own Invocation preface: brief, spec, tdd, code, and test run inline in the current chat under the appropriate persona, while review, draft-pr, and pr-description default to delegating to their owning subagent.
  4. After each stage, summarize:
    • what was produced
    • which paths changed or were created
    • open decisions or blockers
    • the next recommended skill
  5. Keep context compact. Prefer referencing existing artifact paths over restating full document contents.
  6. Do not create workflow state files or command-era JSON checkpoint files in Phase 1.

PR validation (before draft-pr)

  • Prefer targeted checks while iterating; do not rerun full verification on every tiny commit by default.
  • Before opening or updating a PR: run a full verification pass from the repo root. Include builds when the change touches app/runtime code, config, dependencies, or anything that could affect shipped output.
  • Docs-only edits (markdown with no runtime effect): a full build is not required; still run linting when the diff touches linted paths.
  • On follow-up pushes to an open PR, rerun checks when the changeset meaningfully affects verified code.

Stage Outputs

  • brief -> docs/briefs/{feature}.md
  • spec -> docs/specs/{feature}.md
  • tdd -> failing or newly added unit tests
  • code -> implementation and verification results
  • review -> docs/qa/reports/{date}-{branch-or-pr}.md
  • draft-pr -> branch, commit, and draft PR output

Trustgrade B

  • passBody integrity

    Whether the stored document is plausibly the kind of file the artifact declares, rather than something fetched by mistake.

  • passType matchnot applicable to this artifact type

    Whether the artifact is really the kind of thing its metadata claims it is.

  • passFreshness

    How long since the source repository was last pushed to.

  • passPrompt injection

    Scans the artifact's own text for instructions aimed at your agent rather than at you.

  • warnLicenseno SPDX license detected

    Whether the source repository declares an SPDX license permissive enough to redistribute.

How the grade is calculated

Each check contributes 0 points when it passes, 1 when it warns, and 2 when it fails. The total maps to a letter:

  • Aevery check passed
  • Bone warning
  • Ctwo warnings
  • Dprompt injection or body integrity failed, or three warnings
  • Fone of those failed, and something else is wrong

These are automated hygiene checks, not a security audit, and not a dependency or vulnerability scan. A grade of A means nothing was flagged — not that the artifact is safe.

Versions

  • git-7a8991c5d7d92026-07-31