perihelion-platform-context

Use when implementing any feature or bugfix, before writing implementation code

Close the loop after a factory pull request merges by summarising it on its issue, closing the issue, and recording the remediated finding's pull request. Use as the action for a `github:pull_request.closed` trigger where the pull request merged from a `factory/` branch.

Scheduled sweep that checks a repository against its team standards and reports one Tessl finding per standard it drifts from, for the `remediate` action to fix. Use as the skill of the weekly conformance-sweep schedule.

Route work that crosses repositories by opening a labelled `factory` issue in each repository that must follow an upstream change, such as a new perihelion-protos release. Use as the action for a tag `push` trigger in perihelion-protos, or when an issue's work belongs in other repositories.

Keep the Canonical Workflow's ship-ticket and land-pr runs in step with what people do: cancel runs when a person takes an issue back, close the pull request when an issue ends, wake the issues it was blocking, wake an issue when a person answers Tessl's question, and cancel runs when a Tessl pull request closes. Works with Linear and with GitHub Issues.

Turn a GitHub issue labelled `factory` into one pull request by planning and building the change with the Canonical Workflow's role skills. Use as the action for a `github:issues.labeled` trigger on the `factory` label, or an `@factory` comment on a factory issue.

Get a pull request that Tessl opened for a Linear or GitHub issue ready for its owner the Perihelion way: answer review feedback, fix failing checks and conflicts test-first with the build skill on the existing branch, and tell the owner when it is ready. Opens no new pull request.

Turn the current conversation into a spec and publish it to the project issue tracker — no interview, just synthesis of what you've already discussed.

Turn one finding from a conformance sweep into a small pull request that brings the code back in line with the team standard it cites. Use as the action for a `tessl:finding.created` trigger on the conformance-sweep loop.

Review a code change for violated assumptions, cross-component composition failures, multi-step failure cascades, abuse through normal use, and verification mechanisms that can pass while production fails. Use when reviewing for adversarial failure scenarios, emergent misbehavior, or green-while-red CI, test, and deploy guards.

Review a code change for gaps where a user can do something an agent cannot, where the agent lacks the context to act, or where agent tools encode workflows instead of primitives. Use when reviewing for agent-native architecture, action and context parity, agent tool design, or system prompt context.

Review a code change for breaking changes to public interfaces, breaking changes shipped without versioning or migration paths, inconsistent error shapes, undocumented behavior changes, overloaded sentinel values, and backward-incompatible type changes. Use when reviewing for API contract stability, backward compatibility, or consumer impact.

Review a code change for off-by-one and boundary errors, null propagation, changed sentinel meanings, tooling and provisioning drift, race conditions, invalid state transitions, React effect cleanup gaps, and broken error propagation. Use when reviewing for logic bugs, behavioral correctness, or edge cases that tests miss.

Review a code change for schema dump drift, swapped ID or enum mappings, irreversible migrations, missing backfills, deploy-window breaks, orphaned references, broken dual-writes, missing transactions, unsafe hot-table indexes, silent data loss, and missing post-deploy verification. Use when reviewing database migrations, schema changes, or data backfills.

Review a code change for frontend timing and lifecycle bugs, including listeners, timers, observers and async work that outlive their component, missing effect cleanup, Turbo/Stimulus/React lifecycle mistakes, overlapping interactions, and stale promise or animation work. Use when reviewing frontend code for race conditions, cleanup, or UI state consistency.

Review a code change for structural regressions that make code harder to change, delete, or reason about, including complexity moved rather than removed, missed simplifications, shared-path special cases, oversized files, wrong-layer logic, thin wrappers, premature abstraction, dead code, coupling, vague names, data-locality smells, stale comments, and type-safety holes. Use when reviewing for maintainability, simplicity, code structure, or design quality.

Review a code change for production-observable performance problems, including N+1 queries, unbounded memory growth, missing pagination, hot-path allocations, and blocking I/O in async contexts. Use when reviewing for runtime performance, query efficiency, memory use, or scalability at expected load.

Review a code change against the rules the project has written down in its standards and agent instruction files, including frontmatter requirements, reference and inclusion conventions, cross-references, platform portability, tool-use instructions, naming and placement, writing style, and protected paths. Use when reviewing for project standards compliance, especially changes to skills, rules, plugin manifests, or AGENTS.md and CLAUDE.md files.

Review a code change for missing error handling on I/O boundaries, unbounded retries, missing timeouts, swallowed errors, resource leaks on error paths, cascading failures, and CI or deploy guards that do not mirror production. Use when reviewing for reliability, failure modes, partial failures, or graceful degradation.

Review a code change for injection, authentication and authorization bypasses, secrets in code or logs, insecure deserialization, SSRF, path traversal, cryptographic failures, feature-gate leaks, and protections disabled in production config. Use when reviewing for security, vulnerabilities, access control, or exploitable attack paths.