rommelporrasrommelporras/kiro-config/skills/post-implementation/SKILL.md

post-implementation

Skill13 starsChanged 7 months agoMITView on GitHub

Automated post-implementation workflow. Triggers when the orchestrator receives DONE from an implementation subagent. Runs quality gate, doc staleness check, auto-review, and improvement capture.

In this repository19 other files it gives its agents.
- agent-auditSkill
- codebase-auditSkill
- commitSkill
- design-and-specSkill
- dispatching-parallel-agentsSkill
- doc-driftSkill
- execution-planningSkill
- explain-codeSkill
- pushSkill
- python-auditSkill
- receiving-code-reviewSkill
- subagent-driven-developmentSkill
- systematic-debuggingSkill
- terraform-auditSkill
- test-driven-developmentSkill
- trace-codeSkill
- typescript-auditSkill
- verification-before-completionSkill
- writing-plansSkill

The file

Show its rules and text

We split this skill into the rules it gives an agent

14 rules. About 0 are common, 8 are distinctive, and 6 are very specific to this project.

≈0
Common · estimate
Many files like this have a rule of this kind.
≈8
Distinctive · estimate
This author's own choices. Worth a look.
6
Very specific
Tied to their project's names, files or tools. Probably skip.

Common
Distinctive
Very specific

Very specific:
If task diverged from plan, append Actual: note to the task entry
line 13
Distinctive:
If task description was enriched before dispatch, update plan with enriched version
line 14
Distinctive:
If failures → send back to implementer with full command output (not just "tests failed").
line 28
Distinctive:
If any doc references a modified file → flag it
line 33
Distinctive:
If staleness found → dispatch devops-docs to update, or flag for user
line 34
Very specific:
Metrics staleness: After the quality gate, grep docs/ and README.md for test counts and coverage percentages.
line 35
Very specific:
Numeric drift check: Run bash ~/.kiro/hooks/doc-consistency.sh.
line 39
Distinctive:
Doc-drift detection: If git status --porcelain shows created or deleted files, invoke the doc-drift skill (auto mode).
line 40
Distinctive:
Check for friction during this session:
line 62
Distinctive:
If file is inaccessible, log to conversation instead — do not fail silently.
line 78
Distinctive:
If this task completes the final phase of a spec:
line 82
Very specific:
Check if all plan checkboxes are [x]
line 84
Very specific:
Add Status: COMPLETE (date) to the spec header with final metrics
line 85
Very specific:
Update docs/TODO.md to mark the spec section done
line 86

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.

Files

SKILL.md

Trigger

Fires automatically after any implementation subagent (devops-python, devops-typescript, devops-shell, devops-refactor, devops-kiro-config, devops-frontend) returns DONE or DONE_WITH_CONCERNS. Do not skip. Do not ask the user.

Step 1: Update tracking documents

Plan file: - [ ] → - [x] for completed tasks
If task diverged from plan, append Actual: note to the task entry
If task description was enriched before dispatch, update plan with enriched version

Step 2: Quality gate

Detect project type from config files:

Config found	Commands to run
`pyproject.toml`	`uv run ruff check .` · `uv run ruff format --check .` · `uv run mypy .` · `uv run pytest tests/ -q`
`package.json`	`npm run lint` · `npm run typecheck` · `npm test`
`*.sh` files changed	`shellcheck` on each changed `.sh` file
Mixed (both)	Run all applicable
None found	Skip — warn user: "No pyproject.toml or package.json found — skipping automated quality checks."

If failures → send back to implementer with full command output (not just "tests failed"). Max 3 retries. If still failing after 3 attempts, stop and surface to user: "Implementer couldn't resolve this after 3 attempts. Manual intervention needed."

Step 3: Doc staleness check

For each file modified by the implementer, grep docs/ for references to that file
If any doc references a modified file → flag it
If staleness found → dispatch devops-docs to update, or flag for user
Metrics staleness: After the quality gate, grep docs/ and README.md for test counts and coverage percentages. If they don't match the current numbers from the test run, flag them for update. Common patterns: \d+ tests, \d+%\s*coverage, \d+ passed.
Numeric drift check: Run bash ~/.kiro/hooks/doc-consistency.sh. If it reports DRIFT, flag the drifted files for update (dispatch devops-docs or include in doc-drift findings if the skill is active).
Doc-drift detection: If git status --porcelain shows created or deleted files, invoke the doc-drift skill (auto mode). The skill checks whether changes are in tracked categories and runs detection if so. If no docs-structure.md exists in the project, skip — doc-drift auto mode requires it.

Step 4: Auto-review

Dispatch devops-reviewer with:

Files created/modified
What the implementation does
Implementer's concerns (if any)

Wait for verdict.

Step 5: Handle review findings

Verdict	Action
CRITICAL	Send back to implementer with fix list. Loop max 3 attempts — if still unresolved, surface to user: "Implementer couldn't resolve this after 3 attempts. Manual intervention needed."
IMPORTANT	Present to user, ask if they want fixes applied
SUGGESTIONS	Include in summary
APPROVE	Proceed

Step 6: Improvement capture

Check for friction during this session:

Retries > 1? Log cause
Routing corrected? Log mismatch
Context missing? Log what was needed

Append to ~/.kiro/docs/improvements/pending.md:

## YYYY-MM-DD — session in <project path>

### <Category>: <short title>
- What happened: <description>
- Root cause: <steering gap | routing issue | missing skill | missing context>
- Suggested fix: <specific action>

If file is inaccessible, log to conversation instead — do not fail silently.

Step 7: Spec completion check

If this task completes the final phase of a spec:

Check if all plan checkboxes are [x]
Add Status: COMPLETE (date) to the spec header with final metrics
Update docs/TODO.md to mark the spec section done
Dispatch these as a parallel task alongside the review — don't wait for the user to ask

Step 8: Present results

Summary of changes (files modified, key decisions)
Review verdict and findings
Doc staleness warnings (if any)
Concerns from implementer or reviewer
Next steps

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

It worked
Partly
It didn't

What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free